Difference between revisions of "Talk:Rocket passes through the player who fired it"

From DoomWiki.org

(Re: "The original problem should have been fixed by . . . ")
(although those hadn't been invented -> although in id's defense those hadn't been invented)
Line 22: Line 22:
 
: Any trade-off between realism and playability is IMHO an artistic rather than a deductive issue, so there isn't one right answer.  I can't recall why I used such strong language above, but I still think either approach is defensible.
 
: Any trade-off between realism and playability is IMHO an artistic rather than a deductive issue, so there isn't one right answer.  I can't recall why I used such strong language above, but I still think either approach is defensible.
  
: 1)  If (2) were true, so that the projectile was spawned abutting the player's bounding box, then they couldn't actually fire into an occupied sector (unless the wall was improperly flagged as one-sided).  Transparent "force fields" might be a problem, although those hadn't been invented at the time.
+
: 1)  If (2) were true, so that the projectile was spawned abutting the player's bounding box, then they couldn't actually fire into an occupied sector (unless the wall was improperly flagged as one-sided).  Transparent "force fields" might be a problem, although in id's defense those hadn't been invented at the time.
  
 
: 2)  Assuming the engine wouldn't be slowed much by the extra distance calculation and changing the intercepts code slightly, this only affects gameplay at very close range (where the extra distance traveled causes a significant change in the flight time).  Would that be noticed regularly enough to justify keeping the existing unrealistic behavior?  I'm not sure.
 
: 2)  Assuming the engine wouldn't be slowed much by the extra distance calculation and changing the intercepts code slightly, this only affects gameplay at very close range (where the extra distance traveled causes a significant change in the flight time).  Would that be noticed regularly enough to justify keeping the existing unrealistic behavior?  I'm not sure.

Revision as of 16:47, 25 February 2008

This was done on purpose to prevent projectiles exploding inside their hosts. -- so where is the bug? -- Jdowland 15:53, 21 January 2006 (UTC)

Unrealism/quirk, I guess. Anyway, I can't remember where anymore but I do remember reading it. Come to think of it, though it could also have been done to prevent monsters accidentally walking into their fireballs after launch. (Slightly outlandish but possible) -- TheDarkArchon 16:09, 21 January 2006 (UTC)

It isn't a bug, then: It's a behavioural decision that actually prevents a bug -- you can't get hit by your own rockets, at creation. But say if you fire in the direction of a teleport destination and then teleport to it, such that the rocket hits you, then you die, right? I think this article should be deleted. -- Jdowland 17:44, 21 January 2006 (UTC)

No, you do not die — see this demo (file info).  (Should I check with the plasma gun and BFG, too?)
The original problem should have been fixed by adding more frames to the firing animation and having the projectiles emerge in front of the actor.  Therefore, the fact that id dealt with it in a nonsensical manner is a bug.  (If I teleport into the path of my own rocket or BFG ball, I deserve what I get.)  I say we reinstate the page.    Ryan W 23:24, 26 January 2006 (UTC)

Projectiles by default don't teleport I've done DeHackEd mods where teleporting projectiles was a side effect: If the teleported projectile hits me, it wouldn't explode. Anyway, may as well delete it: I only added the article due to a link in the bug list. -- TheDarkArchon 17:48, 21 January 2006 (UTC)

I think he meant the player teleporting, not the projectile (see below).    Ryan W 23:43, 6 October 2006 (UTC)
The original problem should have been fixed by adding more frames to the firing animation and having the projectiles emerge in front of the actor.

I disagree. 1) If it were dealt with in that manner, then a player could walk up to a wall until they were touching it, and then they could actually shoot through the wall! 2) A projectile fired North-East, for example, would have to spawn further away from the player than a projectile fired North. 3) If a player was running forward while firing, they would collide with their own projectile, especially if moving at speeds higher than that of the projectile. -Wagi 69.51.157.227 15:35, 25 February 2008 (UTC)

Any trade-off between realism and playability is IMHO an artistic rather than a deductive issue, so there isn't one right answer.  I can't recall why I used such strong language above, but I still think either approach is defensible.
1)  If (2) were true, so that the projectile was spawned abutting the player's bounding box, then they couldn't actually fire into an occupied sector (unless the wall was improperly flagged as one-sided).  Transparent "force fields" might be a problem, although in id's defense those hadn't been invented at the time.
2)  Assuming the engine wouldn't be slowed much by the extra distance calculation and changing the intercepts code slightly, this only affects gameplay at very close range (where the extra distance traveled causes a significant change in the flight time).  Would that be noticed regularly enough to justify keeping the existing unrealistic behavior?  I'm not sure.
3)  Yes, they would.  That would be consistent with the *un*realistic fact that you can actually run fast enough to catch up to it.  The player would be continually weighing the risks of slowing down vs. not being able to fire straight ahead, which might be awkward, especially in deathmatches; but without beta testing I'm not prepared to say it would be too awkward to get used to.
As various people have pointed out on talk pages, establishing a "bright line" for bug notability is difficult, and we either have to do that or (amongst the whole community, but especially between port programmers and non-technical users) keep agreeing to disagree.    Ryan W 18:55, 25 February 2008 (UTC)

I still do not understand why this article was deleted without a vote.  Although we have no explicit policy about what kinds of phenomena can be added to Bugs, IMHO the fact that a projectile weapon does no damage when it hits you, but 100+ points of damage when it hits the wall right next to you, is quite enough of an "oddity" to qualify.

Demos: without teleportation (file info), with teleportation (file info).  These show the plasma rifle and BFG as well as the rocket launcher.    Ryan W 13:37, 19 September 2006 (UTC)

Those demos are brilliant examples: the doom2 one with the RL is the best (because of brevity really). Can you try and work them into the article as examples? -- 82.39.205.158 18:49, 19 September 2006 (UTC)
I also prefer the Doom II demo, mostly because it is difficult to see the projectiles in the other one (due to the teleporter fog and the fact that the projectiles catch up to me so quickly).  You can use iddt to watch without the fog, but it still happens pretty fast.  The ideal situation would be a teleport landing 2000+ units away along a compass direction, facing toward the teleport linedef, with no wall behind it for 156 units; that way, you could aim with idmypos, then teleport, then see the projectile moving for a couple of seconds before it passed through you, without the misleading complication of blast damage.  However, I didn't want to arouse suspicion by using a non-OEM map.   ;>
On the other hand, if the source code unequivocally shows that the player is the same Thing both before and after teleportation, then the two situations in the demos are equivalent, are they not?    Ryan W 23:43, 6 October 2006 (UTC)

I was playing on a custom wad (i do not have the name, sorry) on Zdaemon and I was camping by standing in the corner and shooting in a straight line along the side spawn areas. (Sorry by those who are mad at me for camping :P) Anyway, I died, and when I respawned, my own plasma hit me, and killed me. —The preceding unsigned comment was added by Roie (talkcontribs) .

Dying while the projectile is in flight is a slightly different situation (at least in the engine's opinion: see section 3I of the BFG FAQ).  But you're right, that situation should be mentioned in the article to avoid misunderstandings.    Ryan W 04:27, 1 February 2007 (UTC)