Here is a list of ongoing, planned and some past coding projects for Simutrans-Extended (i.e., those that have been completed since this list was first started). This post is intended to serve two purposes: (1) to enable discussion of the implementation of these projects; and (2) to give information to people willing to assist with the coding what they might get involved with. I shall update this post periodically with progress on the various projects. If anybody would like to assist with any of these projects, please post on this thread.
I give a brief description of all of the projects below. I have some specific ideas as to how to implement these features, but if anyone would like to help with implementing them, whoever assists might want to put forward an alternative implementation.
Projects marked with [*B]
are projects that are balance critical (i.e., those that must be completed before paksets will properly balance, and are therefore considered a priority). Projects marked with [*S]
are very simple projects that will not take a great deal of time, and might be suitable for a relatively inexperienced programmer, someone new to the Simutrans code, or somebody with very limited time.
A list of updates to this list with dates is shown at the bottom of this post, although this may be incomplete. Usage based vehicle maintenance costs [*B]
Another suggestion by Moblet, the idea is that vehicles would cost more per kilometre to maintain the more kilometres that that they have accumulated to simulate the fact that vehicles wear out and become less reliable. It has been suggested that the increase not be linear, but rather follow a "sigmoid curve" (i.e., an S-shaped curve), increasing slowly initially, then increasing more quickly, before slowly flattening out to a cap specified in the .dat files. We need, I think, at least two parameters in the .dat files: the maximum maintenance cost for a vehicle, and the number of kilometres that the vehicle has to travel before reaching that maximum cost.Vehicle overhauls [*B]
Just as ways need to be renewed from time to time, so do vehicles need to be overhauled. This would represent a recurring large capital cost that would have the effect of making the cost of maintaining vehicles non-constant over their life. The idea would be to simulate only major overhauls, i.e., those that vehicles have only two or three (or perhaps four or five for long-lived vehicles) in their lifetimes.
At its simplest, this could just be dealt with by two figures in the .dat files: an overhaul frequency (in kilometres, not time) and an overhaul cost. The overhaul cost would then automatically be debited after the specified number of kilometres had expired. It would probably need to be a bit more sophisticated than this, however, as players might want to defer an overhaul to wait for the vehicles to be replaced by something better (in which case, overhauling them would be wasteful). There must be some cost to deferring an overhaul, however, or else players would always defer overhauls, and an increased maintenance cost of vehicles overdue for overhauls would seem to be a sensible way of doing that. Also, at overhaul, the vehicles should update themselves to the latest available livery in the current scheme, or, if there are no available liveries in the current scheme, pick a scheme in which a livery is available, and update to that (this should be quite simple to do; I could add this part if that would be easier).
Similar GUI considerations apply to this as to the way renewals.Convoy re-combination [*B]
Currently, the configuration of a convoy can be changed only in a depot manually by the player, when it is not in service. In reality, convoys (especially railway trains, especially before the late 20th century) frequently change their configuration when in service, for example by changing from a steam to an electric locomotive to travel over an electrified section of track. For reasons discussed here
, allowing this to be done is of some importance for game balance.
Quite how to implement this will need careful consideration: it should not be too difficult for players to organise, yet it ought to be realistic. It will have to fit into the new signalling system realistically (perhaps by allowing call-on aspects). The most difficult implementational issues will be semi-automation and scheduling: how should a player control how this works and how much should be partially automated? How will a player control a semi-automated system; how will a semi-automated system work without easily getting stuck/deadlocked?
This could well work in conjunction with a system in which convoys must regularly visit depots for maintenance; a semi-automated system could perhaps then determine that a schedule requires a convoy at a particular time, and assemble one from vehicles waiting for use in the depot according to pre-set rules. This might end up being rather complicated, however, so consideration will need to be given to how and to what extent that this can be made workable. Depot visits and availability [*B]
Currently, convoys visit a depot only when they are purchased new, when they are retired, when they are manually altered by the player or when the replacer function is used. The idea of requiring regular maintenance in depots (rather than just abstracting the concept as a maintenance charge) has not found favour in the past because this is thought to require too much micromanagement.
However, this needs to be reconsidered on two accounts. Firstly, from an economic perspective, if we are to use realistic maintenance costs (i.e., costs based on historically researched values), the maintenance cost itself will not then take account of the fact that, as well as costing money whilst being maintained, the vehicle also cannot be used to generate revenue during that time. The amount of time for which a vehicle needs to be maintained can vary with how well worn that it is, and can also vary greatly from vehicle to vehicle, as can the degree of decay in this value from new. How much time that a vehicle can be used for revenue earning purposes as opposed to being maintained is known in the transport industry as "availability", and is usually recorded as a percentage. Historical data are available for availability percentages for quite a large number of vehicles. Simulating availability is an important thing to do to achieve a realistic economic balance.
The second account on which the historical reluctance to have depot based maintenance simulated ought to be reconsidered is that there is a sufficiently straightforward yet sophisticated means of simulating this without the need to indulge in excessive micromanagement. Assuming that each vehicle has an availability percentage, the time spent in revenue earning service since the last visit to the depot can be measured (or perhaps the time spent estimated from the average speed and distance travelled), and the time spent in the depot calculated accordingly. For example, for a vehicle with a 90% availability rating that has spent 10 hours in revenue earning service, it would have to spend 1 hour in the depot being maintained once it visited the depot before being released to revenue service again. Maintenance could not be interrupted once it had started.
This mechanism means that players should be freed from the need to ensure that the vehicle is sent to the depot at any specific time, so long as the vehicle visits the depot at least once a year (for example) to prevent players never sending the vehicle to a depot at all. A depot visit could just be a part of the timetable, with a parameter that the depot is to be visited only once in every X times that the convoy reaches that point in its timetable, the convoy simply skipping that entry on other occasions.
This regular call to a depot will then make overhauls, replacements and upgrades much easier, as these can simply be performed on the convoy's next routine visit to the depot rather than (as is currently the case for replacements) convoys going to the depot all at once, which players report can cause considerable disruption and be difficult to manage.Variation of costs and revenues over time [*B]
A significant economic factor affecting transport (and many other things besides) has been price instability: the increase in the cost of labour over time is the most significant example, but there are others. This has had profound impacts on transport over time: tram networks which had been profitable in the 1910s and 1920s became unprofitable in the 1930s because of the increase in labour costs, and this loss of profit was a great incentive in the switch to trolleybuses, which had much lower overheads, as there were no rails to maintain. Similarly, steam traction on railways became prohibitively expensive to run in the 1950s and 1960s as a result of this dynamic, whereas before the Second World War, it had been possible to run a highly profitable rail network using only steam traction. As a result of the increasing prominence of labour costs in all overheads, the tendency has been over the decades since the middle of the 20th century to buy more and more expensive and sophisticated equipment, which, by virtue of that sophistication, needs less labour to operate; previously, it would have been more economical to have used simpler and cheaper equipment and employed more staff.
Also, inflation itself is a worthwhile thing to simulate: it would be highly unfortunate if a transport company could build up a small fortune in the 1790s with a canal network, shut down in 1830, wait dormant with a treasure trove of cash in the bank accumulating interest until about 1960, and then start an enormous airline. Inflation gives players due incentive to put their capital to good use.
The best way of simulating these things, I think, is to use the existing .tab file system to have a set of time-based (percentage) factors for prices specified in a "prices.tab" file. Without a prices.tab file, prices would work as they do now: being fixed in amount throughout the game, and taken directly from the .dat files, adjusted for the meters per tile and bits per month settings as appropriate. A prices.tab file would contain a line for each type of item (for example, "monthly_canal_maintenance" or "per_km_vehicle_maintenance_diesel") together with comma separated pairs of years and percentage factors. At a percentage factor of 100, the base prices would prevail: at a factor of 200, twice the base price would prevail, and at a factor of 50, half the base price. These values would vary over time according to the dates specified, and would be tapered automatically between the specified points (so, for example, if the .dat file provided, "1750, 50, 1850, 200", the value in 1800 would be extrapolated as 100). There would need to be a new menu item (perhaps grouped with the lists) to show these price factors now, last year, 5 years ago and 10 years ago (or possibly at any arbitrary time between now and the game start date) so that players can see the effect of inflation. Each month, the inflation adjusted prices for each of the various types of price bearing items (goods, ways, vehicles, buildings, etc.) would be recalculated based on the most up-to-date value calculated from prices.tab. Vehicle replacer enhancements
The current replacer has some unfortunate limitations. A number of things need to be done, I think, none of which are particularly complicated, but which I have not had time to do as yet. Some of these things would impact on depots, too.
Firstly, cascading does not work properly because it is not possible to order out of production vehicles in the replacer even though there might be such vehicles in one's depots somewhere. My idea of how to fix this was, in effect, to combine all the depots so that all stored vehicles available at any one depot of any player are also available at all other depots of that player, and also available for use by the replacer (and shown in the same way in the replacer window as in the depot window, with little white numbers next to the vehicles to show how many stored examples are available). There would then be no need to implement brain-bendingly complicated algorithms to try to work out to which depots that replacing convoys should be sent so as to take advantage of existing vehicles.
Secondly, replacing can cause too much disruption to people's networks as lots of convoys go back to the depot all at once. Two possibilities exist to deal with this. The first, and simplest, is the solution preferred by SDog - remove the requirement for convoys to visit depots at all to replace. This makes things simpler, but might be said to simplify things a bit too much, as buying new vehicles always requires a depot. The other way is to defer replacement of some convoys until others have finished their replacing, either by specifying a specific point in a convoy's schedule of where it should replace (although I anticipate this being tricky from a GUI perspective), or specifying a maximum number of convoys to be replaced at a time. Any of these solutions would be better than the present arrangement, however.
Thirdly, a small change: all convoys with the same vehicles as each other in any order need to be treated as the same, rather than requiring, as now, that the vehicles be in the same order. Finally, there is demand for a feature that allows replacing of all convoys on a line without regard to their composition. Interaction between replacer and overhauls
If vehicle overhauls are implemented, it will often be the case that it is most economical for a player to replace vehicles just as they become due for overhaul, rather than either overhaul them or replace them sooner. A simple way of doing this would be to have a new replacer option, "replace instead of overhaul", which would mark the vehicles for replacing, but only actually replace them when they were due for overhaul. Careful consideration would have to be given as to how to deal with trains, where one would not necessarily want to replace the entire convoy just because one of the carriages needed an overhaul (and were replacing just one vehicle might not work because of coupling constraints). Various options (such as: replace when any one vehicle requires an overhaul, replace when all vehicles require overhauls and defer overhauls, or replace when the locomotive requires an overhaul) is the only satisfactory way of which I have yet thought of dealing with this, but suggestions are welcome.Second-hand market in vehicles
Players should be able to buy and sell vehicles from each other. At its simplest, this would simply involve changing the existing "sell" option in the depot window to two options: (1) "put up for sale" and "scrap". "Put up for sale" would make the vehicle available for sale to all other players for either a pre-calculated price or a price specified by the seller. The vehicle would remain in the possession of the selling player until another player bought it, and the selling player could withdraw it from sale at any time (thought would have to be given as to how to list vehicles being offered for sale in the GUI: this will be easier when the depots are pooled, as suggested above). Vehicles sent for scrap would be disposed of straight away, and a small amount (a percentage of the vehicle's purchase price, default 5%) paid to the player. Players could buy second-hand vehicles from the depot or replacer windows by selecting a new option from the "buy/sell | upgrade" menu, "buy/sell secondhand" (alternatively, this menu might be redesigned a little), where all secondhand vehicles offered for sale by all other players would be displayed. They should be shown in whatever livery that they currently have, and the information should include the number of km that the vehicles have travelled, their current maintenance cost (having regard to their level of previous use, as described above) and the number of kilometres to and cost of their next overhaul. Network optional insolvency [*S]
The current system of dealing with insolvency in Extended was designed with single player games in mind. Proper liquidation, as in Standard, is needed for network games. What would be helpful in this regard is if there could be a third option for the current "allow_bankruptcy" switch: if one sets "allow_bankruptcy=2", then "bankruptcy" (winding up/liquidation) is enabled only in network games, but not in single player games (where it is less useful). Cost of capital
Currently, players start with a large lump sum of free money. This under-estimates the cost of capital. Players should start either with nothing or a very small lump sum, and have to/be able to take out long-term loans to invest. The exact implementation of this is not so important, and there are many workable ways of doing it. One idea is to have bonds in a similar fashion to Railroad Tycoon, where a company could issue a bond for a certain period of time (say 1 year, 2 years, 5 years and 10 years, with the longer bonds having a higher annual rate of interest) if the company's credit rating was sufficiently good (some consideration would need to be given to how to calibrate this: poorer credit ratings should result in higher interest rates, and, if sufficiently bad, no bond issuing at all - new players should start with a moderate credit rating, such that they are able to borrow, but at fairly high rates), and would have to repay it in a lump sum at the end of the period. Another possibility would be a simple bank-loan, repayable in instalments starting a month after the loan is taken out (or perhaps with a three month repayment holiday) - this might be easier for a player to budget for.
Some careful consideration would have to be given to the GUI for this, as there would be quite a bit of loan/bond specific information to display: the number of loans taken out/bonds issued, the dates first taken out, the dates of repayment, the rate of interest, a control for borrowing more, a control for repaying early (at a penalty, perhaps), and so forth. A new dialogue box would probably be needed, accessible by pressing a new button in the finances window. The cost of loan/bond repayments would need to be represented by a new graph in the finance window.
Another issue is how to set a credit limit for a newly formed company or one that has not traded for very long. One good idea is to make this in part dependant on the weighted (by net wealth) aggregate success (measured by profit as a proportion of assets per annum) of other existing transport companies that have existed for some time (if available). This would have several features: it would allow players entering multi-player games late to displace dominant players more easily (as they would have access to more capital if a dominant player were very large and very profitable), and would also replicate to an extent the railway and canal manias of years past. If recent insolvencies were also taken into account negatively (weighted again by net wealth), it would also emulate the converse. There should be a minimum, however, below which the amount of credit available to a starting player will not fall, which should also be the default when starting a new map without other players.Takeovers, mergers, insolvent administration and solvent liquidation
Although I don't think that implementing a stock market is a good idea (Simutrans has a different focus to Railroad Tycoon), allowing a simplified form of takeovers and mergers is a good idea for multi-player games, I think.
A merger should simply be when two players mutually decide that they wish their transport companies to merge into one, controlled by both players (just as multiple players can simultaneously control a transport company now if they both use the same password, or the account is not password protected). If one player requests a merger with another player, and the other player accepts, then all the assets of both players should become owned by the player with the lowest player number, the higher number player should be reset to a neutral state, and either password used to access either of the two previous companies should be useable for the new company (or, alternatively, if it is not feasible to have two passwords for one company, all clients playing as both merging companies should be sent a game message showing a new password which will in future apply to the new, merged company).
A takeover should occur either by mutual agreement, in the same way as a merger (except that whichever player is taking over the other player retains its identity even if it has the higher player number, and there is no change of password), or when a company is in insolvent administration.
A company should be in insolvent administration for a fixed period set in simuconf.tab (default: one year) instead of being liquidated whenever it is insolvent ("bankrupt" in Simutrans-Standard terminology). Within that time, it can be taken over as a going concern by any player (who will take on all of its assets and liabilities), or liquidated at the end of the period. There should be multiple options for liquidation, selectable in simuconf.tab: full liquidation, in which all infrastructure simply disappears, but vehicles are placed on the secondhand market (see the feature description above) for a fixed period (default: 1 year), after which they will be withdrawn, presumed scrapped; mothballing liquidation, in which vehicles are placed on the secondhand market as before, but the infrastructure is replaced by mothballed equivalents (see the mothballing feature above - some consideration will need to be given to what to do with stations - have a system for mothballing them, perhaps; preserve them as they are, or remove them?); and nationalisation, where the infrastructure is taken over by the public player (vehicles again are sold on the secondhand market).
The idea of solvent liquidation has been proposed
: this would allow players manually to liquidate all of the assets of their company instantly (perhaps mothballing all ways and placing all vehicles on the secondhand market and/or scrap them - consideration will have to be given to whether the player should be given a choice in this and, if so, how to exercise it) and retain the identity of the company and all of the cash in its bank account as well as the cash from selling assets. This should probably only be possible where the company is balance sheet solvent (i.e., has a net worth of greater than zero). Private road traffic simulationNote
: This feature will need more careful consideration following investigation some years ago into the performance impact of this on larger maps: see here
for a description of the problem and a discussion of the solutions.
This will be a particularly large (but also potentially satisfying) project. The idea is to have private cars shown in the game actually follow routes from their origin to their destination, such that congestion along particular routes can more easily be simulated, but without creating so much CPU load as to make the game unplayable. This was discussed here
, and the description below is reproduced from that thread.
This idea is loosely based on the way in which the people who made Sim City 4 dealt with the problem of it being too computationally expensive to calculate lots and lots of routes through a relatively complicated network constantly: to have fixed private car routes from specific origins to specific destinations which are updated only periodically.
In the game as it currently stands, unless one turns assume_everywhere_connected_by_road on, the game will in any event calculate routes between each city and each other city, and also between each city and each industry and each attraction, but discard the actual route tiles once the average time per straight line tile for the journey is known. I had considered simply using these routes, but realised that this would not be effective for journeys inside cities, or where cities are close together, such that the distance between two cities is less than, equal to or not much more than distances within the cities.
What would be better would be to have fixed routes to a particular destination cities, attractions and industries stored in tiles individual tiles. Only one route to a particular city (including the city in which the tile is located), industry or attraction can start at any given tile. These routes are renewed periodically, and the particular part of the destination city at which the route ends is selected randomly. The rate of renewal would be set by a parameter in simuconf.tab. Whenever a private car journey is required from a particular start tile (passenger journeys - even in Standard - always originate at a particular building, not station), the system would perform a search of a predefined number of surrounding tiles (the radius being set by a simuconf.tab parameter). If a non-obsolete route is found to the destination city, industry or attraction, then that route would be used. If not, a new route would be calculated. If no route at all could be found, the destination would be marked as unreachable in the surrounding tiles so as to prevent multiple repeated failed searches consuming excessive computational power.
The cars would then all drive along the route to their destination. The number of cars would be based on a reworking of the existing "traffic level" simuconf.tab parameter, which would be reworked so as expressly to become a private car occupancy rate setting, and the number of car journeys adjusted accordingly. It would probably be better for the "traffic" graph in the city then to show only outgoing cars, so that players can more easily use it to tell what proportion of people from that city use the car to get to their destinations (making it comparable with the "transported" and "passengers" graph).
Congestion would be calculated differently to the present system: every road tile would record the time in the current and previous month that road vehicles have been stationery upon it. The congestion in a city would be calculated by adding up all of the values for road tiles within that city and normalising them, probably based partly on constants set in simuconf.tab.
Further, journey times would also henceforth be based on actual recorded journey times by the private cars completing their routes (each would store their journey start times, and would register their total journey time on completing their journeys). For cases in which no private cars have yet completed the particular journey, the time would be approximated in a similar fashion to the way in which it is approximated now. The actual routing mechanism (both for city cars and player vehicles) will take into account the congestion on each tile when calculating the best route. It will probably be possible to create an overlay map, much as in Sim City, showing congestion per road tile as various colours.
That way, congestion will be simulated as accurately as the power of contemporary computers allows: congestion measurements in cities will be based on actual traffic jams, and roads will become congested with actual cars based on their actual usage, simulated accurately. There will be incentive to alleviate congestion along specific routes by upgrading roads (the role of the public player being thus enhanced), and player vehicles will both contribute to and suffer from congestion in a realistic manner.Waiting time limits and stop facilities
Currently, mail and goods can wait an unlimited amount of time at any stop. Passengers and goods with a non-zero speed bonus will terminate their journey early if they have to wait too long (which prevents infinite accumulations), but the amount of time that passengers will wait has no relationship to the type of stop: passengers will wait as long at an airport as at an unsheltered 'bus stop. Stop extension buildings are available in Pak128.Britain for different types of goods, but the differennces between, e.g. a coal bunker and a warehouse or cattle pen are merely cosmetic.
A good enhancement would be to allow stop and stop extension buildings to specify maximum waiting times for each category (i.e., passengers, mail, bulk goods, piece goods, etc.). This would allow the 'bus stop to be differentiated from the airport terminal. The overall stop would have the highest maxmimum waiting time of the individual tile with the highest maximum waiting time. The path finding system would be modified such that no passengers, mail or goods would be able to be routed over a stop where the expected waiting time exceeds the maximum waiting time. At the beginning of every month, every stop with a waiting time for any given convoy or line that exceeds the stop's maximum waiting time should display a warning message for the player whose stop it is. This would allow differentiation for goods: all basic goods stations, for example, might specify a zero waiting time for livestock, requiring livestock pens (which would have a non-zero waiting time for livestock) to be used in order to handle livestock at the station in question.
Furhter, stop extension buildings (e.g. hotels, tea rooms, etc.) ought to be able to earn revenue for every passenger that waits in excess of a certain time. This should not be cumulative: i.e., only one wait based unit of revenue ought to be able to be earned per passenger per stop. This should be based on the tile that gives the highest revenue for which the wait time in question is eligible. This should be based on the actual wait time on departure, not the average waiting time for departures for that convoy or line. Public player finances and taxation [*S]
It would rather add to the game if the public player had a limited budget and a means of raising finances. The best way of doing this is to apply the same credit limit (but not insolvency) rules to the public player as to other players, but allow it to raise money by taxation. Taxation would (1) take a certain proportion of players' profits (discussion is welcome on how exactly "profit" should be measured here); and (2) reduce the growth of all cities on the map proportionate to the rate of taxation levied.
The GUI should be fairly simple: there will need to be a new "tax" graph in the finance window showing (for private players) taxes paid and (for the public player) the tax revenues. There will also need to be somewhere to set the taxes: the player window would be the sensible place. The public player should be able to set the rate, and other players see the rate, but not set it. Town growth based on local transport
Currently, towns grow based, in part, on the overall number of goods, mail and passengers transported in that town in proportion to that town's demand, as well as the proportion of electricity supplied to that demanded. The actual pattern of growth within a town is based on fixed rules.
What needs to happen in order to have realistic growth and to simulate the historically and economically significant phenomenon of commuter housing being built specifically along transport routes (Metro-Land
being the most well known example) is for the places where cities build new buildings and the level to which buildings are built depending on the quality of transport in that specific immediate vicinity, rather than the town as a whole.
To do this, it be necessary to use the success percentages of passengers/mail/goods transported from and to city buildings and factories (this information was always present for factories, and is recorded for city buildings from 11.0 onwards) in two ways: for existing buildings, how far and fast that they upgrade to larger buildings should depend on these percentages, and for new buildings, the higher the percentages of neighbouring buildings, the greater the chance that a new building will be built on the location.
Different sorts of buildings should care about different statistics: residential buildings should principally respond to commuting success rates, as people tend to follow jobs, but also to a lesser extent to non-commuting success rates, as how easy that it is to access leisure (etc.) facilities is of importance to people. Industrial city buildings should respond mainly to the extent to which local industries (that is, actual industries that accept goods other than those which consume but do not produce, which should be deemed commercial, not industrial city buildings) are well supplied, and should prefer to grow near actual industries, but should also respond to a lesser extent to commuting success rates, as it is important that there are enough people to fill the jobs (this should be secondary, as people come to the jobs rather than industry to the people). Commercial city buildings should respond principally to the success rates of non-commuting trips ending in commercial buildings, as commerce needs customers, but should also respond, to a lesser extent, to commuting success rates and the success rates of local end-consumer industries (presumed to be shops) in receiving goods, to ensure that they are well supplied. Park and ride and car parking
Currently, passengers can use private cars to make complete, but not partial journeys, and, whilst private cars are affected by congestion, there is no attempt to simulate another important economic limitation on private car use, scarcity of parking spaces.
In order to improve the realism of private car transport, it needs to be possible for passengers to make private car journeys from their origin to a station equipped with car parking facilities, and then continue their journey by player transport (aircraft, train, bus etc.). There also needs to be some simulation of car parking scarcity.
A way of implementing this is to start with the car parking scarcity feature: a destination building (i.e., an industry or a commercial or industrial city building) should have a limited number of car parking spaces available per month. When more cars have reached that building as a destination in that month than the building has internal car parking capacity, no more private cars should be able to make a direct route to that building until the next month. This simulates buildings' in-built car parks. This number should be set in the pakset for each building: larger or older buildings might well have no car parking space, whereas smaller or medium sized newer buildings (or buildings such as large factories) might have generous provision. Care will need to be taken to design a system to prevent private car journeys all being made at the beginning of the month when parking spaces are available - consideration will have to be given to some sort of offset allowing rolling resetting of car parking data rather than doing it at the beginning of each month. Consideration should also be given to a town-wide setting to allow street parking: this would give all buildings X number of extra parking spaces (where X is a figure that can be set in simuconf.tab) even when they have none built in, but would increase congestion in the town by a set factor, also set in simuconf.tab. This setting should be changeable in the same way as "allow city growth" (i.e., only by the public player in online multi-player games).
A new stop type, a car park (US English: "parking lot") would need to be defined. This would be a sub-class of the current "haltestelle_t" class (which deals with stations and stops). It would be able to be built on its own or as an extension to an existing stop/station. It would have a defined capacity, which would work in the same way as the capacity of individual buildings. Different car parks could be defined with different graphics and different capacities (from small areas of gravel to large multi-storey car parks). A car journey could then be made to the car park and passengers could continue the rest of their journey by foot or by connecting to another form of transport (such as 'bus, train or aircraft).
To the game's internal routing system, road connexions to car parks would be calculated from towns in the same way as they are from towns to other towns. This would give whether any given car park is reachable from any given town, and the journey time per straight line tile from origin to destination. When passengers search for a route, those with access to a private car would search not just local stops, but stops attached to or reachable from any car park connected to the town in which the passengers' journey starts. Notification of vehicle upgrades [*S]
Currently, the only way of ascertaining whether it is possible to upgrade a vehicle is to go to the depot/replace window and select "upgrade" rather than "buy/sell". This makes it not entirely obvious when an upgrade is available.
It would be helpful if there were a system of notifying a player more easily when an upgrade is available: see the feature suggestion here
Currently, players can only transport passengers, mail and goods within the map boundary. Even on extremely large maps, the distances achievable are nowhere near the distances common in international/intercontinental shipping and aviation, which renders of little or no use the vehicles and infrastructure dedicated to such forms of transport. It is not practicable within the computational resources that exist to-day or that will exist in the foreseeable future to expand the maximum map size by orders of magnitude whilst retaining the current level of detail of simulation.
A worthwhile way around this would be to create portals to international destinations on the map's edge. Special tiles, generated randomly at the start of the game (and perhaps added and/or deleted as the game progresses) would act as portals to international destinations. They would produce and demand goods, passengers and mail in varying quantities, and have a notional distance to the actual destination through the portal.
Portals would act as if they were a special sort of stop. The convoys would behave as if they were a stop by stopping at them, loading and unloading at them with their normal loading time, then moving to the next point on their schedule. However, the financial consequences of using a portal would be importantly different to those of using a normal stop. The revenue would be based on the notional distance from the portal tile to the distant destination plus the actual distance travelled based on the time that the convoy would take to complete the remainder of the route at its maximum speed (taking into account its current load, and perhaps with a limit on the speed of supersonic aircraft if the portal tile is on land rather than sea to reflect the fact that aircraft are only generally permitted to travel at supersonic speeds over the sea). A sum would be charged to represent the notional per kilometre cost of travelling that distance and also the notional fixed cost that would have been incurred had the vehicle been in use for the notional part of the journey. Further, a discount would be applied to the revenue to reflect the fact that it was earned more quickly than it would have been had the player had to wait for the convoy to complete its full trip to the notional destination (for example, if the trip to the portal takes 1/10th of the total time that would be taken from the ultimate origin through the portal to the notional destination, the revenue would be reduced by a factor of 10 to take account of the fact that the player can earn the revenue 10 times more quickly, and therefore 10 times more often). The passengers/mail/goods loaded at a portal, when being unloaded at the subsequent stop, would also have the adjustments to the revenue, as would the vehicle's running costs when unloading at the first post-portal stop.Note: Because of the very long (nominal) travelling times that would be involved with portals, this would necessitate changing all of the journey time data from 16-bit to 32-bit integers. This would then enable increasing the resolution of journey times from tenths of minutes to seconds.Request stops for road vehicles and trams
Currently, all vehicles stop at every stop in their schedule even if there is nothing waiting for them there and nothing on board that needs to alight there.
It would be useful, for road vehicles and trams, at least, where request stops are commonplace, to allow a stop to be marked as a request stop in the schedule. A request stop would be one at which the vehicle stops only if, on entering the tile immediately before the stop, there is something on board that has that stop as its next transfer, or there is something waiting at the next stop that will board the vehicle in question. If neither of these conditions were true, the convoy would advance to the next stop in its schedule. This should not be available if the stop is a reversing stop. It should not be possible to specify a request stop as one with a minimum load or to wait for a certain time there. Road stop improvements
Currently, road vehicles stopping at stops remain in the middle of the road and block traffic. Also, dead-end road stops can only accommodate one vehicle at once, whereas through road stops can accommodate two vehicles at once (one in each direction).
It would be sensible to have road vehicles stopping at through road stops to pull over to let other traffic past them. When stopping at a through stop, a road vehicle should enter a pulled over state (with the same graphical offset as for a vehicle being overtaken), and any other vehicles ought to be able to pass on the road unobstructed. Likewise, any vehicles that are waiting for a stop to be free ahead should pull over in the same manner. This reflects how 'buses and lorries actually behave in reality on wider roads (which are common in towns), and will reduce the congestion that can be caused by stopped 'buses and lorries in town centres. It will also reduce conflict between players in multi-player games.
As to dead-end road stops, it would be useful to allow these to have more capacity than they have at present: at the minimum, they should accommodate two vehicles (one in each "direction") at once, both able to enter and leave independently of each other, but, using similar graphical offsets as for pulling over, one might even consider allowing them to accommodate four road vehicles simultaneously. This would more accurately simulate 'bus terminals and loading bays in reality, and reduce the amount of space that players need to take with road stops in crowded towns.Low bridges over roads and double decker trams/buses and tall ships/boats
At present, there is a setting in simuconf.tab that either allows or prohibits half-height bridges to be built over ways. Any vehicle can pass under such a bridge if it is built. It would be helpful to allow half-height bridges to be built over roads/waterways, but restrict the sorts of vehicles that may pass underneath them. Only single decker 'buses and short vans, for example, might pass under half-height road bridges, and only canal barges/narrowboats might pass under waterway half-height bridges. This would require a flag in each vehicle's .dat file indicating whether it may pass beneath a half-height bridge or not. Consideration will have to be given to what is the default option.Better indication of which vehicle has problems finding a depot [*S]
At present, when a vehicle cannot for some reason find a depot, no indication is given as to which vehicle is having the difficulty. It would be most helpful if such an indication were to be given to assist players in locating problems.
for discussion of this feature.Easier signal replacement [*S]
At present, when replacing a signal or roadsign, it is necessary to delete it and then add another. It might be easier if it were possible to replace a signal or road sign in a single step, by CTRL+clicking on the old sign/signal with the tool for the new signal selected: this should work in the same way as if the player had first bulldozed and then added the new sign/signal except
that it should check the cost of both first and only demolish/remove if the player can afford both steps combined.
These are projects formerly listed on this thread that have now been completed. The descriptions are included here for reference only. Note that there may well have been substantial changes between the design for the features being specified and being implemented, so the descriptions below may not be an accurate description of how the feature was implemented. Realistic correlation between town size, town population, mail and passenger generation [Incorporated in version 11.0 and later]
Currently, the relationship between the amount of space that towns and cities occupy on the map, their population size and the number of passengers and amount of mail that they generate is unclear and not grounded in reality.
It would be very helpful to recalibrate these things (preferably by re-coding so as to allow for these relationships to be set in configuration files) so that a town of X square kilometres in Simutrans has the same population and generates the same amount of mail and passengers as an equivalent town of X square kilometres in reality.
Serious consideration needs to be given to mail, as the volume of mail has changed over time other than in response to transportation conditions (for example, the introduction of the penny post, the invention of the telephone and the advent of e-mail), with the possibility of having time based demand factors explored.
Revenue based way tolls [Incorporated in version 10.4 and later]Standard has recently introduced cost-based way tolls (i.e., charges for using another player's way based either on a proportion of the running cost of the vehicles travelling over the way, a proportion of the cost of the maintenance of the way, or a combination of the both). I should like to add a third option, to emulate the way in which British canals and pre-1948 railways dealt with the issue, by sharing revenues. This is useful, as it will give more incentive for players to co-operate in the joint construction of canals, railways, etc. where each can have a share in the profits of operation.What I'd like to see is a "way_toll_profit_percent" or similar setting in simuconf.tab, and each ware packet on reaching its destination paying the proportion of its gross revenue set in the simuconf.tab setting. The tricky bit will be the calculation of the proportion of different players' lines over which the ware packet has passed on this particular journey leg: either a fixed array or a vector (perhaps a minivec) per ware packet in place of the current "accumulated_distance" parameter, giving the distance per player number since the ware packet boarded the convoy. This could then simply be totalled, proportions taken by dividing each of the player's figures by the total, and revenue apportioned according to the total (plus the percentage figure in simuconf.tab). Some testing would need to be undertaken to ensure that this does not use too much memory. Also, consideration would have to be given as to whether to book the revenues received from this as "revenue" or "way tolls" for accounting purposes.Running powers [Incorporated in version 10.4 and later]I am not convinced that the latest changes to Standard to make it easier for players to link their ways together (the new "make way public" tool combined with the "private way gate") are the best way of doing this, not least because, once ways are public, none other than the public player can edit them; the same goes for stations. What we need, I think, is a quite simple system of running powers: without running powers, players would not be able (1) to connect to other players' ways; (2) to stop at other players' stops; or (3) to run vehicles over other players' ways; with running powers, players would be able to do all three. Players would be able to grant and revoke running powers in relation to any other player at will, but, if a player's vehicle is on another player's way when a running power is revoked, it could either be (1) sent to a depot, or (2) be allowed to continue its journey but, once it leaves the other player's way, not return, and have all of the revoked player's stops deleted from its timetable. Some consideration would be needed as to how to implement the GUI for this feature: perhaps a new dialogue, or adding this to the existing "players" dialogue.Stops/signals/road signs that can be built only underground or only above ground [Incorporated in version 10.12 and later]
It would be helpful for the purposes of developing underground railways were it possible to restrict certain station types to above ground/underground. This way, the cost of building underground can properly be modelled, as well as creating the right appearance for underground stations (as it looks absurd, for example, for underground stations to have overall roofs or flower beds).
The best way of doing this would be to add a flag to the .dat files of objects "allow_underground". If "allow_underground=0" is set, the stop/roadsign/signal cannot be built underground. If "allow_underground=1" is set (which should be the default), the stop/roadsign/signal can be built underground or overground. If "allow_underground=2" is set, the stop/roadsign/signal can be built only underground.
The GUI for this would need to follow the current pattern of dealing with things that can and cannot be built underground: in underground mode, for example, the menu buttons for station extensions are hidden. The same effect would be needed here: in overground mode, only stations/etc. that can be built overground should be shown; in full underground mode, only stations, etc. that can be built underground should be shown; and in sliced underground mode, all stations, etc. should be shown.Saving player colours [Incorporated in version 10.4 and later]Currently, player colours can be changed, but cannot be saved or propagated over the network. It would be very useful and satisfying, I think, if players were able to customise their colours in a way that will persist and affect all other players in a network game. This will simply involve loading/saving the primary and secondary colours for any given player, and transmitting those values over the network when they are changed manually by the players.
Way maintenance costs based on use [*B] [Incorporated in 12.x versions]
As suggested by Moblet some years ago now, in order to get paksets to balance properly, the cost of maintaining ways needs to vary with how much that they are used. I had thought of implementing a simple parameter, "cost_per_tonne" in the .dat files, but this might be too linear (the wear caused by a 20t vehicle is more than twice the wear caused by a 10t vehicle, apparently). The simple version would probably suffice for our purposes, although if anyone would like to try to implement a more sophisticated system, that would be good, too.
An alternative, which I am seriously considering, is to link this to renewal (see below). Instead of having a cost per tonne, have a number of tonnes between renewals. Each way tile would collect statistics (and display these in the information window) on (1) the date of first building; (2) the date of the last renewal (if any); (3) the number of tonnes since last renewal (or first building if there has been no renewal); (4) the number of tonnes until the next renewal is due; (5) the estimated date of the next renewal based on a simple calculation from the previous three data; and (6) the cost of next renewal. (Strictly, 4, 5 and 6 would not be stored in the tile, but would be calculated when required for display).
Way upgrading costs [*B] [Incorporated in 12.x versions]
Currently, it costs the same to upgrade one way to another as to build a new way from scratch. Really, it should cost a fair bit less to upgrade one way to another. What I'd like to do is implement a parameter in simuconf.tab, "way_upgrade_percentage", which would be the percentage of the cost of building a new way that it costs to upgrade an old one. So, for example, if "way_upgrade_percentage=75" was set, upgrading an old way would cost 75% of what it costs to build a new way.
Bridge/tunnel upgrading costs [*B] [Incorporated in 12.x versions]
Currently, bridges and tunnels and their ways are inseparable. To upgrade the road surface on a bridge or railway lines in a tunnel, one must replace the entire bridge or tunnel at full price. Clearly, this is silly. Ideally, there would be a complete separation of ways themselves from bridges, tunnels and elevated ways. However, that would require fundamental and very difficult changes in the code. An interim solution would be to have "way_only_cost" and "upgrade_group" parameters in each bridge, tunnel and elevated way's .dat file. For renewal (see below) or when upgrading to a bridge/tunnel with the same upgrade group, the "way_only_cost" would be used. When building new or upgrading to a bridge/tunnel in a different upgrade group, the full cost would apply. The default way_only_cost where none is specified would be 1/10th of the base cost for a bridge and 1/20th for a tunnel.
Way renewal [*B] [Incorporated in 12.x versions]
Connected with the above ideas, and similarly based on a suggestion by Moblet, it should be necessary to renew ways periodically, perhaps after a certain tonnage based in the way's .dat files. Obviously, it would involve painful micromanagement if players manually had to replace every worn-out bit of road or track, so an automated replacer would be needed. The cost of renewing a way would be the upgrade cost, not the new build cost for the way.
An interesting question is what happens when technology has moved on since the way was first built. The way replacer should not renew a way with an obsolete type, so this renewal process would involve an upgrade process, too. At its simplest would be a straightforward formula, such as "if the original way is obsolete, find a non-obsolete way of the same type with the lowest cost of a weight and speed limit not lower than that of the way replaced", or something similar. If we wanted something more sophisticated (which would be good, but not essential), we could think about players being able to specify which ways should be replaced with which other ways, or even pre-emptively upgrade ways (in other words, tell Simutrans to upgrade a particular section of way to a particular type but to wait until the old way needs renewing before doing that).
Another thing to consider is the GUI for this: at its simplest, one could simply have textual information in the way information dialogue. However, it might be good to have, for example, a graphical display of overlaid tile colours to show how close that ways are to needing to be renewed and/or some financial information to show the estimated cost of way renewals in the coming, say, year.
Fully customisable cornering speed limits [*B] [Incorporated in 12.x versions]
Currently, cornering speed limits are partly fixed in the code, and also partly relative to the cost of existing ways. The former makes them inflexible and the latter makes them prone to the well known cornering exploit of upgrading the way to a better type just on the corners to achieve a higher speed around corners on what is otherwise a cheaper type of way. This exploit would end once the linkage between the base speed of a way and the cornering speed is broken and replaced instead by a system based on the number of degrees turned in a set distance.
Land purchase costs [*B] [Incorporated in 12.x versions]
Players can buy land, but the price of this is not always added to the cost of building ways and buildings, and the cost is fixed rather than varying depending on the likely value of the land. Ideally, there should be a fully sophisticated land value system based on the same system as used for local town growth (see below), but, in the interim, a simple system based on distinguishing town and country (and the various categories of town, and, for country, the altitude) should suffice. Land costs should consistently be deducted from players when building ways and buildings and credited when deleting ways and buildings. Similarly, wayleaves should be charged when building elevated ways, bridges and tunnels under/over land.
When realistic/local town growth is implemented, a more realistic system for calculating land value will be needed, which will make this more important yet.
Mothballing [Incorporated in 12.x versions]
It should be possible to have a mothballed way type: one which is free to downgrade from its base way type, but cannot support vehicles. This actually requires only a very minor change to the code: if the build and maintenance cost of a way is zero, it should not be possible to build it except as a downgrade of an existing way. This would prevent an exploit that could otherwise apply, where a player would put down a free mothballed way, then upgrade it (at reduced cost compared to new building) to a usable way. It is intended that genuinely mothballed ways are cheaper to re-instate than it is to build a new way.
Public rights of way [Incorporated in 12.x versions]
Currently, there is no concept of a public right of way: each way is either owned by a player, in which case that player controls access rights, or it is unowned, in which case all players have access, but any player may bulldoze the way or take it into private ownership, excluding other players. It would be most useful if there were a system of public rights of way, in which the way may be privately owned, built and maintained, but where players may not delete, downgrade or restrict access. Even more sophisticatedly, small diversions could be allowed by automatically checking whether the two disconnected ends of a public right of way that a player tries to bulldoze are connected by ways with at least as good a weight and speed limit as the current way within a certain limited number of tiles (set in simuconf.tab): see here for a discussion - that latter feature was suggested by Isidoro.
Canal and river navigation [Incorporated in 12.x versions]
Currently, canals and rivers are unlimited in capacity, as boats do not take notice of the presence of other boats when moving, making a theoretically infinite number of overlapping boats possible. It would be sensible to make canal navigation like road navigation, in which vessels travelling in the same direction cannot pass through each other, but must wait behind each other. This would more accurately simulate especially the narrower canals of the 18th and early 19th centuries.
Also, consideration should be given to the fact that canal boats would take a very long time to pass through locks; perhaps a "canal with locks" flag could be set on a waterway in the .dat file which would cause vehicles passing along it to pause for a predefined time on every height transition tile.
Railway signalling [Incorporated in 12.x versions]
Once realistic braking distances are implemented [now completed], it would add much to the operational and economic realism of railways if the signalling could be made more realistic, specifically, with respect to the speed at which trains can travel in light of the drivers' state of knowledge of the aspect displayed by the next signal. In other words, there comes a speed (and it is not very fast) at which a driver cannot see a signal at danger ahead in time to stop for it. Railways have dealt with that by using warning signals ("distant" signals in British terminology, or "pre-signals" in the terminology of many other systems) to tell the driver of the state of the next signal. In modern times, multiple aspect signals have been developed, which combine the functions of a stop and distant signal: the signal will always give an indication of the aspect of the next signal (and possibly the signal after next) unless it is at danger itself. Here is some information on railway signalling practice.
Maximum distance to connecting industry [*B] [Incorporated in 12.x versions]
At present, industries do not select their connexion partners based on distance. This means that, for example, a dairy in 1750 can connect to a farm thousands of kilometres away, which is entirely at odds with reality, and has been known to give rise in online games to a vast, highly profitable (and rather amusing) intercontinental milk trade. The simplest way of solving the problem is to allow each industry to have a maximum range for other industries to connect to it. Different industries in different eras would then be able to have ha