Support #Define in decorate parser & 'new' Decorate format

[Worst]

I'm suprised this isn't already supported, it could be really helpfull when working with big decorate projects. eg. not having to chance hundreds of values invidually, etc.

As its not already supported.. there cant be any technical limitation for it, is there?

[Graf Zahl]

For the current DECORATE parser, no chance. Due to some syntactic limitations it's not possible to do such a change now.

We'd need a completely new parser and a slightly different format to do it as you wish.

The problem here, which stalls it is called Doomscript. With precisely zero information about Randy's plans it's hard to plan ahead. I could probably do a DECORATE replacement format in a few days, now that I separated the DECORATE parser from the actual implementation so writing a new parser could easiy reuse most of the existing code without change.

However, consider the situation that Randy's Doomscript plans may be incompatible with such a format. We'd end up with 3 different things to maintain. I'll prepare some ideas how I'd like to see a DECORATE successor that can be used as a starting point for Doomscript but this really needs Randy's input. Without it it won't work.

[Graf Zahl]

Here's what I came up with for 'new' DECORATE:

Code: Select all

class ActorName : BaseClass
{
     info
     {
         doomednum(number)
         spawnid(number)
         conversationid(number)
     }
     properties
     {
         health (number)
         Obituary(string)
         +FLAG1
         ...
         and so on
     }
     states
     {
     label:
         SPRT A 1;
         SPRT B 1 A_Look;
         SPRT C 1 A_SpawnItemEx("stuff");
     }
}

The key differences to the old format:

- it no longer assumes 'Actor' as base class. The reason for this is to keep it open for Doomscript extensions that might allow definition of non-actor classes.
- Property parameters are enclosed in parentheses so that there is some kind of delimiter which would allow free use of constant expressions as their parameters.
- Properties are put into a sub-block of the class definition to keep its global block free of unneeded keywords.
- The distinction of 'properties' and 'info' is to differentiate between inheritable properties and non-inheritable spawn information (currently only editor number, spawn ID and conversation ID.)
- States have to be terminated with a semicolon. This is to avoid making assumptions about the formatting. The current version uses line feets as a state definition terminator which is problematic and hard to parse with a formal grammar.
- A few obsolete and problematic features will not be carried over. This will in particular include A_Jump by state offset. The new format will be label only!

The advantage of this format is that it doesn't depend on the way the parser works like current DECORATE. It will no longer be possible to omit commas between property parameters, use quotation marks around numbers and leave them out of string parameters. So once Doomscript finally comes it can be simply implemented as an extension on top of this format - which should save a lot of time.

There's one open issue: Should this get a new lump name or still use DECORATE? Doing an on-the-fly check for old or new format isn't too hard to add so I'd be fine with either. The only thing that won't be possible is mixing old and new style definitions in the same lump.

Comments are welcome, in particular if they tell me that this is worth pursuing considering the future of Doomscript.

[Cutmanmike]

Is this the one you created before? I have no problems with it but I can see some people hating the fact state jumps with jump values will have to be changed, especially for actors which need very minor jumps. As for me I prefer state labels because it's neater and damn easier to keep track of what goes where.

I'd say only bother coding it if Randy is willing to go along with it, and there seems little reason to not if Doomscript can easily be added ontop of this. As for the name you can keep it as DECORATE or call it NOMOREWFDS for all I care, I'd use it!

[Gez]

I have no problems with it but I can see some people hating the fact state jumps with jump values will have to be changed

But will they? Would this replace DECORATE, thus breaking backward compatibility with all ZDoom mods up to now, or wouldn't it simply be a new (and more extensible) way of defining actors, in the same way that the old DECORATE format is still supported?

Because unless it's the former (which seems quite unlikely), there is no reason to change already-made DECORATE actors. They'd still work.

As for lump name, I'd say either ZDSCRIPT (it the fabled DoomScript is ever added atop this new actor definition format -- ZDScript might be a better name for it anyway since DoomScript already exists, it's what's used for Doom3...), ACTORDEF otherwise, or maybe OHNOWFDS.

[Graf Zahl]

It will be a completely separate parser. Almost any of my work on ZDoom in recent months, including the DECORATE conversions of all internal actors was in preparation for this. Before attempting any serious Doomscript attempt I wanted to make sure that as much of the existing code can be used for both existing DECORATE and something new.

The system as it stands consists of 2 separate parts: the parser and a backend that handles the parsed data. The interface between these 2 is designed to handle a different parser as well. It was a lot of work separating this, in particular the expression evaluator but I'm almost done with that.

This means that no old code will have to change - which of course is an important concern but I'm sorry to say that DECORATE's days are numbered. It has far too many problems that make extending it very, very messy and I really don't want to think about it anymore.

[MG_Man]

If you're too worried about DooMScript, then just make it GZScript until things get more final.

[HotWax]

That still presents the possible conundrum later of having one more feature to maintain if randy does decide to go ahead with his own plans for DoomScript.

[Gez]

- The distinction of 'properties' and 'info' is to differentiate between inheritable properties and non-inheritable spawn information (currently only editor number, spawn ID and conversation ID.)

Hmm... Wouldn't "replaces" be an info as well? It can't be a property and unless there is a reason for it to be an "obsolete and problematic" feature, it should be there.

If you're too worried about DooMScript, then just make it GZScript until things get more final.

I think one or two people might have already suggested this once or twice in the past. Maybe.

[Graf Zahl]

- The distinction of 'properties' and 'info' is to differentiate between inheritable properties and non-inheritable spawn information (currently only editor number, spawn ID and conversation ID.)

Hmm... Wouldn't "replaces" be an info as well? It can't be a property and unless there is a reason for it to be an "obsolete and problematic" feature, it should be there.

Of course. That one, too.

[Tormentor667]

No problem as long old DECORATE still stays compatible.

[MG_Man]

I say go ahead with it, and that it's Randy's fault for not answering soon enough with some word/plan on DooMScript, otherwise this wouldn't be needed.

[Macil]

Just curious - does the "replaces" keyword work by making the actor effectively inherit everything from under the "info" block of your new format and make the old actor's info invalid?
And I'd assume with inheritance that actors inherit only the "properties" and "states", not the "info" block? I was thinking that would explain the difference between the properties and info blocks - if this isn't it, is there any functional difference between them other than being restricted to certain keywords in each?

[Slasher]

I have a question. So far it sounds like this new format will do almost all of the things that we can do now, but easier to maintain and add to.

So my question is: What kind of additions are we looking at? What kind of features can this new format do that would make it deserving of the "legendary" status of the theoretical DoomScript? What will this enable us to do?

Either way, I say definitely go for this new format.

EDIT: Another question. Will this allow us to create our own variables? Like a mix of ACS and DECORATE? Anything like that?

[Graf Zahl]

Just curious - does the "replaces" keyword work by making the actor effectively inherit everything from under the "info" block of your new format and make the old actor's info invalid?

No. The 'replaces' keyword doesn't override anything. It works by linking the 2 actors and then deciding at runtime what to do.

And I'd assume with inheritance that actors inherit only the "properties" and "states", not the "info" block? I was thinking that would explain the difference between the properties and info blocks - if this isn't it, is there any functional difference between them other than being restricted to certain keywords in each?

That's the difference and that's why I'd prefer not to mix them. It was creating confusion before for the respective keywords and this makes it much easier to explain to users.