The intended base game behavior is that the contract for the uninstalled airline will still show up (with the question mark logo). Aircraft will arrive in random liveries. This helps because you can load a save, realize you’re missing an airline, get the airline and try again.
Tweaks freaks out because it doesn’t know what to do with the airline that isn’t pointing at any data. When tweaks freaks out it throws an error. The base game loading system handles errors by discarding everything in that loading group, in this case flights.
My hunch is that airlines are loaded on request from flights, so any airlines that get loaded before the error are still shown, while the rest you have to wait for the contract to come around.
No, if I save and reload the same error message pops up and all flights are wiped etc. If I roll back to the stable release I do not have a problem. I have quite a few airline mods. I’ll try unsubscribing and resubscribing gradually to narrow down if its a certain one tomorrow if that helps.
If you can send me the save file that’s doing this that would be awesome; if it behaves the same for me it will be a lot easier for me to find the issue.
Been following this and reading with interest. Regarding “Tweaks freaks out because it doesn’t know what to do with the airline that isn’t pointing at any data.” If I understand this happens when you remove and airline mid game.
As you say, the vanilla will just make something random with it with ? for the airline.
So my idea is to do kinda the same! BUT, we make an airline named (?) OR (No airline), with no country code, put in one plane that is white, (So no livery) and no country code, can you then point all the no data pulls to that special airline?
Don’t even know if it is possible or needed, but thought that would then make the data hunt for bugs around airline easier. Just brainstorming.
The eventual fix look a lot like this; just less explicit. Its generally good practice to have default behavior for “what happens if there isn’t data where I think there is” and I do try to have this throughout; the bug is an example on some link in that chain that I neglected, but much of the chain is in place anyways.
Patch for null reference exception causing failure to load some saves.
I’ve worked on some of the other active bugs (and made good progress), but I’m releasing this ASAP since Beta 3 isn’t totally playable. This should address that, but I haven’t tested it super thoroughly. It does solve the issue in my test cases though.
Remaining bugfixes before 2.2.0 stable
30% complete - Fix for tweaks aircraft shadows and layer changes more generally
70% complete - Fix for broken airline descriptions in contracts window
Under investigation - PAX multiplier being ignored?
In 2.2.1 I’m going to overhaul the flight types system. In my play-testing I find that there is:
lots over overlap between flight types
not lots of incentive to choose certain ones
not good communication to the player about these differences
Overall it feels … muddy. And on top of that it isn’t very robust at a systems level.
I want to pivot to a scheme where each airline contract explicitly tells you what to expect from flights and where this is customizable per-airline. Details are WIP but I’m going for a game loop overhaul and I believe the initial effort fell short of that. I’ve now unlocked the UI customization perk and am on the cusp of saving and loading my own data, so I have better tools this time around.
Livery tools will also get updates in the post 2.1 time-frame to tie into the more customized airlines. With what I know right now I could have features like changing the title card of the aircraft (once arrived) and even messing with ground handling parameters, but it would still be a look-alike in disguise with fundamental limitations. I plan to use the custom data import/export/save/load tools I’m working on for airlines to really test the limits of what can be done here. where the 2.x theme has been “do more with airlines” the 3.x theme will be “do more with aircraft”.
Installed Beta 4. I can report that now airlines provide me with flights that haven’t done so until now. The turnaround times however…mostly they are pure poison for my test airport using remote stands mostly. What might be the incentive of taking fast turnarounds besides being able to have more flights crammed into a day?
I’ve also found the current distribution of desired turnarounds to make remote stand operations challenging; that will be adjusted for sure.
What I’m trying to replicate is the pressure on/from the airline that the aircraft should spend as much of it’s time as possible in the air. This is generally more intense for low cost carriers because they run on tighter margins and for short-haul because the impact of longer turnarounds is multiplied over more fights.
From the player perspective getting more fights per day on a stand is desirable because you make more money, but long turnarounds are easier money. Regardless of what a player chooses to do, I’d like it to be viable to lay out a high volume section of the airport differently from a low volume section and have both make sense. Being able to run very quick turnarounds should be a gameplay reward for having optimized everything contributing to turnaround time, but shouldn’t ever be necessary to enjoy and progress in the game.
As an example, a player going for ultra short turnarounds would buy service vehicles dedicated to each stand and eat the extra cost of the idle time to make sure that aircraft get service immediately. They’d also have many boarding desks per stand, and make efforts to reduce walking distance for arriving pax. Anouther player would spend the same in game time and money on an extra stand or two, run more normal turnarounds with less tuning, and be in a similar situation game progression wise.
That’s all discussion of what the goals are; to be clear I don’t think I’ve hit them yet.
I did some testings now. Obviously, there seems to be an issue when schengen visa rules are activated. As soon as this is used, the route generation is not correct anymore, in the sense that airlines offer routings from B to C, although based in A.
When schengen visa rules are disabled route always includes a destination in “A”.
What you’ve described is consistent with the current implementation. My understanding as a non-European/silly American is that such flights legally can happen, but aren’t the norm for most airlines. I am considering moving forward the option to allow multiple base countries; we’ll see if I can do that without introducing new and interesting bugs. That feature would allow me to change the nationality check to function without caring about the shengen system in game; as the multiple possible “base countries” could be defined by the airline.
I’d also be happy to be refereed to articles about the schengen visa as it affects airlines; when I’ve tried to learn about it I get vastly more articles about how it affects travelers, which is a pretty indirect way to learn airline behavior.
So technically airlines with a registration in the EU can open bases in every EU+Schengen country and operate from there.
This is mainly done by LCC and holiday charters.
Mainlines usually operate only from their own country only. Exceptions are countries which share the mainline (examples are SAS or Air Baltic)
For the beginning I would say, keep the same logic: if there is a country code in the json, use it. If there is non, you get all kind of destinations.
If you can later add further hubs/bases, that would help a lot for those cases.
Fix for broken airline descriptions in contracts window
In vanilla ACEO, once an airline is loaded in your world, its description is saved as part of that save file. My misunderstadning of this is what lead to bugged descriptions: I was adding lines to the description every time the save was loaded. In this version, airline descriptions are reverted to default every time a save is loaded. This purging is only necessary because I broke a bunch of people’s descriptions. In the future, purging will be moved to a debug menu button instead, but for now I want to make sure that the issue is fixed even for people who aren’t paying much attention to descriptions.
Remaining unfixed bugs:
Under investigation - PAX multiplier being ignored?
Not perceivable - I do a very coarse check to see if airports are near your airport to make sure that routes to nearby airports get generated early on (in each play session potential routes are generated over the first 5-10 minutes). This “near airports” check currently returns too many airports. Not sure if bad parameters or bad math; shouldn’t be hard to fix.
The basic function of the schengen regulations is quite easy.
People of all schengen member states can travel freely between these states without the need for border controls. Therefore, with regards to Europe the vanilla implementation of “international flights” is quite unrealistic.
As the majority of european countries are members of the schengen agreement, most flights within Europe do not require passport controls anymore. One can argue that these intra-schengen flights are handled like “domestic” ones.
Therefore, to better reflect reality. I am always playing with schengen rules enabled.
If someone wants to leave the country code tag, they have to change it manually. I’m not removing anything.
As soon as we know how to setup the json when the Tweaks support more bases, I will ad that logic.
