Did you try importing into another program?
At that point no - didn't have the time. Now that I have, unfortunately it doesn't work.
Here's a pack contining the POF, the DAE produced from it, the error log that blender produces when importing it, and the blender DAE import/export scripts for reference. Hopefully something in that will help?
http://game-warden.com/starfox/Non_SF_related_stuff/MVP3610BETA/ColladaStuff.zipI've had an idea about the turret helpers, given that turrets tend to be named all sorts of things. Instead of doing turretXX-YY, it would do <subobject name>-YY. That way it's clearer which subobjects are meant to be turrets and it's less restrictive on turret names. It's pretty much how the saver works currently. It doesn't create an entirely foolproof way to detect multipart turrets though.
Yeah that sounds fine for the firepoints of turrets.
For multiparts, hmm....
Maybe look for an object with "<subobject name>-arm" to recognise them?
Actually it would be a lot easier to just have the (in this example) thrusters being children of the parent engine object.
At least glowpoints should work like this(!)
Because that was the one big advantage of the MAX exporter. I simply set up a helper as glowpoint group (with the texture defined) and all helpers linked to hit (child of) work as glowpoint, regardless of their names, while their radius was used for the size of each glowpoint.
That doesn't sound half bad.
It would be much more organised and hence easier to modify.
One thing about thruster glowpoints is that they can be the children of either an Engine subsystem or an engine subobject model. When the parent subsystem/subobject is destroyed, the children glowpoints dissappear. To accommodate for that, I recommend the points be set up as follows:
In the top half of the pic the parent is a subobject, while in the bottom it's an engine subsystem. In both cases I have all the actual thruster glowpoint helpers set up as children of a generic "Glowpoints#" parent helper (the number is nessecary to avoid having two objects with the same name in the scene). I thought doing it this way would be best because it would allow you to have other helpers as children of the subobject to define other things such as properties.
In fact, maybe something similar could be done with the subobject properties field:
This way you would be able to 'write' multiple lines of subobject properties through the names of the children helpers (Again the ## on the end of "Properties" would just be a discarded unique identifier). The "Vectors" helper would be the one that defined both the u and f vecs with its orientation.
The full list of properties that it would need to recognise according to PCS2 is:
$special=subsystem
$name=x
$fov=180
$rotate=x
$detail_sphere:1,x
$detail_box:1
$box_min: x,x,x
$box_max: x,x,x
$triggered:
$stepped
$steps=4
$t_paused=2
$t_transit=6
$look_at:0
$uvec:0,1,0
$fvec:0,0,1
