ZScript Discussion

[Hell Theatre]

Reading this I again have to question the motivation for such destructive development styles and why some people actually think they are an achievable goal. How good that ZDoom's developers are not supporters of this!

ZDoom is not 'most software'. Most software does not depend on such intricate data as game resources and associated definition files. If a text editor drops compatibility with an old encoding, it'd be at worst a one-time conversion step for the affected file to be readable again.
If a programming IDE like Visual Studio changes how it maintains its projects it is also a one-time conversion step.
Same for C++ compilers. Fix the code once and it works again.
None of these things can easily be done with game data. Change the underlying fundamentals too much and it does not work anymore. So - because we cannot change the underlying fundamentals to allow the suggested 'radical change', both DECORATE and ZSCRIPT will have to produce the same data.
DECORATE is already excellent at this - far better than anything that has been cooked up by other port authors. It's a testament to its design that, despite having been heavily extended, the heart of it is still the same code from the end of 2004. So something in here must have been done very well. Why trash it? Building the new language with all the knowledge about what worked well and what did not makes a lot of sense. And the few things that weren't so great - lack if constant use in properties and states, and the generally shaky state syntax have been addressed in ZSCRIPT - so in my opinion it has done the right thing - take DECORATE and fix the issues. We all know that this would not have been possible inside DECORATE itself, it had to be something different - but being something different does not imply that EVERYTHING has to be done differently, just for the sake of it.

And in case the 'maintaining deprecated code' blurb comes again, just look at the old-style DECORATE parser. Yes, it has occasionally been modified, but that was always minor things, like making adjustments in function calls when some lower level things were changed. Outside of these and a few code cleanup passes this code has basically stayed the same for 10 years. And it still allows loading mods like Daedalus and RTC-3057 which made use of it to define some scenery objects. Note that these mods are 12-13 years old by now!

What should be done with ZSCRIPT is a cleanup of the action function list. Some are badly named, some have bad parameter ordering and some may just be redundant. Now that the lump names and the format change it may be a good time to rename things like A_CustomMissile to A_SpawnProjectile, and deprecate the old name (not remove it!)

[Graf Zahl]

And in case the 'maintaining deprecated code' blurb comes again, just look at the old-style DECORATE parser. Yes, it has occasionally been modified, but that was always minor things, like making adjustments in function calls when some lower level things were changed. Outside of these and a few code cleanup passes this code has basically stayed the same for 10 years. And it still allows loading mods like Daedalus and RTC-3057 which made use of it to define some scenery objects. Note that these mods are 12-13 years old by now!

Indeed.
That old parser is a 20kb source file. It occasionally got changed when something it referenced was changed - it saw some more modification when scripting was added and when the engine was converted to floating point - but all of these were small things that cost a few minutes each to do. It had been suggested to remove it more than once by some people who want to 'move forward', but seriously: Why? It does not constitute an obstacle to anything, it won't get in the way of anything, it just sits there and allows to still play those old mods. Win-win for everyone.

The new-style DECORATE parser - by that I mean just the parser itself - is 3 source files, complete size 75kb. This will be dealt with in the future just like old-style DECORATE. Due to using the same backend as ZSCRIPT it will automatically inherit all new properties and all new action functions - even those which get defined in ZSCRIPT - without putting any work into it. That will only be needed if some of the underlying data structures change.

And it's these 95kb that could be removed if we wanted to drop DECORATE 'for convenience'. Put that into relation with making hundreds of mods inoperable!

[Gez]

He has a point, either require the equals sign or don't... same problem with ZMapInfo currently... (needs equals signs but does not need the semicolon but otherwise everything looks like C (braces, quotes for strings etc))

ZMAPINFO syntax is clean. A property token is identified by the presence of an equal sign after it. A series of parameters is identified by the presence of commas, once you no longer find any comma you have reached the last parameter. Semicolons would be superfluous.

For the same reason, I don't think semicolons are needed for the property block.

[arookas]

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 understand they internally use the same data, VM, etc. My assumption that zscript was being held back by the current DECORATE parser is because of certain issues, such as the self/invoker issue with CustomInventory/Weapon class and DECORATE-inherited syntax inconsistencies. These aren't simple issues to fix the DECORATE parser was a certain way at the time the relevant features were added, so zscript will also have to deal with (in some way) these burdens. I am simply worried more will crop up as zscript develops and run it into a corner that it would've otherwise been free of.

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.

Yes, this sort of release policy can be destructive. I also understand removing an entire parser people have been utlizing for 12 years is extreme. However, my statement was referring to my having wished zdoom started with this philosophy. I see it as an "always do" or "never do". It is certainly not possible to use it now: not for zdoom, and especially not with an addition as big as zscript. Maybe I'm just more of a forward-compatibility guy.

[Graf Zahl]

The entire mess of invoker vs. user with the weapon states is a lot more tricky. Of course it can be swapped around, but I see more of a problem with how that will change the semantics of how to use action functions on weapons. I chose this approach for two reasons:

1. It requires the least amount of work on the engine internals here and
2. It requires the least amount of adjustment for the users.

Any supposedly 'sane' approach would necessitate a buttload of changes in several places, possibly the necessity of declaring different kinds of action functions and who knows what else. With the single rule that got implemented now everything can be solved in a way that allows proper error checking in the compiler, and weapon action functions just behave like they always did. I know it's a bit awkward but I prefer awkward over broken.
Remember: Even Dehacked depends on this implementation. If the semantics of action functions were changed, it'd not only cause problems with DECORATE but also with many Dehacked mods, and if those break the engine would be a lost cause.

[Graf Zahl]

For the same reason, I don't think semicolons are needed for the property block.

Wrong. Without a clean separator the parser may not be able to detect the end of a property's arguments. Same for the states. Don't think I haven't even tried.
This isn't an ad-hoc parser that just takes what it gets as it goes, it has to adhere to a proper grammar, and if you cannot specify default properties without parse conflicts, you have to insert a separator. If it was all just single values, it would work without semicolon, but this is supposed to be capbable of parsing complex expressions as well, like 'health 4*default_health + 1337 - baseclass.default_adjust. And not everything the expression parser may accept will be able to recognize the next property's name. It definitely can't recognize a following flag because it interprets 'health 100 \n +COUNTKILL' as health (100 + COUNTKILL).

[Gez]

If you use equal signs like in ZMAPINFO, a property name token is identified by the presence of an equal sign following it.

As for flags they could belong to a property too, e.g. flags = +COUNTKILL, +NOGRAVITY etc.

Basically what I'm saying is that you if you use equals you don't need to use semicolons.

[Graf Zahl]

...and if you use semicolons you do not need equal signs...

Is it really necessary to bicker about such minute details? I would have liked some discussion of the upcoming capabilities but all people seem to be interested in is that the syntax changes from DECORATE are not to their liking...

Besides, your conclusion is not entirely correct about the property identifier. Since the parser works forward, if the context puts the property token into the last expression, all the equal signs in the world won't help you. It is always better to have a proper terminator token for a robust syntax.

[Nash]

Okay here's a question for upcoming capabilities... will we eventually (doesn't matter if it's many years from now) be allowed to alter or make new menus? Like Client-Side QuakeC? I wish to be rid of the abomination that is ACS-based GetPlayerInput menus for good...

[Graf Zahl]

Since the menu system is entirely based on DObject it should eventually be doable. The only real problem here is that in order to support virtual inheritance, all classes that are supposed to be replaceable or extendable need to be patched for that because there's one thing the scripting language can't do, and that is hooking into how C++ dispatches virtual functions.

Having the menu accessible is definitely on my plan.

[Rachael]

There are a lot of things said by multiple people that I both agree and disagree with, but there's one thing that stands out for me:

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.

This is very fundamental. I always knew it was ultimately a design goal of ZDoom for everything to work with one future version as it did in previous versions, but I never understood why. And this makes perfect sense. I am so glad that this is the goal/policy, because I, too, could not imagine having all different ZDoom versions just for every mod - and until now, had never thought about how much I took that convenience for granted.

What makes the case even stronger is the improvements frequently being done to GZDoom's renderer that those "older mods" would never be able to take advantage of if this were not the case.

So I have to say - as an end-user, I really appreciate this. Thank you.

[Leonard2]

Is it really necessary to bicker about such minute details? I would have liked some discussion of the upcoming capabilities but all people seem to be interested in is that the syntax changes from DECORATE are not to their liking...

You can't blame people for expecting this to be extremely good/near perfect especially after all the promises and the loooooonnnnng wait.
When something was WFDS'd before it was always because of some sort of design limitation so it's natural for people to expect the solution to not be limited in any way and that also applies to the syntax which was complained about too.

About upcoming capabilities, since people hope zscript to replace both DECORATE and ACS stuff, would we be able to write code that run with maps like ACS?
Like having a main function that would be called when entering a level which would be like an OPEN ACS script.
Or just declaring objects that are initialized when entering a map like ACS.
Because so far zscript only allows to define objects like a header file but could it also have code files that would allow this kind of stuff like .cpp and .h files in c++?

[Graf Zahl]

ZScript is not meant to replace ACS. I don't understand why people get this idea. It's entirely about being able to define new objects and attach code to them. And the map is not an object in that sense. Of course what you will be able to do is to define new thinker objects that attach themselves to the map and do some stuff - but it won't be like ACS. ACS itself is actually implemented as a thinker running its scripts, so wherever you go from there is up to any developer's imagination.

Because so far zscript only allows to define objects like a header file but could it also have code files that would allow this kind of stuff like .cpp and .h files in c++?

We have to start somewhere, right? I can't do all the more complex stuff unless I can write code that actually runs - and that's best tested in the existing DECORATE framework, because I can test the code right away without writing complex maintenance stuff first that I cannot test because I can't compile the code.
Before even thinking about virtual functions and stuff like that the code generator needs to get working, and that's what I am currently at, and before that isn't done I won't waste any thought about how to hook it all in later. The goal clearly is to extend classes via scripting, but you have to be aware that in order to extend a class this class needs to be set up to be extended. ZScript won't be the magic wand to solve all problems, and in order to hook into some subsystems they will need quite a bit of refactoring first.

[Nash]

IMO, ACS purely for level scripting is fine. You know, things it was designed for - opening doors, raising or lowering floors or ceilings, change the lighting in a sector. With the way how Hexen used it, the timing stuff is really tight and perfect for those kinds of purposes.

Where it starts getting cringe-y is when you launch scripts from DECORATE states to do non-level stuff like modifying the player, calculating damage, changing an actor's state etc...

[Major Cooke]

IMO, ACS purely for level scripting is fine. You know, things it was designed for - opening doors, raising or lowering floors or ceilings, change the lighting in a sector. With the way how Hexen used it, the timing stuff is really tight and perfect for those kinds of purposes.

Where it starts getting cringe-y is when you launch scripts from DECORATE states to do non-level stuff like modifying the player, calculating damage, changing an actor's state etc...

Yes. This right here I have to agree with. I hate mixing and matching decorate to acs myself.

Maybe I'm just more of a forward-compatibility guy.

And this is why I gave up on consoles, since I cannot play Mechassault on Xbox 360 -- it has to be the very first one. Practices like that, while understandably necessary at some points for more modern things, are just plain awful for the case of ZDoom.