Quasar Posted February 21, 2010 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. 0 Share this post Link to post
esselfortium Posted February 21, 2010 Awesome, looking forward to this. The additive-loading stuff should be useful for anyone interested in doing effects/gameplay mods. 0 Share this post Link to post
printz Posted February 22, 2010 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? 0 Share this post Link to post
Quasar Posted February 22, 2010 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). 0 Share this post Link to post