DOSBOX wad merging

[Revae]

Hey there. I'm working on a (hopefully) vanilla compatible TC. Hitherto I've been testing in Chocolate doom, however.

Tonight I tried patching a doom exe with the dehacked file (which seemed to work) and merging doom.wad with my wad using deutex 4.4.0 (which didn't).

It copies the lumps in, and often overwrites them the right areas, but skips over some lumps and doubles them up, and generally doesn't work well, which causes the game to freeze when loading (at Init Playloop state).

I was curious if there's some tutorial out there I could follow, or if there's something I'm missing or doing wrong or if my wad isn't organized right, or what. At the moment I'm running the game through a dosbox autoexec config like so:

[autoexec]
mount c .\base
c:
DEUSF -merge mywad.wad
dehacked -save current.deh -reload -load mydeh.deh
doom -file mywad.wad e1m1.wad
dehacked -reload -load current.deh
del current.deh
DEUSF -res

Chocolate dooms -merge function works perfectly. I'd like to get it vanilla compatible though.

[Voros]

I'm not very familiar with deusf, as I never had to use it, although I'm more than familiar with Deutex. What's the purpose if e1m1.wad? Why not merge it too?

Why not this (unless I'm missing something)?

mount c .\base
c:
deusf -merge mywad.wad
dehacked -save current.deh -reload -load mydeh.deh
doom -iwad doom.wad -file e1m1.wad
dehacked -reload -load current.deh
del current.deh
deusf -res

Edit: wait a minute, you're working on that Rekkr TC, aren't you?

[scifista42]

The DEUTEX/DEUSF manual is in a file DTEXMAN6.TXT from here.

[Voros]

The manual isn't really a how to tutorial. It just explains what each command mainly does, what happens when executed, etc. And it's lengthy too.

Edit: you say that not all the lumps don't merge correctly? Make sure the wadinfo file for mywad.wad has everything in a correct order eg random example

[lumps]
DS_START
MUSAMB01
MUSAMB02
DS_START

this will produce a WAD file with those files in that specific order. The order tends to matter, as I initially had trouble making a textures WAD, because they weren't in the right order.

Think like this.
An IWAD file has these files in this order:
TEX1
TEX3
TEX2

I want to replace these files. So I make a wadinfo file like this

[lumps]
TEX1
TEX2
TEX3

During building, it'll check for TEX1, easy. Then next in line is TEX2 which is in the end, easy. Now TEX3 won't be added, because it already passed the TEX3 lump in the IWAD. Thus i get a PWAD containing only 2 lumps rather than 3.

I suspect that is your main problem.

[scifista42]

^ I thought that was a good thing, to have all relevant and potentially usable info available to readily search through, than to have just a partial info to adapt to your problem which might not exactly match it. Anyway, here is the relevant part of the document:

Spoiler

            -----------------------------------------------
D)          How to create a PWAD with new Sprites and Flats
            -----------------------------------------------

******** 1) Sprite and Flat REPLACEMENT

BEWARE: Sprite replacement is tricky. If some needed sprites are
  missing DOOM will lock up. Check your work often.

Put your Sprite files in \SPRITES in .GIF or .BMP format.
Put your Flat files in \FLATS in .GIF or .BMP format.
Declare your Sprite NAMES in the [SPRITES] section of WADINFO.TXT.
Declare your Flat NAMES in the [FLATS] section of WADINFO.TXT.
Use only the NAME in WADINFO.TXT, without the .GIF or .BMP extension.

 Since DeuTex 3.1:
 The '=' label lets your Sprites keep the names YOU have given
 them. It tells WADINFO.TXT what DOOM Sprite you mean to replace.
 This enables you to name your sprite files as you damn wish.

If you want to replace *ALL* of the Sprites and Flats in DOOM (crazy):

DEUTEX -iwad -make WADINFO.TXT NEWBIE.WAD

NEWBIE.WAD will be directly usable by DOOM.

Remember: replacing only part of the Sprites and Flats mean you'll
need DeuSF to install your PWAD, but it will be compatible with ALL
versions of DOOM and DOOM2. Redefining all the Sprites is not a good
idea unless you really mean it.


                                                                  page 11




To replace *SOME* of the Sprites and/or Flats in DOOM (better):

DEUTEX -make WADINFO.TXT NEWBIE.WAD

This NEWBIE.WAD will be much smaller and easier to distribute.
BUT: This NEWBIE.WAD will cause DOOM to lock up when it starts!(bad)

    So, if you want to replace only *SOME* of the Sprites and Flats in
    DOOM, you have 3 choices:

DEUTEX -merge NEWBIE.WAD           Modifies DOOM.WAD or DOOM2.WAD.
                                  (Safe, fast, and small)

DEUSF  -append NEWBIE.WAD          Modifies NEWBIE.WAD.
                                  (Safer, still fast, wastes some space)

DEUSF -add NEWBIE.WAD NEWBIE2.WAD  Creates NEWBIE2.WAD.
                                  (Safest, not slow, more space wasted)
+
+ NEW! To merge two PWADS that both redefine Sprites and/or Flats:
+
+ DEUSF -join FIRST.WAD SECOND.WAD  (FIRST.WAD now contains both wads)


NOTE: The steps above are performed at the end users' site, preferably
      from a batch file supplied with your PWAD. This means the user
      must have DeuSF, which can be distributed freely with your PWAD,
      or DeuTex, which has some restrictions on distribution. See the
      License Agreement at the end of this manual for the restrictions
      on distributing DeuTex.

The -sprite command is used to add only Sprites, ignoring the Flats:

DEUSF -sprite -app NEWBIE.WAD

The -flat command is used to add only Flats, without the Sprites:

DEUSF -flat -add NEWBIE.WAD NEWBIE2.WAD

[Revae]

Alright. It was definitely the ordering of things. It merges fine now. My brain was so shot last night that I couldn't think much further than asking for help. Thanks folks!

Though now I'm getting a badtexturecolumn error on level start that I don't get in chocolate doom - so maybe it doesn't merge "fine" (or maybe there are more differences between vanilla to chocolate than I imagined). BUT, it at least doesn't freeze up when loading. (see? gets to the title screen and everything)


One less thing to trouble shoot. I'll keep plugging away at it. Thanks again :-)

[Revae]

Since I have you here,

I'm trying to remedy this bad sprite column issue. I've read elsewhere that you need to have all the original sprites/flats represented in the pwad (which isn't a huge deal, because there's only ~20 or 30 that aren't yet replaced), but that didn't seem to help.

Curious what else could cause this error... Anything I might be overlooking.


Another more minor issue is that I replaced the plasma ball sprite with a version with rotations (so I replaced PLSSA0 with PLSSA1,PLSSA2A8, etc), and if I want to include all the originals it'll take PLSSA0 over the rotations.

[Voros]

Revae said:

I'm trying to remedy this bad sprite column issue. I've read elsewhere that you need to have all the original sprites/flats represented in the pwad (which isn't a huge deal, because there's only ~20 or 30 that aren't yet replaced), but that didn't seem to help.

From the DoomWiki:

R_DrawSpriteRange: bad texturecolumn
An invalid patch graphic has been rendered as a sprite, 
and the texturecolumn index has stepped out of range.

Why don't you find out which patch is being rendered as a sprite for starters?

Revae said:

Another more minor issue is that I replaced the plasma ball sprite with a version with rotations (so I replaced PLSSA0 with PLSSA1,PLSSA2A8, etc), and if I want to include all the originals it'll take PLSSA0 over the rotations.

Merge it twice, joining the modified IWAD with another PWAD that contains only the changes aftwerwards.
Eg
deutex -merge mywad.wad (doom.wad and mywad.wad together)
deutex -merge changes.wad (adds changes.wad to modified doom.wad)

Should work.

[Revae]

Voros said:

Why don't you find out which patch is being rendered as a sprite for starters?

I've looked. The error message doesn't indicate where the problem is, and nothing is standing out to me. Not really sure how to go about doing that.

Alright, I took a look at how Batman Doom does it, and may have found a path to victory...

Sorry to bother you. (but I will be more of a bother if this doesn't pan out)

[Jon]

Hey, if something breaks with vanilla and works with chocolate, then that's a chocolate bug that we would like to fix. Do you still have an example which breaks vanilla and works in chocolate, ideally an isolated case? If so would you be prepare to share it? Thanks!

[Revae]

Well right now my dehacked edits seem to be working with both, except that in vanilla the projectiles hit and explode inside the entity that shot them, whereas in chocolate they work fine.

Not sure what the cause is yet,though. So I can't give any specifics. Might just be something stupid I'm doing.

[Voros]

Post parts of the dehacked file that relate to the entity and projectile.

Or maybe Chocolate Doom is more stable than vanilla, which is amusing.

[Revae]

There's really nothing special about any of it. It happens with every projectile, so I'm not sure it's the dehacked patch itself, or what.

Thing 12 (Imp)
Bits = 155207174
Exploding frame = 0
Height = 3932160
Width = 983040
Hit points = 80
Death sound = 82
Mass = 500

Thing 32 (Imp fireball)
Missile damage = 5

^Should act, more or less, like a normal imp/fireball except that it can fly and it explodes on death.

run like this:

dehacked -save current.deh -reload -load rekkr13.deh
doom -file rekkr25.wad
dehacked -reload -load current.deh
del current.deh

[scifista42]

Revae said:

Bits = 155207174

That means: Obstacle + Shootable + No gravity + Travels over cliffs + Floating + Affect kills + Flying skull + Color 2.

The flying skull flag is an internal flag that the engine gives to Lost Souls when they charge and removes it when they stop charging. Why do you use it on a monster?

[Revae]

scifista42 said:

Why do you use it on a monster?

It wasn't supposed to be. I must've accidentally toggled it, and didn't notice since it doesn't do anything. Whoops. Changed it back, still had self inflicting projectiles.

Here's something though: I had tweaked the max health and armour settings, and soulsphere health and such. Changed them all back to defaults and now the projectiles no longer hit the firer... Chocolate doesn't seem to mind this (changed starting to health 75, max to 150, starting ammo to 10, max soulsphere health to 150, and soulsphere health given to 50, idfa armor to 150 - not sure yet which change made the difference, I reverted them all)

Something else:
The rocket replacement works like a time bomb. Fires with gravity. Hits ground, enters death state (so it drops when hitting monsters/walls and makes a "thud" sound), then ticks and explodes. If you have the death state set without a "fall" it will crash vanilla (freeze) but not chocolate. Pic related:

316 is the "death" state

Only thing left to fix (that I'm aware of) is my pistol/chaingun replacements freeze the game. I'll let you guys know of any other inconsistencies I hit. It seems like chocolate is just more forgiving all around.