ZScript Discussion

Ask about ACS, DECORATE, ZScript, or any other scripting questions here!
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.

ZScript Discussion

Postby Major Cooke » Mon Oct 17, 2016 1:17 pm

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 2:45 pm, edited 3 times in total.
User avatar
Major Cooke
Slaughterer of Sewers
 
Joined: 28 Jan 2007
Discord: Major Cooke#0846

Re: ZScript Discussion

Postby FishyClockwork » Mon Oct 17, 2016 1:26 pm

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
FishyClockwork
-... .-.. ..- -...
 
Joined: 23 Feb 2011

Re: ZScript Discussion

Postby MaxED » Mon Oct 17, 2016 1:51 pm

This?
Code: Select allExpand view
const Number1 1;
default
{
    
Radius 9;
    +
ACTIVATEIMPACT;
}
 


That?
Code: Select allExpand view
const Number1 1
default
{
    
Radius 9
    
+ACTIVATEIMPACT
}
 


Can't decide! Let's throw all of them into the mix!
Code: Select allExpand view
const Number1 1;
default
{
    
Radius 9;
    +
ACTIVATEIMPACT
}
 
User avatar
MaxED
 
Joined: 28 Feb 2012

Re: ZScript Discussion

Postby Major Cooke » Mon Oct 17, 2016 2:03 pm

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
Major Cooke
Slaughterer of Sewers
 
Joined: 28 Jan 2007
Discord: Major Cooke#0846

Re: ZScript Discussion

Postby Graf Zahl » Mon Oct 17, 2016 2:44 pm

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
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZScript Discussion

Postby FishyClockwork » Mon Oct 17, 2016 2:49 pm

Interesting. And I presume every class you define must inherit from something, right?
User avatar
FishyClockwork
-... .-.. ..- -...
 
Joined: 23 Feb 2011

Re: ZScript Discussion

Postby Graf Zahl » Mon Oct 17, 2016 2:52 pm

Of course, but you do not need to specify Object if you so desire.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZScript Discussion

Postby FishyClockwork » Mon Oct 17, 2016 3:02 pm

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
FishyClockwork
-... .-.. ..- -...
 
Joined: 23 Feb 2011

Re: ZScript Discussion

Postby Nash » Tue Oct 18, 2016 12:29 am

MaxED wrote:This?
Code: Select allExpand view

const Number1 
= 1;
default
{
    Radius = 9;
    +ACTIVATEIMPACT;
}


That?
Code: Select allExpand view

const Number1 1
default
{
    Radius 9
    
+ACTIVATEIMPACT
}


Can't decide! Let's throw all of them into the mix!
Code: Select allExpand view

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
Nash
Nash Muhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia

Re: ZScript Discussion

Postby Major Cooke » Tue Oct 18, 2016 1:06 am

Constants and properties have always been like that. Also constants would go inside Defaults block.
User avatar
Major Cooke
Slaughterer of Sewers
 
Joined: 28 Jan 2007
Discord: Major Cooke#0846

Re: ZScript Discussion

Postby Graf Zahl » Tue Oct 18, 2016 1:31 am

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 5:05 am, edited 1 time in total.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZScript Discussion

Postby arookas » Tue Oct 18, 2016 1:58 am

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
arookas
...but only sometimes.
 
Joined: 24 Jan 2011

Re: ZScript Discussion

Postby Arctangent » Tue Oct 18, 2016 2:23 am

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
Arctangent
squawky
 
Joined: 06 Nov 2014
Discord: SquawkyAtan#2371

Re: ZScript Discussion

Postby Graf Zahl » Tue Oct 18, 2016 4:57 am

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 9:07 am, edited 1 time in total.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZScript Discussion

Postby Graf Zahl » Tue Oct 18, 2016 5:06 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Next

Return to Scripting

Who is online

Users browsing this forum: No registered users and 1 guest