Well he could, but that would just take all the mystery out of me wouldn't it?
Ok so Talon: You're on the right track with how to do that in Blender. "Ctrl+A -> Apply scale and rotation" with all objects selected. When you export to DAE you want them
all to read 0° rotations, and 1.0 in scale. (Otherwise chances are that PCS2 will
make them into 0° and 1.0 with no regard for what that does to the model!)
Note: The POF format as far as I can tell, doesn't care at all about subobject rotation. I don't think it even stores it. So however something appears in a POF has no rotation in-game unless that is defined for that subobject, and then the game will handle that.
Anyway so we managed to get the look_at function working...sort of. We found that a lot of the problems I was having were actually due to naming my test model's hydraulic rams things like 'Ram1_A' and the matching 'Ram1_B', all because FSO unhelpfully interpreted them to be different LODs of the same object, which then didn't play nice with the look_at code.
But where it stands now is that if your look_at enabled subobjects are attached to the hull, or attached to another subobject that is attached to the hull, then they will work fine:
http://slickpic.us/1092822NDVlWhere it fails is anything further down the hierarchy than that - the further down you go, the more your look_at subobjects will miss their target by. That implies to me it's a cumulative error in the code that runs through the hierarchy to work out where things are in relation to each other.
If people want to have a look themselves, here's a test model with a table and test mission: (Though you'll need Goob's latest builds, which I don't think he's posted here)
http://www.mediafire.com/download/j27ifbegf9q63cr/LookAtTestRod_H.zipThe key "1" extends the 3-segment arm, "2" retracts.