I suppose I need to go over all this at some point...

Increase the script buffer from ~18MB to MAX_LONG in bytes.
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 other operational pointers for datatype objects from 255 to *.
When is 255 not enough? That's a significant design consideration for an extremely rare case.

Add some lexer symbols, such as ? (question-mark) to be used in function names, such as ?InAir()
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 AngelScript style and token, and or token.
Add Until() and Unless() expressions.
Add Repeat(int iterations) loop type.
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 function pointers.
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.

Read UIDs to use as pointer refs. useful for finding a specific part of a segmented enemy.
UID behavior has already changed in a way that would break compatibility.

Allow reading most internal variables, including enemy timers, and whatnot.
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.

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.

Set/change quest rules by script.
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.

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 require changing the way strings are compiled. And if you did that, TraceS would handle it, anyway.

Increase Screen->D[] regs to 256.
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.
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.

Allow saving user bitmaps directly in the quest file.
Again, as long as you can do it on demand rather than saving all bitmaps for every quest.

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.
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.

Allow 8-bit icons, and improvements to save slot/name entry/display.
Supporting 8-bit icons is impossible with 8-bit color. It would require having four palettes loaded at once.

Find out why counter values, that are supposed unsigned ints, behave as signed ints; and fix rollover.
They're unsigned short ints, 0-65535. Drain counters are signed, however, and the counter mod functions take signed arguments.




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.