Dev Log Week 2026-29: Many happy returns!

English Boards
1

Sorry (not sorry) that the title doesn’t make any sense…it’s nobody’s birthday today (it would be my cats’, had the last of them not passed away last year). It’s just that I dealt with a lot of returns last week :sweat_smile:

As revealed in devlog 28, I am currently working on a possible solution to the “imbalanced inbound and outbound traffic” issue affecting ITRs in particular. Tuesday and Wednesday were taken up by one of the few annual real-world meetings of the simulogics team. But after my colleagues left for their home offices again, I dove back into return bookings.

As I got the basic architecture adjustments out of the way in week 28 already, I focused on the actual return searches and bookings last week. From an implementation-perspective, this worked fairly well, and on Thursday I was able to post this very unimpressive screenshot of the very first return connection to an internal chat:

image
image1897×426 53.9 KB

This just uses the vanilla ORS search UI as it is today, so one has to squint to see that it’s actually a return connection.

Either way, the result in this screenshot already uses a data dump from Paine which I used for initial performance testing. When I first ran the new system with the Paine data but with return connections disabled, I was pleased to see that it worked really well on my little Mac Mini from 2018, even before any optimisations.

After turning on return distribution, though, said little Mac broke into quite a sweat. The Paine data set is far from the largest when it comes to the number of flights, and yet (at least in my local environment) the code currently fails to process traffic distribution fast enough to keep up with the simulation.

To be fair, this was expected. And week 30 is going to be about figuring out where and how I can take shortcuts to speed everything up just enough to make it work.

But even if I fail to do so: It looks like the new algorithm brings a noticeable performance improvement even for single-direction distribution, so the project won’t have been in vain either way.

2

Just a question Martin - I notice in the screenshot, the ORS calculates total journey time from point A back to point A. Hopefully it won’t be the case that we now have to have the fastest round trip to satisfy the ITRs?

3

Nah, of course not. That screenshot was just literally taking the existing ORS UI as is and rendering a return itinerary without any adjustments.

4

So, this seems to have negatively impacted my connections - I’ve gone from no more than 30 or so flights running under 70% LF to around double that over night. I suspect it’s because my wave structure often means you’ll get a connecting pair one way, but not the other - ie: one way B-A-C works, the other it’ll be C-A-D (as my waves run A-B-A, then A-C-A, then A-D-A). I’m not a fan of this so much - I had no issues filling return trips or the pricing problems that others have described before - so it certainly wasn’t a universal issue. Also, it often happens that it’ll be my mainline carrier in one direction, and then a combination of mainline and subsidiary the other - will these be affected because it’s not all the same carrier?

Are there any pax who look for single journey itineraries now, or do I need to entirely overhaul my schedule?

Edit: Just checked the subsidiary and the loads appear to have taken a hit there too.

Edit #2: Having just checked the ORS, this looks as though this change may have inadvertently skewed everything towards the largest airlines with the most comprehensive route structures? I intensively use my subsidiary/interlining partners in one direction and mainline flights only in the other to enable competition with the big players where I don’t have the fleet, this seems to have tipped everything towards the biggest players. I’d suggest this change is a seriously negative one and should be put back ASAP - would a better solution not just be to make sure there are the same numbers of type of ITRs at both ends of a route? Therefore, all things being equal, there’ll be the same bookings?

Essentially makes the game unplayable for me and with the scale of schedule changes this looks like I’ll need to make I’d probably just give up and not come back - I’ve even found a flight tomorrow running 0% full that was 100% full every previous day.

5

Since there currently isn’t a maximum stay and passenger types don’t have a preference for a particular stay duration yet, a single daily flight/connection should suffice for a return booking. That’s in principle, of course. Concrete circumstances might make it more difficult (like on very competitive markets with loads of connections).

Depends. Generally speaking, a return connection requires the so-called plating carrier of each segment to be the same. At the moment, this is determined based on the longest leg of a segment. So as long as your mainline carrier is the plating carrier in both directions, there shouldn’t be an issue.

What does happen though is that a connection of different carriers doesn’t qualify as “direct” anymore for the purpose of Neutral Display Order, which matters internally for connection culling…if there are too many viable options, connections are culled before they are rated based on said order, meaning non-stops and directs get priority over connections between different carriers.

No, not at this time, as they would go against what this change is trying to achieve. Not ruling out that one-way requests might be added in the future, but even if that was the case, I’d assume those requests would be relatively rare. Nothing to build a business on, anyway :slight_smile:

I wouldn’t go that far just yet. As said, this is a first stab and things might (and likely will) still change.

This is a fair point and I see a similar risk. That said, I also see it as a piece of the puzzle to reach the long-term goal of better differentiating business models in AirlineSim. As it stands, interlining and connections in general are far too easy (imo). Nobody would even consider an LCC model without actual connections because it only has downsides. Transfers are essentially free and just happen automatically…one doesn’t even have to put in too much effort to schedule clean waves and planes still fill up with random internal and external transfers. As convenient as that is (or: because it is) I’d like to change that in the future, by making connections generally more costly and hard to achieve, but also by adding new features (this particular case makes codeshare sound more attractive than ever :wink:)

With over 130 aircraft, you airline group doesn’t appear to be on the small side either :slight_smile:. But yeah, as said, as things stand at the moment, especially in an existing game world, this will be easier for large airlines that do not rely on interlining and happen to have the right wave structure. Not sure though how it would play out in a fresh game world, where everyone would have to build up a network under the new rules.

Firstly, Paine is a cheaper, experimental preview game world for a reason: Changes (including drastic ones) can and will be introduced at any time. Secondly, and as said above, I wouldn’t jump to conclusions too fast. If the flight is running at 0% tomorrow when it would typically run at 100% and the change was only introduced yesterday, chances are that flight was already getting lucky before :slight_smile:

But again: This new system runs since yesterday. There will be bugs, there will be things that needs tweaks and optimisations. For example, I am pretty sure already that the return connections need to be sorted into time buckets as well because otherwise the connection culling might be too strict for inbounds.

6

Forgot to respond to this: I considered it, but even if I stored the booking requests for the returns, there would be no guarantees that the connections of the same carrier would be booked in the inbound direction. Or that they would even be available…same as with actual return distribution. So it would still look like unbalanced inbound and outbound traffic.

7

No, not at this time, as they would go against what this change is trying to achieve. Not ruling out that one-way requests might be added in the future, but even if that was the case, I’d assume those requests would be relatively rare. Nothing to build a business on, anyway :slight_smile:

So just to come back on this one - I do think single journeys is the most realistic basis to build the system on?

I personally never book with preference to the same carrier. If I’m going to Barcelona, I have no bias towards Ryanair both ways, if Wizz/Vueling/Easyjet/Iberia fly at better times or prices coming back. Skyscanner is so widely used now. Surely to reflect this in game, at least on markets like the EU, is far more realistic?

The only real cases where people return with the same carrier tend to be long haul, but even then, that usually operates within a codeshare framework and doesn’t imply the same carrier both ways.

I just feel this change quite fundamentally flips the booking system to something unrealistic and less engaging/easy to work with than what was before.

I’m really concerned about the ORS though. I trawled through 17 pages last night looking at NCL-VLC and it appeared to have culled most connections apart from those operated by VZ and 4U - the (really) big players in this game world, who hardly need the help. Mine fall out entirely because they operate across TS/TV, despite having much better overall times than options further along the list and being an example where this should work in both directions (but my model was set up precisely because my subsidiary can form a key part of the structure, or could until now).

Finally, it sounds as though the changes tip the game far more towards a point to point model?

Since there currently isn’t a maximum stay and passenger types don’t have a preference for a particular stay duration yet, a single daily flight/connection should suffice for a return booking. That’s in principle, of course. Concrete circumstances might make it more difficult (like on very competitive markets with loads of connections).

But this, again, changes the game completely. Infrequent connections to smaller airports now don’t make sense, especially to the 2/3 bar destinations that only really warrant 2 or 3 flights per week. It also fundamentally disrupts a lot of airlines models (eg: my waves, where in one direction your connection time will be minimal, in the other you’ll have 16+ hours at BRU - the structure was never designed for return bookings in the first place). I’ll be far from the only airline affected by this I’m sure.

8

Two things:

  1. The word “personally”: This generally means “anecdotal”, and more specifically in regards to AirlineSim community members, I wouldn’t assume this to be the “standard” in the real world. For example, I, personally, have never in my life booked a trip with two different carriers :wink:
  2. “realistic” yes, but the issue with “self-connecting” for AirlineSim lies in performance. If I allowed virtual pax to self-connect, this would mean that any and all potential connections would be possible. That would be billions and as such technically unfeasible. It might be a bit less of an issue for outbound-inbound pairings and as said, this might be something that’s going to be relaxed in the future and/or be allowed via Fares.

Hence my mention of codeshare in my previous response :slight_smile:

But other features play into this as well, of course, like the aforementioned Fares, which could in theory allow segments plated by an interlining partner.

As stated on the preview thread, the current ORS UI is not up to the task, especially because it strictly goes by Neutral Display Order with at most 500 connections, so anything beyond those 500 is culled. When traffic is actually distributed, the system is a lot less strict, as it works with “time buckets” to give later connections a chance. But I am not denying that large carriers with all flights under the same airline have an advantage right now.

The mainline-feeder model is indeed at a disadvantage right now. In reality, those feeder would fly under mainline codes (for the exact same reasons as it’s now the case in AS). In a new game world, one could take this into account from the get go. Not in Paine, unfortunately.

I’ll have to think about this one. But can’t think of a good solution atm.

yes…but Paine :sweat_smile:

9

I mean, personally plus all my friends and family. Everyone uses skyscanner because it presents the best options and these are almost always different carriers, except perhaps for package holidays/long haul. In these cases, they generally appeal because of a lower return fare compared to teo singles - but this isn’t the model ULCs and even most legacy carriers use anymore. If you’re flying intra-europe and you always use the same carrier - give skyscaner a try (you’ll save time and money)!

I think you somewhat miss my point, though ITRs as was, perfectly reflect this behaviour and are, in essence, someone using skyscanner as they act as a different customer at either end of the route. If we want to introduce competitive return fares, this should be something done via fares.

I really felt ITRs we’re about hitting the nail on the head before and in trying to crack one minor problem that only existed for some users, its fundamentally shifted the game to somewhere that is a lot less realistic.

Are we saying this model is sticking as is? I understand its Paine, I know what I signed up for, but if so my 92% LF model will now struggle and I need to make changes - which is fine, it gives me something to do.

10

I mean, I don’t fly much to begin with, so maybe I am not the best reference here. But that’s sort of the point, no? :smiley:

Anyway, as said, I am fairly certain I’ll re-introduce the ability to have different carriers in a return connection with Fares, the latest. Then, this will be an explicit choice players can make:

  1. Offer one-way fares, risking that bookings might be unbalanced but capturing bookings that I might not get at all otherwise.
  2. Offer two-way fares that might capture more revenue and are more balanced, but might miss bookings due to connection times/stay durations.
  3. Why not both?

And different pax types might have different preferences for either, just as in the real world.

11

I just think this really limits the game. I know to an end user you’re only playing the game, but the previous single journey ITR version reflected reality well. Things aren’t balanced - I have a few friends (well, and my partner) who are/used to be crew - unbalanced loads are a very real fact of airline life. I was talking to one friend who was flying LHR-SEA last week. Outbound was full, return less than 50% full.

This reflects people’s differing itineraries much better - some people will be doing multi-city breaks, some people on cruises (so won’t return from the same airport), some people will be students or workers travelling one way and staying for weeks/months on end. There will be some people making a return journey between the same airport pair, but to my mind these pax should be captured via offering return fares (and an according tweak to the booking system) not by changing all booking behaviour to force all pax in the game world to behave as returners.

The previous model seemed to reflect real world behaviour much more accurately. This new one forces every carrier to behave as if it were offering package holidays.

12

I am aware of all of this. But again, your examples are anecdotal: Of course there are going to be “full inbounds and empty outbounds” in reality. But in the greater scheme of things, traffic balances out. In AirlineSim, due to the limitations of the simulation (like the 3 day booking window), an imbalance between inbound and outbound would be the equivalent of a real-world route that people only ever fly in one direction. Not something that’s all that common, I think :smiley:

That said, the “older brother” of yesterday’s change is on the roadmap for a reason: Return flight bookings. It should be able to capture many if not all of the scenarios you mentioned…it’s just no minor engineering challenge and will require more tooling for players (because you can’t just book two weeks worth of flights into the system and hope for the best, without any means to change prices etc.).

13

Yes, i agree it balances out, but it balances out by differing groups of passengers making booking for different reasons (and, in real world, may well balance out over months) - not because you’re forcing every pax to return with the same carrier. In essence, this moves away from pax looking at your product/sests/on board service to make a connection and simply drives passengers towards whatever airline offers the best schedule (in both directions) between two points - fine for point to point models but terrible for hub and spoke unless all your routes perfectly balance.

As I say, despite not actually offering the same connections for final start/end points at BRU in both directions, my flights were broadly speaking full. My suspicion would be a lot of those carriers experiencing an extreme imbalance were not offering good connections both ways.

I appreciate lots of work has likely gone into this change but its changing behaviour away from a real world market and making it much more restrictive. I can see benefits (such as making direct flights more popular), but these feel like changes that could have been made whilst maintaining the old booking behaviour (which is far more realistic/diverse and far more inclusive of different types of traveller - surely the whole reason ITRs exist in the first place?).

14

I agree with your general assessment: In principle, the previous ITR behavior was more diverse and the goal should be to maintain/bring back more nuances to how connections are booked. For the sake of AirlineSim, I think it’s a reasonable assumption that the vast majority of trips are return trips in one way or another. But I agree that this doesn’t necessarily have to imply return bookings as it’s the case with the new return traffic distribution at the moment.

But again, this is a first stab. I need to monitor how the new system behaves both in terms of booking behavior and server load. Based on that, I can decide how much wiggle-room there is for further experiments. It’s just that today, I don’t feel ready to open up the possibility of arbitrary return connections for various reasons.

That said, this is where I actually see an issue:

Emphasis is mine. This is what I meant earlier on the thread: It just feels too easy, no? A network carrier just so “happens”. No elaborate planning required and the cost basis is pretty much the same as for any other airline in the game. There’s a lot more work to be done here imo…hence the length of the roadmap :sob:.

15

Honestly, it might do for some people, but my model has been seriously thought out. I essentially have 8 hour waves which feed from A (northern Europe), to B (Southern Europe) to C (Eastern Europe) via BRU. With time I’m hoping to balance that. TS fits into this model by providing the feeder routes to the smaller airports, but I can’t balance my waves (I’ve started on this by trying to create a pattern in the reverse direction), until I’ve got lots of money in the bank and a huge fleet. In the meantime, I attempt to acheive this by carefully selecting interlining parteners who can balance my waves. This change kinda makes my model null and void (especially as I was pretty heavily reliant on connections). I see some other carriers who seem to just do point to point until theres so many point to point routes that they form connections, but I feel a bit offended that you may imply my model has randomly happened (FAR, FAR from it!) :wink:

But aside from the gameplay side, I guess we’re in agreement. I assume the verdict is this is sticking, so outcome… I best get retiming.

My only real bug bear is that, for a little while, the seriously huge competitors will continue to grow because they’re sucking up all the demand, and I feel changes should be to make life more challenging as you get bigger, make the game more difficult as you gain more experience, not just easier and easier.

If I could ask for one change, could you make it so that subsidiaries can act as part of the overall airline, rather than just a generic interlining partner? I’m sure I won’t be the only one seeing quite a big upset to my model as a result of this change.

1 Like
16

I had opened another post before I actually found that post…

I have checked some of my bookings and connections. Its true, that for many many of my connections I cant find an entry in the ORS anymore.

While I can understood this for travels, where no return connection exists at all I would like to (beg, ask) to consider the following change. Dont make a booking dependend on an (1) airline for both trips.

Ingame I offer some connections e.g. Sharm el Sheik or MPL to La Guardia. But as it is a weekly flight and for other reasons there is no return. I would like to see - when demand calculation is done. Lets say for Sharm el Sheik that it is taking all possible inbounds and then all possible outbounds and combines those. This might enable a passenger to use a company A (+ maybe interlining partners) towards his destination and use company B backwards. Yes it may increase the possible combinations (maybe you could cut them by duration or total costs) but it would give the demand calculation a chance to weight travel legs, total travel time, company loyalty and also costs.

Let me give you an example. From Antananarivo to Montpellier on 25.7. the ORS will give you a total time of: 17h 56 Minutes in 3 legs at 1.377 cash for business. I offer a connection that lasts only 13h and 8 minutes with 2 legs at (let me do the numbers) 1.565 cash. If that connection would be considered the customer could choose a faster connection (maybe with better service and seats) towards his goal and would still reach back with one of the other companies ? If only one company is considered this will result in me probably shrinking a lot of connections as there would be simply no demand at all.

1 Like
17

My thoughts are that this needs putting back to the old system and thinking through again. It’s problematic in so many ways and creates a whole minefield of complexity when it comes to schedules - not least as it renders interlining close to useless (unless you and your partners flights align perfectly in both directions).

There’s so many more unintended consequences but I think we’ve highlighted a good few of them. I’d love more complexity on the scheduling side - something like crew rostering would be brilliant - but this change seems to only have negative consequences. If return fares are wanted, I feel this would be better as something acheived through fares.

Feature Preview: Distribution System / Individual Travel Requests
18

Thanks a lot for your input everyone. After thinking about it, I decided to lift the plating carrier restriction for now. Mostly because I don’t want to wreak too much havoc on Paine at this time :sweat_smile:. I just hope the server can cope, because this will blow up the available options tremendously.

Obviously, I underestimated the impact of the current connection structure people have built and the 3-day booking window constraints.

There’s also another thing that came to my mind (at a camp fire) last night. There are several trip and booking combos that should probably be modelled:

  • Return trip and individual booking: The primary example given in the thread above of people just booking different carriers on outbound and inbound because they don’t need/want a single ticket.
  • Return trip and return booking: Probably the most common option for most long-haul and holiday trips where both segments are on a single ticket.
  • One-way trip/booking: Probably somewhat common in reality but likely evens out in the greater scheme of things. BUT one area where this is almost certainly the norm is…cargo. The implications here go beyond my current experiment because this would also affect how demand is modelled (for returns, I can cut it in half, for one-ways I can’t, but at the moment it’s one or the other for all traffic).

These feel like they should/will just be merely another attribute of the different customer types, so they have the probability, preference and ability to pick either option.

That said, I generally stand by my assessments throughout the previous posts: If the goal is to model reality, it should almost certainly be harder and much more costly to offer connections. I mean…the divide is right in the name, it’s “network carrier vs. low-cost carrier”. The cases you described where there’s a connection in one direction but not in another…that’s exactly the sort of thing that makes offering connections expensive in reality. Because one needs the wave structure to make it work and that typically means very inefficient schedules with lots of downtime for the fleet. Offering too much capacity to destinations that might not warrant it on their own etc.

Of course there need to be more tools. Codeshare and Fares are just two things already mentioned. But I feel there should be a distinction between different business models. And that we can’t assume every passenger is the all-knowing avgeek who can do without travel agent :wink:

EDIT: Forgot to mention it - as the 3-day booking window is much more of an issue than I originally expected, my gut tells me that explorations in that direction would be worthwhile. Either by moving ahead with “proper” return bookings and a (much) longer booking window (which would hinge on other features being available, as discussed), or by trying to “slightly” expand the 3 days to, say, 4 or 5 days. Gotta think about that.

19

Hi Martin,

Thanks very much for taking the feedback onboard. It’s really appreciated and I’m makes the game what it is!

Just a thought on something you said there - this may well feed into ITR passenger groups - but the people (often me!) who book different carriers each way are generally those who are budget conscious and searching for the rock bottom bargain, or those who must travel at a certain time (to be fair, also me on my last trip). Maybe it’s something that could be built into each ITR customer type? :slight_smile:

Thanks for your feedback though, you’ll be happy to hear I spent 5 hours (and got half way toward) rewriting my subsidiaries schedule yesterday so everything does balance in either direction (even down to exact capacity as I figured that probably makes more sense for return bookings) - for sure no small task! If/when this does come back in part/all, it gives everyone time to be in a better position for it.

Thanks again!

Edit: one final thought that crossed my mind on ITR pax types - could we maybe have a very small, decimal point % of avgeeks? So for those airline who fly interesting/older/noisier types have a very very small but not none existent market?

Second edit: Just a thought about what I was saying earlier on 1 way connections - they’re not one way, it just incurs a connection beyond the game-preferred 3 hours. Perhaps loosening this requirement would help as in plenty of real life cases, 4 hour or so transfers (especially long haul) aren’t too rare?

20

The biggest issue for me with this feature is the 3-day booking window. Essentially, this makes all route schedules with less than 4 flights per week useless. Guess what low-cost carriers often do - they schedule less than 4 flights per week. So this feature actually benefits the network airlines because they offer more flights. Allowing the return flight to be with another airline does not solve this issue because my aircrafts offer a far bigger business class than my competitors do.

I understand that you want to test this feature on Paine. Take your time. But my recommendation is to roll it back eventually. I can’t even change my flight schedule because there aren’t enough slots left at my home base in Dusseldorf, Frankfurt and Munich.

1 Like