Starship

You are fully right! Imported via/into MSFS2024 from simbrief (tool). No need to apologize, maybe, for the time being you could, whenever the aircraft is loaded just flush the route that MSFS is injecting. And, at a later point in time we are all happy to welcome the approach with the floppy with the simplified route we discussed in another thread .. )

@Black-Square said in How is VERT SYNC actually working: Sorry to keep this one short, but the limited pitch sync functionality is due to an oversight from Asobo. There is no variable for me to detect whether the user is holding the pitch sync button, so it's impossible for me to create more complex modes of operator, or to show an annunciator. I have workarounds for elsewhere when this is the case (there is no go-around variable either...), but I have yet to come up with anything that could detect pitch sync. Fully understood your point and the also restriction. I am using SPAD Next on my side where you can have a button hold mode programmed. I fail when trying to understand what th VERT SYNC would trigger, especially in a scenario where the AP would be on and you push/hold/release it: button (VERT SYNC) pressed (Disables AP? FD Mode goes into PITCH/ROLL? button hold (Keeps status as with button pressed) button release (Is SYNCING vertical? (also maybe horizontal?) (Is turning AP back on? If yes, which modes? PITCH or VS would make sense in VERTICAL mode, ROLL would only make sense in HOR mode?) Could not really find anything in the original manual except what I shared on top

Glad you're enjoying it. This was a very purposeful design choice on my behalf. Calling some of today's pilot's "children of the magenta line" has become such a common utterance around the airfield that it occurred to me that I might be foolish to create a map display without the proverbial magenta line. Hopefully you can understand that I probably would have received far more complaints about not knowing which leg is active, than your single well researched critique. This was originally due to a simulator limitation, but I thought of an elegant way to synchronized them recently that I will try. (the issue is that I don't want there to be a visible delay between the two if they have to synchronize after becoming out of sync for whatever reason.) Fixed. I actually already had the rounding in there, but forgot to put in the divisor. Thanks again, and always feel free to send me anything else I missed!

That already looks very promising for a WIP, Thank you dadgametime ...

@Black-Square the publication can be found here There is also a thread about the takeoff trim here

I can't swear to you that's the reason, but I'm fairly certain, based on your description. That's why I've spent days writing my own replacements for a lot of their code, because there are just too many bugs to account for with workarounds alone.

Maybe to some extent, but at least the heading intercept for APPR is an issue over here on the SU2 release.

Very interesting, thank you as always!

Ok this is my final understanding: In a turbo prop; N1 spool creates exhaust gas which spins the other power turbine N2 via windmill effect, power turbine connected to gearbox to reduce 50,000 RPM to 1700 RPM, gearbox turns prop shaft which is directly connected to prop itself. Throttle controls N1 gas generator by modulating fuel flow Prop control is for RPM, governors will maintain this RPM AT ALL COSTS!!!!!!!!!!!!! So if we increase torque the governers will say NO, they will maintain RPM at all costs, as torque is increased or decreased the governors will adjust blade angle to maintain RPM, the blade angle change is what produces our thrust! not the prop RPM! Torque is primary parameter in PT6A-67A for Beechcraft Starship 2000 (BE-2000) Change torque via gas generator via throttle levers, blade angles change and THIS is what produces thrust, RPM is always held constant by the governors and the RPM is ONLY changed by the prop controls, prop control ONLY changes target RPM nothing else, we have no direct control over blade angle in alpha range (forward thrust range)

figured it out, engine needed repaired

You can see if Mobiflight has anything updated. There hasn't been an update to FSUIPC for a bit. Still on 7.5.3, I just grabbed it to reinstall yesterday. There's a fairly comprehensive list of variables in the manual if you're familiar with doing it yourself.

For the torque, the variable is in ft-lbs, and the EICAS displays in percentage. Just divide the value by 3,050 to get the percentage. For the gas generator, you should be using BKSQ_NG_1, which is already a percentage. Always happy to help!

Thanks - great help. - Already removed GNS. Assume it using DME arc triangularity now. - But fun to see how Omega works

@dadgametime said in VNAV super helpful!: I’m still struggling with GS in 2024, but ILS is no problem in 2020. I think that may be a 2024 bug though. I’m still not sure about a few things under the skin like, am I navigating with VLF if I use the flight plan in the CDU but don’t use GPS? (I have the 430 turned off completely to prevent any possible conflicts). Whether or not the 430 is in the cockpit means nothing as far as position updates go, you just lose it as an option to drive the FD/AP. On the System Control page, one of the bottom right options allows you to tell what systems it can use to integrate its position. EDIT: found it, Sensors button. I have no GNS in my cockpit, but still had to select GNSS/WAAS off on this screen (there's a GPS unit in the nose avionics bay). Somewhere between the CDU and the MFD you can dig around enough and it will tell you what system it is using; it might be in the FMS page on the MFD, but it's not something I can directly point to without being at my computer to load the aircraft and look at. As far as the ILS goes, if you're trying to intercept with a heading, it seems APPR does not arm a lateral mode like it reportedly does in 2020, so you have to hit Nav as you get to the localizer and then APPR. Otherwise you will grab the GS but blow through the localizer.

@slipperfruit Look at the tablet; the cockpit air also gets piped directly into the instrument bay as well as the pilot/copilot air vents. Cabin temp gets piped into the cabin, but can also be blown into the instrument bay with the aux blower. In practice, I'm sure the cabin/cockpit differential works about as well as modern cars where the passenger tries to set a different temp from the driver but the important part is the cockpit air temp gets blown right into the bay with the displays.

The funny thing is that TOGA was in the original Asobo GNS units, and when WT took them over is when it stopped working! I went through a long back and forth with FSW in their 414 because it had stopped working for me, and eventually they told me the new, mandatory WT GNS units did not support the TOGA Kvar and as they used the avionics AP instead of coding their own, there was nothing they could do about it until WT put it back in. I was pleasantly surprised to find it working in the Starship, where I have the GNS disabled, as Nick has also traditionally relied on the AP of the underlying avionics (I think). For me, that has meant the WT GNS units, as I am not interested in using the various flavors of giant touchscreens, so for most things I've given up having TOGA work at all. However, it seems like this latest batch of nonsense has him just doing the whole thing himself, which I imagine will eventually work its way back from Starship to the Dukes, TBM, and Professional series.

Last few landings were successful on my side. Even with the "Unrestricted Beta" off, adjusting power to maintain a steady speed in slow flight is still kind of tricky. But it feels realistic (I always found slow flight too easy compared to real life in Flight Simulator). I suppose doing a bit of slow flight training would be super useful.

I had a similar issue with the CWS button in the Duke, and for my hardware the solution was to use the _IsDown variable. Try PropGovTestSwitch_IsDown instead maybe? Send it once and then zero it on release.