Bug in ShooterGame (replication)

Community Community & Industry Discussion
, , , , ,
1

I think I found a bug in ShooterGame, I hope I’m wrong though. I’m running ShooterGame 4.4, by the way.

When a bot gets right up in your face and you shoot him with only the weapon_instant, the hit won’t register on clients if you are aiming high (i.e. anything above the bot’s chest).

The output log spat out the following warning:
LogShooterWeapon: CR_WeapGun_C_38 Rejected client side hit of ZombiePawn_C_6 (facing too far from the hit direction)

I’m trying to figure out a way around this, as it affects gameplay for obvious reasons.

Does anyone know anything about this bug? Any ideas on how to fix it?

Thanks!

2

I found a setting in the weapon_instant defaults:

‘Allow View Dot Hit Dir’

This appears to control if a client can hit an enemy with the weapon_instant based on the angle of the player camera vs. that of the weapon’s muzzle location, defined by a socket on the weapon’s skeletal mesh.

When running the game as a server/single player, this isn’t an issue, it only affects clients- which is a problem.

Is this behavior of the weapon by design or might it be an oversight by the programmer(s) on ShooterGame?

Either way I thought it should be brought to Epic’s attention- thanks!

3

Hi ,

I moved this over to our Bug Reports section. Would you be able to provide the exact steps you are following from opening the ShooterGame project in order to see this issue occurring?

4

Sure, open unreal ed, run a game as a client and make sure there are bots:

  • run up to a bot and shoot them in the face from as close as you can
  • make sure you’re using the instant weapon, not the launcher
  • notice the hits don’t register on the bot
  • run as a server/single player and notice that the hits DO register, within the same set of circumstances
  • have the output log window open so you can see the warning/error spit out when the shots don’t register

Let me know if you have any other questions!

5

Hi ,

Thank you for the additional information. I was able to reproduce the issue that you described (and found a couple other minor visual issues I also need to look into), and I have submitted a report to our development team for further investigation (TTP# 345872). Thanks for letting us know about this.

6

Hi ,

This is great- I’m glad I could find that and point it out. ShooterGame is an excellent example project and it’s great to see Epic working hard to make it as best as it can be!

Also, I think I found another bug :stuck_out_tongue:
If you’re playing as a client, use weapon_instant and fire until you empty your clip; then reload, but keep trying to reload over and over again really fast. You will see the reload anim play twice in succession before the weapon’s ammo actually finishes reloading. It’s a cosmetic issue only, as it’s the reload anim that looks quirky reloading twice in a row.
This doesn’t happen when playing as a server, only when playing as a client. Let me know if you have any questions!

7

I found the same reload animation issue.

A quick fix for this is to comment out the check for Role == ROLE_Authority in ShooterWeapon::StartReload()

//if (Role == ROLE_Authority) 
{
    GetWorldTimerManager().SetTimer(this, &AShooterWeapon::ReloadWeapon, FMath::Max(0.1f, AnimDuration - 0.1f), false);
}

What I believe is happening is that the reload is only occurring on the server and there is a small window where the client thinks their gun still needs to be reloaded before the replication of the CurrentAmmo gets back to the client. By allowing the client to call ‘ReloadWeapon()’ it will reflect the server values of CurrentAmmo immediately. Not sure what sort of issues this may cause though with respect to Client/Server safety, would love to hear Epic staff’s response to this fix.

8

Did this bug ever get fixed?

9

Hi Nonlin,

I was able to locate this ticket in our current ticket system, and unfortunately it looks like this was closed with a Won’t Fix resolution. The engineer that closed the ticket stated that it was not worth complicating the client hit verification to cover this specific case. This behavior is not intended, but correcting the issue is something that would need to be addressed in a project by project way.