Arookas wrote:In my opinion, the biggest hurdle zscript will have to overcome is DECORATE, not the syntax. Although I'm also not so certain so-tightly embedding actor logic with actor animation is a stable design, it is too late to change that at this point. It's not just how DECORATE works, it is how zdoom works.
As has been said, this is how Doom always worked. And it's one of the things that will forever remain with us, including all the design mistakes - the worst of which was that entering a state did not queue its action function for execution but did so right away, which is the single biggest unfixable issue here
Thus, I believe zscript should replace DECORATE, not coexist with it. That's not practical because the zdoom development team works so hard for backwards compatibility (not just for older systems, but older mods), and that is admirable...but, I feel zscript will become burdened by DECORATE overtime.
No, it won't. All DECORATE is is a prettified way to access data that by its very design is pretty much invariant and won't change. It contains everything an actor definition needs - with the exception of actual coding beyond the barest minimum. ZSCRIPT cannot reinvent the wheel, it has to play by the same rules that were laid out 23 years ago, which means that everything DECORATE does is just as relevant for the new language.
I wish separate major versions (e.g. when 2.8.0 was released) was the dropoff point for mod backwards compatibility. Certain features become deprecated in minor releases, and become unsupported or removed in the next major release. Countless other engines are often not entirely backwards compatible when a new major release is out. This is a very important way to allow the engine to grow, while still giving the users some legroom of support.
What is it with people like you that you seem to have no grasp on what such a decision would mean? Cutting ourselves off from all the mods made in the past? Alienating all the developers who have poured so much energy into this? Sorry, but that's just ludicrous. Software that is being developed like this will never see the support ZDoom gets. People mapping for ZDoom know that the developers care enough to let that mod still work 10 years down the line, with the latest engine that is build against the hardware of its time.
If backwards compatibility was severed, I can outright tell you what will happen: Someone will pick up the pieces and maintain a 'classic ZDoom' port which will render the official one a waste of time, because if given the choice between an engine that cares about mods' longetivity will inevitably be preferred over one that frequently screws things up and forces modders to redo their work. And once they leave they never come back. Sorry, but such a design philosophy may be affordable by software where changing things around is some minor annoyance, but not where it'd break all the hard work that has been done before.
And what for? That we can drop the old parser that hooks into the exact same backend as the new one to do its stuff? Come on! When I wrote that stuff 12 years ago, I already planned much of its design so that a new parser can easily be plugged in. The entire actor property dispatcher is being completely reused because however you implement it, the new language needs to be able to set up the same information, so why not use the exact same code for the handling? The same is true for the state buider. Again it uses the exact same backend as DECORATE because it was written from the start with the assumption that another parser may have to hook into it later (BTW, here there's actually 4 parsers hooking into it: DECORATE, old style DECORATE, ZSCRIPT and Dehacked.)
Same for the VM's code generator. When I wrote the DECORATE expression evaluator in 2004 that was already done with backing it with an actual bytecode VM in mind, and behold: That part worked perfectly. It was also written so that a new parser could be hooked into it as well - and again, so far it turned out very nicely. Granted, this will require some cleanup and major extensions for currently unsupported language features, but all the old code is still very useful. Stuff like basic math operations require the same bytecode, no matter where the source comes from.
Why do you think was I able to get so much running this quickly? That kind of rapid progress would have been impossible, had it all been redone.
So all that this leaves us with is dumping the old parser. And to be blunt: That doesn't bring any benefit, it won't make anything even a tiny bit easier - it's just a parser but no data manipulator - and certainly not worth trashing 12 years of ZDoom modding in one very ill-advised decision 'to go forward'.
Ultimately, it's up to the developers. I'm very interested in seeing how zscript develops.
Indeed. And I hope I have made my point clear. I am a heavy Doom player myself, so compatibility is a very important thing for me. I do not want to saddle my play directory with a gazillion different ZDoom versions to play everything, always having to remember which version to use for which mod. No player wants to do that so it's not even at the bottom list of my agenda, but in the (virtual) garbage bin where it belongs.