Script Counters Roll Over to Max Int When Going Below Zero

There are two issues here we should disentagle:
- preventing scripts from decrementing a counter, if doing so would cause it to wrap around to a positive value;
- supporting negative values for counters that are currently unsigned.

Both issues have some merit, but the former is much easier and self-contained than the latter (check in the appropriate ZASM interpreter code before applying a change, vs. go through all places where the game engine uses a counter and make sure nothing breaks badly when the counter is negative.)

Are any old scripts relying on the counter-wrapping behavior? It seems unlikely, but I might as well ask.

Quote:

---

Originally Posted by DarkDragon

Are any old scripts relying on the counter-wrapping behavior? It seems unlikely, but I might as well ask.

---

Unlikely, but possible. I have used Counters as global variables is the past because, well they are there and I didn't need them for anything else. I have at least once used a counter as a timer of sorts that incremented every frame and expected it to wrap and keep going. We are talking about fixing a non-issue and creating potential issues for any scripts in the last ~10 years that expect a variable to act like a variable.

I'll ask this plainly this time. Why is the way it is now an issue?

You know what... i was adding ffrules[] to ZScript. I can just make the behaviour a script-set rule, given that it only affects counters modified by script, and whatever guards we set can be set per counter, or globally.

Is that sufficient to prevent concerns?

The same could potentially work for allowing negative counters, and even long counters. We can make counters longs, and artificially roll them at the old values, unless a quest rule 'large counters' is set, and allow negative by quest or script rule. This would emulate the old behaviour for existing quests.

I'll try to punch this one out tomorrow. It might only go into 2.55.