zbrainlezz

Have you turned on the tank 2L and/or 2R fuel pumps? If I'm remembering correctly, that's a required step to start the APU.

Any further progress update on fixing the flight model issues mentioned briefly in the original post of this thread and in at least one other post? (Deck angle on approach several degrees too low, achievable vertical speed in the climb above ~FL280 much too high) Or should I create another thread about this? On an unrelated note, why does there appear to be no way to delete posts if a user wants to?

I can confirm this issue is finally fixed in 1.0.5. To the dev team: thank you very much. One more major issue fixed.

I recently discovered rzjets.net myself and it's been invaluable for finding real SELCALs and occasionally Mode-S codes to put in my SimBrief airframes. It's how I found N765BE's SELCAL (JQ-BE).

The majority of the liveries in the iniManager seem to have that problem. Been hoping for some livery updates to address that for a while.

This issue is still present in 1.0.4. It's seriously beginning to get on my nerves, especially since the IAS and MACH modes also still don't work properly.

This issue (VNAV mode transitioning from IAS to Mach too early in the climb, and vice versa too late in the descent) is unfortunately still present in 1.0.3. Another issue that has still not been corrected is that the autopilot's actuation of the stabilizer trim is too slow when in IAS and MACH vertical modes, causing constantly alternating overshoot and undershoot of the target speeds and therefore slow vertical oscillations. This means I have to use VS mode to correct when the aforementioned VNAV problem occurs. I hope these issues will be fixed in 1.0.4, as again, they are the last major problems that prevent me from fully enjoying the plane.

Interesting. I wonder why I've not been able to get some SPAD bindings to work with any of iniBuilds' aircraft then... At this point, though, I'm tired of messing with different bindings trying to get them all working in SPAD, so I'm going to stick with what I've found that works, which in this case is a mix of SPAD and MSFS bindings.

I've found that using only SPAD control bindings doesn't work with any of the three iniBuilds aircraft in my library (A300-600R, A340-300, TriStar). There are some controls, such as thrust, spoiler, and flap levers, that either only work with MSFS' built-in bindings, or I somehow haven't found the correct bindings in SPAD (I've tried several possibilities for each, none worked). My best guess at the moment is that iniBuilds just hasn't built proper support into any of their aircraft for any control binding system other than MSFS' built-in one. Because of this, I've had to use some SPAD bindings and some of MSFS' built-in bindings with all these aircraft.

The problem I've had with IAS and MACH modes so far is that the autopilot doesn't change the stabilizer trim quickly enough in those modes, so the aircraft can't hold a speed or Mach reliably. There was a similar issue with VNAV mode when the plane first released, but that's since been mostly fixed. Apart from that and a couple of other known issues, the other vertical modes, such as ALT capture, are working decently now on my end.

I very much hope so, as right now that's one of the last major issues that's preventing me from making a fully satisfactory flight with the TriStar. Thanks 👍

I previously reported it here: That topic was locked as a fix is supposedly already in progress. Hopefully the changelog for the next update will have a fix for this issue in it...

Alright, but what about when switching from MIN to NORM or vice versa? Would there be no difference in APU gauge readings between those two modes?

Good to know. What I meant by that second sentence in my original reply, though, is that turning the APU mode knob appears to have absolutely no effect at all. Yes, the knob can be moved, but it doesn't seem to actually trigger any change in the APU's operation. Therefore, I think iniBuilds should add the necessary code to make the knob actually change whatever APU parameters it's supposed to change before worrying about how the knob itself behaves, if that makes any sense.

Can confirm this is still an issue with v1.0.1.