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

dtwid.wad doesn't run

Recommended Posts

I just downloaded the release version of DTWID:
http://www.doomworld.com/vb/wads-mods/58100-doom-the-way-id-did-released/

I'm using Chocolate Doom 1.6 with a recent (Dec. 8) daily build of the Freedoom IWAD (works fine with everything else I tried).

$ chocolate-doom -iwad ./doom.wad -file dtwid.wad -deh dtwid.deh
...
P_Init: Init Playloop state.
R_TextureNumForName: SW1BLUE not found


PrBoom has the same problem, so it must be something about the Freedoom IWAD.

Btw, the dtwid.txt has this:

May Not Run With... : Versions of Doom prior to 1.9

Share this post


Link to post

PrBoom+ reports a bunch of unknown switch textures in stdout.txt when run with today's daily build. Those textures are all normally found in the TEXTURE2 lump that Freedoom doesn't have and I suspect that's the problem.

P_InitSwitchList: unknown texture SW1BLUE
P_InitSwitchList: unknown texture SW2BLUE
P_InitSwitchList: unknown texture SW1CMT
P_InitSwitchList: unknown texture SW2CMT
P_InitSwitchList: unknown texture SW1GARG
P_InitSwitchList: unknown texture SW2GARG
P_InitSwitchList: unknown texture SW1GSTON
P_InitSwitchList: unknown texture SW2GSTON
P_InitSwitchList: unknown texture SW1HOT
P_InitSwitchList: unknown texture SW2HOT
P_InitSwitchList: unknown texture SW1LION
P_InitSwitchList: unknown texture SW2LION
P_InitSwitchList: unknown texture SW1SATYR
P_InitSwitchList: unknown texture SW2SATYR
P_InitSwitchList: unknown texture SW1SKIN
P_InitSwitchList: unknown texture SW2SKIN
P_InitSwitchList: unknown texture SW1VINE
P_InitSwitchList: unknown texture SW2VINE
P_InitSwitchList: unknown texture SW1WOOD
P_InitSwitchList: unknown texture SW2WOOD
I'm going to try rebuilding the IWAD with a TEXTURE2 lump and see if that works with Chocolate Doom.

Share this post


Link to post

Adding a suitable TEXTURE2 lump to the Ultimate FreeDoom IWAD did the job for me, DTWID.WAD now runs under Chocolate Doom.

@hex11 - If you have the tools to patch your IWAD (not sure what's available for *nix users) here are the new/modified lumps, otherwise here is a pre-patched daily build.

Share this post


Link to post

I don't think this is a freedoom bug. If dtwid is replacing the texture lumps it has to override all of them (texture1, texture2, pnames) or bad things will happen.

(I am slightly surprised we don't have a texture2, but we don't need one as all our texture definitions are in texture1. We are free to do this as we are explicitly not building on top of id's doom.wad, which has both texture1 and texture2. On the other hand I wonder if we should add an _empty_ texture2 into ultimate freedoom for consistency...)

Share this post


Link to post

It's definitely a PWAD error and somewhat reminiscent of hex11's Slige problem, where it created a custom TEXTURE2 lump but no PNAMES lump. If DTWID.WAD contained a valid TEXTURE2 lump (I haven't yet tried adding the switches to it's TEXTURE1 lump) we wouldn't be discussing this now, though the problem appears to be restricted to a handful of ports and I don't know if it's part of a check to prevent PWADs from being run with Shareware Doom or something else hardcoded into the engines.

As for adding an empty TEXTURE2 lump, I tried that and it produced the same result as having no lump at all.

Share this post


Link to post

I did a little experiment last night with DeuTex (v4.4 for DOS) to see if I could re-order the patches by editing wadinfo.txt (it worked) though I'll have to do another experiment or two to see if that also fixes the PNAMES issue.

As for DTWID.WAD - adding missing textures to it's TEXTURE1 lump did the trick though for the longer term I'd suggest spreading Ultimate Freedoom's textures across 2 lumps.

Share this post


Link to post

Thanks GreyGhost! Your patched IWAD seems to do the trick. Chocolate Doom showed some warnings at startup:

R_Init: Init DOOM refresh daemon - [.....R_GenerateLookup: column without a patc
h (SKY4)
R_GenerateLookup: column without a patch (SP_DUDE1)
R_GenerateLookup: column without a patch (SP_FACE1)
R_GenerateLookup: column without a patch (SP_ROCK1)
R_GenerateLookup: column without a patch (STEPLAD1@)
R_GenerateLookup: column without a patch (STEPTOP)
R_GenerateLookup: column without a patch (SW1LION)
R_GenerateLookup: column without a patch (SW1SATYR@)
R_GenerateLookup: column without a patch (SW1WOOD)
R_GenerateLookup: column without a patch (SW2GARG)
R_GenerateLookup: column without a patch (SW2LION)
R_GenerateLookup: column without a patch (SW2SATYR@)
R_GenerateLookup: column without a patch (SW2SKIN)
R_GenerateLookup: column without a patch (SW2WOOD)
R_GenerateLookup: column without a patch (WOOD1)
R_GenerateLookup: column without a patch (WOOD5)
R_GenerateLookup: column without a patch (AASHITTY@)
R_GenerateLookup: column without a patch (GLASS1)

I only made it to E1M5 so far, and these look like possible issues with later episodes.

So this is technically a PWAD bug? That's a bit troubling, since the DTWID crew are effectively expert WAD authors. This leads me to belive that similar problems will happen again sooner or later, unless Freedoom takes preventive measures.

Share this post


Link to post

I see what you mean - time for Plan C. As RjY said - the best solution is to replace all three lumps in DTWID.WAD, so try these and run with an unpatched Ultimate Freedoom IWAD. Should also be error free with Registered and Ultimate Doom.

Share this post


Link to post

Hmm, not sure how to use raw texture lumps with xwadtools. DeuTex converts those automatically to text files.

But anyway, it turns out this is a very silly situation, because after running "deutex -xtract dtwid.wad", I come to find out this PWAD doesn't even include any custom textures at all! And yet, the tool they used to build the PWAD bundles TEXTURE1 and PNAMES lumps, for no reason. Or maybe whoever built it did so explicitely. In either case, I'm puzzled...

So at that point I simply edited the wadinfo.txt (directives list generated by DeuTex upon extration):

--- wadinfo.txt.orig    Mon Dec 12 03:11:19 2011
+++ wadinfo.txt Mon Dec 12 03:12:37 2011
@@ -50,10 +50,6 @@
 REJECT
 BLOCKMAP
 
-# List of definitions for TEXTURE1
-[texture1]
-TEXTURE1
-
 # List of Musics
 [musics]
 D_E2M9
Then it's simply a matter of running "deutex -make wadinfo.txt dtwid.wad", and voila... a PWAD that works perfectly with Freedoom. I guess that at this point I might as well download MrFreeze's music and include that as well.

So, that solves the DTWID scenario for now. But the same problem will undoubtly resurface when they release v1.1 or further updates (along with Episode 4, and maybe a D2TWID megawad).

Can Freedoom be changed to gracefully handle these inevitable issues?

Share this post


Link to post
hex11 said:

Hmm, not sure how to use raw texture lumps with xwadtools. DeuTex converts those automatically to text files.

I can run off another pair as text files if you find those easier to work with.

I come to find out this PWAD doesn't even include any custom textures at all! And yet, the tool they used to build the PWAD bundles TEXTURE1 and PNAMES lumps, for no reason.

Looks like there's only two custom textures (BROWN2 & STON2RAD) that are based on standard IWAD patches.

Can Freedoom be changed to gracefully handle these inevitable issues?

Maybe, though in an ideal world the wad author's would replace both texture lumps when adding custom textures.

Share this post


Link to post
GreyGhost said:

Looks like there's only two custom textures (BROWN2 & STON2RAD) that are based on standard IWAD patches.


Thanks for catching that, I hadn't even considered that possibility. When I extracted the PWAD, there were no custom patch or flat lumps, so I assumed incorrectly there were no new textures...

Both of those new textures are at the very end of texture1.txt, so their tool must have appended them to the TEXTURE1 lump, and DeuTex preserved the order.

Using the unmolested release version, I just did a "deutex -xtract", "rm dtwid.wad", "deutex -make", and this seems to have built a valid PWAD. Chocolate Doom runs it without any warnings, and there is no visible mangling (did a quick run in the first map of each episode). This is a bit strange though, because here's what in this new PWAD:

$ lswad -lv dtwid.wad |egrep -i 'texture|pname'
TEXTURE1 18852 4354188
PNAMES 3044 4373040

No TEXTURE2 lump, and yet no problems...

Share this post


Link to post

With no TEXTURE2 lump to replace you should be fine so long as you've covered all the textures, just don't try playing with the commercial IWADs. ;-)

Share this post


Link to post

Hmm, DTWID indeed has a TEXTURE1. If I'm understanding correctly, what's happening here is that DTWID's TEXTURE1 lump is overriding Freedoom's, and since all textures are stored there, we end up with a bunch of missing stuff. If so, I really don't know what we can do from this aside from follow Freedoom's example and pack all of Doom's texture definitions into DTWID's TEXTURE1 lump. Would that introduce any other problems?

God, I hate Doom's texture system so much.

Share this post


Link to post
Xaser said:

If so, I really don't know what we can do from this aside from follow Freedoom's example and pack all of Doom's texture definitions into DTWID's TEXTURE1 lump.

Copy the Doom TEXTURE2 lump as well? But it's better to let that issue be fixed Freedoom-side.

In the meantime, people can use ZDoom if they absolutely want to try the Freedoom+DTWID combo.

Share this post


Link to post

From the previous caesar.wad discussion, could also consider a separate
FreeDoom PNAMES lump that can be stuck in when needed.

I was able to fix some texture problems with caesar.wad by doing things like the following. And these are probably not exactly the lines I used because I am trying to remember this from around a year ago.
It appeared that if you throw enough wads at it, there was a chance of getting all the needed lumps.

> doomlegacy -iwad doom2.wad -file freedoom.wad caesar.wad
> doomlegacy -game freedoom -file doom2.wad freedoom.wad casear.wad
> doomlegacy -game freedoom -file gothic2.wad caesar.wad

Would separate PNAMEs PWAD help or hurt in this latest case ?

Share this post


Link to post
Xaser said:

If so, I really don't know what we can do from this aside from follow Freedoom's example and pack all of Doom's texture definitions into DTWID's TEXTURE1 lump. Would that introduce any other problems?

Depending on which PNAMES lump you use there'll be problems with either Registered or Ultimate Doom, in fact there currently are for the half dozen players still using Registered Doom. Replacing both texture lumps and using the Registered PNAMES lump would give the best all-round compatibility - until a 4th episode's added to the wad.

Share this post


Link to post

Sounds like the order of the PNAMES lump doesn't match the Vanilla one.

Really the Freedoom build system needs to be rejigged to generate the PNAMES and TEXTURE* directories in the same orders as the Vanilla WADs. I'm not sure how much work that will be, though.

Share this post


Link to post

What if the text files generated from the original DOOM are used to generate the texture1 and texture2 and pnames lump. As in un-deutex the ultimate doom wad and use those textures there... The shareware version only included texture1, and any textures used otherwise were found in texture2. so just do that I guess?

Share this post


Link to post

From a copyright perspective that's a less than ideal solution, if it's only a handful of the archive's 14,000-odd wads that are causing problems then a safer option might be to provide compatibility patches for the wads involved.

Share this post


Link to post

I ran a script on the entire idgames archive. About a dozen wads are affected and over half the wads are deathmatch only.

I have been making demos of all the wads on the archive and still have not found any by random luck...yet.

Share this post


Link to post

Was quite awhile ago. Did not keep script or exact names. Kashimir, caesar and all slige wads are the only known wads to be affected.

This has been gone over before and I think rescripting the build system so that the pnames are in the same order as id's was the proper fix. Also suggestions about the tex1/tex2 sound decent. Ultimate Freedoom target should be 100%. But remember Freedoom target also includes final doom, so precise scripting will be needed so that this works.

http://www.doomworld.com/vb/freedoom/55932-weird-patch-texture-bug/
http://www.doomworld.com/vb/freedoom/52810-pnames-wad-for-freedoom/

Share this post


Link to post

Putting the TEXTURE1/TEXTURE2 lumps in the same order as Doom would also allow multiplayer ports to host games with players mixing Freedoom/non-Freedoom.

Share this post


Link to post
fraggle said:

Putting the TEXTURE1/TEXTURE2 lumps in the same order as Doom would also allow multiplayer ports to host games with players mixing Freedoom/non-Freedoom.


Skulltag already allows mixing iwads and it works fine as it is.

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
×