Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
skib

DEHACKED

Recommended Posts

I think FreeDoom, since it is for BOOM and above, I think there should perhaps be an optional patch or maybe merged into the wad.
Because FreeDoom should replace almost everything!

I would happily do ALL the DEHACKED.

Share this post


Link to post

Freedoom's maps are designed with Boom compatibility in mind, but the project is still supposed to be functionally compatible with vanilla PWADs. The original IWADs have no DeHackEd work in them to 'replace', either, since it involves hacking around with the game engine.

I don't think this is a terribly good idea in any case; what is wrong with the way things work in Freedoom that would prompt this line of thought? What would you change with the DeHackEd patch?

Since the actors are (at least functionally) the same regardless of using the Doom(2) or Freedoom IWAD, why wouldn't you just make the hypothetical patch for Vanilla Doom and let people load it with whatever they want?

Share this post


Link to post

I was under the impression that you wanted to do something to the monster or weapon behaviour. While I wouldn't be particularly opposed to changing the map names or pickup messages, I still think that it's unnecessary, and should be left within the realm of the game engines, not the IWAD.

Share this post


Link to post

That's why maybe optional, if not, non-existant.
Also, if level names aren't changed, the levels should suit the name!

Share this post


Link to post

DEHACKED is not in the scope of Freedoom. Go fork yourself an own version or whatever if you want it.

Share this post


Link to post

Blasphemer uses it (though it has some different things) and this is made for Boom and above.
So why not have DEHACKED?

Share this post


Link to post
skib said:

Blasphemer uses it

Toon Doom has furries - why doesn't Freedoom?

The issue of whether or not to include a DeHackEd lump in Freedoom has been discussed before, this thread probably best sums up the dilemma.

Share this post


Link to post

The argument in that thread is that dehacked patches can lead to desyncs, which is correct. However, a dehacked patch that was purely "decorative" would not have that effect. By decorative, I mean: changes to heads-up messages, intermission screen text, level names, etc. I think it's possible to make a good case for including a decorative dehacked patch in the IWAD.

One thing that I will point out is that when Freedoom started, John Carmack explicitly stated that we "can't re-create anything that is clearly our work" and that "if it has imps, cyber demons, BFGs, etc, then you are treading on thin ice". Because of that, we've been careful to avoid monsters that look like the originals, and we use "AGM" instead of "UAC" (among others). However, when you pick up a BFG in Freedoom, it still says "BFG 9000", and when you reach the credits screen at the end of the game, it says "Imp" and "Cyberdemon".

Now, anyone who knows anything about the technical details of how Doom works knows that that isn't Freedoom's "fault" - those strings aren't in the IWAD, they're in the executables. Freedoom is just an IWAD, and that's what the source port is choosing to display. You can argue pretty persuasively along those lines.

But there is a mechanism available to us to replace those strings and we aren't using it. Id can and has been known to shut down projects in the past that it considered to be infringing upon its trademarks. Might they look at Freedoom, see references to BFGs and Cyberdemons and potentially think the same way? Might it be a good idea to include a dehacked patch just in case, to make explicitly clear that Freedoom isn't Doom and that we are trying not to infringe upon their rights?

Share this post


Link to post

Perversely, adding a dehacked patch in Freedoom to change the vanilla strings would actually result in including said strings in the distributed IWAD... So if you want to be really safe, use BEX string replacement instead of the standard dehacked method. (Well, even then, you'll still get stuff like CC_MANCU or CC_IMP contained in the IWAD, but that should probably be okay anyway since none of the names actually coined by id software are used in full.)

Share this post


Link to post

And what about a source ports (if there are any) that don't support loading embedded DEH/BEX files? Let's face it, if id wants to fuck Freedoom because of the strings they can find a way to do it. I guess the only way around that would be to distribute a executable with Freedoom that does not contain the problematic strings.

Share this post


Link to post
boris said:

And what about a source ports (if there are any) that don't support loading embedded DEH/BEX files?

Then I guess it'll just display the hardcoded texts.

boris said:

I guess the only way around that would be to distribute a executable with Freedoom that does not contain the problematic strings.

And you could still load it in your hypothetical non-BEX-compliant source port, so the only way would be to make it deliberately not compatible with anything else than the provided exe! :p

Share this post


Link to post

@Boris, what do you have against dehacked and what wouldn't use DEH? If a source-port doesn't allow DEH or BEX, it's crap and you might as well play DOOM.EXE! Just take those off the supported list

@Fraggle, good point, you put it well.
If John Carmack did say that, then we better use DEHACKED.
And maybe a language lump (for ZDoom users) that changes obituaries.

And it's not that hard to change a pickup message!

GOTSHOTGUN = You have a remington shotgun

Share this post


Link to post
skib said:

@Boris, what do you have against dehacked and what wouldn't use DEH? If a source-port doesn't allow DEH or BEX, it's crap and you might as well play DOOM.EXE! Just take those off the supported list

Indeed, a judge will surely dismiss id's complaints because some .exe's features suck in your opinion.
I think it's just pointless to care about the names. Either "the law" accepts that the strings are stored in the (not supplied) executable or it won't. I assume non of use are lawyers, so even some half-assed lawyer could turn it to make Freedoom look like it has "Imps", "Cyberdemons" or "BFG9000s", no matter if it has a Dehacked patch or not.

Maybe it'd be a good idea to ask the authors of source ports that are still in development to support the Freedoom IWAD with the (yet to be made up) appropriate strings for levels and monsters.

skib said:

And it's not that hard to change a pickup message!

GOTSHOTGUN = You have a remington shotgun

Replacing problematic strings with trademarked names is a splendid idea!

Share this post


Link to post

Have you ever heard of example?

Also, BOOM and other source-ports hold strings!
How else does blasphemer do it?
Huh? Huh?

Share this post


Link to post
boris said:

And what about a source ports (if there are any) that don't support loading embedded DEH/BEX files? Let's face it, if id wants to fuck Freedoom because of the strings they can find a way to do it. I guess the only way around that would be to distribute a executable with Freedoom that does not contain the problematic strings.

If there's no ability to do it (eg. with Chocolate Doom) then it isn't possible to do. But my point is that there is a mechanism that works in the majority of source ports. If carefully constructed (ie. decorative only, see above), it will be a harmless change and won't break anything. I think it's worth doing to distance ourselves from the commercial game and to do our best to respect Id's wishes.

Talking about court cases and judges is missing the point. If it gets to the kind of stage of actual legal threats then it's game over anyway, because the project doesn't have any realistic way to defend itself. What I'm suggesting is that we should do our best to put distance between Freedoom and the original IWADs. If it came down to having to defend the project to Id, at least we could say, we did these things, we made an effort to respect your wishes, we tried to make sure that your trademarks would not appear while playing the game.

Share this post


Link to post

So, DEHACKED?
Fraggle is right, we need to distance ourselves other-wise we are knee-deep in the dead and all go to the shores of hell.
Boris, what do you have against DEHACKED?

Share this post


Link to post

fraggle said:
[BTalking about court cases and judges is missing the point. If it gets to the kind of stage of actual legal threats then it's game over anyway, because the project doesn't have any realistic way to defend itself. What I'm suggesting is that we should do our best to put distance between Freedoom and the original IWADs. If it came down to having to defend the project to Id, at least we could say, we did these things, we made an effort to respect your wishes, we tried to make sure that your trademarks would not appear while playing the game. [/B]

I guess you're right. Personally I'd rather go with BEX though, for the reason Gez pointed out: Dehacked stores the original strings in the patch file. That would especially be ugly with the episode end texts...

Share this post


Link to post

Great, so it's settled.
BEX will be best.
I would like to do that because I actually want to contribute

I wrote a DEHACKED but it doesn't work for ZDoom, I'll have to fix that!

Share this post


Link to post

Well not that my opinion is worth much but I can't help but feel that a dehacked lump in the iwad is a horrible hack, and, for engines that care enough, freedoom support should be done by adding another mission pack like that which is done already for plutonia and tnt.

Share this post


Link to post

DeHackEd is a standard as far as Doom ports go (even ChocoDoom could load it from the IWAD itself in the same way it does for Hacx 1.2) whereas the "additional mission pack" approach would force port developers to adapt the new data to whatever format they use. In other words, you'd needlessly outsource responsibilities for Freedoom working correctly from the Freedoom developers to the port developers.

Most high-profile vanilla/Boom-compatible mods released the last several years have used embedded dehacked lumps.

Share this post


Link to post

Gez said:
In other words, you'd needlessly outsource responsibilities for Freedoom working correctly from the Freedoom developers to the port developers.

We are already, and have always been, in the situation of responsibilities for the IWAD working correctly being outsourced from IWAD developers to engine developers. You must have noticed how far too much of the IWAD is hard-coded into the engine. That's been forced on us from day 1. Any replacement IWAD needs engine-side support.

Most high-profile vanilla/Boom-compatible mods released the last several years have used embedded dehacked lumps.

Quite, and another good reason why Freedoom shouldn't have a dehacked lump. So many of the popular PWADs will override it. All of your nice messages that have been tweaked to match the Freedoom graphics and so forth will get reverted, and it will look stupid.

Share this post


Link to post

I can only speak for Eternity but our gamemission overlay system does *not* allow for mass override of the string resources. There is no efficient way to add that. It would require massive redirection through the BEX strings table and I personally am not prepared to do that. It would cause far more problems than it would ever solve.

If I can think of any argument against including a BEX patch it's that the original BOOM DeHackEd/BEX parser *fails* to find the original copies of strings once they have been replaced by either DeHackEd *OR* BEX string replacement.

This means that, far worse than what RjY is suggesting as a side effect, DEHACKED lumps in PWADs or ones added externally via the command line will *break* if they use DeHackEd-style text replacement. Again I only speak for Eternity, and we have fixed that problem (DeHackEd-style string comparison is done against the original canon string value and not the last BEX replacement copied over it), but other ports may not have followed suit, and older ports, including BOOM itself, MBF, WinMBF, SMMU, earlier versions of PrBoom, etc. are unmaintained and would therefore suffer as well.

Share this post


Link to post

Are you really talking about the strings that were part of the source code released into GPL by id. I would think that those strings, being part of such code that is now GPL, have also been released.
Also, it is not FreeDoom that is displaying such strings.

I think that every souce port, except the ones with minimal changes, have already identified themselves sufficiently as not being an id product, and having been derived from source code released by id.

I agree, it will only make more incompatibilities, and will only work right on a few ports.
DoomLegacy is probably one of them, but so many strings here have already been customized here, that I doubt that there are many that could be argued.
(Also, dehacked string replacement is one place where the old DOS code is broken, as it tries to overwrite CONST strings)

Share this post


Link to post
wesleyjohnson said:

(Also, dehacked string replacement is one place where the old DOS code is broken, as it tries to overwrite CONST strings)


BEX or DEH?

Share this post


Link to post
wesleyjohnson said:

Are you really talking about the strings that were part of the source code released into GPL by id. I would think that those strings, being part of such code that is now GPL, have also been released.
Also, it is not FreeDoom that is displaying such strings.

I think that every souce port, except the ones with minimal changes, have already identified themselves sufficiently as not being an id product, and having been derived from source code released by id.

I agree, it will only make more incompatibilities, and will only work right on a few ports.
DoomLegacy is probably one of them, but so many strings here have already been customized here, that I doubt that there are many that could be argued.
(Also, dehacked string replacement is one place where the old DOS code is broken, as it tries to overwrite CONST strings)

The strings contain trademarked names et al. which are not technically covered by the GPL. It's a very gray and murky area of licensing, and it'd be best to stay far away from it.

I guess you are talking about Legacy because BOOM's DeHackEd/BEX support has always replaced the strings by redirecting the pointers to them, and not via writing into string constants. As for the vanilla EXE, Watcom stores strings into the ordinary writable data segment, and doesn't perform any sort of constant folding magic - thus overwriting the strings in the EXE file was easy and safe.

Share this post


Link to post

DEH and dehacked lumps.
I suspect the code is borrowed from somewhere, because it has the same CONST string overwrite that I saw in zeth, that works in DOS compilers, but segfaults in Linux. I expect there other ports that handle DEH lumps that have the same problem, don't know which ones.
It was mentioned about the older ports that have do not have current maintainers, and this could be a potential problem.
I have been into that code 3 times because only certain wads trigger the string overwrite, and otherwise it sits there as a latent bug.
Introduce an IWAD that tries to replace almost every string, and it could get interesting. Of course this does not affect those ports recently rewritten, but I suspect some old ports will crash.

I expect that most every port has already fixed any string that
mis-identifies itself with a tradename. That would be the port responsibility.

I expect the strings like "Pick up the shotgun", are GPL now.
If that is not what is being discussed, then need to clarify that.

Share this post


Link to post
Quasar said:

The strings contain trademarked names et al. which are not technically covered by the GPL. It's a very gray and murky area of licensing, and it'd be best to stay far away from it.


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.

What I mean is, ignoring the engines (which this project is not a part of, it only covers the IWADs), if you were to look at any FreeDoom related content (e.g. opening the IWAD and looking inside), you will not find any references to the original stuff, so why bother? And consistency doesn't really matter either, if you load a PWAD with intention of running under the id IWAD, there's a slight chance things won't match up anyway.

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)

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?



Though one thing I do think is an issue, we are still using id's names for the difficulty levels (like Ultra-Violence, and Nightmare!, etc.). How are we in the right to be using these titles? Perhaps we should name these "Skill X" with a number in place of X. Or maybe "Very easy, easy, normal, hard, very hard"?

This is more of an issue since it actually deals with what is in the IWAD, not in the source which we have no control over anyway (as it is external and not related to this project).

Share this post


Link to post

I guess I can't convince you!
But I think it should be done.
Also, we could add a language lump.

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
×