Script Counters Roll Over to Max Int When Going Below Zero

[Saffith]

I don't know if we would consider this a problem. Counters are uint16_t; that's just what they do. It's not unreasonable behavior. Maybe it's unexpected that the range is different than other numbers, but plenty of built-in things have different ranges.

[ZoriaRPG]

I don't know if we would consider this a problem. Counters are uint16_t; that's just what they do. It's not unreasonable behavior. Maybe it's unexpected that the range is different than other numbers, but plenty of built-in things have different ranges.

Sure, but when scripts modify them without checking if the post-modufied sum exceeds their value limit, then they generate bus.

The real problem is that ADDR/V don't care what they are writing here. AFAIK increasing a fix to > 214749.9999 doesn't roll it over to -214747.9999, does it?

For a an int 16, it is normal, but in their application, rolling over is irrational, and only scripta can do it. Picking up counter ref items does not.

I could add a check to prevent this behaviour in ZASM. Need to check if this will be problematic.

[SUCCESSOR]

Sure, but when scripts modify them without checking if the post-modufied sum exceeds their value limit, then they generate bus.

The real problem is that ADDR/V don't care what they are writing here. AFAIK increasing a fix to > 214749.9999 doesn't roll it over to -214747.9999, does it?

For a an int 16, it is normal, but in their application, rolling over is irrational, and only scripta can do it. Picking up counter ref items does not.

I could add a check to prevent this behaviour in ZASM. Need to check if this will be problematic.

o.O I don't know if I am tired from school and work but sometimes when you talk I can't wrap my head around what you are trying to say. Longs, Zscript variables, do indeed wrap if you exceed them. I know they have a funniness about them with the whole decimal thing it does, but... that's another bag of WTF. I don't know what behavior you'd want counters to have that would change the way they behave. I don't believe it would happen in game besides through scripting.

If you are coding and setting a value to a variable without concern for what that variable can contain or what you are writing to it then you aren't coding very well.

[ZoriaRPG]

o.O I don't know if I am tired from school and work but sometimes when you talk I can't wrap my head around what you are trying to say. Longs, Zscript variables, do indeed wrap if you exceed them. I know they have a funniness about them with the whole decimal thing it does, but... that's another bag of WTF. I don't know what behavior you'd want counters to have that would change the way they behave. I don't believe it would happen in game besides through scripting.

If you are coding and setting a value to a variable without concern for what that variable can contain or what you are writing to it then you aren't coding very well.

(Emphasis, mine.)

Absolutely true. I check for these sorts of things whenever possible, but when people have a script like this:

item script foo{
    void run(int ctr){
        Game->Counter[ctr]++;
    }
}

...and trust me, these about in the database...

...then it can cause rollover. It's illogical for a counter to roll over anyway. That's my real point. That, and the behaviour doesn't match internal counter ref behaviour from items, IIRC.

ZScript fix values do indeed wrap, although the values generated are bizarre.

214747 += 1 goes to 214748, and ++ again wraps to -214747.7296. ??? What?

9999 - 3647 = 6352, not 7296. What is happening there?

214748.3647 += .0001 wraps to -214748.3648.