Sorry your browser is not supported!

I say almost a cross post, it's more like a more specific version of a question posted in the newcomers corner...

I'm using roll/pitch/turn object - very cool. But for some reason, object angle z() doesn't work.

roll object left 1,rollChangeAmount#
pitch object up 1,pitchChangeAmount#
turn object left 1,turnChangeAmount#

ax# = object angle x(1)
ay# = object angle y(1)
az# = object angle z(1)

az# is always 0, whereas the ax# and ay# are ok. Anyone know what's going on?

I'm afraid this is one of the many bugs remaining in DBPro, even post patch 4. I hit it some time ago and I think the same is true of camera rotation commands. I believe that most of the 3D object manipulation bugs will be sorted in P5 (Lee etc - is this correct??)


Just have to wait for Patch 5!

Or, does anyone know of any cunning ways of extracting this info ia the 3D maths commands?

Noooooooooo.... /me waits for patch 5

Hmm... well, since object y angle() seems to work ok, I could work out the other two by having 4 limbs - front, back, left and right. I can calculate the height difference between left/right, front/band and hey presto, an angle.

Grr - work just seems to be a distraction from darkbasic nowadays

If you use free flight commands you should be working with vectors not angles!

hmm.. maybe vetors are the way to go now ...
but depends what form you want your z angle in, with free flight.

Older cheat methods involve using height ( y coord) of your free flight object compared with :-

1. another object continuosly postioned at the objects coords - set to object orientation, then set to the left or right of main object (using the new Pro command which i can't remember.... they related correctly to the current free flight angles when i tried pro for a very short while.)

2. the original free flight object turned right 90, and moved 1 unit, and then reversed to original pos. and turned left to original attitude

3. a mesh attached as limb to the free flight object and then 'offset limb' on x axis by one unit. You can hide this limb and it still ( in dbc ) reads the limb position y which is what you want .. presume this works in pro)
(By the way, this is a good method to get coords for collisions with matrix .. offsetting limb to the main collision point)

In each case the height difference is a true sine of the roll angle.
I use the sine directly ( since it's for simulation ) while others use :- asin(height difference)

I used method 2 and 3 with classic .. never had problems.

HOWEVER -- It is an angle always related to the world vertical but it is modified by the current pitch angle.
it is equivalent to sine roll * cos pitch.
It makes flight sims 'a piece of cake' as they say, but may not be what you want.
If desperate you could possibly correct this z angle using the known pitch angle ?

And here's another thing.
DB classic 1.13 read this z angle also related to the world but not to the cos pitch., though it did go very quickly to zero z angle when the pitch approached vertical up/down.

At the same time , to get this z angle they had to use a ( possibly quarternion) method which produced an x and y angle that were NOT related to the world direction consistently.
These angles were the equivalent euler angles which would 'combine' to make up the same orientation as the free flight object, but they are little use for anything else and you have to find the pitch and direction related to the world another way.

YOu say the pro x,y angles currently return okay , so if DB pro changes to give you a z angle it would probably have a similar side effect as in classic. I always thought it would be easier if you could get returned angles in both styles.

keep the object x,y,z angles as on db 1.13, and add something like :-
object direction
object pitch
object roll

direction and pitch as on pre 1.09 DB and the roll as on later versions.

DB classic can read these from the 'limb direction x or y' (object, 0)but possibly pro doesn't?

So vectors may be another way to go .. experts ??

Vectors? I thought it would be quicker with matricese. I think I've seen matrix and vector synonomys. Arg! Math makes me crap my pants. It's ok, but I never took calculus so I get a little lost on that stuff and self-teaching has been too slow for now.

1. never worked for me.

2.haven't tried it

3.haven't tried it

Email Lee again.

I created 4 spheres, and at every sync, positioned them to the helicopter, then moved them away;

turn object left x,90 : move object x, 120 : turn object right x,90

I now have 4 spheres around my heli which, which some simple maths, can tell me the pitch and roll angles.

I'm thinking of using vectors for positioning though. I need to take account of too many forces just to hack this one together. The force of roll, pitch, thrust, gravity ....

If I remember my A-level maths, I just need to define a bunch of forces and dot them to get the result of the forces.

Needless to say, once I get this right, you can expect a code snippet from me

Without ZROTATE working properly, you can't z-rotate objects when you first load them.
Don't think you want to use vectors for the initial load of a static object....

W00T! I've done it, and without a single complicated mathematical operation.

Whilst walking home from work, I was getting frustrated by an apparently simple problem; I was almost there, I had the pitching/rolling/turning exactly how I wanted it - the helicopter just needs to go where it's top is pointing.

Well, the solution? Position a "target position" sphere relative to the helicopter. Using move object with every sync, I can position a target to head for...




cool! Then it was just a case of faking gravity. Tweak a couple of values, and there you are!

Lee said in his diary entry this morning that he had about 10 free-flight bug reports in his bug report folder, so hopefully he will be dealing with them asap, although there are 40-odd compiler ones to sort out as well.

aha shizzle .. well done, you can also get lift or thrust of the rotor by just pitching the heli up 90, then move 'thrust/lift' whatever. .. then pitch down 90 to original state off course.
I used this with a gravity consisting of a simple continuos downward displacement .. ie position object it own coords minus amount on y coords. (This 'gravity' has to work straight down) the heli drifts about and sideways rather well.

had to change that later and add more for speed changes in forward movement, but on the whole, the approach works great. and you need some aircraft type response once the thing starts moving forward. When you roll over at speed, the lift drops off and you need to treat the collective pitch on the rotor as a pitching effect to keep height- like an aircraft.
Have fun..!!
muddleglum