Connecting flights/transiting passenger

[Meicci]

exchlbg, you made this feature request sound like impossible to implement. Otherwise, all true.

[swiftus27]

exchlbg, you made this feature request sound like impossible to implement. Otherwise, all true.

Because it requires a complete re write of the demand model in the game.   For you to make a change like this, you need to then make every passenger a unique being who has to choose how he is going from a to b.   Sadly, this will really require massive computing power to cycle now that every pax requires a calculation every 30-35 minutes.    This calculation has to include time to destination, time of day, seat quality, ticket price and more as these are the deciding factors as to why a pax chooses one flight over the other. This is why a lot of these ideas are simply not possible.  

[exchlbg]

I also wish it could be implemented, but somehow these "first came to mind" problems have to be dealt with.
Focus of computer model would be not the flight itself, but an individual passenger, and then, millions of those.
It´s simply going to be a new game, if you additionally think of changing to city based demand and new hub possibilities...

[Jona L.]

if you additionally think of changing to city based demand and new hub possibilities...

Apparently, as you named earlier, these cannot be "additional"...

City Based Demand is a requirement for this feature in order to not double and triple count each PAX, and the new hub-options are a result of it, once done (release expect AWS 4.5 in year 2057 if Sami still runs it till then )...

cheers,
Jona L.

[exchlbg]

I just asked him to think additional. Any other suggestions?

[Name_Omitted]

In a code-share, one airline buys x number of seats from another, and sells those seats to it's own passengers.

This is kind of re-stating something already posted in this thread, but from a technical perspective, would this be possible within an airline in AWS?

I have cities A and B, which both have demand.  C is a small town I wish to serve.  I create a route from B to C, and then allocate 5 seats on flight A-B and 5 seats on flight B-C to a "new" flight A-C, modeled for demand as a flight with a tech stop.  It is still a lot of programming, but should not be as much server load as some of the other suggestions during a game "day."  It would add a lot of flights to the game, but nothing particularly variable.

[exchlbg]

Sorry, I have to ask you to read my long "article" a few messages earlier. It can´t in any way be easily implemented, because you always think only of one tiny connection (5 seats !) and forget the consequences for the whole game.
Every now given demand is calculated with connecting passengers already, so it´s not possible to use that data base for player-controlled connecting traffic.

Additionally to all those major problems just implementing one-stop connection for own routes only, you are suggesting opening up an inter-airline-treaty-and-payment department for codesharing.

Seems all suggestors haven´t run any major airline ever in this game. With 5 tiny aircrafts everything seems so easy...

Some other problem just comes to mind regarding possibilities for new/small/late entry airlines to find a place to successfully start their business. With connecting demand every thinkable connection even in the outskirts of the world would already be served by one or more of the big guys, using their extensive network in their favour, when you face strong competition from day one. Games simply couldn´t host as many successful airlines as now, unless you additionally implement cargo ,Low Cost,business jet or feeder airline operations.

But not always talking so negatively I suggest to somehow automatically "reward" airlines for possible connections they already serve.
It would have to be worked into the other "decision values" that distribute passengers at flight origin, counting in all connecting traffic you meet at origin/destination (within a reasonable and varying transfer time).Possibly  even more refined if connecting own, alliance or other traffic. Demand figures should stay the same, rewarding only good connectors with 100% of possible customers.System would just look at total numbers (of flights, or more refined,passengers ), no logic routing necessary.Data base could stay as is. Startups would have their chance as feeders or by building up a regional "network".
Transfer times could be set min/max according airport class at first, later maybe refined for individual min/max according flight times of connection flights (reasonably longer if LH is involved, shorter for SH connections).
No "report" system about connections necessary,pricing stays untouched,no manual set-up of connections, game interface can stay the same. Leaving the question of necessary computer transaction time and maybe need to prolong game days for that reason.

[Sanabas]

I have cities A and B, which both have demand.  C is a small town I wish to serve.  I create a route from B to C, and then allocate 5 seats on flight A-B and 5 seats on flight B-C to a "new" flight A-C, modeled for demand as a flight with a tech stop.  It is still a lot of programming, but should not be as much server load as some of the other suggestions during a game "day."  It would add a lot of flights to the game, but nothing particularly variable.

Actually, something like this would work perfectly well, with minimal extra load on making calculations. The extra load would only be on the person creating the routes. And the extra work would primarily be in creating the interface.

Say my HQ is in ATL. I fly ATL-Miami, and ATL-LHR. I've got 2000 seats on ATL-Miami (10 daily flights), 1500 on ATL-LHR (5 daily flights). (no idea of actual demand, just making numbers up.) I designate 500 seats of each route to be for Miami-LHR, evenly spaced among the flights, priced at the default Miami-LHR price.

So now, when the system does its pax calcs, it treats me as having 10 daily flights of 150 seats each on ATL-Miami, 5 daily flights of 200 pax each on ATL-LHR, and 5 tech-stopping flights of 100 pax each on Miami-LHR.

There's not the exponential growth in calculation numbers of having the system search for connecting flights itself. If a miami-LHR seat is unsold, it doesn't become available for either Miami-ATL or ATL-LHR.

The issues would be how that affects gameplay balance. It'd also need total flight time to become more of a factor in the weightings, I think, as the 'tech stops' could be hours long. But it would be very workable to do as a test, and would require work by the airline operator, not by the system. Worst case would be maybe double the number of individual 'flights' compared to now. But I suspect much less, as in almost all cases, these tech-stopping flights would also be served by direct flights, and the ticket revenue would be less than the two individual flights.

It'd simply be a useful way to sell otherwise empty seats, to let you have 2 or 3 flights/day when normally that'd trip the oversupply warning, or not be practical (say a 250 pax route, and you're putting 200 seaters on it. 1 flight/day leaves demand unserved. 2 flights/day gives 65% LFs at best. 2 flights/day with 50 of the seats allocated to another route = still sell those 250 tickets, but generate a bit extra). More flexibility for people, and shouldn't lead to gamebreaking issues where a huge airline can take significant pax numbers from people in other airports. I can think of some ways to game the current system a little bit if something like this existed. At least in terms of getting bigger marketshare at routes from my own HQ. But not sure if that would actually translate to more profit, and I don't think it would translate to large-scale attacks on other people. It'd also allow smaller, otherwise unflown routes to be flown without needing to run a fleet of small planes.

[exchlbg]

Everything you supposed is logic, but again, only in YOUR point of view of one single flight/connection.
Please look at whole world when everybody is doing this with every possible connection he likes to set-up, and if only for the hack of it.
And still, your filling your airplanes manually,5 seats here,10 seats there, having to find individual prices for every part of that single airplane.Setting up a complete fare for MIA-LHR still leaves the need for system, to break down that complete fare into single flight legs.How could you otherwise make up single flight/aircraft results? Counting in all other connection possibilities, every seat in every aircraft is sold for a different fare.And since you can´t just divide the single leg fares into half, because it´s a SH/LH combo, who determines them? Should be you.Now looking at all other players doing that, you don´t see any problems?
Breaking up aircraft seats into nonstop/connection passengers would make it necessary to have a seat-plan of every aircraft to fill it seat/connection-wise by hand.No change of interface necessary?
Is MIAMI-LHR your only possible connection? What about all other destinations you serve from Atlanta ?
And still there is that problem, that according how data base for the game was collected, connecting traffic is already reflected.
All passenger demands MIA-ATL and ATL-LHR already count in there are people flying that combination, leaving you adding traffic on top of that.
There is no way this game can be played with manually generated flight connections,regarding actual database,reasonable reporting system,
time for players to keep control (playability), game balancing, and Sami´s time and computer system at given game prices.

There will always be hard limits for this game to reflect reality, otherwise we really start running businesses hiring staff to do so.It must also be possible to play this game with a limited on-line-time.

[Sanabas]

Everything you supposed is logic, but again, only in YOUR point of view of one single flight/connection.
Please look at whole world when everybody is doing this with every possible connection he likes to set-up, and if only for the hack of it.

Sure. But if every single person in the game splits every single one of his routes in 4, so that what was 2 single leg flights becomes 2 single legs and 4 tech-stops, that only triples the number of available flights. Which is why I say the worst case would be a doubling, and likely much less than that. whereas previous suggestions involved exponential growth, and many hundreds of times the calcs.

And still, your filling your airplanes manually,5 seats here,10 seats there, having to find individual prices for every part of that single airplane.

Yes. It'd take a fair bit of effort. But all the effort would be done by the person setting up the schedules, not required to be done by the system automatically connecting pax for you.

This would make it necessary to have a seat-plan of every aircraft to fill it seat/connection-wise.

Sure. So what?

*edit to respond to your edit* - No, no change of interface neccessary. At least not for the original route or the plane config. Say MIA-ATL is on a 757 (CPX001/002), in 186/15. ATL-LHR is on a DC-10, 260/32/10 (CPX003/004). I'd use a 'create connecting route', and pick those two flights. I'd choose 75/5/0 as the number of seats. That'd be CPX005. It'd be one way, because return flights wouldn't match up timewise, I'd need to create that separately. So now, at the end of the day, CPX001 has 111/10, CPX 003 has 185/27/10, CPX 005 is a techstop MIA-LHR, 75/5. Next week, I have a C-check, and so I put CPX003 onto a DC10-10, that only has 240/20/5. I also get a new 753 for 001, in 220/15. I don't have to do anything to the interface, CPX005 just takes its nominated numbers of seats from CPX001 & 003 automatically. So at the end of that day, CPX001 has 145/10, CPX003 has 165/15/5, and CPX005 has 75/5. Easy. If CPX001 or 003 don't fly due to cancels or maintenance, then neither does 005.

Setting up a complete fare for MIA-LHR still leaves the need for system, to break down that complete fare into single flight legs.How could you otherwise make up single flight/aircraft results? Counting in all other connection possibilities, every seat in every aircraft is sold for a different fare.And since you can´t just divide the single leg fares into half, because it´s a SH/LH combo, who determines them?

You could quite easily not bother with single aircraft results. And yes, you could just divide the single leg fare in half, and assign half to each plane. Or do it in whatever proportion you want. After all, it's only relevant for deciding if individual planes are making a profit. It's irrelevant for your own airline's overall revenue or profit. This isn't a case of someone flying one leg on airline A, and the second leg on Airline B, and trying to work out how to split the fare. Everything is on airline A, so any splitting of expenses or revenue is purely for internal accounting, and internal accounting things like which planes are most profitable, or ASK/RPK, are only good for confusing new players.

Is MIAMI-LHR your only possible connection? What about all other destinations you serve from Atlanta ?

What about them? If I currently have 1000 daily flights, maybe now I have 1250.

And still there is that problem, that according how data base for the game was collected, connecting traffic is already reflected.
All passenger demands MIA-ATL and ATL-LHR already count in there are people flying that combination, leaving you adding traffic on top of that.

This is simply wrong. I would be adding flights that service the MIA-LHR demand. IRL, there is demand from Canberra to LHR. But to fly that, you need to fly Canberra-Sydney, or Canberra-Melb, then from there to LHR. Which is modelled in game. Canberra-LHR has 0 demand. Some of Canberra-Sydney, and Sydney-LHR in game is based on RL Canberra-LHR pax. There'd be no point setting up your own Canberra-LHR route while HQed in Sydney, because there is no direct demand in game, the real life traffic is already modelled and covered by your existing flights. So there is no 'doubling up' of demand. The worldwide pax demand would remain the same. It just means more of it could be serviced, in particular thinner routes.

There is no way this game can be played with manually generated flight connections,regarding actual database,reasonable reporting system,
time for players to keep control (playability), game balancing, and Sami´s time and computer system at given game prices.

There will always be hard limits for this game to reflect reality, otherwise we really start running businesses hiring staff to do so.It must also be possible to play this game with a limited on-line-time.

If something like what I suggested was implemented, it would simply be ann addition. Not compulsory. Not required for success. Not an impediment to those with limited online time. No different to 7 day scheduling, or manually fiddling with the prices of individual routes. Nobody has to do that to make a profit. It takes more time to set up. But it's more efficient. So those who want to take the time to do it can. Those who don't, don't have to. Adds more depth for those who like to micromanage, doesn't give such a benefit that people should feel like they must do it to succeed.

This could work with some adjustment to the UI, and to how route profits get assigned to planes. It would fit in perfectly with the existing demand database. It would give players more options, more flexibility, more ability to micromanage and stay interested if they want to. It would allow smaller routes to be flown, and it would encourage people to use bigger planes.

It's also no replacement for city-based demand, or evolving demand in gameworlds. But it is much simpler to implement.

[exchlbg]

Sorry again, but you are wrong trying to prove anything with that Canberra-example.Canberra is no hub it´s dead-end of ULH plus connection. And numbers of Canberra-Sydney are reflecting that, being much smaller if it was only used by local city-city aussies.You would be able, being a SYD airline,to connect manually your CAN-flights to others out of SYD, and again, create demand that is already reflected.
In MIA-LHR example there are only big hub airports involved,who´s traffic numbers already reflect any kind of connection passengers.
If not, demand for MIA-ATL would be much smaller to begin with. Also MIA-LHR numbers would be much smaller if you deduct all passengers that use these airports as hub to somewhere else.
So ,especially for ATL, you are creating an additional demand, who´s numbers already are in the game. Sure, no problem if it was only you doing that, but everyone would start ATL-connections, each and every one adding on top of those numbers.Whole game balance would go down the drain.
Just simple math makes it clear that game data would explode after opening that system.
It´s not just A+B+C,  it´s going to be A*B*C, if you use every flight in worst case for connection traffic.
So, no problem for data handling, if you additionally fill your airplanes manually?
I really would like to hear Sami about that.

[Sanabas]

Sorry again, but you are wrong trying to prove anything with that Canberra-example.Canberra is no hub it´s dead-end of ULH plus connection. And numbers of Canberra-Sydney are reflecting that, being much smaller if it was only used by local city-city aussies.
In MIA-LHR example there are only big hub airports involved,who´s traffic numbers already reflect any kind of connection passengers.
If not, demand for MIA-ATL would be much smaller to begin with. Also MIA-LHR numbers would be much smaller if you deduct all passengers that use these airports as hub to somewhere else.
So ,especially for ATL, you are creating an additional demand, who´s numbers already are in the game. Sure, no problem if it was only you doing that, but everyone would start ATL-connections, each and every one adding on top of those numbers.Whole game balance would go down the drain.

Again, anyone taking the MIA-LHR flight via ATL would only be competing against those on other MIA-LHR flights. They'd only be counted as MIA-LHR pax. ATL is merely the techstop, in the same way that Cold Bay is merely the tech stop for my HND-LAX flight. There's no doubling up. There's no creating of additional demand.

The ingame demand reflects everyone who ends up at Miami, whatever small airport they may have come from, who wants to get to LHR. Those are the only pax who'd be on the flight. It's a Miami-LHR flight. Demand to and from ATL is irrelevant, it's not adding to ATL's pax numbers, because those seats aren't sold to anyone going to and from ATL. They're sold only to those who want to go MIA-LHR. Exactly the same as what is in-game now*. It simply means more airlines can provide a Miami-LHR flight.

*In JA currently, Cold Bay's & Nizhnevartovsk's total pax numbers for the year are 0. Not one pax has flown to either airport. However, more than 500 of my customers have a tech-stop at one of them every single day. To say that my suggestion would inflate ATL's pax numbers is the same as saying that my current JA flights inflate NJC's pax numbers from 0 per year to over 100k per year.

[Sanabas]

everyone would start ATL-connections, each and every one adding on top of those numbers.Whole game balance would go down the drain.

It's a tech-stop. It's adding nothing.

Just simple math makes it clear that game data would explode after opening that system.
It´s not just A+B+C,  it´s going to be A*B*C, if you use every flight in worst case for connection traffic.

No. There is no trying to make every possible connection. There is no looking at every possibility for a seat. Your airline has the seat to sell. Your airline either offers a seat on MIA-ATL + a seat on ATL-LHR, or your airline offers the seat on MIA-LHR. If I went really nuts, and I flew to 50 US destinations, and 50 Euro destinations, all with 200 seaters, I could try and turn those 100 flights into 2500 tech-stopping flights of 4 seats each. If everyone went to those lengths, then yeah, you're looking at 20 times the flights, if not more. I see no reason to assume everyone would do that though. And it's very, very simple to avoid. Simply allow only 1 (or 2, or whatever) of those connecting flights to be taken out of the base route. If it's only 1, then even if everybody in the game did it for every single route they had, it's still only a 50% increase. Let them take 4, and if everybody does it for every route they've got, the total number of routes triples.

So, no problem for data handling, if you additionally fill your airplanes manually?
I really would like to hear Sami about that.

So no, I don't think it's a major problem for data handling. It's double the number of existing routes, at worst.

[exchlbg]

I give up, we have just different point of views. It´s just trying to predict future, and last word stays with Sami anyway.
I would also like to hear your opinion of my suggestion to tie destination/origin traffic numbers into passenger distribution system?
It would encourage airlines to build up networks without the need to manually handle each and every flight/airplane.System could handle that by adding a few more formulas into passenger distribution, but handling more global, not individual numbers:

"But not always talking so negatively I suggest to somehow automatically "reward" airlines for possible connections they already serve.
It would have to be worked into the other "decision values" that distribute passengers at flight origin, counting in all connecting traffic you meet at origin/destination (within a reasonable and varying transfer time).Possibly  even more refined if connecting own, alliance or other traffic. Demand figures should stay the same, rewarding only good connectors with 100% of possible customers.System would just look at total numbers (of flights, or more refined,passengers ), no logic routing necessary.Data base could stay as is. Startups would have their chance as feeders or by building up a regional "network".
Transfer times could be set min/max according airport class at first, later maybe refined for individual min/max according flight times of connection flights (reasonably longer if LH is involved, shorter for SH connections).
No "report" system about connections necessary,pricing stays untouched,no manual set-up of connections, game interface can stay the same. Leaving the question of necessary computer transaction time and maybe need to prolong game days for that reason."

[Sanabas]

"But not always talking so negatively I suggest to somehow automatically "reward" airlines for possible connections they already serve.
It would have to be worked into the other "decision values" that distribute passengers at flight origin, counting in all connecting traffic you meet at origin/destination (within a reasonable and varying transfer time).Possibly  even more refined if connecting own, alliance or other traffic. Demand figures should stay the same, rewarding only good connectors with 100% of possible customers.System would just look at total numbers (of flights, or more refined,passengers ), no logic routing necessary.Data base could stay as is. Startups would have their chance as feeders or by building up a regional "network".
Transfer times could be set min/max according airport class at first, later maybe refined for individual min/max according flight times of connection flights (reasonably longer if LH is involved, shorter for SH connections).
No "report" system about connections necessary,pricing stays untouched,no manual set-up of connections, game interface can stay the same. Leaving the question of necessary computer transaction time and maybe need to prolong game days for that reason."

I'm not sure I follow. Players would basically get bonus pax, for any route that flies into a busy hub? Or players would not be able to get the available demand on a route, unless they flew that route at peak times?

[exchlbg]

Yes, somehow. "Bonus" pax only like you get a "Bonus" for being better in any other of pax distribution values.No additional pax, since I´m still sticking to my opinion, that given demand is somehow the upper limit of all direct/transfer PAX.
It would be just one more value, besides RI,CI,fare etc. Could be called "connectivity index". Stays to be discussed how it should be weighed during distribution process.
In RL individual flights at peak transit times will also see better bookings, use bigger aircraft or are more expensive than the other.

[Sanabas]

I´m still sticking to my opinion, that given demand is somehow the upper limit of all direct/transfer PAX.

Which is also my opinion, and the assumption I based my previous suggestion on.

It would be just one more value, besides RI,CI,fare etc. Could be called "connectivity index". Stays to be discussed how it should be weighed during distribution process.
In RL individual flights at peak transit times will also see better bookings, use bigger aircraft or are more expensive than the other.

I don't see the point, and I don't see any benefit. It'd be simpler, and have the same effect, to just refine the time of day stuff a little more. Instead of just penalising a flight that takes off/lands in the middle of the night, you'd increase the range, with peak times beingthe best, and middle of the night being the worst. But I don't think it matters much.

[exchlbg]

It stays sticky between us concerning that demand/traffic thang.
I`ll give it one more try. In your model the MIA-ATL flight is filled with people for MIA-ATL route and those manually put on connection legs. Right?
Pax are counted as being on different flights, one part according MIA-ATL demand and the other part MIA-LHR, right?
Now here is the exact source of our problem, it´s not solved by handling one flight as virtually two different ones.
We both agree, that demand numbers in game are somehow the top limit of all PAX, direct and connection.
So the demand numbers for MIA-ATL, according to whom your MIA-ATL part of seats are filled, already include all connection passengers (and that´s a huge amount in RL, because only few PAX stay in ATL).Game stats don´t make a difference between people hopping finally off in ATL or changing planes. For the same reason CAN-LHR is zero in game, although in real life there is a demand, it only goes completely into CAN-SYD or -MEL- figures, because in real life everybody is changing planes there.In game those people after transfer form part of the complete SYD-LHR demand.
Demand for MIA-ATL already includes all connection traffic. But in your case those manually placed MIA-LHR PAX are sitting next to PAX that are flying this route automatically ,unseen by us, but forming the game MIA-ATL and ATL-LHR demands. These are the additional PAX I´m always talking about and you deny to see.This problem can only be solved using city-based demand figures, showing exact demand between any two regions of the world regardless of real-world traffic data.Hope I could make myself clear....

Additionally I oppose your statement, that only few airlines would use connection possibilities, if you look alone at the players, whose arguments you used to stake your case. One of those wants to kind of sample together even 5-seat connections (and trade them for codeshare) ! And I also don´t like your idea to limit those possibilities, once given, to one or two (or whatever). All that for one/two/few flights each ? One of your (don´t know) 1000?
In that case the whole thing wouldn´t be worth disputing. And the more rules/limitations you set, the more confusion, discussion and need to control you are adding. No, I believe in the whole picture or nothing.

Also concerning other problems like missing correct flight/aircraft result data you tend to wash everything off the table with one short move.
I believe many players somehow work with these numbers and would protest or constantly ask for reliable data.I also doubt, putting up flights seatwise in an aircraft model would be the easiest little thing to implement, if you think of how much effort the last minor changes needed.

[Sanabas]

Demand for MIA-ATL already includes all connection traffic. But in your case those manually placed MIA-LHR PAX are sitting next to PAX that are flying this route automatically ,unseen by us, but forming the game MIA-ATL and ATL-LHR demands. These are the additional PAX I´m always talking about and you deny to see.This problem can only be solved using city-based demand figures, showing exact demand between any two regions of the world regardless of real-world traffic data.Hope I could make myself clear....

You are talking crap, and I can't tell if it is intentional or not. There is demand for pax to go straight from MIA-LHR in game. This would allow an airline not based in MIA or LHR to provide a tech-stopping flight for those pax. Regardless of where that tech-stop is, the route is only available to those wanting to fly from MIA to LHR. It isn't 'adding' demand that didn't exist before. It could be the tech-stop is in ATL, it could be in Bermuda, it could be an airline using Gander as their HQ. Right now in JA, nobody could fly MIA-LHR non-stop. A miami based airline could fly Miami-LHR via Bermuda. A LHR based airline could fly MIA-LHR via bermuda. Now a Bermuda based airline could fly Miami-LHR via Bermuda as well. And an ATL based one could fly MIA-LHR via ATL. And so on. They're 'adding' exactly as much demand as what a current airline flying MIA-LHR via Bermuda is. Which is zero.

If you want to be critical of it, be critical of it for reasons that are actually true, and stop carping about why you think it's creating demand out of nothing, that doesn't already exist in game, and isn't available to anybody else. Because that's rubbish.

[exchlbg]

First I want to ask you to watch your words. In no way you are qualified to call my words rubbish or crap. I don´t call you stupid either because you don´t see my general point, which has NOTHING to do with Jet Age,Atlanta or tech-stopping in general.Main problem was NOT MIA-LHR traffic, but ATL-MIA and ATL-LHR traffic, already "existing" in game demand numbers.And although you deal those seats as if they were an additional tech-stop, you don´t fly an additional plane,you pile those passengers on existing ones,with no extra costs, just extra revenue.And game consequences are minimal in exact this case, but pile up if you consequently think it through all airlines, all connections.So what the hack.Let other people or Sami decide.I tried staying polite despite your attitude. Try to do the same.