Vehicle occupant's weapon can be seen floating in front of their face by other players

Matt Hands

This bug is due to the player's 3rd person WeaponAttachment failing to become/stay hidden when he enters the vehicle. You're seeing his weapon in 3rd person, when there's no proper attachment/positioning of it for a vehicle occupant animation, as it's meant to be invisible. It can happen in any vehicle position, including riders, not just the driver.

The wep attach gets set to bHidden in DHPawn's StartDriving() event. To demo it, you can recreate the effect by removing the line WeaponAttachment.Hide(true) in that event, or by setting the wep attach to bHidden=false in an exec.

Nothing has changed and I'm pretty sure this isn't any different now. I think it's just that extensive testing tends to make existing bugs more noticeable, or at least we register them more than during frantic gameplay. By considering how bHidden could go wrong, I can see how this can happen and it's easily re-creatable any time, even in SP. And knowing the cause, I don't see a problem fixing it.

First, I looked at how bHidden could fail to reach another net client. It's marked as unreliable in Actor's replication statement, which suggests may or may not happen, depending on net load. But that's misleading, as reliable/unreliable only applies to replicated functions - variables are always replicated (eventually) if their conditions are met. Another potential problem is that if an actor is hidden & doesn't have collision or ambient sound, it isn't considered relevant for replication to non-owning clients. But surely if the server sets an actor bHidden, it's smart enough to know it needs to replicate that to clients before 'switching them off'? Maybe, maybe not, but In any event an actor remains relevant if it was relevant in the last 5 seconds, which it was, because a player entering a vehicle was on foot just before. And we know the change in bHidden does get replicated to other clients, because usually they don't see the wep attach of a player in a vehicle. So I concluded that the problem isn't caused by replication of bHidden.

Second, could it be caused by the pawn not having a WeaponAttachment when StartDriving() is called, so it doesn't get hidden, but afterwards the pawn gets a WeaponAttachment, which is visible? No, don't think that can happen. On another net client, the player getting into the vehicle is visible & relevant to them, so his wep attach was too. I don't see them receiving a WeaponAttachment through replication after/while he's entering the veh. And once he's in, he can't switch weapons or anything.

Thirdly, what if some other function is making the wep attach visible again after StartDriving() has made it invisible? Looking for "bHidden = false" shows that the state PutWeaponAway's EndState does just that to the wep attach. And while code stops a player from entering a vehicle while reloading, there's no prohibition while switching weapons. So if you enter while switching, you will always get this bug. Logging confirms that PutWeaponAway's EndState makes the new wep attach visible AFTER StartDriving() has turned it invisible.

Probable fix is to alter PutWeaponAway.EndState() so it only makes the wep attach visible if DrivenVehicle == none, i.e. player isn't in a vehicle. That will allow the weapon switch to complete, just invisibly. Another option would be to prevent vehicle entry while weapon switching, similar to the prohibition on entry while reloading a weapon, i.e. you can't climb into a vehicle while your hands are busy. I'll do the 1st and run some quick tests.

2015-06-13T07:10:55+00:00

Comments (8)

Colin Basnett reporter
- assigned issue to
  
  Matt Hands
- 2015-06-12T12:26:54+00:00
Matt Hands
Let me check some assumptions:
1. Only visible to the 3rd person viewing (i.e. the weapon attachment), not the actual player in 1st person.
2. Happens sometimes, not always.
3. Only noticed on a server, not a standalone?
Correct?
- 2015-06-12T15:51:43+00:00
Colin Basnett reporter
Correct.
- 2015-06-12T21:01:35+00:00
Matt Hands
- changed title to Vehicle occupant's weapon can be seen floating in front of their face by other players
- 2015-06-13T07:10:09+00:00
Matt Hands
This bug is due to the player's 3rd person WeaponAttachment failing to become/stay hidden when he enters the vehicle. You're seeing his weapon in 3rd person, when there's no proper attachment/positioning of it for a vehicle occupant animation, as it's meant to be invisible. It can happen in any vehicle position, including riders, not just the driver.

The wep attach gets set to bHidden in DHPawn's StartDriving() event. To demo it, you can recreate the effect by removing the line WeaponAttachment.Hide(true) in that event, or by setting the wep attach to bHidden=false in an exec.

Nothing has changed and I'm pretty sure this isn't any different now. I think it's just that extensive testing tends to make existing bugs more noticeable, or at least we register them more than during frantic gameplay. By considering how bHidden could go wrong, I can see how this can happen and it's easily re-creatable any time, even in SP. And knowing the cause, I don't see a problem fixing it.

First, I looked at how bHidden could fail to reach another net client. It's marked as unreliable in Actor's replication statement, which suggests may or may not happen, depending on net load. But that's misleading, as reliable/unreliable only applies to replicated functions - variables are always replicated (eventually) if their conditions are met. Another potential problem is that if an actor is hidden & doesn't have collision or ambient sound, it isn't considered relevant for replication to non-owning clients. But surely if the server sets an actor bHidden, it's smart enough to know it needs to replicate that to clients before 'switching them off'? Maybe, maybe not, but In any event an actor remains relevant if it was relevant in the last 5 seconds, which it was, because a player entering a vehicle was on foot just before. And we know the change in bHidden does get replicated to other clients, because usually they don't see the wep attach of a player in a vehicle. So I concluded that the problem isn't caused by replication of bHidden.

Second, could it be caused by the pawn not having a WeaponAttachment when StartDriving() is called, so it doesn't get hidden, but afterwards the pawn gets a WeaponAttachment, which is visible? No, don't think that can happen. On another net client, the player getting into the vehicle is visible & relevant to them, so his wep attach was too. I don't see them receiving a WeaponAttachment through replication after/while he's entering the veh. And once he's in, he can't switch weapons or anything.

Thirdly, what if some other function is making the wep attach visible again after StartDriving() has made it invisible? Looking for "bHidden = false" shows that the state PutWeaponAway's EndState does just that to the wep attach. And while code stops a player from entering a vehicle while reloading, there's no prohibition while switching weapons. So if you enter while switching, you will always get this bug. Logging confirms that PutWeaponAway's EndState makes the new wep attach visible AFTER StartDriving() has turned it invisible.

Probable fix is to alter PutWeaponAway.EndState() so it only makes the wep attach visible if DrivenVehicle == none, i.e. player isn't in a vehicle. That will allow the weapon switch to complete, just invisibly. Another option would be to prevent vehicle entry while weapon switching, similar to the prohibition on entry while reloading a weapon, i.e. you can't climb into a vehicle while your hands are busy. I'll do the 1st and run some quick tests.
- 2015-06-13T07:10:55+00:00
Matt Hands
Worked. Fixed in commit 3c2f0f8.

Left open so you can read & check. Also if anyone wants to prevent entering a vehicle while switching weapons (as a gameplay feature, nothing to do with bug fix).
- 2015-06-13T07:20:29+00:00
Colin Basnett reporter
Nice sleuthing!
- 2015-06-13T07:24:05+00:00
Matt Hands
- changed status to resolved
Sleuthin' - and massive systematic changes - are pretty much my raison d'être ! :)
- 2015-06-13T07:40:13+00:00
Log in to comment