FSXA Different Prop types in one model

[TiAr]

My Cessna Soloy U206G has two different Propeller types (3-blades or 5-blades prop). Now I started to collect them in one model to control Display via configuration gauge.

I want to use animated standard sdk dummy propellers part0_still/slow/blurred with (unamimated) child parts like e.g. pblur_5prop or pblur3_prop, which are all well modelled.

The control with config gauge works great (no compiling error). I am using in modeldef L:vars e.g.

<PartInfo>
  <Name>pblur3_prop</Name>
  <Visibility>
  <Parameter>
  <Code>(L:proo3, enum) 0 == if{ 1 } els{ 0 }</Code>
  </Parameter>
  </Visibility>
</PartInfo>

or

<PartInfo>
  <Name>pblur_5prop</Name>
  <Visibility>
  <Parameter>
  <Code>(L:pro5, enum) 0 == if{ 1 } els{ 0 }</Code>
  </Parameter>
  </Visibility>
</PartInfo>

After compilation with no errors, switches to display 3 or 5-blades via control gauge are working fine, but most of the animated parts in VC are freezing.

I got the freezing if I collect propeller parts as childs with the dummies (Parts Parent). Without doing this, no freezes.

Every help is more than welcome.

Thomas

 

[Heretic]

I don't quite understand your setup. Is the parent part for both prop types the spinner?

Feel free to reply in German, if it's easier.

 

[TiAr]

Ich weiß nicht so genau, ob es ein XML oder ein Modelling Problem ist. Frage ist eher, ob ich ein Guid brauche, um spezielle animierte sdk Parts wie prop0_... mit nicht animierten Parts via Parts Parent zu kombinieren. Bisher ging es mit den Visibility-Geschichten ohne. Ich habe es bisher nicht ausprobiert, da jeder Propeller aus 3 parts besteht, mit den Spinnern sind das dann 12 Parts.

 

[Heretic]

Nein, du brauchst keine GUID für Visibility-Parts.

Wie ist das mit den Propellern hierarchiemässig aufgebaut?

 

[Anthony31]

I'm pretty sure you will need a GUID unless you are using attach points to handle the 3 and 5 blade props.

If you have a part named "pblur3_prop" and you do not use the attach point tool then I think you will run into problems.

What I do is use the spinner/axle of the propeller as the main animating part, the various propeller disks (for slow, med, fast animations) are children of that main part. The main animating part has keyframes for rotation, the propeller disks do not have any animation keyframes. The propeller disks must not have any animations.

Here is the modeldef for the main animating part:

<Animation name="propeller_axle_anim" guid="F3D60BD1-F3AF-4482-8360-FE53C6DECB51" type="Sim" typeParam2="propeller_axle_anim" length="100" typeParam="AutoPlay" />
<PartInfo>
    <Name>propeller_axle_anim</Name>
    <AnimLength>100</AnimLength>
    <Animation>
        <Parameter>
              <Code>
            (A:IS USER SIM,bool)
            if{
                (A:PROP ROTATION ANGLE:1,percent) 0.1592 * (L:Prop_Offset,number) + 100 %
            }
            els{
                (A:PROP ROTATION ANGLE:1,percent) 0.1592 *
            }
            </Code>
        </Parameter>
    </Animation>
</PartInfo>

I then use attach points for the propeller disk parts. Here is an example of the modeldef code for one of them:

<PartInfo>
    <Name>propeller_slow_vis</Name>
    <AnimLength>100</AnimLength>
    <Visibility>
        <Parameter>
            <Code>
                (A:PROP MAX RPM PERCENT:1, percent) 16.25 &lt; if{ 1 } els{ 0 }
            </Code>
        </Parameter>
    </Visibility>
</PartInfo>

The attach point tool inserts a special code in the exported model which is basically an ASCII version of something like this:

<?xml version="1.0" encoding="ISO-8859-1" ?> <FSMakeMdlData version="9.0"> <Visibility name="propeller_slow_vis"> </Visibility> </FSMakeMdlData>

This code is vital to link the animation code (in this case "propeller_slow_vis") with the part you want to be visible.

I prefer to use this method as it cuts down on GUID animations. Animations are the worst thing for framerates and I have found attach point visibility are not as bad.

Your other option would be to create animations for each and every part where there is a visibility condition and include that condition in a standard animation with GUID.

 

[Deleted member 1281]

The first suspicious thing I notice is "proo3, enum" - could this be a typo?

(edit afterthoughts)

Second, your "xblur" vis's don't make any sense to me; if these are to control what's normally called prop0_still, _slow, and _blurred then those entries are already in the modeldef, more or less similar to what Anthony has in his propeller_slow_vis, you cannot just make them 0 or 1 without killing their effect.

Third, why any of this should "freeze" anything in your VC is a mystery, explain. What do you and what don't you get?

Fourth, you don't need 12 parts for anything, simply poly-attach all propblades to one masterblade, and hey presto 3 (or 5) have become 1.

Of course the easiest thing by far would be to compile a separate model for the 5-blader, but that may be a personal preference (3 layered prop objects are already as many as I can bear). This would also save that control gauge (haven't yet seen a pilot selecting a propeller type by pressing a button. Ok, would be nice I guess. Realistic, no.)

 

[Heretic]

Thomas:

Versuch's mal mit dieser Hierarchie.

Spinner_still
|_ prop_still_3_blades
|_ prop_still_5_blades

Spinner_slow
|_ prop_slow_3_blades
|_ prop_slow_5_blades

Spinner_blurred
|_ prop_blurred_3_blades
|_ prop_blurred_5_blades

Die spinner_xyz-Teile nutzen allesamt die standard prop0_still/slow/blurred -Animationen und Visibility tags.

Ich würde für das Umschalten zwischen den Propellertypen auf die altbewährte "title="-Methodik setzen, damit man das per Repaint machen kann, also:

<PartInfo>
<Name>prop_3_blades</Name>
<Visibility>
<Parameter>
<Code>
(A:TITLE, string) '5BLADES' sstr 1 &lt; if{ 1 } els{ 0 }
</Code>
</Parameter>
</Visibility>
</PartInfo>

<PartInfo>
<Name>prop_5_blades</Name>
<Visibility>
<Parameter>
<Code>
(A:TITLE, string) '5BLADES' sstr 0 &gt; if{ 1 } els{ 0 }
</Code>
</Parameter>
</Visibility>
</PartInfo>

Wenn "title=" eines repaints also "title=Soloy-Cessna 206 Red-Green 5BLADE" ist, bekommst du das Fünfblattmodell angezeigt und bei "title=Soloy-Cessna 206 Red-Green" das Dreiblattmodell.

Du kannst alle Klone (still, slow and blurred) deiner Propellerausführungen mit dem jeweiligen visibility tag (3_blades or 5_blades) versehen, denn die rotationsgeschwindigkeitsabhängige Sichtbarkeit übernimmt ja durch die Hierarchie der spinner.

Falls du noch prop pitch-Effekte in die prop_still-Modelle integrieren willst, kannst du dafür die prop_pitch0 animtion tags nutzen.

 

[TiAr]

First, >1.000 thanks.

Manfred, the L: proo3´s are only fake codes. I am using these weird looking codes only for my configuraton gauge to control the switches there. Nothing serious.

Anyway, all the parts should be children of the standard prob0_still/slow/blurred parts. The "connection" of the Propeller parts (children/parent) causes the problem of "freezing". Nearly all other animated parts of interior model like yokes, pedals, and a lot of switches are not moving anymore in normal running simulator. But Propellers are running in all stages and you can control displaying both groups of 3-or 5-blades. Without connecting the children/parent parts, all is working great.

Bjoern, the "title" method is great - but my intension is first to bring all variants in one model without changing the whole plane. I will take a closer look on it, if my method has no future. For the avionic variants, it should be the best solution to avoid other issues. Thanks again.

Anthony, your answer brought me a new idea to solve the issue.

I will report...

 

[Heretic]

Anyway, all the parts should be children of the standard prob0_still/slow/blurred parts. The "connection" of the Propeller parts (children/parent) causes the problem of "freezing". Nearly all other animated parts of interior model like yokes, pedals, and a lot of switches are not moving anymore in normal running simulator. But Propellers are running in all stages and you can control displaying both groups of 3-or 5-blades. Without connecting the children/parent parts, all is working great.

Is your setup the one I described?

Bjoern, the "title" method is great - but my intension is first to bring all variants in one model without changing the whole plane. I will take a closer look on it, if my method has no future. For the avionic variants, it should be the best solution to avoid other issues. Thanks again.

This is the same method as used with the avionics which means that all your model variations will be contained ina single .mdl file.

 

[TiAr]

Problem is solved - after a long period with try and error, I found the issues beginning step by step again. First, it is not possible to "connect" children with earlier animated parent parts. Thats causes my freezing of animated parts in VC. Second and this was the bad - both disk parts had corrupted polys (compiler logs with no Errors). I did it again and it now works fine.

Now work is going on. Many thanks

 

[Heretic]

Great to hear, Thomas.

 

[Deleted member 1281]

+ 1.

@Anthony, just had another look at your prop animation code. What's that about ...

(A:PROP ROTATION ANGLE:1,percent) 0.1592 * (L:Prop_Offset,number) + 100 %

How do you set that (Prop_Offset,number) and what does it do? Just curious...