New release (due Thu 26th Feb): MK Studios Key West KEYW (FS2020 & FS2024)

It seems Matt’s silence was just while they were testing. They’ve checked the taxiway ‘digital links’ and they’re fine. The problem, they claim, is with BATC’s handling of the larger types on such a short runway (they’ve observed no anomalies with default AI and Just Flight’s FST). So in conclusion, it seems BATC does have at least some independent control over AI aircraft — which makes sense since they behave slightly differently when injected by BATC.

I will test myself with FST tonight. I think I can just enable it and it should work fine, as long as BATC isn’t running. As far as I remember, landing AI traffic was somewhat fixed in SU4, so the test should be pretty conclusive.

I think we’re dealing with a unique situation here, with KEYW’s short runway. As I said, in real life, 319/73G loads have to be limited.

1 Like

I keep beating this dead horse but if you’re using BATC for traffic, and have followed their guidance and disabled the sim’s own traffic, all appearance, movement and disappearance of that traffic is under BATC control, frame by frame, minute by minute. Unlike FSTLT for instance, the injected traffic is moved entirely under BATC control. It does not just inject simobjects and let MSFS move them around, like FSLTL. So if traffic just disappears, that’s BATC removing it for its own reasons.

But I saw Matt’s reply on Discord as well - if traffic is disappearing, it might not just be that BATC doesn’t think the runway is long enoug. It might due to BATC believing the taxiway is too narrow and/or the gate size too small for the traffic.

The way to address any of these concerns is to go to the BATC Discord after you see disappearing traffic, create a specific bug report, and upload your player log file for them to analyze, along with as much detail as possible including the information that the airport developer has already verified the AFCAD files for runway exits and taxiway connections.

While it would seem this way in KEYW’s case, BATC in a (much) earlier post claimed the airport creator is responsible for traffic behaviour; so we have two developers pointing fingers at one another (which doesn’t help us much). I suspect each has a part to play. That these AI aircraft are still going at considerable speed before vanishing practically at the runway end would indicate to me that it’s a runway length issue, interpreted by BATC.

That two devs last week managed to ‘fix’ the very same problem (without input from BATC) is good evidence that fully functioning traffic is in part the responsibility of the scenery creator (so there’s validity in MK and BATC blaming one another). Interestingly, both these airports have runways double the length of KEYW.

Based on how tonight’s testing goes, I will open a bug report with BATC. But I’m now confident that, in this case, BATC is the guilty party. I have actually commented recently on how well MK’s airports handle AI traffic so the antics at KEYW came as a bit of a surprise.

I think you’ve misinterpreted BATC’s comments. The airport developer is repsonsible for creating valid runways and taxi paths and making sure they all connect, and for creating parking gate/stand locations and ensuring they connect to the above. A scenery cannot remove objects placed and moved around by a standalone traffic program like BATC.

Okay, I get that; but if that object has nowhere to go, what ultimately causes its removal?

The way I’m currently understanding this is that BATC controls injected aircraft independently of the sim’s core logic. It would seem most airport devs program these ‘digital links’ in accordance WITH core sim logic — meaning compatibility should only be reasonably expected with default traffic or mods such as FSLTL and FST.

My theory is that BATC slows aircraft on rollout differently to the sim — occasionally resulting in their not making proper connections with the ‘digital links’ the default AI takes advantage of. Therefore, since these aircraft basically have no path to take them off the runway, something makes the decision to remove them entirely. Reasonable assumption?

BATC does, by itself. With nowhere to go, it removes the aircraft so as to not clutter up the scenery. It does the same thing in larger, busier airports even in certain circumstances when its logic recognizes there’s a traffic jam. For instance, at KMEM about 6 months ago I arrived at an intersection at the same time as two other BATC-controlled aircraft. Each of us was instructed to hold for traffic over and over again - the program had gotten itself into a loop. After my bug report and others who experienced the same, the devs added a timeout that will remove one or more AI aircraft after a couple minutes to prevent jams like this.

So what appears to be happening here at KEYW is aircraft are reaching the end of the runway and being removed because BATC believes via its internal logic there is nowhere for them to go - either no adequate parking, taxiways too narrow, whatever.

So when this happens in a session, people should post bug reports for the BATC folks to consider and figure out a fix for.

Okay, gotcha. I’ll post a bug report and see what happens. At least now I know some problems are purely BATC-related. I already reached that conclusion when examining parking radii at some third-party airports — set correctly by the developer (according to the FST airport map), and fine with GSX, but BATC was sending both my and AI aircraft to remote military ramps and the like. What muddies the water is that such issues can also be down to the scenery having inaccurate parking links, so it often takes a bit of effort to determine who and what’s responsible. My first approach is to contact the dev and, as long as they’re reputable, they are normally pretty quick to tell me if their scenery is at fault. The two I dealt with last week were very quick to resolve the issue between their work and BATC.

Bit of a nightmare for those of us who like to concisely troubleshoot, though! So many variables…

2 Likes

Lots of testing tonight (over 3hrs), and the results are… I now have more questions than answers! That said, I think I’m beginning to better understand how AI traffic works. For consistency, all tests were done repeating the same KPIE-KEYW flight I’ve been doing for a few days.

First test was with Just Flight’s FS Traffic. Aircraft parked all over the place and although few were actually disappearing after landing (only one A319, but it did manage to vacate the runway before vanishing on a taxiway), they were taking some… interesting routes from runway to stand! Overall, though, relatively successful with no floating aircraft. Since FST lets the sim control AI aircraft, the haphazard nature of the taxi routes came as no surprise, with the core traffic logic still being broken under SU5. The dodgy parking is also simply explained, by how the sim categorises wingspan — i.e. ‘small’ is anything between something like 17 and 26 metres, so an E-Jet can appear on a stand meant for a Citation and a dev will have zero control over it. Mods like BATC can circumvent this because they use AI averages — so if, in real life, an E-Jet has never parked on a stand reserved exclusively for bizjets, it won’t use that stand in the sim, regardless of whether it has a wingspan common to the ‘small’ category.

Next test was using BATC, but with FSLTL models prioritised (rather than FST). This one produced the most interesting (and pleasing) results, with no anomalies whatsoever. No floating planes, no weird taxi routes, and all traffic successfully taxiing to stand after arrival.

In conclusion, the whole issue at KEYW doesn’t appear to be down to BATC, per se, but is instead related to how different aircraft models are interpreted. Since most people use FSLTL for their type models, it seems BATC took those models as a base. I did notice that FSLTL models were using much less runway to slow down, so KEYW’s runway length could still be a stumbling block. A point worth noting is that both FST and FSLTL actually reduce the wingspans of their aircraft models to better fit airports that have less precise parking radii (though in FST, this is optional).

So going forward, it’s unlikely this issue will be addressed, since it would necessitate BATC, FSHud, SI, et al checking every model available in FST, FSLTL and AIG. It’s just not a realistic expectation. If they adapt for FST, they break FSLTL compatibility, and so on.

I will still raise a bug report with BATC, just in case there’s something they can do to better accommodate FST aircraft models. But at this point, I’m fairly certain the blame doesn’t squarely lie with BATC. I suspect it’s one of those little niggles we’re going to have to learn to live with (and believe me, having re-experienced the chaos of the sim’s core AI logic via FST, it’s an easy annoyance to live with!).

2 Likes

From MK Studios Discord this am:

3 Likes

AFCAD fixes? Why would they ‘fix’ something they allege wasn’t broken? Strange…

Maybe they’re redefined taxiway widths, parking spot sizes or something? I think I also saw reference on their Discord yesterday about some of the GA parking spots but not sure if that’s related.

It will be interesting to see if it fixes any of the issues I’ve encountered when using FST models with BATC.

In the meantime, there’s a payware project due end of this week (or early next week) that replaces the poor default water mask with a high-quality version. Between US$9 and 15 is the price guesstimate.

That’s a lot of money for water masks, especially when that’s the kind of thing MSobo could roll-out server side if they ever decide to do it. Based on stuff Jorg has said in prior dev streams when it is brought it, he has claimed it’s a manual process to clean them up, but it’s something they realize needs work in a lot of parts of the world.

EDIT: I went ahead and asked on Discord. Here’s what they said:

1 Like

A highly-detailed water mask is several gigabytes in size, unless the project just cleans up the existing watermask. It would definitely be nicer and simpler if Asobo fixed just Key West for now, and did the rest whenever they were planning to. But welcome to MSFS, where you have fixes for payware, 3rd-party airports and fixes for those fixes :smile:. My Community folder is full of these.

Don’t know if they’ll fix only that “frozen” water around Key West, but the whole Florida Keys from Key Largo to Dry Tortugas need a huge work.

1 Like

If this new payware mod fixes a significant area, it may be worth the estimated $9-15. If, however, it only fixes a very localised area (i.e. around KEYW), the motive for its release is arguably a quick money-grab.

Sadly, BATC traffic is even more borked here post-update. I’ve watched two A319s and an ERJ all taxi to near the end of the runway and just literally spin their wheels without moving (which should be physically impossible, lol!). In the case of the 319’s they even slide backwards in the face of the headwind, then move slowly forward. WTF moments for sure.

There’s a new product Miami and Keys Reefs for MSFS2024 available on SimMarket. I guess that might work well in conjuction with this scenery…

simMarket: MIAMI AND KEYS REEFS MSFS24

3 Likes

Yep, that’s the one I referred to above. Taburet scenery goes on sale often so I’d advise people to wait, unless they’re desperate.

I see the final price is outside that “$9-15” estimate…

It does seem to have good coverage, though, from Miami down to the Keys. Sure, we can moan about having to pay for something Asobo should really fix but it is what it is. It’s the only option if you want the Keys looking anything like reality.

3 Likes

I don’t care for this line in the description:

I fly glass cockpits planes too much to use DLSS; TAA is the only anti-aliasing technique that doesn’t result in blurry moving number on screens or on a HUD.

1 Like