Last Monday, Domination launched into its next iteration. For that, I decided more or less on the spot that I wanted to add a small new admin feature: Game world resets triggered through the admin UI. In the past, relaunching a game world would require me to log into the respective host, stop the game, drop and recreate the database and restart the game for it to re-install itself. With the free game worlds we introduced for Steam, I already built an auto-reset mechanism that replaced all of these manual steps. But it only worked automatically so far. Now, someone with the respective permissions can trigger this very dangerous operation by just clicking a button in the UI 
What followed was this post’s namesake reconciliation: A technical issue at one of our payment processors lead to a bunch of transactions left in an invalid state that only became apparent once our accountants tried to do…well…accounting. Sorting this out and figuring our what happened and how it could be fixed in a legally correct way took a frustrating amount of hours, especially because the payment processor in question was a pain to work with. So much so, that I am considering replacing them at the next opportunity that presents itself.
Anyway…in the second half of the week, I finally got started on the first steps on the Path to DS implementation in current-generation AirlineSim. Emphasis on “first steps” here…this project is going to be huge and messy. I immediately realised that some of my assumptions in the linked post clash a bit with how certain things work in current-generation AirlineSim, especially in terms of flight ratings and airline image. I actually spent quite some time trying to determine whether it would make sense to do a legacy-compatible version of Individual Travel Request Generation first to address this, but I haven’t arrived at a conclusion yet. It’s going to be a bit of a chicken-and-egg situation either way. Rest assured I’ll keep you posted on this 