@Black-Square Ok thank you, I thought you had already transferred this fix to the Commander 114, but I wasn't sure because I noticed that the beacon light of the Caravan is much more visible during the day than on the Commander 114. I know the core issue is with Asobo, they really need to step up on this.

@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

I expect Just Flight to develop the Hawker Siddeley Trident series for MSFS 2020 and MSFS 2024, not JustTrains, okay?

@SinkRate I didn't mean to step on your toes. I don't know if there is any easy way for you to merge or take over my server... lmk as I'm hardly qualified to manage one

@venemair I experienced a combination of the poor ATS response, but more notably the crosswind issue just before landing using historic weather (Active Sky) on approach to 28L at EIDW. On first attempt I went around as was certainly not a stable approach. On 2nd attempt exactly the same issue, but carried on to land (not pretty) as was out of time for the evening! Because I was using ActiveSky for the weather injection I don't think this can be the system clock issue, but might be a corrupt weather file? As regards the ATS, I had this disengaged for the final approach, but find I keep fighting it as it turns itself on to protect speed. TBF, I think I was in the amber, but how do you tell the computer that it's within parameters for the approach? The correct flap setting was set with an approach speed of 141Kts which I was maintaining, so not really sure what I'm getting wrong if anything... I have done some good landings in the Fokker 100 (in fact some my best), but it does seem very inconsistent.

So, in FSUIPC I have the condition levers set in Axis as "Send to FS Preset". And the preset being "BS Starship Condition Lever 1 (2) Axis". No ranges or anything. Just like that. In the profile, they show up as: x=xU,256,F,PBS_Starship_Condition Lever 1 Axis,0,0,0,(star character)-1 -{ TO SIM: Preset Control }- x=xZ,256,F,PBS_Starship_Condition Lever 2 Axis,0,0,0,(star character)-1 -{ TO SIM: Preset Control }- Where the "x" will be different in your case. I also type (star character) instead of the actual character as the forum interprets it as Italic. But yes, I mean the Shift-8 sign to invert the movement.

All the time. No issues at all. Only „issue“ is that BATC thinks you are a Dornier flying boat during clearance.

@intjmastermind It would not even the legal to key in the procedure yourself in the real world. FAA and EASA rules explicitly state that you have to get them whole from a database. But I agree with you. Such an option would be great. Imagine starship would still be supported. It won’t be a far fetched idea that the avionics would have been upgraded accordingly. I don’t need full VNAV guidance. Just the procedures. And at least a GTN 650.

@Deadeye313 I looked at the SIDS and STARS extensively for the starship. Both FAA and EASA do require the procedure to be able to load from a database. Neither the KNS nor the starship can do that. I am debating if you can user program a procedure in starship yourself, as a stored flightplan, to be loaded. But that is different story.

Thank you for the feedback. I've just had a read of the FCOMs, and it does look like the speed brake lever should return to the IN position during automatic retraction. I have logged this on our internal tracker for our development team to look into further. Mark - Just Flight

For any AFCAS/ATS related feedback, could I kindly ask you to raise a support ticket with Just Flight Support at the following link: https://www.justflight.com/support The F70 & F100 Professional are complex products, so in order to give our support team the best chance at offering speedy assistance, and for any potential bugs to get properly logged and addressed, could you please include any screenshots/videos of the behaviour with your ticket, as well as attaching the log file generated by the product. Instructions for locating the log file can be found here: https://support.justflight.com/en/support/solutions/articles/17000152594-where-to-find-the-log-file-s- Mark - Just Flight

May be of interest... https://community.justflight.com/topic/11221/question-about-upcoming-updates Cheers James

@Black-Square Thank you for fixing it, I really appreciate your constant support to the community. I also highly respect you for having to deal with all of us xD Have a good day!

@Black-Square Hi Nick, looking forward to the upgrades....I see echo19 has created a soundpack for theTBM850....Will any of this batch of upgrades include an official BlackSquare TBM850 soundpack update? Cheers James

If the FAs/Cabin Crew are standing up and doing a safety demo then technically the cabin is not secure until they are also all sat down and fastened with their seatbelts. The cabin security is not only for passengers but for cabin crew as well. The airline operator I work for would usually have the "Cabin is secure for take off" somewhere between us shutting the door after final passenger count and taxi and arrival at the hold point for take off. We are permitted to pushback, engine start and taxi all the way to the hold point but cannot take off. This is an option for you in case you don't want to be late. I think there is an ARM DOORS function on the EFB to do it earlier as well