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.