Replacing Sprites in Vanilla Plutonia

Has anyone successfully done this or know of a WAD where it has been done?

This link is for a zip containing an example WAD and DEH file by Myk. It demonstrates how sprites can be replaced without including all the Doom II sprites.

Try it in Doom II using Chocolate Doom and check out the new green looking Demons and Cacos, it works great! Now try it using Plutonia with the same port - not so great...

So does anyone know how to correct this, or at least explain why it works in one IWAD but not the other? The error I get is this:

R_InstallSpriteLump: Bad frame characters in lump 2762

which occurs when a sprite lump uses a frame character that is not one of A–Z, [, \, or ]. From experimenting I think it's the S_END marker lump in the PWAD, which seems to offends Plutonia - if that helps any.

Help solving this conundrum would be much appreciated!

That's odd. Vanilla Doom 1.666 (does DeHackEd even work with Final Doom?) just hangs at P_Init: Init Playloop state. No error message. Though the error message provided by Chocolate Doom is surprisingly helpful, as we will see:

purist said:

R_InstallSpriteLump: Bad frame characters in lump 2762

which occurs when a sprite lump uses a frame character that is not one of A–Z, [, \, or ].

It also occurs when a lump has a rotation chracacter that is not a digit in the range 0-8, which is indeed the case with lump 2762: FIREBLU1

Sure enough, adding FIREBLU1 to your PWAD causes Doom to crash regardless of which IWAD is used. I haven't the faintest idea why Doom thinks it is a sprite. The DeHackEd patch isn't at fault, as even the unmodified executable chokes on the PWAD. The only thing unusual about that lump is that it shares its name with an animated texture, though if that were a problem Plutonia wouldn't work at all, regardless of what PWADs are used. It doesn't make any sense.

Foxpup said:

Does DeHackEd even work with Final Doom?

http://www.doomworld.com/idgames/index.php?file=utils/exe_edit/dhe31.zip

Foxpup said:

It also occurs when a lump has a rotation chracacter that is not a digit in the range 0-8, which is indeed the case with lump 2762: FIREBLU1

Sure enough, adding FIREBLU1 to your PWAD causes Doom to crash regardless of which IWAD is used. I haven't the faintest idea why Doom thinks it is a sprite. The DeHackEd patch isn't at fault, as even the unmodified executable chokes on the PWAD. The only thing unusual about that lump is that it shares its name with an animated texture, though if that were a problem Plutonia wouldn't work at all, regardless of what PWADs are used. It doesn't make any sense.

My possibly-incorrect understanding:

The "sprite list" is everything from S_END backwards to S_START. (The recolor wad uses SS_START to mark it's sprite list start, but the engine doesn't recognize this marker.) When you add a pwad, it's essentially appending the data onto the bottom of the main iwad. So everything in the IWAD after S_START gets included in the sprite list, essentially.

So why does it work with doom2.wad? Not sure. It could be that there are no other lumps after S_START that match the pattern for a sprite entry AND have an invalid rotation frame. Things like FLOOR3_3 have numbers in both the 6th and 8th character, and NUKAGE1 doesn't have 6 or 8 characters, which is required of a sprite.

This is all just a guess though.

Did you trying use the -merge option to add the wad?

At least the other two (commercial) id IWADs, doom.wad and tnt.wad, can use the green sprites just as well as doom2.wad, so the issue seems more like a bad exception in plutonia.wad rather than some miracle in doom2.wad.

The problem is because FIRE is a sprite identifier (the sprites are defined by an array of 4 character strings).

FIRE* clashes with FIREBLU* and ROCKA0 clashes with ROCK in plutonia's IWAD due to the extension of S_START/S_END to include all non-sprite lumps between them.

So the solution is to rename any sprite name / lump name clashes and include the renamed sprites in the PWAD.

e.g. Copy and rename the sprite patches to the PWAD: FIRE* to AVFR* and ROCKA0 to DHRKA0 and add the changes to the DEH file:

Text 4 4
FIREAVFR

Text 4 4
ROCKDHRK

Foxpup said:

It also occurs when a lump has a rotation chracacter that is not a digit in the range 0-8, which is indeed the case with lump 2762: FIREBLU1

How did you identify FIREBLU1 as lump 2762? I can't figure out how to do this in SLADE3 - did you use a different program or is there an option I've missed?

The reason I mentioned this is because I looked up FIREBLU1 in Plutonia.wad to see if there's anything unusual about it and when I filtered to 'FIRE' it listed the Arch Vile fire sprite along with the FIREBLU1 and FIREBLU2 textures. This made me wonder if Plutonia.exe was treating FIREBLU1 as a sprite because it has the first 4 letters.

To test this I altered Myk's recolour.deh patch, changing the data string FIRE to FIIR so it would not conflict with FIREBLU1 (or FIREBLU2). I then copied the FIRE** sprite frames from Plutonia.wad, pasted them into Myk's recolour.deh and renamed them FIIR** instead.

The result? Another crash, BUUUUT with a different message:

R_InstallSpriteLump: Bad frame characters in lump 2833

This to my small brain means it is now happy with the FIREBLU1 and FIREBLU2 lumps but is instead hanging on a different lump.

But which one? How do I identify lump 2833?

EDIT: Scrolls up...

THANKS MARINECONTROLLER!!

Going to see if this works in my own wad now :-)

marineController said:

The problem is because FIRE is a sprite identifier (the sprites are defined by an array of 4 character strings).

D'oh! Why didn't I think of that?

purist said:

How did you identify FIREBLU1 as lump 2762? I can't figure out how to do this in SLADE3 - did you use a different program or is there an option I've missed?

Select the first entry in the WAD, then hold Shift+Down/PageDown until it says 2762 entries selected. Lump 2762 is the one after that (as lump numbers start from 0 instead of 1). Not the most elegant solution, but it works.

Or in Linux:

lswad plutonia.wad |grep -n FIREBLU

Andrew, the solves the opposite problem of finding the lump number by name. I knew the lump number but not the name. Not that I use Linux anyway.

So, could some kind soul take a look at my DeHacked file and try to work out why it still doesn't work despite following the steps here? The WAD file seems ok as it runs with a simple DeHacked patch with ONLY the changes to the data strings but my patch has quite a few other changes and I guess one of them is causing a conflict.

https://www.dropbox.com/s/g00jl9zigu71w88/VOH_E1d.zip

Much appreciation and one Easter Egg to to anyone who can crack this for me :-)

What, specifically, doesn't work? Doom runs without errors and examination of the DeHackEd patch reveals no obvious problems. No, I'm not playing the entire WAD to find the problem when I don't even know what I'm looking for.

I didn't mention because I thought it was immediately obvious that when you run the files in Vanilla Plutonia (voh_e1d.wad + vohd.deh) it displayed that same R_InstallSpriteLump: Bad frame characters in lump 2762 error.

I still get this error with the files on my HD but I downloaded the files I linked to and tried it again and it worked fine. Weird. I'm puzzled but I'm not complaining. Possibly a problem with the launcher?

Thanks for taking a look anyway Foxpup, hopefully that's the end of it now.

Vanilla Doom never displayed any such error (instead it just hangs), nor does it have a launcher. Those are both from Chocolate Doom. For clarity, vanilla Doom specifically refers to the original DOOM2.EXE, or the EXE produced by running DeHackEd on the original DOOM2.EXE. No source port, however faithful to the original, is vanilla.

When developing for vanilla, it is helpful to actually test in vanilla, if only to ensure that any problems you encounter are really problems with your mod rather than problems with your port, thereby saving everybody else the trouble of figuring out what's wrong when in fact nothing is. ;3

Cheers Foxpop I'll bear that in mind.

Meanwhile, I did a bit of investigating and it turns out I had an older voh.deh file on my HD and my launcher was running this one rather than the newer, fixed one.

I should've thought about checking that first.

Purist, I downloaded the zip, it only had recolor.deh (what is the wad name?).

The deh crashes my PrBoom+ port (it brings me back to my iwad menu when I press play). No matter what iwad I use.

EDIT: its sprite.wad! Nvm! Still deh issue.