Starship

Make a recheck! Maybe my mistake.

@whitesnuf said in Nav-Mode not selectable: Hello, Sorry for a maybe stupid question. After my first flights with GBS as source I cannot select the nav-mode in the autopilot anymore. In the GNS I select a direct to path and want to follow it with the Nav-Mode, but I doesn't engage. It deactivated heading mode and itself stay also deactivated. I have selected the GNS as nav source. What am I missing? If you happen to be using the Haida livery for Starship, download the 1.1 update of the 2024 livery.

No worries! I hope all your problems in life can be so easy

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.

Smoke

Thanks for confirming that. I've made the error message more clear for future troubleshooting. I've found that MSFS 2024 creates all sorts of user defined waypoints with name collisions, while MSFS 2020 didn't do this unless you explicitly created one yourself...

@Avionic Tomorrow I take a look at that! Thanks for the idea.

@Black-Square said in Single Engine Airspeed: I must have lost this many versions ago, but it's easy enough that I just reprogrammed it instead of looking for how it used to work. All set for v1.2. Thanks for pointing it out. It's so easy to miss the most obvious things when you spend all day looking for the minutia. Nice, thank you!

@Black-Square said in Radar tilt in SYNC mode: I think I just missed one line of code. I'll figure it out and get this in the next update. Thank you! I had noticed too that when auto tilt is on, the tilt knob still changes the tilt while the tilt is still kept in auto. Almost like it applies a tilt bias. Not sure if that is correct or if the tilt knob should force it back into manual tilt, or not affect it at all when in auto tilt.

Honestly, you could probably "spoof it" in the gauge programming I suppose (I have no knowledge of actually coding these things though), and reality is 99% of people would probably be satisfied with it. Unfortunately, only way to really model it correctly (as highlighted in an another thread) is to wholly develop a different engine model - and I don't think that's fair to put on you and this project at the moment. So is what it is. You already got a Garrett you're going to have to somehow model in MSFS with the Turbo Commander so I think your hands are gonna be full haha. Patrick

What you can do is download an existing 3rd party livery, convert the ktx2 textures to PNG, load them into Blender and edit them. You’ll probably want to grab the paint kit or the N2000S white exterior textures and use those as a base, and you’ll have your new textures in PNG format. Then convert back to ktx2 using the livery converter above and modify all the files and names to make it into a new livery. That converter actually turns PNG into ktx2.

I can recommend adjusting the timeout like explained in this post: https://community.justflight.com/post/38785 The default timing clashed with the time it took for me, from completing entry of one waypoint - pressing ok - looking back at my flightplan - starting to enter the next point. Sometimes I would be too slow for the timeout, other times I would be fast enough but anticipating that I was too slow and end up exiting keyboard mode instead. I adjusted the timeout to 9000 ms instead, and now there is no confusion anymore. Using headtracking and a 6 DOF input for moving the camera means that getting stuck is no risk in my case.

Thank you guys! My community folder does not contain any WT things anymore, so i am save i think.

To be honest, I'm not sure. I've read up on the SDK to see if I could find something, and that 6.7 keeps coming up indeed in the [FUEL]/[FUEL SYSTEM] SDK. But I couldn't see anything different in your .xml file (with my 1 cent worth of code reading experience). Since it's only an indication problem, I'll try and do a few flights while changing weight units to see if I can spot anything else.

@plhought Hey Thanks for the video! Here is the AFX text for the 350 that shows the same behavior Video rewind to watch the prop governor test as well but the feather really shows the torque spike

@Black-Square just bumping this in case you can fix it for 1.2... Also if you have any tips on how to structure the thumbnail/file hierarchy for a 2024 Starship livery so that it appears as a "native" 2024 livery and not 2020 with another variant of the aircraft...

If you're using MSFS 2024, both of these effects are much worse. The way exterior lights affect the interior illumination with exposure compensation means that I can never fine-tune the interior lights to get the perfect effect that was so easy in MSFS 2020.

You can, at least, tap the standby instruments just like the other aircraft.

Yeah, that adds up, I also have the feeling that the legs must be far enough apart to cause it. Thanks a lot Correction: I also see it closer to a fix.