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

Obituary repackaging

Recommended Posts

Having gained momentum from my repackaging of the doomworld.com/vb/wads-mods/56652-quest-for-the-necronomicon-v1-9-update/]Quest for the Necronomicon, I gave another classic a try:

Obtic11 aka Obituary. Compared to Quest for the Necronomicon, this one was a breeze and much better packaged and well-formed, but still a major PITA to get to work with source ports.





To make a long story short, I made a single-file, source-port compatible version of it, with standard DEUTEX lumps. I also restored two "lost" maps the original PWADs contained (they look like earlier versions of MAP01 and MAP11 of Obituary itself), and placed them as MAP17 and MAP18, respectively. Did some minor cleanup with the texture lump, and now it runs happily with chocolate, prboom+ and Zdoom.

You can get the test package from here:

Obituary source port fix. Use both the WAD and the DEH file. This version is for testing only and does not include the deathmatch maps or the original texts.

Share this post


Link to post

Oh, sweet. I've already played Obituary using a semi-fixed up version from the DSDA, but this goes much farther toward facilitating compatibility. I'm looking forward to trying out Quest for the Necronomicon, even if it's still incomplete.

Share this post


Link to post

Yeah! You are awsome, Maes. I have to try this out asap.

edit: I encountered a problem at map01, the rising platform that gives acces to the yellow key isn't working properly (you no-clip through it after it moved up, so you can't get the yellow key which is hovering above you).

So far I am really enjoying this. Gives me nostalgic vibes, it was the first Doom mod I played in the 1990es :)

Share this post


Link to post
Tetzlaff said:

edit: I encountered a problem at map01, the rising platform that gives acces to the yellow key isn't working properly (you no-clip through it after it moved up, so you can't get the yellow key which is hovering above you).


What source port did you encounter this problem with? I didn't edit any of the maps (just rearranged resources), so this is most likely source-port dependant. I didn't really playtest it myself, yet, so I need this kind of input.

Share this post


Link to post

Edit: it turns out that the "pillar" is not supposed to be sticking out at all. Due to differences in how the "find shortest texture" is implemented in source ports and in chocolate/vanilla, the pillar never "sticks out" in vanilla/chocolate. To achieve this, you should play it with -complevel 2 in prBoom+ and set the "Find lowest texture like Doom" option on in ZDoom.

Share this post


Link to post

Yes, the "find shortest texture" compatibility option in ZDoom fixed that error with the yellow key. Thanks!

I' ll post here if I find more glitches or errors.

Share this post


Link to post

Fixed that, and updated the upload. It seems that the texture editing tool they used did weird stuff with the texture names (left whitespace in) and so "YELMIX" was actually stored as "YELMIX 2", with the space being actually a null (0x00). Some other textures also had similar issues, and I fixed them by shortening them to the first whitespace occurence e.g. "YELMIX 2" -> "YELMIX".

The Quest For the Necronomicon was plagued majorly by this problem, resulting in practically all source ports HOM-ing and tutti-fruttying its composite textures.

It's weird how vanilla Doom seems totally unplagued by this problem (apparently the string parsing function used searched the first null character with a left-chars-first search, while most source ports try to act "sly" by starting from the right, and thus stop at the NEXT null character or not at all, if they find a valid character at position 8.

E.g. "YELMIX 2" is scanned right to left, with a maximum string length of 8 characters. Since the 8th character is found not to be null, the whole string is erroneously assumed to be "YELMIX 2"...even Chocolate Doom behaves incorrectly in this sense (complains of not finding the YELMIX texture at all and exits)

Share this post


Link to post

Oh, yeah, great. So took a WAD that had optional weapons modifications and mashed it all together having no option at all. Great work, really.


You also clearly violated their terms of use:

Authors may NOT use this levels as a base to build additional
levels. You are NOT allowed to change this package. Obituary is
distributed as freeware!



Even when considering modifications to just keep a WAD operable not changing the package you did precisely that thus making your fix illegal.

The weapon mod contained in here was clearly optional as there's a second DEH patch without the weapon changes. You omitted that and you also made it impossible to omit the changed weapon graphics so no matter how you twist it, you *DID* change the package!

I'm not one of those boneheaded types who take such statements literally as meaning you are not allowed to change a single bit about it but it's very clear to me that this is what they wanted to prevent.

And there's no text file.

Share this post


Link to post

Oh come on, you really think fixing a wad from 1995 to make it playable with source ports in 2011 is exactly what they wanted to prevent?

They don't wanted someone to take Obituary and make some "Obituary plus" mod with additional custom stuff in it is how I understand it.

Share this post


Link to post
Graf Zahl said:

Oh, yeah, great. So took a WAD that had optional weapons modifications and mashed it all together having no option at all. Great work, really.


You also clearly violated their terms of use:




Even when considering modifications to just keep a WAD operable not changing the package you did precisely that thus making your fix illegal.

The weapon mod contained in here was clearly optional as there's a second DEH patch without the weapon changes. You omitted that and you also made it impossible to omit the changed weapon graphics so no matter how you twist it, you *DID* change the package!

I'm not one of those boneheaded types who take such statements literally as meaning you are not allowed to change a single bit about it but it's very clear to me that this is what they wanted to prevent.

And there's no text file.

Make your own package if this pisses you off! You're always pissed off... Anyway I agree that Maes should fix everything you mentioned there, so as to keep the integrity of the mod, while still keeping it workable. I know where you were getting at.

Share this post


Link to post

More bugs (all running GZDoom)

-map03 Chambers of Confusion: Missing textures on both sides of the yellow door (probably the textures that indicate the yellow door).

-map04 The Church: Missing texture on red bars.

Share this post


Link to post
Graf Zahl said:

I'm not one of those boneheaded types who take such statements literally as meaning you are not allowed to change a single bit about it


You sure did put up a convincing show, though.

Graf Zahl said:

Oh, yeah, great. So took a WAD that had optional weapons modifications and mashed it all together having no option at all. Great work, really.


This can be easily split into a separate file, once the rest of the problems are ironed out. But clearly my intent wasn't to fix it as little as possible so it just works with modern source ports. However having the weapons apart as a source port compliant WAD isn't itself a bad idea.

Graf Zahl said:

Even when considering modifications to just keep a WAD operable not changing the package you did precisely that thus making your fix illegal.


Cite the law, year of introduction, paragraph and comma, then. What I'm trying to do is a convenient repackaging that works with modern source ports, and I'm adopting a result-oriented rather than a process-oriented approach here. I know full well that there's a split in the community regarding this, but I also know full well where I stand.

Graf Zahl said:

And there's no text file.

...but it's very clear to me that this is what they wanted to prevent.

Maes said:

Use both the WAD and the DEH file. This version is for testing only and does not include the deathmatch maps or the original texts.


Plus, what others said. I don't think that they had the future appearance of source ports and their independence from the game's .exe (and the demise of MS-DOS) in mind when they laid out those "do not modify clauses". The community needs to take a clear stance on this matter once and for all. It can't depend just on the whim of Random Ass Guy A or B to stir up drama or not.

P.S.: Don't think I didn't consider those "implications" myself. The last more famous case, OTTAWAU, resulted in a protracted flamewar in which you took a totally "pro-repackaging" stance vs myk. In the end, what was released was a sort of patch that only included part of the original's data, and was to be used TOGETHER with the original package. In the case of OBTIC11, something like that could be feasible (only releasing sanitized versions of the sprites/flats/DEH resources) but even then, an "all in one" version is MUCH more convenient for testing. Despite any ethical/principle flaws it may have.

Share this post


Link to post
Maes said:

in which you took a totally "pro-repackaging" stance vs myk.



I have no problem with repackaging as long as the original contents remain intact. Obituary is in dire need of it. That still doesn't mean that you should take away options.

The weapon mod was just that in the original, the mod could be played with or without it and that's how it should stay.

Share this post


Link to post

Of course there are practical limits to how "intact" a repackaging can stay. E.g. I can't omit proper SS_START/F_START and SS_END/F_END markers around flats anymore. However it is possible to keep the weapon mod separate (and I think I duly thanked you for noticing it).

Finally, don't forget that this is still a project in testing, so anything lacking in this current test version can still be fixed/added in the end.

If needed, I will try to see if a simple "add this to the official package so it runs with source ports" approach is possible, but not to the point of requiring a custom patcher/installer.

Share this post


Link to post

To echo one of GZ's points, I do think that this and Quest_19 should contain the original text files, and possibly also a short note about the update--but I assume that you just haven't done it yet because it's a beta.

Share this post


Link to post
Not Jabba said:

To echo one of GZ's points, I do think that this and Quest_19 should contain the original text files, and possibly also a short note about the update--but I assume that you just haven't done it yet because it's a beta.


No disagreement here. But exactly because it's a beta, and I'm not really distributing these anywhere but here, I felt that including any form of textfile at this point would be premature, as any relevant discussion and feedback is done through the thread(s).

Share this post


Link to post

Would you redo Galaxia next since it's for v1.2? Because of that the map doesn't work properly in modern source ports, and I've never been able to play it. (Unless Chocolate Doom runs it, but I just can't play without mouselook)

Share this post


Link to post
TrueDude said:

Would you redo Galaxia next since it's for v1.2? Because of that the map doesn't work properly in modern source ports, and I've never been able to play it. (Unless Chocolate Doom runs it, but I just can't play without mouselook)


What part of Galaxia doesn't work in modern ports? I don't recall experiencing any issues when I played it in ZDoom.

Share this post


Link to post
Maes said:

The community needs to take a clear stance on this matter once and for all.

This isn't something that "the community" has any right to decide. What can be done with someone's own creative work is dictated solely by the stated wishes of whoever created it.

Share this post


Link to post
kmxexii said:

What part of Galaxia doesn't work in modern ports? I don't recall experiencing any issues when I played it in ZDoom.

Well it didn't work last time I tried it, anyway. I could try again.

EDIT: Works fine, don't know (or remember) what was wrong last time.

Share this post


Link to post
Grazza said:

This isn't something that "the community" has any right to decide. What can be done with someone's own creative work is dictated solely by the stated wishes of whoever created it.

Maes said:

It can't depend just on the whim of Random Ass Guy A or B

Share this post


Link to post

Well, yeah, Grazza was clearly referring to random guy C, the Creator, who isn't random at all for without Him there would be no PWAD for us to argue about.

Share this post


Link to post

No deny that the author's wishes should be respected, but then comes the thorny and not-so-easily-dismissable issue that when the authors said stuff like "[this wad] CANNOT be used as a basis to build additional levels" and, in particular "You CANNOT modify this package in any way", they did not have modern source ports in mind (hell, not even BOOM), or anything else than a specific version of doom.exe, and could not possibly imagine how one day their package would be all but unusable.

Perversely, the handful of TCs that are afflicted more by this kind of premature aging/installation lockout vs source ports, INVARIABLY do carry those bullshit clauses.

What has "divided the community" is whether these clauses should be

  1. taken conservatively, at face value EVEN at the risk of leaving the affected works unplayable forever with modern source ports (sometimes they are even unplayable with vanilla Doom, if you don't have the correct version). Even if this will eventually lead to their abandonment. Proponents accept this as a matter of course.
  2. interpreted differently, in a way that allows repackaging for convenience (and functionality), on the grounds that the authors couldn't have possibly foreseen such a situation in the future, and that this is NOT the kind of repackaging they were warning against.
Some people in this community are clearly A-types, others such as myself are clearly B-types. I interpret those "do not repackage" clauses as follows:

We're in 1994-1996. There's only doom.exe and MS-DOS to consider in terms of software (hell, not even ALL versions of doom.exe, just one in particular will do).

Random Ass Guy C. makes a complex TC involving an arbitrarily complex installation procedure dependent on MS-DOS tools and a particular version of doom.exe, packs his masterpiece together, and attaches a "DON'T MODIFY MY SHIT" clause.

What he really wanted to prevent was people redistributing modified versions of the package missing important files, e.g. external resources, required .exes, explanatory texts that would simply break it and make it useless.


Assuming first and foremost that Random Ass Guy C. wanted his work to be played by others, those "no modification" clauses were primarily meant to prevent breaking the -quite flimsy- installation package, and thus getting them a bad rep/undue support requests etc., NOT so that they could secretly laugh their asses off in 10 years time seeing how the Doomers of the future couldn't make neither head nor tails of their Sphinx-like clause.

Share this post


Link to post

Thanks so much Maes for doing this! 

 

I just found this thread after being unable to follow chocolate-doom's instructions to prep Obituary with TiC's ancient WAD tool NWT..  because guess what, it's 2017 and this 16-bit application does not run on 64-bit systems. 

 

Please also let it be known that I fully support your last statement and taking these bullshit clauses from 22 years ago at face value is, frankly, unreasonable.

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
×