ZScript Discussion
Moderator: GZDoom Developers
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.
Please bear in mind that the people helping you do not automatically know how much you know. You may be asked to upload your project file to look at. Don't be afraid to ask questions about what things mean, but also please be patient with the people trying to help you. (And helpers, please be patient with the person you're trying to help!)
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.
Please bear in mind that the people helping you do not automatically know how much you know. You may be asked to upload your project file to look at. Don't be afraid to ask questions about what things mean, but also please be patient with the people trying to help you. (And helpers, please be patient with the person you're trying to help!)
-
- Posts: 23
- Joined: Sat Apr 30, 2016 10:33 am
Re: ZScript Discussion
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!)
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!)
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
Hell Theatre wrote: 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!
-
-
- Posts: 17934
- Joined: Fri Jul 06, 2007 3:22 pm
Re: ZScript Discussion
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.Nash wrote: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))
For the same reason, I don't think semicolons are needed for the property block.
-
- Posts: 265
- Joined: Mon Jan 24, 2011 6:04 pm
Re: ZScript Discussion
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.Graf Zahl wrote: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.
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.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.
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
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.
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
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.Gez wrote:For the same reason, I don't think semicolons are needed for the property block.
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).
-
-
- Posts: 17934
- Joined: Fri Jul 06, 2007 3:22 pm
Re: ZScript Discussion
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.
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
...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.
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.
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: ZScript Discussion
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...
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
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.
Having the menu accessible is definitely on my plan.
-
- Posts: 13797
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: ZScript Discussion
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:
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.
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.Graf Zahl wrote: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.
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.
-
- Posts: 313
- Joined: Tue Aug 14, 2012 6:10 pm
Re: ZScript Discussion
You can't blame people for expecting this to be extremely good/near perfect especially after all the promises and the loooooonnnnng wait.Graf Zahl wrote: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...
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++?
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
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.
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.
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.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++?
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.
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: ZScript Discussion
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...
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...
-
- Posts: 8196
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: ZScript Discussion
Yes. This right here I have to agree with. I hate mixing and matching decorate to acs myself.Nash wrote: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...
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.Arookas wrote:Maybe I'm just more of a forward-compatibility guy.