[Danukem]

This is an old bug, and I'm bringing it up again because I'm struggling to find a workaround.

Define a fast moving (but not hitscan) projectile. Stand on a ledge and fire at a down angle. The projectile will hit the ledge you are standing on instead of what you aimed at. This happens regardless of whether the player or some other actor is doing the firing. For example, I tried making pigcops shoot a fast moving custom projectile (with speed multiplier it has a speed of 2048). When they stand on ledges and fire down at the player, the projectile hit the floor under their feet. In the exact same situation, pigcops firing their normal shotguns can hit the player just fine. The problem is not as pronounced with slower projectiles, but you can get it to happen at more extreme angles.

One thing that seems to help is manually changing the sector of the projectile when it spawns to one that is some distance in front of it. This isn't a complete solution, though, and I am still struggling with it. I've spend over an hour today on this.

[Fox]

There always had a problem with way too fast moving projectiles. As far I remember, fast projectiles also explode away from walls.

I suppose you can just change the .x .y .z of it. I use this so that mini Overlord don't kill himself as he usually does...

[Danukem]

Ilovefoxes, on Aug 13 2009, 03:34 PM, said:

There always had a problem with way too fast moving projectiles. As far I remember, fast projectiles also explode away from walls.

I suppose you can just change the .x .y .z of it. I use this so that mini Overlord don't kill himself as he usually does...

I think the exploding away from walls thing is a separate issue and was fixed a while ago, IIRC.

Also, the mini-bosses shooting themselves because of hardcoded clipdist and/or rocket positioning is yet another issue -- I don't even consider that an EDuke32 bug, because you can always make your miniboss from a different tile that doesn't have hardcoding associated with it.

I made a thread about this particular bug because fast nonhitscan projectiles are very useful if you want to make something visible that emulates bullets, and the bug makes that difficult to do (unless none of your maps have ledges).

Of course, we all have our workarounds, but they aren't perfect and I'm hoping it will be fixed for real.

[Forge]

DeeperThought, on Aug 13 2009, 02:56 PM, said:

One thing that seems to help is manually changing the sector of the projectile when it spawns to one that is some distance in front of it.

I like that. The enemy can sit behind a tree or a rock and snipe the player to death without being able to get shot themselves.

[Danukem]

Forge, on Aug 13 2009, 06:06 PM, said:

I like that. The enemy can sit behind a tree or a rock and snipe the player to death without being able to get shot themselves.

No, I'm pretty sure it doesn't work that way, because I only change the sector number of the projectile, not the coordinates. If there is a tree or something else blocking in front of it, the projectile should still be stopped.

[XThX2]

Would rotatepoint work in your case to spawn the actors a bit far from Pigcop ? I bet this is a crappy solution, but temporarily, can work.

[Danukem]

XThX2, on Aug 14 2009, 12:50 AM, said:

Would rotatepoint work in your case to spawn the actors a bit far from Pigcop ? I bet this is a crappy solution, but temporarily, can work.

I have a solution that works pretty good now, and that isn't it. I tried the rotatepoint thing early on in combination with some other things, and it didn't help. Even if it had helped, it would have been crappy: For one thing, it would mean that the pigcop would be unable to hit you at point blank range, because the projectile would spawn past you. It also changes the trajectory of the projectile so that it goes too far (because you are moving it out without changing its zvel).

My solution is to constantly set the sector of the projectile to the player's sector (but only if the projectile has a high zvel).

It seems to work ok, but I don't like adding hacks like that, because it can cause other problems down the road. When you have code that compensates for an underlying bug, then the code can get broken when the underlying bug is fixed. Also, if the projectile having an accurate sector is important in some context (which it probably is) then welcome to bug city.

[TerminX]

So... this happens because the engine's movement functions like clipmove() don't support z movement, requiring stuff like a diagonally moving projectile to tack its z movement on after the fact. This means that your projectile separately moves horizontally and then moves vertically every time it moves when traveling in a downward motion. The problem, however, is that the game was comparing the z position of the sprite to whatever the floor/ceilingz was BEFORE the horizontal movement.

The solution here is to simply update the sprite's floor/ceilingz (they store their own copy of it to account for sprite bridges, etc) when the sector changes after movement. That causes another problem, however... now the corners between floors and walls (as if you were standing on a crate and shooting down) are "soft" and there's an area where rockets will fly right through them. I think I can fix it with some cansee() trickery. Hopefully the extra calls don't slow things down too much when there are thousands of projectiles flying...

[Danukem]

TX, on Aug 14 2009, 02:33 PM, said:

So... this happens because the engine's movement functions like clipmove() don't support z movement, requiring stuff like a diagonally moving projectile to tack its z movement on after the fact. This means that your projectile separately moves horizontally and then moves vertically every time it moves when traveling in a downward motion. The problem, however, is that the game was comparing the z position of the sprite to whatever the floor/ceilingz was BEFORE the horizontal movement.

The solution here is to simply update the sprite's floor/ceilingz (they store their own copy of it to account for sprite bridges, etc) when the sector changes after movement. That causes another problem, however... now the corners between floors and walls (as if you were standing on a crate and shooting down) are "soft" and there's an area where rockets will fly right through them. I think I can fix it with some cansee() trickery. Hopefully the extra calls don't slow things down too much when there are thousands of projectiles flying...

Maybe the new improved collision detection should only apply to custom projectiles. It wasn't a big problem with the original projectiles anyway, and it would be a shame to have people dropping fps on older computers when playing unmodified Duke. It wouldn't take thousands of projectiles flying to slow things down on an older computer. All you need are a few dozen jetpacking liztroops firing their lasers.

[TerminX]

Oh, but it WAS a problem with the original projectiles... I can't even imagine how many times I've been pissed off by an RPG exploding in my face instead of going where I aimed it.

[Danukem]

TX, on Aug 14 2009, 07:05 PM, said:

Oh, but it WAS a problem with the original projectiles... I can't even imagine how many times I've been pissed off by an RPG exploding in my face instead of going where I aimed it.

Now that you mention it, that's true. I guess I have gotten so used to avoiding certain things -- like firing RPGs from a window at enemies below -- that I forgot how fucked up it was.

[Jimmy]

I think the Freezer has the same problem. Another thing that bugs me is that when a projectile goes from above water to underwater, it appears to change its angle.