I think what he wanted was a script that would check if the player entered a certain area which then sets the IntValue to 1 or something and that activates another script checking if the IntValue is the desired number. Though he can just write all this in one script. (assuming he knows how to change the gravity already)
Could you define âoverkillâ? You are able to specify a force.
Consider this too [30 characters]
Keep it short and simple. A single assignment (workspace.Gravity = 100
) is faster, more efficient and less lines than making a BodyForce, calculating the character mass, and parenting the BodyForce.
Well I donât have any oppositions, but I will always want to have more control and security rather than saving 5 lines.
OH I understand now! sorry for the inconvenience
Why create a bodyforce, parent it, change its force (which is going to cost more) than just changing the workspace gravity?
Your solution doesnât provide anything in regards of security, one might say itâs even worse than just setting the gravity. A player can still delete the BodyForce and change the workspace.Gravity
as they wish. And if your anti-exploit measures depend on not letting clients have BodyMovers, your solution would open up the possibility of using the BodyForce for a crude fly hack.
It doesnât provide more control either in a practical sense. Vehicles and tools will still obey normal gravity unless you want to make a new BodyForce for every single unanchored assembly (- seriously?). Negative gravity doesnât exist and if OP ever wants to make a meteor impact or jetpacks, they can add BodyForces as they go along at any point in development.
Create a new LocalScript, then parent it to StarterPlayerScripts or something.
Then open the script and set the code to:
workspace.Gravity = 25 -- whatever you want the gravity to be
This only affects gravity for the local player and thus, your problem has been solved. If this were during the time of FilteringDisabled then well, itâll be a little more complicated.
I never mentioned negative gravity but rather an upwards force, gravity is a force like any other force. And Iâm not sure how do you make jetpacks without body movers. Do some lerping? No. Your post doesnât make sense at all as you can have FULL control over the velocity using body movers.
Get a local script inside the players starter scripts and change the workspaceâs gravity to what you want:
workspace.Gravity = 60
you can still make it for a specific player through checking for ID or PlayerName
or have a specific item/button start a local script that does the same thing.
@bt5191 has same solution as mine just realized
But how would I make it change the gravity for that person when someone touches a part?
He can use part.Touched:Connect()
, and then, detect the character who touched the part, and get the player from that character using GetPlayerFromCharacter
Oh yes, if you want to activate a LocalScript for that specific player, you can use RemoteEvents
An upward force is the same as a downward force in the same direction but negative. Thatâs the entire premise of BodyForce
, since it doesnât have a directional property. You go âthe other directionâ by negating the values in the Force
property. Letâs not forget that BodyMovers are considered legacy. You are free to use them, but there are better methods of moving stuff around. BodyMovers donât even give you full control over a partâs physical properties, as they all just simulate (possibly very strong) forces with dampening. âFull controlâ over velocity can only be achieved with a loop changing the partâs properties.
I think what he means is that your solution is flawed.
Not in the sense that it wonât work but in the sense that, not to be offensive to Rainzyyy (not my intention at all) or anything, but if he hasnât already explored some of the basic solutions we have listed here (like setting gravity in a LS), how do you expect him to be able to follow suit with your solution?
As @emojipasta said too, introducing BodyForces, BodyMovers, things like that make managing âgravityâ difficult and some aspects of anti-fly exploits difficult to include. Setting workspace.Gravity is easier and offers pretty similar levels of security (and as he mentioned, possibly even more).
Here is an example, have this as a local script inside the part you want to be touched:
local part = script.Parent
part.Touched:Connect(function(hit)
if hit.Parent:FindFirstChild("Humanoid") then
workspace.Gravity = 50 -- ur gravity here
end
end)
Hope this can help, I might be wrong.
What are you even trying to conclude with this statement?
Local scripts donât execute in a part in workspace unless itâs a descendant of the character. The LocalScript has to be in a place like StarterCharacterScripts
or the script has to be a server script with a remove event attached.
I donât know about the consequences of repeatedly setting the gravity, but a script like that should have a simple check to ensure it only runs once (if gravity ~= 50 then gravity = 50 end
)
I said your argument of âyou can use them to apply any amount of force in any direction. You canât use workspace.Gravity to reverse the force anyhowâ (which equates to saying only BodyForces will allow OP to define a negative gravity) is nonsensical, since negative gravity (=> gravity/âa forceâ pointing upward) doesnât exist.
workspace.Gravity = 50
local Plr = workspace:WaitForChild(game.Players.LocalPlayer.Name)
local Mass = 0
local BodyForce = Instance.new("BodyForce")
BodyForce.Parent = Plr:WaitForChild("HumanoidRootPart")
local AllParts = Plr:GetChildren()
for index = 1, #AllParts do
if AllParts[index]:IsA("BasePart") then
Mass += AllParts[index]:GetMass()
end
end
BodyForce.Force = Vector3.new(0, (workspace.Gravity * Mass)/2, 0)
While the end result may look almost the same, the performance cost using the depreciated body movers is much higher than simply changing the gravity.
Changing the gravity:
Bodymover:
Really you should be using the new constraint movers however they move relative to the player so if they tilt they will likely be dragged slightly in that direction.