Apply Forces and Momentums to Entity/Object

[LeFix]

I recently looked at the existing documentations and descriptions about these natives: (15.05.17)

http://www.dev-c.com/nativedb/func/info/18ff00fc7eff559e

known as APPLY_FORCE_TO_ENTITY_CENTER_OF_MASS

// 0x18FF00FC7EFF559E 0x28924E98

http://www.dev-c.com/nativedb/func/info/c5f68be9613e2d18

known as APPLY_FORCE_TO_ENTITY

// 0xC5F68BE9613E2D18 0xC1C0855A

https://github.com/crosire/scripthookvdotnet/blob/dev_v3/source/scripting/Entity.cs

(ScriptHookVDotNet)

There are some mistakes and the descriptions are confusing.

As far as I know this is right:

APPLY_FORCE_TO_ENTITY_CENTER_OF_MASS(Entity entity, int forceFlags, float x, float y, float z, BOOL p5, BOOL isDirectionRel, BOOL isAmountRel, BOOL p8)
{ invoke<Void>(0x18FF00FC7EFF559E, entity, forceType, x, y, z, p5, isDirectionRel, isAmountRel, p8); }

APPLY_FORCE_TO_ENTITY(Entity entity, int forceFlags, float x, float y, float z, float offsetX, float offsetY, float offsetZ, int boneIndex, BOOL isDirectionRel, BOOL ignoreUpVec, BOOL isAmountRel, BOOL p12, BOOL p13)
{ invoke<Void>(0xC5F68BE9613E2D18, entity, forceFlags, x, y, z, offsetX, offsetY, offsetZ, boneIndex, isDirectionRel, ignoreUpVec, isAmountRel, p12, p13); }

forceFlags
the only "documentation" about this is from ScriptHookVDotNet
public enum ForceType
{
MinForce,
MaxForceRot,
MinForce2,
MaxForceRot2,
ForceNoRot,
ForceRotPlusForce
}

Imo it doesn't make any sense because these are bitflags.
Only the three lowest bits work, if higher bits are set to 1 my script didn't apply any forces.

First bit (lowest): Strong force Flag, seems to be a simple multiplier
Second bit: Unkown Flag (Didn't see a difference, but didn't stop working compared to higher bits)
Third bit: Momentum Flag=1 (the vector (x,y,z) is a momentum and not a force anymore)

 

offsetX, offsetY, offsetZ
These parameters are frequently found as xRot, yRot, zRot but are the offset of the force attack point.
For solid bodies there's no such thing like a attack point for momentums (called free momentum in german) so the offset is needless then.

isDirectionRel determines if the direction of the force vector is in global/world coordinates or in relative coordinates (e.g. the thrust from a jet engine is body fixed)

ignoreUpVec could someone explain this one for me, any code I've found sets this TRUE-

isAmountRel enables mass multiplier

In other words if this is set to FALSE, the force has a constant value (Newton) for all objects. A heavy object will accelerate slower than a light object.

If this is set to TRUE the force will be multiplied with the mass, so as a result the acceleration is a constant value for all objects.

p8 (Center of mass function) whenever I set this to TRUE my scripts stops running. -> Always false (at least for me)

p5 (Center of mass function) didn't see a difference if set to TRUE or FALSE, (didn't check for complex entity like peds with mutliple bones)

p12 is always set to FALSE, didn't test it.

p13 is always set to TRUE, didn't test it as well.

 

Please share your knowledge! (Imo these are very important methods for many modders)

Edited May 15, 2017 by LeFix

[LeFix]

I have a related thread about object physics here:

http://gtaforums.com/topic/885669-precisely-define-object-physics

[LeFix]

Momentums behave super weird, I don't understand what's happening behind the scences.

Applying an arbitrary momentum to an object often leads to a pendulum-like motion. (Rotation gets faster then stops and spins backwards again and so on)

This occurs with global and local momentum (isDirRel setting), but maybe my description is (partly) wrong for momentums or there's another relevant parameter.

I guess I have to implement them as pairs of opposite forces.

 

Edit:

Meanwhile I implemented the workaround and it works absolutely fine for body fixed momentums.

void ENTITY::APPLY_FORCE_TO_ENTITY_CENTER_OF_MASS(Entity entity, Vektor3D force, bool isDirRel, bool isStrong, bool isMassRel){	int forceFlags = 0u;	if (isStrong) forceFlags |= (1u << 0); //Set first bit	//LAST BOOL HAS TO BE FALSE (SCRIPT STOPS RUNNING)	ENTITY::APPLY_FORCE_TO_ENTITY_CENTER_OF_MASS(entity, forceFlags, force.x, force.y, force.z, FALSE, isDirRel, isMassRel, FALSE);}

void ENTITY::APPLY_FORCE_TO_ENTITY(Entity entity, Vektor3D force, Vektor3D offset, int boneIndex, bool isDirRel, bool isStrong, bool isMassRel){	int forceFlags = 0u;	if (isStrong) forceFlags |= (1u << 0); //Set first bit	ENTITY::APPLY_FORCE_TO_ENTITY(entity, forceFlags, force.x, force.y, force.z, offset.x, offset.y, offset.z, boneIndex, isDirRel, TRUE, isMassRel, FALSE, TRUE);}

void ENTITY::APPLY_MOMENTUM_TO_ENTITY(Entity entity, Vektor3D momentum, int boneIndex, bool isStrong, bool isMassRel){	//This method has no isDirRel setting!	//For the workaround I would have to pass or read the objects rotation to calculate the global force pair.	//And I don't need global momentums for my mod...	float momSqr = momentum.getNormSquared();	//Why is a zero momentum vector stopping body rotation?	//Following code produces zero vectors (force and offset) which shouldn't stop object roation.	if (momSqr < 0.0001f*0.0001f) return; //Workaround: Don't apply forces at all when momentum is near zero.	// FIRST: get an arbitrary perpendicular vector to momentum	Vektor3D offset = Vektor3D(0.0f, momentum.z, -momentum.y); //Crossproduct with (1/0/0)	//Check if (1/0/0) was a good choice (almost parallel is bad)        //0.7f (~1/sqrt(2)) close to zero has probably a better performance	if (offset.getNormSquared() < 0.7f*momSqr) {		offset = Vektor3D(-momentum.z, 0.0f, momentum.x); //Crossproduct with (0/1/0) has to be better than (1/0/0)	}	offset.normalize();	// SECOND: calculate the force vector(s)	Vektor3D force = momentum.cross(offset);	// THIRD: force flags, momentums behave strange can't properly use them yet	int forceFlags = 0u;	if (isStrong) forceFlags |= (1u << 0); //Set first bit	//forceFlags |= (1u << 2); //Set third bit	// FOURTH: Apply Forces which are physically the same as the desired momentum	ENTITY::APPLY_FORCE_TO_ENTITY(entity, force*(+1.0f), offset*(+0.5f), boneIndex, true, isStrong, isMassRel);	ENTITY::APPLY_FORCE_TO_ENTITY(entity, force*(-1.0f), offset*(-0.5f), boneIndex, true, isStrong, isMassRel);	//ENTITY::APPLY_FORCE_TO_ENTITY_CENTER_OF_MASS(entity, forceFlags, momentum.x, momentum.y, momentum.z, FALSE, isDirRel, isMassRel, FALSE); //y u no work}

Edited May 17, 2017 by LeFix

[LeFix]

I checked the isStrong force flag and so far it looks like it its a simple factor which is applied. -> 100

Two identical objects should have the same acceleration wih these settings:

Object A -> force:1, isStrong:false

Object B -> force:0.01, isStrong: true

 

Edit:

The differences are really small and they vary during multiple runs. (Randomly)

When I do the same with two identical objects and apply identical forces (isStrong setting as well) there are some small velocity differences too(!)

(Something like floating point errors I assume)

 

I also checked the collision behavior by applying opposite forces to two identical objects which push them against each other in air.

(One force isStrong=true multiplied with 0.01f, the other isStrong=false)

Even then there's no real difference, they just stay at the same spot)

 

Thought the force calculations might be in a specific order so two different force types interact in a specific way, no they don't.

 

Unit of the applied force?

I already mentioned (other thread?) that objects (with no drag) will fall with an acceleration of 10m/s^2 (gravity setting 1.0=default)

This is 10 Newtons/Kilogram

First i thought applying a force (x=0;y=0;z=-10; isStrong=false, isMassRel=true) would accelerate any object the same way like the inbuilt gravity does, but this only accelerates them with 5m/s^2!

So the vector used for applying a force to an entity has the unit 0.5Newtons(/Kilograms if isMassRel=true);

Edited May 19, 2017 by LeFix

[Kroket]

Sorry to revive an old post but doing some research into applying forces and can verify for you that ignoreUpVec, without the words to explain it itself, if you apply a force on the X/Y axis of an entity, and you have that set FALSE, once the entity turns "upsidedown" the force will aplly "backwards" and flip them back over the way they came, rather than continue the force to complete the original flip.

[YouDontKnowMyName]

Hi. I know It Is an old post but I have a question.

When I use entity force the peds and vehicles fly and the other players stay there. I want other players fly too,  How can I fix this ? 

Edited September 7, 2022 by YouDontKnowMyName

[kagikn]

I don't think many people talks about GTA V modding much here now, but I'll write more correct info for the natives APPLY_FORCE_TO_ENTITY and APPLY_FORCE_TO_ENTITY_CENTER_OF_MASS as there's leaked native definitions.

The native header leak in September 2022 revealed what arguments APPLY_FORCE_TO_ENTITY and APPLY_FORCE_TO_ENTITY_CENTER_OF_MASS take. Here's the definitions:
 

NATIVE PROC APPLY_FORCE_TO_ENTITY(ENTITY_INDEX EntityIndex, APPLY_FORCE_TYPE ApplyType, VECTOR vForce, VECTOR vOffset, INT Component, BOOL LocalForce, BOOL LocalOffset, BOOL ScaleByMass, BOOL triggerAudio = FALSE, BOOL ScaleByTimeWarp = TRUE)
NATIVE PROC APPLY_FORCE_TO_ENTITY_CENTER_OF_MASS(ENTITY_INDEX EntityIndex, APPLY_FORCE_TYPE ApplyType, VECTOR vForce, INT Component, BOOL LocalForce, BOOL ScaleByMass, BOOL applyToChildren = FALSE )

 

Despite what LeFix said, the 2nd argument ApplyType is NOT a set of bit flags. The native add forces only if you pass any value between 0 to 5 as ApplyType, but APPLY_FORCE_TO_ENTITY_CENTER_OF_MASS doesn't accept 2 or 3. These are my guessed APPLY_FORCE_TYPE enum values:

ENUM APPLY_FORCE_TYPE
	APPLY_TYPE_INTERNAL_FORCE = 0, // Apply a continuous internal force to the entity
	APPLY_TYPE_INTERNAL_IMPULSE = 1, // Apply a instant internal impulse to the entity
	APPLY_TYPE_EXTERNAL_FORCE = 2, // Apply a continuous external force to the entity. Does not work with APPLY_FORCE_TO_ENTITY_CENTER_OF_MASS as the documation of it says
	APPLY_TYPE_EXTERNAL_IMPULSE = 3, // Apply a instant external impulse to the entity. Does not work with APPLY_FORCE_TO_ENTITY_CENTER_OF_MASS as the documation of it says
	/*APPLY_TYPE_ROTATION_VELOCITY = 4,*/ // I don't know what names are appropriate for the values 4 and 5 because I couldn't get along with the natives these force type values correctly (I'm sure the values 4 and 5 are about angular velocity though). Even R* don't use these values much.
	/*APPLY_TYPE_ROTATION_VELOCITY2 = 5,*/ // Basically same calculation as APPLY_TYPE_ROTATION_VELOCITY but force will be multiplied by 102.931 (which is calculated by (1.75f / (0.0340035 / 2.0f)))
ENDENUM

External force can detach fragment parts of objects without getting collided (I'm not completely sure if external force can detach fragment parts of vehicles or peds, but I guess not). I haven't figure out what type of vector you should pass as the force vector when ApplyType is 4 or 5. I know GET_ENTITY_ROTATION_VELOCITY returns the velocity represents the angular velocity in world space of the entity but with rotation matrix applied, though.

 

And here's more parameter info (some part of the descriptions are copy-pasted from the leaked header, but I added a bit more detailed info than it says):

vOffset: Offset from centre of entity at which to apply force.

LocalForce: Specifies whether the force vector passed in is in local or world coordinates. Local coordinates (true) means the force will get automatically transformed into world space before being applied.

LocalOffset: Specifies whether the offset passed in is in local or world coordinates. 

ScaleByMass: Specifies whether to scale the force by mass. If true, force will be multiplied by mass. For example, force passed in is in fact an acceleration rate in m/s*s (force) or velocity change in m/s(impulse). If false, force will be applied directly and it's effect will depend on the mass of the entity. For example, force passed in is a proper force in Newtons (force) or a step change in momentum kg*m/s (impulse). In other words, scaling by mass is probably easier in most situations - if the mass of the object changes it's behaviour shouldn't, and it's easier to picture the effect because an acceleration rate of 10.0 is approximately the same as gravity (9.81 to be more precise). 

TriggerAudio: Specifies whether to play audio events related to the force being applied. Actually, vehicles are the only entity types supported (as of b2802) and will play a suspension squeal depending on the magnitude of the force. The sound will play even if ApplyType is a value other than between 0 to 5.

ScaleByTimeWarp: Specifies whether scale the force by the current time scale (max: 1.0f). Only affects when ApplyType is 1 or 3 (APPLY_TYPE_INTERNAL_IMPULSE or APPLY_TYPE_EXTERNAL_IMPULSE). The native always scales the force by the current time scale when ApplyType is 4 or 5.

Component: Component of the entity to apply the force too - only matters for peds. See the enum RagdollComponent below for possible values. Important info, the native will crash the game if you pass a ped handle as 1st parameter and pass a value other than RagdollComponent below as the 2nd argument (Component) as the native doesn't check the current frag type child count when access to the frag type child for the corresponding index! (leaked info says "only matters for breakable or articulated (ragdoll) physics.", but I can spot the difference only when I used the native to peds)

applyToChildren: Specifies whether to apply force to children components as well as the speficied component (will recursively call the internal function for APPLY_FORCE_TO_ENTITY_CENTER_OF_MASS)

Here's possible values for the parameter Component (huge thanks to rage-parser-dumps)

enum RagdollComponent
{
	RAGDOLL_BUTTOCKS = 0,
	RAGDOLL_THIGH_LEFT = 1,
	RAGDOLL_SHIN_LEFT = 2,
	RAGDOLL_FOOT_LEFT = 3,
	RAGDOLL_THIGH_RIGHT = 4,
	RAGDOLL_SHIN_RIGHT = 5,
	RAGDOLL_FOOT_RIGHT = 6,
	RAGDOLL_SPINE0 = 7,
	RAGDOLL_SPINE1 = 8,
	RAGDOLL_SPINE2 = 9,
	RAGDOLL_SPINE3 = 10,
	RAGDOLL_CLAVICLE_LEFT = 11,
	RAGDOLL_UPPER_ARM_LEFT = 12,
	RAGDOLL_LOWER_ARM_LEFT = 13,
	RAGDOLL_HAND_LEFT = 14,
	RAGDOLL_CLAVICLE_RIGHT = 15,
	RAGDOLL_UPPER_ARM_RIGHT = 16,
	RAGDOLL_LOWER_ARM_RIGHT = 17,
	RAGDOLL_HAND_RIGHT = 18,
	RAGDOLL_NECK = 19,
	RAGDOLL_HEAD = 20,
};

The documantations of the natives in the leaked header suggests you should use GET_PED_RAGDOLL_BONE_INDEX for the parameter Component, but don't think about that native since it returns what you passed as the 2nd argument as I tested. Instead, use one of the values defined in RagdollComponent above.

 

Hope this info will help you, and it would be great if someone posted how the natives work when 4 or 5 is passed as the 2nd argument in the future.

Edited February 2, 2023 by kagikn
To add a small part of missing info

[fredakilla]

Great thanks i m currently using it.. i ll test that