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: 8196
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
ZScript Discussion
Current Information
Continuing discussion from this thread.
Discussion about DOCUMENTATION should go in there.
I think it'd be a good idea to have these threads for keeping up to date on what changes occur to ZScript and what we can expect the code syntax and functionality is like, as well as the difference between ZScript, DECORATE, and how to convert from the latter to the former. Also a good place for asking questions.
(If beneficial enough, perhaps a pinning would be nice so others don't have to look far for questions and answers on zscript?)
Continuing discussion from this thread.
Discussion about DOCUMENTATION should go in there.
I think it'd be a good idea to have these threads for keeping up to date on what changes occur to ZScript and what we can expect the code syntax and functionality is like, as well as the difference between ZScript, DECORATE, and how to convert from the latter to the former. Also a good place for asking questions.
(If beneficial enough, perhaps a pinning would be nice so others don't have to look far for questions and answers on zscript?)
Last edited by Major Cooke on Thu Oct 19, 2017 1:45 pm, edited 3 times in total.
-
- Posts: 787
- Joined: Wed Feb 23, 2011 11:04 am
- Preferred Pronouns: No Preference
Re: ZScript Discussion
Hmm. So if I wanted to be really daft and, say, inherit from Thinker or Object, would I get a error?wiki wrote:Actors are now known as classes which must inherit from Actor.
-
- Posts: 2246
- Joined: Tue Feb 28, 2012 12:55 pm
Re: ZScript Discussion
This?
That?
Can't decide! Let's throw all of them into the mix!
Code: Select all
const Number1 = 1;
default
{
Radius = 9;
+ACTIVATEIMPACT;
}
Code: Select all
const Number1 1
default
{
Radius 9
+ACTIVATEIMPACT
}
Code: Select all
const Number1 = 1;
default
{
Radius 9;
+ACTIVATEIMPACT
}
-
- Posts: 8196
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: ZScript Discussion
Actor can also be changed, akin to the CustomInventory as seen on the wiki page, with the porkalator. Updated the wiki to reflect that. I think this is just for defining an actual actor though. I believe classes may also be used for defining functions/thinker/objects potentially... Don't quote me on that, I need Graf's confirmation, though he said he hasn't thought of a lot of it just yet.FishyClockwork wrote:Hmm. So if I wanted to be really daft and, say, inherit from Thinker or Object, would I get a error?wiki wrote:Actors are now known as classes which must inherit from Actor.
@MaxED: Graf can change it so you can have ; after flags.
Also I think the consts go inside of Default.
Graf Zahl wrote:That's to avoid polluting the main class body with the properties. They use quite different syntax than the rest and would cause parsing problems otherwise.
-
- Lead GZDoom+Raze Developer
- Posts: 49179
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
FishyClockwork wrote:Hmm. So if I wanted to be really daft and, say, inherit from Thinker or Object, would I get a error?wiki wrote:Actors are now known as classes which must inherit from Actor.
No. You'd get a class that's not an actor.
-
- Posts: 787
- Joined: Wed Feb 23, 2011 11:04 am
- Preferred Pronouns: No Preference
Re: ZScript Discussion
Interesting. And I presume every class you define must inherit from something, right?
-
- Lead GZDoom+Raze Developer
- Posts: 49179
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
Of course, but you do not need to specify Object if you so desire.
-
- Posts: 787
- Joined: Wed Feb 23, 2011 11:04 am
- Preferred Pronouns: No Preference
Re: ZScript Discussion
Well, of course I'm probably gonna specify to inherit from Actor. Just wanted to know if it was possible to define things which aren't exactly subclasses of AActor.
Pretty exciting stuff here.
So glad I'm going to get more options to create random, insane bullshit out of sheer boredom and probably never publish it because I'm too embarrassed. Oh boy!
But seriously, I'm getting tired of DECORATE and ACS hacks. So this is really good stuff.
Pretty exciting stuff here.
So glad I'm going to get more options to create random, insane bullshit out of sheer boredom and probably never publish it because I'm too embarrassed. Oh boy!
But seriously, I'm getting tired of DECORATE and ACS hacks. So this is really good stuff.
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: ZScript Discussion
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))MaxED wrote:This?That?Code: Select all
const Number1 = 1; default { Radius = 9; +ACTIVATEIMPACT; }
Can't decide! Let's throw all of them into the mix!Code: Select all
const Number1 1 default { Radius 9 +ACTIVATEIMPACT }
Code: Select all
const Number1 = 1; default { Radius 9; +ACTIVATEIMPACT }
-
- Posts: 8196
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: ZScript Discussion
Constants and properties have always been like that. Also constants would go inside Defaults block.
-
- Lead GZDoom+Raze Developer
- Posts: 49179
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
Nash wrote:MaxED 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))
And how would you explain the States syntax then? It's completely different. I made it the way it is so that it's easier to convert DECORATE. The less unnecessary syntax changes, the easier. These special cases are only inside the Default and State blocks because their content is inherited from an older format.
Last edited by Graf Zahl on Tue Oct 18, 2016 4:05 am, edited 1 time in total.
-
- Posts: 265
- Joined: Mon Jan 24, 2011 6:04 pm
Re: ZScript Discussion
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.
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. 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.
Ultimately, it's up to the developers. I'm very interested in seeing how zscript develops.
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. 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.
Ultimately, it's up to the developers. I'm very interested in seeing how zscript develops.
-
- Posts: 1235
- Joined: Thu Nov 06, 2014 1:53 pm
Re: ZScript Discussion
It's also just flat-out how idTech 1 works.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.
-
- Lead GZDoom+Raze Developer
- Posts: 49179
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
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 hereArookas 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.
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.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.
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.Arookas wrote: 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.
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'.
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.Arookas wrote: Ultimately, it's up to the developers. I'm very interested in seeing how zscript develops.
Last edited by Graf Zahl on Fri Jan 13, 2017 8:07 am, edited 1 time in total.
-
- Lead GZDoom+Raze Developer
- Posts: 49179
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
No, they won't. Constants go into the main block. They are not defaults they are class properties, not instance properties.Major Cooke wrote:Also constants would go inside Defaults block.