Quote Originally Posted by DarkDragon View Post
I've explained this several times before and won't rehash the argument here in full.

Giving the script engine raw access to implementation details about how ZC is implemented deep under the hood calcifies poor decisions, bugs, and unmaintainanle spaghetti code that infests the core of the ZC logic.

The hardest, and most underrated, part of being a good developer of a long term project is knowing when to listen to what users are asking for, and when to realize that they are succumbing to short-term and ill-informed thinking, saying "no," and standing your ground. Giving people access to engine internals satisfies the users screaming "gimme gimme gimme now now now," at the price of signing ZC's death warrant.

I refuse to make that bargain.

What you say about how to implement actions is absolutely the right way to go. Instead of mucking directly with the Link class internals, scripts should have access to a restricted set of high-level actions, which are then passed on to the game engine, which tries to act on the script command as best as possible. So if a script tries to tell Link to charge, while he's already riding a raft, the game engine does something reasonable (like ignoring the charge command) rather than entering an unpredictable, inconsistent and corrupt state, which is what currently happens when scripts blindly trample willy nilly over internal variables.
Right, but what I am also saying, is that the engine shouldn't be directly mucking with them either. I would rather that the engine point to the script engine, and let the script engine have priority when deciding how to handle them. This way, the script engine and the game engine do not diverge. Where the values are stored becomes immaterial, as you can always relocate them.

This is also why I'm not rushing to make pull requests, or to try to force anything into main. There exists at present no implementation that works this way, short of the ffrules thing that I've been working on. I tend to see this entire thing as a slow migration though. If you want to move things into a form of abstraction, you need to do it a bit at a time, unless you have sixty hours a week to spend rewriting the engine.

I do not see anything that prevents reimplementing these things in this manner, and still being safe. Keeping the variables in the classes preserved compatibility, as well. Where would you store the values? Do you want duplicate values in the script engine, that are setting the class values? What is the ultimate advantage over doing it at a function level? I've done some of that, and frankly, I would prefer the variables in the script engine, but I don't have the time to completely rewrite ZC, which is what this amounts to needing as far as I can see.

The other concern, is always, how much compatibility are you willing to lose when doing this? The answer thus far, for most of us, has been none. That means that everything need be reimplemented, and as long as you are going to do that, you may as well finish the stuff that was left out, in the process.

One thing I can say, is that if you slave the script engine to the game engine, you preclude being able to do things later down the road, that you might want to do. Making the game engine call tot he script engine, gives you far more options. It also maintains uniformity between the two. The notion that a scripted behaviour does A, but the internal behaviour does B, is a huge fault in the engine, as it stands.