Why does "Raise Floor by Shortest Lower Texture" only half work on older ports?

[Ol' Scratch]

Does anybody understand this issue and/or have a workaround? I recently switched to crispy doom from Zdoom, and I'm now having this issue again (I seem to recall the same thing happening in chocolate doom): I have a few sectors where the shortest lower texture is 128, and yet when I use the "raise floor by shortest lower" trigger it only goes up by 64 or so. In fact I think all floors with this trigger go up by the same amount regardless of the height of the shortest lower texture, also regardless of texture offsets. What's going on?

[esselfortium]

Vanilla Doom treated missing textures as the same as AASHITTY, the dummy texture at the start of the list. As such, leaving any lower textures left unfilled (on either the front or back side) would be equivalent to setting them to the 64-tall AASHITTY. Set them to another texture that's the height you want, and it should work as intended in all ports.

[Ol' Scratch]

It works! Thank you esselfortium. Do you perhaps have any insight into why some of my "Floor lower to lowest floor" triggers have also stopped working now that I've switched from Zdoom to Crispy? In one case, switching a linedef of the triggered sector so that its' back faces the intended lowest-floored neighbor worked, but in two other cases it didn't.

[Bauul]

1 hour ago, Ol' Scratch said:

It works! Thank you esselfortium. Do you perhaps have any insight into why some of my "Floor lower to lowest floor" triggers have also stopped working now that I've switched from Zdoom to Crispy? In one case, switching a linedef of the triggered sector so that its' back faces the intended lowest-floored neighbor worked, but in two other cases it didn't.

Have you set them up with tags properly?  If you aren't using tags ZDoom will "guess" you mean the effect the sector the line backs onto, but vanilla Doom doesn't do that for anything other than Door actions.  You need to give everything a tag.

[Ol' Scratch]

Bauul Yeah, it's all tagged. Are you suggesting I tag the lines outlining the sector that's supposed to drop as well as the switch that has the effect? As is the switch has a tag and an action (floor lower to lowest), and the sector that is supposed to move has the same tag.

[Fonze]

Might be best to post the map, or at least the relevant parts of it. You don't need to tag anything but the triggering line(s) and the sector(s) it's intended to directly operate. 

[Ol' Scratch]

https://drive.google.com/open?id=0B6B9k9j54oGvaHVKZm9UT215cG8

 

it's tag 107- works on most of the sectors it's tagged to, just not the sector nearest the switch (sector 2325). Tag 106, right next to it, also works in Zdoom but not in Crispy- I think that one might be a linedef proximity issue though, I've run into those before in old ports.

[Fonze]

Somebody else could perhaps explain it better than I and in a nice, scientific way, but while I notice the triggers not working when running the file as-is in Crispy, after deleting the mass of barrels in s2325 I notice that it does work, or as an alternative simply IDCLIP'ing into the wall, destroying them all, and exiting the sector makes it work as well. So the long of the short of it is that those barrels (or anything, for that matter) are blocking the floor movement simply from being on the floor as it lowers. I have no idea why that is but that's what's happening.

 

You could probably make the lowering walls really thin so the barrels do not interfere, but aside from that Idk what is going on there.

[Ol' Scratch]

wow, thanks for putting the time in to figure that out! I think I can work around this now, just gotta make room for those barrels.

[Linguica]

I would bet that it's the same issue discussed in 

 where stuff can stop a sector from moving so long as it's within a blockmap block touching the bounding box of the sector.