Weapon projectiles are not always creating the correct hit emitters or creating a decal

Issue #376 invalid
Andrew Theel created an issue

This did not happen in RO or DH, so it has to be a new change someone has done. Sorry Matt, but I think it must be something in your projectile code changes.

Comments (6)

  1. Andrew Theel reporter

    This might also be a problem for only close range shots, but this is not confirmed and is a bit harder to confirm.

  2. Matt Hands

    Again, it's simply now that the original bullet pre-launch trace system is working now, where before it wasn't functioning as designed and so bullets were being spawned anyway.

    Now that the existing PLT works and prevents bullets spawning, as a network optimisation, the non-Actor, non-replicated DHProjectileFire class has to handle it all serverside & cause any traced hit to appear on the client. It does this by replicating an mHitLocation vector, which is used to spawn a clientside hit effect - this is UT2004 stuff, in the WeaponAttachment class. When a new value of mHitLocation is received by a client, it has to do a trace to find out what kind of object/material it hit. The trace isn't completely reliable. Specifically, it initially traces from where the player's weapon attachment muzzle is now, which may be in a different position to when shot was fired, due to replication delay. Then I see that the non-vehicle hit effect class uses a hit normal for the direction of the trace, rather than the bullet's flight direction, which would be more accurate.

    There are so many problems with PLT that I'm going to simply switch it off temporarily, so we can see what difference that makes. It's well intentioned, in that it can avoid a bullet being spawned on the server, replicated to all clients, with each machine running its own collision detection & hit functionality - when the server can quickly calculate that the bullet will hit X within a close distance. But it brings multiple problems & compromises of its own, which a bullet actor would handle much better. And I think bullets are fairly net efficient anyway, as they are torn off replicated actors, i.e. they spawn, replicate to clients, then the net channel is shut down, no further replication, client handles it from there.

  3. Matt Hands

    Temporarily disabled bullet's pre-launch trace, so we can test how much better DHBullet handles things. What differences do we notice?

  4. Andrew Theel reporter

    Now that we realize that it really wasn't a prelaunch issue and more an issue with a specific mesh and inaccuracies with hit effects. Here is what we should do.

    No pre-launch for bolt actions. No PLT for grenades and other projectiles, pretty sure this is the case already, but wanted to state it.1 Pre-launch for semis with a reduced range. Pre-launch for autos with a standard range. If Machine Guns (LMGs) use a similar system, than to actually have the range increased in hopes to optimize MGs more than they were.

    What do you think?

  5. Andrew Theel reporter

    This was not a valid report because when the hit emitters were wrong it was likely a problem with the mesh or PLT. PLT could also be an additive to the issue, however, we cannot be certain that this 'bug' is fixable in unreal script.

  6. Log in to comment