VectorForce and artificial gravity

I’m creating a CustomController and using VectorForce as my main way of moving the character, one of the issues I’ve found is that I can’t reliably move the character without taking into account the characters mass, the main part’s current velocity (external to VectorForce) and the difference between them.

So far, my code for horizontal movement looks like this;
InputHor is a vector3 with no Y value, and vh is just vector3(1,0,1)

	local Intended = InputHor * self.MoveSpeed * ET_Settings.GameTime --Whatever vector we want to *achieve*, this is where we put it.
	local Difference =  Intended - (self.Model.PrimaryPart.Velocity * vh)
	local FinalPass = Difference * self.MoveSpeed --Appears to need a high value for snappyness?
	self.Velocity = v3(FinalPass.X, UpValue, FinalPass.Z)

Its messy, but this works and it does so reasonably accurately. The value of ET_Setting.GameTime is a numerical value between 1-0 and allows me to alter time in game. I have the method here for doing this horizontally, but I don’t really know how I can do this vertically. Does anyone have any suggestions or experience with this at all?

2 Likes

Can you enable Massless on the player’s parts?

All parts are currently massless, however still appears to have mass.
Very weird.

1 Like

If massless parts aren’t attached to a part with mass, the property won’t make a difference. This is because an actual massless part would be infinitely affected by any force applied and would probably break things.

3 Likes

Ok, but moving forward without worrying about mass for the moment, how would I go about this correctly?

I don’t really have a solution, sorry. Just thought that clarification could be useful.

1 Like

So I have an interesting idea.

We know that acceleration is measured in studs/s^2, and velocity is measured in studs/s.
Everything that is measured in 1/seconds can just be multiplied by an alpha of ET_Setting.GameTime, and that will be the new speed of the object.
For example, since Workspace.Gravity is measured in studs/s^2, we can simply multiply the original gravity by ET_Setting.GameTime ^ 2, and use that as the current gravity. Similarly, we can do the same for everything, and I mean everything, that uses a unit of time, like humanoid’s WalkSpeed and JumpPower, the velocity and rotational velocity of a part, vector forces’ Force property, and even the speed at which characters are animated.

So, we don’t exactly have to use some complicated formula for slowing down time, which is what I think you’re doing. You could just save an original value of what it’s supposed to be, and then multiply by an alpha of your ET_Setting.GameTime for every existence of time there is in a unit of measure for a property.

The problem with this method is just how many variables you will have to change in nearly every instance in workspace, and how many “Original Values” you will have to keep in memory for the objects you changed. It might be very laggy, and you might have to replicate the event to all clients. You would probably have to prioritize what should get changed, and what doesn’t really matter.

1 Like

ET_Setting.GameTime Defaults at 1, so everything behaves properly, changing this value tending towards 0 acts fairly simply. I’ve repeated this process before using BodyMovers and CFrame with fairly decent results;

I just can’t get the VectorForce equations to work with the physics :confused:

The force equation looks like this:

Force = mass * acceleration

Standard acceleration is studs/s^2, and therefore, theoretically, you would multiply VectorForce.Force by ET_Setting.GameTime ^ 2.

Also, very cool explosion! :open_mouth:

There are other forces that might have to be considered…

Example:

Of course you could always raycast from the origin to the ground {0, -1, 0} unit vector, and determine if the object is on the ground - if it isn’t on the ground, you can then calculate the Y value for the VectorForce (gravity).

1 Like

Oh, as another note, this Fnet (net force) could get more complicated if the ground is on an angle (such as a wedge part) because there would be a lot of trigonometric equations to factor…

To be honest, you might be better off using body mover instances…

BodyForce (There is also an anti-gravity setup explanation here)

BodyThrust (To launch the projectile part)