DEHACKED

skib said:

Also, we could add a language lump.

How do you propose to do that without a scripting language?

What do you mean?
Haven't you used language before?

OB_MTZ = "%o was killed by MTZFire";

With ZDoom - yes. With DeHackEd - no. I'm pretty sure language lump support for DeHackEd patches is restricted to some of the advanced ports but I won't mind being proven wrong.

GreyGhost said:

I'm pretty sure language lump support for DeHackEd patches is restricted to some of the advanced ports

It's a ZDoom-only feature. As are the obituary string and formatting character in his example.

Yes, I was talking for ZDoom users!
There should be a ZDoom patch or something.

There may be some scope for port-specific lumps, but ideally it should be done without breaking compatibility with other ports.

I agree!
Maybe a ZDoom Patch and a DeHacked patch that can be applied, but not built-in!

At this point, I think I would understand the pros and cons of a DEHACKED/BEX/? lump a lot better if someone actually wrote one -- a first stab, so we could try it and see how it works.

Jon said:

At this point, I think I would understand the pros and cons of a DEHACKED/BEX/? lump a lot better if someone actually wrote one -- a first stab, so we could try it and see how it works.

agree.

Please don't tell me that the official maintainers are seriously considering this. A dehacked file is a pointless waste of effort, as it is the engine's fault that the strings reference Doom stuff, not the IWAD's fault.

Plus, considering a lot of the effort needed to make this run across different engines, all just to change something that shouldn't be changed in the first place, it's just completely pointless.

If it ever is included, it should be kept separate from the IWAD (as in, don't embed it), just as an optional file included with it, not in it.

I agree with Sodaholic here. I think a DeHacked patch is unnecessary.

Sodaholic said:

Well, to be honest, I don't really see how this applies to FreeDoom itself. It's the engines that need to worry about copyright issues, since they're the ones including the strings, not us. As long as we aren't the ones including any trademarked strings in the IWAD, I think we would be safe.

Technically you're correct but you're missing the point. Freedoom isn't just an IWAD - in practical terms it's a complete game. At present, anyone who sees Freedoom in play can see references to "BFGs" and "Cyberdemons" in the messages that appear - in direct contradiction to the advice that John Carmack gave us when we originally started the project. The excuse that it's the source port doing it seems like a lame one considering that:

(1) the source code is available for us to develop a modified source port that doesn't display those strings, but we haven't done that or ever even considered going to the effort.

(2) a widely supported practical mechanism is available (DEHACKED) that we could easily use to change those strings, and we haven't used it.

Basically what I'm saying is: don't look at this issue as though you're a programmer, WAD author or a fan who understands the technical details about how Doom works. I think our technical knowledge can make us blind to the big picture here. Look at it from the simplest perspective of someone who just loads the game up and looks at what they see. Does it show trademarked names? Why? If it's possible to avoid showing those names, why haven't we done it?

If id included the strings in the free release of the source code, I don't think they care that much. The fact that the strings are in the free source code could mean that they are open to use with any IWAD. (but I'm not a lawyer, but still, I think they are not considered part of owning the full game)

Absolutely and totally incorrect - see Carmack's email.

Besides, what's the point anyway if some (even if not many) source ports do not include BEX support (or even DEH), and what about ports that add more strings related to the original content (like ZDoom's obituary messages). Should we really bother if we're gonna have to deal with consistency across every port?

Yes. There are definitely technical challenges to implementing a patch that works on all ports; however, we can at least show that we've made the effort. That is in fact the whole point of what I'm trying to argue for - that we at least have the defence that we've made a deliberate effort to avoid Id's trademarks. If there are ports in which the original messages still appear, it's because of bugs, not because we haven't made the effort.

Another thing that's worth pointing out is that Freedoom has no real ability to legally defend itself. If a legal threat were to come against the project (which fortunately hasn't happened yet), that would realistically be the end of the project. Perhaps in a legal court you might be able that Freedoom doesn't technically contain the trademarked names, but that's irrelevant because it would never even reach a court in the first place. The best defence is therefore to eliminate any potential reason why there might be an objection in the first place.

This especially true if like me you're inclined to read this:

You can make a completely different game using the code with our blessing

as a reference to games such as Heretic, Strife or even Chex Quest. What did Raven, Rogue and Digital Café do? They did "completely different games using the code".

Even if the IWAD ends up containing the strings in question hidden in a DEHACKED lump, that'd be actually a lot less of a problem than all the Ultimate Doom stuff that the Chex Quest developers forgot to remove in chex.wad.

Besides, using DEHACKED is even more justified when one remembers that Freedoom aims for Boom compatibility, rather than vanilla compatibility; and even uses some other advanced port features when they don't create compatibility problems (such as a few ZDoom slopes in some maps). That's precedent enough to use a DEHACKED lump and maybe EMAPINFO, ZMAPINFO, LANGUAGE, etc. lumps as well.

There is still a technical problem to solve when using the Freedoom IWAD with a mod containing DEHACKED/BEX replacement for the same strings, though.

Gez said:

This especially true if like me you're inclined to read this:

as a reference to games such as Heretic, Strife or even Chex Quest. What did Raven, Rogue and Digital Café do? They did "completely different games using the code".

Yes, exactly. "Completely new game" means everything that makes up the game - including the text strings.

Jon said:

At this point, I think I would understand the pros and cons of a DEHACKED/BEX/? lump a lot better if someone actually wrote one -- a first stab, so we could try it and see how it works.

This seemed like a very good idea, so I've put together a BEX patch that changes various text strings. I made up some temporary names for things where necessary; suggestions for better names are welcome.

Curious to know what peoples' opinions are.

LOL @overdrive sphere

Well the BEX doesn't work with Chocolate Doom, which is the FreeDM target. Maybe a regular DEH would be good enough.

It's probably not necessary to change every name. For example, id doesn't own the trademarks to "shotgun" or "chaingun", etc. Carmack mentioned BFG because it's something they created out of thin air. But his message is pretty vague when it comes to "demons" and "imps", which are in fact age-old terms. He may have been referencing the likeness of them (pixel art). Then again, since the Freedoom monsters are quite differerent, it makes sense to use better names.

hex11 said:

Well the BEX doesn't work with Chocolate Doom, which is the FreeDM target. Maybe a regular DEH would be good enough.

I didn't think of that. Writing BEX patches is easier :-)

It's probably not necessary to change every name. For example, id doesn't own the trademarks to "shotgun" or "chaingun", etc.

True. I just went through the list and made replacements for as many as possible. If we're going to replace some, we might as well replace them all; it helps to hammer home the fact that it's a different game, and puts some distance between the two.

Carmack mentioned BFG because it's something they created out of thin air. But his message is pretty vague when it comes to "demons" and "imps", which are in fact age-old terms. He may have been referencing the likeness of them (pixel art). Then again, since the Freedoom monsters are quite differerent, it makes sense to use better names.

Exactly, and I chose names that I thought were descriptive of the Freedoom monsters (the Mancubus looks like a slug for example). Again, it's probably a good idea to use names that are deliberately different to distinguish from Doom.

Gez said:

There is still a technical problem to solve when using the Freedoom IWAD with a mod containing DEHACKED/BEX replacement for the same strings, though.

This is what I'm concerned about. If there's going to be unfixable conflicts with mods, it probably isn't worth the effort, as the IWAD contents are what really matter.

And I can see what you're saying, Fraggle, but I don't think that it's important enough that the player would really care, they can easily infer as to why the strings refer to Doom stuff.
And it's not that I'm missing the point, it's that I don't think it's a big enough deal to really bother with.

Perhaps we should ask John Carmack what he thinks about this?

Maybe package the DEH/BEX file with Freedoom, and let the player use it if they want to, or omit it if there's a conflict. Anyone who plays mods knows what these files are.

Sodaholic said:

And I can see what you're saying, Fraggle, but I don't think that it's important enough that the player would really care, they can easily infer as to why the strings refer to Doom stuff.

Yeah, a random player trying the IWAD probably doesn't really care, but I think the point is that a party behind a legal threat does care about trademarked names appearing in the game.

Sodaholic said:

Perhaps we should ask John Carmack what he thinks about this?

fraggle said:

the advice that John Carmack gave us

Sodaholic said:

This is what I'm concerned about. If there's going to be unfixable conflicts with mods, it probably isn't worth the effort, as the IWAD contents are what really matter.

There won't be any 'unfixable conflicts' if the DEHACKED/BEX patch is purely decorative, eg. just modifies the strings.
There's also no need to distribute it separately from the IWAD, if it's purely decorative.

When a PWAD with DEHACKED is loaded, the worst that will happen is that it'll simply replace the DEHACKED lump within the IWAD, and you just won't see the freedoom strings.

Worst said:

There won't be any 'unfixable conflicts' if the DEHACKED/BEX patch is purely decorative, eg. just modifies the strings.
There's also no need to distribute it separately from the IWAD, if it's purely decorative.

When a PWAD with DEHACKED is loaded, the worst that will happen is that it'll simply replace the DEHACKED lump within the IWAD, and you just won't see the freedoom strings.

To be fair there is a technical challenge here due to the way that the Boom Dehacked parser works (see Quasar's post earlier in the thread). The Boom Dehacked parser (used in Prboom, Eternity, etc) doesn't correctly handle the case where a string is changed by one patch and the same string then changed by a different patch (Dehacked works by replacing one string value with another one, and the "string to change from" has been changed from the original).

Personally I think this is just a technical bug that needs to be solved. It's a long-running bug in the way that the Boom-derived ports handle Dehacked string replacements and deserves to be fixed in its own right anyway.

fraggle said:

The Boom Dehacked parser (used in Prboom, Eternity, etc) doesn't correctly handle the case where a string is changed by one patch and the same string then changed by a different patch

Heh, well the original boom dehacked parser does not support wad embedded DEHACKED lumps, let alone loading multiple ones of them.

Just to be sure, I tested various sourceports:

chocolate-doom 1.6.0: no support for wad embedded DEHACKED lumps
boom 2.02 : no support for wad embedded DEHACKED lumps.
prboom-plus 2.5.1.0 : only last loaded DEHACKED lump is parsed. *
edge 1.35 : only last loaded DEHACKED lump is parsed. *
zdaemon 1.08.08b : only last loaded DEHACKED lump is parsed. *
Doomsday 1.8.6: only last loaded DEHACKED lump is parsed. *
mbf 12/22/1998 : loads both DEHACKED lumps, string replacement has the issue quasar described.
Doom Legacy 1.44.0 alpha2: loads both DEHACKED lumps, string replacement has the issue quasar described.
eternity 3.40.11 : loads both DEHACKED lumps, but string replacement works anyways.
zdoom 2.5.0 (r3218): loads both DEHACKED lumps, string replacement works.

* the ports that only parse the last loaded DEHACKED lump, have no 'conflicts' in the string replacement. The DEHACKED lump in the IWAD is never parsed in the cases where a pwad includes a DEHACKED lump.

So out of these 10 ports I tried;
2 does not support embedded DEHACKED lumps at all.
4 ignores the DEHACKED in the iwad if a pwad has one.
2 has the string replacement issue that quasar described.
2 handles the DEHACKED lumps in perhaps the most ideal way.

perhaps testing more ports would change the proportion of ports that are affected by the string replacement issue.. but I think it's more or less specific to the MBF based ports, which support loading of multiple DEHACKED lumps.

fraggle said:

Personally I think this is just a technical bug that needs to be solved. It's a long-running bug in the way that the Boom MBF-derived ports handle Dehacked string replacements and deserves to be fixed in its own right anyway.

Yeah agreed.

fraggle said:

I've put together a BEX patch that changes various text strings.

Thanks, I've taken the liberty of committing this - if it causes problems, it can always be reverted.

Worst said:

chocolate-doom 1.6.0:[/B] no support for wad embedded DEHACKED lumps

Actually there is, but it's disabled normally. It's used when playing the Hacx 1.2 IWAD; and a similar IWAD-based exception could certainly be used for Freedoom in future versions.

Worst said:

Just to be sure, I tested various sourceports:

Thanks for testing these. It's slightly more complicated than that though - the second (non-IWAD) patch might also come from a separate dehacked patch specified on the command line as well as from a DEHACKED lump inside a PWAD. For example, this should do the sensible thing:

doom -iwad (freedoom iwad) -file batman.wad -deh batman.deh

In this scenario, the order should be:

• IWAD is loaded
  
• DEHACKED lump inside IWAD is loaded
  
• External dehacked patches are loaded (-deh on command line)
  
• External PWAD(s) are loaded
  
• DEHACKED lumps inside PWADs are loaded

With the current setup in PrBoom+, the ordering is:

• IWAD is loaded
  
• External dehacked patches are loaded (-deh on command line)
  
• External PWAD(s) are loaded
  
• DEHACKED lump is loaded, either from PWAD or IWAD (only a single lump is supported)

The Batman Doom example therefore doesn't work because the DEHACKED lump is loaded last, overriding the patch specified on the command line.

For what it's worth I've put together a relatively simple patch to fix the string replacements problem, and it should be trivial to adapt this patch to other Boom-based ports (Eternity etc). However, the ordering problem described above also needs to be fixed.

I really do think that it should be optional, and not built into the IWAD. Let the player decide if they want the alternate strings or not.

Nothing is stopping you from ripping the DEHACKED lump out of the wad if you don't want it. Or from just playing the original game, if you like BFG900s and cyberdemons so much.

Sodaholic said:

I really do think that it should be optional, and not built into the IWAD. Let the player decide if they want the alternate strings or not.

I can understand your point of view; however, I think it would be much better to fix the source ports to work properly, and it shouldn't be difficult to do so.

It could be distributed as a separate accompanying patch, but to do so would defeat most of the purpose of having a patch in the first place (the purpose as I have expressed it in this thread). The whole idea is to remove trademarks from Freedoom when it is played. By having a separate patch, the default would then be to having the game run without the patch. How many people, reasonably, would go to the effort of adding "-deh freedoom.bex" to the command line every time they load the game, especially if, after all, it is just a set of text string replacements?

The best option is to fix the source ports; they ought to be fixed as the current behaviour isn't sensible anyway. I've made progress towards this already (see patch above), and it shouldn't be hard to fix the DEHACKED lump ordering problem described above either.

Gez said:

Actually there is, but it's disabled normally. It's used when playing the Hacx 1.2 IWAD; and a similar IWAD-based exception could certainly be used for Freedoom in future versions.

This is correct, and I'm not adverse to the idea of adding a similar exception for Freedoom/FreeDM as well. Similarly, Gez pointed out that, "adding a dehacked patch in Freedoom to change the vanilla strings would actually result in including said strings in the distributed IWAD"; I'd be willing to add support for BEX [strings] sections to resolve this.