I am still not sure if there is a missunderstanding. In my post I just named the Templates. Each template is of course serveral lines long. But i really just copied these 10-20 lines from one instrument.xml to the other. Maybe that is what you meant?
As i said ā¦ i have to compare those files again. Have just no access to my Flightsim PC right now. So no worries.
BTW are you the JayDee making YouTube Videos? ā¦ i like them 
thank you, I did open a report bug for the stuck HSI and it got promptly answered as āSolvedā.
I asked again for the solution, again moved to Solved.
There is no way to check which bug reports have been filed by other users, there is no traceabilty, there is no feedback.
this is, to say the least, horrible customer support and, honestly, any other line of business using the same practice would not live for long.
the bugtracker should be public, the buglist should be public and, stop asking those details like āwhat buildāā¦I know they are added as deterrent.
it has to be improved.
As always, unfortunately, Zendesk was designed by software developers for software developers. They really donāt care what users think. Solved only means itās been pushed from the Zendesk data collection system to someplace else. It does not necessarily mean the issue is solved.
I, however, wholeheardedly disagree that it should not ask for OS build and Software build etc, etc. That information is EXTREMELY important for solving any problem, as well as for sorting out bugs being reported that have actually already been solved. Determining this one little bit is a full time job.
As far as feedback is concernedā¦ letās see, they probably get something on the order of 5000 to who knows how many events submitted every single day, and those events are probably sorted through by 1 to 3 people, and it may only be a portion of their job. The best you could hope for is that they reported stages for the event (reproducible, not reproducible, sent to ticket system for evaluation, working as designed, bug, etc. etc.). I think this could be possible, but, then again, I could understand that it might not be. Imagine 10,000 bug reports, some contain multiple issues, some are just stupid, then you get the numbskulls who report the same bug every single day (you know they exist), some are a real bug that get fixed by something else. It would mean they have to classify every single one of those reports to a specific work stream, and a system keeps track of all that all along the way, and reports back to the submitter (oops, they mistyped their email, sorry). Itās possible. I donāt know, maybe someday.
Now, this is the Flightsim Zendesk, Carenadoās Zendesk will get fewer, but their staff is almost much fewer.
of course, I donāt mean feedback provided by a human, letās be realistic.
1 Like
now i took a closer look. When i compare your instruments.xml with my fixed one (original + two templates/sections) yours has the following lines, that mine hasnāt:
<Template Name="CARENADO_INSTRUMENT_CDI_2_Template">
<DefaultTemplateParameters>
<ID>1</ID>
<NODE_ID>CUSTOM_INSTRUMENT_CDI</NODE_ID>
<ANIM_NAME>CUSTOM_INSTRUMENT_CDI</ANIM_NAME>
</DefaultTemplateParameters>
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_CODE>(A:NAV CDI:2,Number) 127 + 0 max 254 min</ANIM_CODE>
<ANIM_LENGTH>254</ANIM_LENGTH>
<Lag>150</Lag>
</UseTemplate>
</Template>
<Template Name="CARENADO_INSTRUMENT_GSI_2_Template">
<DefaultTemplateParameters>
<ID>1</ID>
<NODE_ID>CUSTOM_INSTRUMENT_GSI</NODE_ID>
<ANIM_NAME>CUSTOM_INSTRUMENT_GSI</ANIM_NAME>
</DefaultTemplateParameters>
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_CODE>(A:NAV GSI:2,Number) 119 + 0 max 238 min</ANIM_CODE>
<ANIM_LENGTH>238</ANIM_LENGTH>
<Lag>150</Lag>
</UseTemplate>
</Template>
So it seems our basline (the original waco file) differs ā¦ no idea why. But as adding the 2 templates, you posted in the first place seems to be sufficient to fix the issue, this may just be related to me having directly purchased the already updated version instead of the originally released one - no need to further inverstigate i guess.
Fly safe, Dirk
It has to do with poor QA from Carenado. It seems they never tested having all three planes installed on the same installation and what the interactions were between them.
Again, the reason Jay did this was because, well, it starts with the way MSFS works. It reads in files in the order of the packages listed in content.xml. Sometimes, itās smart enough to know particular files are owned by particular packages and it keeps them in memory even though another package has a file with the same name, sometimes it doesnāt know that, and just overwrites the data itās keeping from the last file it read of the same name. I donāt know why, but, to me, is indicative of rather sloppy programming on Asoboās part. Same thing with what Martial said about most CTDās have to do with āuninitialized memoryāā¦ Really??? These are supposed to be professional shops.
In this case, no matter which plane youāve chosen to fly, it reads in Instruments.xml of say the Mooney, then, it reads in the instruments.xml of the Seminole, and promptly forgets all the data from the Mooney Instruments.xml file, then it reads in the Instruments.xml of the YMF, and promptly forgets everything it read in before.
Therefore, by adding in the extra templates from the Mooney and Seminole, now MSFS has all the templates it needs for whichever plane you choose to fly.
Iām not sure who has to fix this, Carenado giving each Instruments.xml file a unique name, or, maybe they are dependent on Asobo to fix this problem. Or, maybe it has to do with the way Carenado is naming their instruments. Iām not familiar with gauge design to that level of detail.
If you mean the german youtuber, thatĀ“s me^^. Kind Regards
YouĀ“re right. My apologies. I did indeed copied all 4 templates over. I blame my age for forgetting it^^. Kind regards, JayDee
Thanks so much! Worked for me 
Thanks for the tip! It fixed my HSI issue with the PA44!!! I found also that OBS NAV2 was not working either, from/to flag was working but interception needles were not.
I fixed by adding the following lines to the instrument.xml file of the carenado-aircraft-wymf5 file ( havent tested the WAKO or any other Carenado airplane yet) but PA44 is working fine so far.
Make sure you backup your Instrument.xml file before changing anythingā¦
<Template Name="CARENADO_INSTRUMENT_CDI_2_Template">
<DefaultTemplateParameters>
<ID>1</ID>
<NODE_ID>CUSTOM_INSTRUMENT_CDI</NODE_ID>
<ANIM_NAME>CUSTOM_INSTRUMENT_CDI</ANIM_NAME>
</DefaultTemplateParameters>
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_CODE>(A:NAV CDI:2,Number) 127 + 0 max 254 min</ANIM_CODE>
<ANIM_LENGTH>254</ANIM_LENGTH>
<Lag>150</Lag>
</UseTemplate>
</Template>
<Template Name="CARENADO_INSTRUMENT_GSI_2_Template">
<DefaultTemplateParameters>
<ID>1</ID>
<NODE_ID>CUSTOM_INSTRUMENT_GSI</NODE_ID>
<ANIM_NAME>CUSTOM_INSTRUMENT_GSI</ANIM_NAME>
</DefaultTemplateParameters>
<UseTemplate Name="ASOBO_GT_Anim_Code">
<ANIM_CODE>(A:NAV GSI:2,Number) 119 + 0 max 238 min</ANIM_CODE>
<ANIM_LENGTH>238</ANIM_LENGTH>
<Lag>150</Lag>
</UseTemplate>
</Template>Has anyone reported this to Carenado, surely they should fix the issue if their products conflict with each other?
There was an update on the seminole some days ago, does this apply to the latest version?
I reported it of course to carenado to.
My Waco HSI is frozen after latest update of Waco and Seminole at the Marketplace grrrr
edit: lol I totally missed the first post and the subsequent NAV2 fixā¦ THANKS to both of you!
Brilliant! I have spent so long trying to fix this problem and came across this post this afternoon. Well done for finding it and fixing it. I have missed the HSI on the PA44 and now I can navigate again!
1 Like
Thank you for this. Worked perfectly for me.
Hello! I have the same problem with the PA-44, but I donāt own the Waco. Only the 182 abd the Mooney. Does anyone know how I could fix the HSI issue? Thanks in advance!
Given that you cannot run the game on anything except the current build the question asking this is rather redundant no?
If they would like to know if you are enrolled in any beta testing of unreleased builds there would be a better way of asking that. (and one would in fact hope that there would be a dedicated channel for bug reporting in this case but frankly nothing surprises me any more)
That would be true if they knew what software build on which you saw the bug. Unless you tell them, by the time they get to reviewing your issue, the software might have already gone through multiple updates and the issue may have been fixed. Itās an extremely important piece of information for any debugging process.
Sure, they might be able to determine what version by the date of submission (I assume they track that), but, I have no issue making their jobs easier. Another issue would be offline players, they may not be on the latest update.
Itās possible, also, that they thought they fixed the bug, but didnāt. Remember, Zendesk just helps them sort the likely hundreds or thousands of reports they get per day. āSolvedā only means itās been processed and either rejected or put in the debugging queue. It would be nice if they communicated whether or not the report was rejected.