Current development projects: coding help welcome

[jamespetts]

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.

This also needs a fix of vehicle alignment issues in certain paksets to work.

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.

Towns generated to serve industries [*B]

Currently, industries require passengers to work in them, or else they will cease to function, but there is no way of making sure that, in early eras when transporting lower class workers to farms from their homes by horse would have been uneconomic, industries are in walking distance of a town. It is not practical to secure this result by using the industry's maximum distance to its consumers, as this would result in that distance being too short in many cases.

A solution to this is to spawn a new town whenever an industry is built too far from an existing town. Whether an industry is too far from an existing town should be determined by a maximum distance to town parameter in the industry's .dat file. The town that spawns will need to be a small town, just enough to supply the industry with employees.

Careful thought will need to be given to how this interacts with the planned improved town growth mechanic (on which see below) and additionally how this works when maps are generated: if a player has specified a certain number of towns, this has the potential to interfere with that setting if it applies on map generation by creating more towns than the player requested; yet, if it is not used on map generation, many industries generated on map generation may be too far from the nearest town to attract enough workers on foot to operate.

Consideration will have to be given to how town naming should work when automatically generating towns in online games. Currently, town names are generated using the asynchronous random number generator, as using the synchronous random number generator causes loss of synchronisation between server and client when the server and client have different language files. Ideally, the name should be set by the server and propagated to clients, but I am currently unsure how well that this will work with existing code structures.

Interpolated way gradients

Currently, gradients for the purpose of physics calculations can only be determined on the basis of the two possible non-flat gradients displayed. This makes it difficult to calibrate gradients, and, in particular, difficult for players to plan for smooth gradients.

A. Carlotti has proposed an improved system for gradients here, the substance of which is as follows:

I think a reasonable approach would be to assign a 'microheight' to each edge between adjoining way tiles. If this tile is an intersection, then this microhieght is forced to be the displayed height, and if the tile has an obstacle (another way tile or building) within two levels above or below it, then this microheight is forced to be at most or at least the displayed height. Otherwise, for each slope tile, search up to 2N tiles along the way (where N is the maximum distance in one direction to average over), until reaching another slope, an intersection, or a obstacle above/below the tile (depending on whether we're averaging a downhill or uphill slope). The linearly interpolate the microheight between the two end points (which are either the middle of a slope tile, with a height of +/- half the height difference per level relative to the level section of way; or the edge of an intersection or tile with an obstacle, with a height equal to the displayed height). This gives a height at each edge, which can be used to assign a gradient to each direction on each way tile.
(Note that there are some inconsistencies in what I write here that should not be included in an implementation, but the basic idea is correct.)

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.

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

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

Conurbations and districts

At present, towns can grow to overlap each other as in reality, but the two towns retain their equal status as towns, which can cause anomalies in determining which town any given building is in.

What ought to happen is that smaller towns that are encroached upon by larger towns become absorbed into the larger towns, and cease to be full towns in their own rights, but become instead districts of the larger town.

Whenever one town hall falls within the boundary of another town, whichever of the two towns is the larger should be converted into a conurbation, and the smaller town into a district of that conurbation. Any other towns or villages absorbed by the conurbation would also become districts.

This should affect the town statistics, such that the statistics for the conurbation are the statistics for both the original town and all the districts in the conurbation, whereas the districts retain separate local statistics. Likewise electrical supply to any part of the conurbation should give power to all districts of the conurbation, and private car routing should treat the conurbation as a single town and journeys between districts of that conurbation as journeys within a single town, rather than journeys between towns. The existence of conurbations ought also to affect how stops are named, with docks, airports and first stops taking the conurbation rather than the district name.

This may not directly affect town growth if implemented after the local town growth feature described above.

Neroden had proposed something similar a few years ago involving the larger town completely subsuming the smaller town and removing the town hall, but that would be difficult to achieve technically, since pointers to the original town which would, on deletion, become invalid, would be strewn around the code and hard to unpick. In any event, I believe that the idea of having conurbations with separate districts is more realistic (and will also give more variety to local stop names).

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.

It should be possible to have short-stay or long-stay car parks; short stay car parks would be available only to visiting passengers, whereas long-stay car parks would be available to visiting or commuting passengers, or those transferring to another form of transport. It should be possible for players to choose to have a car park connected to a stop reserved for the exclusive use of passengers using that stop.

This system could also interact with the passenger and mail classes system by allowing players to set different levels of price for car parking corresponding to the different classes of passenger: a low priced car park could be afforded by passengers of all levels of wealth, whereas a higher priced car park could be afforded by only those passengers of the corresponding level of wealth or higher, and would be unavailable to passengers of a lower level of wealth in the same way as it would be if the car park were full.

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.

Portals/overseas destinations

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.

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.

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.

See here for discussion of this feature.

Easier signal replacement [*S]

At present, when replacing a signal or road sign, 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.

Varying price of goods transport/goods classes

Currently, it is possible to change the price of transport for passengers and mail, but not goods. Goods have different categories attracting different prices (e.g., hauling a tonne of coal 1km earns much less revenue than hauling a tonne of canned food 1km), but there is no way for a player to charge a higher or lower price for transporting goods. This is because in large part there is no current means of simulating any adverse consequence for a player charging a high price, so that, given a choice, players would always charge the highest possible price for hauling goods, and there would be no reason to do anything else.

A great improvement on this situation would be a system in which goods have as many different pricing levels as passengers have classes. All goods transported would be impressed with the price of the highest priced link in their journey. The path explorer (the part of the code that decides what route that mail/passengers/goods take to get to their destinations) would try to find the fastest route at the lowest price, and only look to higher priced routes if no route (or none within the goods' journey time tolerance, journey time tolerance for goods being a feature that it might be worthwhile to introduce alongside this feature) could be found.

All goods produced would take the highest price from all input goods (if any). When the goods would eventually be dispatched to consumer industries, only those passengers whose wealth is of the same or a higher level than the price impressed upon those goods would be able to buy them. For example, suppose that a grocer accepts tinned food from a cannery, and the cannery takes steel from a steelworks and meat from a slaughterhouse, the steelworks taking coal and iron ore from mines and the slaughterhouse taking livestock from farms. If the player transporting the meat from the slaughterhouse to the cannery sets the goods transport price to "medium" instead of the default "very low", then that player would make more money for every unit of meat transported; but, even assuming that all other transport links were very low, the tinned food produced as a result would then be impressed with "medium" cost, which cost would mean that only consumers whose wealth is "medium" or above would be able to buy the tinned food from the grocer. Passengers of "low" or "very low" wealth would be turned away (in the same way that all passengers are currently turned away when there are no goods in stock). This could be done selectively when different goods at different prices are sold, e.g. at a market, either by causing the lower wealth passengers to buy more of the lower priced goods in compensation, or assigning them to desire one specific product at random and turning them away if that product is too expensive for them.

One way of implementing this in the pakset would be to increase more the prices for hauling goods over longer distances (there is already a mechanism for differing prices for different distances and has been since 12.x). This would mean that, e.g., "low" coal would give the same amount of money as "very low" coal for journeys of <500km, but would pay more for journeys in excess of 500km, making long-haul coal transport viable where otherwise it might not be, but also simulating that longer distance transport makes commodities more expensive. The higher prices should also affect shorter distance transport, such as to make pack horses viable where otherwise they would not be.

Unresolved issues so far are what to do with the price of goods destined for power stations and consumers with a 0 visitor demand (e.g. gasworks and dairies) that are assumed to distribute the products themselves. This feature has been discussed in more detail here.

Journey time tolerances for goods

Currently, passengers, but not mail or goods, have a journey time tolerance. This makes sense for goods such as coal, tinned food or hardware, but less sense for goods such as milk, meat or newspapers where time is of the essence.

It might be useful to have a journey time tolerance for goods, but careful thought would have to be given to this to make sure that industry chains did not spawn (at least, with any regularity) whose distance from each other were such that, given the technological limitations of the age, it would be entirely impossible to transport anything among them within the journey time tolerance of the goods in question.  This is not an easy problem to solve, as the journey time achievable in any given era from any given point to any other given point is extremely difficult to calculate (consider the slowing effect that locks have on canals, for instance, or that players may need to route railways or roads around hills if they cannot afford a tunnel).

Private vans

Currently, while passengers can get to their destination in some cases by private car, industrial products can only ever reach their destination by player transport. This is not entirely realistic, as many industries had/have their own road transport capability.

It would be advantageous if it were possible for industries to be able to connect to other industries and ship goods by way of low capacity private road transport. The routes between these could be calculated in the same way as for private cars.

Consideration would have to be given to which industries get access to private vans, their speed and capacity (how many vans per hour that an industry can dispatch) and how this would affect the price of the goods, assuming that the price of goods feature discussed above should be implemented. Such a feature should still leave room for player transport in so far as that is realistic (modern businesses might well be able to compete effectively with player transport). Consideration would also have to be given to allowing private vans to travel part of the way to a goods stop and allowing the remainder of the journey to be completed by player transport, similarly as with the park and ride feature for passengers envisaged above.

One imagines that the individual vans would be defined in similar ways to individual private cars (there are already some horse drawn cart graphics for private cars that would be more appropriately used as vans), although care would have to be taken to ensure that each category of goods has its own appropriate private van type, which might involve quite a lot of additional work.

Different private cars for different levels of passenger wealth

Currently, although the rate of private car ownership varies with wealth, the actual private car graphics (and their speed, which affects the speed at which passengers can travel by private car) does not.

It would be good if there could be different sets of private cars separate by wealth, and that passengers of each degree of wealth would, when travelling by private car, generate the appropriate graphics.

Because this would involve a considerable amount of pakset work to implement, and would mostly be of cosmetic significance, this is currently a very low priority task; but anyone who has a passion for motor cars and a willingness to model (or import) a large number of motor car graphics for all levels of wealth through all time periods would be welcome to work on this.

Fractional power and tractive effort values[*S]

Currently, it is only possible to specify power and tractive effort in units of kilowatts or kilonewtons. This is problematic for very low powered vehicles (e.g., bicycles, horses), as it is not possible to set realistic values for power. Internally, the physics engine can cope with fractional values of power and tractive effort, and it is possible to work around this to some extent for power by using "gear", but this is not effective for tractive effort.

It would thus be useful to be able to specify power and tractive effort as decimals of up to two decimal places (in the same way that weight can now be specified as a decimal). This should be relatively straightforward to implement, but does require some work in altering the memory structures to accommodate it.


See the next post for completed projects.

[jamespetts]

I have updated this post to add a few additional features, and also to mark certain features as balance critical and others as simple.

Edit: Also, completed projects have been moved to this post, as the original post was running out of space and truncating text.

Completed projects

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.


Automatic industry road connexions [Incorporated in version 14.7 and later]

At present, towns are connected to each other by road (if a road route be available) when the world is generated. The same is not so for industries. This can cause problems for players who wish to connect to low volume industries with low profit margins: having to build road infrastructure to connect the industries costs more than the profit that the player is ever likely to make by transporting goods from the industries. This is especially a problem for farms.

The best way of dealing with this would be to have industries automatically connected by roads in the same way as towns when the world is first generated, and, further, for additional industries also to connect by road when they are built. For these later industries, some careful thought will have to be given to the algorithm to be used, as the same algorithm as with towns cannot be used, as that requires an all at once set of connexions.

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


Low bridges over roads and double decker trams/buses and tall ships/boats [Incorporated in versions 12.0 and later]

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.

Takeovers, insolvent administration and solvent liquidation[Incorporated May 2020]


Currently, no transport company can take over another. When a company becomes insolvent, its assets are liquidated after a set period; there is no option for another player to rescue the insolvent company. A solvent company cannot be liquidated. This leads to anomalies in multi-player games when players abandon the game or their companies fail.

A better system would be to allow takeovers. A takeover of a transport company should be possible either where (1) the player has elected to allow a takeover; or (2) the company is in a state of insolvent administration (see below). The company taking over the other company should be able to do so at the cost of the net book value of the assets of the company to be taken over, unless that value is negative, in which case the company pays nothing. In either case, the company taking over would take control of all the assets of the company taken over (apart from its headquarters, which would be destroyed), but would also take on responsibility for all its liabilities. A company should only be able to take over another company if it has the cash to pay the price of doing so and would not immediately itself be insolvent by taking over the other company's liabilities.

A player might voluntarily elect to put a company up for takeover in a multi-player game if he/she no longer wishes to play on that server, or no longer has time to do so; or alternatively, if he/she realises that her/his company is in trouble and would prefer to start afresh, leaving a more successful company to rescue what is left. Alternatively, two players might wish to co-operate and play one company, in which case, one player may take over the other's company, and then give the other player the first player's password so that they can both play the same company. In both cases, a player slot will have been freed for a new player to join.

Whenever a company becomes insolvent, it should continue to operate for a period of time (default 1 year, configurable in simuconf.tab) in administration. During this period, the player would continue to be able to control the company, but it would be liable for takeover by any other player. If at any end of month during that time the company ceased to be insolvent, it would leave insolvent administration and full control would continue to rest with the player, the company no longer being able to be taken over (unless the player subsequently voluntarily permits this as above). If at the end of the specified period the company has neither been taken over nor ceased to be insolvent, the company should revert to a dormant state for a further specified period (default 1 year, configurable in simuconf.tab): all convoys should be automatically ordered to return to their depots and be put up for sale (see above on a second-hand market in vehicles), the company should cease to be playable, but remain available for takeover. On takeover, all vehicles would automatically be withdrawn from sale. Any takeover of a company in this state would have to pay only the value of its assets and would not have to take over its liabilities. If at the end of the further period, an insolvent company were not taken over, it should then be liquidated in the same way as at present, and all the company's vehicles would be scrapped.

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 simulation [Incorporated January 2020]


Note: This feature proposal has been revised as of January 2020: see here for a discussion and also the archived text of the previous version, as well as the description of the current system, which cannot fit into this post without exceeding length limits. See further here for an earlier discussion of the computational intensity of this feature.

If, instead of discarding the tiles constituting a route to any given destination as at present, the private car route finder were instead to store (1) the destination (a co-ordinate is probably better than a pointer here); and (2) a direction in the tiles of road constituting the route, then this would allow private cars to follow the route without doing their own routefinding.

Private cars whose origin and destination are within the same town would continue to behave as they do now, and drive around randomly, with one change: they would refuse to go outside the boundaries of the town. If they were to get to a road heading out of the town, they would turn back.

Private cars whose destination is outside the origin town would start by driving around randomly as now. However, at each junction (intersection), they would check whether the tile in question is marked as being part of a route to their destination. If it is, they would turn to travel in the direction that that route points. They would not leave a town unless (1) the tile outside the town is on a route to their destination; or (2) the tile outside the town is in another town (i.e. an immediately adjacent town). If at any point in their journey, the route were broken (e.g. because a tile forming part of the route has been deleted), they would simply revert to driving around randomly.

In all cases, the despawn timer would remain the same as it is now.

This would somewhat increase the memory overhead for ways, and the computational overhead of the private car route finder, but these should (hopefully) be relatively modest, especially as the latter is multi-threaded. (I will have to check to see how much memory that ways take up already). It may also somewhat increase the computational intensity of the private cars' sync_step (i.e. the code for moving them around), although by how much is debatable.

Private cars' sync_step already takes a fairly substantial proportion of processor time in very large games in the modern era (the Bridgewater-Brunel game with 768 towns in the game year 2004, for example). Multi-threading this may be an option. Multi-threading this would work by having batches of cars check which tile that they should turn to next simultaneously (e.g., if there are 100 cars and 4 threads specified in simuconf.tab, process 4 batches of 25 at a time in 4 threads), but not execute the movement until after all the threads have terminated. I have not investigated the code in enough detail at present to know whether this is feasible, but I know that the "hop_check" part of private cars' sync_step routine takes a lot of time (collectively) on the Bridgwater-Brunel 768 town map in 2004.

There is then a question of whether congestion should be calculated differently. For journeys within a town, the current congestion system, based on the city's congestion rating, should be retained, as it is a reasonably good proxy of general congestion. However, for journeys between towns, it would be helpful to track the congestion of individual road tiles. Quite how to do this is an interesting challenge. One approach is the traditional Sim City style option of having each road type having a capacity of cars per (game month) and any excess of that recorded as congestion. A complexity here is that marking a road as one way will double that capacity; but it is very difficult for the game to work out whether any given tile of road is one way as this can be done by signs placed on a tile of road a long way back. An alternative is some sort of system of measuring stationary traffic, but I cannot think of a way of doing this that is not likely to be excessive in memory and memory bandwidth consumption. This may need more thought. Without a satisfactory alternative congestion measuring system, the existing system would have to be used.

Note: As it transpires, a system of per tile congestion based on the time take to traverse a tile compared to the maximum speed time to do so, written by Freddy Hayward, was used, and town congestion measured on the basis of an average of the congestion of all road tiles in the town.

[rsdworker]

looks good

Revenue based way tolls and Running powers sounds good - i like to test those features

and also Takeovers, mergers and insolvent administration sound good in single player - if there other players that player created networks so if one of them is bankupt and its should poof away not left behind

and also i like to test those new features

thanks

[Carl]

I'm very keen to assist with the simpler projects on this list at some point. Sadly (as with so many things) my ambition outruns my ability, so I'm here to ask for some advice on how to make myself more useful.


Thus far I have familiarised myself with the basic concepts of C++ and am at a point where I can read and interpret a good portion of the Simutrans code at a basic schematic level. (Since I've had plenty of experience reading logical notation and formal semantic notation, this step wasn't too troubling.) But it's a big step from having a basic understanding of the language to being able to contribute to a huge project like Simutrans, and at the moment I feel incompetent to even address the "low-hanging fruit" items described in your post above -- even having digested Prissi's advice here and looked at the doxygen reports.


I'd greatly appreciate any advice on how I might efficiently develop my skills so as to become competent enough to contribute to these projects. Would the best way be to continue to study the Simutrans code and learn how it all works, or instead to spend time working on simpler projects in order to develop an understanding of the language?

[jamespetts]

Carl,

your enthusiasm to assist is very much welcomed! Getting started with C++ can be a little tricky, as it is not the easiest language in the world, but I learned C++ specifically for Simutrans, and if I can do it, anyone can!

The best thing to do is to set up a Github branch of the code, and see if you can compile Simutrans-Experimental, then see if you can tinker aimlessly and make arbitrary changes that do what you intended.

Once you have done that, the next thing might be to find a small element of the GUI that you want to improve in some slight way, and see if you can work out how to do that (for example, see if you can work out how to widen the load/save dialogue so that both digits of the Experimental major version number are visible beneath the scrollbar).

Once you have learned how to compile the code and make minor changes that do what you want them to do, the rest will begin to fall into place.

If you're after any more specific help, don't hesitate to ask further!

[Carl]

Many thanks for your advice, James -- that's very helpful! I'm especially pleased to hear that you learned C++ specifically for Simutrans, because I was half-expecting someone to say that couldn't be done.


I've created a github fork, so I'll follow your advice on the GUI changes and check in again when I've achieved something useful!

[jamespetts]

Excellent!

[omikron]

Now that I have finally managed to compile simutrans standard, I thought I should try to do the same with experimental, but I fail, mainly because there are a lot of warnings and fatal errors while compiling - mostly due to 'converting' issues, but also because it can't find bzlib.h.

Do I have to take care that the directory from github is ina  special relation to the standard source directory for MSVC or have I done something else wrong?

omikron

[Carl]

Have you added the location of bzlib.h to the "Library Directories" portion of the "VC++ Directories" tab in MSVC?

[omikron]

Thanks, I've added that. In MSVC 2010, you need to do that for every single project, no longer over properties etc.

However, the warnings persist, having difficulties converting from 'const sint64' to 'uint32' with possible loss of data as well as a singed/unsigned mismatch

I'm sure there is an easy answer to this one, ,aybe someone can hint at it? I haven't done anything programming-related for ages!

omikron

[Combuijs]

Anything to do with 64-bits versus 32-bits somewhere in the build options?

[Carl]

However, the warnings persist, having difficulties converting from 'const sint64' to 'uint32' with possible loss of data as well as a singed/unsigned mismatch

The executable will compile successfully -- and run as expected -- despite the presence of these errors, I think.

[omikron]

Indeed, thanks! My error. Now I can turn to my other duties :-)

[jamespetts]

A man is smoking a cigarette and blowing smoke rings into the air.  His girlfriend becomes irritated with the smoke and says, "Can't you see the warning on the cigarette pack?  Smoking is hazardous to your health!"

To which the man replies, "I am a programmer.  We don't worry about warnings; we only worry about errors."

(Source)

[mopoona]

Does usage based maintenance cost include speed-related costs as well?

[jamespetts]

I hadn't specifically planned to do so - do you think it economically important?

[mopoona]

Hmm, it depends on the map, I think. If you play on a larger map, you might want to built high speed train routes for example. You will get more money with the speed bonus. To balance this we have to make the costs higher. But I find it illogical that high speed trains should cost more (each km) even when they don't use their potential maximum speed.

A slower vehicle consumes less energy, so I think it would make the game more realistic. But to keep the gameplay simple, you could do it like this:
You specify a "normal speed" for every waytype (or vehicle). Above that normal speed the km-costs rise up linear/to the square with some multiplier. This is just a quick thought how to do it.

[jamespetts]

I'm not sure that this is correct on a physical level, is it? A Ferrari going at 30mph will still do far fewer miles to the gallon than a Mini going 50km/h, even if the top speed of the Ferrari is twice as high as the top speed of the mini.

Also, increasing speed increases the amount of fuel used by unit of time, not necessarily by unit of distance, as each unit of distance is traversed in less time. There are variations in efficiency by speed (ordinary private cars are said to be at their most efficient at about 100km/h), but these strike me as potentially complicated to implement and probably more detail than is needed to get a good game balance.

[greenling]

Highspeedtrains are expensive!
The highspeedline from Köln to Frankfurt have at the beginning of building be plannning with 4millards Euro.
And as the Highspeedline be finish was with build have the highspeedline be cost 9millards euro!

[TygerFish]

I'm having some trouble compiling from source.  Downloaded from GitHub, opened Simutrans-Experimental.sln in VS2010.  Haven't written C++ in >10 years.


The comments by carlbaker/omikron helped me get rid of the header file not found errors -- fixed by downloading the bzip and zlib sources and adding their directories to the "Include Directories" under "VC++ directories" in the project properties.  (Adding to Library Directories actually didn't do anything for me.)


Now I'm getting a bunch of:
error C2664: 'gz[something]': cannot convert parameter 1 from 'FILE *' to 'gzFile'


Looking at the library code, it makes sense... is this not the right place to download zlib? [size=78%]http://www.zlib.net/[/size]

[Carl]

I think the file you want to open for compiling is Simutrans-Experimental.vcxproj. (That's what always works for me, anyway). Do you have any more luck with that?

[jamespetts]

Hello, and thank you for your interest in assisting! For Zlib, you need to follow the same instructions as for Standard, which are here; is that not what you have done?

[TygerFish]

Hello, and thank you for your interest in assisting! For Zlib, you need to follow the same instructions as for Standard, which are here; is that not what you have done?

Ah, thanks for that!  I think I was missing libbz2.lib -- I'd found the OpenTTD package, which had all the other stuff except that.

[jamespetts]

Splendid!

[Lefthand]

Hi James,

yesterday I was thinking about the "way upgrading cost". I looked into the code and found that, only small changes needed to do this (in wegbauer.cc void wegbauer_t::baue_strasse() around line: 2152, and void wegbauer_t::baue_schiene() around line 2258), and perhaps add the setting to the GUI.

But I found an exploit with this idea. If one builds an unsurfaced road (2.5c per tile) and then upgrades it to the best road (~250c per tile) then he/she will get around 63c discount per tile with the 75% upgrade cost.
187,5+2,5 <-> 250.
I think this upgrade discount should diminish when upgrading to a much better road, but I can not figure out the numbers by myself.  And the discount must not be greater than the original cost of the old road. OR just set the discount to be the cost of the old road?

And I found that the cost of a road downgrade is equal to the cost of the better road. Is it correct, or it is a bug?
(And the cost estimate is very wrong when upgrading. It shows more, about 500c per tile than the actual cost).

Lefthand.

[paichtis]

OR just set the discount to be the cost of the old road?

75% the cost of the old road perhaps ? (seems pretty reasonable this way)

[jamespetts]

Thank you very much for your thoughts on this. I have had some thoughts about this myself recently, and come up with a slightly different means of achieving the same thing that avoids the exploit that you describe. Instead of having an upgrading cost, one might have a "forge cost", which is the additional cost of building any way of one particular sort (e.g., any type of road, any type of canal, etc.) on a tile where no way of that sort already exists. This cost would be added to the construction cost of the way itself. When upgrading/downgrading, only the construction cost of the way itself would be charged (except in the case of mothballing, which would be free). Further, building one way parallel to another way of the same type should attract a discounted forge cost (perhaps 1/2) to reflect the fact that, for example, building a double track railway does not cost the same as building two separate single track railways, but costs more than building one single track railway. (I am told by the Standard developers that checking for a parallel way of this sort should not be hard - I posted a thread about it somewhere). I should be interested in people's views on this system.

As for the cost of downgrading, you indeed appear to have found a bug - under the current system, the cost of downgrading should be the cost of the inferior way, not the cost of the superior way.

[Lefthand]

I don't really get this forge cost idea. Is it the "cost of the land"? Or another fix additinal cost when building new ways?

On the other hand, when building a new way, there is  a check in the code, if the land-tile is owned by the player (gr->obj_bei(0)->get_besitzer())
But it seems to be buggy too, because it substracts from the cost, not add to it. (When building, the cost will be negative... and added to the balance, so a negative cost hurting our balance, and a positive cost is good for us). I think we should check whether the landtile is NOT owned by the player. And the next line is checking the cost if it is below zero and set it to zero if true. I think this is wrong too, because the cost is always 0 when we check the land-tile ownership if I remember correctly), then we substract from it, then we set to zero.

By the way the cost will get overriden 5 line below: cost = -gr->neuen_weg_b....

Lh.

[jamespetts]

The forge cost is not the cost of the land, per se, but an additional fixed cost when building new ways to simulate the additional cost of actually forging a way in a particular place. Building a new road requires much more work than upgrading one type to another. It is that extra work that is represented in the forge cost. The cost of the land can be dealt with separately.

On that subject, I have fixed the over-writing issue that you have found here - thank you for spotting that! The -= is correct, however, as the welt->get_settings().cst_buy_land itself returns a negative number. I pushed the fix to the 10.x branch.

There might be something to be said for reforming the cost of land generally and having that as an additional cost on top of other things for building, as well as having different cost for buying land in town and in the country, and different depending on the size of the town, as well, when the time variable prices system is implemented, having these inflating at different rates. This could be done at the same time as the forge cost. This could also include making it more expensive to tunnel under buildings than roads, a factor which greatly influenced the early London Underground network.

Edit: There is probably also something to be said for greatly increasing the cost of "demolishing" rivers, to represent the cost of putting them in an underground culvert.

[RustyMachnik]

A man is smoking a cigarette which he got from ecigfiend and blowing smoke rings into the air.  His girlfriend becomes irritated with the smoke and says, "Can't you see the warning on the cigarette pack?  Smoking is hazardous to your health!"

To which the man replies, "I am a programmer.  We don't worry about warnings; we only worry about errors."

It was real good one..But still smoking is not good..But who cares about warning..

[jamespetts]

Welcome to the forums! I do agree about smoking.

[AndrewTraviss]

Hi, I only just discovered Simutrans and I've been looking for a good open source project to contribute to. With my love of transport simulations this seems like a great choice. It's been quite a long time since the list of projects was updated, but provided that it's up to date, I think that "Usage based vehicle maintenance costs" would be a great way to get my feet wet?

My C++ experience is practically zero, but I've been developing software in a professional capacity for over 10 years, so I'm pretty confident with my ability to ramp up.

[jamespetts]

Hello and welcome! Thank you for your interest in contributing to Simutrans-Experimental, a fork of Simutrans intended to provide extra depth and realism. It will be excellent to have more contributors.

Are you familiar with Github? The project repository is here. The relevant code is in the vehikel_besch_t::calc_running_cost function in vehikel_besch.cc, which is actually the first function in that file.

There is currently a calculation in there referring to an "obsolescence increase". This mechanism should be replaced with the new mechanism relating to usage based maintenance costs above.

There are a number of things to bear in mind when implementing this feature, as it is a balance critical feature. Firstly, it must be able to be calibrated per vehicle so as to allow pakset authors to calibrate this with some precision, so you will need to add some .dat file parameters (as well as removing the old ones for obsolescence, and dealing with existing .pak files that have what will be the deprecated obsolescence code). Secondly, you will need to set a sensible default for when the pakset author has not specified any usage based increase in the .dat files, which should be realistic. Thirdly, there needs to be a representation in the UI (the depot window and the convoy details window) that this is happening: the latter already shows the obsolescence increase. You will need to think carefully how to represent this to the player clearly without taking more than a very small amount of space in the already somewhat full UI. The existing UI uses the colour DARK_BLUE in places to indicate that vehicles are obsolete in the current system. You will need to remove this, and consider whether to use that colour to indicate something relating to this feature (but that is not an easy translation, as this feature is not binary in the way that the obsolescence feature is).

Fourthly, it is particularly important that this feature integrate closely with the forthcoming vehicle overhauls feature (also on the list, just underneath the increased maintenance costs item). When a vehicle is overhauled, its wear based maintenance costs should reset to something close to (but not necessarily identical to) their as new value. Those two features were always intended to work together. Edit This means that you will need to store kilometres travelled since the last overhaul somewhere (but not simply replace the existing total km travelled odometer).

To give an idea of what I am doing at present, my current work is on railway signalling (I am about to amend the list to show that I am working on that), after which I will be concentrating on a number of the remaining balance critical features, including a feature-set not listed at the time of writing (albeit I am about to add it) but the necessity for which is discussed here) relating to being able to modify convoys automatically other than in depots to be able to achieve railway locomotive changes and the like, which it turns out is a balance critical feature, and also is closely related to signalling, so makes sense to follow on directly from that project. The intention is to aim for a next release in which all of the balance critical features are implemented so that they can be thoroughly tested and that pakset balancing can then get underway in earnest.

As to C++ programming, I do not know what other languages that you have used, but if you are familiar with Java, for example, the main thing to watch out for in C++ is manual memory management. If you are familiar with C, you should know all about that in any event. I should add that I am entirely self taught and have never worked in programming professionally, so you will have a head start on me in any event.

Thank you again for your interest in Simutrans-Experimental - do let me know if you have any further queries or get stuck. (For more detailed discussion of the implementation of this feature, I suggest that you start a new thread: I prefer these discussions to be in public where possible so that others can add things that neither of us have thought of and also so that others can learn from it).

Edit: Incidentally, I now recall that I had thought at one stage that it might be worthwhile to have a system in which convoys have to visit a depot regularly for maintenance. That system would work by not requiring the convoy to visit the depot at any particular time, allowing players to add depot visits to a schedule for convenience, subject only to a long-stop maximum time to prevent players from not sending their convoys to depots at all, but for the time spent in the depot being maintained to be proportionate to the amount of time that the vehicle has spent out of the depot running (or perhaps the distance that it has travelled) using an availability percentage figure, which is set in the .dat files, and which varies depending on how well used that the vehicle is in the same way as the maintenance costs will vary depending on total distance travelled. This is important because it reflects the real life concept of vehicle availability, which is balance critical because has a very significant impact on capital asset utilisation. Indeed, I will re-amend the list now to add this on that account.

[AndrewTraviss]

Thanks for the quick primer on the relevant code.

I haven't really worked with a manually-managed language before, but I'm at least aware of the concerns that come along with it, and I have access to fellow developers that can help me figure my way through it.

And yeah, I can see that this ties into several other mechanics in various ways. I hope you don't mind if I offer some thoughts on how this will all fit together (I'm also a game designer, as it happens). I'll create a separate thread on the topic with my thoughts.

[jamespetts]

Thanks for the quick primer on the relevant code.

I haven't really worked with a manually-managed language before, but I'm at least aware of the concerns that come along with it, and I have access to fellow developers that can help me figure my way through it.

And yeah, I can see that this ties into several other mechanics in various ways. I hope you don't mind if I offer some thoughts on how this will all fit together (I'm also a game designer, as it happens). I'll create a separate thread on the topic with my thoughts.

Excellent - I shall look forward to your thoughts! Please note that I have added a section above on "Depot visits and availability" that you may want to read before posting the other thread.

[AndrewTraviss]

Alright, I have some ideas based on what you wrote. I think I will create a thread to discuss the overall design of maintenance, rather than focusing on just one or two of these features, as it seems maintenance is being completely overhauled as a concept between all of the outstanding items.

Should this discussion happen in the Development board, or on the main Experimental Discussion board?

[jamespetts]

Sorry for the delay in replying: if you are discussing the merits of possible new features, rather than just the mechanics of implementation, may I suggest that the thread be posted in the discussion board rather than the development board?

I shall look forward to reading it in any event.

[AndrewTraviss]

Now that I'm actually digging into the code, I suspect that all of the German is going to be more of an obstacle for me than C++

[Rollmaterial]

Now that I'm actually digging into the code, I suspect that all of the German is going to be more of an obstacle for me than C++

This thread should help you with that.

[AndrewTraviss]

This thread should help you with that.

Oh, excellent. Thanks!

[jamespetts]

I have tried to translate some things in comments where possible. If you get stuck with anything, let me know.

[NoMorePacers]

Would the liquid insolvency for network games only thing require only a bit of tinkering with simuconf.tab, or is it wider-scale?

[jamespetts]

It would require changes to the code: if it were only changes to the simuconf.tab file, it would have been done long ago.

[jamespetts]

I have updated this to add reference to a possible future feature, waiting time limits based on individual stops, and revenue from stop extension buildings.

[jamespetts]

I have added two further items to the list, both relatively minor features affecting trams and road vehicles.

[jamespetts]

I have updated this list to acknowledge the completion of the low bridges feature from earlier in the year, to move completed projects to another post as space was running low in the original post and to add a new project, industry road connexions.

[jamespetts]

I have updated this to add several features discussed and considered recently, as well as to update the text of the proposed car parking feature to fit in with recent developments in passenger generation and classes.

[jamespetts]

I have updated this to add fractional power and tractive effort values.

[freddyhayward]

I understand that current development is focused around bug fixing and other more pressing issues (and I lack the skills to contribute code), but I wanted to share my thoughts on private car behavior. The key limitation as I see it is that only one vehicle per direction can occupy a 125m stretch of road at any given time. Currently, ludicrous situations arise from this such as small towns becoming gridlocked. cars also slow down large maps significantly, but disabling them results in congestion dropping to 0, reducing public transport usage. Regardless of CPU performance, it would be impossible to realistically simulate private car traffic on a one-car-per-tile basis. I see three possible approaches to this problem, each of increasing complexity. All, I believe, would produce far more realistic results than the current.

1) retain physical car simulation but represent multiple simulated cars as one physical car. For example, at 5 simulated cars per physical car, an 8-tile (1km) stretch of road would have a capacity of 40 private cars per direction at a given time rather than 8.

2) abandon physical car simulation. calculate traffic, routes & congestion per town. adjust per-town speed limits based on congestion. A particularly congested city might limit the speed of all buses within its borders to 35 km/h.

3) abandon physical car simulation. calculate traffic, routes & congestion per tile. adjust per-tile speed limits for player road vehicles: for example, a bus travelling on a congested section of a city street might be limited to 25km/h.

[ACarlotti]

There is another option that would partly help - allowing multiple vehicles to occupy a single tile while travelling in a single lane.
I think the graphics scale is approximately 30m per tile*, compared to a default physics scale of 125m per tile. So effectively we are simulating modern cars as if they are 16m long instead of 4m long. If we allow multiple vehicles in a tile, then a stationary queue would have approximately 1/3 of the capacity it would have in real life (allowing for a bit more space between cars in real life). The impact only flowing traffic would be less - maybe 50%-80% of the real capacity for a city road, and perhaps >90% of the real capacity for motorways.

[freddyhayward]

Another advantage of that approach would be its application to player vehicles. In reality, an advantage of buses (and trams, though these are handled as rail vehicles) is that multiple vehicles from different routes can board at a single stop simultaneously. This is currently impossible on two-way road tiles. As someone familiar with the game internally, how feasible would your option be? OpenTTD has this feature:

[jamespetts]

I agree with A. Carlotti - this would be a preferable solution and also assist with player vehicle interactions with each other. However, this would be a substantial and complex coding project interacting with some code that has so far remained untouched from Standard and there are many higher priorities for my time at present, and I am hampered in what I can do by needing to upgrade my computer, but the parts for doing so being not available until next month.

If anyone else would like to implement the feature of road vehicles being able to occupy fragments of a tile (tiles are divided into 1/16ths for some purposes and vehicle lengths can be specified in their .dat files as these 16ths), so there are at least some fragments of code in the existing game that can in principle be extended to support this.

[ACarlotti]

As someone familiar with the game internally, how feasible would your option be?

It would be a substantial undertaking, which should possibly be tied in with changes to how junctions and lanes work. I think there has already been suggestion of reworking some of this stuff in Standard, but it is definitely a long-term ambition rather than and easy patch.

[jamespetts]

I have modified this thread to document the recent incorporation of the insolvency features and private car routing.

[Sirius]

Notice that you might want to adjust the congestion measurement paragraph of Private road traffic simulation section.
It seems to be an outdated description.

[jamespetts]

Notice that you might want to adjust the congestion measurement paragraph of Private road traffic simulation section.
It seems to be an outdated description.

I have added a note at the end of the original description explaining the system as implemented.