1. I updated to v2.0.2, went in-game and get duplicated jetways. (I don't have any other OMDB since I have Standard MSFS)

2. Exited MSFS, un-installed and re-installed OMDB v2.0.2

3. Went back in-game and to OMDB, still get duplicate jetways.

4. Exited MSFS, un-installed

5. Went back in-game so MSFS can clear the scenery library of OMDB. (Confirmed via My Library)

6. Exited MSFS and re-installed OMDB

7. Went back in-game and to OMDB, still get duplicate jetways.

8. During the 1st un-install and re-install I even re-installed the multi jetway tool.

9. Flight eventually cancelled.

No matter what combination I tried, there were duplicated jetways.

EDIT: Tests were all done with ini A380 EA A6-EOE at gates A4 and A5.

It is there because you had hot brakes after takeoff. The action to remedy hot brakes after takeoff is to lower the landing gear. Hence the speed limitation you are seeing there is the maximum gear down speed. If left un actioned, the limitation disappears after takeoff the temperatures drop out of the hot zone.

I tend to agree. Things like engine parameters, VNAV Control and Logic and flight model don't seem to fall into any news cycle. I understand the Tristar was a cheaper aircraft brought out by ini, but I figured it's because complex FMC calculations, BTV, systems, etc. etc. don't need to be modelled. I hope they prove me wrong and finish the product they started.

I reported this on April 17th. I see it still hasn't been fixed then ...

STBY Power Test

The 777, which uses ARINC data also has had issue recently with STAR waypoints. Having fly-over coding where there shouldn't be and distance to go errors. I'm wondering if maybe something changed coding-wise with the latest AIRAC cycles.

So, -13% just about averages out. The main question I have however is, who is right and who is wrong. i.e. Why is one 13% lower, or the other 13% higher. Which one is closer to book values?

Can it be that INS 3 coincidentally drifted away and then back? Resulting in such good accuracy? Did you do more than one flight?

I concur. I believe this was introduced with the release of SU5. Move the eyepoint a bit closer and you'll see it reappear. So, I think it's a LOD issue.

Give it time. I believe since 1.0.5 you need to keep the start button pressed for like 30 seconds before the old thing finally gets cranking. Try it and see if it's still the case. It was corrected I believe after it was reported that the APU lights up before the door sequence finished.

I'm guessing this line: "FIXED INS cannot check drift results post flight in INS due to wp parsing error" addresses it. I can only check it once I get back home.

I did a basic search in the BA systems pdf. For the VS autopilot mode, the following is stated:

"Before engagement the vertical speed tape acts as a vertical speed indicator. When VS is engaged the VSI tape locks to current vertical speed, but this datum can be adjusted with the VS control wheel. This is the only pitch mode datum that can be varied with the mode engaged. Range available is +4000 to -8000 FPM."

This is an earlier version of the Tristar autopilot. However, looking at the above system, it is not out of the realm of possibility that the basic engagement parameters between this and the new ACP remain identical in that when a major mode gets engaged (engaging VS, or in this case turning ON the AP with VS mode already engaged) the system resets to the current value. It makes sense a little bit as you don't want (or back then there wasn't a proper way to) the autopilot to suddenly jump to a new VS value on a mode change. Those days G limited autopilots I believe weren't a thing.

So, again, even though I don't know the definitive answer, it MAY be designed like this.

p.s. Combing through the Delta L-1011 manual and looking at the -500 specific differences, I read the following statement:

"When an autopilot is engaged in CWS, it will automatically maintain the airplane pitch attitude and roll attitude (or heading if the bank angle is less than three degrees) existing at the moment the pilot releases the controls."

Given the fact that on the Tristar you HAVE to transit through CWS to reach CMD, it would also make sense that the autopilot captures current values instead of the ones which the FD system previously had,

Will do Jamir. Currently on a trip that took me all the way to NZAA. when I'm back, I'll take her out for a spin and check 1.0.6 behaviour.

On 4/30/2026 at 12:19 AM, IniJamir said:

I'll have to check that out, and pass it along to the team. Thank you

@IniJamir ,

I just corresponded with an ex TAP employee who confirmed via a video link from the 80's that CS-TEB's SELCAL code in its TAP days was CD-EG. I already updated rzjets.net and airframes.org . Is it possible to update her reg card to include this corrected SELCAL?

Did you try placing all three in RMT and then loading them in?

As reported in the v1.0.5 update post, Progressive Aircraft Loading will soon arrive -->

Features coming soon? 👀

We’re not done there! Development on the TriStar is still ongoing, with even more features and QoL upgrades already in the pipeline. From subtle improvements like PFB Pause at Top of Descent, to deeper immersion through progressive aircraft loading, and streamlined workflows with direct SimBrief import into INS3, there’s plenty more on the way. As always, we’ll continue building on this platform with the goal of delivering an even more complete & refined experience!

So, it's on the way. Just not sure how it will be implemented in the end.

2 hours ago, Joshua Green said:

I have tested this again. The bug isn't what we think. They DO drift, but every time you enter a new waypoint manually, they magically reset to the correct, actual aircraft position. See video:
https://youtu.be/56t3ZEmLk9E?si=uG24GOAz-x2Nync7

Very interesting. This would explain why while crossing the Atlantic and entering all waypoints manually, I pass directly overhead every waypoint because I keep resetting the airplane's position everytime I enter waypoints.

Coming back to the INS drift simulation, I just completed a 9-hour flight from Sao Paulo to Lisbon. On purpose I did not perform any position update procedures during the whole flight. After parking on Position 801 in Lisbon, I performed the INS post-flight drift check by entering the parking spot in waypoint 1, activating track change 0 --> 1 and switching the INS Mode to DIS/TIME/

1. Actual position

2. LPPT Stand 801 coordinates --> Track change 0 to 1.

3. Distance offset for both INS 1 and 2 showing 0.0 nautical miles.

As you can see, at least for INS's 1 and 2 the net INS Drift over 9 hours of operation was 0.0 nautical miles. Which clearly indicates the INS Drift is still not there. p.s. Yes, INS Drift was enabled. I also flew with a buddy who flew out of Rio to Lisbon. Same result. No INS Drift.

Hello there,

I have 1.0.5 and I see a manual 1.1 with change log and change bars. Which is pretty neat.

I'm quite sure you could be able to get the test pattern on the weather RADAR display. Not so anymore in 1.0.5.

In all;

1. No test pattern or TEST indication on screen

2. Weather tilt manipulation does not change displayed value of U 3.0

3. Pressing one mode control button should de-select the previous selection (i.e. Pressing WX while WX+T is pressed, de-presses WX+T)

4. WX+T mode only displays WX on screen. Same as WX mode. (Logical but unverified)

Ok, so I now have v 1.0.5. I understand the logic of 888 on the ground. But now, in cruise, the optimum altitude is still at 888 with an indicated SAT of -37 at FL310.

Remote loading works. All three INS's I had set in RMT.

This is from the TWA manual. We used these older systems on some MD80's I flew. It's all the same. The fact that the flow bar only appears when inhaling through the mask with the Supply ON is in this part of the manual. The TEST and EMERGENCY flow logically out of this.

EDIT: I now also see item 26. that describes what happens when the Operating Mode is placed on EMERGENCY

Hello,

when setting the captain's and co-pilot's oxygen panels, it appears to me that as soon as the system is turned ON, the pilots are using it. This conclusion gathered from the fact that the flow bar rhythmically moves with the average adult breath cycle. In my experience this should be:

Supply OFF --> System is Dead
Supply ON, Demand Normal or 100%, Operating Mode Normal --> Pressure rises on the oxygen pressure gauge (No reference found for value, but 60-70 psi seems normal for indicator)
Supply ON, Demand Normal or 100%, Operating Mode Emergency --> Continuous flow bar as mixed or 100% positive oxygen flow commences. Should have a slight drop on regulator pressure
Supply ON, Demand Normal or 100%, Operating Mode Test --> Same as Emergency, but spring-loaded to Normal

As in idea, the flow bar can cycle as it does now, whenever the cabin altitude warning triggers. (To simulate the pilots doing their memory item of donning their masks) <-- Assuming the supply is ON and the Operating Mode is in Normal.

@IniJamir @richboy2307 Sorry to pin you guys. Can you maybe give some thought into this? Especially since it is an option on the Charts Tab, it would be nice to also have it on the Enroute Tab. You can then have a nice IFR chart, with or without your route plotted on top of it, without an airplane symbol "unrealistically" moving on said "paper" chart.

Thanks

3 hours ago, CaptainCAVU said:

I'd be more worried that after 20 minutes off crossfeed and on tank-to-engine, your quantities in 2L & 2R increased by 600# in each tank!

I'm including the Fuel Distribution/Usage tables we used at TWA...makes it a little simpler.

That’s amazing reference! Thanks 🙏🏼.

To be fair, I flew again on 1.0.3 and the tank balance remained. So, it could be something that was already fixed. I’ll take her up once I return from leave.