AirwaySim

Before getting started; Yes, I've searched and found a couple of topics about this:

https://www.airwaysim.com/forum/index.php/topic,12045.0.html
https://www.airwaysim.com/forum/index.php/topic,10670.0.html
https://www.airwaysim.com/forum/index.php/topic,3360.0.html
https://www.airwaysim.com/forum/index.php/topic,6081.0.html

etc. etc.

But I still feel the need to vent some thoughts and ideas, so bare with me. Here goes...


The current system is pretty straightforward, point-to-point routes only and very simplified competiton, a bit too simplified as there is a lot of talks now about anti-monopoly regulations etc. To go beyond having just a little fun and have a few planes and really be able to expand, you currently have to be based on a large high-demand airport (fixed to real-world numbers, not dynamic). Even if multilple bases would be added to the game, it still wouldn't really add anything except more simple hard-core expansion options, it wouldn't really add to "being smart". This takes a bit of the edge away. From what I understand the current issue is the staggering amount of calculations that would be necessary to have truly transiting passengers. But what about a simplified, expandable version of this.
Let's start off by some conditions to limit the amount of possibilities for a "transfer" (which can later be expanded/relaxed):
* No "second destinations" allowed in your schedules
* It can only be your own flights
* PAX accepts a maximum of 1 transfer
* PAX accepts a maximum transfer time of 3 hours
This should greatly limit the number of options for a transfer, and can of course be relaxed later on depeding on computational limits etc.


So how would this work?
Every time a route-pair is created/edited/removed the "connections table" (database table) is updated with consideration to the above mentioned rules.

Example:
You already have connection A - B - A, departing 08.00 and returning to base at 12.00.
You create connection A - C - A, departing 14.30 and returning to base at 18.00.
When creating second connection the following happens:
A connection "A - C" is created in the database with calculation information such as price, service levels, aircraft, type of aircraft, capacity, departure time, total flight time and other variables necessary to calculate PAX distribution. Also during the creation of connection "A - C" a check is also made to see if a transfer is possible according to the above mentioned rules.
As there is an arrival from a different destination by your own airline within 3 hours before the flights departure, a connection is possible between B - C via A!
A connection "B - C" is created in the database with calculation information necessary to calculate PAX distribution incl. but not limited to an average service level, via, total flighttime, total price etc.

When time to determine distribution of passengers from B to C, all flights are compared (the entered direct connections for those airports and the transfer connections) and depending on PAX preferences the PAX are distrubuted on the avialable choices between B and C.


This would of course require a few more calculations to determine exact capacities of the different legs used, and what is prioritised in terms of direct PAX vs. connecting PAX, and other calculations/presentations to make this work fully as intended.

In combination with adjustments to take departure time (high-demand times) more into account and adjusting flights to make transfers possible, this would add to the "be smart" instead of "be more" part of the game. Since it's obviously impossible to have all flights at all time to depart in the peak hours it would make it possible for smaller airlines to have clever routes with lots of connecting passengers between smaller destinations. As an example a small airline flying small, low-capacity airplanes with short turn-around times would be able to have connecting flights and compete with direct flights as total flying time would not be much more. And as smaller planes are cheaper to operate they should also be able to have pricing levels that make even connecting flights attractive vs. direct flights.

Along with this system I would also like it more clearly shown the prices and service levels of other airlines, in order to provide a possibility to make sensible choices in terms of pricing, service levels, departure times and type of aircraft. I've read the aeguments for hiding this information but disagree as it makes the game anonymous and almost turns it into a vs. computer game. All in all, I would definately ask for more "smart" than "more" improvements (read: connecting flights, better distribution of PAX vs. multiple bases). At least until the "smart" improvements are implemented.

An obvious extension of this is of course to reset the fixed demand figures between airport pairs and recalculate them depending on population, airport size (uptake area) and other nearby airports, and let natural hubs be created depending on where airlines set up their bases. A larger capacity airport (open 24H) would of course allow more flights then. And in an extension having demand be dynamic and based on most utilised aiport in the area, capacity etc. I've read the discussion about it, and maybe now is the time to recalculate the fixed numbers for demand and let natural hubs evolve?

Just some quick ideas before the nightshift. Thoughts?

Quote from: TommyC81 on November 08, 2009, 07:43:21 PM
* PAX accepts a maximum transfer time of 3 hours

Why?

Quote from: TommyC81 on November 08, 2009, 07:43:21 PM
* It can only be your own flights

Why? We should be able to make codeshare agreements.. This could make alliances more reasonable in game.

But I'm more for system of manual adding connection services.. For example, I have route A-B and A-C.. but system wouldn't sale B-A-C route automaticaly, but I would need to set it first manually..

Also, minumum connecting times - there should be some minimum time (based on airport size, maybe real number of flights in specific daytime). It would work exactly like turn-around times - if you just use minimum connection time, there would be high possibility of delay (due to waiting for connecting pax). Adding +30-40% of time would set "possibility of delay" to very low number.

Because:

Quote from: TommyC81 on November 08, 2009, 07:43:21 PM
--- From what I understand the current issue is the staggering amount of calculations that would be necessary to have truly transiting passengers.---
--- This should greatly limit the number of options for a transfer, and can of course be relaxed later on depeding on computational limits etc. ---

Quote from: Samo on November 09, 2009, 04:13:44 PM
Why?
Why? We should be able to make codeshare agreements.. This could make alliances more reasonable in game.

But I'm more for system of manual adding connection services.. For example, I have route A-B and A-C.. but system wouldn't sale B-A-C route automaticaly, but I would need to set it first manually..

Also, minumum connecting times - there should be some minimum time (based on airport size, maybe real number of flights in specific daytime). It would work exactly like turn-around times - if you just use minimum connection time, there would be high possibility of delay (due to waiting for connecting pax). Adding +30-40% of time would set "possibility of delay" to very low number.

Thanks Powi for clarifying reason why, maybe wasn't obvious  :)

Defining your own connecting flights may also be an option to limit the number of calculations necessary, that would also leave room for more precisely adjusting pricelevels, service while waiting, seats with priority for connecting passengers etc. Of course, some rules could still apply if a connecting flight is possible or not. Had not really thought of this option. Defining your own connecting flights would still require a lot of administration compared to a couple of settings and automation of this, but could possibly be worthwhile.

Either way, a better presentation of the competition is still desireable, like prices and servicelevels, in order to actually be able to make sensible choices. In comparison Airline Empires (another onlie airline game) does show pricing levels of other airlines and is overall much harder as soon as you're competing with others on different routes. Spamming a route with cheap capacity is extremely costly, while in Airwaysim, it's just a matter of small fuel cost and a monthly lease.

What do you think about this: not every flight and airport needs to be connected to every other flight or airport. There are only certain routes, I believe, on which there is a demand for connecting flight. You would have to come up with some kind of 'transisting passengers index', in order to really be able to simulate the connection thing.

Without reading all this. Would you prefer to determine the connection flights and prices yourself (ie. choose which connections are offered), or let the system be fully automated?  At least some price controls would be needed in my mind.

Quote from: sami on November 09, 2009, 07:40:21 PM
Without reading all this. Would you prefer to determine the connection flights and prices yourself (ie. choose which connections are offered), or let the system be fully automated?  At least some price controls would be needed in my mind.

IMHO

Passengers will naturally connect between airports, with or without the help of an airline.

For this reason, I'd automate the pricing system (as it is now) but leave the option for a player to tinker with the prices, offer special prices for pax that fly a-c via b when flown with that airline etc..

Best Regards
Richard

Quote from: sami on November 09, 2009, 07:40:21 PM
Without reading all this. Would you prefer to determine the connection flights and prices yourself (ie. choose which connections are offered), or let the system be fully automated?  At least some price controls would be needed in my mind.

My initial thought regarding connections and pricing was an automated system for determining connections offered and a general setting for discount on the cheapest fare. It would make the system very easy but would perhaps be a bit restrictive in terms of price control. Maybe a good starting point?

A manual system that would show possible connecting flight offerings which can be accepted and then fine adjusting the prices and possibly also how many seats are reserved for your direct PAX vs connecting PAX could work, but would be a very tedious task unless very streamlined as soon as you open a new route which enable lots of connections

So, to answer your question; I'd prefer automated connection offerings and an improved pricing management system overall to compare competition and streamline the pricing process (incl. a research system to see what estimated effect on profit and loadfactors a price change would have, we have staff employed for this kind of research  :) ).

Quote from: Riger on November 09, 2009, 08:04:41 PM
IMHO

Passengers will naturally connect between airports, with or without the help of an airline.

For this reason, I'd automate the pricing system (as it is now) but leave the option for a player to tinker with the prices, offer special prices for pax that fly a-c via b when flown with that airline etc..

Best Regards
Richard

I wouldn't say the pricing system is automated, rather only suggesting. To keep comparing, there is an option for "Auto pricing" in Airline Empires which sort of tries to achieve maximum profit (or lack thereof if heavy competition), though not as good as you could by manually adjusting prices (there is a research option to try different prices and their outcome). But the current system which basically hides prices of the competition and their service levels make it barely a guessing game to compete (i.e. lower the price a couple of %, wait a couple of days and see if it made a difference). Airwaysim has a lot of strengths, in particular the presentation, the route planning system (which gives a feeling for actual peak times and achieving maximum use of your aircraft) among other things, and with a few more things added Airwaysim will be even more miles ahead.

Interesting reading: http://www.airlineempires.net/content/view/48/49/

I think we should start with one stop passenger first before we do connections. I have played other games with connections and it is very complicated. ie how do you control for connecting pax versus locals? What if you want only locals, what about 10% connects, 20% etc? Take that concept to a hub with 100 flights and it is impossible to do manually

Mostly automatic, if possible (manual is better than nothing). However there should be some manual control of this, because some airlines could choose to not offer connecting flights (IRL Ryanair). Choosing to offer connecting flights would mean higher demand for customer service personnel etc and delayed/canceled flight should cost to the airline, because it need to re-route passengers, maybe to another carriers. Marketing costs should also be significantly higher (mostly for game balance).

Why are all of you writing books here?!
you could make millions (alltogether) if you would just write Novells! ;D ;D ;D

Well... I think you should either only let PAX connect to alliance intern routes, or to your own ones only!!

that is my opinion, but mabe you have better ideas ;);)!

To add my coins to this great idea, I would have the system create 2 separate route pages. In other words, you would the normal route page where you can modify your current routes (the "Manage Routes" page) and the connecting flights page where the system automatically creates connecting flights. Using that page, you can do whatever changes you would like for connecting flights. It is a bit more organized this way and less confusing.

After some thinking I have an idea how to simplify the idea a bit.

a) All connection routes have to be created manualy (yes they have to be as in real world).

b) after you create a connecting route it will be a normal one (as per normal direct flight) but less pax will be willing to travel with you (depending on the waiting time, aircraft type, price).

By creating the routes by hand you are making sure that there will be no more calculations and even if there was still you use the normal chart - no extra numbers. After you create this you can then just mark which routes will be connected (i.e. you have a route 0031 from Amsterdam to Prague and then 0250 to Moscow - if you have at least hour in between these flights and you can mark them as a connecting flight.

Its a bit of a simplified concept but I think it would be a good start.

Just thinking about the sheer number of possible connections that can be created even if you only have 70 or 80 unique routes, it is staggering to imagine having to create all those flights manually, one by one... (unless i am misunderstanding something about the manual creation suggestions?)

I don't have any hard knowledge of real world airline scheduling systems, but I have a hard time believing that when you book a flight online at an airline's website, it's anything other than a computer somewhere that is simply comparing your inputs of departure point, destination, and requested dates, with a database of all the airline's individual route legs to spit out all possible connections.

I don't see how anything other than at least a partially-automated system would work in AWS.  

As for pricing, I think the best solution is to first take the sum of the user-defined prices for each leg, and then factor in a discount that reduces this sum to a reasonable total fare for the whole flight (since, as I understand it, in real life you don't pay for each leg you fly.. you pay one price for the whole flight that is derived based on the number of connections, distance of each leg, etc.)


Thoughts?

I am a strong advocate of doing one stop thru pax first before connections

Quote from: ekaneti on November 12, 2009, 12:24:38 AM
I am a strong advocate of doing one stop thru pax first before connections

Just to clarify, what do you mean by that?

Quote from: Branmuffin on November 12, 2009, 12:35:08 AM
Just to clarify, what do you mean by that?

Right now we can schedule a plane from ORD-DEN-LAX, but not carry pax on ORD-LAX via DEN. We should try that first before we have connections.

Connecting pax are one of those "becareful what you ask for" things

I thought you already could carry pax ORD-LAX via DEN by making the stop at DEN a technical / refueling stop only, or am I misunderstanding you?

Quote from: Tivec on November 12, 2009, 01:01:48 PM
I thought you already could carry pax ORD-LAX via DEN by making the stop at DEN a technical / refueling stop only, or am I misunderstanding you?

you can, and it will remain in the game!

Quote from: ekaneti on November 12, 2009, 12:24:38 AM
I am a strong advocate of doing one stop thru pax first before connections

Well, that would be more or less what I'm saying apart from the part where I suggest ways to limit the calculations needed to process ALL connections. Having truly connecting flights for all possibilities would likely require more processing power than all users can supply during a 30 min gameday.

Quote from: TommyC81 on November 12, 2009, 09:40:59 PM
Having truly connecting flights for all possibilities would likely require more processing power than all users can supply during a 30 min gameday.

That is one of the issues. With a 24h game day for example (= full real time) that wouldn't be a problem at all. But try to count all that data in just 30 mins.

(And some guys even wish to play something like 15 min days (= no way). :P)

So whats the decision on this idea?

I wouldn't mind if the game progressed a little slower (even 2-3 hours/day), if I were to get a system closer to reality. And connecting flights is something very important imo.

The ideal would be a system like the software every travel agency uses: it is feeded with all flight data and on every request it is showing a long list of possibilities. The client choses his flight out of the list acording to his own preferences like price, date, number of transfers airline etc.
In this game, the computer would have to generate millions of travellers ("Sims") with different preferences taking their choice. This means billions of calculations for the software!

I´m not deep in programming, but I´m sure this not something made in a week...

So, i think it would be the only way to have a fast solution to create connecting flights semi-manually. Maybe the system could help:
whenever you created a new route, the programme automatically shows you a list with flight starting in a timeframe after the arrival time of the new route.
It could be a popup, saying something like" Do you want to create connecting flight to xyz" and a check box. (A connecting flight from New York to Boston via Los angeles wouldn´t make sense!). If you click yes, the route is automatically created.
This functionality is close to the  technical stop function, so it should be easy to integrate?!
The connecting routes might also been shown as direct line on the map, maybe on a second layer.

Edit:
Ups, just found an answer somewhere else:

Quote from: sami on June 27, 2009, 02:39:43 PM
The number of route pairs goes up more than exponentially by this so before it can be even thought of the calculation system must be tested and partly re-optimized. Not a simple process.  (ie. if we'd have 110 000 route pairs now, with connections automatically this could go to millions, which is way beyond the design limits)

As I know the planning is in progress for the next version (1.2), I'd just like to make one more push for this feature.

Sorry I only just noticed this thread,  :P

Ok heres how I see the system working, much like the real world system with airlines.

Passengers booking online punch in their departure dates, destinations etc, normally direct flights are listed first, then connecting flights with the same airline or their partner airlines.

So maybe when inserting a new route you could include an option to choose which flights this new route will connect with. If they click Yes to 'Connect flight with;' they could select connecting flights from either a drop down menu or popup screen of available flights from that airport after the previous flights turnaround time is completed. (IE a 737 lands, the system will show all flights available 40 minutes after arriving, 747 it will be 120 minutes etc.) Maybe we could even make it more standard to just 90 minutes ore something round.

I was thinking maybe too connect with alliance members, could the database search for flights departing from airport with the alliance logo attached to the route? (IE in route planning alliance logo is attached to airline name, could database search for that?)

Just an idea, I dont know much about this sort of stuff, but its my opinion anyways.  :laugh:

Any news on this subject?

This would be my #1 request for the game, in order to add realism.

With this addition, the game could be a lot more dynamic.  Instead huge 3000 static demand between large airports, the inherent demand of, say ATL - DFW should be a lot more modest, say 1000 or so, corresponding to local demand.  It would only grow to 3,000+ if passengers from connecting flights create this demand.

Ideally, the system should handle as much, or everything in the background.  If there is a route A-B and A-C, the system should check the quality of possible connection B-C based on timing of connecting flights.  Direct, non-stop B-C flight(s) would be perfect, and 100% of inherent B-C demand could be realized and turned into ticket purchases.  Less perfect connections, such as B-A-C would receive some scoring based on timing etc, and would receive less that 100% score, meaning less than 100% of the inherent B-C demand would turn into ticket purchases.

Now the system could do that all in the background, no changes in interface would be required for the bare bone functionality.

An are for enhancements would be ability to set prices (discounts) for connecting passengers and maybe limits of how may of the discounted transferring passengers the player is willing to take.

Another area to make the world more dynamic (if desired) would be a way for airports to grow based on demand.  If slots are sold out, airport could decide to expand and create more slots.  But this would be more of a departure from the Sim trying to mimic the real world.

OTOH, passengers transfers from connecting flights would make the Sim closer to the real world - and frankly, a lot more fun.

Bumping this because this would be really great to get, but to be able to fully use this feature it would also need the code-share agreements.

To be able to get the connecting passengers it could need some restrictions on the time spent on the airport by the connecting passenger. For example

Small airport  30min to 1 hour
Middle-sized airport 1 hour to 2 hours
Significant airport 1,5 hours to 3 hours
Large airport 2,5 to 5 hours

This is just so that the passengers won't be making turnarounds which would be impossible in real life or turnarounds which nobody (expect people who love airplanes) would be really making like staying 12 hours on an airport.

And why do I support the connecting passenger idea is, prolly the same as for everyone else. You may be flying from B to C with a 150 seater, but the demand is 120/day and the demand from A to C is 20/day so you could get more people on board if the schedule is reasonable.

Just dropping my 2c for an easy way to model connecting flights.
Generally speaking, a traveler flying from a small-airport to another far-away-small-airport will take 3 flights: local-airport-to-close-hub, hub-to-remote-hub and remote-hub-to-remote-small-airport. Of course, there are variation, but that's the general gist of it.

A simpler way to put this : A large number of SERVED domestic flights at an airport will increase the demand of short international and large international routes at that airport.
Also, a larger number of SERVED international routes can increase the demand on domestic routes.

For my case, there are 2 airports located in Bucharest: LROP and LRBS. Having a large number of domestic flights from most local cities to LROP might create an increase in international routes, so that more passengers will fly to, say, EDDH from LROP than LRBS, because of the additional connecting passegers.

While not exactly easy this should be much simpler to implement than some sort of connectivity-path-finding, and it will model connecting passengers close enough: eg. larger airlines operating at large airports now have an incentive to partner up with smaller domestic airlines that would bring their passengers for international routes.

Quote from: radu.poenaru on February 21, 2012, 02:55:56 PM
Just dropping my 2c for an easy way to model connecting flights.
Generally speaking, a traveler flying from a small-airport to another far-away-small-airport will take 3 flights: local-airport-to-close-hub, hub-to-remote-hub and remote-hub-to-remote-small-airport. Of course, there are variation, but that's the general gist of it.

A simpler way to put this : A large number of SERVED domestic flights at an airport will increase the demand of short international and large international routes at that airport.
Also, a larger number of SERVED international routes can increase the demand on domestic routes.

For my case, there are 2 airports located in Bucharest: LROP and LRBS. Having a large number of domestic flights from most local cities to LROP might create an increase in international routes, so that more passengers will fly to, say, EDDH from LROP than LRBS, because of the additional connecting passegers.

While not exactly easy this should be much simpler to implement than some sort of connectivity-path-finding, and it will model connecting passengers close enough: eg. larger airlines operating at large airports now have an incentive to partner up with smaller domestic airlines that would bring their passengers for international routes.

That would be something along the lines of Fake Passenger Connection thread I started a while ago:
https://www.airwaysim.com/forum/index.php/topic,25004.msg126089.html#msg126089

It would be a diversion.  Since the real thing is far away, I thought it would be a good stop gap measure.  But spending time on this (which would bring us no closer to the real thing) would just postpone the real thing even more..

When you are saying "the real thing", you mean actually computing connecting passengers with route-finding ala "I want to fly to Rome and the cheapest way is via a 2h stop in Budapest"? Cause' I don't think that can actually be modeled in a 35 min day.

What my (and your) proposal will do is allow airlines to "create" these airport-hubs (or destroy them by going bankrupt) thus adding a little variance in the demand of the routes.. not the real thing for sure, but still nice.

Quote from: radu.poenaru on February 24, 2012, 11:43:55 AM
When you are saying "the real thing", you mean actually computing connecting passengers with route-finding ala "I want to fly to Rome and the cheapest way is via a 2h stop in Budapest"? Cause' I don't think that can actually be modeled in a 35 min day.

A lot of corners will have to be cut to get it off the ground, such as at first only connecting within 1 airline (most have only 1 hub), probably no time of day etc...

Quote from: radu.poenaru on February 24, 2012, 11:43:55 AM
What my (and your) proposal will do is allow airlines to "create" these airport-hubs (or destroy them by going bankrupt) thus adding a little variance in the demand of the routes.. not the real thing for sure, but still nice.

Definitely, every game world would be different.

Would it be possible to charge more on smaller legs to make serving smaller cities viable?  In real life United charges little on the IAD-ORD route, then make up the money on the regional flight to LAN, ect. 

Bump.

Connecting passengers is a must.  I have a friend who won't play again (purchase credits) until there are connecting passengers (and he wants mergers too).

I've read most of the post on this subject, and would like to voice my support for some sort of dynamic and potentially significant bump to demand when considering connecting passengers.

I realize the difficulty of this task because of the real-world information influencing airport and city pair information, but think there should be some way to build a hub in a smaller city (and by build I mean right-size to bigger aircraft as I grow).

Why make it so complicated? The data is already there! Let me give you an example.

You have a hub (base airport) at A.
Two of your destination cities, B and C have 50 pax demand between them, but no flights offered.
These pax will have to fly to A, and then hop on a transfer flight from there.

Pax should prefer direct non-stop flights, so the formula for tech stops can be used. If another airline (or yourself) open a direct route between B and C, the pax will prefer to go on that route. This is how it works in real life.

One could set the "patience" of the pax to for example 4 hours (Maybe more on long haul routes?):

Mr. Pax lives in C, but wants to go to B. Unfortunately for him there are no direct routes, so he flies from C to A at 6:00 and arrives at 7:00.
This means the flight from A to B has to depart within 11:00.
If there are no flights scheduled within that time frame, Mr. Pax simply won't fly from C to A in the first place.

As for prices, pax will pay the price a direct flight would cost, minus the penalty for a stop (Like tech-stop pricing).
This means that the transfer pax flying from C to B will create less than half the revenue as the direct pax on the same flight (who's destination is A). The transfer pax will not be as lucrative as the direct pax, but still a welcome supplement.

C to B Direct Route price: $100
C to B Transfer Pax price: $80

$80 / 2 flights = $40 on each flight (C to A and A to B)

Sounds really simple. But it isn´t in any way. You say, pax pay some price minus something and take two of your flights to get anywhere.Who determines, which price they are paying ? The system? Pricing is your task. What statistics tell you about which passenger is flying where at what price? The whole route/airplane documentation would have to look different, that one additional column in your example doesn´t tell you anything.

Since the game and it´s basic data refer to real-world numbers, connection demand is worked into the game already. Otherwise the demand for real-world hubs would be much,much smaller. That makes it essential to have city-based demand introduced first, or traffic/demand will grow to unnaturally high figures.
I don´t have insight of the technical possibilities of the game´s equipment, but computing connection demand/traffic might take much longer,so game would have to change to real-world days to handle all that stuff.

Next problem would be building up personal hubs. Should we stick to real world infrastructure or should we allow popping up world hubs in the middle of nowhere implying politics would simply build a big hub for you?

So there are many reasons why it`s not incorporated yet.

Quote from: exchlbg on October 26, 2012, 07:12:58 PM
Sounds really simple. But it isn´t in any way. You say, pax pay some price minus something and take two of your flights to get anywhere.Who determines, which price they are paying ? The system? Pricing is your task. What statistics tell you about which passenger is flying where at what price? The whole route/airplane documentation would have to look different, that one additional column in your example doesn´t tell you anything.

Since the game and it´s basic data refer to real-world numbers, connection demand is worked into the game already. Otherwise the demand for real-world hubs would be much,much smaller. That makes it essential to have city-based demand introduced first, or traffic/demand will grow to unnaturally high figures.
I don´t have insight of the technical possibilities of the game´s equipment, but computing connection demand/traffic might take much longer,so game would have to change to real-world days to handle all that stuff.

Next problem would be building up personal hubs. Should we stick to real world infrastructure or should we allow popping up world hubs in the middle of nowhere implying politics would simply build a big hub for you?

So there are many reasons why it`s not incorporated yet.

Sounds really simple. But it isn´t in any way. You say, pax pay some price minus something and take two of your flights to get anywhere.Who determines, which price they are paying ? The system? Pricing is your task. What statistics tell you about which passenger is flying where at what price? The whole route/airplane documentation would have to look different, that one additional column in your example doesn´t tell you anything.

- Who determines what price they're paying? You of course. Thats how the system is now. It calculates a price fitting for the route, but you're free to change it however you want. What's the problem? Yes, of course the route pages would have to be updated and changed. There would have to be a route page for transfer pax. Let's say you open a route to a new destination. On the same page, you can get info on transfer pax willing to go there from other destinations too. It's not simple, but it's not a huge problem. I made the additional column to show you how it could look.

Since the game and it´s basic data refer to real-world numbers, connection demand is worked into the game already. Otherwise the demand for real-world hubs would be much,much smaller. That makes it essential to have city-based demand introduced first, or traffic/demand will grow to unnaturally high figures.
I don´t have insight of the technical possibilities of the game´s equipment, but computing connection demand/traffic might take much longer,so game would have to change to real-world days to handle all that stuff.

- That really isn't a problem. The pax who wants to go from C -> B just goes through A instead. If an airline establishes a route directly from B -> C, the demand for C -> A -> B decreases depending on the seats offered from C -> B. Also, decreasing demand on some direct routes would be a very small price to pay if we got transfer pax into the system, wouldn't it?

Next problem would be building up personal hubs. Should we stick to real world infrastructure or should we allow popping up world hubs in the middle of nowhere implying politics would simply build a big hub for you?

- I really don't understand what you're saying here. What are you talking about? Your base airports are your hubs. The system with airport bases would be just the way it is now. Only difference is that transfer pax could fly through your base airport to get from B -> C.

I think you are missing the nature of the calculations involved for each and every flight : currently, the system calculates the load for a given flight, after considering all the variables: price, demand, supply, CI, RI, seats, frequency, etc , and the same for any competition on the route to determine who gets what share: for the above connecting system to work, each flight would also require additional calculations made for every other airport you serve. first to determine demand : how many pax wish to connect through your destination airport to that destination; and then the additional load: how many are actually going to fly that day and not forgetting : that the flights involved meet any connection time limitations : and is there competition, and how will that affect matters.

It will not just be pax wanting to go from B to C via A, after all : there will also be pax wanting to go B to D, E, F, G and so on.

So if you serve 50 airports, every flight will need its main calculation : A to B; then an extra 48 sets of calculations to determine connecting pax : that's an awful lot of calculating going on : for every flight : and every time you open a new route, you increase that set of calculations and increase the processor load again.

Just looking at one airline in MT#7 : it has over 17000 weekly flights to over 350 airports : we are going to need a bigger server.

You really don´t understand anything I´m saying. Concerning demand figures: I said, that connecting passengers already are worked into the system, otherwise Atlanta for example would have the demand of any other middle-sized city of the US.
So the numbers of your transit passengers would just add on top of already worked in numbers, leaving demand/traffic hugely oversized.And I´m not talking just lowering the figures a bit, it needs a complete data overhaul. (City based demand)

Concerning hubs: With connecting passenger system you can build a hub out of any base airport you choose.If we use city-based demand   it´s up to the players where they evolve their hub for connections. Real-world infrastructure data have evolved over ages with traffic/politics as given by history, but if we develop a new system of hubs, infrastructure would have to grow after our needs, turning airports like maybe Kansas City into a major american hub,leaving Atlanta a mediocre airport for example. It´s going to be a completely new world for every game, not just re-playing history over and over.

In your example you just talk about one additional connection via hub. But what´s about all other connections that are possible within 4 (why?) hours transit, each and every one forming a route you would have to establish, make prices for and check regularly.And it´s not just concerning you, but every player in game, the data to be handled would not just add up ,they would explode.
What about the time needed for every player, to harmonize all that additional demand/traffic? With big businesses, one additional flight from hub to a new destination might open up numerous of possible new connection routes, each and every one to be managed.How many staff you are going to hire in RL to help you manage that monster? How are the single passengers documented per aircraft, because on every single plane there will be direct passengers and passengers for/from up to hundreds of other destinations, not to mention the possibilities of connecting flights via more than one hub, connections to other alliance members, to other airlines, codesharing?
How should planning/documentation of flights/aircrafts look, when every flight is also used as a part of another one and every passenger has another final destination? How do you set prices, when splitting complete price evenly over used single legs can´t be the answer considering SH/LH connections? How do you work out single flight/aircraft results, if in worst case every passenger is paying a different fare for his single leg seat? What about combinations of different cabin classes?
You will have to think just one or two steps further to see all those additional problems to be solved besides your nice shiny new column.So it´s fully understandable why it is not implemented yet.

+1 exchlbg

This would create much more dynamic GW's. Any hub with a big enough runway could host an alliance.

Perhaps alliance funds could be channelled into building the terminal infrastructure etc.?

Why not trial this is a small scenario first?

The game is great, but to have a GW that truly moves with the players decisions and not just following RL events would be a special challenge...

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

Quote from: Meicci on October 31, 2012, 08:53:28 PM
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.  

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...

Quote from: exchlbg on November 01, 2012, 05:46:46 PM
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 :P )...

cheers,
Jona L.

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

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.

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.

Quote from: Name_Omitted on November 03, 2012, 06:34:51 PM
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.

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.

Quote from: exchlbg on November 04, 2012, 02:45:49 AM
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.

QuoteAnd 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.

QuoteThis 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.

QuoteSetting 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.

QuoteIs 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.

QuoteAnd 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.

Quote
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.

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.

Quote from: exchlbg on November 04, 2012, 03:41:50 AM
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.

Quote from: exchlbg on November 04, 2012, 03:41:50 AM
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.

QuoteJust 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.

QuoteSo, 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.

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."

Quote from: exchlbg on November 04, 2012, 04:33:12 AM
"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?

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.

Quote from: exchlbg on November 04, 2012, 05:14:40 AM
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.

Quote
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.

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.

Quote from: exchlbg on November 04, 2012, 01:57:21 PM
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.

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.

I am not calling you stupid. I am saying that your insistence on saying that making a techstop route with your HQ as the tech-stop somehow doubles up on demand is rubbish. Because it is. If you equate 'that thing you keep saying is rubbish' with 'you are stupid', then that's a problem on your end, not mine.

If you want to be critical, be critical of things that are actually true.

I don't see what your general point is, because I haven't seen you explain it. Other than "It stays sticky between us concerning that demand/traffic thang." Which you continue to misunderstand & misrepresent, wilfully or not. We both say that any simple option needs to use the existing demand model. I am suggesting something that does use it. You keep telling me it doesn't. You are wrong.

What I see is:

This doesn't make sense because it adds demand not already included in the demand model - Simply incorrect. It would give the ability to create a tech-stop route between two airports you are not based in. Using the existing demand between those two airports. Simple as that.

This won't work because it means far too many extra route calculations. - Also incorrect. It'd be double the existing number of routes at absolute worst.

It's all too confusing. - So don't use it. 7 day schedules are confusing. Micromanaging prices is confusing. If it's too much effort, don't use it. It's not compulsory, it's not required for success. The game's already very simple to succeed at.

I wouldn't get accurate profit for individual planes. - Big deal. Individual plane profit is irrelevant & arbitrary. It is also extremely simple to take this, and arbitrarily split the revenue between the two planes involved however you want to.

It doesn´t make it any better if you repeat insulting people you don´t really want to understand nor to additionally insult anybody not following your point of view."Complicated" was my word for your propose to first implement connection service and then limit it by rules.
And not everybody finding things complicated you deal as easy is necessarily stupid.
I would just ask you now to let it go, it´s going somewhere I don´t want to follow.

Digging up an old topic as I've just dug up the game again trying out the free trial. Did anything ever come out of the possibility to connect passengers?

Thanks for reading!

If the model will cause problem then shouldn't the solution be modifing the model?

And worrying about how it will benefit large airlines is like worrying about the way how real world airlines suceeded with their hub and spoke model

PAX Connectivity.
Manual metod.

There is more simple solution.
Connecting flights only at HQ base airport. Let's say that the new City Based Demand system is fully operational.

Example:
HQ is WAW / EPWA there is a flight CDG - WAW and WAW - GDN.
Lets say fictional numbers on pax demand:
- CDG - WAW 200
- WAW - GDN 50
- CDG - GDN 50 (but not deserved)

50% of CDG-GDN pax will take CDG-WAW then WAW-GDN route.
The % MAY (but not nescessary) vary depending of actual game mechanics and nothing big there to implement.
This will work untill You or opponent will open one day CDG-GDN.
Of course it can be 25% 20% or whatever to make the game balanced.

There should be a room for Alliance co-op also.
New feature - Alliance Connecting route flag. When two of them are flagged, the same as above should be possible.
Let's say one have CDG-WAW (CDG HQ) and I have WAW-GDN (WAW HQ). 

As You are making profit this way without opening a new route, You have to be a little bit penalised, so let's say there will be a new selection in "Route Tab":
- Open Connecting Route
- Manage Connecting Routes

In the "Open New Connecting Route" tab, You will select 2 already existing flagged routes or else you will try to open it as already done and system will find and propose routes.

In "Manage Connecting Routes" you should see same financial system as already exsting one.

So the HQ only routes is better in terms of balanced gameplay. Servers shouldn't be overloaded this way and we could get basic Connectivity feature enabled.

This way I find it a lot easier, efficient in terms of gameplay, it promotes regional airlines or regional routes.
It is more simple to code it and implement as feature (still not easy but possible) more than a complex system, taking in count the servers traffic, workload etc...
That's a micromanagement!

Just saw an essay about a method to calculate connectin traffic percentage in airport annual passenger figure at http://www.dlr.de/fw/Portaldata/42/Resources/dokumente/paper/Maertens_Grimme_Transfer_Rate_estimation.pdf which could be needed to determine how many demand of an airport is really O/D