[Bobboau]

[edit]now that I'm not asleep I changed the title to make it a bit more noticeable.[/edit]

been up all night working on this damned little thing, would have been easy if the stupid matrix functions would have been precise enough to have it not require implementation on a low level,but here I am, got it working, at least to the proof of concept stage.

anyway, did some work on the turret code you all will like, here is the executable, and here is the test data you can use to test it or figure out how to set the stuff up.

going to sleep now.

[Woolie Wool]

Great...

What is it?

[Flipside]

If this is what I think it is, Bobb is my favourite person ever!

< Goes to re-install FS2 after his Hard Drive crash > ......

[karajorma]

Opens data in modelview.
 

[Woolie Wool]

Ugh, use a less irritating debug build. I don't want to change stupid bull**** things normal builds never notice just to make the damn thing run.

[karajorma]

The build works without giving me a single debug error. I suggest you clean up your FS2 folder rather than trying to blame Bob's build. Those errors you consider unimportant are probably causing mysterious crashes.

[Shade]

Not to mention one of the reasons for debug builds is that they ***** about things that might cause problems, even if they are minor. As Kara said, the solution is to fix the problems and not to complain about the build pointing them out for you.

[Bobboau]

the main reason I uploaded a debug build is because I didn't want to spend the time compiling a release build, when I could be sleeping, wich I would still be doing if someone in the other room hadn't decided was a good time to clank a bunch of plates together... .
so it is working for every one? turrets moving the way you'd want them too and all that.
I didn't actually test the tbm, just assumed I did everything right making the mod package.
I should note that the way I coded this 'should' allow the same thing with rotateing submodels.

[karajorma]

You're asking people to bug test. They should run a debug build anyway

[Bobboau]

true, but I was mostly doing this just to let people know I was working on this.

and it does work for you?

[karajorma]

I'd have said something if it didn't

So far I've had no issues with it. Did you bump the number of multiparts too BTW? Cause you know people are going to start demanding that next

[Bobboau]

if it becomes an issue I might, or I might make that dynamic.

[Nuke]

very nice, now explain:

$uvec: 0,1,1
$fvec: 0,0,1

[Bobboau]

up vector and forward vector, the more important of the two is the up vector, in general it should be coliniar to the turret normal, it is the axis of rotation for the base of the turret (I have code that normalises it so you just have to give a vector of the right direction). the fvec points in the direction of the front  of the turret, you don't have to be as precise with this one, all you need is to get it generaly pointing in the right direction and the underlieing code will figure out what the proper fvec should be (it will basicly project what you give onto the plane formed by the uvec)

now those two values you were asking about say that the up vector points up and forward equaly (the true in game value would be something like [0,0.707...,0.707...]) and the fvec is more or less directly forward (this will be translated internaly to be something like [0,-0.707...,0.707...]).

there is also a third vector involved that you do not have direct controle over called the rvec (right vector) generaly you will not need to cocern yourself with it, unless you have a turret that has an off center fireing arch (like the turrets that are partaly tilted forward or backward) in wich case you need to make sure that the two models have the same rvec, the rvec is formed from the crossproduct of the u and f vecs (so in other words that the uvec and fvec of both the base and arms are coplanar).
based on what you provide in the two vectors the code will construct three vectors that are completely orthoginal to each other (so you don't have to, you only need to get the uvec completely right and even then you only need to worry about direction)

in most cases you will have turrets that are just angled around one of the principal axes so once you have your uvec, you just give a fvec in the general direction (along one of the principal axes). knowing a bit about vector math helps, but you'll get the hang of it quick. don't be fearfull of words like 'crossproduct' or 'orthoginal'

[Nuke]

up vector and forward vector, the more important of the two is the up vector, in general it should be coliniar to the turret normal, it is the axis of rotation for the base of the turret (I have code that normalises it so you just have to give a vector of the right direction). the fvec points in the direction of the front  of the turret, you don't have to be as precise with this one, all you need is to get it generaly pointing in the right direction and the underlieing code will figure out what the proper fvec should be (it will basicly project what you give onto the plane formed by the uvec)

now those two values you were asking about say that the up vector points up and forward equaly (the true in game value would be something like [0,0.707...,0.707...]) and the fvec is more or less directly forward (this will be translated internaly to be something like [0,-0.707...,0.707...]).

there is also a third vector involved that you do not have direct controle over called the rvec (right vector) generaly you will not need to cocern yourself with it, unless you have a turret that has an off center fireing arch (like the turrets that are partaly tilted forward or backward) in wich case you need to make sure that the two models have the same rvec, the rvec is formed from the crossproduct of the u and f vecs (so in other words that the uvec and fvec of both the base and arms are coplanar).
based on what you provide in the two vectors the code will construct three vectors that are completely orthoginal to each other (so you don't have to, you only need to get the uvec completely right and even then you only need to worry about direction)

in most cases you will have turrets that are just angled around one of the principal axes so once you have your uvec, you just give a fvec in the general direction (along one of the principal axes). knowing a bit about vector math helps, but you'll get the hang of it quick. don't be fearfull of words like 'crossproduct' or 'orthoginal'

ive been learning a small bit about vector operations from doing scripting reading articles on normal mapping, ect. so pretty much everything you said makes sence to me. seems pretty straignt forward. now the question is whats left do do with it it? seems pretty complete if you ask me.

[Bobboau]

it might be done, but I doubt I'm that lucky. I had to add in a matrix, which I have to manually add in before normal orientation operations, because the subobjects don't use a matrix, they use a combination of angles, so every bit of code that has to do with subobjects rotating is potentially broken in a not-so-obvious way.

I guess trying it with a rotating subobject (like radar dishes) hasn't been tested yet, and should theoretically work, same with animations.

[DaBrain]

I want the HLP highlights back!

Great work Bob, I'll have something to test your feature soon.

[Trivial Psychic]

One ship to to test such non-turret rotations could be Inferno's  R1 Gigas.  It has these... things that sit on its "wings" that don't rotate, but they sit at non-upright angles and are submodels, so altering them to rotate via this system would be a good test.

[WMCoolmon]

Sweet!

Bet Omni will be happy to hear about this...

[Nuke]

the new vulture im working on has some animations which could binifit from arbitrary axes, so i can really test the **** out of that whenever i finish the model.