I suppose I need to go over all this at some point...
The buffer is just a std::string. Any limit on it is from that class, and it may vary by platform. Not that it's all that hard to replace, probably.Increase the script buffer from ~18MB to MAX_LONG in bytes.
When is 255 not enough? That's a significant design consideration for an extremely rare case.Increase other operational pointers for datatype objects from 255 to *.
Why? There's no way to fit that into existing naming standards, it would make it impossible to implement the ternary operator (not that I expect that to happen anyway), and there isn't any obvious benefit.Add some lexer symbols, such as ? (question-mark) to be used in function names, such as ?InAir()
Okay, I guess? Again, I don't see much benefit. It'll create more reserved words, and "repeat" in particular is likely to be used in existing scripts.Add AngelScript style and token, and or token.
Add Until() and Unless() expressions.
Add Repeat(int iterations) loop type.
That's going to be seriously limited without fundamentally changing how scripts work. Functions aren't shared among compiled scripts, so a pointer passed from one script to another would become invalid.Add function pointers.
UID behavior has already changed in a way that would break compatibility.Read UIDs to use as pointer refs. useful for finding a specific part of a segmented enemy.
This is right at the top of the list of things we absolutely should not do. One of the big problems with ZScript is all the internal behavior it already exposes. Anything that's visible to ZScript has to remain in the game, or at least be emulated, indefinitely.Allow reading most internal variables, including enemy timers, and whatnot.
This is also one of the reasons for converting all the built-in objects to scripts: it would allow access to their inner workings without putting them forever off-limits.
Similar deal, plus there are several issues with it already. Lots of rules wouldn't take effect if set while the game was already running. We'd either have to rewrite a lot of stuff to address that, or just accept that it would be inconsistent and unpredictable.Set/change quest rules by script.
That would require changing the way strings are compiled. And if you did that, TraceS would handle it, anyway.Add PrintToLog(char str) to ZScript.
- This would print the contents of 'str' directly to the log, without needing to declare a ZScript string.
That would increase memory usage by 134,912 bytes per map. And every byte of that is save data, which means load and save times for even small quests would be drastically increased. To take one example, the save data for Isle of Rebirth is currently about 2.24 MB; with this change, it would become 20.18 MB. And that vast majority of that would be totally unused.Increase Screen->D[] regs to 256.
If you come up with a way to do this that allows the memory to be allocated on demand and not saved unless it's used, it might be okay. Simply increasing the number wihtout changing its behavior would be unacceptable.
Again, as long as you can do it on demand rather than saving all bitmaps for every quest.Allow saving user bitmaps directly in the quest file.
This sounds like the same thing as making Link->Equipment writable. That was the case in 2.50 until build 1187 or so, but it was disabled because it was too buggy and basically unfixable. I don't know the details of that, though.Add Link->SetItemA/B internally, instead of the std.zh pressDirand subscreen madness. This will set an item to A/B directly. It should have a param 'bool force' that sets it even if Link doesn't have it.
Supporting 8-bit icons is impossible with 8-bit color. It would require having four palettes loaded at once.Allow 8-bit icons, and improvements to save slot/name entry/display.
They're unsigned short ints, 0-65535. Drain counters are signed, however, and the counter mod functions take signed arguments.Find out why counter values, that are supposed unsigned ints, behave as signed ints; and fix rollover.
I don't even want to think about most of this stuff. Suffice it to say, virtually nothing will be easy, and doing it without breaking existing quests nearly impossible.
It took eight years to finish 2.50 because more and more poorly written features were glommed onto a codebase that was already an unsustainable shambles. This is not a practice I am interested in continuing. Don't expect approval of anything that would make maintenance more of a nightmare than it already is.