Sign in to follow this  
Followers 0

Impending EDF Changes

In order to move forward with support for DECORATE state syntax in EDF, some major architectural changes have to be made. This will result in the following changes and deprecations, which I do not believe should affect any existing Eternity projects:

  • EDFROOT and independent EDF lumps will become strictly additive, and include_prev() will be deprecated. Definitions will no longer ever be processed more than once, which can sometimes happen currently.
  • Including anything under /base other than root.edf via stdinclude() for purposes of including the original EDF definitions will be deprecated and unsupported for purposes of forward compatibility.
  • It will become possible to specify ANY type of EDF definition inside any EDF lump, regardless of its name or intended purpose.
  • Sprite names will be capable of being defined implicitly by frames. The spritenames array will remain only to provide DeHackEd compatibility for DOOM sprites, which must be defined in a certain order.

Share this post


Link to post

Awesome, looking forward to this. The additive-loading stuff should be useful for anyone interested in doing effects/gameplay mods.

Share this post


Link to post
Quasar said:


  • It will become possible to specify ANY type of EDF definition inside any EDF lump, regardless of its name or intended purpose.

It wasn't? Probably you mean ESOUNDS, ETERRAIN and so on. They were/are restrictive?

Share this post


Link to post
printz said:

It wasn't? Probably you mean ESOUNDS, ETERRAIN and so on. They were/are restrictive?

Yes, this was mentioned in the documentation. The specific lumps can only currently contain a subset of EDF definition types which relate directly to their lump name. For example ETERRAIN can define only terrain, splash, and floor objects.

After the rewrite this will change. Those lumps will simply be the preferred location to place definitions of those types. If other definitions are included they will still be parsed. This could be advantageous; for example, you might want to define splash actors along with the splashes that use them, rather than in a separate file.

This will largely be a streamlining of the EDF parsing and processing sequence, due to an ability of libConfuse of which I wasn't aware while creating the original architecture (that is, the fact that it can accumulate definitions from multiple parsing passes into a single cfg_t object).

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