Frequency Bonus - Gone Mad?

[Curse]

I agree - this would make a lot of sense. But perhaps it could be scaled so that the number of flights before you stopped seeing the benefit varied depending on distance. After all IRL people are usually far more fussed about frequency for a short (commuter) flight than for an ultra long haul one where they'll already be spending the best part of a day on the aeroplane. You could make it so that say:
< 300nm - frequency benefit disappears after 5 flights per day
300 - 600nm - after 4 flights
600 - 1200nm - after 3 flights
1200 - 2400nm - after 2 flights
2400 + nm no frequency benefit provided the route is flown every day.

The best request I read since I'm back here... maybe you want to create a feature request thread in the freature request forums about it?

[Jona L.]

I agree - this would make a lot of sense. But perhaps it could be scaled so that the number of flights before you stopped seeing the benefit varied depending on distance. After all IRL people are usually far more fussed about frequency for a short (commuter) flight than for an ultra long haul one where they'll already be spending the best part of a day on the aeroplane. You could make it so that say:
< 300nm - frequency benefit disappears after 5 flights per day
300 - 600nm - after 4 flights
600 - 1200nm - after 3 flights
1200 - 2400nm - after 2 flights
2400 + nm no frequency benefit provided the route is flown every day.

Definitely + 1 million votes on that

[GEnx]

I agree - this would make a lot of sense. But perhaps it could be scaled so that the number of flights before you stopped seeing the benefit varied depending on distance. After all IRL people are usually far more fussed about frequency for a short (commuter) flight than for an ultra long haul one where they'll already be spending the best part of a day on the aeroplane. You could make it so that say:
< 300nm - frequency benefit disappears after 5 flights per day
300 - 600nm - after 4 flights
600 - 1200nm - after 3 flights
1200 - 2400nm - after 2 flights
2400 + nm no frequency benefit provided the route is flown every day.

+1 from me as well.

[alexgv1]

Amazing words

+1million too

Is your alter ego called Chuck Norris?

I think this is a complete request ready to be programmed into the game and doesn't even need any alterations.

[Powi]

If possible some kind of logarithmic decrease of frequency bonus would be better than on/off at a specific point. Otherwise a good call.

[alexgv1]

If possible some kind of logarithmic decrease of frequency bonus would be better than on/off at a specific point. Otherwise a good call.

Quite hard to have a logarithmic scale on something like daily flights as it is a finite number (i.e. You can't have 4.65 daily flights).

[flightsimer]

I agree - this would make a lot of sense. But perhaps it could be scaled so that the number of flights before you stopped seeing the benefit varied depending on distance. After all IRL people are usually far more fussed about frequency for a short (commuter) flight than for an ultra long haul one where they'll already be spending the best part of a day on the aeroplane. You could make it so that say:
< 300nm - frequency benefit disappears after 5 flights per day
300 - 600nm - after 4 flights
600 - 1200nm - after 3 flights
1200 - 2400nm - after 2 flights
2400 + nm no frequency benefit provided the route is flown every day.

good but will need to add in a multiplier for each region of the world or size of the two cities. For example in the US, its all about Freqs especially between the big cities. I mean NYC-Philly has 19 daily flights from USAIR alone between philly and LGA because of the pure amount of business travelers between the two.

[slither360]

In my opinion, frequency limit (assuming we're keeping one, which I would think since it would be too much work to program otherwise for now) should be demand/75+2 frequencies

So for example, Dubai to Bahrain has a demand of ~2300 daily. So the frequency limit would be 33.
Compared to Dubai to Sanaa, which has a demand of ~890 daily. So the frequency limit would be 14.

[JumboShrimp]

I agree - this would make a lot of sense. But perhaps it could be scaled so that the number of flights before you stopped seeing the benefit varied depending on distance. After all IRL people are usually far more fussed about frequency for a short (commuter) flight than for an ultra long haul one where they'll already be spending the best part of a day on the aeroplane. You could make it so that say:
< 300nm - frequency benefit disappears after 5 flights per day
300 - 600nm - after 4 flights
600 - 1200nm - after 3 flights
1200 - 2400nm - after 2 flights
2400 + nm no frequency benefit provided the route is flown every day.

+1

[swiftus27]

+1

Frequency wins because the math involved with this game is so simple.

Now, discounting CI/RI/Alliance, the game simply divides the number of passengers by the number of flights (except some pluses/minuses for flight time and comfort).     So, if there are 1000 people wanting to fly a 300nm route, having 20 F27s against 7 722s means that the F27 user gets ~20/27th of the total number of pax flown that day.  That is GREAT for that plane but if the prices were the same, I bet many of us would personally opt for the jet.

[alexgv1]

In my opinion, frequency limit (assuming we're keeping one, which I would think since it would be too much work to program otherwise for now) should be demand/75+2 frequencies

So for example, Dubai to Bahrain has a demand of ~2300 daily. So the frequency limit would be 33.
Compared to Dubai to Sanaa, which has a demand of ~890 daily. So the frequency limit would be 14.

No offense Bob but this seems like an empirical rule with these figures off the top of your head. Is there any reason to use there numbers? Or is there science behind this? Too many people try and complicate AWS with mathematical rules which they do not understand and do not actually model what happens in the real world (if that is the desired result).

You will learn as an engineer, the Romans used empirical rules, but now we are more sophisticated and cannot rely on such rules of hand.

[EYguy]

I agree with Alex. The demand model and how the pax accept the offer is still a point of debat even in real life, so I wouldn't be so impatient to say it is right.

What Curse wrote is correct but I would also consider the time in flight as a variable: if I fly a 500nm route with a turboprop or with a jet it makes a HUGE difference, bot in terms of CI and pax reference. In this case is not only a matter of frequency, but it turns out to be something more "image oriented".

Bob, every math formula we use (and I'm usually against formulas because I want a demonstration first. And even after I'm never 100% sure, ehehe!) must be checked out against reality. If you can prove that what you proposed is actually used by at least one major carrier, we'll be more than happy to alk about it. Otherwise we go back again to the topic about cost commonality, where I talk about a way to understand how much I'm going to pay for my next airframe in fleet and someone talks about formulas...

[Sigma]

Bob, every math formula we use (and I'm usually against formulas because I want a demonstration first. And even after I'm never 100% sure, ehehe!) must be checked out against reality. If you can prove that what you proposed is actually used by at least one major carrier, we'll be more than happy to alk about it. Otherwise we go back again to the topic about cost commonality, where I talk about a way to understand how much I'm going to pay for my next airframe in fleet and someone talks about formulas...

There's an old adage that would apply here:

"Perfection is the enemy of the good."

Just because you can't do something exactly right, doesn't mean you shouldn't try to make iterative steps in the right direction.  Hell, it might not even be the right direction at all, but when you are seeing behavior you don't expect or want to see, then you have to do something to move it in the direction you want it to.  You can't sit around waiting for the perfect solution to the problem -- because by time that comes around the whole thing has collapsed on itself.

AWS is not reality.  And it never, ever will be.  Even the most comprehensive simulations in the world run by the most sophisticated supercomputers in the world cannot mimic reality completely and use abstract datasets and/or algorithms to approximate expected behavior.  And sometimes you're not even trying to realize some method directly, but rather implementing components into the simulation to ultimately achieve the desired result regardless of whether the means are "realistic"/exact or not.  And what I mean by that is that, one often times doesn't worry about the minutiae or ensuring your simulation hires the exact number of people for the exact roles, but rather than your simulation allocates as much for payroll expenses as one expects, without any concern for what job these virtual employees were hired to do.  It depends on what the level of simulation one was expecting to achieve (financial models versus hiring models have different ultimate goals with different levels of granularity required).

AWS is based almost entirely on this level of data abstraction, which is why, for example, you hire employees you wouldn't expect to hire by doing a particular action and/or too many of them, simply because the model says your costs should increase by $Xm, and it had to be illustrated somehow, so it simply divides them out into your personnel, regardless of whether it exactly makes sense or not, and certainly isn't based on reality.

Since AWS is not reality, one cannot expect what works in reality to necessarily be the solution to work here.  In fact, it's far more likely that it WON'T work.  So it is illogical to expect what any particular airline, or even every airline (if such a thing ever existed that would apply equally in reality), uses as solution/formula/whatever to actually work here and to use it as some sort of yardstick or criteria as to what can be a solution within AWS or not.

[LemonButt]

I'm going to go ahead and throw in my two cents: frequency's influence should be the maximum delta between flight times in a given week.  For example:

flight 1x/daily 6 days/week -- maximum 48 hours between departures
flight 1x/daily everyday -- maximum 24 hours between departures
flight 2x/daily everyday at 600 and 1800 -- maximum 12 hours between departures
flight 3x/daily everyday at 600, 1400, and 2200 -- maximum 8 hours between departures
flight 3x/daily everyday at 600, 700, and 800 -- maximum 22 hours between departures

In the real world, frequency matters only if the frequency is spread out.  The player with the least lowest maximum time between departures should be favored.  Virtual passengers would see the 3x/daily with 8 hours between departures as 3x daily where the 22 hours between departures is basically 1x daily split up to be flown by 3 planes.  The player who can maximize frequency through strategically planning departure times will get the biggest piece of the pie versus just scheduling 12 flights leaving every 5 minutes between 600-700 to max things out. </2cents>

[Curse]

Hey guys, keep the system simple. Something everybody can see without doing math etc.

And as long as the slot situation is f***ed up as it is at the moment please nothing that is time/day/etc. related

Glob-al made an absolutely simple and good working request. It's not necessary to destroy this with 'better' ideas or some discussions far away from this.


PS: If the basic systems like city based dynamic demand and dynamic slots etc. are done it's a maybe a good point to make this system more complicated, but at the moment with the current system it simply won't work out.

[flightsimer]

What Curse wrote is correct but I would also consider the time in flight as a variable: if I fly a 500nm route with a turboprop or with a jet it makes a HUGE difference, but in terms of CI and pax reference. In this case is not only a matter of frequency, but it turns out to be something more "image oriented".

Bob, every math formula we use (and I'm usually against formulas because I want a demonstration first. And even after I'm never 100% sure, ehehe!) must be checked out against reality. If you can prove that what you proposed is actually used by at least one major carrier, we'll be more than happy to talk about it. Otherwise we go back again to the topic about cost commonality, where I talk about a way to understand how much I'm going to pay for my next airframe in fleet and someone talks about formulas...

Well then there will never be a freq cap, because there is no freq cap in RW. So you cant check it against RW.

Like I said earlier, USair alone operates 19 nonstop flights a day between LGA and PHL. That's a whopping 83nm flight... you can't just limit the number and expect to be realistic because in reality there is no limit. If the airline is going to make money, then they are going to fly as many as they can.

Again, the better solution is this in my eyes

First class- 65% are freq conscience
Business class- 90% are freq conscience
economy class- 25% are freq conscience

A bigger shift needs to be made so that pax choose flights based on the airline. For example, I operate a route for over a year at max capacity with ATR's. flights were always 85% full. My competitor comes onto the route and uses slower MA-60's that have a poor seating config compared to my good seating and all my pax leave me?

There needs to be a loyalty bonus, because in real life, most likely, that would never happen. Plus passengers need to be more conscience of seating quality and flight time. I highly doubt anyone here would fly on a slower and more cramp aircraft for the same amount of money as a flight with a faster and comfortable aircraft.   

[flightsimer]

I'm going to go ahead and throw in my two cents: frequency's influence should be the maximum delta between flight times in a given week.  For example:

flight 1x/daily 6 days/week -- maximum 48 hours between departures
flight 1x/daily everyday -- maximum 24 hours between departures
flight 2x/daily everyday at 600 and 1800 -- maximum 12 hours between departures
flight 3x/daily everyday at 600, 1400, and 2200 -- maximum 8 hours between departures
flight 3x/daily everyday at 600, 700, and 800 -- maximum 22 hours between departures
In the real world, frequency matters only if the frequency is spread out.  The player with the least lowest maximum time between departures should be favored.  Virtual passengers would see the 3x/daily with 8 hours between departures as 3x daily where the 22 hours between departures is basically 1x daily split up to be flown by 3 planes.  The player who can maximize frequency through strategically planning departure times will get the biggest piece of the pie versus just scheduling 12 flights leaving every 5 minutes between 600-700 to max things out. </2cents>

i dont get where you are getting 22hrs from... whether the flight be being flown by the same aircraft or not doesnt matter, its still three daily flights. If an airline is going to fly say 3 daily flights, most of the time, due to scheduling, every flight will be operated by a different aircraft. There is only 1 case that i can think of where it would be the same aircraft every flight, which is if there is a subfleet specifically for that route or base.

[Curse]

Again, the better solution is this in my eyes

First class- 65% are freq conscience
Business class- 90% are freq conscience
economy class- 25% are freq conscience

There should be no difference between pax, because this would destroy the long-haul system. In real life people choose to fly long-haul (especially business and first class) about variables that are not included in AWS like connection etc.

Two A330-200 should get not boost on first/business class compared to one B747-400.

[EYguy]

No no no, wait... IRL airlines operate flights even if they're operated at loss just because they need those flights to reposition a/c from one apo to another one. Moreover, you forget that there's something called "hub and spoke" and the spoke are sometimes operated at loss in order to "feed" flight with way higher LF that will "subsidize" the flight operated at loss.

Operating flight at loss while occupying slots is something that here is often defined as "slot hogging" and it even makes sense because here we have no such thing as connecting demand, which would help us making the money that is usually earned by the carriers on those trunk routes fed by those shorter flights.

Sigma, you're right, but I just do not like formulas: they're not always easy to understand (i.e. my maths is average but I also care about those who have maths skills crappier than mine ) and you never know how do they come from. We have player John suggesting a certain formula, with user Peter is fan of another one... How do you know that they're right?
However, going back again to the commonality costs issue: I think that the merit of my proposal was of being totally "maths free" and user friendly, because we were talking about very simple maths (you're given figures per every a/c you buy, not some % or logratimic curves) that can be extrapolated quite easily.
Of course, as you wrote, we should always strive for perfection or at least go get close to it, but formulas are by definition approximation of reality

Regards

[Glob-Al]

Wow, I seem to have inadvertantly started quite a debate here! I realise my proposal was not perfect, but as someone else (sorry I forget who!) said above, it's straightforward and I would hope (although I know nothing about computer programming!) reasonably easy to code in.

Well then there will never be a freq cap, because there is no freq cap in RW. So you cant check it against RW.

Like I said earlier, USair alone operates 19 nonstop flights a day between LGA and PHL. That's a whopping 83nm flight... you can't just limit the number and expect to be realistic because in reality there is no limit. If the airline is going to make money, then they are going to fly as many as they can.

Again, the better solution is this in my eyes

First class- 65% are freq conscience
Business class- 90% are freq conscience
economy class- 25% are freq conscience

A cap would only be capping the benefit received, not actually capping the number of flights you could fly. So you could fly 19 flights a day, it's just that it wouldn't give you an advantage over someone who flew 12 - so other things, like price, RI and seat type would come in to play more. I doubt that USAir run all those flights because they think the competitor is flying 18 and so they'd better beat them by 1 because that will make a big difference - which sadly is how some people seem to view it in AWS at the moment.

I like your other suggestions about how concerned people are about frequency - and think that something like that would be good to build in to a more complex demand model. (indeed I suggested something along those lines myself here https://www.airwaysim.com/forum/index.php/topic,23532.0.html) My guess though is that this would be much more complex to code, and hence a longer-term solution; whereas my idea yesterday wasn't trying to do that, it was simply looking for a quick and easy but still reasonably fair way to remove a big chunk of the problems we have just now.