Started by jamespetts, December 14, 2008, 05:50:16 PM
0 Members and 1 Guest are viewing this topic.
################################Passenger routing################################# Note: the program will generate three groups of passengers: (1) local;# (2) midrange; and (3) long distance. The program will look for a town within# the specified distance ranges for each class of passenger. If it cannot# find such a town within a certain number of tries, it will pick a random town.# The ranges *may* overlap - indeed, this is encouraged.local_passengers_min_distance = 0local_passengers_max_distance = 64midrange_passengers_min_distance = 0midrange_passengers_max_distance = 128longdistance_passengers_min_distance = 0longdistance_passengers_max_distance = 4096# The following are percentage chances. They represent the chances that# any passengers generated will try to find a town within each of the three# ranges, respectively. passenger_routing_local_chance = 33passenger_routing_midrange_chance = 33# passenger_routing_longdistance_chance is 100 minus the sum of the two above values,# but not stipulated individually.# Some passengers who are not able to find a route will be content# to go to an alternative destination. Set the maximum number here.# (Note: whether any given passenger is content to go to an alternative# destination, and, if so, the number, will be random. For each # possible number of alternative destinations, the chances will be even.# For example, if the number is set at 2, there will be an equal chance# of passengers having 0, 1 or 2 alternative destinations).max_alternative_destinations = 3# This is the number of passengers routed at once,# to save CPU resources. Decreasing this number will# make the game run more slowly. Default = 7.passenger_routing_packet_size = 7
Quote from: jamespetts on December 14, 2008, 05:50:16 PMAdditionally, I am keen on the idea of a revenue penalty (a sort of opposite speed bonus) for passengers, mail and goods travelling from overcrowded stations, as well as capping the total number of passengers/mail/goods that can accumulate at an overcrowded station, to make handling overcrowded stations more challenging (the idea being to make it easier to avoid station overcrowding than it is now, but more of a problem when it does occur)
Quote from: isidoro on December 15, 2008, 01:51:26 AMNice ideas. My two cents:What about making the passenger generation rate be dependent on average time to travel to the city instead of physical distance? In olden times, very few people traveled to China from Europe. Now, lots of people do. The key is time, not distance.
QuoteWhat about patterns? Certain people travel to certain places at certain times: go to work, go to eat, go to visit an attraction... Depending on time of the day or of the year, some routes get congested or nearly free.
Quote from: colonyan on December 14, 2008, 06:23:25 PMI'm no programmer so I can't analyse this to the detail butthis is what I was looking for. Either to simulate the commutersthis method is better suited.
QuoteAlternative destination sounds good too.
QuoteThese process may burden the cpu/memory but a conscious playershould be able to control the size of the map and play whitout too muchlagging.
QuoteIt is better if the 64, 128, 4096 tile distance were able to modify through config.
Quote from: jamespetts on December 15, 2008, 08:40:29 PM[...] the way that it works now, the passengers decide which destination that they want to go there before they work out whether there is a route that takes them to their destination: if there is no route, [...]
Quote from: isidoro on December 16, 2008, 02:36:10 AMI can't see the first problem. Whichever is the algorithm used the only thing to do is to substitute space distance with time distance. It applies to your solution as well. When you say 16 tiles apart at most, you can say 2 hours apart, etc. There is an interesting concept in transportation: isochrones: lines in a map connecting equal travel time. Here is a very nice applet for London tube stations here:http://www.tom-carden.co.uk/p5/tube_map_travel_times/applet/Or this figure for train transportation also from London:http://www.dft.gov.uk/144130/185507/262838/figure8_2.gif
Quote from: VS on December 16, 2008, 08:55:10 AMYou beat me to it One idea I had yesterday before falling asleep was: how about adapting the (re-)usable (for us) parts of routing protocols (RIP, EIGRP...) They deal with connectivity and metric, too. Only - which parts are the ones interesting? Maybe it is useless.
Quote from: jamespetts on December 16, 2008, 08:41:10 AMThe problem is, if there isn't a transport link between two towns, there is no way of measuring how long that it takes to get between those towns...
Quote from: jamespetts on December 16, 2008, 08:58:50 AMI'm not sure that I follow... those are computer networking protocols, yes? I do not immediately see how those relate to passenger generation in Simutrans...
Quote from: jbode on December 16, 2008, 10:35:58 AMno connections --> takes "forever"
Quote from: jbode on December 16, 2008, 02:03:55 PMSorry James,in the words of economics it is "forever", therefore costing "more than anybody can spend" truly makes the places unreachable - thus people unhappy. This is why Simutrans show the "unhappy" passengers. I don't understand your suggestion as to remove those. What I understood that you want a different balance of short, medium, long distance and the not reachable places (the forever unhappy people whining that nobody takes them to heaven/mars/Paris or where ever you think of). This is a very good and useful plan.The "takes forever" was written more in the context of the suggestion of "isochrone mapping" ... I like this idea too. imagine you select a city on the map and you can see where the people/post can go to in a certain time. also show places where there is no connection to ...
QuoteThe aim of this patch is to effect a subtle but hopefully important change to gameplay and, consequently, strategy. At present, the game is really very hard in the first decade or so (especially for making a profit from passengers), but, once a certain threshold is passed in terms of the number of towns connected, the game suddenly becomes very easy, and making money ceases to be a challenge. The reason for this is because, because the numbers of generated passengers have their destinations fairly evenly spread throughout the map (albeit subject to the slight local preference indicated above), a linear increase in the number of connected towns will result in an exponential increase in the number of passengers who are able to get to their destination. I find that this makes the game too imbalanced: it is too difficult at the beginning, and too easy later on. What is needed is a way to reduce the rate of increase of the number of passengers carried with every added connexion. Increasing the preference for local towns will go some way towards doing that.
Quote from: prissi on December 16, 2008, 10:49:58 PMThe patch could be certainly made more efficient by an array of all town within range for a certain town (needs to be updated only when cities are constructed or deleted).
QuoteApart from that:You patch make the beginning easier (the only part with a little challenge) and then you make the later game even more easier (the part, where the challenge needs increasing) by flooding long distance networks even more. Generating more local passengers will certainly reduce the revenue on long distance, but then why make it dependent on pak_transported? (And even more, to this number all AI and even just building stations will contribute.)
Quote from: prissi on December 16, 2008, 11:44:31 PMYou patch use pax_ratio, which is low at the beginnign but increases during the game, the higher the more pasenger are transported. Thus the local constrain is eased. As a result, mor long distance passengers will appear. Or am I wrong?
Quote from: prissi on December 16, 2008, 11:55:46 PMAh, ok my fault. However, with you definition of pax_routed, only buildings producing more than 3 passengers will profit from the routine. This will be fewer at the beginning ...
Quote from: jamespetts on December 16, 2008, 11:35:31 PMAn interesting thought, although I'm not sure that I know enough about the depths of the code to do that within a sensible time unless assisted.
stadt_t::stadt_t(spieler_t* sp, koord pos, sint32 citizens) : // Is called when a city is created.void stadt_t::laden_abschliessen() // Is called after loading, when all cities are loaded.stadt_t::~stadt_t() // Is called when a city is deleted (Did this ever happen ingame, except when quitting the game????)
Quote from: prissi on December 20, 2008, 10:30:26 PMPlease, keep related discussion in a single topic. Thank you.