Here’s an example of a developer who doesn’t know what they’re doing.
They’re reading the SDK, but, not totally getting how the Virtual File System (VFS) works, nor do they completely understand the Services they’ve created or how to properly structure a package for MSFS.
It’s a good thing they’ve created a new path for their files by putting LTAU on the start of the Airport Services. It seems like what they wanted to do was change the default services that Asobo created and not overwrite the default services as they sit in the VFS.
Many companies in the past took the default code, rewrote it, then left it at the default path which meant their code replaced the default code. This is the advantage of using a VFS that you can do this, but also its bane.
The problem is, and I imagine sometimes this comes from having to interpret an SDK written in English into another language makes things hard to understand, and then from Asobo themselves not being abundantly clear about the issues surrounding their VFS, which cause users innumerable problems. For instance, Carenado wanted to make some changes to the html_ui/…Registration code, so they just copied Asobo’s code, rewrote it, and put it in their products. Problem is, it replaced Asobo’s code, which broke the Registration code for other developers, compounded by the fact, when Asobo changed the Registration code, Carenado didn’t make those changes to their code, which made problems even worse. Carenado I believe has since fixed this problem.
The second thing that I see that annoys the heck out of me, are developers who don’t bother to change the names that Asobo uses for defaults in their examples… for example the MyCompany…aggghhh!!!.. THAT’s what is supposed to be LTAU! sigh… anyway, talk about poor development practices. SMH
So LTAU were at least attempting (but still failing) to avoid the problem they are likely still causing, because…
I have no idea if what this developer wanted to do was create services specific for their airport, or replace all services like LVFR did with their airport services package. Despite putting their code on a new path, which would mean they want it to be specific to their airport only, what they’ve effectively done is still replace ALL services in an installation, rather than what they intended.
If they meant to just create services for their own airport, YOU can fix all this by changing LTAUAirportServices/Shared/Services.spb to a new location at
AirportServices/ICAO/Services.spb and leave everything else as is.
As annoyed as I am by the MyCompany stuff in the directory names (agghhhh), those files are at least at a unique path that likely will be required by calls in the Services.spb, and those services scripts shouldn’t affect those same services scripts that are in the default implementation.
If you ever decide to do your own development, please make sure you use totally unique names from the sample files and files within Asobo’s installation. All those services files they wrote, baggageloader, fuel, V2a, those are Asobo’s filenames for their scripts. Don’t use those names for new sets of scripts (unless you Actually want to replace those scripts, like LVFR did (and most likely, being a good developer, I bet they STILL used new names and didn’t just replace the original scripts).
Sorry I used so many words, but, I wanted to make it clear what’s going on.
P.S. way back early on in late 2020 when I first started trying to modify Services files along with a bunch of other people, I figured out that the SDK was written incorrectly with wrong paths and notified MicroSobo and they eventually fixed and expanded the Services section, which was why a lot of early Services.xml files weren’t working properly, so frustrated developers just turned everything off. Since then SDK and samples have become excellent. Sadly, many developers still get it wrong even though all the details are there.
P.P.S. the reason I hate seeing “MyCompany” in file paths isn’t just my annoyance at developers not understanding why Asobo put that in their examples in the first place (to be replaced by the actual company name), but, so many developers leave it that way that files from multiple developers and packages end up being at the same VFS path and overwrite each other all over the place and cause CTD’s for users as files from one developer conflict with those of others, and cause memory overwrites and all kinds of other problems. MSFSScenery is famous for doing this. I’ve stopped purchasing from them, but I’ve had to fix multiple packages from them in my own installation to keep it from crashing. I’ve seen situations where developers even overwrite their own files of the same name and path in other packages they release (I’ve pointed this out to Carenado for instance (gauge issues this time).
In fact, technically, rather than just replace that with your company name, it should, unless you’re actually expecting to be sharing these files across multiple packages, it should be a totally unique package specific path. So, for instance, I put ICAO or something similar there rather than what I use for my “company” name.