Does Eternity currently support ACS? And heredoc question... And state block question

[printz]

I've been seeing hints about Eternity having ACS. There are functions here and there, with ACS names (not Small names, with leading underscores). In spite of Small's deprecation, Eternity maps can still be scripted, through ACS? Can I just append a BEHAVIOR lump to each Eternity map, and get access to the code with Extradata ACS_Execute parameterized specials on linedefs?

Also, I saw you added heredoc support to EDF. Are there parts of the code that currently make use of heredocs?

I also saw in the source code (e_things.c) some thingtype state defining properties with plurals in them. Looking in the readme file, I assumed those are DECORATE-like state block shorteners. Are they really implemented, and if yes, how is the syntax?

[Quasar]

printz said:

I've been seeing hints about Eternity having ACS. There are functions here and there, with ACS names (not Small names, with leading underscores). In spite of Small's deprecation, Eternity maps can still be scripted, through ACS? Can I just append a BEHAVIOR lump to each Eternity map, and get access to the code with Extradata ACS_Execute parameterized specials on linedefs?

Also, I saw you added heredoc support to EDF. Are there parts of the code that currently make use of heredocs?

I also saw in the source code (e_things.c) some thingtype state defining properties with plurals in them. Looking in the readme file, I assumed those are DECORATE-like state block shorteners. Are they really implemented, and if yes, how is the syntax?

Due to the fact that BEHAVIOR lumps must be used to distinguish between DOOM and Hexen format maps, DOOM format maps may not have BEHAVIOR lumps. There is not currently any other way to add ACS code in Eternity, therefore you cannot use ACS with a DOOM format map.

The specials however are also available through ExtraData, as always.

This is obviously being worked on for Hexen compatibility, and for use with UDMF. It is not in a state you could currently want to try to use. It's not even up to full Hexen support yet, nor does it have any ZDoom extensions.

A heredoc can be used anywhere in EDF that a normal string can be used, but there is currently basically no reason to do this. DECORATE states are, however, immediately around the corner - they will be in the next release without a doubt, as they are almost finished right now. DECORATE states in EDF will be required to be contained inside heredoc strings, because they must contain characters that conflict with EDF's external syntax.

Example of what it will look like:

thingtype Foobar
{
   states
   @"
   Spawn:
      FOOB AB  10 A_Look
      goto Spawn
   See:
      FOOB ABCD 5 A_Chase
      goto See
   "@
}

[Gez]

Quasar said:

Due to the fact that BEHAVIOR lumps must be used to distinguish between DOOM and Hexen format maps, DOOM format maps may not have BEHAVIOR lumps. There is not currently any other way to add ACS code in Eternity, therefore you cannot use ACS with a DOOM format map.

And about that, does Eternity supports a Doom-in-Hexen format?

[printz]

Thanks for the information.

I've looked a bit more in the code (e_things.c) and among the supported EDF thing properties I saw "dmg_damagestates", "dmg_deathstates" and others that had ".add" and ".remove" appended to them. They appear to be lists... What exactly is their purpose? Are they practical, for now? Do they really exist, for the user?

[Quasar]

It will to an extent; it is not currently supported though. Hexen map format support is WIP - you can load the maps, but they are in a broken sort of condition, particularly with respect to sector specials. This stuff is simply not finished.

We will be focusing on UDMF, however. Use of Doom-in-Hexen will be considered deprecated in favor of UDMF.

[Mordeth]

Again: where are the updated docs? New shiny things is all nice and stuff, but if one does not mention how to implement them it does not do much good.

[Quasar]

There aren't any. If you want me to take 3 months off of development to work on them alone, keep in mind the price that is paid. :)

I certainly understand the scope of the problem, but I have yet to find a workable solution to it.

[printz]

Quasar said:

I certainly understand the scope of the problem, but I have yet to find a workable solution to it.

Well, the people with inside knowledge of Eternity (like one whose name starts with an 'e') have to also be enthusiastic and willing enough to add to the wiki.

Again, what do dmg_damagestates and dmg_deathstates do? :P

[Mordeth]

I don't expect a fully-fledged wiki, but mentioning eg the slope trigger numbers or what arguments the new action routines take would already be extremely helpfull. Just saying "EE has slopes" will not magically tell me how to implement them.

Don't think it will take more than 30 minutes for a quick writeup. And you do want people to start using your new features, yes?

[printz]

Mordeth said:

I don't expect a fully-fledged wiki, but mentioning eg the slope trigger numbers or what arguments the new action routines take would already be extremely helpfull. Just saying "EE has slopes" will not magically tell me how to implement them.

In this one case, here IS something (but then again, it was posted here when the sekhmet came up).

Most of it is copied from the (latest) EDITREF.HTML so it looks more like a textbook than a wiki tutorial, but it may be modified with each update or revision, or need for better writing.

[Gez]

What the EE wiki needs is somebody who watches the SVN updates and every time a feature is added or enhanced, deciphers the code and document it. That's what I try to do for ZDoom and GZDoom. It does require some knowledge of programming and enough familiarity with the codebase, which is not something given to everybody. Still, it's not that hard.

[Quasar]

dmg_deathstates is a string array of alternating damagetype and state names which, when placed in an actor, results in the named states being bound to their respective damagetypes.

EX:

thingtype HereticPlayer
{
   dmg_deathstates 
   { 
      Fire, S_HPLAY_FDTH1,
      Lava, S_HPLAY_FDTH1
   }
}

However, this syntax is kludgy at best and will not be preferable to using DECORATE-format states, which should be functional in the next release.

Adding the suffix .add to dmg_deathstates causes the states listed to be added to any that are already in the actor (of use in situations involving inheritance and thingdeltas). Without add, the list replaces any in the actor.

Adding the suffix .remove to dmg_deathstates alters the syntax to be used. You omit any names of states and simply list damagetypes, as in this example:

   dmg_deathstates.remove { Fire, Lava }

The states will then be unbound from those damagetypes for that thingtype.

dmg_painstates works in the exact same manner, except for pain states rather than death states.

[printz]

I didn't find listings of Fire, Lava... anywhere in the source code, so I assume damage types are arbitrary. Now there is another property called "damagefactor". Does it act like in zdoom, and the format is damagefactor {type1, ratio1, type2, ratio2, ...}[/i] ?

Actually, I could try it myself... And the implications are interesting, as I could try a missile that doesn't kill monsters, it does something else...

[Quasar]

They are defined in things.edf

Damagefactors use a new EDF syntax called multi-valued properties, which are exactly like the matching DECORATE syntax:

  thingtype Foobar
  {
     damagefactor Fire, 0.5
  }

You can have as many of those as you want. To remove one, you just set the damagefactor for that damagetype back to 1.0. It would have probably made sense to use mvprops for death and pain damage states, but they predate the addition of mvprops by a year or so.

[Csonicgo]

Gez said:

What the EE wiki needs is somebody who watches the SVN updates and every time a feature is added or enhanced, deciphers the code and document it. That's what I try to do for ZDoom and GZDoom. It does require some knowledge of programming and enough familiarity with the codebase, which is not something given to everybody. Still, it's not that hard.

I'm the only one that's testing SVN releases, and I have no idea how to do that.

[esselfortium]

Csonicgo said:

I'm the only one that's testing SVN releases, and I have no idea how to do that.

Er, what? I'm pretty sure quite a few other people are, myself included.

[kristus]

To jot down the rudimentary info for every new feature as they are introduced shouldn't take so long. Should it?