Connecting Flight Prices and a More Realistic Game

Hello Sedna, nice to see you again :slight_smile: I hope you are still doing well.
I find your valuable perspective interesting and I thank you for your contribution.

I don’t disagree with what you are saying, as with Sam. However I still stand by the skepticism in which this will be implemented to the AS system as is.

The problems with adding LCCs as I see them:

  • How do you have a computer calculate who buys a snack/drink/whatever? Do we set a fixed ratio, probability, etc? If someone is flying on a connecting one, how does one determine what segment the person buys a snack in - and therefore gives the ancillary to?

  • AS is based on fixed demands, and creation of demands on basic premises (eg cheap fares to the beach, even if that beach is the unknown Tivat, but someone prefers to go for 10$ to Tivat vs paying $100 for something like Antalya?) - how does the computer calculate the value of destinations. The game runs on fixed pairs - eg, X # of pax want to go from STR to AYT - not unfortunately X number of pax want a beach holiday starting in STR.

  • This would also have to sort demand and passengers into buckets - not just the basic demographic but also intent of journey and what they value. I’ve talked about this here but essentially sorting demand into certain intents - my basic idea was Leisure/VFR/Work but there are more types and more should be included - for example someone going to hitchhike in Tasmania will not value the same as the family going to Hawaii - but they’d both be “leisure” pax.
    (edit) This dilemma is also discussed from 10:35 onward here
    As demand is acquired in raw numbers (which I can prove as someone who has delved into these demand pools) on the pure OD it is impossible to sample what the intent is though. So the passenger then has to have one set of priorities to correspond with the congruency of the passenger base.
    If someone was heading from Houston IAH to San Francisco for a meeting in Downtown or someone wanting to do tourism in the Bay Area, they are both listed in data as IAH > SFO pax - and to get such data from the real world would prove impossible as in most cases it isn’t sampled (esp domestic), and in the ones that possibly could (Intent of travel, as in customs) - then I doubt any government security agency would be willing to give this data to AS much less the almost 200 members of IATA/ICAO’s security agencies. So that makes it hard. We can make generalizations (such as most pax going to AYT are tourists) but as seen above cases like NYC and SFO are more ambiguous to distinguish.
    Therefore if we only are allowed to have one congruent demand set we must settle for one set of satisfaction criteria. Hence why the ORS is weighted the way it is.

  • I think if we want to get apocalyptic, most of this industry as it is today is going to eventually die or transform. So such argument is hard to quantify

  • Additionally most demand sets would not be “normal” for a few years - even “recovered” countries have changed demand patterns such as a massive increase of demand to Bozeman in the USA and half of the SFO demand. So to predict post-pandemic things we must wait until we either accept the Post dataset as abridged from 2019 or stick with the Pre set until something happens…

  • Pilot workloads and stuff would require a major expansion of the role of the staff, and I personally believe that this should not be where our precious daily cents should be going toward…

  • The loyalty of manufacturer is something I believe is a realistic ask as the implementations for discounts in bulk are already in place in existing codebase. And something I support.

  • We don’t deal really with the function of the terminal - and to the core purpose of the game, this would only really be seen as a boost hidden somewhere in the ORS - sure, a nice thing to implement, but hardly a priority (impo)… unless AirportSim has any plans of making a comeback integrated into AS… (Martin? :rofl:)

  • Baggage - we’d have to mess with predetermined weights of pax to allow for baggage variations - might complicate calculations of MTOW and by proxy reduce capacities or invalidate some flights…

  • As someone who knows what it’s like to serve barren airports here, and knows people who have served arguably worse, “government assistance” would be a miracle to some little tracks…
    An idea: Maybe an Airlinesim Global Development fund is a branch of the AS Bank that offers bonds / payments / discounts based on conditional of serving select airports with X weekly flights - maybe these routes rotates randomly (to not have simulogics have to manually implement this) between certain one and two bar airports per year/6mo/3mo, to incentivize constant new routes… maybe “New bonus for serving (1-bar”)" and this would be advertised on some panel in the Dashboard.
    The selection of the spokes would pool the 1-2 bar airports per continent, and randomly draw only those airports without any Stations (as I imagine it will be easier for the machine to tell than flights actually operating). So it is truly a route with no service, vs a route that is already served and can be viably served without subsidy. And the payment would keep going for 1 or maybe 2 or 3 of the cycles until it is announced that it will stop, then the CEO has to decide whether it can maybe stand on its own (as connection links and such will be done) or not. Airports should have a “cooldown” so they arent selected too close to each other - maybe 4-5 cycles after. And the idea is 3-5 per continent running at a time.
    Of course, this is best paired with an expansion of the FI list to be able to serve more airports, for example if there is one in Bolivia but there is no airline with Bolivian rights, right now that would go unclaimed…
    The payments would probably be doled out with the weekly closing of the airline, as some sort of ‘refund’ on that cost - as that is the way I see it implemented most naturally, though it could also be added like a leasing income at any time into the airline’s timeline
    Payments would follow a full week (measurement is TBD, I propose either a fixed time like Mon0000U or the closing time) of continuous non-cancelled service…

I think that is it for now - but I’ve left you some plenty of ideas to ponder…