News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

[Patch] Passenger generation (revised - UPDATED 5 Jan 2009)

Started by jamespetts, December 14, 2008, 05:50:16 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

Attached is a patch to change, and, I hope, enhance, the system of passenger and mail generation in Simutrans, in respect of the choice of destination city. The current system works like this: each city generates a certain number of passengers, checks to see whether a stop is in range, and, if it is, gets a random city as its destination (if the city is more than 120 tiles away, it tries again, therefore very approximately preferring more local cities), then checks to see whether the stop has a route to the destination, etc.

This patch is aimed at increasing the chances that passengers will find a local, rather than a distant, city as their destination: the number of passengers waiting to be assigned are split into three roughly equal groups. The first looks for a city within 64 tiles (if the returned random city is more than 64 tiles away, it asks for another one: to prevent infinite loops, if it has done that unsuccessfully 32 times, it returns any city, even if more than 64 tiles away), the second for a city within 128 tiles, and the third, a city within 4096 tiles (each using the same method).

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

If passengers and mail are generated at the same rates, but more strongly prefer local destinations, then, as local destinations will be easier and more cheap to connect than distant destinations, players will have more passengers and mail to transport near the beginning of the game, but the rate of increase as more and more distant destinations are increased will reduce. If the overall number of passengers is reduced slightly (easily achieved by editing the setting in simuconf.tab), then the difficulty at the beginning will be either the same as at present, or slightly lower, but the game will not then become easier at quite the rate that it does now.

I note above that this patch is only a partial solution to the problem: a second solution would be to give one third of passengers one alternative destination, and one third of passengers two alternative destinations, to which each will travel if there is no route to their chosen destination. This is realistic, in that people often go to a town not for something that that town has uniquely, but for something that is present in a number of towns, and people really would go to an alternative town if a route to their chosen town was not available. In gameplay terms, this would have the effect of far more greatly flattening the growth of passenger numbers over the cycle of the game than a simple preference for locality.

I have not yet written the code for that, as that would be somewhat more complicated, and I should like to see people's thoughts on this patch first; however, I am looking into doing that soon. (The plan at this stage is to have people who travel to alternative destinations be counted as happy/unhappy rather than "no route", and for the fact that they are going to alternative destinations to be invisible to the player, just as it would be to a real transport network planner; but, if anyone has alternative ideas, I should be interested to learn of them).

If, overall, the growth of passenger numbers as more towns are added can be flattened somewhat (obviously, not too much, since the whole point of the game is to acheive success by building networks), the overall passenger generation level could be reduced whilst retaining approximately the same (or even, a somewhat lower) level of difficulty at the beginning of the game. This would, in turn, make it far easier to avoid overcrowding in the later part of the game (when the player has a large network), but, conversely, it would be incrementally harder to make newer lines generate a profit. Additionally, 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).

Any feedback would be most welcome!

Edit: (5th of January 2009) I have now revised and updated the patch to work with the new translations in the code. This patch is up-to-date for nightly r2218. The patch itself no longer includes the simuconf.tab file, because my simuconf.tab contains settings irrelevant to this patch and that might interfere with other people's settings. Instead, I reproduce below the section that needs to be added to the simuconf.tab file in order to make this patch work properly:

################################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 = 0
local_passengers_max_distance = 64
midrange_passengers_min_distance = 0
midrange_passengers_max_distance = 128
longdistance_passengers_min_distance = 0
longdistance_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 = 33
passenger_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
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

colonyan

I'm no programmer so I can't analyse this to the detail but
this is what I was looking for. Either to simulate the commuters
this method is better suited.

Alternative destination sounds good too.

These process may burden the cpu/memory but a conscious player
should be able to control the size of the map and play whitout too much
lagging.

It is better if the 64, 128, 4096 tile distance were able to modify through
config.

jbode

Quote from: jamespetts on December 14, 2008, 05:50:16 PM
Additionally, 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)

Think that this is a good plan ...

I have one problem with capping the overcrowded stations: it renders the problematic stations to a cryptic status at the moment.

Those station should get an additional flag like "rejected passengers/goods". This would help the network designer (player) find out where problems are hidden.

Jörg

isidoro

Nice 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.
  • What 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.

jamespetts

Quote from: isidoro on December 15, 2008, 01:51:26 AM
Nice 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.

I understand the point, but there are some difficulties with that approach. Firstly, 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, they simply don't travel. The idea of that is that the player is incentivised to build transport connexions to places where people want to go, rather than, as with Transport Tycoon, people being happy to go wherever there happen to be transport connexions. That then has the effect (known as the "network effect") of increasing total ridership on existing routes when new towns are connected. That effect is desirable to some extent, but its effects can on occasions be too extreme an exponential growth. The idea that I posted here, and plan on coding, is designed to mitigate the worst excesses of the network effect whilst still preserving its best features. The second problem is that, as a matter of mechanics, there is, as far as I am aware, no code in the program to measure the journey time. Such code might be computationally expensive, reducing the performance of the programme. Certainly, it would require quite a substantial additional amount of coding, and would considerably alter the present model of calculations.

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

This might work for tourist attractions (if there was some specification in the tourist attraction's own data file about the months of the year during which it is popular: a ski resort in the winter, a beach in the summer, an indoor museum all year around), but it would not really work for rush hour, since the game's timing model does not allow any variation in service patterns over the course of just a few hours to be simulated satisfactorily.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

Quote from: colonyan on December 14, 2008, 06:23:25 PM
I'm no programmer so I can't analyse this to the detail but
this is what I was looking for. Either to simulate the commuters
this method is better suited.

I'm glad that you like the idea :-)

QuoteAlternative destination sounds good too.

I will be working on that next.

QuoteThese process may burden the cpu/memory but a conscious player
should be able to control the size of the map and play whitout too much
lagging.

In my very brief tests, I have not noticed a problem. I have not tried it yet with a large map, however.

QuoteIt is better if the 64, 128, 4096 tile distance were able to modify through config.

I have just finished programming that now :-) I will not upload that, however, until I have done the alternative destinations (which is harder), and then I will put it all in a patch together.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

isidoro

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, [...]

I 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

Regarding the complexity of getting the statistics, it all depends on how is the grain size.  They can be statistics considering stations, considering big areas in the map, considering cities, considering schedules or lines, etc.  Stations would be the best alternative, since directly connected stations are only a few.  Passengers in present implementation traveling to a distant place can be made to desist if too far in time...

But if done exactly, it can be too much data, I agree.

jamespetts

Quote from: isidoro on December 16, 2008, 02:36:10 AM
I 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

The 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...
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

VS

#8
You 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, OSPF...) ;D They deal with connectivity and metric, too. Only - which parts are the ones interesting? Maybe it is useless.

EDIT: links.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

jamespetts

Quote from: VS on December 16, 2008, 08:55:10 AM
You 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...) ;D They deal with connectivity and metric, too. Only - which parts are the ones interesting? Maybe it is useless.

I'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...
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jbode

Quote from: jamespetts on December 16, 2008, 08:41:10 AM
The 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...

no connections --> takes "forever"

During my last years at University I had been dealing with Operations-Research problems ... There are interesting problems to find the "best" routing. Most of the time you will have to restrict your efforts to "good" as "best" will lead to too much cost for that calculation ...

That applies to network routing also. You will never get the certainty that all the packets we send around take the same path.

The idea of isochromes to validate the passenger routing on a Simutrans game is great, but might be a little difficult to calculate. What could we use? The best connected stop of a city or the worst connected one ...

VS

Quote from: jamespetts on December 16, 2008, 08:58:50 AM
I'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...
It was in reaction to isidoro's idea about travel time.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

jamespetts

Quote from: jbode on December 16, 2008, 10:35:58 AM
no connections --> takes "forever"

The problem with that is that it would mean that all or most passengers would have as their destination a town to which there is a transport connexion. The way that Simutrans has conventionally worked is that where passengers wanted to go did not depend on where the transport networks happened to be. The idea of alternative destinations is to give a small amount of additional flexibility (people do not always have only one, singular destination in mind), whilst still retaining the general principle that passengers have their own idea of where they want to go, largely independent of where transport companies are willing to take them.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jbode

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

jamespetts

Quote from: jbode on December 16, 2008, 02:03:55 PM
Sorry 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 ...

Ahh, in which case, I think that we've been misunderstanding each other. I am not suggesting getting rid of the unhappy people - the unhappy people are an important part of the game. (In fact, there is a distinction between "unhappy" (there is a route, but the station is too crowded) and "no route" people: both are an important part of the game).

But I suspect that calculating the distance to each destination before deciding which destination to use will be very computationally expensive. Indeed, there is a specific warning in the code comments in that section about using the route-finding algorithms any more than necessary, or altering that part of the code at all, for that reason. The current system grabs a random destination and, if it is more than 120 tiles away, has one more try. My revised system in the patch grabs a random destination and has up to 32 extra tries if the destination is not within the distance range specified (passengers are split into three groups for that purpose, each with their own destination range). What I will be doing next is giving a third of passengers one alternative destination, and a further third of passengers two alternative destinations, so that the chance that passengers will find a route is higher (but only higher by a limited amount).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

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.

The 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). Apart 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.)

jamespetts

Quote from: prissi on December 16, 2008, 10:49:58 PM
The 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).

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

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

I am having some trouble understanding you here. Firstly, I am not sure why this patch would flood the long-distance networks in the later part of the game more than at present: surely if a higher proportion of the passengers preferred local travel, the long-distance networks would be emptier, not fuller? Or have you spotted something in my code that means that it does not have the desired effect?

Secondly, what do you mean here by making it dependant on "pak_transported"? I have searched the code, and cannot find any reference to "pak_transported" anywhere. I should be very grateful for any clarification.

I certainly did not intend my patch to have the effect of increasing long distance passengers when the networks are more complete at the later stage. The ultimate idea is to increase the proportion of passengers that travel locally (and, using the alternative destinations system that I have just coded (no patch yet), increase the probability that passengers will choose a destination that is network connected, rather than not network connected), so as to make it possible to reduce the overall passenger level whilst not making it any harder at the beginning than it is now, but making it more challenging for players when their networks are more mature compared to the present position, in a realistic way. If my patch (and my forthcoming alternative destinations patch) does not acheive that, then I have done something wrong with my coding, and I'd be very grateful if you could help me to understand where my mistake is.

I have not yet had a chance to test my new code properly (I have only tested it enough to see that it does not crash the game), so I shall have to see in due course what effect that it has on revenues with different sizes of network, map, passenger generation numbers, etc.. Thank you for looking into this and replying; I should be interested in any further input.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

You 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?

jamespetts

Quote from: prissi on December 16, 2008, 11:44:31 PM
You 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?

I'm afraid that I still don't understand, since I can't find "pax_ratio" in the code, either (using search>entire solution on Visual C++ Express).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

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

jamespetts

Quote from: prissi on December 16, 2008, 11:55:46 PM
Ah, 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 ...

Ahh, yes, good point. I have already changed the algorithm to reduce the packet size if the number generated is less than three times the size of the packet (to enable them to be divided into three easily), and made the packet size customisable in simuconf.tab. Perhaps, instead of breaking down the passengers into equal thirds, I should randomise which passengers use the local, mid-range, and long-distance ranges, with an equal chance of each?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

gerw

Quote from: jamespetts on December 16, 2008, 11:35:31 PM
An 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.

You can to do this in

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????)


I have coded a template for sorted vectors, maybe you can use this (You can define a new data structure consisting of the distance to your town and a pointer. If you define now "<=" and "==" for this structure you may use my template). I will upload the template soon.

jamespetts

This is a revised version of my passenger generation patch, the original of which was posted here. I have added code for alternative destinations, changed the system of allocating passengers to local, midrange and long-distance (by using weighted random assignment, rather than even division), and made most of the settings configurable in simuconf.tab. I have tested this fairly thoroughly (up to r2173): the code compiles, the game runs without crashing, performance is acceptable, and the program seems to function as intended with the patch applied. I also attach a sample simuconf.tab file (for pak128) with the necessary settings at useful values.

The overall effect of this patch will be to flatten the passenger generation to number of cities served ratio: in other words, the increase in passenger numbers for each additional city added to the network is not as great as before because passengers will tend to prefer destinations that they can reach by a transportation network because of alternative destinations (i.e., passengers will have between 1 and 4 destinations (the maximum number is configurable), and, if their primary destination is not transport connected, they will iterate through the rest of the destinations until they find one that is transport connected, and will then travel to that destination and only show "no route" if all four destinations are unavailable. The behaviour of the current official release can be preserved by setting "max_alternative_destinations" to 0, or alternatively by not having a "max_alternative_destinations" line in simuconf.tab at all).

With the passenger level unchanged compared to the default code (16 is the default), it will mean more passengers in the early game, and just as many in the later game. Given that that is not the intention of the patch (the intention is to make passenger numbers more manageable in the later game without making the early game too hard), it is recommended that, with this patch applied, the passenger level is reduced. I have not tested the optimum level extensively, but something around 8-12 should probably be adequate. The attached simuconf.tab has the passenger level set to 10. The effect of the patch with the passenger level reduced is that the number of passengers riding on a player's early networks is likely to be more or less unchanged from the present, but that number will not increase as rapidly when the network gets larger. Passengers also have a stronger preference to travel to local destinations than with the default code, and that is now customisable in simuconf.tab. An interesting side effect of the alternative destinations code will be that it will be easier for a competing transportation network to reduce the number of passengers travelling on one's own network by connecting them to a destination higher in their list of alternatives than is presently served.

Note that the code and simuconf.tab contain options for another patch relating to the speed bonus and obsolete running costs: those are redundant in this patch and can be ignored (I was not clear on how to be selective in what parts of the modified code are added to a .patch file). The redundant parts are small and should make no difference to how the game performs.

I should be very grateful for any feedback on this patch.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

Please, keep related discussion in a single topic. Thank you.

jamespetts

Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

I have now revised this patch and updated it to take account of the new translations in the code. Details in the original post.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.