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 enhancementsThe 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 overhaulsIf 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 vehiclesPlayers 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 capitalCurrently, 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 facilitiesCurrently, 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 tramsCurrently, 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 improvementsCurrently, 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.
