Jump to content

Recommended Posts

Hi, folks! Could you please explain or share your thoughts on that weird glitch when a monster gets stuck in an open doorway and stands dead on its tracks until something makes it change its movement direction (like a gun shot or a different player's position)?

 

Here is a video that shows the glitch. Watch the imp!

Edited by Dimon12321

Share this post


Link to post
  • 3 weeks later...

This is awesome and I am still figuring out what happened.

 

The demo plays back with hr2final.wad, it is MAP28, played with a couple of saves, so cheated.

 

First, -skipsec 505, you have a nice instance of a cyber getting stuck. Were it not for the second one interfering, two pinkies would have eaten the first one alive. Still, nice, HP dropped to 1600.

 

But this alone would not make me upload this.

 

-skipsec 916 is where the fun begins. This is my interpretation, which may be wrong.

One of the revs or chaingunners is resurrected as an arachnotron (!), then this arachnotron climbs very steep stairs (!!) which it wouldn't even fit due to its size, sneaks behind my back and kills me.

noway.zip

Share this post


Link to post

@vdgg that's just a ghost monster from corpse of an Arachnotron you killed around 12:15 mark. Also nice to see you tackling MAP28, can't wait for your final demo.

 

I'll throw one demo of my own: from my BTSX1 D2ALL attempts. I got an all-ghosts glitch in MAP02, in the absolute last place I would ever expect to get it. What the hell could have triggered that? -skipsec 430 for the moment

b1all-allghosts.zip

Edited by tchkb

Share this post


Link to post
  • 4 weeks later...

Has anyone ever wondered why sometimes we hear like a fireball crashes on a wall outside of the map, even if we've already killed everything about two minutes ago? May be no news for some people, but this bugged me for years. I just recently incidentally captured that occurrence with my eyes in a demo and felt like sharing the moment.

 

Runs with garrulo.wad, garrulo.deh, it's Garrulismo btw, map 15, not that the map slot really matters. Turn on IDDT x2, skip to 10:15 where you'll see two mancubus fireballs clipping (the second in a more straight line) and about minute 12 you can watch it come close to my position from the other opposite of the map. Now I get it, it bugged me because I could swear it happening in doom 1 too, though that could have been baron snot.

 

Link

Share this post


Link to post
  • 2 months later...

Can someone explain to me what happened at the end of this demo? I was trying to go up a lift and all of a sudden my view turned into a HOM effect and an imp clawed me to death.

planisf2-glitch.zip

-skipsec 2880

Runs with the version of planisf2.wad shared in this post (the version on /idgames is an old version that doesn't have nodes built).

 

Edit: Never mind, I think it was the all-ghosts bug. Just had another attempt result in all-ghosts in the same area...

Edited by Shepardus

Share this post


Link to post

Well, something even weirder happened: I was being crushed but took no damage. This map in general is... mysterious. Plays back with sunlust.wad and use -skipsec 55 for your convenience.

invulcrusher.zip

2 hours ago, plums said:

Yeah that looks like it. In this demo, I was on the edge of the sectors too, maybe that's what happened.

Share this post


Link to post

@Starduster I believe this is what happened:

 

"The player's health cannot drop below 1% while within this type of sector, a fact that has strange consequences when the player is not touching the sector floor – so long as the player's mid-point remains in such a sector, he becomes essentially invulnerable after his health is reduced to 1%, but will not exit because that check is only made if he is on the floor."

Share this post


Link to post
1 hour ago, Shepardus said:

@Starduster I believe this is what happened:

 

"The player's health cannot drop below 1% while within this type of sector, a fact that has strange consequences when the player is not touching the sector floor – so long as the player's mid-point remains in such a sector, he becomes essentially invulnerable after his health is reduced to 1%, but will not exit because that check is only made if he is on the floor."

Ah that makes more sense, thx. I remember that bug getting exploited in Sunder map14 (skip to 7:32):

It is so strange that I had both of those weird things happen on the same day. 

Share this post


Link to post
  • 3 weeks later...

IIRC, aggroing is tied to pain animation. A single rocket only has two chances of triggering it: from the rocket itself and from the splash damage. Which is more than most attacks in the game, but still not a lot.

Share this post


Link to post
  • 2 months later...

Fell through the floor to the void, how it's possible?

Probably due to lowering wall, but I can't replicate it by suiciding.

eternal doom map 12, -skipsec 55.

 

 

Edited by GrumpyCat

Share this post


Link to post

@GrumpyCat, maybe it will sound stupid, but I didn't see this anomaly. I can assume it's a flag problem with some sector. In other words, mapper's mistake.

Edited by Dimon12321

Share this post


Link to post

I mean, player's z position went below the floor (look at the medikit), normally it never happens.

 

EDIT I am idiot and included wrong .lmp, sorry!

This is the right one.

 

et12-below.zip

Edited by GrumpyCat

Share this post


Link to post
  • 3 weeks later...
  • 3 weeks later...

A strange demo on 32of64-lr where I shoot through several gunshot doors in a single shot because of a monster in the bullet path. Not 100% on why that happens, it doesn't seem like a blockmap bug because the blockmap line isn't in that location. This is included as part of the demo pack, wanted to cross-post it here to see if anyone could figure out what happened. :P

64l34pwhat.zip

Share this post


Link to post
16 minutes ago, 4shockblast said:

A strange demo on 32of64-lr where I shoot through several gunshot doors in a single shot because of a monster in the bullet path. Not 100% on why that happens, it doesn't seem like a blockmap bug because the blockmap line isn't in that location. This is included as part of the demo pack, wanted to cross-post it here to see if anyone could figure out what happened. :P

64l34pwhat.zip

It looks like both the pistol shots are shot very low, close to the ground (or maybe *under* the ground?). You can see it if you pause the demo just as the player takes the 2nd shot, and spectate on the other side of the doors. The bullet puff is very low. So maybe the hitscan line went under all the doors because of the auto-aim doing a vertical-near-miss when the player shoots close to the Specter? I have no idea why it would happen or why it would shoot down in that case. Really weird this one.

Share this post


Link to post

The bullet puff always snaps to the lowest point of the wall in classic engines, even if the shot is aimed at the floor. I don't know what implications it has for how the actual tracer behaves, however.

Share this post


Link to post
  • 3 months later...
  • 2 weeks later...
On 11/17/2020 at 8:20 AM, GrumpyCat said:

I mean, player's z position went below the floor (look at the medikit), normally it never happens.

 

This is a nodebuilder bug. In sector 411 there is a "crack" which projects northeast around a continuation of line 2095. Despite its knife-like thinness you were (un?)lucky enough to fall into it exactly. Inside, the game thinks you are in sector 425, 16 units lower.

I've heard cases like these are created by a ZenNode bug which is triggered by having two lines that are almost but not exactly collinear. For example when a single line is split and the new vertex has to be rounded to integer coordinates. There is a similar flaw near the start of Plutonia map25, in sector 4 projected west from line 72; the sergeants around there sometimes fall in it.

Share this post


Link to post
  • 2 months later...
On 3/2/2015 at 10:32 PM, Looper said:

Heh, Doom1 E2M1.

Turbo was used.

ripdoom.zip

 

This is really interesting, as with help from the level geometry one could build enough momentum using rocket boosts in-air (no friction) in order to avoid turbo. Not sure if a single boost would be enough, maybe if the angle of the sliding wall is good enough.

 

However having everything line up to hit the exact point the walls meet with as much momentum as possible parallel to the sliding wall would be really tricky with this method, and probably needs even more help from the level to even make it possible.

Edited by A_CyberAttack

Share this post


Link to post
On 12/25/2020 at 7:12 PM, 4shockblast said:

A strange demo on 32of64-lr where I shoot through several gunshot doors in a single shot because of a monster in the bullet path. Not 100% on why that happens, it doesn't seem like a blockmap bug because the blockmap line isn't in that location. This is included as part of the demo pack, wanted to cross-post it here to see if anyone could figure out what happened. :P

64l34pwhat.zip

 

The shot that opened the multiple doors was aimed at the spectre that was to your left, but it missed (the game first does a check for where to aim with a wide angle range, then does the actual bullet shot, so it's possible that you try to aim to a specific demon, but then you miss. I guess this is done so the bullet puffs appear near the demon).

 

Both the player and the spectre are in the same Z coordinate and are the same height, but the pistol is shot from slightly above the middle of the player height and towards the middle of the spectre, so the bullet goes downwards, in fact you can see that the bullet puff from the shot that opened the multiple doors hits the floor before the doors.

 

However, since you missed the demon so it didn't stop the bullet, the game checks the next bullet intercept, which is one of the doors (the game doesn't care about the Z coordinate when looking for intercepts, it's just as if you it drawed a line over the automap).

 

The code to handle the collision with the door's line actually checks the Z coordinate and it correctly detects that the bullet flied too low ( https://github.com/chocolate-doom/chocolate-doom/blob/c3e9173772e07ee21f3cea39fd6e3935ed95a02c/src/doom/p_map.c#L984 ) so it detects it doesn't hit.

 

However and this is where the glitch comes, for some reason the code for special line effects such as doors opening comes before the check for the Z coordinate ( https://github.com/chocolate-doom/chocolate-doom/blob/c3e9173772e07ee21f3cea39fd6e3935ed95a02c/src/doom/p_map.c#L949 ). So the game still opens the door.

 

Since neither the demon nor the door stopped the bullet it goes to the next door and the same thing happens, the game opens the door, detects the bullet flied too low, and continues with the next intercept.

 

-

 

I can get the glitch to happen with some consistency by reproducing your scenario: try to get the spectre to my left, then intentionally shoot the pistol to its right, so I miss the spectre but the bullet is still aimed for it.

Edited by A_CyberAttack

Share this post


Link to post

TNT Map32 Void Glide ( -skipsec 60 ).

This is similar to looper's ripdoom.zip but with no -turbo.

I got the speed by running against an linedef which is angled in a way which lets me get to Y=-30 speed and then get lucky to hit near the corner of the wall with max speed and get some extra momentum from the glitchy slide algorithm.

Not hard to do if you like to run into a wall for an hour.

ev32-wallglide.zip

Edited by A_CyberAttack

Share this post


Link to post
  • 3 weeks later...

In my Avactor MAP01 demo, at 6:34, I took a 20-damage attack from an arch-vile since the blast damage portion got absorbed in an adjacent pillar. I've seen this before with ledges and small pillars that can contain the blast without blocking line of sight between the arch-vile and the player. However, this is a full-height pillar spanning from the floor to the ceiling, so I'm not sure how it managed to block the blast damage without also blocking the hitscan damage.

Share this post


Link to post
On 7/15/2021 at 3:10 AM, Shepardus said:

However, this is a full-height pillar spanning from the floor to the ceiling, so I'm not sure how it managed to block the blast damage without also blocking the hitscan damage.

 

This is a combination of usually-irrelevant consequences of the A_VileTarget fire cloud spawn position bug, which here leaves the cloud at a ridiculously out-of-range z-coordinate, and your movement blocking and opening the line of sight to the archvile with miraculously precise timing (to a single tic). This prevented the erroneous z-coordinate being corrected, while still allowing the attack to complete. Here is a poorly-edited-for-verbosity timeline of events.

leveltime 13743 (T 0)

In A_Chase, P_CheckMissileSpawn chains the archvile into an attack. Let's call this Time Zero as a reference point.

leveltime 13753 (T+10)

A_VileTarget is called. It spawns the fire cloud at the target's (your) (x,y,z) coordinates. Then calls A_Fire which repositions the cloud 24 units away in front of the target's eyes.

There is a bug here in old engines. The initial spawn incorrectly passes the x-coordinate as the y-coordinate, a trivial copy-paste error. Since the flame is immediately repositioned, the bug persisted until it was fixed in MBF.

The fire cloud which was meant to be spawned at (-2810,1421,-288) in sector 1805 is thus spawned at (-2810,-2810,-288). This is in sector 351, halfway up a pyramid on the other side of the map. The floor height there is 392. This value is cached in the fire cloud actor's floorz field as the current floor height underneath the actor.

leveltime 13754 to 13807 (T+11 to T+64)

The archvile goes through its attack animation as normal, doing nothing much but turning to face its target. The fire cloud, every two tics, is repositioned by A_Fire, 24 units in front of your face, except sometimes when it detects line of sight between vile and player is blocked. On those tics the fire remains where it is.

The fire cloud is still processed by P_MobjThinker as a normal thinker, every tic. In particular it passes through P_ZMovement which notices the flame's z-position (around -288) is below its cached floorz value (392), which is what P_ZMovement thinks (has been fooled into thinking) is the current floor height under the fire. So P_ZMovement moves the fire up to height 392, every tic. On half of those tics, A_Fire then immediately moves it back down again, provided there is still line of sight between vile and player.

[ Why is floorz wrong? Archvile fire clouds do not use any of the usual machinery to move around. They are just picked up and plonked down wherever A_Fire feels like. In particular P_CheckPosition, which would recalculate floorz, is never used. ]

Also towards the end of this period you hit the vile with an SSG shot, which doesn't interrupt it, but does knock it back a bit.

leveltime 13808 (T+65)

This is the last chance A_Fire has to fix the cloud position before the vile explodes. And it fails! P_ZMovement kicks the fire cloud back up way above the ceiling, but A_Fire's final line of sight check passes (to within rounding error) exactly through vertex 9746, at (-2688,1824). So as this tic ends, the fire is way up in the void above the ceiling of the room.

leveltime 13809 (T+66)
 

The first relevant thinker to be processed in this final tic is the archvile. Usually in maps the player is thing 0 so is first in the thinker list but in maps with lots of voodoo dolls the real player ends up having a high number (1532) than the archvile (thing 533). Firstly the usual movement rules in P_XYMovement are applied: momentum from the SSG shot from earlier pushes the vile a fraction of a map unit, but enough to regain line of sight between vile and target.

Then finally 66 tics after it started winding up, the state changes to call A_VileAttack. Now line of sight has been moved out of the vertex, the routine proceeds and the target (you) takes the mandatory unavoidable 20 points of damage.

Immediately next P_RadiusAttack attempts to apply the splash damage. But it fails! Line of sight between the player at (-2666,1864,-272) and the cloud at (-2678,1843,392) is blocked by line 11657 - the fire cloud is hundreds of units into the void above the ceiling of sector 1917!

leveltime 13812 (T+69)

The attack ends. The fire, whose position is now utterly irrelevant, does get one or two more passes through A_Fire to get it back down from the gods but it is too late. You get away with only 20% damage. Not 0% as you were a vertex width away from achieving, but also a lot better than it could have been.

Reproducing the effect

The requirements are, firstly, given a target at (x,y), the floor height at error coordinates (x,x) must be far above the ceiling height at (x,y).

Then you need a 2s linedef with a ceiling height change (of any magnitude, one unit can be enough) between the coordinates of the player and the explosion point when the attack completes. (Presumably this would work the other way up: spawn the fire cloud well below the floor, have a 2s floor height change as a blocking line.)

Finally line of sight must be blocked sometime after the flame is spawned at T+10, up to and including T+65. Then opened precisely on T+66.

In your demo, line of sight was only blocked for a single gametic, T+65, by the width of a vertex, which I found astonishing. But it is not necessary: only the unblocking on T+66 which must not happen even a single tic before that.

I leave it to others to weaponise this effect intentionally in a speed run. Alternatively I might imagine a fiendish challenge puzzle where the player must take a 20% archvile blast to reach a goal: the full splash damage would kill you or otherwise result in failure.
 

Spoiler

nlSs8Ba.gif

Here the player strafes out from behind a single-unit-wide red pillar at precisely the right moment. Previously the fire cloud had been spawned inside the column to the right before the player made a very tiny movement to hide behind the red line. (There is also a one-unit ceiling height difference in a small sector above the player which cannot be seen from this angle.)


 

Share this post


Link to post
  • 3 weeks later...

In my Sinergy E2M8 max the level ends instantly after the last Cyber dies, as in there is no 2-3s delay that typically occurs. @RjY or anyone else have an idea why this happened? Something to do with killing the last two Cybers in such a quick succession?

Share this post


Link to post

Yes, this is a known phenomenon with tags 666 and 667, and deliberately exploited in many shorter demos where they come into play.

 

Ryback's post here explains it in the context of E1M8.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...