Node Limit

[*i]

A really basic thing to "fix" is to get rid of the pesky node limit. I have frequently found 50 to be too restrictive. While removing this altogether would be easy, the point of the node limit is to get rid of infinite loops. I propose we keep some kind of ceiling in, but make it quite high. We can always raise it if the need arises.

 

I propose we make it 2500. That should give people ample space to do nodes. I need to update a couple things, but it should be an easy fix. What are people's feelings on this?

[Lilith]

If you're going to raise the cap that high, you may as well remove it altogether. Infinite loops involving time-consuming nodes like stairways or sounds will effectively require the game to be force-quit if they're allowed to go on that long anyway.

[Khoth]

Something I've wondered about is whether it makes sense to have a limit like 200, and a new special node that's "Increase the limit in this chain by another 100", that can't be in a chain after any node that's not that one. That way, you could get as long as you needed, without being able to go infinite.

[Kelandon]

I like that idea, or Stareye's. I don't like getting rid of it entirely, because I've caused infinite loops in BoA on occasion, and the game has successfully caught me on it.

[*i]

This comes down to a design philosophy issue. The point is how much do we as the developers trust the designers. In BoA, Jeff still has an upper limit on how many calls he tolerates before the script terminates. With regard to this issue, our options are as follows:

 

1) Full trust in the designer. Eliminate the ceiling and if the designer messes up, it is his/her fault.

2) Keep some control by the developer by setting an arbitrary upper limit. Set an upper limit to protect players and if the designers need it higher we can set it.

3) Some call to reset the node counter. There is still the possibility of infinite loops, but the designer has to work a bit harder to get into this territory.

 

After speaking with Khoth, one thing that probably should be added is for Blades to handle any menu calls after each node. Such that if the designer would screw up, the player can just abort the game rather than just freeze.

[Aran]

The "increase by another 200" sounds a bit messy to me. Could we instead have an option (perhaps even a global setting) that says "turn off node limits"? It's a useful safeguard for inexperienced designers (though perhaps increase it to 500 or so), but if they know what they're doing...

 

We can have another check in the game that asks whether the game should allow this setting, with the default set to a warning - "The designer of this scenario has [...]. Do you wish to proceed?". So the player has some idea what they're getting into.

[Kelandon]

Oh, right. My choice would be this: remove the limit entirely, but add a "Pause" feature that allows the game to come to a halt in the middle of whatever it's doing (running nodes, combat, etc.) in order to access menus or other applications. Attempting to quit while paused would have the same effect as quitting during combat (no opportunity for saving).

[Spidweb]

If you change the scenario format, I strongly suggest providing extensive documentation regarding exactly what changes you make to the format, and tinkering with the flags at the beginning of the scenario file to identify its format. Then anyone working on the Windows side will have a better idea of what is going on when they try to make a version that can understand your new format's scenarios.

 

(A change of format means any change that would make new scenarios incompatible with older copies of Blades. Changing the node limit would do that.)

 

Not saying you shouldn't change the limit. Sounds like a very good idea. Just a general warning.

 

- Jeff Vogel

[Kelandon]

EDIT: Oops. Never mind me.

[*i]

I agree 100%. The thing with the node limit is we can always raise it or remove it, but never lower it or put it back. I want to find out what people would prefer. I'm going to think on this matter and what people have said here.

[Aran]

I haven't yet looked at the code, but I'm a bit surprised that the node limit is so closely entwined with the scenario format...

[*i]

It's not, as far as I can tell. It looks like a hard coded value of 50. I don't think it pops up anywhere else as I haven't looked everywhere, but I think this one specific thing is it. I believe (correct me if I'm wrong) that Jeff was speaking in general about making changes.

[Kelandon]

I had the same reaction as Aran (hence the deleted post above), but I think I figured it out. I think that Jeff doesn't mean a literal change in the format of the exs file, but rather what he defined: a change that would make new scenarios incompatible with older copies of Blades. A new scenario made without the node limit would break an older copy of Blades that still has the node limit when you get to the 50+ node part of the scenario.

 

Now, it'd be easy enough to put a warning in the readme or in the intro messages that one should use only the most recent version of BoE (or only some particular version of BoE), so I don't think that this is much of a problem. Nevertheless, it is worth documenting.

[Aran]

I have no real qualms with breaking compatibility of new scenarios with old game versions. Now, old scenarios with new game versions is another matter, since updating ancient works whose designers have disappeared is virtually impossible.

 

But the shift to open source will likely mean an end to CD-distributed and pretty much any other media that isn't downloaded from the net (who'd produce and store them?), and since the game is completely free, it's no big hassle to re-download and re-install the game.

 

Of course, we would need to implement compatibility checking so it actually tells the user that they need to update, instead of breaking randomly.

[Duskwolf]

As far as I can tell, increasing the limit on the number of nodes executed in a single encounter is just a matter of increasing the constant at special.c:1655:

 

Code:

1655|        if (num_nodes >= 50) {

The only effect of increasing this value would be that encounters longer than 50 nodes would no longer error out. Otherwise, functionality would be identical.

 

There's a completely separate limit of 50 special nodes per town, which can't be increased without modifying the scenario format. Fixing this would probably be best accomplished by "dynamicizing" allocations throughout the program - probably a good idea in the long run, but not a small task. More on this in OBoE.

[stepped pyramids]

I'm with Thuryl. Eliminate the upper limit entirely and implement some basic heuristics to prevent trivial infinite loops. And have a user-editable ceiling after which some variety of 'this may be an infinite loop' dialog is presented.

[The Almighty Doer of Stuff]

I have an idea for the node limit. What if we include a node chain limit and the Set Node Limit node, and force the designer to attach an SDF to the node to change the limit so it only goes off once, and then every time after that, when it checks to see if the flag has been set to 1 and sees it has, it simply goes to the next node without changing the limit? This would allow the designer to set however many nodes they need without allowing for infinite loops.

[*i]

You are correct, Duskwolf. I think I have decided on taking out the error part of the code entirely. The way to combat the infinite loop is after each node call, to have Blades handle any menu command is per Khoth's discussion. This way the player can at least exit out of an infinite loop.

 

Now I just have to figure out how to do the latter.

[*i]

Update: I took out the node limit entirely. It is now possible to quite the game during a node sequence by hitting the command key during execution. The same dialog for the quitting in combat comes up with options to quit or cancel. I wanted to make this nicer, but I had trouble getting it to handle menu commands. Basically, this is primarily used as an emergency feature for infinite loops, so I didn't want to put too much effort into it.

 

The following changes have been made to the code base:

 

• run_special in specials.c has been modified. Node limit has been added, num_nodes has been changed to type int, and a call to a new function node_interrupt has been added.
• node_interrupt has been added to bldsexil.c that checks for the interrupt of the command key and gives the quit prompt. This was also added to bldsexil.h.

I'll send what I have to Khoth. I think this is probably good. If anyone wants to make it better, feel free, but I think I am (for the most part) finished with this part of the project.

[Kelandon]

Sounds good to me.