Something I noted in some of my scripts. (I don't know if this applies to just script counters, but that's where I saw this happen.)
When the counter drops below zero for whatever reason, it rolls over to 65,535.
Something I noted in some of my scripts. (I don't know if this applies to just script counters, but that's where I saw this happen.)
When the counter drops below zero for whatever reason, it rolls over to 65,535.
Last edited by ZoriaRPG; 01-19-2017 at 03:59 PM.
Please post a tiny sample quest that attempts to do this using whatever methods you know that have this issue, for each counter, so that we know which counters it affects, and precisely what is causing it.
I mentioned this in the past, but everyone assured me that it was fixed?
It should not be hard to write a handler to resolve this problem, although for the record, I think counters would be better as individual 32-bit width longs instead of 16-bit width ints.(This is to keep them in the same mathematical context as other ZC values.)
Check also MCounter[] and DCounter[] please, as well as Link->MP and Link->HP, which IIRC should not do this because they do have handlers to prevent that sort of thing.
http://www.zoriarpg.com/zc/LoE_Userbar.png http://zoriarpg.com/zc/EiyuuUserbar.png
http://www.zoriarpg.com/zc/CIS_Original.pnghttp://www.zoriarpg.com/zc/CIS_II_Userbar.png
Latest ZC 2.53 (Win32) | (Technical Specification | Changelog)
Latest ZC 2.55(Win32) | 2.55 Modules | (Techical Specification | Changelog)
ZC Source Code | ZClaunch Source Code
Featured Scripts & Headers: RPG.zh ( v. a0.97.1 ) ( RPG.zh Thread ) | Zelda 3 Thief's Town Treasure Chest Minigame (ffc) | Bobomb (enemy)
ZScript & ZC-Related Pastebin | ZC Dev & Builds | ARCHIVED ZC Dev & Builds | YouTube Channel | Quests and ZScript Repository
All of the code that I create and publish here is free for use, modification and distribution under the GPL v2.0, or v3.0 where applicable.
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.
http://www.zoriarpg.com/zc/LoE_Userbar.png http://zoriarpg.com/zc/EiyuuUserbar.png
http://www.zoriarpg.com/zc/CIS_Original.pnghttp://www.zoriarpg.com/zc/CIS_II_Userbar.png
Latest ZC 2.53 (Win32) | (Technical Specification | Changelog)
Latest ZC 2.55(Win32) | 2.55 Modules | (Techical Specification | Changelog)
ZC Source Code | ZClaunch Source Code
Featured Scripts & Headers: RPG.zh ( v. a0.97.1 ) ( RPG.zh Thread ) | Zelda 3 Thief's Town Treasure Chest Minigame (ffc) | Bobomb (enemy)
ZScript & ZC-Related Pastebin | ZC Dev & Builds | ARCHIVED ZC Dev & Builds | YouTube Channel | Quests and ZScript Repository
All of the code that I create and publish here is free for use, modification and distribution under the GPL v2.0, or v3.0 where applicable.
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:
...and trust me, these about in the database...Code:item script foo{ void run(int ctr){ Game->Counter[ctr]++; } }
...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.
Last edited by ZoriaRPG; 01-20-2017 at 12:52 AM.
http://www.zoriarpg.com/zc/LoE_Userbar.png http://zoriarpg.com/zc/EiyuuUserbar.png
http://www.zoriarpg.com/zc/CIS_Original.pnghttp://www.zoriarpg.com/zc/CIS_II_Userbar.png
Latest ZC 2.53 (Win32) | (Technical Specification | Changelog)
Latest ZC 2.55(Win32) | 2.55 Modules | (Techical Specification | Changelog)
ZC Source Code | ZClaunch Source Code
Featured Scripts & Headers: RPG.zh ( v. a0.97.1 ) ( RPG.zh Thread ) | Zelda 3 Thief's Town Treasure Chest Minigame (ffc) | Bobomb (enemy)
ZScript & ZC-Related Pastebin | ZC Dev & Builds | ARCHIVED ZC Dev & Builds | YouTube Channel | Quests and ZScript Repository
All of the code that I create and publish here is free for use, modification and distribution under the GPL v2.0, or v3.0 where applicable.
Rpgs have this problem. A base value is always expected to be in range 0:N, but modifiers are valid if < 0 or > N. Finally, final derived values are again expected to be within range of 0 to N when the dust settles. (This is not the case with statistical values but ZC doesn't have those. ) I would assume that setting a counter (with implicit positive range) to -1 would set it to 0 and not 65535.
What are all the counters affected by this?
This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.
I just want to point out the one "common" case in which allowing negative hp would be beneficial, since I don't believe anybody's mentioned it:
I've set up an elemental damage system where I encode the damage in the ones digit of the decimal damage number, and the actual damage in the higher digits. Then, every frame, you compare Link's hp to his hp in the previous frame. If he took damage, you can tell exactly what element it was, and adjust his hp to the correct amount based on weaknesses, etc.
The problem hits when your hp gets too low to take the full damage from an attack. To get around this I add around 1000 hp to link to make sure it never goes negative - but this messes up the built-in hp meter, and the save file, and a whole bunch of other things, meaning you need custom scripts to handle all of them.
Of course, my specific case is a bit complicated. But I've seen several other people (attempt to) use the "compare hp to last frame and then do something" strategy, that disallowing negative hp makes difficult. Ideally, the game would allow hp to go negative, but all the built-in aspects like the health meter and such would treat it as 0.
I understand if y'all don't want to do that, though.
THat's true. I wish that people used them, but one reason they do not, is that say, you want to write Game->DCounter[CR_RIUPEES] -= 10000;
Who long do you want to head that sound and watch the counter go down? Writing to Game->counter instantly applies the change.
Let me try this: Who can make a case for rollover being useful, or beneficial, in the context of counters?
@DarkDragon , @Grayswandir , and I all seem to agree that rollover in the counters is irrational.
We can always make it a rule or setting. I could put it in ffrules[], or add a global bit for it. I just don;t see the point of doing that, unless there is a very good reason for it.
Likewise, I would like to see cases against both longs as counters, and signed values; as I do not see an issue with any of these, based on what we now have. We already trim bits off of the word to make counters work with DCounter, which is signed.
http://www.zoriarpg.com/zc/LoE_Userbar.png http://zoriarpg.com/zc/EiyuuUserbar.png
http://www.zoriarpg.com/zc/CIS_Original.pnghttp://www.zoriarpg.com/zc/CIS_II_Userbar.png
Latest ZC 2.53 (Win32) | (Technical Specification | Changelog)
Latest ZC 2.55(Win32) | 2.55 Modules | (Techical Specification | Changelog)
ZC Source Code | ZClaunch Source Code
Featured Scripts & Headers: RPG.zh ( v. a0.97.1 ) ( RPG.zh Thread ) | Zelda 3 Thief's Town Treasure Chest Minigame (ffc) | Bobomb (enemy)
ZScript & ZC-Related Pastebin | ZC Dev & Builds | ARCHIVED ZC Dev & Builds | YouTube Channel | Quests and ZScript Repository
All of the code that I create and publish here is free for use, modification and distribution under the GPL v2.0, or v3.0 where applicable.
There are currently 1 users browsing this thread. (0 members and 1 guests)