Paine is the first game world to offer a very early preview of the Distribution System in general and Individual Travel Requests in particular. Please note that when I say “Distribution System”, I actually mean a hybrid between the existing ORS and several features of the “full DS”.
In this post, I want to document the current state of development, near-term plans, known issues and anything else one should be aware of when playing with this preview.
State of development
As of 2025-09-12
- DS integrated as a “drop-in replacement” for the ORS (everything looks almost identical from the outside atm)
- Connection search works exactly as it has done before
- Inventories/booking classes are mocked based on existing 3(+1) service classes for pax and cargo
- Fares only exist as a facade and work exactly as they did with the ORS (total fare = sum of individual segment prices)
- Travel requests are generated in bulk per destination once a day when the ORS has computed all possible connections for a destination (destinations and their demand are de facto static as before)
- Itineraries are built from physical connections, inventories and fares as they will be once the DS is fully implemented.
- For each travel request, a selection of itineraries based on the requests filter criteria is generated and rated (also as per the individual request’s rating criteria). Then the best match is booked.
- At the moment there are 4 hard-coded passenger types and one cargo type.
- Each passenger type has certain weight ranges for each rating criterion. When individual travel requests are generated, individual weights are rolled within each criterion’s range (so no two travel requests are exactly the same).
- Implemented filter criteria:
- maximum budget
- booking size (aka “amount of pax”)
- accepted service class(es)
- Implemented rating criteria:
- Stop aversion
- Travel time aversion
- Ground travel aversion
- Price sensitivity
- Seat quality sensitivity
- Service sensitivity
- Terminal sensitivity
- Dedicated freighter sensitivity (cargo only)
- Image sensitivity
- Ratings have been removed from ORS results as they wouldn’t represent how flights are actually rated. Results are shown in “neutral display order” instead.
As of 2025-09-16
- Travel requests have a preferred arrival time. Connections arriving closer to the preferred arrival time score better.
- Travel requests feature arrival time tolerance. Connections falling outside of a time window around the preferred arrival time are ignored.
As of 2025-09-18
- Customer types are now loaded from data files rather than defined statically in code, allowing easier customisation.
- New customer types have been added. There now are
- 4 Economy types: budget, regular, VFR, comfort (will also book affordable business)
- 4 Business types: smart (lower budget, will also fly eco), regular, urgent (will book any class, think tech specialist that needs to be at a site tonight no matter the cost), executive (will also book First)
- 1 First type (as before)
- 4 Cargo types (economy, regular, express, urgent)
As of 2025-10-16
- Each travel request in logged with bookings statistics. This is (for now) an internal feature to allow analysing booking behavior for the purpose of optimising and fine-tuning the DS. More details on the devlog for week 42.
As of 2025-11-11
- Added more values to (internal) booking request logging to help with the analysis of budget limits and the effects of multi-segment connections on booking behavior.
- Spotted and fixed a bug in customer type data, leading to regular economy passengers often having very low or even negative maximum budgets.
As of 2025-11-25
- Adjusted connection culling such that itineraries are generated for travel requests with late arrival times even if there are many direct connections early in the booking window.
As of 2026-01-13
- Increased budget bounds for most “non-budget” customer types so they will typically accept total prices at or above the the standard price for the direct connection.
- Reduced probabilities of large booking request sizes (>10 pax or cargo units) to zero for most customer types.
As of 2026-02-04
- Flight rating overviews show product factors on a relative scale between the theoretical minimum and maximum values for the respective factor. This is because the actual (absolute) rating is only computed whenever a connection is rated in the context of a specific travel request and actual market conditions. Price has been removed from the list of product factors as prices will eventually be set using Fares rather than directly on flight segments/airport pairs.
- Service profiles and cabin configurations show the same relative rating for all distances (see above for reasoning behind this).
As of 2026-02-11
- Support for distance-based probabilities of customer types.
- Budget customer types that focus primarily on price (both pax and cargo) now phase out over longer distances.
- Adjustments to travel request size rolling which should alleviate some of the booking fluctuations on thing routes.
As of 2026-06-30
- Budget caps of budget eco/cargo customer types have been increased slightly.
- Price sensitivity across economy customer types has been decreased slightly.
- Arrival time tolerances of urgent business types have been increased slightly.
As of 2026-07-23
- New DS implementation with a pathfinding engine taken (in large parts) from the AS Technology Demonstrator.
- Return Traffic Distribution:
- When traffic is distributed for a given origin, it is distributed in the return direction at the same time.
- Return itineraries are generated based on outbound and inbound connections, then rated as before.
- Because of this, traffic is cut in half (outbound + inbound bookings = original demand)
- Plating carriers (currently defined as the carrier operating the longest leg) of the inbound and outbound segments of an itinerary need to be identical.
- Since ground networks have to be symmetric, the algorithm to generate them has been simplified, resulting in (typically) smaller networks. To be reviewed.
As of 2026-07-24
- When connections are generated for distribution, inbound connections are now sorted into buckets by departure time, similar to how outbounds are sorted into buckets by arrival times. This way, connections departing late don’t get culled, leading to many late outbounds ending up without a matching inbound. Previously, outbound and inbound connection counts were quite out of balance, stats since the change look like they are a lot closer now.
- Arrival time limits for inbound flight have been lifted, so a return flight doesn’t get ignored just because it arrives after the 72h flight instancing window.
As of 2026-07-25
- Lifted the rule that the plating carrier of outbound and inbound segments have to match.
- Fixed that bookings on the outbound segment were tracked as incoming transfers on the inbound segment.
As of 2026-07-29
- Fixed a bug causing the pathfinder to generate connections with “loops”
- The minimum stay for returns has been reduced from 3h to 0.5h to enable more return connections, especially on long-haul
Upcoming enhancements/changes
These are focused on Individual Travel Requests for now. All other parts of the fully built-out DS will follow in due time.
- Reworked ORS/DS search UI that offers more filter and sorting options.
- Experimental/speculative: Actually log travel requests and/or bookings for better analysis, at least internally but possible for players as well.
Dynamic passenger types loaded through our regular data pipeline (just like airports and aircraft, for example).Additional passenger and cargo types.Rework how flight ratings are displayed for flight numbers, flights, service profiles etc.- More rating and filter criteria for passenger/cargo types, within the means of what the current state of the simulation allows (as in: without work on other features on the roadmap).
- Varying passenger type distributions based on day of the week.
Varying passenger type distributions based on trip distance (fewer/no low-cost pax on long-distance flights)- Rating criterion for stay duration between outbound and inbound segment.
- Hard minimum/maximum stay limits for some passenger types (TBD)
- Possibly an experimental extension of the flight booking window from the current 3 days to anything between 4 and 7 (TBD)
Known Issues/Limitations
Traffic rights currently aren’t respected (will be fixed asap)- Passengers only book connections that offer the same service class on all legs (current ORS will allow lower service classes on single legs). Will likely only be addressed once fares are fleshed out.
As booking requests are a lot more random, there might be more noticeable imbalances between inbound and outbound connections until I have come up with a solution to address this.- While a new DS search UI is both on the list of enhancements (see above) and the roadmap, the current one is really not made for return itineraries. They render, but both display and search options don’t do the DS with return connections justice.
Things to look out for
Current passenger type definitions arestatic, few anda first attempt “off the drawing board”. Don’t overrate current booking behavior.- Current Economy passengers tend to be very price sensitive. Flights at standard prices will price out a sizeable share of the market as passengers have a hard cap on their budget and will filter out connection completely that exceed it.
Product ratings displayed for flight numbers, service profiles, cabin configurations etc. are misleading as these are not actually rated this way anymore. Example: A given service profile has not “positive” or “negative” rating per se, especially not dependent on distance. Service quality will rather be rated according to market situation and individual passenger preference.- Return Traffic Distribution is highly experimental and - like the rest of ITRs before - is subject to on-going tuning before it is deemed production-ready.