Talk:Blast damage has unlimited vertical range

Not really a bug?

If it was a bug, shouldn't they have tried to fix it instead of making it part of the game? Once it becomes part of the game, shouldn't it become not a bug at all? You might as well list damage from the green and red floors if something used in the game (Commercial Doom, not a custom wad) counts as a bug, where is the line drawn? B10Reaper 18:51, 16 December 2008 (UTC)

[IANAP]   A few things are fairly unambiguous because they crash the program or make the mouse stop working or something, or because there's actual evidence that they were unintentional (comment in the code, old newsgroup post from id, list of "bugs fixed" in a later readme file).  Others are included because people have taken the time to study the source code carefully, mostly while writing ports, and formed a general consensus to interpret certain things as imperfections (e.g. slime trails, spechit overflow, blockmap traversal algorithm).  What people have disagreed about, in this wiki, is whether we should describe something as a bug simply because it doesn't match real-world physics (e.g. wallrunning, lost soul charging backwards, rocket passes through the player who fired it).

Is that what you're saying?  Or are you saying that Venetian blind crash isn't a bug, because it was included in the commercial release, therefore the programmers must have done it on purpose?    Ryan W 12:41, 18 December 2008 (UTC)

no no, part of the game. The vertical explosion damage, it is in the game to kill the final boss in doom 2. That makes it part of the game, just like the damage you take from the slime is not (and was never) a bug because it is used in gameplay. Without the unlimited blast damage range, the final boss in doom 2 would have been different, but being in the game such as it is, and used in the gameplay, It shouldn't really be counted as a bug. Also, I have to laugh about the real world physics part, in a game where toxic waste explodes when you shoot it, stuff teleports from hell, and blue/green/brown orbs with faces in them, that float, give you health and armor. But anyway, this "bug" was used in a commercial release as part of the gameplay, not just included but used to win the game, with no other way (besides idclip). That is why I am questioning the validity of the "bug". B10Reaper 21:43, 18 December 2008 (UTC)

That's an interesting line of reasoning.  There was a lot of stuff intentionally programmed sloppily for speed reasons however, so maybe they'd already decided to compute distances without the z coordinate (IIRC Masters of Doom says the details of the head were only finalized at the last minute), and were just making a virtue of necessity.

Also, I have to laugh about the real world physics part, in a game where . . .    Yeah, that's my opinion also, and I've advocated being fairly inclusive, at least for now, about which anomalies we write about.  (Engine bug is introduced as a list of "bugs, limitations, and oddities" to make this clearer.  For example, if an array overflows and causes an exception, that clearly means they knew about the limit and chose that method to address it.)  One of the first bug articles to be written on this wiki was Ouch face, which is a totally cosmetic phenomenon with no effect on gameplay whatsoever, and yet somehow five hardcore Doomers got together and all agreed that it was really important to document it.  :D     Ryan W 15:29, 20 December 2008 (UTC)

lol well, the ouch face was meant to be there, but it doesn't work the way it was intended, I would think that is a bug even if it doesn't affect gameplay, much like the hall of mirrors effect. Little things that do not actually affect the game, but that should work the same everywhere, might qualify as a bug, just because they are an actual mistake in programming. Imagine if the double barrelled shotgun reload animation didn't work half the time? I would be slightly upset. Unless the story went "Oh, by the way, the demons made your shotgun spontaneously refill your shells once in a while" then it would be a bug. I still don't understand this as a bug, but oh well. B10Reaper 08:26, 21 December 2008 (UTC)

Many bugs have become part of the game, even errors. How much may depend on the players concerned. Some prefer to use the original executables to experience all the original bugs, other use engines with many fixes. A bug is either an evident error (not this case) or something that may be seen as an oddity (as this one). In this case, people may find it odd that they get damaged by a blast occurring far below at a great distance, and not by a much closer blast occurring at a vertical distance. Most bugs of this sort are marked as "disputed" because they might not be considered a bug by everyone, unlike errors or critical problems would. I would agree that changing this bugs status from "undisputed" to "disputed" in Engine bug under Canonicity may make sense. If we argue that such a bug is "undisputed" (which means it's objectively seen as a bug), things like the lack of true 3D floors and the inability to jump or crouch may as well be added to the list of bugs. The phenomenon is objectively verifiable, but whether it's a bug is subjective. We do add the more subjective bugs, but it's necessary to note that they aren't absolute bugs. Who is like God? 11:25, 22 December 2008 (UTC)