Talk:Dead player's line of sight tracks his killer


Does this really count as a bug? It strikes me as one Doom's many unreal-isms rather than a bug. -- TheDarkArchon 22:06, 13 September 2006 (UTC)

Well, you know how you only see the front of any object and not any of the sides or back ('cept players and monsters since they actually move around)? I guess you could say that the line of sight moves because it's repositioning it for the player who killed you... though... it wouldn't matter for the other players cause they'd see the font of you anyway... I dunno, it's difficult to explain, but I'd say it's a bug. --Frusion1021 22:22, 13 September 2006 (UTC)
There are a few borderline cases, certainly.  And in the absence of comprehensive firsthand accounts of the engine's development (I'm not holding my breath), there will always be room for debate.  For example:
  • A long fall makes the player say "oof" even if his health is zero.  Colin Phipps has called this a bug, but on the other hand it is medically accurate IIRC (there can even be reflex motion of a person's limbs after brain death).
  • Monsters gibbed by blast damage seem to fly in an arc through the air for a prescribed distance, then stop and fall straight down like Wile E. Coyote.  I think of this as an unreal-ism (especially considering the technology of the time), but some source port programmers apparently consider it a glaring oversight which must be expunged from the earth.
  • The nonlinear AI phenomena described in Monsters fleeing and Lost Soul charging backwards have been called bugs by many technically minded people on this site.  On the other hand, none of us has ever met a demon IRL (I don't think), so how do we know how much common sense they should have?  Maybe id programmed it that way on purpose.
The description in Bugs says "bugs, limitations and oddities", which I take to mean "if in doubt, write it up".  I agree with this, if for no other reason than that almost every anomaly turns out to be useful somehow!  For instance, in a one-on-one deathmatch, this effect could reveal which direction your opponent ran in after killing you, so when you respawned, you'd know roughly how close he was.    Ryan W 23:44, 13 September 2006 (UTC)

This is not a bug.[edit]

This is a deliberate feature of the game engine which has a large segment of code in the function P_DeathThink dedicated to its implementation, complete with comments to the effect of "Looking at killer." There is no way by any definition of the word bug that this qualifies as one. Unrealistic? Maybe. But so is everything else in DOOM. Shall we next claim that being able to run fullspeed while carrying all your weapons, armor, and items is a bug rather than a design feature? Treading on dangerous territory here. I will post the code if necessary, but for now I'm putting an accuracy dispute template on this.--Quasar 02:31, 18 September 2006 (UTC)

I think I agree with the first half of this.  Splarka will wonder how I can say that, but the difference here is the evidence of intent in the code; the monster flag conversation is almost entirely speculation.  If I had known about P_DeathThink when I made this list (maybe I should know exactly where to look for such things, but I just don't yet), I probably wouldn't have bothered to start this article.
#ifdef SOAPBOX
Cataloging engine bugs on this wiki is complicated by two factors.  First, we have no explicit guidelines about how broadly to interpret "limitations and oddities".  It could include every known quirk of game physics, including the "encumbrance" phenomenon you mention (which was addressed in Doom 3 and in the movie) and the trajectory weirdness I describe above.  It probably doesn't include those things, but until there is a more thorough and visible debate, we can't claim to have stated our intentions clearly.
The second point is one of programming philosophy, Doom engine or no Doom engine.  Suppose that the visible sprites limit is common knowledge in the mapmaking community.  There is then a difference between a designer
  • carefully assembling a level so that the limit can't possibly be relevant (e.g. MAP01 of Doom II);
  • being unaware of the limit and having it affect gameplay in unforeseen ways;
  • seeing the flickering during testing, but deciding that it has no substantial effect on gameplay (which must have happened with this level); and
  • deliberately using the effect to make a level harder (I really wonder about MAP13 of NJDOOM2.WAD).
In the second case, we can call the designer slipshod, but in the other three situations we have to ask whether or not the limit is a bug.  Some people, apparently, would say no.  They would say that a mapmaker has no right to take "locked door" linedefs at face value, and must plan accordingly.  That strikes me as unfair.
Dangerous territory?  Of course.  Such are the perils of trying to become an authority on the code, which is one goal some editors have for the wiki.  If the problem is deemed inherently subtle, fine, but then we will be having this type of discussion quite often as the technical articles become more numerous.  IMHO these issues will become easier to untangle as we accumulate genuinely knowledgeable contributors such as yourself.
I personally would love to see a more explicit policy, because I am not as smart as Fredrik and Fraggle and will undoubtedly do this again otherwise.
Ryan W 15:49, 18 September 2006 (UTC)
You make some good points. While the vissprite limit was an intentional part of the game, its behavior strikes the user as a bug in the end, due to how annoying it is. It may be by design, but the design in that case was flawed. I'm not sure if we could derive any firm guidelines, but it couldn't hurt to try ;) --Quasar 05:39, 19 September 2006 (UTC)
Exactly.  ("Cheated demo" is also an ill-defined concept at times, but that doesn't stop the COMPET-N people from trying.)    Ryan W 12:29, 19 September 2006 (UTC)
So I'm not sure what the outcome of this discussion is. Can we delete this yet? :-) Fraggle 15:00, 14 March 2007 (UTC)
You say that as though you suspect I have an opinion.  :>   I think it should be deleted if people agree with Quasar's reasoning (which is supported by the code, of course).  I would rather have a VfD than just get rid of it instantly, however, because I don't want a precedent for deleting every article about a bug someone thinks is "intentional" (see edit summary written by whoever removed this from Bugs).  One could plausibly argue that all the overflow-related bugs are intentional, because implementing range checks is a completely straightforward procedure — or so I am assured by people who know C — yet id chose not to do it, presumably in the interest of increased speed.    Ryan W 17:59, 14 March 2007 (UTC)
I don't see how that makes this a bug. Range checks don't really produce bugs, they produce limits. This is an intentionally designed feature that was deliberately added into the behavior of the game. If this is a bug, then arguably, so is the behavior: "when you press on a door, it opens". Fraggle 18:09, 14 March 2007 (UTC)
Er, no, I mean using range checks to *prevent* bugs, such as the all-ghosts bug.  Some cases may be more complex than just counting things, of course.    Ryan W 18:35, 14 March 2007 (UTC)

Should this be noted[edit]

I've only had this happened when I've been gibbed. (With something like a rocket launcher or BFG) —The preceding unsigned comment was added by (talkcontribs) .

Um... did you watch the demo?    Ryan W 20:37, 27 January 2007 (UTC)

Nominating for deletion[edit]

I'm nominating this for deletion based on the fact that it was created under the assumption that it is a bug, and I don't believe this is a bug. It is an intentionally designed behavior of the game. Fraggle 18:12, 14 March 2007 (UTC)

Delete. Fraggle 18:12, 14 March 2007 (UTC)
Agreed. Delete. -- Janizdreg 00:16, 21 April 2007 (UTC)
Keep, though it shouldn't be classed as a bug -- TheDarkArchon 22:26, 21 April 2007 (UTC)

Keep, perhaps move. Not really a bug.