DECORATE support added

[smite-meister]

To make testing MD3 models easier, I decided to add really limited DECORATE support to Legacy.
It turned out to be much more fun than I imagined, so I ended up adding quite a respectable subset of the new DECORATE syntax (http://www.zdoom.org/wiki/index.php?title=DECORATE_format_specification). :D
Even though many of the more ZDoom specific things are not implemented, when it comes to mapthings, one can now outdo DeHackEd using DECORATE.

An example: Replace zombiemen with a weak version of DoomImps which shoot Arachnotron plasma, fall slowly and are represented using an MD3 model:
actor test : DoomImp 3004
{
states
{
See:
TROO AABBCCDD 3 A_Chase
loop
Missile:
TROO EF 8 A_FaceTarget
TROO G 6 A_BspiAttack
goto See
}
health 1
model "models/players/imp/"
+LOWGRAVITY
}
The "model" property is a Legacy-specific addition.

[MR_ROCKET]

Freaking sweet smite-meister ;)

[Aliotroph?]

Neat. Can you script the states based on what's happening in the game? Would be fun to push a switch and morph a lost soul into a Caco... :D

[DooMAD]

Since DECORATE is a lump, once the values are declared, I don't think they can be changed during gameplay. I could be wrong, it's all new to me. It's might be possible via ACS though.

[smite-meister]

Neat. Can you script the states based on what's happening in the game? Would be fun to push a switch and morph a lost soul into a Caco... :D
No, at least not yet. DECORATE is for defining initial properties for Actors and for creating new AI states for them (an unlimited frametable in DeHackEd language!).
Maybe if we allowed the DECORATE actor classes to retain custom state labels...
This is what I mean:

In DECORATE something like this:

actor LostSoul
{
states
{
Morph:
goto Cacodemon::See // this is not currently possible
}
}

then, when the switch is thrown, run the following FS:

script 123
{
some_lostsoulmobj.SetState("Morph"); // nor is this
}

I believe the ZDoom people are thinking about something like this as well, so perhaps it's better to wait and see.

[Aliotroph?]

Hmm, this stuff is pretty cool anyway. Makes life so much simpler (unless you can't script to save your life).

[Graf_Zahl]

I believe the ZDoom people are thinking about something like this as well, so perhaps it's better to wait and see.

Custom state labels are already implemented and working. If you want to see it in action you can grab the latest GZDoom.

Regarding some of the things posted here:

- In ZDoom you can not cross-jump into states of an unrelated actor as in your LostSoul/Cacodemon example.
- State switch functions for ACS are planned but not yet implemented. But again, cross-jumps into unrelated actors will not be allowed.
- I looked at your source and noticed that you only load the last DECORATE lump. You really should do it like ZDoom and load all DECORATE lumps that are found. This would make combining resources spread over different WADs much easier.

[Aliotroph?]

Though if you could custom label states and make new actors I suppose you wouldn't care if you could jump states between actors.

[rustyslacker]

Holy crap, DECORATE support?

Awesome. *bang*

[Osiris's_Legacy]

Hoorays for DECORATE support!!

[MR_ROCKET]

It's basically a helper if someone wants to make a mod or tc or something. But in this case, showing model support. and yeah I'm gonna need some docs heh.
Smite's example will help a ton when we'r able to test it out anyway. :D

[Danimetal]

Does this Decorate support include the weapons frames? Just being curious: I understand that actors means only things that are "in the map".

[smite-meister]

Custom state labels are already implemented and working. If you want to see it in action you can grab the latest GZDoom.

Do you store the actual label strings into the runtime DECORATE class instances, or do you simply use them during the state construction phase during startup and then throw them away?

- In ZDoom you can not cross-jump into states of an unrelated actor as in your LostSoul/Cacodemon example.
- State switch functions for ACS are planned but not yet implemented. But again, cross-jumps into unrelated actors will not be allowed.

Since additional states are so cheap memory-wise, you're probably right.
You can create the states for the DECORATE classes using a single-pass algorithm if you disallow jumps to other Actors' labels during state construction.
The reason for the second restriction (no scripted jumps to other Actors' labels at runtime) is not entirely clear to me. Sure, it's easier if each state has a single user/owner class, but I don't think there is a reason to delete states while a map is running, so where's the harm in that?


- I looked at your source and noticed that you only load the last DECORATE lump. You really should do it like ZDoom and load all DECORATE lumps that are found. This would make combining resources spread over different WADs much easier.
You mean we should allow more than one DECORATE lump per file?

[Graf_Zahl]

Do you store the actual label strings into the runtime DECORATE class instances, or do you simply use them during the state construction phase during startup and then throw them away?


The labels have to be kept so that they can be used inside the game. This is necessary because only the most frequently used state addresses are cached in variables. Everything else is always looked up in the table.
For example, this is used to have damage type specific death and pain states which have to be looked up dynamically and for A_Jump... calls that use labels as their target. The lookup uses a simple binary search so the additional time required isn't really relevant.



The reason for the second restriction (no scripted jumps to other Actors' labels at runtime) is not entirely clear to me. Sure, it's easier if each state has a single user/owner class, but I don't think there is a reason to delete states while a map is running, so where's the harm in that?


ZDoom uses a strict class hierarchy and the same rules as for C++ classes are applied here: You can use what you inherit but that's it.


You mean we should allow more than one DECORATE lump per file?

ZDoom allows it and loads each DECORATE lump it can find in all WADs being loaded.

[smite-meister]

The labels have to be kept so that they can be used inside the game. This is necessary because only the most frequently used state addresses are cached in variables. Everything else is always looked up in the table.
I took your advice and implemented persistent custom state labels in Legacy as well. Now, I'll just have to fix the savegame code to match the new system...

[g6672D]

Doom Legacy sure is redefining the term "comeback". Watch out Doomsday! ;)

[Osiris's_Legacy]

Exactly what g6672D just said.

[xbolt]

Not just Doomsday... :D

[Chilvence]

This is really cool. Hopefully, decorate will only grow, its easily the easiest system for adding new stuff to the game.

I'm dubious about the model def though. It doesn't look like there is much control offered. Really, you cant make any model look good without another 50 frames of animation on top of the sprites, and being able to seperate the model for different rendering parameters is also highly desirable.