Changing gravity for only one player

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

2 Likes

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.

1 Like

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.

1 Like

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

2 Likes

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).

2 Likes

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.

1 Like

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:
image

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.

2 Likes