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

[Graf Zahl]

Update:

I commited everything I did concerning the separation of the parser from the underlying implementation so I could start with a new parser any time now. The question is: Makes it sense? What's the status of Doomscript? Would writing a grammar for a proper DECORATE parser in any way interfere with this?

[Ghastly]

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

What, for example, could we do with non-actor classes?

[Graf Zahl]

Nothing yet. But when Doomscript becomes reality, you could, for example, design your own floor/ceiling movement or lighting effect code.

[Graf Zahl]

I think I should post an update. Yesterday evening I finally managed to get my new parser to compile this:

Code: Select all

//===========================================================================
//
// Imp
//
//===========================================================================

ACTOR DoomImpTest
{
	info
	{
		doomednum (1337)
		Game ("Doom")
		SpawnID (5)
	}
	
	
	defaultproperties
	{
		Health (60)
		Radius (20)
		Height (56)
		Mass (100)
		Speed (8)
		PainChance (200)
		Monster()
		+FLOORCLIP
		SeeSound ("imp/sight")
		PainSound ("imp/pain")
		DeathSound ("imp/death")
		ActiveSound ("imp/active")
		HitObituary ("$OB_IMPHIT")
		Obituary ("$OB_IMP")
	}
	
	States
	{
	Spawn:
		TROO AB 10 A_Look;
		Loop
	See:
		TROO AABBCCDD 3 A_Chase;
		Loop
	Melee:
	Missile:
		TROO EF 8 A_FaceTarget;
		TROO G 6 A_TroopAttack;
		Goto See
	Pain:
		TROO H 2;
		TROO H 2 A_Pain;
		Goto See
	Death:
		TROO I 8;
		TROO J 8 A_Scream;
		TROO K 6;
		TROO L 6 A_NoBlocking;
		TROO M -1;
		Stop
	XDeath:
		TROO N 5;
		TROO O 5 A_XScream;
		TROO P 5;
		TROO Q 5 A_NoBlocking;
		TROO RST 5;
		TROO U -1;
		Stop
	Raise:
		TROO MLKJI 8;
		Goto See
	}
}

... which is just a straight syntax conversion of the existing DoomImp definition.

So where's the advantages of this format?

By introducing the parentheses for property parameters and the semicolons for state definitions the syntax becomes much easier to handle. Most importantly this means that any parameter to an actor property can be a constant expression so you can define values outside the class and then use them in multiple actors.

The separation between 'info' and 'defaultproperties' is not really necessary but I thought it's a good idea to separate non-inheritable spawn/maintenance information from inheritable properties. Anything in the 'info' block is local to the defined class and anything defined in 'defaultproperties' can be inherited by child classes.

Separating the properties into sub-blocks has the advantage that the amount of different items in the actor's main block is limited so that adding script code and variables later will cause less problems.

That's about it. I wanted this to be as straight a transition from DECORATE as possible so I only changed the things that needed change to keep the syntax clean. All properties still use the same names (in fact they use the same definition table so that anything added in the future will be available in both formats) and the syntax for state definitions is still the same as before, except for the terminating semicolon.

Here's a list of differences:

- Actor names, sprite names and frame strings may contain non-alphanumeric characters. However, any name that cannot be parsed as an identifier must be enclosed in quotation marks. Otherwise you get an error.
- The damage expression's syntax had to be changed slightly. Just use 'damage [expression]' for it. This was necessary because now parentheses are needed for all properties.


So the question now is, how to continue? Include this in ZDoom and deprecate DECORATE? Unlike DECORATE this new format is usable as a base for Doomscript while preserving all of DECORATE's features with two exceptions:

- The old deprecated state assignment commands are not supported. They are of no use and I would have deleted them from DECORATE, too, if there weren't WADs that used them.
- Old style DECORATE definitions are not supported either, of course. They are a relic of DECORATE's past and should stay there. The DECORATE parser will continue to support them.

[skadoomer]

So would new code pointers be defined in default properties or info, or in somewhere new all together? Does the seperation (or would it) of information allow you to control what is inherited from new monsters as opposed to old?

- The old deprecated state assignment commands are not supported. They are of no use and I would have deleted them from DECORATE, too, if there weren't WADs that used them.

What does this refer to?

Lastly, I think you and Randy need to figure out the future of decorate and doomscript. You have a working example and as far as we know, he does not. What is for sure is until doomscript happens, zdooms development will continue in its current plateau.

[Graf Zahl]

So would new code pointers be defined in default properties or info, or in somewhere new all together? Does the seperation (or would it) of information allow you to control what is inherited from new monsters as opposed to old?

In between. Variables, functions and other declarations are top level stuff. That's why I separated the properties into a sub-block.

- The old deprecated state assignment commands are not supported. They are of no use and I would have deleted them from DECORATE, too, if there weren't WADs that used them.

What does this refer to?

The first versions of DECORATE used the follwing syntax for state assignments:

Code: Select all

  melee 0
  spawn parent death+5

It was really this limited. There's really no point thinking about it any further. It has been deprecated for 2.5 years. There's really no point at all in porting this over. The new method is much better.

Lastly, I think you and Randy need to figure out the future of decorate and doomscript. You have a working example and as far as we know, he does not. What is for sure is until doomscript happens, zdooms development will continue in its current plateau.

It's still no Doomscript (yet.) For now it's just an equivalent of DECORATE with a more robust syntax so that it can be extended. First this has to be made stable.

Actually, many of the changes I made over the last 6 months in preparation of this new parser are already in ZDoom:
- exporting all actors out of the executable was an inevitable first step. Without that I would have had to deal with a lot of baggage.
- rewriting the DECORATE property parser to use a parameterized approach. The old setup would have necessitated complete duplication. Now almost all code is used by both parsers and the actual parsing done in one function only.
- Same for much of the state definition code. Again most of it is being shared between both parsers
- Last but not least, a complete rewrite of the expression evaluator with the same motivation in mind. It is also shared between both parsers and once it is transitioned to create interpreted bytecode this will automatically work for both parsers.

But regarding the future, all I can do right now is wait for a response. It's obvious that the main parser is a completely different animal than these other changes. That's why I did all the work on an SVN branch in GZDoom so that it didn't interfere with anything else.

[Gez]

Since this isn't DoomScript but DECORATE 3.0, and since the behavior of ZDoom with regards to existing DECORATE code wouldn't be affected (maybe even make this a new lump, like "ACTORDEF" for example, to better separate both?), I think you could go ahead. Waiting for Randy's input is like waiting for Godot. This wouldn't be a fundamental change to ZDoom, it would just allow it to continue to grow organically now that a more robust syntax is available.

Speaking of which, why "defaultproperties" instead of just "properties" or even "props"? I'm curious just because on the other hand, "information" is shortened to "info".

Comparing this with your prototype on the first page, I notice you've dropped the possibility to declare non-Actor classes. I suppose if support for other kind of classes get added later down the line, it'll be with a different keyword?

[Graf Zahl]

Since this isn't DoomScript but DECORATE 3.0, and since the behavior of ZDoom with regards to existing DECORATE code wouldn't be affected (maybe even make this a new lump, like "ACTORDEF" for example, to better separate both?), I think you could go ahead. Waiting for Randy's input is like waiting for Godot. This wouldn't be a fundamental change to ZDoom, it would just allow it to continue to grow organically now that a more robust syntax is available.

We'll see. It's not finished yet. I still can't import action functions and the code needs some considerable cleaning up. But the biggest issue is that the interface to the expression evaluator is not well designed. I implemented that part with the expectation that it's only a temporary measure until a real interpreter is working.

Speaking of which, why "defaultproperties" instead of just "properties" or even "props"? I'm curious just because on the other hand, "information" is shortened to "info".

Because I haven't decided yet. Defaultproperties is a keyword in the parser from Unrealscript. Maybe I'll shorten it. I find it a bit clumsy, too.

Comparing this with your prototype on the first page, I notice you've dropped the possibility to declare non-Actor classes. I suppose if support for other kind of classes get added later down the line, it'll be with a different keyword?

I have not. The 'class' keyword still exists for that. But since actors need special initialization I thought that a different keyword made more sense.

[Ghastly]

Because I haven't decided yet. Defaultproperties is a keyword in the parser from Unrealscript. Maybe I'll shorten it. I find it a bit clumsy, too.

Ah, I assumed it was because properties could be changed now.

[bagheadspidey]

By introducing the parentheses for property parameters and the semicolons for state definitions the syntax becomes much easier to handle. Most importantly this means that any parameter to an actor property can be a constant expression so you can define values outside the class and then use them in multiple actors.

Does this also mean that expressions can be used for offsets? If so (and if a sin cos functions were included) I think people could finally have their custom weapon bobbing.

[Graf Zahl]

Offsets can be constant expressions. You are more flexible with the syntax but not with the capabilities.

[Michi]

Isn't it interesting?

Randy was visiting this forum yesterday and even implemented 2 feature suggestions. But no comment about this here.
I think this is telling a clear story about any chances of Doomscript happening - ever!

[Graf Zahl]

I prefer to wait for an official response.

[Nash]

Looks good, Graf! It's definitely not Doomscript but it's the closest we'll ever get...

[Gez]

*chirp, chirp, chirp*