Can you copy the specific issue (something to do with reflected magic not working correctly?) into a new thread?
Can you copy the specific issue (something to do with reflected magic not working correctly?) into a new thread?
Going back to the original issue, rather than adding a whole bunch of if(ri->ffcref<=31), how about this as a solution:
Any problems with that?Code:byte ffcref: 5;
We were planning to allow calling ffcs > 32 on demand. These would not be preserved in global memory, and would use resources only when in use.
The allowed range for ffcref needs defines MIN_FFCREF and MAXFFCREF. Just modify LoadFFC and vbound it's input value to a range between those values.
That's how I'd do it.
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.
Also a possible concern is that this may affect existing quests. Some may be doing things with invalid FFC pointers, and it just happens to be having no visible effect. If an FFC pointer can no longer be invalid, those benign invalid operations could become quest-breaking.
I don't think that's a reason not to change it - surely invalid operations have undefined behavior if the game doesn't catch them - but it's something to warn people about, at least.
I could always report an invalid pointer, and break, instead of returning the index, instead of vbounding them. Returning 0 or -1 there would probably be bad, for similar reasons.
I read your post, and I hope you will stick around for these little discussions in the future.
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.
Here's a thought: add a 33rd FFC. Don't save it or load it; just make the arrays bigger and don't do anything else. Whenever ffcref is set, if it would be out of range, point it to #33. It won't hurt anything, and it won't need further verification.
Of course, if FFCs were changed to structs (which shouldn't be hard), you'd only need one global dummy rather than one per screen.
Doesn't FFCREF only need to be validated (i) when the interpreter first begins executing the script; and (ii) when a script explicitly changes its value? That doesn't seem like too many places to check if the ref is valid and if not, terminate the script with a warning message.
EDIT: Ah, I see the issue.
I'm not so against a lot of if(isValid(ffcref)), though. Sure it's ugly, but it's safe, makes it clear what the code is intending to do, makes it easy to later change the number of FFCs (or allow the refs to be nonconsecutive integers, i.e. UIDs), and makes it slightly more painful to add gratuitous new FFC variables
I think it would be a good idea to find out what @Gleeok is working on in this regard. A month or two back, he said that he was still planning to work on FFC memory management, user-created FFCs, and stuff of that sort. if(isValid(ffcref)) would become quite important at that point. The only things that I had at all considered adding to ffcs, that would require new values and variables are: Solidity flags, and a running flag. A running flag would be useful say, to pause/suspend and unpause/resume a script. That one is surely gratuitous.
The solidity, I figured I would just use the present 'solid' flag, and we would read the combo solidity for each combo comprising the ffc. (I wouldn't mind making ffcs larger than 4x4, too, but that is incidental.)
All of that more belongs in a dev topic. I like the solutions of validity checking, and I also like the idea of putting ffcs into their own class or struct. I'm concerned that @Gleeok may already have some of this legwork done, and I do not want to step on his toes.
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.
Sure, that makes sense. And I completely agree that ffcs (and the ASM interpreter) could use a good refactoring.
Different things: The FFC memory issue has to do with how they are stored inefficiently (in the map struct) after being read from the quest file; the user-created scripts was an AS thing. I haven't started the ffc refactor because I haven't had time... :/ ..Also it's possible I might break the build for a day or two once I actually start it, so I'll start a thread about it first, depends on how long it takes.
Surely "isValid(ffcref)" is like the most horrible last-resort anti-solution for the problem, isn't it? I mean it has to be valid for it to run in the first place, right?
This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.
There are currently 1 users browsing this thread. (0 members and 1 guests)