(Client-side, your character should be evicted from the seat)
Client-side, set the seat’s Disabled property to false
Client-side, try to sit in the seat again – if the bug is happening, you shouldn’t be able to
Resetting your character and loading a new one will fix the bug. And the bug won’t happen if you don’t do step 3 (and by consequence 5). This applies to both Seat:Sit() and the default character sitting trigger.
The main reason this seems to happen is because the server still thinks the character is sitting in the seat. But this seems like a situation where the client should be able to sit again if it is still considered the occupant of the seat by the server, or where it should get some network authority over whether it is still sitting in the seat or not.
This bug makes it difficult to implement seats which are enabled/disabled individually for different clients.
You can also just make your own custom sitting function. Just disable the seat and use the occupant property instead. We did this in my game to create prompt activated seats instead of touch seats, but you can use a Touched function to continue the touch to sit behavior.
I must have been mistaken, haven’t touched the code for our seats in over a year. It is custom though. Thanks for the bug report, I hope they look into this.
It can however be set using Seat:Sit(Humanoid), if the seat isn’t already occupied.
Indeed, seats are handled by the server. And I don’t find this a bug, deleting a weld or disabling a property client-side doesn’t replicate to server. Inconvenient, but not a bug. My opinion.
Seat:Sit() is affected by the bug, so it is not a valid solution here…
And yeah, it’s not a bug in the technical sense since it is expected networking behaviour over the entire engine. But is more of an API bug like “this seat API roblox gives us is not working as working as expected”, mainly because characters operate in this weird space where the client does have ownership over some things and getting out of a seat seems like a reasonable thing it should be able to control.
The client is already able to have some authority over the character’s sitting state by what happens when the player presses the jump button. It’s kinda weird to have an API that does replication under-the-hood in response to user input, but not one that does replication in a way that is controlled by code. (It should be the other way around, if anything, since that is more complete. But that’s not how Roblox chose to do things.)
It’s also strange for the Disabled property to only “half-work” when used client-side. It does have an effect and work correctly, but in this one case where a character is sitting in the seat when it is disabled it doesn’t work. That’s why I originally thought it was a technical bug. If the property just straight up didn’t work at all I would have just been like “ok, fair enough, I just can’t use this” but instead it baited me into thinking it worked when it didn’t.
Also: I did solve this issue on my end by firing a remote to the server prior to disabling, and this remote is just responsible for evicting players from whatever seat they are sitting in server-side. It’s fairly simple and non-invasive so I’m happy with it.
This ticket had been closed as its currently expected behavior. It sounds like a workaround was found, which is what I would recommend as well (set property on server)
We’ll update the documentation to be more clear. By comparison, the Enabled property on WeldConstraints and other constraints function the same way, and is expected based on the current limitations of the networking model.