ZScript Discussion

[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?)

[FishyClockwork]

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?

[MaxED]

This?

Code: Select all • Expand view

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

That?

Code: Select all • Expand view

const Number1 1
default
{
    Radius 9
    +ACTIVATEIMPACT
}
 

Can't decide! Let's throw all of them into the mix!

Code: Select all • Expand view

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

[Major Cooke]

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.

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.

[Graf Zahl]

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.

[FishyClockwork]

Interesting. And I presume every class you define must inherit from something, right?

[Graf Zahl]

Of course, but you do not need to specify Object if you so desire.

[FishyClockwork]

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.

[Nash]

This?

Code: Select all • Expand view


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


That?

Code: Select all • Expand view


const Number1 1
default
{
    Radius 9
    +ACTIVATEIMPACT
}


Can't decide! Let's throw all of them into the mix!

Code: Select all • Expand 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))

[Major Cooke]

Constants and properties have always been like that. Also constants would go inside Defaults block.

[Graf Zahl]

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.

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

[Arctangent]

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.

[Graf Zahl]

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.

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

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.

[Graf Zahl]

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.