Starship

Trying to decide what I want the starship avionics to look like though - how lit up, etc. That was part of the mismatch above - have some different ones to look at while flying and decide which way I want to go.

That's it! One lever for 1 and the other lever for 2 and you should be set. Did you test it out?

The cool thing about it is that the Starship requires a bit of intuitive thinking. If you're departing from a regular temperature airport, delay the pitot heat until lined up. Heck, if you're flying on a clear Caribbean summer day, why not leave it off and save the filaments and prevent their MTBF to creep up. For example, when I depart before sunrise from an airport, or from a small airport, I simulate the lack of a GPU. I also don't import plans. I always plan in the cockpit, in the CDU. If I follow the checklist to a tee, I can quickly drain the battery. So, to save the battery, I pull the circuit breakers of the PFD and ND on both sides. It makes quite a difference. Then, when the time is right in the sequence, I pop them back in one by one.

Oh never mind I guess it has to be an existing waypoint, not a custom one.

Here's what happens: After indicating an import failure, the only thing available is to select a deletion of the current plan. I'll make note of the exact language the next time it happens. After the plan deletion, when I return to the Flight Plan screen and begin manual entry the system refuses to except entry of the departure or destination airports. I can enter waypoints but not the airports. (it gives a X-side error message - I'll make note of it the next time it happens). After I force a reboot of the FMS I am able to enter a flight plan manually and the airports are accepted.

I bought BATC and I can confirm it works great, it avoids the native ATC bug and does better traffic injection than other tools.

@SadBucket GNSS SID/STAR's as you mention are generally procedures ending with the name RNAV. And although the whole RNAV/RNP nomenclature is extremely murky, it generally entails performance-based navigation and always have an accompanying RNP. All these require the procedure to line-selectable from your equipment and can't be flown. Since conventional terminal procedures are also flown using conventional radio receivers there is no restriction placed on these non-RNP procedures. I guess one of the main reasons of this requirement is also to guarantee altitude restrictions and constraints. Since there is a process by which these procedures are checked and validated, you can guarantee every pilot has these constraints, whereas building it manually leaves a lot of ambiguity. That's just what I think. Not sure.

Well if it was restricted it didn't seem to be affecting performance. I'll have to recheck

@SinkRate I didn't mean to step on your toes. I don't know if there is any easy way for you to merge or take over my server... lmk as I'm hardly qualified to manage one

@intjmastermind It would not even the legal to key in the procedure yourself in the real world. FAA and EASA rules explicitly state that you have to get them whole from a database. But I agree with you. Such an option would be great. Imagine starship would still be supported. It won’t be a far fetched idea that the avionics would have been upgraded accordingly. I don’t need full VNAV guidance. Just the procedures. And at least a GTN 650.

Can you share with us the route?

FYI Nick - SU6 fixed the LOD issues with the CDU etc with the Pimax crystal super and the Starship. Everything looks to be rendering great now

Nick, I tried the following as you suggested. Switched ON Set SIMCONNECT:GENERAL ENG MASTER ALTERNATOR:1 to 1 ;Turns the Left Generator switch to the ON position Delay execution for 500 ms ;Pause execution momentarily to see each action happen Set LVAR:var GeneratorTrip L to 0 This functionally worked, but it doesn't display the switch being put up into the Reset position, and then back to the On position. What I ended up doing was the following. It puts the switch into the on position, momentarily into the Reset position, then "visually" back to the on position. Removing the delays after setting LVAR:var GeneratorReset L to 0 prevents me from "seeing" the switch actually turn back off and then back on. The first Set SIMCONNECT:GENERAL ENG MASTER ALTERNATOR:1 to 1 leaves the switch in the off position for some reason (I don't know why), but the second Set SIMCONNECT:GENERAL ENG MASTER ALTERNATOR:1 to 1 moves it back to the on position as desired. Then the Set LVAR:var GeneratorTrip L to 0 tells the system that the reset was done. I published a snippet online in SPAD for just this switch, so anybody else that ran into this issue can use this solution. I'm glad that I was finally able to get this working. Thanks for your help. Switched ON Set SIMCONNECT:GENERAL ENG MASTER ALTERNATOR:1 to 1 ;Turns the Left Generator switch to the ON position Delay execution for 500 ms Set LVAR:var GeneratorReset L to 1 ;Set the Left Generator switch to the RESET position Delay execution for 500 ms Set LVAR:var GeneratorReset L to 0 ;Return the Left Generator switch to the ON position (Actually turns it off) Set SIMCONNECT:GENERAL ENG MASTER ALTERNATOR:1 to 1 ;Turns the Left Generator switch to the ON position Set SIMCONNECT:GENERAL ENG MASTER ALTERNATOR:1 to 1 ;Turns the Left Generator switch to the ON position Set LVAR:var GeneratorTrip L to 0 ; Tells the system that the reset was done.[image: c9c170c7-1b24-45f5-a58c-be145747dbdc.jpg]

@Black-Square does using the native load manager have negative effects? Should we use the samevweightscas we use in your load manager? Or only one lbs?

@toby23 ah Ok. I’m having a similar problem with the Commander so was hoping you’d stumbled across something. I shall keep digging

@Black-Square Hey Nick, Will the new PT6 model be implemented for the starship in 2024?