Vehicle occupants sometimes do not attach to correct position
Sometimes any vehicle occupant may appear out of position to another player. Usually they appear some way above where they should be. This incorrect attachment position remains until the player leaves that position.
Comments (9)
-
reporter -
- attached 2015-06-13_00006.jpg
- attached 2015-06-13_00003.jpg
Added a couple screenshots. The view of the gunsight is what is seen when I enter the gun when it is in this state. The log is also spammed with errors that
Gun
isnone
. -
- marked as critical
-
reporter Hopefully fixed for cannon (including AT gun) in commit 00c13c0.
Can't really test on my own, but I used this in a modded vehicle a couple of years back and tested it quite a lot then and it worked fine. Well, it certainly solved the positioning bug I found happened quite often on initial replication to client. Should solve problems where Gun isn't received until after attachment, but can't solve problem if Gun is never received. Pretty sure it's the former though, so we should be ok.
Only differences are I did it in PostNetReceive() back then, when bInitializedVehicleGun was set, but now I do it in InitializeCannon(), which is called from the same place in PRN().
Will add to other classes, including mortar, later.
-
reporter Same fix for unbuttoning MGs in commit 1f20749.
Don't think this problem affects vehicles themselves, as there's not the replication timing complications of Gun etc.
Have made same change for mortars, but will commit separately as part of wider mortar changes.
-
reporter Same change for mortars implemented as part of wider commit a040439.
Mortars had bigger problems as often didn't get the Gun actor EVER, once they'd been been deployed and un-deployed. But that should all be fixed as part of the commit.
Hopefully this issue can be closed now.
-
- changed status to resolved
Marking as resolved, will re-open if this issue reappears.
-
reporter More thorough, belt n' braces fix added in commit 924450e. Same refinement for mortars as for other vehicle classes.
-
reporter Proper implementation of my belt n' braces fix for mortar operators in commit 2122927. Didn't do it right the 1st time !
- Log in to comment
The problem, as with many others, is a replication timing issue. We can rely on a client receiving certain replicated actors, but not the order in which they will receive them. So sometimes a just replicated actor tries to do something that needs a related actor, which is hasn't received yet, but will do so in another split second.
The solution, as I suspect with many other similar problems, is to use PostNetReceive() to control the timing of certain functionality on each net client. PNR, if enabled, gets triggered when a replicated actor is received, if the client has a replicated reference to that actor (e.g. Driver, Gun, VehicleBase, Owner, Base).