[FUBAR-BDHR]

I've noticed that not all the available properties appear in the drop down box under properties.  Could they be added?  Some are new ($lod0_name=) but some have been there for ages. 

[Spicious]

If you post a list of missing properties, I can add them. I won't be rebuilding the windows executable for probably at least a week though.

[FUBAR-BDHR]

I went through the code and this is everything I found.  I know some are already there but it was easier to list them all.

$name=<string>		Subsystem name
$fov=x		Turret field of view default 180
$crewspot=<string>		Not used
$rotate=x		rotation speed
$pbank=<bank>		use with $rotate for weapon controlled rotation
$stepped		use with $rotate for stepped rotation
$steps=x		use with $stepped number of steps default 8
$t_paused=x		use with $stepped pause time default 2.0
$t_transit=x		use with $stepped transition time default 2.0
$fraction_accel=x		use with $stepped fraction of time spent in accel default 0.3
$triggered:		animation code key
$dumb_rotate:		no idea only comment is "Iyojj skybox 4" default 0.0
$special=subsystem		defines subobject as subsystem
$special=no_rotate		marks submodel which should not rotate
$no_collisions		causes subobject and all under it not to have collision detection
$nocollide_this_only		cause only this subobject not to have collision detection
$collide_invisible		subobject should collide even if invisible
$gun_rotation:		for animated weapon models
$lod0_name=<string>		name to use for LOD0 for adding LODs to old models
$detail_box:		defines this subobject as a detail box
$box_min:x,y,z		$detail box minimum coordinates
$box_max:x,y,z		$detail box maximum coordinates
$uvec:x,y,z		turret orientation up vector (normal)
$fvec:x,y,z		turret orientation front vector

[Bobboau]

it would be nice if uvec and fvec were actually produced on the fly when the POF was saved, and the submodel given an orientation matrix.

dumb_rotate is a different way of implementing rotation, where the angle of rotation is a function of time, this causes the rotation to show up in all circumstances, not just when attached to a subsystem on a ship, so for instance you can get rotation subobjects in skyboxes, or missiles.

[Spicious]

it would be nice if uvec and fvec were actually produced on the fly when the POF was saved, and the submodel given an orientation matrix.

I'm tempted to try this. It's more or less what I'm planning for the Collada importer/exporter.

[headdie]

it would be nice if uvec and fvec were actually produced on the fly when the POF was saved, and the submodel given an orientation matrix.

I'm tempted to try this. It's more or less what I'm planning for the Collada importer/exporter.

yay working multiparts on non vertical axis

[pecenipicek]

it would be nice if uvec and fvec were actually produced on the fly when the POF was saved, and the submodel given an orientation matrix.

I'm tempted to try this. It's more or less what I'm planning for the Collada importer/exporter.

yay working multiparts on non vertical axis

they work now too, its just a pain to figure out the uvec and fvec if you didnt do it a million times before.

[headdie]

it would be nice if uvec and fvec were actually produced on the fly when the POF was saved, and the submodel given an orientation matrix.

I'm tempted to try this. It's more or less what I'm planning for the Collada importer/exporter.

yay working multiparts on non vertical axis

they work now too, its just a pain to figure out the uvec and fvec if you didnt do it a million times before.

that's what I meant lol 

[Spicious]

The subobject properties suggestions should match the list of available properties now.

Feel free to provide sample models for uvec/fvec importing. Create a helper called vec where the forward and up directions point in the fvec and uvec directions, respectively.

[FUBAR-BDHR]

You need to remember that some axis info is flipped int he fvec/uvec stuff.  For instance yesterday I was just fixing some on the TBP Hyperion.  Turret faced forward and the normal was 1:0:0 but the while you would think that would be uvec:1,0,0 and fvec 0,0,1 you would be wrong.  the uvec was -1,0,0. 

[Spicious]

That would be pcs2 flipping the x-coordinates of everything. I'm still not sure why that's done.
I'm planning the same sort of idea for rotations: add a rotate helper pointing in the axis of rotation and you'll get rotation around the closest standard axis.
Any objections/suggestions?

[FUBAR-BDHR]

Actually it's not PCS2 flipping x axis but half the SCP code expecting flipped axis and the other half not. 

BTW I take back what I said about the PCS2 interface being screwed up.  It seems to be fixed in the latest.  That hold shift to zoom crap was awful. 

[Spicious]

PCS2 is definitely flipping the x-axis.

uvec, fvec and rotate should export and import to/from Collada now. I haven't tested it beyond a simple example so axis flipping may occur.

[FUBAR-BDHR]

I wasn't talking about PCS2 to collada flipping the axis I was talking about PCS2 to pof and the code axis info.  Some things like the uvec/fvec are specified in the code flipped as others take the info just like it is in PCS2.  Tabled thrusters are another one (although not part of PCS2) they are opposite PCS2 thruster info. 

I haven't tested but is rotate still getting set on turrets?  It's not supposed to but did in some versions.  Turrets should never have rotation or axis defined.  While the code doesn't ***** about it like it does with other rotating subobjects it can't be good.

[Spicious]

Rotations are no longer being set on turrets on import now.

[FUBAR-BDHR]

Yea I should have checked email from mantis before I posted that. 

[Spicious]

I guess this is a "known issue:" exporting with rotations or uvec/fvec tends to leave behind blank lines in the subobject properties.

[Spicious]

fvec and uvec x-coordinates should be correct now. A few other things have been fixed/added too.