Seat Occupant and Humanoid SeatPart not replicating to new players to a server

Bug Reports Engine Bugs
#1

The Occupant property of VehicleSeat and Seat, as well as the SeatPart property of Humanoid is not properly being replicated to players who join the game after another player already sat in a seat, for players who join after another player has already sat in a seat, the SeatPart and Occupant properties will be nil for the respective Humanoid and Seat, despite a SeatWeld being visible on all clients, including new ones. If the sat player jumps and sits back on the seat, all properties are then correct again.

I have an uncopylocked repro place here which displays the Occupant property of a seat, whether or not there is a SeatWeld instance as a child of it and the SeatPart property of all the other Humanoids in the game, output is displayed on both client and server output.

I’m able to reproduce 100% of the time:

  1. Join the game on one account and sit in the seat, open F9 client output to view status of properties.
  2. Join the same server on a different account and view the F9 client output to see SeatPart and Occupant both be nil.

The behaviour I’m expecting new players to see is for the SeatPart property to point to the sat Humanoid and for the SeatPart property to point to the Seat the Humanoid is sat on.

I’ve only just had a report of this bug and I’ve only tested and repro’d on a Windows 10 PC so far.

15 Likes
#2

Can confirm this issue is appearing in my places, making it difficult to program cars efficiently.

1 Like
#3

I have the same issue. It makes everything much more complicated…

2 Likes
#4

I’m getting this on a place with StreamingEnabled still. Vehicles appear to have open passenger seats, when in reality they are already occupied.

This requires me to make extra state on top of the occupant property, set up remotes to get this value from the server—and since my game has StreamingEnabled, this can be inconsistent, since the humanoid might not replicate before the seat does.

Occupant also can’t be set manually, so I have to treat this property as something that’s entirely unreliable.

1 Like
#5

100%
I’d like to know the progress on this. I completely forgot I posted on this thread, however, just today I rediscovered the bug being a nuisance. And, like last year when I posted, I was in the middle of programming a vehicle system, that’s twice I’ve ran into this bug, and twice now that I’ve posted about it, we can’t have a property being unreliable - please look into fixing this!

I shouldn’t have to be doing this:

local function GetOccupant(seatPart)
	if seatPart.Occupant then
		return seatPart.Occupant
	end
	local seatWeld = seatPart:FindFirstChild("SeatWeld")
	if seatWeld and seatWeld.Part1 and seatWeld.Part1.Parent and seatWeld.Part1.Parent:FindFirstChild("Humanoid") and Players:FindFirstChild(seatWeld.Part1.Parent.Name) then
		return seatWeld.Part1.Parent.Humanoid
	end
end
Players can force themselves in a seat even when the seat's Disabled property is true
#6

I can confirm this bug is still present. In fact, thanks for the above function (GetOccupant) as it helped solve my issue. I do agree though, we shouldn’t need to have to call a function like this at all.

1 Like
#7

This is still happening and is extremely annoying as it results in new players seeing voodoo character models floating in random places in the place. Not sure if that specific detail is a separate bug, but we are seeing the same symptom of Seat.Occupant not being correct, so am assuming it’s relevant / connected.

#8

This issue is still occurring. My current fix is using a module that contains this:

return function(seat) -- GetSeatOccupant
    local seatWeld = seat:FindFirstChild('SeatWeld')
    return seatWeld and seatWeld.Part1.Parent.Humanoid
end
3 Likes
#9

Our game is still affected by this. We run code on Heartbeat to render wheels and sounds for our bicycles and skateboards. We were encountering a bug and spent significant time debugging to figure out this was the root of our issue. Now we have to use the SeatWeld workaround.

#10

Still an ongoing issue. Can this please be addressed? Thank you!

2 Likes
#12

This bug is still ongoing, and is affecting the game Greenville.

We have systems to control car functions - such as sounds, lights, and player visibility - that depend on the Seat.Occupant and Humanoid.SeatPart properties. Ever since our last content update / most recent patch (give or take 10 days and 2 days respectively), these errors have been skyrocketing, breaking core detail elements for the cars.

The expected behavior should be 100% reliability with the affected properties changing.
The actual behavior is more or less 50% reliability in normal use with near 0% reliability when “stress-testing” the bug (prints in the systems confirm that with every exaggerated call, the occupant value is nil.)

We do not know if the values eventually change after a delay, but our code (and others) expects the values to change almost instantaneously for smoothest operation.

To stress test the bug in the game:

  • Buy a car in the game if you don’t have one
  • Spawn a car
  • Repeatedly get in and out of the car by pressing E and then Space; mash the buttons.

You’ll know the bug is happening if your car doesn’t have normal engine sounds, if your character is still visible through the car, or if a part of your lights don’t seem right when getting in.

2 Likes
#13

100% reproducibility rate. You’re able to do this in studio by having 1 client join, sit, and another client join. The newest client will not be able to see the first one’s SeatPart, but they’ll know they are Sitting. Have been unknowingly encountering this bug for years, and now that I realize the root cause I’ll implement a workaround in which the server assigns each Humanoid an additional value/attribute of their SeatPart just so new clients can always know.

#14

This issue still persists and was an absolute pain to uncover. Can this please be addressed already? It has been 3 years

1 Like
#15

Occupant still is not being replicated to new clients for seats that have the property set before join. This is another one of those small bugs that have existed on the platform for years and makes bug fixing that much more tedious.

Luckily a work around can be done simply by checking for “SeatWeld” under the seat.

1 Like