Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Bobboau on November 11, 2006, 06:55:34 am
-
[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 (http://freespace.volitionwatch.com/blackwater/fs2_open_Bobboau_11-11-06.zip) is the executable, and here (http://freespace.volitionwatch.com/blackwater/turret_test.zip) is the test data you can use to test it or figure out how to set the stuff up.
going to sleep now.
-
Great...
What is it?
-
If this is what I think it is, Bobb is my favourite person ever!
< Goes to re-install FS2 after his Hard Drive crash > ......
-
Opens data in modelview.
:jaw:
-
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.
-
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.
-
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.
-
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... :doubt:.
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.
-
You're asking people to bug test. They should run a debug build anyway :)
-
true, but I was mostly doing this just to let people know I was working on this.
and it does work for you?
-
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 :p
-
if it becomes an issue I might, or I might make that dynamic.
-
very nice, now explain:
$uvec: 0,1,1
$fvec: 0,0,1
-
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'
-
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.
-
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.
-
I want the HLP highlights back!
Great work Bob, I'll have something to test your feature soon. ;)
-
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.
-
Sweet!
Bet Omni will be happy to hear about this... :p
-
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.
-
Bookmark this topic.
-
Forgive the obvious lamen here, But i assume that we will now have side mounted turrets?
Resulting in mega broadside style death? :) :confused:
-
As soon as this hits CVS (which might take a while), yes.
Thanks Bob for working on one of the oldest requests ever.
-
Whoopee, i'll cgheck up on the progress of this when i get back :D :yes:
-
Heh, I'm going to have to go and relearn vectors again now :D
-
Sweet!!!
Having a problem though.... The actually bolt is coming from the wrong place, no wheres near the actually turret itself. The firepoint in modelview shows up correctly and the y axis in truespace is showing up pointing forward/outward.
-
what are you sub object properties?
describe the turret in more detail (or post a screen shot)
-
Ugh not having much success...
Ok if I had a turret with a normal of (-1,0,0) [facing straight out port side]
would the uvec be: -1,0,0 (pointing in the normal's direction) or would it be 0,-1, 0 (pointing straight up)?
and the fvec be: (0,0,-1) (pointing straight forward)
?
-
well you are defining what is up and forward for the turret so your uvec should be -1,0,0 and the fvec should be 0,0,1 (what you had is backwards).
keep in mind that the turret has to be modeled to look like this before you add this stuff in.
-
Ok that helps a bit... the turret barrel is tracking the target correctly (or at least it seems) but the firepoint is way off
(http://img.photobucket.com/albums/v356/Shodan_AI/misaim.jpg)
Also would it be possible to lock an axis for the up arrow (like the X) and forward (the Y axis) automatically so you wouldn't need the uvec and fvec?
-
can you give me that test pof?
-
Sorry had to leave for a while...
It's probably something stupid I'm doing that works ok in the normal version.
http://www.wcsaga.com/~team/Scooby/Custom_Mod/test_turret.rar (http://www.wcsaga.com/~team/Scooby/Custom_Mod/test_turret.rar)
-
ok, I think I see what's going on, all my test models used arms that were centered on the bas, this has a rotation point well above it, I guess I've got something to fix then.
-
huh? it should be centered on the base.... the arm's pivot point is right next to the turret base, and the turret's base should be centered on the base box.
edit: how do i visually check where the pivot points are in modelview?
-
if you hit the 'rotate parts' button it'll show it. (sometimes)
it's not centered on the base it's centered (from the turret's perspective) above it, in all my test data the base and arms were in the exact same position, so I didn't catch this till just now.
funny thing is I could have sworn I took care of the function were the problem was in, oh, yeah, fixed it.
http://freespace.volitionwatch.com/blackwater/fs2_open_Bobboau_11-19-06.zip
-
I think you fixed it! :)
Now I can go back and start thinking about how to side mount my cap ships. If they're complaining about features being added and not used... this definetely won't be one of them!!!! *bounces up and down happy with joy*
-
keep in mind this isn't going to be in any official builds until after the next release. so don't do anything that's going to be mission critical with it untill after that.
though with the new branching thing I'll probly get it committed soonish.
and don't forget that you can do more than just side mounting, you can put a turret at prety much any angle you can figure the uvec for
-
Any idea how soon will that be?
If nothing else I think I can get by by using a "fake" version (i.e. not multi-turret) until then and then just change the turret's arm to the real arm
-
that could work.
-
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.
Except when you are given no clue as to what the problem is.
Only just got round to trying this... but the build just quits on me. I just get Windows' 'this program has performed an illegal operation and will be shu down. Sorry for the inconvinence.' message. :hopping:
the 29th August 3_6_9 build runs fine for me, but any debuild just gives me that ^.
I'll try ripping out all my mod tables and try again... :sigh:
EDIT: Nope, still didn't work.
EDIT2: BTW, I was trying the build in the first post, if that makes any differance.
-
all debug builds cause this problem (not just mine)?
-
All the one's I've tried.
-
Well this feature is already being put to use.... :D
(http://img.photobucket.com/albums/v356/Shodan_AI/rak-1.jpg)
(http://img.photobucket.com/albums/v356/Shodan_AI/rak-9.jpg)
I just need to get out of the top/bottom turret mindset...
-
How about some in action pics? :p
-
Well I tried... just that the turrets use fast blob weapons, so they don't show off very well, that plus the fact i can't hit the print screen fast enough :P
Btw, bob could we get a release version of this? Nothing like having to hit "n" a couple million times because it's complaining about depresiated flags (probably the no damage from subsytem to parent entry).
-
yeah, someone made a syntax change, honestly it's a lot cleaner, rather than put +non-targetable +no damage
on diferent lines you put it in $flags:("non targetable" "no damage")
like ship flags.
...anyway nice work so far but don't limet yourself to just putting them on the sides, you could put them on those slanty bits too.
-
Bob, if you were a woman, I would marry you! :D
THANK YOU FOR THIS!!!!!
-
Is there still a cap on maximum number of multipart turrets? I'd like to try this code with Galactica's 175 AAA turrets.
-
I think thats part of PCS's problem too Omniscaper.
-
yeah, someone made a syntax change, honestly it's a lot cleaner, rather than put +non-targetable +no damage
on diferent lines you put it in $flags:("non targetable" "no damage")
like ship flags.
...anyway nice work so far but don't limet yourself to just putting them on the sides, you could put them on those slanty bits too.
or you can use something like the turret i posted on the recent builds thread. i also have a couple more ideas to try, just havent modeled up the tests yet.
is it just be or does there seem to be some collision detection issues. seems like some of the shots are passing through the base or barrel models, or their explosions and other effects arent being rendered.
-
I have been worried about colision detection problems this whole time, and is principly why I haven't commited this yet, problem is when I explicitly try to shoot at a turret it seems to hit.
-
i figure its just a matter to make the collision trees rotate with the models. i think its just a matter of their range of motion being limited to a fixed range. of course i havent looked at the code and im really talking out of my ass.
-
you've got it sort of backwards, the point's being collided with get rotated into the object's normal rest position, I inserted the optional axis into the code in the same way it got inserted every were else so it should be working, but things might be diferent.
-
well im glad i got it bass akwards, rather than completely wrong :D
but that makes sence, why rotate something as vast as a collision tree when you simply just need to rotate a couple of shots.