As you might expect if you follow the devlog, work on the Steam integration was the main topic of last week. With the technical foundation of the actual Steam client in place and the design of the Steam-specific parts of the account management system in the works with our freelance designer/developer, my focus shifted towards adjustments affecting the game itself. So far, this was concerned mostly with smaller display things…like not to show a login/logout button when playing via Steam, how to open external links, where to put some low-priority info that currently takes up space on each and every screen but could actually be hidden in a menu or a different page somewhere. You’ll likely see most of these changes land in all game worlds soon as I fixed a couple of other bugs in the process. I want to wrap up this stuff this week so I can move on to higher-level things like the actual “gameplay experience” within Steam (and outside of it).
I also improved the process of how the Steam client on Windows ensures all prerequisites are met. This should be a non-issue on most modern Windows installations, but early versions of Windows 10 and anything before that need special hand-holding. I might reach out to a few players soon to give this a try on their machines. So if you are on Windows, please feel free to leave a note on this thread!
Last but not least, we had an internal discussion about the so-called “bar-sums”, the mechanism which decided whether an aircraft is large enough to be allowed to operate between two airports (the motivation being that we want to prevent intentional or accidental slot-blocking by using aircraft that are too small relative to the demand of a given airport pair). That restriction is based on the namesake “bars” which in turn depend on an airport’s absolute demand. Since demand is fluctuating and typically rises over time, we are facing a bit of an issue with the upcoming data patch, because a lot of airports would suddenly fall into higher categories, causing potential issues for players who’s aircraft on certain routes would be “too small” over night. The decision for now was that we’ll update the demand anyway (everyone wants new demand figures, right?) but will remove the mechanism that auto-disables flights violating the bar-sum rule. That way, the changed values only become an issue once new flights are scheduled or existing ones are changed. Please let me know what you think below!
Great solution on the bars. I couldn’t think of a better way of dealing with it, as demand is definitely an issue on some servers now (looks like covid numbers). Will the private servers also get this demand update?
Exclusive game worlds are technically identical to our public game worlds. Whenever there are data changes or updates, these are applied to exclusive game worlds as well.
So for better or worse, all updates will land there as well
As much as I understand the size restrictions, I think there’s one key piece missing - allowing regional jets on routes under a certain distance between large/very large airports.
Look at any major airline hub and you’ll see this happens regularly. United out of IAH is a great example. DFW is regularly served by CRJs.
Is there any potential for introducing a bit more nuance to the route restrictions to allow routes within a certain distance of a hub?
Not sure which exact example you’re referring to, but using a CRJ between in DFW and IAH (for example) in AS is likely the sort of “slot blocking” we’d like to avoid even though this sort of ops might exist in reality
Im referring to the example of United operating CRJ’s between IAH and DFW. Or look at any Northeast US hub and every airline is operating flights to short-range mega airports on RJs.
Obviously I understand the desire to avoid slot blocking, but it seems like there’s a better system than just arbitrarily banning RJ’s from flights between large airports across the board.
There could be distance limitations, caps based on number of total departures an airline has (i.e. 10% or less of the total departures an airline has and within X00 miles) that would allow us to build more accurate feeder networks for close-in destinations out of hubs.
Adding a range limit would go against the original motivation for the rule, because it would essentially allow to flood an airport with lots of cheap, short-distance flights to block slots. It’s sad that we have to constrain the game like this because of a few bad apples, but that’s just how it is.
Concerning more complex rules: Those quickly become hard to understand/communicate and of course come with their own unintended side-effects…the more complex, the trickier to get right
I believe one missing piece to the puzzle might be that the meaning of “slots” differs quite a bit between the US and Europe. While in Europe, airports are usually limited by runway capacities, airports in the US are often limited by terminal capacities. DFW has 7 runways, IAH has 5. Just for comparison: LHR, one of the world’s busiest airports, has 2 (!). So if United doesn’t have gate or space constraints in DFW and IAH, then of course there’s no reason not to fly CRJs between the two. But AS is missing the required dimension to simulate this properly.
Thats fair. Perhaps something that can be considered for AS2.0 - expanding the complexity of slot/airport limitations to better simulate real world conditions?
