Simple additions to enhance accuracy….

[Adam106]

I realise that ‘simple’ additions may be anything but…..however, there are a number of items that don’t quite match some real world documentation. Is there any chance these might get looked at Nick?

In no particular order:

1. Using the vertical SYNC button should display a yellow ‘SYNC’ message on the pfd when pressed.
2. The autopilot disengage aural warning should be continuous until cancelled. One way of cancellation is pressing the trim button ‘in’. Another is pressing the yoke disconnect button again.
3. GA mode. Go-around mode should disengage the AP and the GA button is another way to cancel the AP aural disconnect tone.
4. The CDU yellow message MSG cue should flash when a new message is waiting. It’s far too easy to miss a new message. Flashing should help.
5. Both the PFD ‘A/P’ and ‘YD’ should flash when disengaged. And should clear after acknowledgment. (Yoke AP disengage switch or trim button, or GA button).
6. During an ILS approach G/S should not arm until after LOC is captured. I’ve had several instance where G/S is descending the aircraft without the LOC captured….
7. Waypoint Alert. The waypoint symbol and identifier on the ND should flash 10 seconds before either of 2 conditions. Either waypoint flyover or waypoint turn anticipation.
8. All autopilot modes and transitions should display flashing for 5 seconds on the pfd before becoming steady.
9. Manually deploying the pax oxygen masks doesn’t seem to display the PAX OXYGEN ON EICAS message?

May seem super nit-picky but this aircraft deserves its place right up there with the likes of the Hot Start Challenger 650 etc. It’s so nearly there……..

[Black Square]

Thank you for the things you point out here, and in your other topics. I hope you don't mind if I go through them super quickly before getting back to work on something else.

1. As I said elsewhere, there is no way for me to detect when this button is pressed from the simulator.
2. This one was a tough call. I decided not to do it, because I was worried about the users who did not read my FAQ about how to properly setup their control bindings for the autopilot disconnect, and instead use their hardware to simply toggle the autopilot master. They would be stuck with the tone continuously unless they knew how real aircraft typically work.
3. I already fixed this with the button in the cockpit after your last request, but there is no way for me to detect go-around mode either, because the simulator's go-around variable has been broken, possibly for 30+ years.
4. See previous conversation about the performance impacts of testing/drawing many blinking indicators.
5. Same as above.
6. This is a limitation of the native autopilot implementation that cannot be overcome without programming your own autopilot mode controller, as several GPS developers have done for their payware products.
7. Same as above.
8. Same as above.
9. Thanks for that one! I just had the wrong variable in that line of code.

I really appreciate all the notes, but I hope you understand that it's this last 0.1% of details that have severely diminishing returns for both my development schedule, and also performance for the user.

[Adam106]

Hmmm..ok, thanks for the response. I guess the issue is that when developing a somewhat generic panel with a mix of different commercially available avionics for a Baron, Duke, TBM etc, creative license is available on some of those details. Starship is very much a specific airframe with detailed descriptions of how it should all tie together….and these items are a key part of the user interaction. In this way it’s no different from a high fidelity A320 or 737 sim. It sort of has to be correct.

I appreciate MSFS limitations are holding some items back. Anyway, it’s a fantastic product overall, as will be your future aircraft I’m sure.

[Black Square]

As you said, it is rather amusing to me the accuracy that people expect in different scenarios. Starship has absolutely been like an airliner developed by one person, with a fraction of the mass appeal. Yet, the inaccuracies in the GNS 530/430 are numerous and obvious to someone well acquainted with them in real life. It's a great addition to the simulator from WT, don't get me wrong, it's just amusing to me to see where the demands for accuracy lie amongst the community.

[jmarkows]

@Black-Square said in Simple additions to enhance accuracy….:

1. As I said elsewhere, there is no way for me to detect when this button is pressed from the simulator.
2. This one was a tough call. I decided not to do it, because I was worried about the users who did not read my FAQ about how to properly setup their control bindings for the autopilot disconnect, and instead use their hardware to simply toggle the autopilot master. They would be stuck with the tone continuously unless they knew how real aircraft typically work.
3. I already fixed this with the button in the cockpit after your last request, but there is no way for me to detect go-around mode either, because the simulator's go-around variable has been broken, possibly for 30+ years.

For numbers 1 and 3, you're not afraid to make use of LVars when the simvars won't get the job done. I see that you dropped the recommendation with the Starship compared to the Dukes on using the CWS LVar compared to the stock Kvar, would going back to using custom LVars solve the issue?

Same with number 2, I suppose, and there's already plenty of questions on here that can be solved by RTFM.

[Black Square]

Number two is a great example of how difficult these decisions can be, because the same person who does not read the FAQ for the proper disconnect binding is the same person who doesn't know how it works in the real aircraft, and is the same person who won't be looking up the L:Vars. These are the executive decisions that developers must make to try to create an enjoyable experience for as many as possible. I can't claim that I get it right even half the time, but I do my best.

[jmarkows]

Well I certainly fall into the category of not knowing how it works into the real aircraft.

I think you strike a good balance, but I'm also one of those people who lean to the higher fidelity side as much as possible precisely because I want to learn about it. If you need your own variable to do something, I'm OK figuring out how to bind it (or I'll click it in the cockpit).

But I also can't speak to what comprises your audience as a whole, since I only have the interactions here with other like-minded users to go on.

[x4569]

+1 and fully with jmarkows even though I fully get your point as well bs!

[SinkRate]

Just to educate those of us who aren't familiar, how much of a performance hit would it be (on average) to make all the stuff that's supposed to flash, flash? Rarely would they all be flashing at the same time, and rarely for more than a few seconds, but it would bring the airplane even closer to reality. Which is kinda bizarre to even think about or say, given that it's 99.99999% accurate to begin with.

[Black Square]

I had someone ask a little while ago how I test my aircraft for performance, and I said that I rarely do, unless there is something very specific that I'm looking for. Instead, I just program the only way I know how, which is to conserve resources like it's maybe 2010. As for the numbers, the impact is small, but they all add up with everything else. The blinking is an addition test that must be performed on every loop, regardless of the blink state, for every single indicator that would blink. If it's supposed to only blink for ~10 seconds before coming steady, that's another counter that has to be incremented for every single indicator on every loop, and another test to see if it's supposed to become steady. When it's blinking, writing to the screen is the most resource consuming of all.