@Mad_X i am sorry, my english is very bad, i am not from the US. i dont understand what you mean, sorry

@venemair thanks for your reply . My experience echoes your own as flew back to EGNX from EIDW last night and no such issues. I was keeping a much closer eye on the amber band on the speed tape and the ATS handled things fairly well, all be it with a bit of hunting when heading downwind, but it did a reasonable job of maintaining the speed. Wind on finals was realistic and did a pretty smooth landing, so inconsistent, but will keep persevering!

@Black-Square I am also experiencing some strange behaviour. I am not sure if this started after 1.1 or was there with 1.0. The "VR Tablet Static Position" option in the tablet is always resetting back to an "On" state for every flight. I turn if off and at the start of the next flight, it is back on again. This is happening for the TC variant only. I am able to toggle it off on the normal variant and it stays off.

In the engines.cfg documentation for the SDK, it says that the default airspeed minimum for the Hobbes elapsed time is 25 knots. So given that, you should have less time on the Hobbs meter than the tach time.

I bought BATC and I can confirm it works great, it avoids the native ATC bug and does better traffic injection than other tools.

Interesting. I didn't change anything either. I'll work on it on my side then to see what I can find. Thanks for the quick confirmation.

The change in new update seems to be good for me. Needle moves in NA and TC no problem.

got it - button needed to be pulse/momentary....thanks

@Rich said in Commander Update v0.1.1: @Fabbi It's down to how long the paths get inside the package folder. In the case of the Commander, this html path often pushes users over the limit: bksq-aircraft-commander114\html_ui\Pages\VCockpit\Instruments\Generic\Misc\bksq-aircraft-commander114\BlackSquareTablet\Shared\Assets\commander114ElectricalVisualizer.svg If you add the path to your Community folder to that, in my case it becomes 271 characters long and Windows won't allow it, even with 64bit versions of the installation software. Other aircraft have shorter names and more people fall under the path size limit. As this is one of the longest we've had, more people are seeing it. For the Commander, I've expanded the default installation option in the installer to pre-check whether the package will fit inside the path limit, and if it won't it will send you to the custom location option that will get you around this limit. Hope that helps explain what's going on. Thank you so much for this information.

Also on version 1.1. No issues, 8 to 10 °C in the air around Tromsø. Consistent with ATIS just checked Metar-Taf dot com: 14 °C right now. A nice 22 to 23 °C in the cabin.

Yeah, same issue here. Before the update I had it working perfectly with the switch releasing without delay.

Second this. I use MobiFlight free version also. Once you get to grips with it you can do so much. I would recommend checking out the SDK with regards to RPN also so when you look at other peoples examples it makes a bit more sense. REVERSE POLISH NOTATION

@SadBucket GNSS SID/STAR's as you mention are generally procedures ending with the name RNAV. And although the whole RNAV/RNP nomenclature is extremely murky, it generally entails performance-based navigation and always have an accompanying RNP. All these require the procedure to line-selectable from your equipment and can't be flown. Since conventional terminal procedures are also flown using conventional radio receivers there is no restriction placed on these non-RNP procedures. I guess one of the main reasons of this requirement is also to guarantee altitude restrictions and constraints. Since there is a process by which these procedures are checked and validated, you can guarantee every pilot has these constraints, whereas building it manually leaves a lot of ambiguity. That's just what I think. Not sure.

[image: fd5e28e1-bbe3-41dc-8ec3-d13718b98cf7.png] EDIT: Went through and made sure to delete any cached files and then did another full reinstall and that sorted the issue. Lights now illuminate the ground properly. Unfortunately, a reinstall did not work. It's weird how the lights illuminate the airframe but no interaction with the ground at all. I'll have to go through my community folder and see what I can find.

The inverted signs are just a byproduct of every aircraft having different nomenclature for what the ammeters are actually sensing, and whether we call that positive or negative. I suppose I've just left the nomenclature the same in my tablet for all my aircraft. As for your second observation, I'm not sure I see anything wrong here. It looks like the cockpit instrumentation is reading about 13A, accounting for parallax. I would expect a higher charging rate just after engine start at high RPM, but only if you had most of the aircraft systems turned off. If you have everything up and running like in this screenshot, the power has to come from somewhere, so there will not be as much excess power to charge the battery.

I think the way around this is to use custom install location with teh installer, which seems to default to a short folder structure of c:\justflight\product (paraphrasing). It also then creates a shortcut in your correct packages folder so this will just work, but I delete that shortcut and manually copy the folder from the c:\justflightfolder into my community folder because I dont want it to live on my C: drive.

Well if it was restricted it didn't seem to be affecting performance. I'll have to recheck