[FUBAR-BDHR]

Off topic but easy way to set up turret fire points:  Make a copy of the working model and delete everything but the turrets and bases.   Select all bases and center to 0,0,0.  Select the center of each barrel and there you have your coordinates to enter into pcs2. 

[Spicious]

Firepoints are meant to be relative to the barrels? Why has this never been reported before?

[FreeSpaceFreak]

No-one bothered enough, I guess. It only becomes really apparent when setting up non-orthogonal multiparts, where the firepoint will actually end up outside the barrel instead of just deeper/less deep in it.

[Spicious]

It's an easy fix; sig build updated.

Fixing Collada import/export to work properly with multiparts is a bit more complicated though. I guess single-part and multipart firepoints are going to need different names.

Edit: Multipart firepoints should be under a helper named multifirepoints as a child of the barrel helper.

[FreeSpaceFreak]

Kewl

[Spicious]

1) Switching the 'Movement type' and 'Axis' options to be radio buttons would make them a lot faster to use

More or less done, but given that models aren't restricted to these combinations, which should take priority: no movement or a rotation axis?

DEFINITELY change the "Parent" and "Physical" labels to "Turret Base" and "Turret Arm" respectively!!!

Done.

[attachment deleted by admin]

[Vasudan Admiral]

Awesome!
What do you mean they're not restricted to those combinations though? Subobjects either rotate or don't right? I don't think I've missed subobject translations happening have I? <_<

I'd get it defaulting to no movement definitely as is.

[Spicious]

With radio buttons there are 4 choices, but there are 4 other (inconsistent) possibilities in terms of rotation axis and rotation or no rotation. If it's set to rotation but no rotation axis, this is interpreted as no rotation, no axis. No rotation with an axis set is what I was asking about. I'm interpreting this as no rotation, no axis.

[FUBAR-BDHR]

Very bad example as turrets should never have rotation.

Which brings up this idea.  Can you filter things with turret in the name and auto set them to none and make it unchangeable? 

[The E]

Automatic defaulting to none: Yes. Locking it down to none: Bad idea.

[Spicious]

Locking it will just result in angry and/or confused users.

[FUBAR-BDHR]

Well then how about a message that you aren't supposed to have rotation defined for turrets and anything with turret anywhere in the name is considered one by the engine?

[Vasudan Admiral]

Huh? Since when has defining axes of rotation for multipart turrets been a nono??

Spicious: Ok yeah I get what you mean now - dealing with what are basically POF data errors. Good question, and I guess it would have to depend on how FSO interprets it. AFAIK if 'Rotation' is not set OR no axes for the rotation is defined, the object won't rotate, so based purely on that assumption defaulting both to the 'no rotation, no axis' case is best.

I can't think of any time I've seen anything other than that happen.

[FUBAR-BDHR]

While technically not illegal there have been at least 2 problems caused by it.

First is rotation without axis.  There must have been at least one version of PCS2 that auto-assigned rotation but no axis to turrets which is not allowed.  I've also seen several cases of axis defined but no rotation. 

Second if you do define it and give it $rotation or $stepped as well it is actually illegal. 

So if you are going to do turrets you need to use uvec/fvec (unless it's on the top facing forward or bottom facing backward like in retail) and define the rotation speed on the $subsystem line. 

[Vasudan Admiral]

Well yeah those cases of rotation but no axis or vice-versa and using the $rotation or $stepped flags on a turret are just ones of faulty POF data.

However to set up a basic rotating turret, you set the base to be rotating around Z, and the arms around X. So defaulting the settings (let alone locking them) to 'no rotation' and expecting the user to use u/fvecs would break almost every model with turrets done that way when opened in PCS2.

[FUBAR-BDHR]

No you don't.  Turrets need no rotation entries in the pof.  In fact those axis entries would be incorrect to begin with.  It anything it would be Y for base and z for barrels.  This kind of information is part of the problem.

An example:  B5 rotates around X axis.  If a turrets barrels rotated that way they would turn sideways instead of elevating. 

[chief1983]

So retail FS2 models don't have rotation info set for their turrets?  Because I had been under the same impression as VA, that standard turrets could set a rotation axis.

[FUBAR-BDHR]

Code: [Select]

pm->submodel[n].movement_type = cfread_int(fp);
pm->submodel[n].movement_axis = cfread_int(fp);

// change turret movement type to MOVEMENT_TYPE_ROT_SPECIAL
if (pm->submodel[n].movement_type == MOVEMENT_TYPE_ROT) {
if ( strstr(pm->submodel[n].name, "turret") || strstr(pm->submodel[n].name, "gun") || strstr(pm->submodel[n].name, "cannon")) {
pm->submodel[n].movement_type = MOVEMENT_TYPE_ROT_SPECIAL;
} else if (strstr(pm->submodel[n].name, "thruster")) {
// Int3();
pm->submodel[n].movement_type = MOVEMENT_TYPE_NONE;
pm->submodel[n].movement_axis = MOVEMENT_AXIS_NONE;
}else if(strstr(props, "$triggered:")){
pm->submodel[n].movement_type = MOVEMENT_TYPE_TRIGGERED;
}
}
No matter what you set there the type gets changed from rotation to rotation special for turrets.  This basically causes any rotation info to be skipped.  Multi part turrets must either have the barrels facing up and the turret facing forward, the barrels facing down and the turret facing backward, or a uvec/fvec definition in which case the uvec is the axis of rotation for the base and the fvec determines elevation. 

[Vasudan Admiral]

Just tested to confirm (before you posted to relevant code) and yeah you're right. (obviously now) Multipart turrets don't need any rotation details in the POF.

That's lame! We've been taught to do that since the modding cradle, and have been telling others to do the same the whole way! I have been propagating liez! 

Well one final question then:

a uvec/fvec definition in which case the uvec is the axis of rotation for the base and the fvec determines elevation. 

I've never actually used them, but my understanding of off-axis rotation is that fvec refers to the forward vector of a turret base rather than the current barrel elevation. The barrels should always be pointing along the Uvec line in the POF itself. Is that not correct?

[Spicious]

That code snippet looks horribly brittle. And the correct rotation axes would have been Y for the base and X for the barrels.

That sounds about right on uvec/fvecs.