DECORATE states near 100%

As of r1234, EE's edf-branch has reached full maturity with the completion of DECORATE states, and the branch will be merged with trunk tomorrow after additional testing.

Here is a functional example EDF which reimplements the DoomImp using DECORATE state syntax (inheritance is not used to avoid inheriting any states from the normal DoomImp, for full proof of concept).

stdinclude("root.edf")

thingtype DoomImpTest
{
   doomednum   20001
   spawnhealth 60
   seesound    bgsit1
   painchance  200
   painsound   popain
   deathsound  bgdth1
   speed       8
   height      56.0
   activesound bgact
   cflags      SOLID|SHOOTABLE|COUNTKILL|FOOTCLIP|SPACMONSTER|PASSMOBJ
   
   obituary_normal "felt some DECORATE states"
   obituary_melee  "felt some DECORATE states"
      
   states =
   @"
   Spawn:
      TROO AB 10 A_Look
      loop
   See:
      TROO AABBCCDD 3 A_Chase
      loop
   Pain:
      TROO H 2
      TROO H 2 A_Pain
      goto See
   Melee:
   Missile:
      TROO EF 8 A_FaceTarget
      TROO G  6 A_TroopAttack
      goto See   
   Death:
      TROO I  8
      TROO J  8  A_Scream
      TROO K  6
      TROO L  6  A_Fall
      TROO M -1
   XDeath:
      TROO N    5
      TROO O    5 A_XScream
      TROO P    5
      TROO Q    5 A_Fall
      TROO RST  5
      TROO U   -1
   Raise:
      TROO ML  8
      TROO KJI 6
      goto See
   "@
}

Share this post


Link to post



Awesome. Having seen all the effort and internal reworking it took to make EE capable of handling it, I have to reiterate how much I hugely appreciate the lengths you've gone to in order to make this possible.

Defining objects in EDF just got a whole lot quicker :)

Share this post


Link to post

So "Null" has to be explicitly stated for states that have no codepointers?

Share this post


Link to post
Gez said:

So "Null" has to be explicitly stated for states that have no codepointers?

At the moment yes. Evidently I somehow missed that you're allowed to skip it. Looks like I get to do a shit load of work to fix this now.

Share this post


Link to post
Quasar said:

At the moment yes. Evidently I somehow missed that you're allowed to skip it. Looks like I get to do a shit load of work to fix this now.


Does that really need to be fixed? It's not that big a deal to use null directly.

Share this post


Link to post
Use3D said:

Does that really need to be fixed? It's not that big a deal to use null directly.

I already have it fixed ;) And it is, since this is supposed to be as copypastable from DECORATE as is possible for EE. As of right now the one thing you have to do is change codepointers.

I'll be implementing some of the important DECORATE pointers though, particularly various Jump pointers. But that work will be done in trunk after the merge, as it's not strictly anything to do with EDF itself.

Share this post


Link to post

Does this bring us any closer to seeing Heretic be playable?

Share this post


Link to post
Stilgar said:

Does this bring us any closer to seeing Heretic be playable?

I think it's unrelated. Heretic (and Hexen, and Strife) are waiting for a rework of the inventory and weapon systems.

Share this post


Link to post
Gez said:

I think it's unrelated. Heretic (and Hexen, and Strife) are waiting for a rework of the inventory and weapon systems.

It's partially related in that DECORATE states will be used in the weapon and inventory definitions :) I realized that these should go in first about half a year ago and so I suspended any further work on them until this prerequisite was finished.

Share this post


Link to post

Double posting to note that edf-branch has now been merged with trunk. DECORATE state support in EDF will officially debut with the next SVN revision upload.

A new official release, codename Resheph, will follow this pretty swiftly. I just need to finish the LevelInfo rewrite I started the other day and it will be ready to ship.

Share this post


Link to post

How are the frames defined DECORATE-style going to be named? They're independent from the thingtypes in Eternity, unlike ZDoom.

Share this post


Link to post

Why would they need a different name? It's not like the rest of the actor definition is DECORATE-style after all. Just the states.

r1247 is online by the way.

Share this post


Link to post
printz said:

How are the frames defined DECORATE-style going to be named? They're independent from the thingtypes in Eternity, unlike ZDoom.

Unsure of what you really mean here, since DECORATE-block-defined states are not in fact "independent" of the thingtype in the sense that they do not have public names or DeHackEd numbers.

Internally they are given the name {DS %d} with %d being an arbitrary ordinal representing the order in which they were defined. However this is not a name you can use with external frame targeting because it is not added into the hash table. It's only for internal use; for example, when printing an object's metatable, its metastates must have valid names to print. Note it is also not a name that can conflict with any valid frame mnemonic, since {} characters are not syntactically allowed within them.

Eternity's various codepointers which can take frames to jump to will most likely be modified to additionally accept DECORATE state labels (which really amounts to saying they'll be extended to access metastate labels). When an argument doesn't match one in the hash table, I can look at the object's metatable and see if it has a state matching that description.

Share this post


Link to post
Quasar said:

I'll be implementing some of the important DECORATE pointers though, particularly various Jump pointers.

Eternity already has RandomJump, CounterJump and so on. Probably you're adding A_Jump to simplify the DECORATE->EDF copy-pasting process. Speaking of RandomJump, how are the misc1 and misc2 fields handled in the Decorate heredoc syntax?

Is the '=' sign required before the heredoc?

Anyway, thanks a ton, because I'm also copying popular bestiary monsters into my EE work.

Share this post


Link to post

Are Eternity's frame-pointing codepointers currently supporting state labels?

Share this post


Link to post
printz said:

Eternity already has RandomJump, CounterJump and so on. Probably you're adding A_Jump to simplify the DECORATE->EDF copy-pasting process. Speaking of RandomJump, how are the misc1 and misc2 fields handled in the Decorate heredoc syntax?

Is the '=' sign required before the heredoc?

Anyway, thanks a ton, because I'm also copying popular bestiary monsters into my EE work.

A_RandomJump isn't currently compatible with DECORATE states because I haven't implemented offset() syntax (yet?). Though it may also be possible for me to simply define an alternate way to use the pointer with the normal args instead of misc fields. (The args didn't exist in MBF so it's not a compatibility issue).

A_Jump is already implemented, and can address any DECORATE state label. A_Jump supports its own random jump ability, and so it kinda makes adapting A_RandomJump less important. It expressly and intentionally does *not* support global state names, so as to remain roughly equivalent to ZDoom's implementation.

All other Eternity pointers that pre-existed will currently (as of a very recent SVN revision) check for a global state name first, and, having failed to find a match, will then check DECORATE state labels (both native and metastate labels will be matched properly - ie. Spawn, or Death.Fire, or Foobar). This allows them to seamlessly extend to DECORATE states.

Do note btw that EE has for quite a while now supported A_ prefixes on action names even outside of DECORATE states. If the A_ is found, it is simply stripped off before trying to match the function against the internal bexptrs hash table.

And no, equals signs are not required anywhere in EDF any more. I just prefer to put one there myself because to me it looks odd without it, kinda like the states keyword is just detached out there by itself.

Share this post


Link to post
Quasar said:

A_RandomJump isn't currently compatible with DECORATE states because I haven't implemented offset() syntax (yet?). Though it may also be possible for me to simply define an alternate way to use the pointer with the normal args instead of misc fields. (The args didn't exist in MBF so it's not a compatibility issue).

When I wrote some hacky way to add MBF dehacked compatibility to ZDoom, that's kinda what I did. The RandomJump call is remapped to A_Jump, and the misc values are turned into real parameters.

EE doesn't need to do that of course since it already has these functions anyway; but yeah it'd make a lot more sense to use the parameters there.

Share this post


Link to post
Quasar said:

Unsure of what you really mean here, since DECORATE-block-defined states are not in fact "independent" of the thingtype in the sense that they do not have public names or DeHackEd numbers.

What I tried to say in that post was that if thing frames are defined via Decorate, I won't be able to create Delta structures to individual frames any more, so it will be more work to patch a custom monster from another mod to act slightly differently. I trust that there'll still be a root FRAMES.EDF containing classically defined frames?

Share this post


Link to post
printz said:

What I tried to say in that post was that if thing frames are defined via Decorate, I won't be able to create Delta structures to individual frames any more, so it will be more work to patch a custom monster from another mod to act slightly differently. I trust that there'll still be a root FRAMES.EDF containing classically defined frames?

For compatibility reasons, yes, the frames for DOOM objects must remain defined as global states. I may or may not convert Heretic's objects to DECORATE states; it depends on the feedback I get in response to this idea. Strife and Hexen's things will be defined using them from the get-go.

It will soon be possible to completely replace (including via DoomEdNum) objects by inheriting from them, and at that point, what you'd do rather than use a framedelta is simply replace the state sequences that need to be different. The rest will be inherited, and can be used by utilization of the Super:: specifier, a parent thingtype namespace, or just the simple bare label name if it hasn't been overridden in the child type, in goto labels and A_Jump targets. The only reason this hasn't been possible up til now is because Lee's DoomEdNum hash table is volatile and doesn't guarantee that the newest thing using a DoomEdNum is necessarily the one that will be gotten from the hash table. I intend to replace that hash with one that has the guaranteed properties of EE's other hashes.

This is the sexy thing about metatables - I just call MetaCopyTable and an inheriting thing automagically gets all of its parent's metastates :D

EDIT: It's probably important for me to mention this fact explicitly: Even an object which does not use DECORATE states can be inherited from and have its native state fields referenced using the corresponding DECORATE state labels. Native state labels currently include Spawn, See, Pain, Missile, Melee, Death, XDeath, Raise, and Crash. So for instance this is perfectly valid (however pointless - there are actual possible uses for it, of course) EDF:

thingtype Foo { spawnstate S_FOO }

thingtype Bar
{
  inherits Foo
  states =
  @"
  Spawn:
     goto Super::Spawn
  "@
}

Share this post


Link to post
Quasar said:

For compatibility reasons, yes, the frames for DOOM objects must remain defined as global states. I may or may not convert Heretic's objects to DECORATE states; it depends on the feedback I get in response to this idea. Strife and Hexen's things will be defined using them from the get-go.

It will soon be possible to completely replace (including via DoomEdNum) objects by inheriting from them, and at that point, what you'd do rather than use a framedelta is simply replace the state sequences that need to be different.

That would prevent me from creating very compact EDF patches that only replace individual frame details (such as making already existing frames faster or changing their codepointers). Since there's already the Heretic frame list inside its FRAMES.EDF, why scrap it?

Different thing species won't be able to reference common frames. I know I'll be able to rewrite each sequence for each species, but having a common pool of frames sounds cleaner to me, than an exact copy for each object.

Because this is not exact DECORATE, maybe you can add new features to it? Like an optional mnemonic field to each frame (similar in necessity to how the Dehackednum was in the old days), that makes the frame public. The mnemonic will probably be read as S_thingname_framename.

Hopefully the DECORATE will be released readable in the EDF, unlike with ZDoom, where I have to read the wiki and hope it's up to date.

Is the "replaces" declarator supported? Are custom fields, as well?

EDIT: there are a few equivalent but differently named codepointers, such as A_CustomMissile having to become A_MissileAttack.

Share this post


Link to post

Tested with r1292, the "bright" keyword causes the game to crash.

EDIT: the offset() syntax is important, because Spawn, PlaySound, Mushroom and so on need it.

Share this post


Link to post
printz said:

Tested with r1292, the "bright" keyword causes the game to crash.

EDIT: the offset() syntax is important, because Spawn, PlaySound, Mushroom and so on need it.

Crash how? Is that really all the info you can give me?

offset will probably be added when weapons are added, but I don't want pointers using it to pass parameters.
Spawn will be one-upped by a DECORATE-compatible pointer.
PlaySound is already one-upped by PlaySoundEx.
Mushroom is a special case and I will consider it by itself.

Share this post


Link to post

Example with crash:

thingtype CacoLichFlameFar
{
  basictype              projectile
  
  seesound               lichflam

  speed                  30.0
  radius                 16.0
  height                 6.0

  damage                 2

  addflags               TLSTYLEADD

  translucency           80%

  states
  @"
        Spawn:
         CFIR ABCDEFGHIJKLMOP 1 bright
	   Stop
	Death:
         CFIR HIJKLMOP 1 bright
	   Stop
  "@
}
Result:
After monster tries to shoot said projectile, the game bombs with
Z_Realloc: Failure trying to allocate 838860800 bytes
Source: .\source\r_things.c:409
In addition, right before the bombing, I see the additively translucent picture of an Imp instead of the projectiles.

It only happens if I go melee with that monster (in which case, the creature fires these things instead, described below). At range, it shoots what you see above, and in effect, nothing in-game happens (no projectile).
thingtype CacoLichFlame
{
  inherits CacoLichFlameFar
  speed 28.0
  radius 15.0
  damage 1
}

Quasar said:

Mushroom is a special case and I will consider it by itself.

I have a MBF mod that uses the two misc parameters to make the mushroom explosion more horizontal, thus more effective. Are you sure it's a good idea to abandon its parameters? Here's a pic of firing them with undefault params:

Share this post


Link to post

For Mushroom, I'd advise simply doing it like ZDoom does: instead of misc1 and misc2, you can use the fourth and fifth parameters.

Using Offset(x, y) to pass parameters is frankly counter-intuitive and the illustration of a slavish devotion to the implementation details inherited from an old hack.

Share this post


Link to post
Quasar said:

Spawn will be one-upped by a DECORATE-compatible pointer.
PlaySound is already one-upped by PlaySoundEx.
Mushroom is a special case and I will consider it by itself.

What else is left: Turn, Face (does ZDoom have equivalents?), Scratch (important, could use expanding), LineEffect (pretty interesting codepointer if I may say so).

Share this post


Link to post
printz said:

What else is left: Turn, Face (does ZDoom have equivalents?)

http://zdoom.org/wiki/A_SetAngle

printz said:

Scratch (important, could use expanding)

http://zdoom.org/wiki/A_CustomMeleeAttack

printz said:

LineEffect (pretty interesting codepointer if I may say so).

ZDoom allows to put call to action specials instead of a codepointer. If Eternity copies this convention, it's a lot more user-friendly than using a number.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now