Starship

Interesting thread, I've had the same thing when using heading mode, I can see the GS and LOC on my display but APP didn't trigger so ignored the FD and flew down using the LOC and GS indicators. This happened after Vectors to ILS from Beyond ATC, when flying in a STAR and using Nav then wasn't an issue, APP worked as expected. Glad to see the issue wasn't between the keyboard and chair

Additionally fuel scheduling changes as you go from flt idle to ground fine, N1 decreases. At min beta you end up at the START N1

Looks like it was just too early for any threshold to require it.

Interesting. I have not seen that, but I wonder if it's tied to my observations of IAS mode only leveling the aircraft instead of climbing.

This is due to the engine case and associated components heating the thermocouple up via convection (heating the air then heating the probe), radiation, and conduction (the probe is cooled by air moving over it but then the hot metal conducts heat back into it).

I wonder what the integration is between that and [image: 1b3ea228-0999-43ef-8266-014a3df4b51f.png]

@hughesj2 said in Feature Request: Cabin Polarized Windows: @Black-Square Sounds great Nick, just think it's a really cool and elegant alternative to the traditional blinds but obviously if it's going to impact performance a lot then understandable to leave out It sounds good on paper but having worked with them IRL they aren't that great, it takes longer to darken, and dust will start to collect on the panels plus the rollers, motors and switches that have to be maintained, also you can't just close the shades after shutting down and parking

No worries I did try and search for to see if it had been recommended but I didn't see that. I don't even put it in the nice to have category, it is even lower in the "neat" category at best.

@Black-Square Cool, it appears the signal comes out of P3 (LH PFD) 23-26 and P6 23-26 (RH PFD), which passes through the input output concentrator. Each display has a comparator so either can trip the flag based on that side's associated signal. Had to really go diving into the wiring diagram for that and it's still not totally clear to me because of the block diagrams how the signal propagates.

Using an IFR flight plan with ATC in MSFS 2024 can absolutely disrupt your FMS flight plan. For example, I've had certain waypoints entered, and when ATC assigned an approach and arrival to me, it automatically swapped my FMS waypoints with their assigned ones (which caused issues). At this point of my testing with Starship 1.1 I believe if you want simple ATC, you simply select the departing and arriving airport in a minimal VFR plan and start a flight with that. I also plan to do a few more flights by starting with a simple EFB-created IFR flight plan with only departure/arrival airport, request IFR clearance and see if I can preserve my flight plan all the way. I use the Simbrief EFB app to create my flight plan, but copy/paste all values manually into the aircraft, never importing it. When ATC assigns an approach to you it's likely that you'll still have to fix things, but most of the flight should be fine. I hope version 1.2 will guard against such flight plan injections from ATC.

I am enjoying these and hope you continue with the rest of the flights.

@Black-Square I will try a duplication case, but it should be pretty easy. Just get to any nominal altitude with the AP on, press the [pause] key for 30 or so minutes, you can tell something is starting to go awry with when the FD starts moving. then resume and watch the airplane fly a crab. I utilized the AP and YD independently and they both displayed the behavior. Ill see if I get any feedback about it from the WT folks. All the best, Crash

I would if I could, but that would be creating my own simulator to get around some of these issues, I'm afraid. I have changed nothing about how payload and fuel saving works in any of my aircraft for years. They all work on my end, and every computer I have tested on physically. Yet, it just doesn't seem to work for some people. I have spent a huge amount of time trying to find the cause in the past, with no luck. The differences that arise between installations when everything runs on Windows, and all supposedly on the same simulator versions, are really surprising.

Good questions. Performance is only degraded below ~20% engine condition, getting progressively worse until failure. Failing to disengage the starters (in a turbine aircraft) should cause any engine damage by itself. Here are all the items that can degrade engine health: Over-Torque, Prop RPM Exceedance, Ng Exceedance, Oil Temperature Exceedance, Engine Fire, and FOD Ingestion. They will not degrade below 100% if you do everything perfectly, leaving the MTBF to be the reason your engine fails (at 100% health). I consider this to be substantially more realistic than other forms of engine damage simulation that I have seen, since components often fail hours after they leave the factory, which is called "infant mortality".

I'm on the original setup as well. I have nearly finished my ferry from Wichita to Europe via the northern route, and have deselected the 430 from day one, as well as the GPS augmentation on the original system. VATSIM is a bad excuse in my opinion. While I fly on IVAO, I have never ever had any issues flying classic aircraft with classic navigation methods online. I have flown over the pond with the A2A Stratocruiser navigating by stars and weatherships, flown the 707 with INS and radio navigation, and was never turned down by ATC. Sure working an aircraft which is unable for certain procedures increases workload on both sides (hold over...), but also the fun factor. Because it's different and not the same as other aircraft, packed in a different shell. On the Dukes I'm simulating a personal aircraft that has been updated to the latest avionics (and would love to get rid of this RNAV receiver). For the Starship the original equipment is fantastic. Simbrief route import via floppy would be nice, but that's all. Of course, only my personal opinion.

Well, I've fixed it (it was actually one missing material node), but unfortunately, I was unable to improve upon the King Air, since MSFS does not provide a variable to access the amount of windshield icing. This means you will get some mildly strange behavior if you run the windshield wipers while the glass is iced over. No different than the King Air, though. As usual, I did find something to improve, though. Here is a preview from the changelog: Windshield wipers now flutter when deployed at high indicated airspeeds, and also become jammed when airframe icing is moderate. When the wipers are deployed at high airspeed, the apparent wind will affect the resistance on the motor, slowing down the downward sweep. At high enough wind speeds, the wipers will not return to their parked position at lower wiper speeds. This was a particularly fun effect to program, so I hope you enjoy it!

It’s absolutely fixed now @Marionettework !