Vanilla doom autoaim glitch/bug

[Watermelon]

I've always been wondering why in online ports that autoaim seems to really suck and not trigger, and after some testing with other members I found out why.


Apparently there is a 'dead zone' adjacent to the player where autoaim will not trigger for some unknown reason. Up close the angle required is small enough that it probably won't fail you, though the farther away you get, the wider the dead zone increases.



Take this [really horrible] image [I made really quickly] for example:


The arrow is the player, and the white cross is autoaim. If the player is on a higher platform (since he's above the crosshair, or in vanilla where the center of the screen would be), if you aim at a player who falls under the red lines at the top, autoaim will not fire. However, if it's in the green zone it will fire.


You can try it yourself with this wad:
http://dl.dropbox.com/u/87656485/AutoaimTest.wad



Why is this of interest?
It's an autoaim glitch it appears. This is probably not noticed as much in vanilla because monsters are slow, it's really hard to miss... and most monsters are usually on a horizontal plane anyways. Now in *online* play this is much more irritating because players are moving, juking, doing stuff to throw off your aim. Since this dead zone appears literally just outside the players sprite, it is really punishing when you have a slight miss (ESPECIALLY with the ssg), but seems to reward worse aim because if you have a major miss it will then lock on and hopefully the spread of the ssg will have caught them.
I don't know if this bug has been discovered or even solved yet, but it exists in chocolate doom, zdoom, gzdoom, odamex, zdaemon and zandronum.

Worth patching? I think so at least in zdoom or its derivative ports. Even though 99.99% of the community probably uses freelook though, it'd help the codebase in oda/zd/zan because duel compilations still use OS settings, and this is where the bug tends to hurt. I'd rather just use freelook in duels but purists freak out on that recommendation.

[Memfis]

Interesting. I made a video of this, it should help people understand what you're talking about.

[ASD]

Memfis said:

[vid]

Happens to me each time when shooting the above imps with the shotgun in E1M1.

[TimeOfDeath]

This is Doom. Players have been deathmatching with this "bug" for years. Changing it would make it different from Doom.

[Watermelon]

TimeOfDeath said:

This is Doom. Players have been deathmatching with this "bug" for years. Changing it would make it different from Doom.

That logic doesn't hold because freelook is different from doom, *insert all these bug fixes like the blockmap fix/visplanes fix/whatever here in newer ports* is "changed to be different from doom", but despite it being different, probably 95%+ of the active doom population plays these ports.

I mean, do people actually want to have an autoaim bug? What fun is it playing if your shot just misses because of a glitch?

[Phobus]

Apologies in advance for how vague and/or incorrect this is, as it's all being written from memory of other people's discussions.

This must be down to the blockmap bug (basically, how a map is divided up by Doom's BSP tree tends to mean that any actor being in more than one block is harder to hit due to only registering as in one of those blocks at a time). It's the same reason 1-shotting a Spider Mastermind is relatively difficult in vanilla Doom but very easy in ZDoom (which has this bug fixed).

[Graf Zahl]

Actually, it's a very good analysis of how the autoaiming code works.

It fires 3 traces, one at 0°, one at a small negative angle and one at a small positive angle (can't tell you the exact value in degrees, sorry) and looks if it finds something. Any target that's in one of the gaps will be missed, logically.

[printz]

Wow, awesome, I've never known about this!

[tempun]

http://doomwiki.org/wiki/Autoaim

[Gez]

So a "fix" could simply involve firing two more traces at the intermediate angles. The gaps would only reappear at very long distances.

[printz]

Would a continuous sweep be too expensive to perform?

[TimeOfDeath]

Watermelon said:

I mean, do people actually want to have an autoaim bug? What fun is it playing if your shot just misses because of a glitch?

I don't think it's a glitch. If you aim a bit further away from the player, the autoaim will kick in and the SSG spread might hit him. Why not adapt instead of "fix bugs"?

Raising limits in source ports and adding freelook etc. have contributed a lot to playing and mapping. But I don't know if changing the autoaim would add anything. Removing the dead zones will just make it easier to aim at/near your target when they are above/below you.

[Gez]

printz said:

Would a continuous sweep be too expensive to perform?

It'd make a single hitscan attack about 60% more expensive.

To give an idea of how horrible that would be, the BFG blast fires 40 hitscan attacks at once (120 traces), which means that if you can fire the BFG without getting an FPS hit, then you could fire 24 5-trace hitscans at once without getting an FPS hit either. :p

[qoncept]

I think that's pretty clearly an unintended glitch that should be fixed in source ports, with an option to disable for "purists."

To those who think it should be left alone

- Do you think id would have left it alone if they'd noticed while still maintaining Doom?

- What benefit does leaving it possibly have? I would say wall running and (maybe) strafe running are glitches that were unintended but add a new dimension to gameplay (particularly speedrunners). This autoaim glitch doesn't have any such benefits.

I really don't think fixing this glitch could have any negative impact whatsoever, unless you're DMing the guy that always misses by just the right amount.

[qoncept]

TimeOfDeath said:

I don't think it's a glitch. If you aim a bit further away from the player, the autoaim will kick in and the SSG spread might hit him. Why not adapt instead of "fix bugs"?

"Adapting" would mean aiming perfectly every time. It just doesn't happen. The way it currently works shows the original intent was for you to have, say, a 5 degree margin of error, NOT perfectly, and still aim at the correct plane.

The discussion of mouselook is a moot point. If you're using it the way autoaim works doesn't matter. FWIW, I never use mouselook.

[tempun]

Gez said:

To give an idea of how horrible that would be, the BFG blast fires 40 hitscan attacks at once (120 traces)

40 traces. Perhaps ZDoom changed it?

[tempun]

qoncept said:

"Adapting" would mean aiming perfectly every time. It just doesn't happen. The way it currently works shows the original intent was for you to have, say, a 5 degree margin of error, NOT perfectly, and still aim at the correct plane.

If you think so, write a patch demonstrating what code should have been different and explain what the exact error was.
Hint: corners were intentionally cut here.

[Gez]

tempun said:

40 traces. Perhaps ZDoom changed it?

They aren't autoaimed? Autoaim runs three traces per hitscan.

[printz]

qoncept said:

I think that's pretty clearly an unintended glitch that should be fixed in source ports, with an option to disable for "purists."

To those who think it should be left alone

Simple: it's a game feature (rule). It doesn't need by any reason to be changed as long as it doesn't break (destabilize) the game.

[Gez]

Plenty of things that do not destabilize the game have been changed.

For example, the sky never changing across episodes in Doom II unless you load a save? Doesn't damage stability in any way. Hitscan attacks warping through the blockmap instead of hitting an enemy? Not going to corrupt memory. Monsters unable to see the player if they are aligned with a vertex? It's not going to cause any sort of crash. Ouch face only showing if you're healed? This does not negatively impact the integrity of your computer. And so on.

[Mogul]

Watermelon said:

I mean, do people actually want to have an autoaim bug? What fun is it playing if your shot just misses because of a glitch?

Registered: 2012. rofl. Yes, believe it or not, some people actually like DOOM and don't want to fuck with any part of it unless it's absolutely necessary. It might be something a source port "fixes", but that will never become standardized play. As far as legitimate deathmatch goes (ZDaemon, Doom2.exe, perhaps Odamex...), this is one of those things that's never going to be touched. And it shouldn't be. Don't Lucas that shit. With one of the "who cares, let's mouselook and jump weeeee" ports like ZDoom or jDoom, there's probably a higher chance of this change going through, if it's not already.

[MP2E]

Instead of making 2 intermediate angles, would it be possible to find the angle of the 2 tracers based on how far the nearest Autoaim-able mobj is locate? This would create a variably "thinner" autoaim area vs traditional. And by getting thinner by distance, it makes longer shots more difficult.

But this fundamentally changes the way autoaim works. I don't think any fix would be universally accepted.

[NaturalTvventy]

I frequently notice this when trying to shoot barrels with a SG. The barrels require autoaim to hit, and when the shell spread whiffs right over 'em it's annoying. Fix that shit says I.

[cq75]

just coming in to say I support fixing this bug

[Technician]

Gez said:

Plenty of things that do not destabilize the game have been changed.

For example, the sky never changing across episodes in Doom II unless you load a save? Doesn't damage stability in any way. Hitscan attacks warping through the blockmap instead of hitting an enemy? Not going to corrupt memory. Monsters unable to see the player if they are aligned with a vertex? It's not going to cause any sort of crash. Ouch face only showing if you're healed? This does not negatively impact the integrity of your computer. And so on.

I agree. I'd like to see the bug fixed.

[tempun]

Gez said:

They aren't autoaimed? Autoaim runs three traces per hitscan.

They are vertically autoaimed. At least in PrBoom-plus, hitscan weapons autoaim is handled by P_BulletSlope, which calls P_AimLineAttack up to three times. A_BFGSpray just calls P_AimLineAttack once per trace.

[tempun]

Just saying I'm strongly against removing this feature. If you want to hit your target, aim better. If you don't, well, it's a lottery. Doom always had random damage even for direct hits, so why not allow randomness here too?
Can't aim? Get a triggerbot.

[qoncept]

tempun said:

Just saying I'm strongly against removing this feature. If you want to hit your target, aim better. If you don't, well, it's a lottery. Doom always had random damage even for direct hits, so why not allow randomness here too?
Can't aim? Get a triggerbot.

Features are intended. Autoaim working beyond the "gaps" shows this was not intended. Pretty clearly an unintended glitch. Gez just listed a handful of similar, very minor bugs that have been fixed in source ports. I would argue that this one impacts gameplay even less AND makes even more sense to fix than those.

tempun said:

If you think so, write a patch demonstrating what code should have been different and explain what the exact error was.
Hint: corners were intentionally cut here.

Nice. Your proof that I'm wrong is that I'm not willing to take the time to learn a new programming language and dig through the source code to make a change.

Hint: Whether I want to use my limited free time to make this change is not indicative of whether it's a good change.

[Quasar]

This is less of a glitch and more an obvious consequence of what was a cheap, simplistic way to implement autoaim. When you send out three tracers in a spread, it is trivially obvious that there are gaps. They knew this. They accepted it as good enough and, most importantly, fast enough at the time given the hardware restrictions that were in place.

[Gez]

tempun said:

A_BFGSpray just calls P_AimLineAttack once per trace.

Ah, okay. Anyway, it's still 40 traces at once without framerate suffering that much, so having P_BulletSlope call it up to five times instead of three wouldn't change much on the performances front.

tempun said:

Just saying I'm strongly against removing this feature.

Calling an oversight or side-effect a feature doesn't make it one. A problem formally detected nearly 20 years after the game was made can very well be considered a bug rather than something deliberately designed to have this effect.

I personally don't care either way if port maintainers decide to leave things as they are or tweak it (possibly as an option) to reduce the gaps, as the gameplay impact would be minimal to the point of near inconsequence anyway. (See also: problem detected nearly 20 years after the game was released.)