Need to shoot in front of player in order to hit the hitbox

Hey all,

I am a developer on the game TheColony (www.thecolonygame.com) and we just had our first 10 person test session. Everything went really well and everyone had a good time. However, we had some hit detection issues. In short, you had to shoot in front of the player in order to hit the player.

We followed the SgtBolt tutorial around authoritative hitboxes. If I understand everything correctly, when the Client fires his/her weapon, that Fire=True is sent with the next PlayerCommand. When that PlayerCommand is executed on the server it calls the hitbox logic on the server as a coroutine and then sets State.Fire trigger (this trigger tells all the clients to execute the hit logic for that particular player) . The client hit logic is purely for effects/animations, while the server hitbox logic determines if the shooting player really did hit another player. The problem is that even though the client and server are executing similar raycasts, I need to shoot in front of the player in order for the server raycast to register the hit.

What this is telling me is the what the client is seeing is lagging what is actually occurring on the server by ~.2 seconds. That ~.2 seconds delays means I need to lead the player on the client to actually hit the player on the server.

I have tested on the latest release build of Bolt and still see the issue. Let me know if you have suggestions for debug.

Comments

  • If you use Bolt raycasts and Bolt hitboxes, then the shots will be lag compensated. See here for more on that https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_compensation

    When I try the tutorial I dont run into the problem you're describing. You may have some problem with your hitbox, client side prediction, or something else.
  • Okay, I will go back to the original tutorial and re-test it out there. If it works then it must be something piece of code I added. Thanks.
  • Coroutines fire after the fixed update loop, which is where everything in bolt will be updated. It is possible, and likely depending on your sim rate, that at times you will get multiple fixed updates in a single frame.

    I'm not sure how you are queuing the lag compensated query for the coroutine, but I can see all sorts of trouble doing it this way. Also, you must make sure that you use the serverframe of the player's fire command and not the server's frame when doing the lage compensated query.

    Finally, I would use something like Vectrosity to show weapon traces in-game (based on a configuration), because it will help you easily see what the actual traces are like in case there is a bug somewhere that has nothing to do with lag compensation.
  • Thanks for the feedback. I removed the coroutines and went back to the basic shoot logic from the SgtBolt tutorial. Unfortunately, it didn't resolve my issue.

    This is my code around fire frames. Straight out of the tutorial.
    if (activeWeapon.fireFrame + activeWeapon.refireRate <= BoltNetwork.serverFrame)
    {
    activeWeapon.fireFrame = BoltNetwork.serverFrame;

    //Fire Trigger
    state.Fire();

    // if we are the owner and the active weapon is a hitscan weapon, do logic
    if (entity.isOwner)
    {
    activeWeapon.OnOwner(cmd, entity);
    }


    I tried using Unity's built in DrawRay to show the raycasts. Interesting enough, when I host the server in my Unity editor and my fellow developer connects to my game. The Bolt raycasts and the FX Raycasts are 95% exactly on top of each other, however they are behind where my fellow player is actually shooting. So on his system, he is shooting me, on the server, he is shooting behind me. I would expect the lag compensated Bolt RayCasts to be ahead of the Unity FX raycasts, correct? Since they are lag compensated.

    I will try to get the tutorial working tomorrow and see if I can reproduce on a clean project without all my crappy/legendary code.



  • bigd
    bigd
    edited January 2016
    Video of the raycasts for reference. Red line is Client's FX, Cyan is Server's raycast. Ignore the duration of the raycasts, the server was set to expire a little longer.
    https://youtu.be/zYqLpiV5pkg
  • After 20 changesets of gradually reverting my code to go back to the SgtBolt tutorial I found the issue in my own derpy code... at some point the I removed the cmd.ServerFrame argument from BoltNetwork.RaycastAll(new Ray(pos, look * Vector3.forward), cmd.ServerFrame) ... doh!

    All is working now, thanks for the help.
  • Good to hear