ZScript Discussion

Ask about ACS, DECORATE, ZScript, or any other scripting questions here!

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!)
Locked
User avatar
Major Cooke
Posts: 8170
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

ZScript Discussion

Post by Major Cooke »

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?)
Last edited by Major Cooke on Thu Oct 19, 2017 1:45 pm, edited 3 times in total.
User avatar
Fishytza
Posts: 781
Joined: Wed Feb 23, 2011 11:04 am
Preferred Pronouns: No Preference
Contact:

Re: ZScript Discussion

Post by Fishytza »

wiki wrote:Actors are now known as classes which must inherit from Actor.
Hmm. So if I wanted to be really daft and, say, inherit from Thinker or Object, would I get a error?
User avatar
MaxED
Posts: 2246
Joined: Tue Feb 28, 2012 12:55 pm

Re: ZScript Discussion

Post by MaxED »

This?

Code: Select all

const Number1 = 1;
default
{
    Radius = 9;
    +ACTIVATEIMPACT;
}
 
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
}
 
User avatar
Major Cooke
Posts: 8170
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: ZScript Discussion

Post by Major Cooke »

FishyClockwork wrote:
wiki wrote:Actors are now known as classes which must inherit from Actor.
Hmm. So if I wanted to be really daft and, say, inherit from Thinker or Object, would I get a error?
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.

@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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

FishyClockwork wrote:
wiki wrote:Actors are now known as classes which must inherit from Actor.
Hmm. So if I wanted to be really daft and, say, inherit from Thinker or Object, would I get a error?

No. You'd get a class that's not an actor.
User avatar
Fishytza
Posts: 781
Joined: Wed Feb 23, 2011 11:04 am
Preferred Pronouns: No Preference
Contact:

Re: ZScript Discussion

Post by Fishytza »

Interesting. And I presume every class you define must inherit from something, right?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

Of course, but you do not need to specify Object if you so desire.
User avatar
Fishytza
Posts: 781
Joined: Wed Feb 23, 2011 11:04 am
Preferred Pronouns: No Preference
Contact:

Re: ZScript Discussion

Post by Fishytza »

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.
User avatar
Nash
 
 
Posts: 17433
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: ZScript Discussion

Post by Nash »

MaxED wrote:This?

Code: Select all

const Number1 = 1;
default
{
    Radius = 9;
    +ACTIVATEIMPACT;
}
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
}
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))
User avatar
Major Cooke
Posts: 8170
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: ZScript Discussion

Post by Major Cooke »

Constants and properties have always been like that. Also constants would go inside Defaults block.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

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.
User avatar
arookas
Posts: 265
Joined: Mon Jan 24, 2011 6:04 pm
Contact:

Re: ZScript Discussion

Post by arookas »

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.
User avatar
Arctangent
Posts: 1235
Joined: Thu Nov 06, 2014 1:53 pm
Contact:

Re: ZScript Discussion

Post by Arctangent »

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.
It's also just flat-out how idTech 1 works.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

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.
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.
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'.


Arookas wrote: 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.
Last edited by Graf Zahl on Fri Jan 13, 2017 8:07 am, edited 1 time in total.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

Major Cooke wrote:Also constants would go inside Defaults block.
No, they won't. Constants go into the main block. They are not defaults they are class properties, not instance properties.
Locked

Return to “Scripting”