• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

MSFS20 HSI-RMI Gauge Help

C

chachi17_ve

Messages
2
Country
chile
Hi everyone, let me introduce, with a friend we are developing a plane for FS2020 (Chilean T-35 Pillán), we are a little new on this so we have just a few experience on develope, and it´s been a trial and error thing with a tons of tutorials, study, and more, right now we are a little bit stuck into de develope of the HSI and RMI gaugues, I dont know if theres anyone who can give us a hand, maybe our coding is not right or something with the blender 3D model, animation or names.

We would really apreciate any help. I´ll leave the link of the blender model and the code he is using and the one I think could work.

HSI-RMI blender model:

HSI_T35.zip

drive.google.com drive.google.com

XML link:

DA62.xml

drive.google.com drive.google.com

Code one:

<!-- RMI -->

<!-- Possibly needs 180 offset -->
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_NAME>RmiAdfNeedle</ANIM_NAME>
<ANIM_LAG>0</ANIM_LAG>
<ANIM_LENGTH>100</ANIM_LENGTH>
<ANIM_WRAP>True</ANIM_WRAP>
<ANIM_CODE>
(A:CIRCUIT ON:@ADFCircuit, bool) if{
(A:ADF SIGNAL:1, bool) if{
(L:BKSQ_ADF_BRG_1_Degraded, Number) 360 + 0.27777 *
} els{ 10 }
} els{ 0 }
(&gt;O:inputValue_rmiAdfNeedle, number)

(O:inputValue_rmiAdfNeedle, number) (O:lastInputValue_rmiAdfNeedle, number) - -50 &lt; if{
(O:phaseOffset_rmiAdfNeedle, number) 100 + (&gt;O:phaseOffset_rmiAdfNeedle, number)
}
els{
(O:inputValue_rmiAdfNeedle, number) (O:lastInputValue_rmiAdfNeedle, number) - 50 &gt; if{
(O:phaseOffset_rmiAdfNeedle, number) 100 - (&gt;O:phaseOffset_rmiAdfNeedle, number)
}
}

(O:inputValue_rmiAdfNeedle, number) (&gt;O:lastInputValue_rmiAdfNeedle, number)
(O:inputValue_rmiAdfNeedle, number) (O:phaseOffset_rmiAdfNeedle, number) +

0.03 * (O:lastAnimValue_rmiAdfNeedle, number) 1.78 * + (O:secondLastAnimValue_rmiAdfNeedle, number) -0.81 * +
(O:lastAnimValue_rmiAdfNeedle, number) (&gt;O:secondlastAnimValue_rmiAdfNeedle, number)
(&gt;O:lastAnimValue_rmiAdfNeedle, number)
(O:lastAnimValue_rmiAdfNeedle, number)
100000 + 100 %
</ANIM_CODE>
</UseTemplate>

<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_NAME>RmiVorNeedle</ANIM_NAME>
<ANIM_LAG>0</ANIM_LAG>
<ANIM_LENGTH>100</ANIM_LENGTH>
<ANIM_CODE>
(A:CIRCUIT ON:@Com1Circuit, bool) (A:CIRCUIT ON:@Nav1Circuit, bool) and if{
(A:NAV HAS NAV:1, bool) if{
(L:BKSQ_VOR_BRG_1_Degraded, Number) (A:PLANE HEADING DEGREES MAGNETIC, Radians) 57.2958 * - 540 + 0.27777 * 100 %
} els{ 90 }
} els{ 0 }
(&gt;O:inputValue_rmiVorNeedle, number)

(O:inputValue_rmiVorNeedle, number) (O:lastInputValue_rmiVorNeedle, number) - -50 &lt; if{
(O:phaseOffset_rmiVorNeedle, number) 100 + (&gt;O:phaseOffset_rmiVorNeedle, number)
}
els{
(O:inputValue_rmiVorNeedle, number) (O:lastInputValue_rmiVorNeedle, number) - 50 &gt; if{
(O:phaseOffset_rmiVorNeedle, number) 100 - (&gt;O:phaseOffset_rmiVorNeedle, number)
}
}

(O:inputValue_rmiVorNeedle, number) (&gt;O:lastInputValue_rmiVorNeedle, number)
(O:inputValue_rmiVorNeedle, number) (O:phaseOffset_rmiVorNeedle, number) +

0.042 * (O:lastAnimValue_rmiVorNeedle, number) 1.681 * + (O:secondLastAnimValue_rmiVorNeedle, number) -0.723 * +
(O:lastAnimValue_rmiVorNeedle, number) (&gt;O:secondlastAnimValue_rmiVorNeedle, number)
(&gt;O:lastAnimValue_rmiVorNeedle, number)
(O:lastAnimValue_rmiVorNeedle, number)
100000 + 100 %
</ANIM_CODE>
<ANIM_WRAP>True</ANIM_WRAP>
</UseTemplate>



Code two:

#################################RMI################################

<Component ID="Compass_Adf_b407">
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_NAME>b407_needle_compass_adf</ANIM_NAME>
<ANIM_CODE>(L:switchPrimaryCompassMode,bool) ! if{ (A:HEADING INDICATOR, degree) (L:compassAdjustValue,degree) + 90 + dnor } els{ (A:HEADING INDICATOR, degree) 90 + dnor }</ANIM_CODE>
<ANIM_LENGTH>360</ANIM_LENGTH>
<NODE_ID>sk_needle_compass_adf</NODE_ID>
<WWISE_EVENT></WWISE_EVENT>
</UseTemplate>
</Component>

<Component ID="Compass_Adf_obs_b407">
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_NAME>b407_needle_obs_adf</ANIM_NAME>
<ANIM_CODE>(L:adfObs,degrees)</ANIM_CODE>
<ANIM_LENGTH>360</ANIM_LENGTH>
<NODE_ID>sk_needle_obs_adf</NODE_ID>
<WWISE_EVENT></WWISE_EVENT>
</UseTemplate>
</Component>

<Component ID="Needle_Adf_brg1_b407">
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_NAME>b407_needle_adf_bearing_1</ANIM_NAME>
<ANIM_CODE>
(A:CIRCUIT ON:20,bool) if{
(L:switchPrimaryCompassMode,bool) ! if{ (A:ADF RADIAL:1, degree) /-/ (L:compassAdjustValue,degree) + dnor }
els{
(A:ADF RADIAL:1, degree) /-/ dnor
}
}
</ANIM_CODE>
<ANIM_LENGTH>360</ANIM_LENGTH>
<NODE_ID>sk_needle_adf_bearing_1</NODE_ID>
<WWISE_EVENT></WWISE_EVENT>
</UseTemplate>
</Component>

<Component ID="Needle_Adf_brg2_b407">
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_NAME>b407_needle_adf_bearing_2</ANIM_NAME>
<ANIM_CODE>
(A:CIRCUIT ON:20,bool) if{
(L:switchPrimaryCompassMode,bool) ! if{ (A:ADF RADIAL:1, degree) /-/ (L:compassAdjustValue,degree) + dnor }
els{
(A:ADF RADIAL:1, degree) /-/ dnor
}
}
</ANIM_CODE>
<ANIM_LENGTH>360</ANIM_LENGTH>
<NODE_ID>sk_needle_adf_bearing_2</NODE_ID>
<WWISE_EVENT></WWISE_EVENT>
</UseTemplate>
</Component>



###########################################HSI###############################################

<Component ID="Compass_Hsi_b407">
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_NAME>b407_needle_hsi_compass</ANIM_NAME>
<ANIM_CODE>(L:switchPrimaryCompassMode,bool) ! if{ (A:HEADING INDICATOR, degree) (L:compassAdjustValue,degree) + dnor } els{ (A:HEADING INDICATOR, degree) }</ANIM_CODE>
<ANIM_LENGTH>360</ANIM_LENGTH>
<NODE_ID>sk_needle_hsi_compass</NODE_ID>
<WWISE_EVENT></WWISE_EVENT>
</UseTemplate>
</Component>

<Component ID="Course_Hsi_b407">
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_NAME>b407_needle_hsi_course</ANIM_NAME>
<ANIM_CODE>(A:GPS DRIVES NAV1,bool) ! if{ (A:NAV OBS:1,degree) } els{ (A:GPS WP DESIRED TRACK,degree) }</ANIM_CODE>
<ANIM_LENGTH>360</ANIM_LENGTH>
<NODE_ID>sk_needle_hsi_course</NODE_ID>
<WWISE_EVENT></WWISE_EVENT>
</UseTemplate>
</Component>

<Component ID="Needle_Hsi_Cdi_b407">
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_NAME>b407_needle_hsi_cdi</ANIM_NAME>
<ANIM_CODE>
(A:CIRCUIT ON:20,bool) if{
(A:GPS DRIVES NAV1,bool) ! if{ (A:NAV HAS NAV:1,bool) if{ (A:NAV CDI:1, number) /-/ 127 + } els{ 127 } }
(A:GPS DRIVES NAV1,bool) if{ (A:GPS IS DIRECTTO FLIGHTPLAN,bool) (A:GPS IS APPROACH ACTIVE,bool) or (A:GPS IS ACTIVE WAY POINT,bool) or (A:GPS IS ACTIVE FLIGHT PLAN,bool) or if{ (A:GPS CDI NEEDLE, number) /-/ 127 + } els{ 127 } }
} els{ 127 }
</ANIM_CODE>
<ANIM_LENGTH>254</ANIM_LENGTH>
<ANIM_LAG>400</ANIM_LAG>
<NODE_ID>sk_needle_hsi_deviation</NODE_ID>
<WWISE_EVENT></WWISE_EVENT>
</UseTemplate>
</Component>

<Component ID="Needle_Hsi_Gs_b407">
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_NAME>b407_needle_hsi_gs</ANIM_NAME>
<ANIM_CODE>
(A:CIRCUIT ON:20,bool) (A:NAV HAS NAV:1,bool) and if{
(A:NAV GSI:1, Number) /-/ 119 +
} els{ 119 }
</ANIM_CODE>
<ANIM_LENGTH>238</ANIM_LENGTH>
<ANIM_LAG>400</ANIM_LAG>
<NODE_ID>sk_needle_hsi_gs</NODE_ID>
<WWISE_EVENT></WWISE_EVENT>
</UseTemplate>
</Component>

<Component ID="Needle_Hsi_Mkr_b407">
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_NAME>b407_needle_hsi_mkr</ANIM_NAME>
<ANIM_CODE>
(L:needleHsiMarker,number)
</ANIM_CODE>
<ANIM_LENGTH>360</ANIM_LENGTH>
<NODE_ID>sk_needle_hsi_mkr</NODE_ID>
<WWISE_EVENT></WWISE_EVENT>
</UseTemplate>
</Component>

<Component ID="Flag_Hsi_Loc_b407">
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_NAME>b407_flag_hsi_loc</ANIM_NAME>
<ANIM_CODE>(A:CIRCUIT ON:20,bool) ! 25 *</ANIM_CODE>
<ANIM_LENGTH>25</ANIM_LENGTH>
<ANIM_LAG>200</ANIM_LAG>
<NODE_ID>sk_flag_hsi_loc</NODE_ID>
<WWISE_EVENT></WWISE_EVENT>
</UseTemplate>
</Component>

<Component ID="Flag_Hsi_Gs_b407">
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_NAME>b407_flag_hsi_gs</ANIM_NAME>
<ANIM_CODE>(A:CIRCUIT ON:20,bool) ! 25 *</ANIM_CODE>
<ANIM_LENGTH>25</ANIM_LENGTH>
<ANIM_LAG>400</ANIM_LAG>
<NODE_ID>sk_flag_hsi_gs</NODE_ID>
<WWISE_EVENT></WWISE_EVENT>
</UseTemplate>
</Component>

<Component ID="flag_hsi_to" Node="flag_hsi_to">
<UseTemplate Name="ASOBO_GT_Visibility_Code">
<VISIBILITY_CODE>(A:CIRCUIT ON:20,bool) if{ (A:NAV TOFROM:1,enum) 1 == }</VISIBILITY_CODE>
</UseTemplate>
</Component>

<Component ID="flag_hsi_from" Node="flag_hsi_from">
<UseTemplate Name="ASOBO_GT_Visibility_Code">
<VISIBILITY_CODE>(A:CIRCUIT ON:20,bool) if{ (A:NAV TOFROM:1,enum) 2 == }</VISIBILITY_CODE>
</UseTemplate>
</Component>

<Component ID="flag_hsi_stripes" Node="flag_hsi_stripes">
<UseTemplate Name="ASOBO_GT_Visibility_Code">
<VISIBILITY_CODE>(A:NAV TOFROM:1,enum) 0 ==</VISIBILITY_CODE>
</UseTemplate>
</Component>

<Component ID="Compass_Vor_b407">
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_NAME>b407_needle_vor_compass</ANIM_NAME>
<!--<ANIM_CODE>(L:switchPrimaryCompassMode,bool) ! if{ (A:HEADING INDICATOR, degree) (A:NAV OBS:2, degree) + (L:compassAdjustValue,degree) + dnor } els{ (A:HEADING INDICATOR, degree) (A:NAV OBS:2, degree) + dnor }</ANIM_CODE>-->
<ANIM_CODE>(A:NAV OBS:2, degree)</ANIM_CODE>
<ANIM_LENGTH>360</ANIM_LENGTH>
<NODE_ID>sk_needle_vor_compass</NODE_ID>
<WWISE_EVENT></WWISE_EVENT>
</UseTemplate>
</Component>

<Component ID="Course_Vor_b407">
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_NAME>b407_needle_vor_course</ANIM_NAME>
<ANIM_CODE>(L:NAV OBS:2, degree)</ANIM_CODE>
<ANIM_LENGTH>360</ANIM_LENGTH>
<NODE_ID>sk_needle_vor_course</NODE_ID>
<WWISE_EVENT></WWISE_EVENT>
</UseTemplate>
</Component>

<Component ID="Needle_Vor_Cdi_b407">
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_NAME>b407_needle_vor_cdi</ANIM_NAME>
<ANIM_CODE>
(A:CIRCUIT ON:20,bool) (A:NAV HAS NAV:2,bool) and if{
(A:NAV CDI:2, number) /-/ 127 +
} els{ 127 }
</ANIM_CODE>
<ANIM_LENGTH>254</ANIM_LENGTH>
<ANIM_LAG>400</ANIM_LAG>
<NODE_ID>sk_needle_vor_cdi</NODE_ID>
<WWISE_EVENT></WWISE_EVENT>
</UseTemplate>
</Component>

<Component ID="flag_vor_to" Node="flag_vor_to">
<UseTemplate Name="ASOBO_GT_Visibility_Code">
<VISIBILITY_CODE>(A:CIRCUIT ON:20,bool) if{ (A:NAV TOFROM:2,enum) 1 == }</VISIBILITY_CODE>
</UseTemplate>
</Component>

<Component ID="flag_vor_from" Node="flag_vor_from">
<UseTemplate Name="ASOBO_GT_Visibility_Code">
<VISIBILITY_CODE>(A:CIRCUIT ON:20,bool) if{ (A:NAV TOFROM:2,enum) 2 == }</VISIBILITY_CODE>
</UseTemplate>
</Component>

<Component ID="flag_vor_stripes" Node="flag_vor_stripes">
<UseTemplate Name="ASOBO_GT_Visibility_Code">
<VISIBILITY_CODE>(A:NAV TOFROM:2,enum) 0 ==</VISIBILITY_CODE>
</UseTemplate>
</Component>

1705107875455.png
1705107897752.jpeg
 
Just a couple of observations; your first gauge, "RMI" has no Component ID, I think that's necessary but you'd probably get an XML parse error if my suspicion holds out to be true. Also the rest of the Component ID's are copy/pasted straight from the default Bell 407 and it seems like you should probably rename those to your own aircraft name for forms sake, because doing so might also avoid a VFS name conflict if you ever release, but I think at least for now it shouldn't matter if all the names match since you're not simultaneously using both aircraft.

Since it looks like the default code, the only likely problems with the XML would be name mismatches, if you've edited it then those parts would be a big area for intense scrutiny, I'm using the same code but don't know it well enough to see how close to default yours is, but it does appear to be very close. The node/helper hierarchy is probably the most important and I can't check yours because I use 3ds Max. I know from trying to reverse engineer default aircraft and conversing with other developers that many gauge components use animated meshes, while the SDK tells us to use helpers. Also you have active instrument components that I don't see any flags modeled for in either the Blender image or in sim.

HSI_examined.png


The little red box just to the right of the tail of the virtual aircraft below the centering markers for the localizer needle are three images of "to" "from" and crosshatched lines that relate direction of the VOR and the Component ID's about "flag vor to from and stripes" control visibility for those flags. It is a good idea to empty your Community folder, or at least run a conflict check, guaranteed you will find at least 30 you can do nothing about and maybe one or two you can. Parallel 42 has a nice tool for that and it's also a good idea to remove all Component/Behaviors code from the aircraft_interior XML that isn't directly relevant to the gauge being tuned in.

Finally I want to remind you about the BehaviorDebug window available in DevMode of course. You can see my own HSI has an invalid animation scale, I think it says I rotated it the wrong direction. Anyways give it a try, maybe if you figure it out you can tell me how to get mine working!
 
=rk= said:
Just a couple of observations; your first gauge, "RMI" has no Component ID, I think that's necessary but you'd probably get an XML parse error if my suspicion holds out to be true. Also the rest of the Component ID's are copy/pasted straight from the default Bell 407 and it seems like you should probably rename those to your own aircraft name for forms sake, because doing so might also avoid a VFS name conflict if you ever release, but I think at least for now it shouldn't matter if all the names match since you're not simultaneously using both aircraft.

Since it looks like the default code, the only likely problems with the XML would be name mismatches, if you've edited it then those parts would be a big area for intense scrutiny, I'm using the same code but don't know it well enough to see how close to default yours is, but it does appear to be very close. The node/helper hierarchy is probably the most important and I can't check yours because I use 3ds Max. I know from trying to reverse engineer default aircraft and conversing with other developers that many gauge components use animated meshes, while the SDK tells us to use helpers. Also you have active instrument components that I don't see any flags modeled for in either the Blender image or in sim.

View attachment 91092

The little red box just to the right of the tail of the virtual aircraft below the centering markers for the localizer needle are three images of "to" "from" and crosshatched lines that relate direction of the VOR and the Component ID's about "flag vor to from and stripes" control visibility for those flags. It is a good idea to empty your Community folder, or at least run a conflict check, guaranteed you will find at least 30 you can do nothing about and maybe one or two you can. Parallel 42 has a nice tool for that and it's also a good idea to remove all Component/Behaviors code from the aircraft_interior XML that isn't directly relevant to the gauge being tuned in.

Finally I want to remind you about the BehaviorDebug window available in DevMode of course. You can see my own HSI has an invalid animation scale, I think it says I rotated it the wrong direction. Anyways give it a try, maybe if you figure it out you can tell me how to get mine working!
Click to expand...
RK, I know I'm late to this discussion but maybe you can help. I am doing a HSI and am using the default template system but have come up against a problem. The increments for the course pointer have started to move in 10 degree increments and I dont know how to solve this. please see the following code.

XML: 
        <Code>0.10 (A:NAV OBS:1, degrees)</Code>

I have tried:

XML: 
        <Code>0.10 (A:NAV OBS:1, degrees) 0.10 *</Code>

amongst several permutations but nothing seems to work. Please help.

Many thanks
 
Ah fascinating, how lucky you are. You are experiencing "conflicts," almost certainly, possibly something else, but that is why the gauge started operating intermittently. You should be able to correlate adding an additional component xml with the occasion of the animation changing. Personally, I would stop working on animation arguments to address this conflict. In my experience, the sim engine is fairly obliging when it comes to animation code, I've seen various animations of mine work flawlessly, despite the fact that they are written fundamentally differently, so I strongly believe specific code arguments are not the issue here.

What you need to find specifically imo, is the source of the conflict and eliminate that, so you know your code expression snippets are most likely to be able to run when you trigger them. I can't be more direct because it is not something I have begun to nail down in earnest, I am so close to completion that I intend to finish my rough XML before perfecting it, all my gauges are complete, correctly animated, but only two of them work currently. I know for a fact the others work because I've seen them disable and reenable several times already. I will tell you what I've learned along the way in the hopes you will find the missing clue and report back.

All component xml is subject to these conflicts, after completing the initial work on gauges, I turned to visual effects and managed to get them all crossfiring against each other, as well. There is a section in the SDK about naming conventions and it refers to suffixes in relation to animated gauges. I believe that section has relevant information. During experimentation, I added an underscore 1 suffix, "_1" to all relevant parts of two gauges, after that all the other gauges except those two started working until I added another xml component. Doing so broke them again, but by this point I was aware of the possibility. So clearly, I had been onto something, if misdirected.

When I review the broken animations in the Behaviors Debug, a common warning is an absence of "Input Event ID." I believe this warning may be kind of a false flag, that input event issues don't really apply, but I've studied the input event section of the SDK and it does seem extremely relevant. However the code structure demands files and directories I've never seen in other aircraft folders, additionally on the occasions I clear animation errors, the input event ID is suddenly no longer a problem and I don't really feel like I'd set up the input event structured hierarchy, but it's possible I suppose. It is also possible that input event IDs are established more simply than I had thought.

Finally, another thing you could do that will only work to help perfect your HSI gauge animation, is that you could remove all conflicts by disabling them. The ascii string "<--/" will strike out all XML code in green until "-->" is encountered, effectively removing anything green from parsing by the sim engine. I used this trick to prove to myself I was not going crazy as fast as circumstances appeared to indicate, perhaps it will reassure you as well. Otherwise, it is a great way to store code arguments we may decide to use at a later time.

I notice your sig and I bet xml is moving a bit closer to familiarity at this point!
 
=rk= said:
Ah fascinating, how lucky you are. You are experiencing "conflicts," almost certainly, possibly something else, but that is why the gauge started operating intermittently. You should be able to correlate adding an additional component xml with the occasion of the animation changing. Personally, I would stop working on animation arguments to address this conflict. In my experience, the sim engine is fairly obliging when it comes to animation code, I've seen various animations of mine work flawlessly, despite the fact that they are written fundamentally differently, so I strongly believe specific code arguments are not the issue here.

What you need to find specifically imo, is the source of the conflict and eliminate that, so you know your code expression snippets are most likely to be able to run when you trigger them. I can't be more direct because it is not something I have begun to nail down in earnest, I am so close to completion that I intend to finish my rough XML before perfecting it, all my gauges are complete, correctly animated, but only two of them work currently. I know for a fact the others work because I've seen them disable and reenable several times already. I will tell you what I've learned along the way in the hopes you will find the missing clue and report back.

All component xml is subject to these conflicts, after completing the initial work on gauges, I turned to visual effects and managed to get them all crossfiring against each other, as well. There is a section in the SDK about naming conventions and it refers to suffixes in relation to animated gauges. I believe that section has relevant information. During experimentation, I added an underscore 1 suffix, "_1" to all relevant parts of two gauges, after that all the other gauges except those two started working until I added another xml component. Doing so broke them again, but by this point I was aware of the possibility. So clearly, I had been onto something, if misdirected.

When I review the broken animations in the Behaviors Debug, a common warning is an absence of "Input Event ID." I believe this warning may be kind of a false flag, that input event issues don't really apply, but I've studied the input event section of the SDK and it does seem extremely relevant. However the code structure demands files and directories I've never seen in other aircraft folders, additionally on the occasions I clear animation errors, the input event ID is suddenly no longer a problem and I don't really feel like I'd set up the input event structured hierarchy, but it's possible I suppose. It is also possible that input event IDs are established more simply than I had thought.

Finally, another thing you could do that will only work to help perfect your HSI gauge animation, is that you could remove all conflicts by disabling them. The ascii string "<--/" will strike out all XML code in green until "-->" is encountered, effectively removing anything green from parsing by the sim engine. I used this trick to prove to myself I was not going crazy as fast as circumstances appeared to indicate, perhaps it will reassure you as well. Otherwise, it is a great way to store code arguments we may decide to use at a later time.

I notice your sig and I bet xml is moving a bit closer to familiarity at this point!
Click to expand...
Thanks Rick, I think you hit the nail on the head fairly and squarely.
Now off to try and find the little bugger that is driving me absolutely insane.

And you are once again absolutely true about xml being closer to familiarity at this point, except that familiarity is starting to breed contempt as far as I'm concerned, LOL
 
terence jordan said:
Thanks Rick, I think you hit the nail on the head fairly and squarely.
Now off to try and find the little bugger that is driving me absolutely insane.

And you are once again absolutely true about xml being closer to familiarity at this point, except that familiarity is starting to breed contempt as far as I'm concerned, LOL
Click to expand...
Well Rick, I must thank you once again. Your advice inspired me to retrace my steps over the past week or so and I found the culprit. I have an initialisation gauge that I was using to set certain conditions on start up and this had a fuel selector code in an update section. Once I removed this update section, voile, the HSI returned to its normal increments. Damn near had me pull the entire project apart to find it. Luckily, I have a very disciplined regimen for backing up everything otherwise I might have lost the whole thing. So once again thank you so much for your sage advice. My appreciation sir!
 
=rk= said:
Ah fascinating, how lucky you are. You are experiencing "conflicts," almost certainly, possibly something else, but that is why the gauge started operating intermittently. You should be able to correlate adding an additional component xml with the occasion of the animation changing. Personally, I would stop working on animation arguments to address this conflict. In my experience, the sim engine is fairly obliging when it comes to animation code, I've seen various animations of mine work flawlessly, despite the fact that they are written fundamentally differently, so I strongly believe specific code arguments are not the issue here.

What you need to find specifically imo, is the source of the conflict and eliminate that, so you know your code expression snippets are most likely to be able to run when you trigger them. I can't be more direct because it is not something I have begun to nail down in earnest, I am so close to completion that I intend to finish my rough XML before perfecting it, all my gauges are complete, correctly animated, but only two of them work currently. I know for a fact the others work because I've seen them disable and reenable several times already. I will tell you what I've learned along the way in the hopes you will find the missing clue and report back.

All component xml is subject to these conflicts, after completing the initial work on gauges, I turned to visual effects and managed to get them all crossfiring against each other, as well. There is a section in the SDK about naming conventions and it refers to suffixes in relation to animated gauges. I believe that section has relevant information. During experimentation, I added an underscore 1 suffix, "_1" to all relevant parts of two gauges, after that all the other gauges except those two started working until I added another xml component. Doing so broke them again, but by this point I was aware of the possibility. So clearly, I had been onto something, if misdirected.

When I review the broken animations in the Behaviors Debug, a common warning is an absence of "Input Event ID." I believe this warning may be kind of a false flag, that input event issues don't really apply, but I've studied the input event section of the SDK and it does seem extremely relevant. However the code structure demands files and directories I've never seen in other aircraft folders, additionally on the occasions I clear animation errors, the input event ID is suddenly no longer a problem and I don't really feel like I'd set up the input event structured hierarchy, but it's possible I suppose. It is also possible that input event IDs are established more simply than I had thought.

Finally, another thing you could do that will only work to help perfect your HSI gauge animation, is that you could remove all conflicts by disabling them. The ascii string "<--/" will strike out all XML code in green until "-->" is encountered, effectively removing anything green from parsing by the sim engine. I used this trick to prove to myself I was not going crazy as fast as circumstances appeared to indicate, perhaps it will reassure you as well. Otherwise, it is a great way to store code arguments we may decide to use at a later time.

I notice your sig and I bet xml is moving a bit closer to familiarity at this point!
Click to expand...
Well Rick, I must thank you once again. Your advice inspired me to retrace my steps over the past week or so and I found the culprit. I have an initialisation gauge that I was using to set certain conditions on start up and this had a fuel selector code in an update section. Once I removed this update section, voile, the HSI returned to its normal increments. Damn near had me pull the entire project apart to find it. Luckily, I have a very disciplined regimen for backing up everything otherwise I might have lost the whole thing. So once again thank you so much for your sage advice. My appreciation sir!
 
You must log in or register to reply here.
Back
Top