Starship

Seems like it.

@Black-Square There is an option in the FS ATC Chatter settings to tick/untick "Only play chatter when your COM1/COM2 radio is powered up" which works for now. Just a heads up. Thanks

Thanks to all. I just set it to high to see if we can get the feeling back in our fingertips Cheers! EDIT: ffs I even have it highlighted in the manual

Ohh, okay. That's probably the same problem i faced with the Dukes a while back.

Well, what's the source for it. It's just a technical question as I would like to understand the source for it. Additionally I did not notice much roll on takeoff when trimmed neutral.

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