DEH implementation consensus

Does that mean that Eternity is doing DEH/BEX as described by the following (or some edited version of the following?):

Notice that this differs from the order Fraggle suggested in the command line DEH application.

1) The command line DEH entries must be considered mods to the IWAD, equal to DEH lumps in PWAD, so they must be applied to the IWAD after any IWAD internal DEH.
2) Any PWAD DEH lumps must mod the IWAD.
3) The command line DEH probably should come last, as a deliberate DEH lump should have highest precedence.
4) For some ports it should be considered in order of command line items. Apply DEH in the order of appearance on the command line, same as PWAD are applied in the order of appearance, with the last one winning.


My point being that to have a consensus, we really need a text description that some of us agree upon. Otherwise ...

Quasar said:

Eternity enqueues DEHACKED lumps for processing in the order that wads were added to the wad directory, via use of a FIFO queue. This means that a DEHACKED lump in the IWAD ought to be applied before any in a PWAD.

This is correct. However, this doesn't take into account dehacked patches loaded from the command line with -deh.

I just tried the Batman Doom example from my previous post with the latest SVN version of Eternity and I get the Freedoom strings for everything, not the Batman Doom ones. Presumably the IWAD's internal DEHACKED lump is being loaded after the one from batman.deh.

I also believe that Eternity, when doing DeHackEd-style string replacement, which works by value, compares against the original string value when doing subsequent replacements, and not with the value as established by the previously applied patch.

Indeed, I just checked and confirmed this. It looks like Lee Killough already fixed this way back in MBF. Prboom/Prboom+ still don't have the fix though.

I must stress that it would be much better if this Freedoom patch were to use BEX mnemonics and not DeHackEd-style string replacement. Eternity considers the latter to be deprecated for use in new modifications, as it's really quite awful from the fundamentals up.

Yes, this is what is already being used - although it's actually for legal / purity reasons (go back earlier in the thread and read some of the boring trademark law comments if you're curious why).

fraggle said:

This is correct. However, this doesn't take into account dehacked patches loaded from the command line with -deh.

I just tried the Batman Doom example from my previous post with the latest SVN version of Eternity and I get the Freedoom strings for everything, not the Batman Doom ones. Presumably the IWAD's internal DEHACKED lump is being loaded after the one from batman.de

It gets tricky. All-in-all there are tons of ways for EE to load DeHackEd/BEX patches:

• IWADs
  
• -file PWADs and drag-n-drop "loose" wad files
  
• PWADs loaded through the base/game/autoload directory
  
• PWADs loaded from a GFS script
  
• -deh / -bex files and drag-n-drop "loose" .deh/.bex files
  
• DEH/BEX in the base/game/autoload directory
  
• DEH/BEX specified via GFS files
  
• Legacy MBF autoloaded DEH/BEX configuration settings (up to two)
  

I can see some arguments for why any should be loaded before OR after certain others. For example some patches may only work right if they get the first shot at modifying data that exists in a singular instance, such as the mobjinfo and states. Once other patches modify them, the assumptions they make may break. They're really things that were never meant to be arbitrarily combined in this manner.

fraggle said:

Indeed, I just checked and confirmed this. It looks like Lee Killough already fixed this way back in MBF. Prboom/Prboom+ still don't have the fix though.

Nope, not to my knowledge - I remember fixing this myself in Eternity when you pointed out to me that it was broken one time, using a patch someone had submitted to Chocolate Doom for regression testing of your own DeHackEd parser - the patch exchanged the SPOS and POSS sprite names, and Eternity failed when using the raw BOOM string replacement semantics because after the first replacement was done, the second had no match left in the string table :>

fraggle said:

Yes, this is what is already being used - although it's actually for legal / purity reasons (go back earlier in the thread and read some of the boring trademark law comments if you're curious why).

Right and I remember seeing some of those. I just wanted to stress the point that DEH style string replacement is terrible and is better not used except when vanilla compatibility is at stake ;)

fraggle said:

Prboom/Prboom+ still don't have the fix though.

r3975 (plus) and r3976 (trunk) are your string replacement patch ... Is that wrong, or did you mean something else?

Quasar said:
It gets tricky. All-in-all there are tons of ways for EE to load DeHackEd/BEX patches:

Yeah we don't have as many as you but we do have "autoloaded" wads/patches (specified in config).

It looks like I'm still going to have to dig up half of D_DoomMainSetup and put it back in a different order to do this patch ordering thing, and that seems like a good way to introduce a whole load of new bugs.

[ Thinking out loud: If the first patch you load is the one from the iwad, you can't touch any patches at all until after W_Init. That means separating autoloaded *wads* (which have to be D_AddFile'd before W_Init) and autoloaded dehs. Also doing things in strict command line order is hard because DoLooseFiles rearranges the command line ;) I think probably doing all wad patches first in ascending lump order so the IWAD gets done first (trunk does this already, as of r4044) and then all command-line (-deh) patches, would be the easiest order to implement, but it's still going to be a fair amount of code rearrangement. ]

I cannot argue the difficulty.

But, to have the command line DEH overridden by PWAD, means that the user cannot fix a problem by specifying a correcting DEH on the command line.
A problematic PWAD will always override it. The only way to get around it is to edit the PWAD.

Having the command line DEH last means that the user can make a patching DEH and manually invoke it.

It will not be fun trying to implement it, but I think it is the best from the view of the end user. We may not all achieve that on the first pass at this, but I think "command line DEH last" should be stated as the end goal and desired behavior.

I also suspect that the command line specifics will likely remain individualistic behavior for each port simply because consensus there is not necessary to uniformly play IWAD and PWAD. Each port will only implement command line consensus that it can do so within its command line handling limitations.

RjY said:

r3975 (plus) and r3976 (trunk) are your string replacement patch ... Is that wrong, or did you mean something else?

Didn't know it had been applied. Thanks!

ReMooD does it MBF style, loads each DEHACKED lump in each WAD in sequential order. DEHACKED is in -file,-deh order.

Found the BoomDEH doc in the Boom202s source.
Some things it does not specify.
?? What ends a [STRINGS] section ??
?? Does it allow # comments in between backslash continuation lines.
Cause the Boom code seems to allow that, maybe by accident ??

I am also trying to fix the FRENCH strings.
I seems that using FRENCH makes it impossible for DEH strings to be recognized, and DEH changes would not be used anyway because the text[] references are not used.

One fix is to convert the french.h to a BEX, there is even a old note suggesting that.

Has anyone tried this, and did it work ????

I think that some of the strings are not in the BEX keywords.
Some of the strings have a leading space (that maybe could be removed).
Some of the strings have a trailing space (some of which should not be removed.

I was considering a fix to keep these spaces.
1. Recognized strings in quotes. If the first character of the BEX string is a double quote, then remove double quotes from the string.
2. Recognizing another character as a non-printing boundary, like vertical line. This would be the first or last character, but would be removed. This quickly looks like another quoted string solution.
3. Recognizing another character as a space, like underline. If an underline is seen as the first or last character of a string, change it to a space.