I’m thinking there’s probably a way to do this but I’m not finding it. I have a game where some of the characters should be able to sit in seats and others should not - right now the ones that should not, if they touch a seat, sit despite themselves. I’ve tried Humanoid:SetStateEnabled( Enum.HumanoidStateType.Seated, false ) but all that does is prevent them from playing the sit animation - they still weld to the seat.
Credit to @SummerEquinox for giving me the idea to delete the SeatWeld instead of making the character’s humanoid jump. This is not the best solution
I tested most methods I know about and only found two solutions, if you want to really make something advanced you could make a custom seat and if the player touches it and is not on a certain list they aren’t allowed to sit there but if they aren’t on the list they can sit there.
Deleting the “SeatWeld” would be the best way to go, you can also make the character’s humanoid jump.
for _,v in pairs(workspace:GetChildren()) do
if v.Name == "Seat" then
v.ChildAdded:Connect(function(item)
if item.Name == "SeatWeld" then --I don't see what other things would come into the seat but just to be sure.
wait()
item:Destroy() --Removes the SeatWeld player doesn't sit.
end
end)
end
end
When players sit, a weld called SeatWeld is created inside of the Seat object welding their character to the seat. To get them out of this Seat, you have to destroy the SeatWeld inside of the Seat(or you can just have the Player’s Humanoid jump).
Destruction of SeatWeld is the most efficient way of doing this. @OP
local Functions = {}
Functions.__Index = {}
function Functions:DestroySeatWeld(player)
--[[Pathway To Seat]].SeatWeld:Destroy()
end
--Functions:DestroySeatWeld(PLAYERNAME)
CleverSource already wrote you some base code, so here’s a function that removes the SeatWeld.
You can change the Disabled property locally. I do this in a project I’m working on and it works great.
You can know where all your seats are and set them disabled that way
You can tag all your seats and get everything by tag + listen to added/removed to disable them
You can listen to all added and removed descendants of workspace (possibly slow) to disable them
Here's some code for that last one:
local enabled = true
local seats = {}
for _, seat in next, workspace:GetDescendants() do
if seat:IsA("Seat") then
seats[seat] = true
end
end
workspace.DescendantAdded:connect(function(seat)
if seat:IsA("Seat") then
seats[seat] = true
seat.Disabled = not enabled
end
end)
workspace.DescendantRemoving:connect(function(seat)
if seat:IsA("Seat") then
seats[seat] = nil
end
end)
setEnabled = function(newEnabled)
if newEnabled == enabled then
return
end
enabled = newEnabled
for seat, _ in next, seats do
seat.Disabled = not enabled
end
end
---
setEnabled(false)
If for some reason this is not an option, you could also look at the SeatPart property of the humanoid or use the Seated event. I imagine this would be better than having a ChildAdded listener on ever Seat.
Edit:
Another solution is to set the seat to Disabled and create the SeatWeld yourself. The humanoid will act like it’s a normal seat and allow jumping out of it, but you get to control who sits in it because the Seat is disabled.
Simply deleting the weld after it has been created seems messy to me. Plus, if you have any other ChildAdded event listeners on the seat, you would have to code them to ignore welds created by players who are not allowed to sit.
I would just make it so that it would save all the players into one table and have the player name and if there seat is x (x is enabled or false) then there seat x would be in the table along with there player name. I also would have a check where if a seats properties change it will run a scan thru the table checking if that seat is meant to be enabled/disabled (client sided since we are going based on what @Corecii said). Probally not the best way but i’d expect it to work.
The exploiter could disable that check if its being ran client-side. The idea of setting the property to its proper format if changed is good, but then comes the question of how to stop exploiters from changing or disabling those protocols.
As long as its on the client-side and the exploiter has a good enough program, they’ll be able to see that code and act upon it.
Exploits for sitting are mostly negligible. The client could execute arbitrary code to play the sit animation and since they have physics ownership of their character could repeatedly move themselves to the seat. It’s fine to do the work clientside because we’re not going to stop them either way if they exploit.