Whats different about vector thrusters compared to wired normal thrusters?

[mjmr89]

I know the obvious differences, I'm talking about the technical differences. I've tried many times to use vector thrusters on the world z axis for hovering/selfbalancing things, but they are really odd - they sort of "jump" around. They'll have bursts of power every second or so, really uneven and obviously doesn't make for good hovering... Why is this?

[Jat Goodwin]

Try the local Z axis, that may work a bit better.

[Babb517]

The major difference between local and world is the point of origin.... if you want it to use a point of origin at 0,0,0 on the map than use world, if you want it to have its point of origin at the location of the vector thruster than its local....
The reason why a vector thruster will jump like that is probably because it cannot output force in multiple directions simultanously, so to have a thruster stabalize all movements (X,Y,Z,Pitch,Yaw,Roll) it will try to find the average of the movements to cancel out as much as possible, this is very good in zero G but the thruster does not take into account the second it stops firing down in normal G, the ship will begin to fall.... As such it helps to have one system regulating up down movement, and a second system of thrusters working on all the other axis' and rotations, that way it will never compromise the gravity negation to stabalize it otherwise.

[mjmr89]

No no no, I should have been clearer. What I want to use the VTs for is keeping a stable height. That's all - I will ONLY be inputting the Z value. Though Babb, that does seem to explain why when I try to use VTs for air resistance in the x and y direction, it sort of spirals to a stop.

Anyway, Jat, the only reason I'd want to use the VTs is so that if the thing that is hovering is tilted, even for a little bit, the angle of a normal wire thruster would be a bit in the non-z axis', causing drifting. I figure with VTs on the world axis, they would only push straight up and down, therefore not causing the drift if the plate is unbalanced for a little bit.

Though I have noticed something very interesting with the E2 - I'm using the same concept in my expression as I did with E1, but now my hovering things tend to counterbalance the drift if they drift at a low speed - like it will go a couple degrees in the opposite direction of the drift so to neutralize it. It's really odd. Good odd, but still odd.

[Babb517]

unfortunately, I'm in the same boat as you in this case... I've been toying around with this for some time to stabilize ships in varying amounts of gravity for spacebuild, what I'm currently toying around with is this.

@name X400
@inputs T1:wirelink T2:wirelink T3:wirelink
@outputs
interval(20)
TM = 500
Downvel1=T1:entity():vel()*-T1:entity():up()
Mul1=Downvel1:length()
Downvel2=T2:entity():vel()*-T2:entity():up()
Mul2=Downvel2:length()
Downvel3=T3:entity():vel()*-T3:entity():up()
Mul3=Downvel3:length()
if(0<Downvel1:z()<25){
T1:setNumber("X",Downvel1:x()), T1:setNumber("Y",Downvel1:y()), T1:setNumber("Z",Downvel1:z())}
if(0<Downvel2:z()<25){
T2:setNumber("X",Downvel2:x()), T2:setNumber("Y",Downvel2:y()), T2:setNumber("Z",Downvel2:z())}
if(0<Downvel3:z()<25){
T3:setNumber("X",Downvel3:x()), T3:setNumber("Y",Downvel3:y()), T3:setNumber("Z",Downvel3:z())}
T1:setNumber("Mul",Mul1*TM), T2:setNumber("Mul",Mul2*TM), T3:setNumber("Mul",Mul3*TM)

You Might try checking out this thread:

http://www.wiremod.com/forum/wiremod-challenges/5648-space-stabilization-challenge.html

A couple of notes about the code, that is for height stabilization only, and it will not work its my first attempt at a different approach to stabalization (I've tried a good 5 different approaches with no success) and as such is flawed, I post it merely as an example... although if somebody can give me some tips it would be nice.

[mjmr89]

I'll take a look at that a little later (busy atm) - but I was thinking someone should make an option for XYZ LOCAL speedo speeds. So I can hook a couple thrusters to a local speedo and cancel out drift that way. Or I can take the whole "tilt to cancel" idea that E2 inadvertantly uses a bit higher and do it on purpose.

[mjmr89]

Huh...I just tried it with world z VTs and somehow, IT WORKS! I dunno, I guess it was a bug or something - the last time I actually tried it was a couple months ago. Well now it works perfectly! My test plate can go to maybe 40 degrees before launching whatever was causing that degree change off with very little movement. It also seems to slow itself like I explained.

Babb - would you mind explaining that code a bit? You say its supposed to just stabalize height, i.e. stay at a specified Z value? That's quite simple if that's all you're trying to do
ZThrust = DiffZ + $DiffZ*Mul
DiffZ is your target Z value minus your current Z value, and the Mul is just a multiplier to tune it. You can also tweak the oveall multiplier value (by changing the thruster value or something) and that would also tweak it a bit.

Oh, something odd about the vector thruster setup I have - it only seems to work if I have the ZThrust value wired up to the "Mul" and my "on/off" switch up to the Z value. I don't know why this is, but oh well. I wish it was the other way around so I could hook maybe my forward thrust up to the one VT.

[Babb517]

Huh...I just tried it with world z VTs and somehow, IT WORKS! I dunno, I guess it was a bug or something - the last time I actually tried it was a couple months ago. Well now it works perfectly! My test plate can go to maybe 40 degrees before launching whatever was causing that degree change off with very little movement. It also seems to slow itself like I explained.

Babb - would you mind explaining that code a bit? You say its supposed to just stabalize height, i.e. stay at a specified Z value? That's quite simple if that's all you're trying to do
ZThrust = DiffZ + $DiffZ*Mul
DiffZ is your target Z value minus your current Z value, and the Mul is just a multiplier to tune it. You can also tweak the oveall multiplier value (by changing the thruster value or something) and that would also tweak it a bit.

Oh, something odd about the vector thruster setup I have - it only seems to work if I have the ZThrust value wired up to the "Mul" and my "on/off" switch up to the Z value. I don't know why this is, but oh well. I wish it was the other way around so I could hook maybe my forward thrust up to the one VT.

the odd thing yoiu speak of is because if your only using Z it should be set to 1, and the Mul(Multiplier) should be set to whatever you need the Z speed to be. First off, I've fixed maybe a dozen glaring errors in that code since I posted, most obvious was that I was using a - multiplier to determine its thrust down, so it would always increase the direction it was going in instead of decrease.
The code itself is meant to be adaptive and used for a fighter jet, as such it has no such (target Z) value, its meant to merely prevent it from falling from whatever height it is at.