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

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

PNAMES+TEXTURE1 can affect linedef special behavior?

Postby JPL » Fri Sep 11, 2020 1:03 am

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.
User avatar
JPL
 
 
 
Joined: 09 Apr 2012

Re: PNAMES+TEXTURE1 can affect linedef special behavior?

Postby Gez » Fri Sep 11, 2020 4:14 am

JPL wrote: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.
Spoiler:


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?

Spoiler:

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!
Spoiler:


Verdict: doesn't work either. Odd. I'm not sure what it is, then.
Gez
 
 
 
Joined: 06 Jul 2007

Re: PNAMES+TEXTURE1 can affect linedef special behavior?

Postby Gez » Fri Sep 11, 2020 4:35 am

I think the problem might be somewhere in there:
Code: Select allExpand 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();
}
Gez
 
 
 
Joined: 06 Jul 2007

Re: PNAMES+TEXTURE1 can affect linedef special behavior?

Postby Graf Zahl » Fri Sep 11, 2020 5:08 am

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: PNAMES+TEXTURE1 can affect linedef special behavior?

Postby Gez » Fri Sep 11, 2020 6:29 am

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.
Gez
 
 
 
Joined: 06 Jul 2007

Re: PNAMES+TEXTURE1 can affect linedef special behavior?

Postby Graf Zahl » Fri Sep 11, 2020 7:38 am

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: PNAMES+TEXTURE1 can affect linedef special behavior?

Postby Gez » Fri Sep 11, 2020 9:48 am

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

I wonder what ResolveTextureIndex(0, false, false) gives with DoomComplete.pk3.
Gez
 
 
 
Joined: 06 Jul 2007

Re: PNAMES+TEXTURE1 can affect linedef special behavior?

Postby JPL » Fri Sep 11, 2020 8:33 pm

Gez wrote: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?
User avatar
JPL
 
 
 
Joined: 09 Apr 2012

Re: PNAMES+TEXTURE1 can affect linedef special behavior?

Postby Gez » Sat Sep 12, 2020 3:29 am

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.
Gez
 
 
 
Joined: 06 Jul 2007

Re: PNAMES+TEXTURE1 can affect linedef special behavior?

Postby JPL » Sat Sep 12, 2020 10:44 am

Gez wrote: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 allExpand 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.
User avatar
JPL
 
 
 
Joined: 09 Apr 2012

Re: PNAMES+TEXTURE1 can affect linedef special behavior?

Postby Gez » Sat Sep 12, 2020 11:32 am

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.

JPL wrote: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.
Gez
 
 
 
Joined: 06 Jul 2007

Re: PNAMES+TEXTURE1 can affect linedef special behavior?

Postby JPL » Sat Sep 12, 2020 12:02 pm

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?
User avatar
JPL
 
 
 
Joined: 09 Apr 2012

Re: PNAMES+TEXTURE1 can affect linedef special behavior?

Postby Graf Zahl » Sat Sep 12, 2020 1:27 pm

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: PNAMES+TEXTURE1 can affect linedef special behavior?

Postby JPL » Sat Sep 12, 2020 3:32 pm

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?
You do not have the required permissions to view the files attached to this post.
User avatar
JPL
 
 
 
Joined: 09 Apr 2012

Re: PNAMES+TEXTURE1 can affect linedef special behavior?

Postby Gez » Sat Sep 12, 2020 4:46 pm

JPL wrote: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:
JPL wrote: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 allExpand 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.
Gez
 
 
 
Joined: 06 Jul 2007

Next

Return to Closed Bugs

Who is online

Users browsing this forum: Deoster and 4 guests