The title of this issue is pretty much what I did last week: I added rating components to the individual travel request generator 
Okay, yes, there’s a little bit more to it. As described before, each travel request is comprised of an individual set of preferences and aversions. Example: One passenger might value the quality of seats much more than another. Think “budget vacationer vs. movie star”.
The rating system as such is a part of the Distribution System, and large parts of that have already been implemented last year (see dev logs starting around 2024-27, I think). But since a lot of the respective code was originally written for the AS Technology Demonstrator project, and the ASTD never had any service or product settings of any kind, the only rating components that existed so far were about the basic connection quality (like travel duration, amount of stops etc.). Consequently, I started to get (almost) all the components implemented that AS currently supports:
- Seats
- On-board service
- Passenger terminals
- Dedicated freighter (for cargo)
The only one I didn’t manage to finish was image.
While adding these is mostly busy-work, the challenge comes from the fact that the current rating system pre-computes the ratings per service class and than just uses those pre-computed values when rating connections. Due to the individual nature of travel requests, this doesn’t work anymore. So all the inputs for the rating components have to be made available during demand distribution, which is a bit cumbersome due to fact that the respective code is highly optimised and as such might not the most…uhm…“ergonomic”.
On top of the mere rating components, I also added a “distance factor” for some of them. Take my example from above: Even a movie star flying First Class will care less about seats on a 300km short-haul flight than on a trip from LAX to LHR. And the other way around, the ground travel component of a connection becomes less and less relevant with increasing travel distance.
Last but not least, I added a crucial aspect of Individual Travel Requests that’s neither a preference nor an aversion: Each request will have an individual maximum budget. A connection that’s more expensive than that is out by definition, no matter how good the overall product might be or whether there are alternatives or not. In the long run, this is supposed to model the supposed “LCC effect”, namely that (U)LLCs “generate their demand” by offering such low prices that previously untapped market segments open up.
And with that, the crucial parts of “Individual Travel Request Generation” are mostly done now, so among other things, week 12 will be about how to get this new feature into large-scale testing and - eventually - released. So stay tuned (and don’t forget to leave your comments on Dev Log Week 2025-10 if you haven’t done so yet)!
