sviridovt

I might play around with fonts more, I am using TailwindsCSS with this redesign and am still figuring out the exact design as far as fonts and the exact color scheme. I do want to go with something a bit more interesting

Hi Folks! I am now putting the new dashboard into preview as I have achieved feature parity with the current dashboard, there are still a few issues to work out and notifications/competitive outlook is still not supported (though will be before full release). This is also the first step in a UI revamp, so general feedback about the look is appreciated as well. I do want to add some more color into the whole setup and plan to play around with it more. Further, while the new dashboard does show fuel prices, and those prices are 'real' in the sense that this is what the sim will use once the fuel update comes out, the flight model currently does not use those prices. As always, I look forward to hearing your feedback. To get a look into the new dashboard just go ahead to the dashboard and press the 'Try Now' button. Thanks!

Yeah, I think it was something to do with your browser not recognizing the certificate and intercepting the response. I'd be willing to bet money that the request actually went through and it was the response that got intercepted. Either way glad you're enjoying the game!

I mean it's in your interest to do that regardless to make sure that planes keep flying (indeed this is what real airlines do), however if you wish to keep planes stationed (say overnight) just make sure that you either own the terminal or lease the gate that it's staying in since those gates are charged a flat fee rather than a per minute one.

Your revenue is number of pax * price of the ticket (plus whatever IFE you have this might bring some income). The costs of your flights do not depend on the price so may be discounted for this discussion. The default price is slightly lower than the median of what the willingness to pay is, such that with that price you should be able to capture about 80-90% of the demand, if you want to capture 100% you'll have to lower prices, similarly if you capture less of a demand, you may increase prices to generate more revenue per passenger. Further consideration is which passengers you're capturing, for example if your aircraft has 2 or more classes, it's possible to see that pricing your economy class might drive passengers away from business class as you have excess capacity in economy from lower cost pax opting to not fly (admittely there is no mechanic in the sim to say that if the prices are similar enough some passengers will opt to 'spoil themselves' and upgrade, this is covered in my plans for demand redesign). In this scenario, you might have passengers who are willing to pay a premium price but would still opt for the cheapest option, as you price people out of economy those folks will buy an economy ticket rather than a business class which may also decrease your revenue. Essentially it's important to remember that the passengers are 'fluid', and do not attach themselves to a particular class just as in real life your business class competes with your premium economy class and economy class etc. As for an ideal formula, there isn't a mathematical formula that I'm aware of, and while I'm sure that it exists, I try hard to make sure that there isn't a hard and fast way to 'win' the system. I aim for realism with the sim so want to keep some variability to keep things interesting.

'Recommended' prices are just slightly below the price a median passenger is willing to pay, if you're well below the demand you should be safe to increase the price by quite a bit. If you're still having issues making a profit, it's likely that the aircraft you're using is not a good fit for that flight. The price passengers are willing to make do not take anything about the aircraft you're using into account to determine their willingness to pay (reputation impacts associated with your configuration and other aspects like how fast the plane is impact how preferrable your flight is, which plays a role when consideration competition as your passengers might still prefer your airline even at a slightly higher price but it makes no impact when there is no competition).

Here is the new Arcade world, apologies for the delay as I didn't want to reset the world so close to reset of world B, I was also investigating an issue that turned out to be false alarm. World Arcade I Timeframe: 2020-2200 Starting Money: $10 Million World Speed: 7 Days/30 Minutes Difficulty/Rules: Arcade, no political restrictions or aircraft release dates.

Ok, I did a deep dive into the increase of latency since last update and it appears to be false alarm, after not being able to understand where the latency was coming from (since all of the page specific metrics/alarms were not showing any increase) I discovered that the issue is in the metrics scraping request which has seen a massive increase in latency. Not sure why, no updates to metrics were released in the update but either way there is no impact to the players. See graph below where green represents the total P95 latency (latency of the slowest 5% of requests) and yellow represents P95 if we exclude metrics requests (note that the update in question was released to prod on 12/27). As such, I will be launching Arcade I later today seeing as there are no latency concerns.

That was a purposeful decision to not add them as I would prefer to add other aspects that make a hub a hub instead of just having you label it a 'hub' and having it automatically put all the other things into place. If I was to add the term hub it would be purely cosmetic and I don't wish to do that until there is a more in-depth facilities system such that it's more than a checkbox.

That is kind of the the idea behind arcade worlds, for them to last a long time (although not infinite, to allow people to get in early in the world), Arcade 0 was a trial run hence the really short run time, the plan for Arcade I will be to run for over half a year IRL.

When you start a route, if you're going to be staying at an airport a long time make sure it's not using 'A' gates (short term stays in A gates should not be very expensive, it only starts getting expensive after you've stayed over 30 minutes). If there are gates available for lease at an airport it will lease them for you automatically (unless you have a terminal) when you create your flight.

It does that if the server response either crashes or doesn't receive a response but I'd be curious to see why it says not secure, I'm guessing there is some kind of certificate validation issue. I have validated that the certificate is correct so I'm guessing it's something with how your browser is validating it. Can you check that you're on the latest version of Chrome? Also does the same not secure message appear in your other windows?

I plan to restart Arcade I in the near future (I wanted to have a bit of a gap with it being very close to World B reset), I do also have a long term strategy for more worlds that I haven't finalized but in general I want to move towards a more shorter, but faster moving worlds. Further I'm working on addressing an issue caused by the last update to prod, whereby since it was pushed latency has slowly creeped up across the board. This is due to a slight increase in CPU utilization for the prod container, likely caused by a bug fix whereby flights weren't forced to update in some scenarios where they should be. This significantly increased the load on the container and thus increased latency on average. I am working on addressing this but would be necessary before adding any additional worlds. I do have a long term plan to bring on another server (in FRA, in addition to the current server in ATL) though this will have to happen after IPB deprecation to keep the finances in control (currently it runs on a separate server). That said, my current plans for the worlds however are as follows: World A IV: 1970-2000 (1 day every 10 minutes) World B X: 1950-1980 (1 day every 10 minutes) World C I: 2000-2030 (1 day every 10 minutes) Arcade I: 2000-2150 (1 week every 30 minutes) Campaign 1: 1940-2050 (1 week every 30 minutes, all realism rules apply) These are bound to change of-course and will be launched in a staggered manner (plan to start around March) but that is the current plan.

Looks like you're doing slot rental, which is what's costing you. Basically when there aren't enough gates at an airport for you to lease one, it will utilize a slot rental system whereby you will pay per minute that you're parked at the gate, that gets very expensive if you stay at an airport for a long time. You can tell you're using slot rental if your flights arrive/depart in A gates.

Arcade world is over, hence why you can't do anything. I will reset it to Arcade I in a little bit but wanted to give it some time since World B just reset as well for spacing purposes. 1. Yeah, currently that's the way I have it set up. I do plan to make it possible to do an immediate configuration change for a (significantly) higher fee. 2. Do you get an error? That should work even in paused world.

Hi folks! As we approach the end of 2023, we can reflect on the changes that happened to the sim over the past year. Although there were only a handful visible changes, there was significant work done to improve stability and optimize the back end to improve the experience for all players. Early in the year we migrated hosting from AWS to Linode, which has reduced the overall bill. Further I have used this opportunity to improve the overall infrastructure and reliability. The bottom line is that when the sim was created 5 years ago, I was not nearly the programmer that I am today (and hopefully in 5 years I will be able to say the same about myself today). I have always credited ASW with being the single biggest learning in my programming career, although I have been programming from an early age, this was my first long term project, and on more than one occasion my lack of experience with long term projects led to taking short cuts that led to issues long term. I have gotten better over the years, and I thank you all for giving me the opportunity to better myself. That said, I have taken the past year primarily to take what I have learned from 5 years of keeping the sim up, combined with my recent experience programming professionally for one of the largest tech companies to improve the sim stability, drive better user experience and create a solid platform before moving on to major feature work. Stability Improvements Improved Monitoring and Reliability One of the things that I did as part of migration was add in better monitoring capability for errors and latency. We have, since the early days of the sim had analytics on things like user counts, as well as taking a snapshot of the sim state during any crashes, which remains useful to this day for debugging specific problems. However due to how this data was stored, it was difficult to drive any actionable decisions regarding what to prioritize and where to spend more time on, both in development as well as bug fixes. As such, we added server side monitoring and log indexing (previously logging was done to a file, making it cumbersome to work with as there was limited support for even the basics like searching for a specific request). This gave important visibility into which pages were causing the most issues, latency for each page, as well as the nature of the issues. Along with that it gave important metrics regarding which pages were getting the most traffic, and which features were being used most vs least etc. Fatals reductions One of the main goals to come out of the expanded monitoring was tracking how many fatal requests were were receiving on each page, at the time we started tracking this metric I found that we were getting about 20 fatals per day (A fatal being a 5xx error, namely that page with the error code, that error code identifies a snapshot that I can refer back to debug the issue), however the vast majority of the fatals came from only a handful of pages. As such, much of the first couple of months was spent focusing on pages that were causing the most issues which included the scheduler, as well as the flight update page. The vast majority of the issues were down to lack of input validations (like having a string instead of number etc., notably while we were sanitizing input for things like SQL injection attacks, we weren't verifying input validity for the specific context). However some bigger issues were discovered as well. For example, about halfway through last year I transitioned to a CI pipeline for deployments (automating deployments such that deploying new features or bug fixes did not require manual actions on my side but rather a press of a button, a great improvement in my ability to get things out faster), however as part of that change I moved the beta server from my home server to the production server, and used the same instance for beta as I do for prod. This created issues causing fatals due to the fact that owing to the Event Manager taking a number of connections, when combining connections required for both beta and prod instances, we were running out of connections. Discovering this issue prompted to disabling beta briefly and undertaking a containerization effort which completely isolated beta and prod dependencies and greatly improved reliability, creating a firewall between the two stages. We also now take greater care to track database connections to avoid this issue from happening again. All of this work focusing on stability paid off, following the improvements we have reduced from having about 20 fatals per day, to now having about 2, with all pages having fatal % well under 10%. A great improvement from previous years. Latency Improvements After concluding the fatals effort, the next area of focus was on improving the latency. A number of pages were marked as needing improvement, chief among them was the route research page. Apart from being the most requested page in the sim, it was also the highest latency with a P50 (median request) latency of about 23 seconds, and P95 (95th percentile) latency of over a minute and a half. This was unacceptable. I have taken a personal goal of reducing latency across the sim to a P50 of 2.5 seconds and P95 of 5 seconds. To achieve this goal, I have taken the strategy of reducing dependence on server-side rendering in favor of API calls, allowing data to load as it arrived. As the vast majority of the latency issues was due to waiting for data to load from the database, this kind of divide and conquer approach led to significant improvements, further pagination was added server-side to limit the data that is being loaded. When applied to route research page, where all of the table data (my flights, all flights data) was moved to API based approach we transitioned the page from being one of the worst pages for latency, to being one of the fastest with a P50 of about 250 ms with little variability between busy/non-busy flights. This approach was further applied to other pages, such as the airline ranking and flights list page to overall improve latency across the board. When I first undertook this effort, i set up an alarm for P50/P95 latency metrics, and at first almost every part of the site was in alarm for one or the other. After all of these changes we are regularly green on the alarms for specific pages. Although the work is not done as we are at 5 seconds for P95 sim-wide (and P99 over), we are in a much better place. One of the other changes that came out of this effort was a complete redesign of the new flight/update flight flow called by the scheduler, this page was problematic for both latency as well as fatals and bugs. As a result, I took the decision to completely redesign the page, and although the scheduler API still remains one of the higher latency pages (I plan to undertake an improvement when I redesign the scheduler which is planned) it was a noticeable improvement with a significant reduction of bugs in the flow and improvement of latency. Ongoing Feature Work New Dashboard/UI Redesign Although initially only meant as an improvement to support new fuel model (which is otherwise ready to go), this ended up a much bigger effort as I decided to take this opportunity to start migrating the broader sim to react rather than Django based templates, this is an improtant step to improve the usability of the website, further the new UI is designed to be mobile-first, addressing a major issue that currently exists with the sim. This is all part of a broader effort to move completely off of Django based views in favor of a React site, however as this would be a significant undertaking that would take over a year, I am in the meanwhile working on this 'halfway' solution where we integrate React components inside the current Django site that we can later transition. This way, you will get the advantages of the new UI sooner. As of now, the base work for UI is done, and I am currently working on integrating the newly created SDK to establish a front end/back end connection. Once that is done the new dashboard should be ready for release. New Fuel Model/Maintenance The fuel model is complete but is pending dashboard (I do not wish to release the fuel model without a way to see fuel prices etc.). As it stands, the model introduced dynamic fuel prices that are variable day to day. Further it fixes one of the main issues with the current fuel model, which is that it does not adjust to inflation, since at present we do not model inflation in the sim (and have no plans to do so to avoid having to constantly update flight prices), meaning that fuel is unrealistically cheap in earlier years. Maintenance Update One of the major updates planned is to the maintenance system, part of that update will also be a redesign of the scheduler which is intended to allow you to move flights between planes. More will be coming on this at a later time. New Demand Model One of my major undertakings for 2024 will be a redesign of the demand system, this will mean the creation of a new service, what I termed Atlanta service written in Rust to take advantage of it's more optimized runtime performance (also I just want to learn Rust), as well as a graph based database to allow implementation of connecting flights. The model itself is already worked out (math wise) and will introduce 7 different types of passengers each with their own needs and priorities when it comes to choosing flights, price will no longer be king when it comes to certain kinds of passengers. This should allow better diversity of airline carriers as particularly wealthier passengers would be a lot more pickier about which flights they want to take, though would be willing to pay top dollar to ensure their demands are met. Closing Thoughts As we go into the new year, the 5 year anniversary of ASW, I am excited for the future and to get back into feature work now that we have a good platform to build on. While my availability unfortunately remains unpredictable due to my job and other commitments, it always brings me great joy to work on ASW and interact with the community. Thank you for making it possible and I wish you all a happy 2024 and I hope you will join us as we celebrate our 5th anniversary! PS: As a thank you to our Patreons, they got to see this post earlier. Interested in supporting the sim? Become a Patreon here!

Correct

Update 23.12.27 New Features Updated Willingness to pay formula to slightly increase pax willingness to pay on ultra short haul routes, decreasing it significantly for medium haul and long haul routes. Note that this change will not impact Arcade ∅ which will stay with the current algorithm but will impact Arcade I when that gets started, this change will also effect World B IX following any route updates. Changed default price for routes to be slightly below median willingness to pay, such that assuming there are no competitors you should be able to capture majority (though not all) of the demand for a route given the default price. The Scheduler direction selector will now flip on flight creation to make it easier to create flights in the opposite direction Various Scheduler performance improvements Bug Fixes Fixed an issue where updating the route in the Scheduler would not force a route update. Fixed an issue where the Scheduler would allow creation of flights before the turnaround time. Fixed Airline selector drop down on route research and some other pages not showing user's airlines. Please note that these willingness to pay changes are designed to make the game harder and will be applied to the current World B IX, as such you might need to re-adjust your prices down. I apologize for not getting these changes out earlier, I expected to get them out before the world reset but miscalculated when the B VIII was going to end. Also note that while this update changes how much pax are willing to pay, it does not change the demand itself. Please let me know if there are any issues or suggestions, I will continue to mess around with the values in the coming days to further tweak them for best in game experience. Thanks!

Resetting world B World B IX Timeframe: 1950-2025 World Speed: 10 Minutes/day (Paused until tomorrow, 45 minutes/day until Thursday, December 28th to give people time to join and set up their airlines) Starting Money: $5,000,000 Rules/Difficulty: Normal/5 Instant deliveries for new airlines Note, that there will be a rebalance update for willingness to pay to reduce the amount that passengers will be willing to pay some point before the world accelerates to full speed. Further, this is likely the last iteration of World B (at least in it's current form), as I wish to move these longer running worlds to run at a pace of 7 days per turn to speed them up (currently World B runs for about half a year IRL, I want to make most worlds run at most 3 months or so to speed things up). I am working on plans to create new worlds and will share those details at a later time.

Hi folks! We are now introducing a new world and a new game mode, Arcade Mode. Unlike standard worlds, Arcade Mode is a faster game world, without any political restrictions, aircraft manufacture days, meaning you're free to fly whatever and wherever you want. The game world further moves at a faster rate of 7 days per turn, which for this world would happen every half hour. This means that 1 real life day is approximately 1 in game year. For now this is just a preview world that will run for 20 days, however I will officially launch a long running world after. As always, I would love to hear your feedback regarding any changes you'd like to see or issues you face. Thanks! World Arcade ∅ Timeframe: 2020-2040 Starting Money: $10 Million World Speed: 7 Days/30 Minutes Difficulty/Rules: Arcade, no political restrictions or aircraft release dates. Unlike with other worlds, we will not have an initial slower launch period.

I'm sorry what's the issue?

hmm, I wonder if it's still updating in the background but removed the box too early, these are the kinds of shenanigans I would expect if that were to happen.

World B IX will have all the same configuration as B, though I might play around with game balancing to reduce revenue and balance the game out during the swap. There is also a new world in the works to be an open arcade world where there are no political restrictions, planes can be bought at any time, and time will advance by a week at a time rather than a day. That world would also reset every IRL year and be 'endless' rather than fixed to a timeline. Currently working on all of the required changes for that and plan to get a preview world out hopefully within a week as a test run to run for the rest of the month.

Ok, I'll take a look later. It does appear that something hasn't gone right since you do have gates without any flights in your new terminal, so there should be capacity.

Update on the new dashboard I haven't had quite the time to work on it as I had hoped due to work commitments, but have made some progress. For one, I have made a decision to move away from the 3 pane approach and instead have 2 equal panes with the left pane being the informational pane, showing cards that will show up all the time including valuation graph, fuel prices, top/worst flights etc. with the long term plan to support user customization on which cards there are and where they appear. The left pane, or the notification pane will show notification cards, such as alerts about issues with your airline (plane leases expiring, aircraft running out of cycles etc.), aircraft deliveries, as well as competitive outlook when any of your competitors update prices, add/remove flights etc. This notification system will also replace the current in-game messaging mechanic thus deprecating that system. On mobile and smaller screens the two panes will appear as tabs instead, thus furthering support for mobile users which is a priority for me. The other use of the new dashboard is the introduction of React into the game as part of an effort to refresh the UI and add interactivity to the sim as well as increase performance. At present, the entire UI is processed server side, which results in some issues such as high latency on certain pages that require a lot of data, as well as limitations on the interactivity we can do (we do leverage APIs to enable interactivity in some places such as the seat map generator or lately in dynamic tables, but currently this is very much an exception rather than the rule). This is a quite dated approach and one I hope to replace. The long term plan here is to completely sever the front end and the back end, however with the amount of pages we have, with most requiring some amount of new APIs this is significant amount of work. Instead of stopping working on new features in favor of dedicating significant effort to purely front end work (or as I would call it, hell), in the interim I am redesigning pages as I go to embed react pages as components within existing site. Since the dashboard is the first such page, there is a lot of additional work to set everything up, especially since I want to be cautious about having all of this new work in a separate package such that whenever the full migration does happen, I can just import it into the new UI rather than needing to put in a lot of effort migrating everything over. I'm happy to say that much of this pre-requisite work is completed and I can now start working on the actual dashboard.