Sign in to follow this  
Followers 0

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

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?

Share this post


Link to post
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
   "@
}

Share this post


Link to post
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?

Share this post


Link to post

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?

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
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

Share this post


Link to post

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?

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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

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
Sign in to follow this  
Followers 0