Why do some upper/lower textures in backside absorb missiles?

[tatsurd-cacocaco]

Some upper/lower textures in backside absorb rockets, plasma, and shots of BFG under vanilla compatibility. I know the behavior for a long time and I have met with making my map a few times. The behavior didn't occur when I changed a texture has upper or lower textures from backside to frontside. I don't know the condition that it occurs. Why does it happen?

Proboom-plus with vanilla compatibility

[plums]

I don't know the cause either, but I'm pretty sure it only happens in sectors with F_SKY1 as the ceiling.

[Foxpup]

Missiles don't hit two-sided walls if there is a ceiling height difference between the two sectors and the back side of the wall has a sky ceiling. This is to prevent missiles from hitting sky hack walls, but Doom does not check that it was actually the sky that was hit. Note that if you're right up against the wall, the missile will explode anyway, because missiles always explode when they have no room to spawn, without regard for the properties of the obstruction.

Incidentally, hitscan attacks exhibit a similar bug, though the behaviour is incorrect in a different way: hitscan attacks will not hit two-sided walls only if both sides have a sky ceiling, but different ceiling heights are not required in this case.

[printz]

This is trully an unholy phenomenon. The hell is a powerful force.

[plums]

Thanks Foxpup. Any idea why missiles will sometimes explode in those cases anyhow? (When the player is far away, I mean.) I assume it's something along the lines of a rounding error.

[Snakes]

I first noticed that in E4M6 - you can imagine how annoyed I was when the intended to target proceeded to kill me not long after the missile just happened to disappear into oblivion.

[clamgor]

Interesting bug.

I think that sector you were shooting at has F_SKY1 as a ceiling or floor.

[Foxpup]

plums said:

Thanks Foxpup. Any idea why missiles will sometimes explode in those cases anyhow? (When the player is far away, I mean.) I assume it's something along the lines of a rounding error.

I've only ever seen that happen when two lines are very close together, so I'm guessing the missile intersects both in the same tic, and Doom applies the sky test to the wrong one (I'm pretty sure it only tests the last line hit that has a ceiling height difference, where "last" is based on the order of the blockmap list, not the missile's trajectory). Also, one-sided lines are checked before two-sided lines, so if a missile hits a one-sided line in the same tic, it will always explode. This happens with genuine sky hack walls, as well.

[plums]

Gotta be something else to it though. Here's a simple two-sector map, a box in a larger box, with a plasma rifle. If you pick it up and start firing while turning in Chocolate Doom, the plasma bolts will sometimes collide with the walls. (South and West walls only?)

https://www.mediafire.com/?81lma0e3g47g135

[Foxpup]

Hmm. I can't explain that.

[Maes]

This looks more like a blockmap bug, which has been discussed in length and even led to a fix time ago, by me and entryway (which, BTW, should be implemented in PrBoom+ if you turn on an option called "Fix clipping problems in large levels". Try that and see if it fixes the level).

The bug can trigger quite easily if the blockmap is stretched beyond 128 units in either direction, and the no-clipping behavior will occur only in those directions and not in others.

[plums]

Maes said:

which, BTW, should be implemented in PrBoom+ if you turn on an option called "Fix clipping problems in large levels". Try that and see if it fixes the level

Nope, not on -complevel 2 anyhow. Also tried rotating the map, offseting it slightly (with a grid-aligned outer sector), etc., and the projectiles still sometimes collide with the wall.

Might be related to the way calculations done for collisions, that allow for wallrunning?

[Maes]

Can you share the map? Maybe some esoteric source-port experimenting will lead to an answer, and maybe even a new bug -and its fix- be discovered.

[plums]

The link was right above you :) . It's literally two squares though.
https://www.mediafire.com/?81lma0e3g47g135

Here's the rotated and offset version:
https://www.mediafire.com/?n04s1tpojnlrz8o


edit: Also the bug does seem to be present in PrBoom+ on cl9, if it's an actual skyhack wall. (Boom fixed the problem of disappearing projectiles in non-skyhack walls I guess?)
https://www.mediafire.com/?bbvz2ywvc82pp84

[kb1]

Here's another interesting bug that can be noticed when rockets hit small 4-sided pillars (and other similar constructs): Rockets often explode within the pillar, not upon impact with the closest side. The reason is simple:

Each tic, rockets (and all moving things) are "transported" from their previous position to their new position, based on their momentum. In other words, they do not smoothly move from point A to point B; instead they are removed from the map, and then re-added into their new position (which may be inside a wall). When the rocket is just outside of the pillar, the very next move might place it within the pillar. At that time, collision checks are performed, and any of the 4 sides of the pillar might be found to be the wall that was hit, even if it's the opposite wall, and even if it's inside the pillar!

This effect can wreak havoc on ports that attempt to paint splats on the impacted wall. In many ports, and in vanilla, this can cause missile explosions and smoke puffs to be drawn behind the wall, thus invisible, though usually you can still see some part of the explosion sprite peek through the pillar.

[Foxpup]

kb1 said:

In many ports, and in vanilla, this can cause missile explosions and smoke puffs to be drawn behind the wall, thus invisible, though usually you can still see some part of the explosion sprite peek through the pillar.

Not in vanilla, it can't. The movement clipping code moves the missile back to the correct side of the wall. Mancubus fireballs and -fast missiles are fast enough to go completely through a wall in a single tic, and will explode in the void if they fail to so again when re-entering a sector, but even then it's still the "correct" side of the wall that was hit, as it was actually hit from the wrong side in the first place.

Bullets are not physical objects in Doom, and do not go through walls under any circumstances (given a functioning blockmap). Also, when a shot does hit something, the bullet puffs are always projected along the shot's original path back towards the shooter, and so can never appear on the wrong side of a wall.

[Wagi]

Maes said:

This looks more like a blockmap bug,

This has nothing to with a blockmap. There are two separate bugs with the way Doom handles sky walls, both of them relating to a lack of a Z position check when seeing if something hit a sky wall.

		// explode a missile
		if (ceilingline &&
		    ceilingline->backsector &&
		    ceilingline->backsector->ceilingpic == skyflatnum)
		{
		    // Hack to prevent missiles exploding
		    // against the sky.
		    // Does not handle sky floors.
		    P_RemoveMobj (mo);
		    return;
		}

A simple addition of "mo->z + mo->height > ceilingline->backsector->ceilingheight &&" would fix this issue, I believe.

For an example of a normal Doom map that features the bug, visit E1M8, kill the barons, fall down to the large outdoor area, and fire projectiles at the "star" structure. 90% of them will disappear, but bullet puffs still appear on it.

[kb1]

Foxpup said:

Not in vanilla, it can't. The movement clipping code moves the missile back to the correct side of the wall. Mancubus fireballs and -fast missiles are fast enough to go completely through a wall in a single tic, and will explode in the void if they fail to so again when re-entering a sector, but even then it's still the "correct" side of the wall that was hit, as it was actually hit from the wrong side in the first place.

Say what? :) If a missile is headed towards a pillar, it can be detected as hitting the far wall. Because the missile, given it's radius, could be hitting more than one wall at a time. Once a collision is confirmed, no more checking is done. The code stops immediately after the hit is first confirmed, and the missile explodes inside the pillar. In vanilla.

Foxpup said:

Bullets are not physical objects in Doom, and do not go through walls under any circumstances (given a functioning blockmap). Also, when a shot does hit something, the bullet puffs are always projected along the shot's original path back towards the shooter, and so can never appear on the wrong side of a wall.

This is actually true. I forgot that my code shows puffs for rockets, which can end up inside the pillar. But, you're right - hitscans do not exhibit the same behavior.

[Quasar]

Foxpup said:

Bullets ... do not go through walls under any circumstances

I'm not so certain. The tracing algorithm used has a couple of known bugs which also affected the line of sight check up to v1.2 of the engine. There are cases that are not checked for when stepping through the blockmap which can lead to a runaway trace.

[Foxpup]

kb1 said:

Say what? :) If a missile is headed towards a pillar, it can be detected as hitting the far wall. Because the missile, given it's radius, could be hitting more than one wall at a time. Once a collision is confirmed, no more checking is done. The code stops immediately after the hit is first confirmed, and the missile explodes inside the pillar. In vanilla.

Why does it need to do more checking? The movement clipping code doesn't care which wall was hit. If P_TryMove fails (ie, it hit something), the movement is blocked, and the thing is clipped to its last unblocked position, and if it was a missile, it explodes at that location. The only case where a missile can explode inside a wall is if was spawned inside the wall in the first place.

LMPs or it didn't happen.

[kb1]

Foxpup said:

Why does it need to do more checking? The movement clipping code doesn't care which wall was hit. If P_TryMove fails (ie, it hit something), the movement is blocked, and the thing is clipped to its last unblocked position, and if it was a missile, it explodes at that location.

Fully agree (That's basically what I said).

Foxpup said:

The only case where a missile can explode inside a wall is if was spawned inside the wall in the first place.

Fully disagree - see explanation in previous post.

Foxpup said:

LMPs or it didn't happen.

We already know it "didn't happen" for you - I'm ok with that. What is your goal? My goal is not to show everyone how smart I am, it was simply to inform. I can do that without proving it to you.

I've fixed the issue to my satisfaction in my home port, by backtracking away from the explosion, toward the source, with an invisible trace, then reversing with another invisible trace until it hits the correct wall. This allows me to place a splat on the expected wall. Finally, this code enhancement moves the missile explosion right in front of the splat, so it explodes in the expected location.

If I come across the situation again, remember this thread, and feel inclined, I might make a demo of it.

Just remember: Truth is true, whether is has been proven, and whether you believe it or not. I would not have mentioned it otherwise.

[Foxpup]

I'm not talking about decals appearing on the wrong wall, I'm talking about missiles exploding inside walls in vanilla. I don't know or care what your port is doing to the missile clipping code; you insist it happens in vanilla, which it does not.

There are only two layers of proof: that which the code says should happen, and that which a demo says actually happens. The code says missiles that hit a wall can't end up inside another wall if they weren't spawned there to begin with. In the absence of demos proving otherwise, that is what I believe.

[Graf Zahl]

Quasar said:

I'm not so certain. The tracing algorithm used has a couple of known bugs which also affected the line of sight check up to v1.2 of the engine. There are cases that are not checked for when stepping through the blockmap which can lead to a runaway trace.

Correct, but those traces are lost, they won't hit anything so they do not really go through walls.

I did some extensive debugging when I hunted down that particular bug and there's no chance they can hit anything after 'getting lost'. The tracing code completely fails to advance the trace if the error condition (exit through a block's corner) occurs.

With the sight checking code this condition was interpreted as 'nothing view blocking found in the trace', not that a successful connection with the target was made.

[kb1]

Foxpup said:

I'm not talking about decals appearing on the wrong wall, I'm talking about missiles exploding inside walls in vanilla.

Indirectly, you are - the wall that gets the decal (unless you decide to fix it) is the wall that the rocket was determined to have collided with. That's what helped me identify that this situation does indeed occur.

Foxpup said:

There are only two layers of proof: that which the code says should happen, and that which a demo says actually happens. The code says missiles that hit a wall can't end up inside another wall if they weren't spawned there to begin with. In the absence of demos proving otherwise, that is what I believe.

There are actually 3 "layers of proof" - I have claimed that it is true, and I consider myself honest.
Ok, let me try once again: When this situation occurs, yes, the expected wall is collided against. However, the far wall can also be considered a collider, when wall linedefs are close together. Depending on the order the walls are checked, Doom could choose either wall as THE wall that blocked the missile. Once Doom has determined that A wall was hit, it doesn't bother to check if there could be a more-suitable wall in the block. Therefore, at times, the missile explodes inside the column.

Now, speaking of proof: I have done the work, and determined what I say to be true. Because of my first-hand knowledge of this, I also know that you have not worked it out. Which is ok. But, it's not ok to spread misinformation. If it's that important to you, and it appears to be, then set up some scenarios, modify some code to report on which wall was contacted, where the missile ends up, etc, and you see the effect.

[Foxpup]

kb1 said:

Indirectly, you are

No, I'm not. I'm specifically talking about this:

kb1 said:

in vanilla, this can cause missile explosions and smoke puffs to be drawn behind the wall, thus invisible, though usually you can still see some part of the explosion sprite peek through the pillar.

This is a completely false statement. This behaviour does not and cannot occur in vanilla. Or, for that matter, any port that hasn't futzed with the clipping code. I'm not talking about decals, I'm not talking about modified clipping code, I'm talking about missiles allegedly exploding on the wrong side of a wall in vanilla, which doesn't happen.

[kb1]

Foxpup said:

No, I'm not. I'm specifically talking about this:


This is a completely false statement. This behaviour does not and cannot occur in vanilla. Or, for that matter, any port that hasn't futzed with the clipping code. I'm not talking about decals, I'm not talking about modified clipping code, I'm talking about missiles allegedly exploding on the wrong side of a wall in vanilla, which doesn't happen.

Again, you didn't mock it up to see for yourself. I already gave you the benefit of the doubt, and tried to explain it to you. Maybe you don't shoot rockets at pillars. Maybe you just don't comprehend. Either way, now, you are just being rude. It's just not that important to me, whether you get it or not. I have better things to do. I'm done.