Error exclusive to Chocolate Doom 3.0.0 reads "R_InitSprites: Sprite PISF frame A has multip rot=0 lump"

[Cammy]

An ongoing vanilla-compatible project of mine has a decent number of custom sprites and almost all of them seem to result in a crash message equivalent to this when the wad is loaded in Chocolate Doom 3.0.0.

 

 

I thought it was just my own download of Choco being damaged somehow, but A.H. Sankhatayan has reported the same problem with it. Removing the custom sprites fixed the crash. Doomkid tested in Windows 98 and ensured that, custom sprites included, the wad does not crash in the vanilla Doom II executable.

 

The sprites in question can be downloaded as a wad here. Would appreciate any help very much!

[Gez]

The message complains about having several PISFA0 lumps. It happens when it tries to install a PISFA0 sprite when a previous PISFA0 sprite has already been installed.

 

//
// R_InstallSpriteLump
// Local function for R_InitSprites.
//
void
R_InstallSpriteLump
( int		lump,
  unsigned	frame,
  unsigned	rotation,
  boolean	flipped )
{
    int		r;
	
    if (frame >= 29 || rotation > 8)
	I_Error("R_InstallSpriteLump: "
		"Bad frame characters in lump %i", lump);
	
    if ((int)frame > maxframe)
	maxframe = frame;
		
    if (rotation == 0)
    {
	// the lump should be used for all rotations
	if (sprtemp[frame].rotate == false)
	    I_Error ("R_InitSprites: Sprite %s frame %c has "
		     "multip rot=0 lump", spritename, 'A'+frame);

	if (sprtemp[frame].rotate == true)
	    I_Error ("R_InitSprites: Sprite %s frame %c has rotations "
		     "and a rot=0 lump", spritename, 'A'+frame);
			
	sprtemp[frame].rotate = false;
	for (r=0 ; r<8 ; r++)
	{
	    sprtemp[frame].lump[r] = lump - firstspritelump;
	    sprtemp[frame].flip[r] = (byte)flipped;
	}
	return;
    }
	
    // the lump is only used for one rotation
    if (sprtemp[frame].rotate == false)
	I_Error ("R_InitSprites: Sprite %s frame %c has rotations "
		 "and a rot=0 lump", spritename, 'A'+frame);
		
    sprtemp[frame].rotate = true;

    // make 0 based
    rotation--;		
    if (sprtemp[frame].lump[rotation] != -1)
	I_Error ("R_InitSprites: Sprite %s : %c : %c "
		 "has two lumps mapped to it",
		 spritename, 'A'+frame, '1'+rotation);
		
    sprtemp[frame].lump[rotation] = lump - firstspritelump;
    sprtemp[frame].flip[rotation] = (byte)flipped;
}

Custom sprites in vanilla compatibility is a bit of a pain, due to incomplete implementation of the namespace system. The solution found back in the days was to either modify the IWAD to put all the custom sprites in it, or duplicate all the sprites from the IWAD in the PWAD. Either way, it left only one unbroken namespace (S_START/S_END span of lumps) with all the sprites in it.

 

That's why things like DEUSF and NWT were created. And that's why you have to use the -merge switch instead of the -file switch to successfully load this kind of file in Choco.

[Lippeth]

Running a batch file with "chocolate-doom -merge RoC25sprites.wad" makes it run in Chocolate Doom for me, which is like running deusf.exe for vanilla Doom. There might be another way to do it, and I don't fully understand wad merging and appending sprites, but here's a good page for some info. https://www.chocolate-doom.org/wiki/index.php/WAD_merging_capability

 

I like the blue!

 

EDIT:

Ah, using DeuSF in DOSBox edits the wad which can then be used in Chocolate Doom without a batch file.

https://www.mediafire.com/file/3941ivbz1j9praq/RoC25sprites-deusf.wad/file

 

With both deusf.exe and RoC25sprites.wad in the Doom2 directory, type "deusf -app RoC25sprites.wad". It does increase the file size because (I assume) it's adding some of Doom's info to the wad. To restore the wad you can type "deusf -res RoC25sprites.wad".

Edited May 22, 2022 by Lippeth

[Aurelius]

One way to get around the problem is to use frames that aren't included in the IWAD. For example, instead of trying to replace PISFA0, include the sprite as PISFB0 and use dehacked to change the flash frame to refer to it instead. Just make sure you leave no "gaps", because including PISFC0 without PISFB0 will cause an error.

 

This is of course a bit more work than just replacing sprites, but it'd make the wad run on Choco with just the -file parameter.

[Cammy]

 

11 hours ago, Gez said:

And that's why you have to use the -merge switch instead of the -file switch to successfully load this kind of file in Choco.

 

13 hours ago, Lippeth said:

Running a batch file with "chocolate-doom -merge RoC25sprites.wad" makes it run in Chocolate Doom for me

 

Damn, is it really as simple as me using -merge incorrectly?? That actually is something I've attempted - both from the Chocolate Doom launcher and from within Ultimate Doom Builder - but in the past it hasn't worked for me. In that case, as a follow-up question, what is it I'm doing wrong in Chocolate?

 

I am utterly illiterate in the ways of the command prompt (which is itself a problem perhaps in need of fixing), so my process has been opening chocolate-doom-setup.exe (which I have in the same file folder as both DOOM2.wad and RoC25sprites.wad), using the "F2 = Warp" command and from there the "W = Add WADs" command to add RoC25sprites.wad, and then heading to the "Add extra parameters..." field, typing "-merge", and launching. I've tried typing "-merge RoC25sprites.wad" instead, but the crash still occurs without fail. Game doesn't even launch. What am I doing wrong?

 

By the way, glad you like the blue, Lippeth!

[Gez]

That's kind of a convoluted way of doing things, lol.

 

You could create a small text file, name it roc25.bat, and in its content there would just be:

chocolate-doom -merge RoC25sprites.wad

Then run it and it should work.

[Cammy]

1 hour ago, Gez said:

That's kind of a convoluted way of doing things, lol.

 

You could create a small text file, name it roc25.bat, and in its content there would just be:

chocolate-doom -merge RoC25sprites.wad

Then run it and it should work.

 

Hot damn, so THAT'S how it works! Thank you so much!