Who's good with dealing with nodes? Who's good with dealing with nodes that DON'T WORK?

[lampshade]

Hello, I'm dealing with some major problems with my scenario. I'll just say that some stuff isn't working and I can't figure out why.

 

If you're interesting in helping, let me know. I'll send you my scenario and the details of what's wrong.

[*i]

I would look at it, but I would like to hear a description first. Tell me what you are trying to do, how you are doing it, how you think it should work, and what is actually happening.

[Celtic Minstrel]

What type of node isn't working?

[lampshade]

Hold on, I'm going to make a package which will include the Scenario, SDF notes, and a text file describing what and where the problems are.

[lampshade]

Nevermind, I think I found the problem by myself.

 

Nodes that are placed after a Stairway node don't work right?

Well, that's what I did.

 

There was actually another problem I thought I had, but apparently that was "fixed".

[*i]

A stairway node immediately places you in a new town. This transfers control of the nodes over to the new town and any nodes in the current town will not be called thereafter.

[Celtic Minstrel]

Hmm... would it call nodes in the new town instead? Or does the entire sequence terminate?

 

The former would seem to be a potentially useful idea...

[*i]

For some reason, I seem to recall things continuing in the town you call. I would verify this, however.

[Celtic Minstrel]

A quick look at the code suggests that this is the case – the stairway node does not set *nextspec to -1.

[Chokboyz]

Confirmed, the next node to be called will be taken in the new town special list (i.e if you take a stairway from town A to town B and the next node to be called is node X, then the node X from town B will be called).

 

Chokboyz

[*i]

As I think about this more, this is behavior that has been used to great effect, (cutscenes) so it should not be changed.

[Lilith]

Yeah, there's absolutely no reason to change it. The current behaviour is logical, I'm pretty sure the documentation mentions that it works the way it does, and changing it would completely break frame animation among other things.

[Celtic Minstrel]

Heh, I was actually saying it would be a good idea to change it to that behaviour if it did not already behave that way.

 

It would be good for the editor to take that into account, but I think that would require loading all towns simultaneously, right?

 

I have been wondering for awhile... would it be too much to have 200 towns and 100 outdoor sections in memory all at the same time?

[Niemand]

On current systems, that would hardly be an issue at all. After all, the amount of memory required would almost exactly equal the disk space that the saved scenario file takes, which is typically only a few megabytes. That's pretty trivial as RAM usage goes these days.

[*i]

I concur with Niemand. Memory usage is trivial on modern machines. I was working on code that would load all towns and outdoors into memory, but it was a bit tricky with preserving compatibility.