[Won't change] PNAMES+TEXTURE1 can affect linedef special behavior?

[JPL]

This is a bizarre one and I want to make sure the problem is on my end rather than some subtle issue with GZDoom.

I'm sorry the steps to repro aren't simpler for this; I tried to create a one or two file small and simple test case, but couldn't because it involves IWAD content.

1. Use the latest version of WadSmoosh to create a doom_complete.pk3 with both Doom 2 and Final Doom content.
2. Launch GZDoom latest with this PK3 IWAD and from the console open PL_MAP30 (plutonia map30).
3. Proceed into the level and step through the first teleporter.
4. Observe: the line trigger you hit just before the teleporter did not fire as it does with Plutonia.wad, causing you to be sunk into a pit and unable to get up and proceed with the level. (without archvile-jumping, which isn't the intended progression obviously)
5. Exit and open the WadSmoosh IPK3 in SLADE. Open doom2.wad alongside it. Copy doom2's PNAMES and TEXTURE1 lump into the root of the WadSmoosh IPK3 and save it.
6. Relaunch with WadSmoosh and reopen PL_MAP30.
7. Proceed through the teleporter and observe: the line trigger works as expected this time.
8. Optional: Try the PNAMES+TEXTURE1-less IPK3 from steps 1-4 with GZDoom 3.6.0 or earlier - the issue doesn't seem to occur, because that version's texture handling code is completely different. (You may need to remove the ZScript file from the IPK3 to have it work with that version.)

Was this a GZDoom bug introduced in 3.7.0, or am I doing something wrong with WadSmoosh by not including a PNAMES + TEXTURE1 lump? I added the extraction of those a long time ago to fix some rare PWAD compat issues, but then recently removed that because I knew it wasn't necessary (100% of the actual textures WadSmoosh has are defined in a series of plaintext TEXTURES lumps). I'd prefer to not extract data unless I know exactly what it's doing. The bug report on my side is "Plutonia map30 doesn't work properly", but there's clearly something deeper at work.

[Gez]

4. Observe: the line trigger you hit just before the teleporter did not fire as it does with Plutonia.wad, causing you to be sunk into a pit and unable to get up and proceed with the level. (without archvile-jumping, which isn't the intended progression obviously)

It does. You can check this by using the iddt cheat so that all lines are shown, and using a distinctive color for lines that have an action on it.

---

Map start: trigger line is white.

After teleport (using follow mode off): trigger line is tan, showing it lost its trigger.

So you're pursuing a red herring. The texture definition lump is responsible for something, but not for map trigger no longer working, the map trigger works, it's not the triggering that's a failure point here.

Let's look at this line. What is it exactly it does?

---

30: W1 Floor Up by Shortest Lower Texture.

This seems like the direction in which we gotta search. It's looking at the height of a texture. The texture in this case is MARBFAC4. It's not one of the textures that get replaced or modified, since it's not changed in Plutonia compared to Doom II. But there's still a difference between when it's present from TEXTURE1 and when it's only present from TEXTURES. Gotta be something about namespaces I think.

You know what? Let's try that!

---

Verdict: doesn't work either. Odd. I'm not sure what it is, then.

[Gez]

I think the problem might be somewhere in there:

Code: Select all • Expand view

//
// P_FindShortestTextureAround()
//
// Passed a sector number, returns the shortest lower texture on a
// linedef bounding the sector.
//
// jff 02/03/98 Add routine to find shortest lower texture
//

static inline void CheckShortestTex (FLevelLocals *Level, FTextureID texnum, double &minsize)
{
   if (texnum.isValid() || (texnum.isNull() && (Level->i_compatflags & COMPATF_SHORTTEX)))
   {
      auto tex = TexMan.GetGameTexture(texnum);
      if (tex != NULL)
      {
         double h = tex->GetDisplayHeight();
         if (h < minsize)
         {
            minsize = h;
         }
      }
   }
}

double FindShortestTextureAround (sector_t *sec)
{
   double minsize = FLT_MAX;

   for (auto check : sec->Lines)
   {
      if (check->flags & ML_TWOSIDED)
      {
         CheckShortestTex (sec->Level, check->sidedef[0]->GetTexture(side_t::bottom), minsize);
         CheckShortestTex (sec->Level, check->sidedef[1]->GetTexture(side_t::bottom), minsize);
      }
   }
   return minsize < FLT_MAX ? minsize : TexMan.GameByIndex(0)->GetDisplayHeight();
}


[Graf Zahl]

You are still looking at the wrong place, I think. See that compatibility option being tested in there? It actually overrides the current texture's height if texture 0 is less tall. And it's here where I suspect the problem, i.e. the Wadsmoosh IPK3 does not define its 0-texture properly. When copying back the TEXTURE1 lump you get back AASHITTY and its actual height so things work again.

Which opens another can of worms: Texture 0 has different heights in the various IWADs so lumping everything together into one may produce incorrect height changes in maps where this is used for textures more than 64 pixels tall.

[Gez]

Testing with a TEXTURE1 + PNAMES pair that's reduced to just BODIES and AASHITTY respectively, the level works again.

Moving the various textures.stuff files from WadSmoosh, then using SLADE's texture editor and telling it to create a new (empty) TEXTURE1 + PNAMES so that it's filled only with the S3DUMMY texture/patch, and then putting the textures.stuff files back, then saving, and the level works again too.

So basically the FindShortestTextureAround() functions needs a FirstDefined texture to work, and it's only going to happen if there's a TEXTURE1 because TEXTURES cannot create a FirstDefined texture. At least, that's my understanding.

[Graf Zahl]

It neets a 'nulltexture', you can add that keyword to TEXTURES as well, preferably for both AASHITTY and AASTINKY because those are needed for some levels to work as intended.

[Gez]

Adding the NullTexture keyword to AASHITTY and AASTINKY doesn't solve the issue.

I wonder what ResolveTextureIndex(0, false, false) gives with DoomComplete.pk3.

[JPL]

Adding the NullTexture keyword to AASHITTY and AASTINKY doesn't solve the issue.

I wonder what ResolveTextureIndex(0, false, false) gives with DoomComplete.pk3.

That's one thing I'm curious about - if defining AASTINKY and AASHITTY in one of my TEXTURES lumps as they appear in doom1 and doom2, and give them each the "nulltexture" flag, why doesn't that have the same effect (eg fixing the Plutonia MAP30 issue) as creating a PNAMES and TEXTURE1 lump that does the same? What is the latter doing that the former isn't?

[Gez]

You don't need AASHITTY or AASTINKY specifically; you just need to have one texture, any texture be defined in TEXTURE1 so that you will have a FirstDefined texture, as shown by having S3DUMMY work just fine. Without a FirstDefined texture, the effect breaks.

[JPL]

You don't need AASHITTY or AASTINKY specifically; you just need to have one texture, any texture be defined in TEXTURE1 so that you will have a FirstDefined texture, as shown by having S3DUMMY work just fine. Without a FirstDefined texture, the effect breaks.

Makes sense, I'll make a dummy texture entry (64x64, to follow what doom2.wad's does) to avoid overriding the AASHITTY/AASTINKY already in my TEXTURES lump definitions.

Is there a reason that a TEXTURES lump cannot create a FirstDefined texture? And why does defining a NullTexture at the top of a TEXTURES lump not do the same thing?

One thing I noticed about including a minimal (1 entry) dummy PNAMES + TEXTURE1 lump with WadSmoosh is that it gives a fatal error when loading WADs that define their own lumps for that, eg Sheer Poison. The error text:

Code: Select all • Expand view

Bad PNAMES and/or texture directory:

PNAMES has 1 entries, but
BIGDOOR1 wants to use entry 3.


So that's not really an option, unless there's a special setting I'm missing.

[Gez]

shpo1 does a naughty thing: it includes TEXTURE1 and TEXTURE2, but not PNAMES.

I don't think you're going to be compatible with it easily. If you don't have a PNAMES, it'll break. If you have a Doom II PNAMES, it'll also break because what it expects is the Ultimate Doom PNAMES. If you have the Ultimate Doom PNAMES, it'll work -- but then a Doom II mod might break.

Is there a reason that a TEXTURES lump cannot create a FirstDefined texture? And why does defining a NullTexture at the top of a TEXTURES lump not do the same thing?

FirstDefined is texture index 0. It is ignored when used in a level but for some reason some game logic depends on it existing.
NullTexture is a generic way to have textures that don't get shown. The FirstDefined texture is a NullTexture, but there's no vice-versa here. The sprite name TNT1A0 is also a NullTexture.

[JPL]

Okay, I guess what I'm wondering is why nothing I define in an exclusively TEXTURES lump based setup has texture index 0... one of them has to be loaded first right? What special magic does PNAMES+TEXTURE1 have?

[Graf Zahl]

Actually something rather simple: The TEXTURE1 parser copies its first texture's dimensions to the real texture 0, TEXTURES does not do that.
Texture 0 is always a dummy placeholder, you will never be able to define it yourself.

[JPL]

I think I finally understand what Plutonia MAP30 is doing. Correct me if I'm wrong on any of this:

• The line that has special 30, "W1 Floor Up by Shortest Lower Texture", is part of a sector that's flush with the surrounding floor, and thus untextured. So when the player crosses it, it tries to "raise a tagged sector's floor by the height of the shortest lower texture on its defining linedefs" but doesn't have a texture on that line. So instead, it refers to texture 0. Which is defined in Plutonia's TEXTURE1 as AASHITTY, which is 64 units tall. So it raises the platform by 64 units.
• In a WadSmoosh 1.25 IPK3, it comes up with nothing for texture 0, and so the platform raises by 0 units.
• When I add Doom2's TEXTURE1 (and PNAMES, which it depends on) lumps to the WadSmoosh, it gets a 64x64 AASHITTY definition, which reproduces the Plutonia.wad behavior.

Which, to be clear, Plutonia is depending on an undefined behavior. Any idea how many maps do this? Because those all potentially break with WadSmoosh as well, in an invisible and extremely hard to track down way.

So here's one thing I'm curious about, then. See my attached "minimal IWAD" in PK3 format, from my Sectorseed project. It does not care about Doom and tries to use only modern methods for defining everything, ie no PNAMES and TEXTURE1 lump.

But when the included example PWAD uses the same "W1 Floor Up by Shortest Lower Texture" special in a similar context (no texture on the linedef), even though there is not a texture 0 defined in the way Doom2 et al do, the platform still rises up. Why is this?

At the end of the day, I'd WadSmoosh to act as much like vanilla Doom, Doom 2, etc IWADs as possible - the whole goal is that people can use it for playing everything and never have to worry about switching IWADs. It seems like my options are:
- include a minimal PNAMES and TEXTURE1 lump, which breaks certain naughty PWADs that don't redefine PNAMES and whose TEXTURE1 assumes something will be there and isn't. (Sheer Poison is already totally fucked anyway compat-wise, but I care more about WADs that aren't being deliberately weird and half-broken.)
- extract PNAMES and TEXTURE1 from doom2.wad during the WadSmoosh process, ensuring that everything works as before I made that change for 1.25. Could break specific Doom 1 WADs that are expecting specific patches and textures.
- include no PNAMES or TEXTURE1 lumps and use some other way to make the maps depending on undefined behavior work correctly. maybe a compat flag in the MAPINFO?

[Gez]

The line that has special 30, "W1 Floor Up by Shortest Lower Texture", is part of a sector that's flush with the surrounding floor, and thus untextured. So when the player crosses it, it tries to "raise a tagged sector's floor by the height of the shortest lower texture on its defining linedefs" but doesn't have a texture on that line.

The effect looks for the lower textures of the lines of the tagged sector. Not the lower textures of the effect line. So it's not that. Even more, the same effect is used for arachnotrons on MAP07, and obviously they don't have a lower texture.

You can try it, by the way: add AASTINKY as lower texture to the effect line in that map, save, and test. Still broken.

Furthermore:

So instead, it refers to texture 0. Which is defined in Plutonia's TEXTURE1 as AASHITTY, which is 64 units tall. So it raises the platform by 64 units.

S3DUMMY is 128 units tall, and the raise effect still works correctly -- you don't get raised to 64 above the expected position.

Code: Select all • Expand view

   case DFloor::floorRaiseByTexture:
      floor->m_Direction = 1;
      // [RH] Use P_FindShortestTextureAround from BOOM to do this
      //      since the code is identical to what was here. (Oddly
      //      enough, BOOM preserved the code here even though it
      //      also had this function.)
      newheight = sec->CenterFloor() + FindShortestTextureAround(sec);
      floor->m_FloorDestDist = sec->floorplane.PointToDist(sec->centerspot, newheight);
      break;


The tagged sector is at a started height of -64. It is surrounded by a pit at -128, itself surrounded by the level area at 0. The lower textures are MARBFAC4, which is 128 units tall.

I still don't get what's happening here.