As far as I got with it, it was very easy and worked fine. There was a little issue with the wall masters - for some reason, they made Link scroll to the next screen instead of warping, but it only took a minor adjustment to fix that. Aside from that, everything continued to work perfectly, ZScript and all.
The only real problem I ever had was that it didn't work at all for Gleeok. That seemed to have something to do with how return values were handled, but we never ruled out things like compiler issues, as far as I recall. Really, the reason it was rolled back has more to do with my personal problems than anything else.
There is some question of how much overlap you want between old and new stuff. Should new things continue to be based on the same sprite class, with its fix coordinates and miscellaneous garbage? It would be feasible, and I think not even difficult, for compatibility scripts and new ones to use totally separate base classes and script engines. That's a big plus, in my view - a lot of the legacy cruft can just be moved neatly out of the way.
As for ZScript, it has a variety of issues. The number system doesn't match data types used internally, and the conversion is inefficient and produces unexpected results (2.0/3.0==0). It's difficult to add new built-in functions, and overloading them is currently impossible, as far as I can tell. But the single biggest issue is the extent to which it depends on ZC's internal behavior. In many areas, ZScript was not designed with the notion that things might change.
Consider this simple bit of code:
This iterates over every combo on the screen and does something whenever it finds water, right? Wrong. It iterates over combos 0-175 and does something whever it finds a combo of type 3.Code:for(int i=0; i<176; i++) { if(Screen->ComboT[i]==CT_WATER) {
Say scrolling is implemented. Now instead of screens of 176 combos, you've got rooms with varying numbers of combos. This code doesn't necessarily cover the whole screen anymore. It will still work, but not correctly.
But that's the easy problem. Suppose the combo system changes. Instead of a limited number of well-defined combos, you can now give each combo an arbitrary set of properties. Maybe you make combo #3 a magic-reflecting, poundable hookshot trigger. The script isn't checking for anything like that; it just assumes combo #3 is water. Again, it will still work, but not correctly.
ComboF has similar issues and more. What if it becomes possible to place multiple flags on the same combo? ComboF can't handle that at all.
What about DrawZOffset? Currently, it doubles as HitZOffset. That should obviously change, but existing scripts that uses it were made with that quirk in mind. They won't work correctly without being updated.
New warp system? Warp functions break.
Quirks, bugs, and old behavior can often be imitated, but there are limits. In particular, when a feature is used in multiple different ways, they can't all work. For instance, going back to scrolling again, what happens to drawing functions? Currently, coordinates on the screen and coordinates in the world are the same. If the screen can scroll, that's no longer true. It will have to be one or the other in existing scripts, and some will break.
To some degree, these problems are inevitable, and I'm certainly not under the impression that switching to AngelScript automatically fixes everything forever. The point is that the notion that updating ZScript instead will keep existing scripts working is wrong. Many scripts will break, and it's going to be every bit as difficult and confusing for average users, if not more so. Yes, it will be easy to update these scripts most of the time, but it won't be significantly easier than converting them to AngelScript.
There's nothing AngelScript does that can't theoretically be added to ZScript. But it's a lot more work, and the benefit to users is dubious.
Reply With Quote