applyForce, applyOffsetForce, and applyAngForce Tutorial

[mjmr89]

Hi everyone, I've noticed a lot of people have trouble understanding these three functions (abbreviated AF, AOF, and AAF for this tutorial) and these are the three most used functions in pretty much all of my contraptions, so I thought I'd try to show how to use them. I tried making a video tutorial but I ramble on a lot so it ended up being 15 minutes or so :S

First I'll lay out the abbreviations that I'll use in the tutorial. I think they're pretty self explanatory for the most part. And on most of the force (NOT THE POSITION OF AOF) arguments in these functions, you're probably going to want a multiplier. Just mess with the multipliers a bit to get the behavior you want. If you're using just a simple E2 gate, you're probably going to want to go with a fairly small multiplier - maybe 2/100,3/100,4/100, something like that. Experiment a lot with it

E = entity() # Or you can use something like E = entity():isWeldedTo() or import your own entity as an input
Pos = E:pos()
Vel = E:vel()
Ang = E:angles()
AngVel = E:angVel()
Forward = E:forward(),Right= E:right(), Up = E:up()
Inertia=shiftL(ang(E:inertia()))
Mass = E:mass()

AF is basically a vector thruster located at the props location (you can see this using the "picker" add on). It takes one vector argument and can only cause translational (side to side, up and down, and forward/back) movement. My most common use for this is to act as a force to slow the prop down,

E:applyForce(-Vel)

This applies force in the opposite direction that the entity is moving, causing it to slow down.

Another use for AF is to go to one specific point. If you want to go to point A,

V = A-Pos
V /= V:length()
E:applyForce((V-Vel)*Mass)

This code applies force on all axis proportional to the difference - if you're 500 units away on the x axis, it will apply 500 units of force, then when you're at 250 it will apply 250 units, etc. I also added in friction force from the earlier code which allows it to actually work well. The Mass multiplier aids in moving the prop by taking the props mass into account - it takes more force to move a prop weighing 1000 than a prop weighing 1. Note that if you are simply using this on a normal e2 model, it will be equal to 1, so it's not needed.

Next is applyOffsetForce. This is similar to AF, but you can apply the force at any point on the map and it will be like you welded a vector thruster at that point to the e2/entity. Note that this is in global coordinates - that is,

E:applyOffsetForce(U,Pos)
#is the same thing as
E:applyForce(U)

A common use for this is make a prop face any coordinate (and doesn't spaz out at any particular orientation)
If you wanted the FRONT of the contraption to face TP (if you use picker2, front is the direction from the origin going out on the red/x axis)

V = TarP-Pos
E:applyOffsetForce(V,Pos+Forward)
E:applyOffsetForce(-V,Pos-Forward)

This works similarly to the example about going to a specific point only it does it twice, away from the center (so it causes rotation), and negates any translational movement. You'll also want to add the angular friction code that comes later to smooth out the movement.

Last but not least is the applyAngularForce function. It does exactly what it says - applies angular force.

Heres code that balances something (pitch = 0, roll = 0)

E:applyAngForce((-Ang:setYaw(0) - AngVel)*Inertia)

The Inertia multiplier accounts for the different inertia values on the different axis, allowing you to rotate the prop more easily and more efficiently.
The setYaw makes the yaw = 0; this is so that it doesn't try to be at that bearing, yaw = 0, all the time. Also, the kind of equation I'm using for this is

NewVal = TarVal - CurVal - $CurVal

TarVal is 0, CurVal is Ang:setYaw(0), and $CurVal is AngVel

To simply have angular friction, only include the -AngVel (you can use this on the point-to code earlier)

Here's some code that makes the E2 hover at z = 100. It resists movement and snaps to pitch = 0 and roll = 0 pretty quickly.

@name e2hover
@inputs
@outputs 
@persist 
@trigger all

runOnTick(1)

E = entity() Pos = E:pos()
Ang = E:angles() AVel = E:angVel()
Vel = E:vel()
Inertia = shiftL(E:inertia():toAngle())

TarZ = 100

AngF = -(Ang:setYaw(0)*20 + AVel)*5/100

E:applyAngForce(AngF)

Vec = (TarZ - Pos:z())*vec(0,0,1)*10

E:applyForce(Vec - Vel)

I think that's about it! Constructive criticisms, corrections, etc are very welcome! And please go easy on me, this is my first time ever writing a tutorial for anything. I hope you enjoy it and learn from it

[Magos Mechanicus]

Good tutorial!

You may also want to add how multiplying a force by the mass/inertia tensors before applying it leads to consistent accelerations for different entities thanks to Newton's 2nd Law and its rotational cousin. For translation this is merely

E:applyForce((V-EV)*E:mass())

but for AAF you need to use shiftL(ang(E:inertia())). This is because inertia() gives rotational momentum around the X,Y and Z axes in that order and PYR angles are rotation around the Y,Z and X axes in that order.

EAM=shiftL(ang(E:inertia()))
E:applyAngForce((-EA:setYaw(0) - EAV)*EAM)

[Jimlad]

Nice, but am I the only one who's concerned about this trend of giving variables two/three-letter names? "EP, EA, EV" etc. aren't very descriptive, and it isn't any more efficient than writing something like "Pos, Ang, Vel" which are much harder to confuse and are easier on the eyes in general. When it comes down to sacrificing "compactness" for "readability", I would much rather err on the side of readability. Where did this trend come from, anyway? Did you pick it up from other examples?

[mjmr89]

I can read them just fine - if people want to name them something else, of course that's fine . I don't see what the problem is, really. I've only had one "conflict" with my variables and that was solved by adding a bit more of one of the words to one of the abbreviations. And I picked it up from Chinoto's example of a hovering chip on the wiki.

[Jimlad]

Argh, I knew it, it always comes back to that. Apologies to chinoto, but although that example is good for showing what applyOffsetForce can do, it's one of the worst written examples on that page. I'll stop delaying today and get around to writing a series of examples that will hopefully replace it, because I've seen so many new players develop bad habits because of it.

The issue is that if anyone wants to read it besides yourself, it's just not easy to read and understand. For example in chinoto's example expression, "EU*EA:pitch(),EV+EF*Lev" is a complete mystery on its own. Even if you backtrack and read through how all the variables are assigned, they're so similar it can quickly become confusing. It's a textbook example of how not to name variables. The formatting is also particularly bad, because it lacks proper spacing and line breaks. It's as though the main objective was to save space, which is completely unnecessary. This is fine if that's how you want to write yourself, but it's really not suited for examples and tutorials. The main objective should be to make everything as easy to understand as possible.

I'm probably coming off as more harsh than I should, so don't worry too much, I don't really blame you and I'm not trying to detract from your tutorial. I'm just a bit frustrated after seeing yet another player following poor examples. Also, I don't intend any offence towards chinoto, but I feel it's something that needs to be said straight. chinoto probably wrote it that way with the best intentions, but like a lot of people who have no past experience of programming, it's easy to develop bad habits early on and not even be aware of them. As a disclaimer, I'm in the same boat; I'm not a programmer, but I know poor writing when I see it.

[mjmr89]

You have a good point that they shouldn't be in a tutorial, so I replaced them.

[Jimlad]

Good to hear, that reads so much better now. It's refreshing to see people picking up on the correct usage of the inertia() function as well.

[eduardo]

Handful nubbin heros tutorial yes imma like memorize this shit thank you


postreading: i liked it thanks for your help on my thread

[Lyinginbedmon]

I'm having some issues with the stabilisation code.

Everything validates alright, but the chip doesn't seem to actually have any effect. I fiddled around some more and figured out that the applyForce definitely is doing something (Largely by making an insta-death frisbee with no stabilisation whatsoever) but I can't get the contraption to stay stable at all, it just goes wherever I make it with the physgun, including spinning like a gyroscope into the distance.

[mjmr89]

I should (and will) mention that when using it on a chip, you need a fairly low multiplier. I think I used something like 4/100 or something in that range.