Abnormal location of [0,0,0] pos of vehicle

[chris330 0]

I'm not sure how many other people have been this far into this subject but I suspect it cannot be many. It appears to me that when pitching an aircraft - in this case a helicopter - forward the vehicle's frame and amazingly it's geometry LOD too, do not rotate around it's [0,0,0] reference position.

I've written my own optimised version of Dschulle's getpitch function which I thought might be causing the problem at first. It wasn't. A simple hint loop running values for both functions side by side provided no discrepancy between them.

Further checks seem to reinforce the conclusion. Placing an object at the helicopter’s [0,0,0] position in a 0.001s loop and then flying the helicopter shows the object move way forward of the initial position relative to the chopper's body.

Placing a game logic at the vehicle's [0,0,0] (or [x,y,z] whichever you prefer to term it) and then running a loop showing distance values between it and the pilot proves it also. If the chopper was pivoting about the [0,0,0] position then the distance between it and the pilot would always be constant.

But here's the really weird thing. Even though it isn't pivoting about the [0,0,0] position the distance between that and the pilot should still be the same. But it isn't! So doesn't this mean that the vehicle's [0,0,0] position is actually changing its relative position to the vehicle's frame when it's pitching forward.

Very strange stuff indeed! It can still be compensated for though, it's just I wouldn't have expected it. I also have to wonder how my pitching camera script ever worked though given that this is the case. The camera was pointed at a game logic being constantly set to the vehicle's [0,0,0] position and its offset values changed depending on the chopper's pitch. Worked perfectly.

If the getpos command will return [x,y,z] co-ordinates for a camera's position I might run this script again and try and see how the pitching camera script ever worked. An ODOL open of the AH1 might be in order too.

I'd appreciate any advice anyone could offer. This is a pretty tricky problem.

[chris330 0]

Here's the proof:

Proof Demo

Put the cylinder.pbo in your addons folder. In the script proof.sqs trying changing the camera's target from _logic to _heli and back again or vice versa. It should give the same result both times. It does not however.

When placing the cylinder _c1 at the camera's postion when it is targetted at the heli it moves round with the heli normally as the heli pitches. Not so with the logic, and the logic is positioned at the vehicle's [x,y,z] coords. It behaves very differently here.

In fact it appears to be advancing in a line through some point on the vehicle's body and its proximity to that point depends on the heli's pitch. Why the hell it is doing this I really don't know but it happens for all the default aircraft. I'm using the AH-1 as it's the closest to the base helicopter class.

This is extremely unusual behaviour and most unexpected indeed. It appears Flashpoint's amazing quirks are seemingly endless and just when you think you know it all, something new and really fundamental pops up.

Getting back to the original reason for this investigation I could potentially set the cylinders to the points I wanted to by placing cameras there, but this introduces objects into the game which don't need to be there and it's unclean.

I'd rather compute their positions as it will result in much neater and optimized code. It's nice to have just discovered that you can setpos objects to a camera's [x,y,z] co-ords aswell. I didn't know you could do that before this morning. Might be useful for some kind of tweaked height above sea level function. Who knows. I'm sure they'll be a use for it.

Anyhow back to work. This thread can be closed now as I've got the info I wanted myself, unless anyone has something useful to add or wants to discuss the findings.

[vektorboson 8]

That's actually a really old issue. It's known as the setpos/getpos bug.

The problem is that every object has three (or more?) different types of "centers" calculated from its LODs. Ie you have the model center, you have the "calculated" model center (from the most extending vertices) and you have the weighted center (from the Geometry LOD).

Now, different scripting commands may use different centers and you get those quirks.

[raedor 8]

Did you try the new commands modelToWorld and worldToModel? Maybe they can help further...

[UNN 0]

If it's OFP your working with, then try setting Autocentre to false in the config. That way it should rotate around the position [0,0,0] as defined with O2’s coordinates.

[chris330 0]

Ah some help arrives yay! Had no idea that bug was already known about. I've completely missed it up to now. Thanks for explaining how it works, that will skip me past so much investigation work

I will check out those world to model command also but I'm working in Flashpoint I think perhaps they are only for ArmA?

Thanks UNN. That's a great suggestion. I'll give that a try

**Edit**

Done a bit more work on it. Setting a camera to target the heli puttng it at relative position [0,0,0] and then putting a logic at the heli's [0,0,0] position gives this. The cylinders are placed the the co-ords of the camera and the logic:

They remain in a vertical line regardless of pitch:

So it can be done via calculation, without a config alteration. Using the predicted plot of an object relative to the vehicle's frame contrasted with where the actual [0,0,0] is being set by the engine means the change in respect to the vehicle's frame of the [0,0,0] can be accurately predicted and worked into my setpitch function in the other thread.

I'm definitely going to try out that autocentre thing though. That's a really good find.

I'd never have believed something this simple could be so difficult. I don't know about you but for me it's one of the highlights of working with Flashpoint

[chris330 0]

Lol it still don't work perfectly. There's only so many quirks I can personally deal with and I think after this:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_c1=_this select 0

_heli=_this select 2

_logic="logic" camcreate[0,0,0]

_cam1="camera" camcreate[0,0,0]

_xh=getpos _heli select 0

_yh=getpos _heli select 1

_zh=getpos _heli select 2

_cam1 camsettarget _heli

_cam1 camsetrelpos [0,0,0]

_cam1 camcommit 0

_logic setpos[_xh,_yh,_zh]

_hhcf=_cam1 distance _logic

#loop

_heli call drops

_pitch=[frontdroparray,centredroparray] call calcpitch

_ta=_pitch

_xh=getpos _heli select 0

_yh=getpos _heli select 1

_zh=getpos _heli select 2

_ohhf1=(sin(90-_ta))*_hhcf

_ohhf2=_hhcf-_ohhf1

_ycf1=(cos(_ta))*(cos(90-_ta)*_hhcf)

_zcf1=(sin(_ta))*(cos(90-_ta)*_hhcf)

_ycf2=(cos(_ta))*_ohhf2

_zcf2=(sin(_ta))*_ohhf2

_c1 setpos[_xh+8,_yh-_ycf1-_ycf2,_zh+_zcf1-_zcf2]

_cam1 camsetrelpos [0,0,0]

_cam1 camcommit 0

_string=format["Variable=%1",_c1 distance _cam1]

hint _string

~0.001

goto"loop"

....it's time to explore another avenue. Namely using cameras. It almost works it just bows in about 0.01m halfway between 0 and 45 degrees but I can see it's a further game quirk for which I do not have the inclination to find a work around.

I think now I'll look at creating one camera and then setposing other ojbects relative to its position. At least that way I get good positional data at the cost of creating only one camera. I'll have a rummage round on the island later and check to see if this will work the way I hope it will

[chris330 0]

Lol I'd be almost ready to hang myself here if I was still as uptight as I used to be several years ago. Had to give in and go the camera route for all objects. Something wierd is happening with the way the camsetrelpos command works. It isn't in the linear fashion you would expect and is in some way related to the vehicle's frame or the flashpoint core engine flight model.

Just making a camera for each object and camsetrelpos'ing it then placing required objects at returned [x,y,z] values for the camera took care of it. I just can't stand the stress of going into it further.

I'm still a little worried though about this being a resource hogging way of doing it. This is really not my area but can someone with some hardware knowledge enlighten me.

Am I worrying too much about increasing CPU time by using cameras instead of computed [x,y,z] positions for the placed objects? Eventually the setpitch function could have maybe 6 or more cameras running per vehicle? Is this a problem or is it insignificant given how much the CPU has to work just to render the vehicle's various LOD's?

I intend to wrap everything up into functions also. I could use a little pointer here thanks