A_CyberAttack

Not sure if this has been reported (didn't find any mention from a quick scan), but for me this berserk in the hidden monster closets in MAP19 didn't teleport, preventing 100% items. RC5, played on Woof 14.3.0. PS: Congrats on the WAD, I'm having a blast playing it, everything but specially the map aesthetics is top notch :) PS2: Wow, MAP24 is incredible.

Great WAD, I love the short but intense map format, and the WAD feels coherent and balanced despite the variety of themes and authors. In general I found the more slaughtery maps at the end easier than the ones at the beginning where you're often suddenly surprised by a nasty trap. The only map that feels off is MAP10, it's too long, has too little ammo, the fights don't feel great and both the megasphere and BFG are tricky to obtain. But overall, this is a great mapset, good job to everyone involved :)

MAP02 Pacifist in 0:06 prcp202p006.zip

Great, I've been playing the first few maps and I'm enjoying it so far, so far the map quality is good :) Some notes so far, incl. images: - MAP08 has a corner where it's easy to get trapped (moderately hard to get out) - In MAP01 the red key room can easily be skipped by jumping through the huge window - In MAP02 you can cut straight through the end by squeezing in this place

While this topic explains how the classic E2M6 glide and similar ones work, there are some other glides which I didn't understand at first: * The new E2M6 glide which is on a different corner and uses a rocket boost, as seen for example on the E2M6 0:17.97 by Zero Master: https://dsdarchive.com/files/demos/doom/45940/e2m6p017.zip * The demos where you can void glide on the corner between an angled wall and a non-angled (horizontal or vertical) wall: https://www.doomworld.com/forum/post/2340506 (uses -turbo) and https://www.doomworld.com/forum/post/1348983 (no -turbo) The conceptualization to understand those demos is that doing a void glide consists of two parts which you can see as independent: Build up a lot of speed (near MAXMOVE=30 in one or both of the X and Y axes). Hit the corner where the two walls meet in a very precise way. When you do the glide between two 45º angled walls such as the E2M6 glide, you get both parts at the same time, as hitting that corner will allow you to build speed, and after you have built up enough speed, you just need to get lucky to hit that same corner in the right way. Also in this case you also benefit from the wall running "double-TAP" bug mentioned in the OP by Linguica which gives you a lot of leeway in how you hit the corner. However, looking at both parts separately allows you to explain a wider variety of glides. -- (1) Build up a lot of speed (near MAXMOVE=30 in one or both of the X and Y axes). You can't get a speed near 30 by doing a normal SR40 or SR50 input, you need help from other sources. However, there are various other ways that I can think of to get to a speed near 30 in one or both axes: Getting trapped between two angled walls like the ones in the classic E2M6 void glide -turbo cheat (of course, this is cheating, but this is great to test) Sliding against specific angled walls will build speed near 30. For example the one in TNT Map32 you can see in this demo: https://www.doomworld.com/forum/post/1348983 . Note that this is NOT the same as the "wall running" trick mentioned in the OP by Linguica, when you are "wall running" you are moving very fast, but it's because the game is moving you twice in a tic, not because your actual speed is high. Only specific walls have this property where you can build high speeds by sliding, most walls will either have a speed cap below 30, or eventually "eject" you and cause you to lose speed if you try to slide against them. Damage boosts (from enemies or your own rockets). Doing it this way you will only get near 30 for a tic, since you will lose speed very fast due to friction. (However, if you are in the air, you will get no friction, so you can keep the speed for many tics, but you will lose control of your character. Due to this it will be very hard to do a void glide this way, I haven't seen any demo using this.) -- (2) Hit the corner where the two walls meet in a very precise way. Ideally, you should hit the intersection where the two walls meet in the following way: Obviously, the tic you want to glide out, you should hit the sliding wall at the furthest point you can in the axis you want to glide out. Unless you are TASing a demo, the point of the sliding wall you will hit is basically random, so you just need to try over and over. Your speed should be as parallel to the sliding wall as possible, otherwise some of your speed will be lost. Your speed should be angled with one of the angles where you get a speed boost due to the P_AproxDistance approximation, see the OP by Linguica. This is absolutely necessary since this is the only way your speed can rise from 30 to 32 and above. The wall you are NOT sliding against should block your movement, this way the P_SlideMove algorithm will do the boost by P_AproxDistance two times. This will always happen since you are hitting the intersection. Your X or Y speed should be positive, this way the "double-TAP" bug will let you move twice in a single tic so you can get up to four P_AproxDistance boosts in a single tic. Your position (i.e. your hitbox) should be as physically close as possible the wall. If you hit the sliding wall but you aren't as physically close as possible, you will lose a lot of speed, even as far as instantly going to zero if you hit the wall in the worst way possible (your speed is multiplied by a variable called "bestslidefrac" in the code which does this). Again, unless you are TASing a demo, this is basically a combination of random, and the method you are using to build up speed. The bad part is that often you can't control many of those factors, since you need to do this right after the trick you used to build up a lot of speed. The good part is that the amplification you get from a good P_AproxDistance boost(s) is huge, so as long as your speed is angled in the right way, you can miss a lot of those conditions and still glide out. -- With this in mind we can explain the two glides: In the E2M6 0:17.97 by Zero Master, the method to build speed is to get trapped between the two angled walls, this works similarly as the classic E2M6 glide. However, unlike the classic E2M6 glide, getting momentum by getting trapped between those two angled walls does not automatically glide you out, because the speed vector is still not good enough to glide you out when meeting the intersection of the two walls (since the walls are not angled at 45º, he doesn't get to 30 speed in both axes, but only in the X axis). By getting damaged by a rocket in the right way, he gains more speed, and the way he hits the intersection where the two walls is more favourable (given the above conditions) and he can glide out. In the TNT Map32 Void Glide, the method to build speed is sliding against a specific angled wall, this will get a Y speed near 30. However, unlike in the E2M6 glides and the explanation by Linguica, there's no "positive feedback loop" at all at the interesection of the two walls here. Instead, it is simply of trying over and over until I get very lucky so that at the last tic of the run against the angled wall, I hit the very end point of the angled wall, I get a boost by P_AproxDistance, and my Y speed goes over 32, which allows me to simply glide out against the other wall which is perfectly horizontal. (If I missed the trick here, I would simply stop dead in the tracks, there's no "wobble" at the intersection).

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

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.

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.

As a test I made the code above unconditional, and while it doesn't have any noticeable effect on uses, it has pretty noticeable effects on movement, for example momentum is always preserved when running against axis-aligned walls and wall-running is very easy. I haven't looked much into it but my guess is since walls are 0 units thick, shifting the x or y coordinate a mere unit makes various checks in the movement code fail to detect the wall. As I said it's probably nothing, as forcing this code to always execute is very artificial, even if it were useful you would need help from the map's architecture and either to find a way to get consistently aligned with the blockmap for various tics or find some place where failing a single check could be useful.

BTW I can't be the first one to notice this and this probably isn't useful, but I noticed the following code in P_PathTraverse: if ( ((x1-bmaporgx)&(MAPBLOCKSIZE-1)) == 0) x1 += FRACUNIT; // don't side exactly on a line if ( ((y1-bmaporgy)&(MAPBLOCKSIZE-1)) == 0) y1 += FRACUNIT; // don't side exactly on a line trace.x = x1; trace.y = y1; trace.dx = x2 - x1; trace.dy = y2 - y1; It appears that this code gives you an extra unit (which is absolutely microscopic) of reach when trying to use something, as long as you are completely aligned (to an insane level of precision) with one of the blockmap axes.

I was looking into this and I think I have a pretty good idea why it happens. This is probably already known but just in case someone stumbles upon this topic and is curious. P_InterceptVector is a function to calculate the distance of intersection between two lines/vectors, the first parameter is related to the player position and angle and the second parameter is related to the line i.e. the switch. The parameters are set up in a way that the function returns a value <1 in case it's a hit, i.e. the switch can be used. I don't see anything wrong with the formula the function uses per se, however, as mentioned by Linguica, the function does some bit shifts (>>8), I believe to avoid overflow issues. If you look at those bit shifts from a mathematical point of view as if they were divisions by 256 the result of P_InterceptVector wouldn't change, because they all cancel out. But since those are used over DOOM's fixed point numbers, a bit of the precision of the number is thrown away. Additionally, since for example in DOOM2 MAP07 the switch is hit almost perpendicular, both the "num" and "den" variables that are computed by the function are very small numbers. This causes the division that is done in the function to amplify the numerical error caused by the bit shifts. For example in the demo by Looper (no07-113) he would not have hit the switch if the P_InterceptVector calculated results in a mathematically accurate way. However this is not all, for example in the demo by eLim (lv07no457) even if P_InterceptVector calculated the distance correctly, he would still have hit the switch. So there must be something else. I am not 100% sure about this, but I believe the problem is in P_UseLines, it uses the "finecosine" and "finesine" arrays to calculate the pair of points that are used for the vector of the player's position and angle. I think it's known from squeeze glides that those tables are inaccurate. This also causes more numerical error which also contributes in actually hitting the switch (I think this actually helps more than the error in P_InterceptVector, I believe). It would be really interesting to see if other numerical errors could be useful!