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:
Join the game on one account and sit in the seat, open F9 client output to view status of properties.
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.
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.
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
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.
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.
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.
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.
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.
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.
I am having this issue again now with StreamingEnabled on the local player’s character. The SeatPart is not replicating so the character gets stuck in the vehicle and is unable to jump out even though the SeatPart is operating fine on the server. I decided to just write my own seat system with welds because, once again, Roblox’s blackbox non-lua implementation proves to be a buggy neglected mess.