The International Simutrans Forum

Simutrans Extended => Simutrans Extended Discussion => Topic started by: jamespetts on April 20, 2009, 10:49:19 PM

Title: Overview of Simutrans-Extended features
Post by: jamespetts on April 20, 2009, 10:49:19 PM

 Last modified: 10th of December 2017 for Simutrans-Extended nightly development builds (13.x).

Simutrans-Extended has been developed to provide additional features not found in Simutrans-Standard, and also to modify some existing features to change the overall balance of the game. The emphasis is on economic and operational realism, improving the gameplay balance, increasing variety, and making the game more challenging in the later stages (where, in Simutrans-Standard, it can be very easy), and less challenging in the earlier stage (where, in Simutrans-Standard, it can be very hard): in other words, to have a longer, smoother learning curve. There follows a brief summary of each of the main ways in which Simutrans-Extended differs from Simutrans-Standard, divided into three sections: (1) economics and finance; (2) operations; and (3) miscellaneous. Only significant changes are shown here. Minor changes (mainly to the GUI) are not listed.

As of December 2017, this list is split into two parts, as the text limits for a single post prevent all the necessary data being fitted into a single part.

Part I

1. Economics and finance

Revenue calculation and passenger and mail classes

In Simutrans-Standard, the revenue is calculated based on the type of goods transported, the quantity of the goods transported, the distance, and the maximum achievable speed of the convoy (taking into account the speed limits of the individual vehicles and the ways (roads, rails, canals, etc.) over which they pass) in which they were transported relative to a set list of speeds for transport networks of that type set in a file named speedbonus.tab. Those numbers generally increase with time. The revenue is calculated for all passengers and goods at every intermediate stop ("hop") whether or not those goods board or alight there. In more recent versions of Simutrans-Standard, the revenue is limited to the proportion of the total distance to the destination that the journey gets the goods or passengers nearer, which can result in negative revenue in some cases. (Until version 111.0, this bonus was based just on the maximum speed of the slowest vehicle in the convoy).

In Simutrans-Extended (as of 13.0 and later), the revenue is based on the type of goods transported, the quantity transported, the distance, for passengers and mail, the class of those passengers or mail and that of the accommodation in which they are transported, and, for passengers, the comfort of the means of transport. Speed no longer has any effect on revenue (and the "speed bonus" of Standard does not exist), but speed does affect routing, in that passengers, mail and goods will always prefer to travel on the route with the lowest journey time of all available routes.

For passengers and mail, they will each be generated with a level of wealth/ability to pay. Players can set prices for individual convoys (and vehicles within convoys) to match what passengers/mail of particular classes can pay. Passengers/mail of a lower class will not be able to afford to travel on a particular route if players set the prices too high. Passengers/mail of any given class will travel on the route with the lowest journey time of all those routes available to them in light of the prices.

The total revenue is calculated at the end of each journey leg (rather than, as in Standard, each time that the convoy stops): in consequence, it is easier to see where the profit is being made. Furthermore, it is possible to have catering or travelling post office vehicles that further increase the revenue for passengers and mail respectively on longer (but not shorter) distance journeys, the extent to which they increase the revenue varying with the length of the journey.

The aim of this feature is to make the calculation of revenue more realistic and intuitive: the revenue no longer depends on what to the people paying for transport is irrelevant (the theoretical maximum speed of the vehicles and ways over which they operate), but rather on the basis of a realistic interaction between (for passengers and mail) the amount of money available to spend on transport, the competition for the route, the journey time, and, for passengers, the comfort.

Another aim is to provide more incentive to players to use a greater variety of vehicles, and to pick the right vehicle for the right job. No longer will it always be more profitable to use the fastest vehicle for every kind of transportation. Beginner players' heuristic judgments about what sort of vehicle is right for any particular sort of work, made without reference to the detailed rules of the game, should be right more often. Local transportation should be more profitable than it is in Simutrans-Standard. Excessive revenues can no longer be earned by transporting large numbers of passengers/mail/goods by very fast means of transport.

Comfort

In Simutrans-Standard, there is no concept of comfort: the only differentiation between vehicles is their theoretical maximum speed.

In Simutrans-Extended, each passenger carrying vehicle has a comfort rating. This corresponds to the maximum comfortable journey time that passengers may spend in that vehicle. Passengers will still travel when the vehicle's comfort is lower than their comfortable journey time, but will yield less revenue in consequence. Paksets can be configured so that passengers pay a bonus fare when the comfort exceeds the passengers' maximum comfortable journey time, but this feature is no longer used on Pak128.Britain-Ex as it is superseded by the passenger and mail classes feature (discussed above).

Comfort is important for distinguishing between different classes in the same convoy. Passengers who can afford to pay for a higher price of accommodation will only do so if the better accommodation is more comfortable than the cheaper accommodation, or the cheaper accommodation is full or overcrowded. Passengers will always upgrade to the higher class of accommodation if the cheaper accommodation's comfort is below the maximum comfortable journey time for the passengers' journey, but will only sometimes do so otherwise (some passengers are more willing to pay more for extra comfort than others). Please note that, for technical reasons, it is not possible within a reasonable level of performance to have a workable system in which passengers take into account comfort in deciding which route to take. This might be possible in a future time where CPUs with very many cores (perhaps 16-32) are commonplace.

Passengers who have to stand because they occupy an overcrowded vehicle assume their comfort to be 10 (or lower if the vehicle's base comfort is 10) for revenue purposes.

Logistics

In Simutrans-Standard, consumer industries consume goods at a fixed rate per game month. Industries can continue to produce whether or not any passengers (or pedestrians) ever arrive at them.

In Simutrans-Extended (13.0 and later), consumer industries (except for power stations or those with 0 visitor demand, which will continue to consume at a fixed rate) will consume goods in proportion to the number of visitors. For example, a consumer industry with a monthly visitor demand of 100 and a monthly consumption of 50 units will consume 0.5 units for every visiting passenger that visits the industry. If the consumer industry has no goods in stick

Industries that have many unfilled job slots (by default, more than 20% for producing industries) produce proportionately less - for example, an industry with 50% jobs filled will produce 50% of its normal output. An industry with 0% of its jobs filled will not produce anything at all. Consumer industries will not accept visiting passengers if the staffing level falls below 66%. (These percentages can be changed in simuconf.tab).

Staff will be laid off if an industry has no input goods (or, for a producing industry, no input goods of any one type). This means that commuting passengers will not be able to start their journeys to that industry until the goods shortage is rectified.

The aim of this feature is more realistically to simulate the interaction between passenger and goods transport and also to give players a greater incentive to create more comprehensive transport networks.

Debt handling

Note: As of around 2016/2017, a similar feature has now been introduced into Standard, but I have not had a chance to look into how this works in any detail, so I am not sure the extent to which it is similar to or different from the long-standing feature in Extended.

**

In Simutrans-Standard, it used to be the case that a player could go overdrawn by any amount, but a player would go bankrupt if that player's debts exceed her/his/its net wealth at the end of any given month. Going bankrupt in a single player game in Simutrans entails a message dialogue being presented saying "You are bankrupt!", and the option to start a new game appearing in a single player game. If the player chose to cancel that dialogue box, he/she could continue playing despite being bankrupt. In a multi-player online game, the insolvent company will be liquidated automatically. However, in more recent versions, this now works in a very similar way to how it works in Simutrans-Extended (see below).

In Simutrans-Extended, each player has a credit limit. A player can go into debt up to the credit limit. Beyond that, the player cannot spend on any new capital items (such as buying new vehicles, or building transport infrastructure), but can continue to become more indebted meeting ordinary running costs. Interest on that debt will accrue at 10% per month, compound. There is an option to disable insolvency/liquidation. The credit limit is based on the player's assets and recent profitability. The credit limit and interest repayments are shown as graphs in the finances window. The credit limit does not apply to the public service player. Additionally, a positive bank balance attracts a credit interest rate of one quarter of the debit interest rate. There is a separate "solvency limit", which determines when a player becomes insolvent, which is calculated in the same way as the credit limit beyond which a player cannot borrow further, but is more generous in amount.

Note that the interest rate, whether players can go bankrupt, and whether players can spend money beyond their credit limit can all be customised in simuconf.tab.

The aim of this feature is to make it easier for players to understand what happens when they go into debt, and make the game more satisfying by removing the difficult choice between giving up a developed game when a player goes bankrupt, or, in effect, cheating, and ignoring the bankruptcy dialogue, and automatically providing a middle course, as well as more accurately to simulate the cost of capital.

Industrial obsolescence, upgrading and density balancing

In Simutrans-Standard, new factory chains can be built, but old ones never close down, although they can be bulldozed by the public service player. Factories can have a retirement date, which means that, after that date, no more factories of that type will be built. New industries are built every time that the population increases beyond a certain threshold specified in simuconf.tab.

In Simutrans-Extended, factories will close down some time within 30* years of their retirement date (exactly when is random, but the chances increase as time passes). Any other factories in the chain will attempt to link to other suitable factories that have not yet closed down. If they are unable to do so, then they will also close. Players will be given a message in the news ticker whenever a factory closes. Factories may upgrade to other factories (if the feature has been configured in the pakset being used) instead of closing. New factories are created when the overall industry density to population ratio falls below the industry density to population ratio that obtained when the game was first started, thus maintaining the same overall industry density throughout. How individual factories contribute to the industry density can be set by the pakset authors, so that a change in the overall amount or production of industry over time can be simulated. Pak128.Britain-Ex, for example, uses this feature to simulate the industrial decline in the UK from the 1970s onwards.

The aim of this feature is to simulate changing patterns of industry with time, and to give players with established networks a greater challenge in dealing with changing circumstances, as well as to balance industry creation more precisely than it was balanced before.

* This number is variable in simuconf.tab. 30 is the default.

Passenger generation

In Simutrans-Standard, passengers prefer local destinations in early years, but less so in later years. There is a single "locality" factor which changes with time which determines that preference. Passengers are generated with only a single destination. Passengers are generated from any city buildings, and can be bound for other city buildings, attractions, and industries.

In earlier versions of Standard, passengers would have a roughly equal chance of going to any destination anywhere on the map. The effect of that was that the number of passengers who travel on a player's network increases exponentially with the number of different places served. With only a few places served, very few passengers would use a player's network. With a large number of places served, an overwhelming number of passengers would use the network.

In Simutrans-Extended, passengers are generated only from residential buildings, and can be bound for commercial/industrial city buildings, industries, attractions, player buildings (such as depots or signalboxes) or other residential buildings. Passengers can be either visiting or commuting passengers (the proportion of which can be set in simuconf.tab). Commuting passengers have different destination preferences to visiting passengers (commuting passengers never head for residential buildings, for example, whereas visiting passengers sometimes do). Commuting passengers head for buildings with available jobs; visiting passengers head for buildings with a visitor demand. Different buildings generate/demand different proportions of passengers of different classes (and see above on passenger classes/levels of wealth).

Passengers are instead limited by the journey time tolerance (see in detail below), but can have multiple preferences of destination so that if, for example, a passenger's first, second and third preference destination is not reachable at all or within the passenger's journey time tolerance, the passenger can head to her/his fourth preference destination building.

Note that the behaviour of this feature depends largely on settings in simuconf.tab.

The aim of this feature is to reduce the differential between the number of passengers that a player can transport near the beginning of the game and the number of passengers demanding to be transported when a player's network is large and well-developed, and also to make passenger demand more predictable and realistic.

In older versions of Simutrans-Experimental (as Simutrans-Extended was called at the time), passengers would prefer geographically proximate destinations, but this was found to cause distorted passenger generation, so it was replaced with the current system, which scales better and is more stable.

Journey time tolerance

In Simutrans-Standard, passengers will travel anywhere, no matter how long that their journey will take. In Simutrans-Extended, passengers will only travel if the estimated journey time to their destination is less than those passengers' journey time tolerance.

The journey time tolerance is a semi-randomised figure, based on: (1) how far that the passengers are planning to go; (2) whether the passenger is a visiting or commuting passenger; and (3) a range of values set in simuconf.tab. If a proposed journey is longer than the passengers' journey time tolerance, the passengers will not travel, and will display "too slow" (similar to "no route") in the graphs of the stop that they would have used. The destinations of passengers whose journey would be outside their tolerance level is shown as pink on the passenger destinations map.

The aim of this feature is to enable players to generate additional revenue streams by reducing the travelling time between towns, and also to simulate the difference between actual and latent demand for transport, and the fact that latent demand will only materialise into actual demand in many cases when the travelling time is low enough. It should also make playing in early times, when only slow, low-capacity transport is available, more realistic, as only a number of passengers commensurate with the capacity of the transport networks of the day will be generated.

Transfer times and passenger walking

In Simutrans-Standard, all goods and passengers within a stop's catchment area (which typically fairly small - generally 2-3 tiles) go to any station/stop within that catchment area, based only on which station/stop can provide the route with the least transfers and intermediate stops to their destination. As noted above in relation to journey time tolerance, journey time is not measured or considered at all. Passengers will walk to their destination whenever the origin and destination is within the catchment area of the same stop, but never otherwise, however close the origin and destination are, and however much faster that walking would be than using public transport.

In Simutrans-Extended, the journey time, used for determining which route to take and the passengers' journey time tolerances, includes the time that it takes goods to be moved by hand (at 1km/h) and passengers to walk (at 4km/h; can be changed in simuconf.tab) from their ultimate origin to their origin stop and from their destination stop to their destination. At every transfer (where goods/passengers change from one convoy to another), a transfer time, based on the size of the station/stop, will be added to the journey time to represent the time that it takes to walk from one part of a station/stop to another, or the time that it takes to transship goods inside a station/stop. Transfer times are increased when stations/stops are overcrowded. Passengers will always walk to their destination whenever the total journey time is within half their journey time tolerance and the overall journey time is lower than a route using a player's transport, but not otherwise.

This feature works best when the station catchment area is much greater than in Standard (8-12 tiles is recommended for passengers). Also in Extended, the coverage for freight is different than for passengers: by default, it is 3. This is to represent the fact that passengers can walk further than freight can be hauled by hand.

The aim of this set of features is more realistically to simulate the interaction between walking and public transport, to make the placement and size of stations significant in a realistic way, to prevent players from gaining an advantage by building one large station covering an entire town rather than building a local transport network, and more accurately to simulate the total journey time between the ultimate origin and ultimate destination, as well as to simulate the relevant differences in this regard between freight and passenger transport.

Private cars

In Simutrans-Standard, passengers will always use the player's transport network if available. The number of private cars visible in the map bears an approximate relationship to the number of passengers who want to be transported but cannot find a route on the player's transport. This does not vary over time.

In Simutrans-Extended, some passengers have access to a private car. The proportion of such passengers varies with time (the figures are set in a special file named privatecar.tab - the default version is based on UK government statistics), but generally increases as time progresses. Whether passengers prefer to use a private car or a player's transport will depend mainly on the which mode of transport has the lower door to door journey time. However, a certain proportion of passengers will always prefer to use a private car provided that there is an available private car route to their destination and the journey time for using a private car is within their journey time tolerance. Every private car trip generates congestion in the cities to, from or within which private cars travel. The more congested that a city, the slower that private car journeys in that city will be, and the more likely that passengers will use a player's transport instead. Congestion impacts adversely on the rate of growth of a city, and, if it is too severe (100 or more on the graph), stops it from growing entirely. Players can relieve congestion by improving passenger transport in and around the city. The number of private car trips is always directly proportionate to the number of private car graphics visible in the main game window. The "citycar_level" parameter in Simuconf.tab scales non-linearly: 16 is equivalent to an average car occupancy of 1, and 11 (the default for version 9.3 onwards) is equivalent to an average car occupancy of 1.6. Some private cars have express origins and destinations (which are shown in their information window when the user clocks on them), and visibly tend to travel towards their destinations (although, to save CPU time, they do not have carefully calculated routes in the same way as player transport); this part of the feature was written by Prissi, the main developer of Simutrans-Standard, but is not operational in the released version of Simutrans-Standard. The version in Simutrans-Extendedis modified to control the number of private cars in the game world more effectively. The destinations of passengers who undertake their journey by private car is shown as turquoise on the passenger destinations map.

The game will check to see whether two towns are connected by road (and, if so, how long/fast that the road connexion is), and whether passengers will take their private cars or not will depend on whether the destination (be it an industry, attraction or building in another city) is connected by road to the origin, and the relative journey times by road and by player's transport. Note that this feature can be disabled by setting "assume_everywhere_connected_by_road=1" in simuconf.tab, in which case the game will proceed on the assumption that everywhere is connected by an average sort of road.

Private cars can generate road tolls for players who build private roads and allow access to the public player; if access to the public player is not allowed, private cars cannot use a player's private road.

Note that how congested that cities get, the proportion of people who prefer to use private cars either generally, or all the time, and some other related matters can be customised in simuconf.tab.

The aim of this feature is to provide more depth and interest in relation to the simulation of passenger transport, and also to provide additional challenges for players with well-developed networks, who will have to deal with additional competition from private cars, and make difficult but interesting decisions about whether, and if so, by how much, to cut back on transport connexions to smaller towns when private car usage increases (knowing that some of the connexions might need to be restored if congestion becomes a problem in those towns).

Obsolete vehicle running costs

In Simutrans-Standard, vehicles go out of production, but there is no functional difference between an obsolete vehicle and a current vehicle.

In Simutrans-Extended, vehicles become obsolete a certain number of years after they go out of production. Once they become obsolete, they cost more to maintain than current vehicles. The cost of maintaining obsolete vehicles slowly increases with time until it reaches a certain percentage (by default, 400%) of the normal value, when it ceases to rise any further. The increase is linear over a set number of years: 40 by default.

Note that the calibration of this feature can substantially be customised in simuconf.tab, including the extent of the increase, and the time over which it comes into effect. It is possible to revert this feature to the behaviour of Simutrans-Standard by changing settings in simuconf.tab.

Fixed maintenance costs

In Simutrans-Standard, all vehicle maintenance costs are paid per kilometre. If the vehicle does not move, it does not incur any operational costs.

In Simutrans-Extended, vehicles can be set to have a fixed monthly cost as well as a per kilometre cost. This is achieved by using the "fixed_maintenance=" value in the vehicle's .dat file by the pakset author. The function is dependant on the pakset - using paksets designed for Simutrans-Standard will give the same behaviour in relation to running costs as Simutrans-Standard. From version 9.3 onwards, this cost will be reduced by 95% (to 5% of the original cost) when a vehicle is stored in a depot to represent the fact that most of this cost is the staff cost of running the vehicle, but some small element of maintenance is necessary even on a vehicle that is not used to keep it in a serviceable condition.

The aim of this feature is to provide a more realistic means of calculating the running costs of vehicles, and create a stronger incentive for players to run more efficient networks. See here (http://forum.simutrans.com/index.php?topic=1920.0) for more information.

Scale

In Simutrans-Standard, 1 tile is taken to be 1 kilometre. There is no separation between UI representation of tiles and UI representation of kilometres. All of the building cost and maintenance settings in paksets are per tile settings.

In Simutrans-Extended, there is a variable scale. This is set by a distance_per_tile setting in simuconf.tab. This represents the distance of every tile in units of 10 meters. Therefore, distance_per_tile=100 means that each tile represents 1km. At the default setting of distance_per_tile=25, each tile represents 250m, meaning that there are four tiles to the kilometre. All distance based settings, including the cost of building and maintaining roads, tracks, canals and tunnels and bridges (bridges only after version 9.3), the distance dependant (but not fixed) cost of maintaining vehicles, and the revenues from each type of cargo (including mail and passengers) are adjusted accordingly. Thus, if the cost of building one tile of track in Simutrans-Standard is 100.00C, in Simutrans-Extended with the default distance_per_tile=25, the cost is 25.00C. Likewise, if the revenue from transporting a tonne of coal accross a tile is 1.00C in Simutrans-Standard, in Simutrans-Extendedwith the default setting, it is 0.25C. The scale can be displayed by opening the map window and selecting "show map scale". Also, the scale affects the physics, so that a convoy that would accelerate to any given speed in 10 tiles with a distance per tile of 250m would accelerate to full speed in 5 tiles with a distance per tile of 500m.

The aim of this feature is to allow for more separation between short, medium and long distance transport, which is necessary for the journey time tolerance, comfort and catering features to be used to their full potential. A full discussion of this feature can be found here (http://forum.simutrans.com/index.php?topic=2797.0).

Station capacities and costs

In Simutrans-Standard, until recently, the capacity, purchase price and maintenance cost of all station/stop buildings were tied together in fixed proportions. Pakset authors could only change the "level" of a station/stop, which changes all of those parameters proportionately. Recently, however, the feature described below that was initially written for Simutrans-Experimental (as Simutrans-Extended was then called) was added to Simutrans-Standard.

In Simutrans-Extended, it is possible to set the capacity, purchase price and maintenance cost of stations individually.

The aim of this feature is to allow for some stations to be more cost effective than others, and to allow for more economic fine-tuning of paksets generally.

Depot traction types

In Simutrans-Standard, any depot for the particular way type (rail, road, air, etc.) can build any type of vehicle for that way type (with the exception that electric vehicles can only be built in electrified depots).

In Simutrans-Extended, depots can be set to build only certain types of traction (steam, diesel, sail, etc.). They can be set to build one or more of the various types.

The aim of this feature is to allow the cost of depots for different types of transport to be more finely tuned, and give players additional considerations to take into account when branching out into new types of traction.

Geometry

In Simutrans-Standard, the distances for the purposes of calculating trip revenue, calculating vehicle running costs, calculating way maintenance costs and calculating way building costs are simplified Manhattan distances (http://en.wikipedia.org/wiki/Taxicab_geometry). This means that diagonal routes are no cheaper or faster than straight routes with a single 90 degree bend half-way along the route.

In Simutrans-Extended, all such distances (and also for the purpose of calculating journey times and average speeds, which are not calculated at all in Simutrans-Standard are based on the Euclidian distance.

The aim of this feature is to give players a proper incentive to use the truly shortest route between any given points, all other things being equal, and to make the calculation of revenue and cost more transparent and fit better with what appears to be the distance in the game world.

Industry generation

Note: in Simutrans, "industry" includes producers of raw materials, such as mines, farms and fisheries, and ultimate end-consumers, such as shops.

In Simutrans-Standard, the production/consumption rates of all industries are set at a random value within a predefined range. In more recent versions, industries require passengers/mail/electricity for increases in their production or consumption, and can grow if used heavily. The number of passengers demanded are now also set per factory (these new Standard features are also present in Extended).

In Simutrans-Extended, consumer industries (i.e., those that consume but do not produce, such as shops) intended to be located in cities will have their visitor demand (which will affect the number of visiting passengers, and thus the rate of consumption when those passengers arrive) set proportionately to the size of the city compared to other cities. There is also an improved system for linking producing industries to consumer industries with unsatisfied demand.

The aim of this feature is to make the goods consumed by a city proportionate to its size, which is more intuitive and makes network planning more realistic, as players are able to foresee, for example, that more goods will need to be shipped into a large city as more shops open, etc..

2. Operations

Routing of goods and passengers

In Simutrans-Standard, goods and passengers find the route with the fewest intermediate transfers (changes) between their origin and destination. If there is more than one possible route with the same, lowest number of transfers, it effectively picks one of them at random. Passengers that can walk to more than one origin station will choose from which station to depart at random, then find a destination, then check to see whether they can get to that destination from that origin. Goods and passengers will always board the first convoy that will take them to where they are going, provided that there is enough space. Passengers not within reach of a stop will not walk to their destination however close that it is.

In Simutrans-Extended, the journey time for each route is calculated, and passengers and goods will automatically take the route with the shortest journey time. The waiting time for goods and passengers bound for each station at each station is also calculated and added to the journey time when calculating the shortest route, as is the time walking/being hand hauled from the passengers/goods ultimate origin to the origin stop/station, and from the destination stop/station to the ultimate destination, as well as the transfer times when changing between one convoy and another at a stop/station. The journey time and waiting time for each direct connexion from each stop is visible in the stop's detail window. The walking/hand hauling time to nearby stations is shown in city buildings' and industries' information windows. The transfer/transshipment time is shown in stations'/stops' detail windows. Where passengers are within reach of more than one origin stop, they will first choose their destination, and then see which, if any, of the origin stops within reach connects to their destination, and then choose to depart from the one with the shortest route (measured in journey time (including waiting time and walking/transfer time)) to their destination. Passengers who have not been waiting very long at a station will wait for the line or convoy with the shortest journey time, but will board anything that gets them to their destination if they have been waiting a while (how long that they will wait for the best line or convoy is proportionate to the likely overall journey time). Passengers will always walk to their destination if they are close enough. A side-effect of this feature is that it is now possible to see the origins of goods and passengers when looking at a convoy or station.

Note that one or two aspects (such as the maximum search depth) of this feature can be customised in simuconf.tab.

The aim of this feature is to promote realistic competition between different players, or even different forms of transport operated by the same player, and have goods and passengers use the network in a realistic way, requiring players to respond to the demand for the best route. Players can now take passengers away from other players by providing a faster route to their destination. This also incentives players to have a high enough service level to avoid overcrowded stations, as overcrowding leads to increased waiting times, and discourages passengers from using that route.

Overcrowding handling

The handling of overcrowded stops in Simutrans-Standard varies depending on the configuration option selected. One "avoid_overcrowding" causes goods or passengers to be lost from the player's network when they detect that their next transfer station is overcrowded; another, "no_routing_over_overcrowding" stops any route being found at all if one of the stations on that route is overcrowded. Other than that, there is no limit to how overcrowded that staitons can be. In some cases, approximately 27,000 passengers have been known to be waiting at a station with a capacity of around 7,000.

In Simutrans-Extended, "avoid_overcrowding" means that the passengers or goods are discarded when they reach the station that is overcrowded, not when the next transfer is overcrowded. There is no "no_routing_over_overcrowding" setting, because that often leads to unrealistic deadlocks that are likely to be confusing and frustrating for players. Also, if passengers or goods (except for goods, such as coal, that do not care about how fast that they are transported) have been waiting more than a certain amount of time to board a convoy, they will leave the network entirely, never to return. A refund will be payable in respect of these goods for what has been paid for their journey so far (approximately). This is shown in a "refunds" graph in the line or convoy that would have transported the goods/passengers onwards had they not had to wait too long. The amount of time that goods or passengers are prepared to wait is proportionate to the estimated journey time. Whenever passengers leave in this way, they record as "unhappy" on the station's graph, which affects the revenue of all passengers travelling from that station for that month; likewise for when passengers leave an overcrowded station with "avoid_overcrowding" enabled.

Overcrowding will also increase the transfer time of an overcrowded stop (i.e., the time that it takes for passengers/mail/goods to make their way through the stop and transfer to their next connexion or enter/leave the stop).

Note that the behaviour on overcrowding, including the time that passengers/goods will wait before leaving, can be customised in simuconf.tab.

The aim of this feature was to avoid the overwhelming levels of overcrowding possible in Simutrans-Standard, and to provide the player with a realistic monetary incentive not to have stations overcrowded for any significant length of time.

Weight limits

In Simutrans-Standard, vehicles of any weight can traverse any way without penalty. (There has been discussion of adding a weight limit feature to Standard, implemented differently to that in Extended, but, as of June 2011, no such feature has yet been added).

In Simutrans-Extended, ways (including roads, railways, bridges and tunnels) all have a weight limit. If a vehicle tries to use a way for which it is too heavy, it will either have to travel at a fraction of its normal speed, and will display a message informing the user that it is too heavy. For ways other than bridges, the weight limit is an axle load limit. All vehicles have an axle load (which is not affected by whether they are full or empty), and all non-bridge ways have axle load limits. Bridges' weight limits are based on the total convoy weight (including any load), divided by the maximum proportion of the convoy that can be on the bridge at any one time.

This feature can be customised in simuconf.tab: weight limits can be disabled entirely (which allows reversion to the behaviour of Simutrans-Standard), enforced in the default way described above, or strictly enforced, preventing any routing over overweight ways at all.

The aim of this feature is to give the player more challenges and interesting decisions in the construction of networks, and also to give the player incentives to use appropriate vehicles for particular tasks (lighter vehicles for more minor routes where it is not profitable to install bridges with high weight limits, for example). Weight limits are an important part of transport infrastructure design, so their implementation makes Simutrans more realistic.

Cornering

In Simutrans-Standard, vehicles going around a corner have their "friction" increased, causing them to go more slowly. No account is taken of how sharp that the corners are: the same amount of "friction" is added for any sort of corner. It is not possible to have tilting trains in Simutrans-Standard.

In Simutrans-Extended, corners do not add friction: they impose a speed limit based on the inferred minimum radius of the corner given the scale of the pakset and realistic cornering speed limits for that radius. Tilting trains can travel around corners at higher speed than other vehicles.

Note that the extent to which corners of any particular type make vehicles of any particular type slower can be set in detail in simuconf.tab. It is also possible to set the "friction", although the default is zero. It is possible fully to restore the behaviour of Simutrans-Standard in respect of corners by adjusting settings in simuconf.tab.

The aim of this feature is to make cornering behaviour more realistic, and also give players more comprehensible incentives in relation to network construction. No longer will more powerful vehicles be able to take corners faster than less powerful ones simply because of their power. Corners will affect high speed transport far more than they affect low speed transport, so a network design that works early in the game may well have to be adapted as transport speeds increase. This will give players greater incentive to modify their networks as time progresses.

Physics

In Simutrans-Standard, there is a "power" setting for all vehicles, but there is no tractive effort setting. Also, all hills have the same effect on vehicles no matter how many consecutive hill tiles are climbed. All vehicles brake at the same rate. The physics model is only partly realistic, being a deliberate compromise.

In Simutrans-Extended, powered vehicles can have separate tractive effort* and power parameters. Also, the more consecutive hill tiles that there are, the greater the effect of the hill on the vehicles. This approximately simulates hills of different steepnesses. Vehicles have adjustable air resistance to simulate streamlining. Vehicles have individual braking characteristics that affect how quickly that they brake and therefore how soon that they have to start slowing down. The physics model generally is set to be as realistic as possible.

This feature cannot be adjusted in simuconf.tab.

The aim of this feature is to provide realistic incentives for players developing transport networks: steam locomotives (which tend to have a lower tractive effort than diesel/electric locomotives) have distinct disadvantages compared with other sorts of locomotives, which prompted the development of electrified railways in some places as early as the 1900s, although the expense of electrification meant that only certain sorts of networks (mainly suburban networks, where steam's poor acceleration compared to electric was a more substantial handicap than on long-distance trains, and whose high capacity demand warranted the cost of electrification) benefited from alternative power until diesel locomotives became viable in the 1940s and beyond. This feature should give players more interesting things to think about when choosing which type of vehicle to use for any particular sort of task. Also, this feature combined with the hills and cornering feature should make the sort of railway network that makes economic sense in the early years of the game (many corners, few hills) very different to that which makes sense in the latter part of the game (many hills, few corners), which should prompt players in the latter stages of the game to redesign their railways to meet changing circumstances. Also, the change with respect to hills sould incentivise realistic network design that involves gentler gradients. Further, the braking characteristics feature, when implemented in the pakset, allows the simulation of the fact that, in the early days of railways, the principal limit on trains' speed was not the power of the locomotives but their ability to stop in good time.

* Note that the tractive effort is the starting tractive effort, not the continuous tractive effort.

Way constraints

In Simutrans-Standard, any vehicle can go on any way of the relevant type, except that electrified vehicles cannot go on unelectrified ways.

In Simutrans-Extended, it is possible to define way constraints so that only certain sorts of vehicles can go on certain ways, or certain sorts of vehicle need a particular type of way. There are two types of way constraints: permissive and prohibitive. A permissive way constraint is one that allows a vehicle with a matching constraint to use it. For example, if a particular vehicle requires 3rd rail electrification to run, then it would have the 3rd rail electrification permissive constraint, and would only be able to run on track with the matching 3rd rail permissive constraint (not on track with, say, overhead electrification). Track with a permissive constraint does not stop vehicles without the matching constraint also using it: a diesel train, for example, can run over electrified lines. A prohibitive way constraint is one that prohibits all vehicles except for those with a matching constraint from using the way. For example, some suburban underground rail networks, such as that in London, use very small ("tube") tunnels into which ordinary trains cannot fit. To simulate this, the tunnel would have the "tube" prohibitive constraint, and would only allow tube trains (trains with the matching "tube" prohibitive constraint) to use them. Vehicles with a prohibitive constraint are not stopped from using ways without a matching constraint. For example, tube trains can also run in larger tunnels, or in the open, on stretches of track shared with full-sized trains.

There are no settings for this in simuconf.tab, but, if no constraints on either ways or vehicles are specified in the paksets, then this feature will not be used.

The aim of this feature is to provide more variety of different subtypes of transport network, and to require players to choose appropriate vehicles for particular tasks. Examples of where way constraints might be used are given above.

Reversing

In Simutrans-Standard, all convoys reverse by turning in full 180 degrees. All different types of convoy take exactly the same time to reverse.

In Simutrans-Extended, the amount of time that it takes to reverse, and what is shown graphically when a convoy reverses, depends on the nature of the convoy. This is mainly relevant to trains, although, from circa early 2017, reversing also applies to road vehicles. If the train is a multiple unit and can be driven from either end, it reverses quickly, and does not rotate 180 degrees when going backwards: the formation remains the same. If the train has a locomotive at one end that has to run around the carriages, then it will take longer to reverse. The formation will not rotate 180 degrees: the carriages will stay in the same formation, and the locomotive (which will not itself rotate 180 degrees) will attach to the other end of the train. If the train is hauled by a steam tender locomotive, or some other sort of locomotive that has to be turned on a turntable, it will take even longer to reverse, and the locomotive will rotate 180 degrees, but (generally) the carriages will not.

This function is dependant on having a compatible pakset - paksets produced for Simutrans-Standard will not display this reversing behaviour. It is possible to customise the reversing time in simuconf.tab. It is possible to revert to the behaviour of Simutrans-Standard by using a Simutrans-Standard pakset and configuring simuconf.tab.

The aim of this feature is to provide greater operational depth to the simulation, and give players incentives to use suitable vehicles for particular tasks (multiple units, for example, being faster to turn around, but sometimes less powerful, or more expensive, than a locomotive hauled train).

Overcrowded vehicles

In Simutrans-Standard, all vehicles have a single maximum number of goods/passengers that can be loaded. Vehicles cannot be overcrowded.

In Simutrans-Extended, vehicles may have an overcrowded capacity, which equates to standing capacity for passengers. More passengers can use the vehicle, but those who do will be very uncomfortable, and will adversely affect the comfort rating of the line or convoy, in turn, impacting on revenue (more for longer journeys). Overcrowding also affects loading time. Overcrowded lines or convoys show in purple in the line management and convoy information windows.

This setting cannot be customised in simuconf.tab, but is only operational if configured in the pak files.

The aim of this feature is to provide a deeper and more interesting simulation of passenger transport, in which overcrowding is an important concern. I

Loading time

In Simutrans-Standard, all convoys used to take the same amount of time to load and unload as each other, In more recent versions, loading time has been partly customisable, but there is not a range of loading times based on minimum and maximum loading.

In Simutrans-Extended, all vehicles have a loading time range in in-game seconds. A convoy's loading time range is based on the loading time of the slowest vehicle in the convoy. Different vehicles can therefore load and unload at different rates. How long that it actually takes a convoy to load/unload within that range depends on the number of passengers/amount of goods that are loaded at the stop in question.

The aim of this features is to distinguish between long-distance and suburban transportation, and give incentive players to choose appropriate vehicles for the particular task, as well as simulating the relative inefficiencies of higher utilisations.

Scheduling features

A small cluster of miscellaneous schedule related features are described here. In Simutrans-Standard, there is a "mirror schedule" button, which replicates the schedule in reverse. It does not work effectively for double track railways, where the co-ordinates for the stops are different on the outward and return journeys.

In Simutrans-Extended, there is the option to mirror the schedule automatically, meaning that a vehicle will run through its schedule in reverse order when it reaches the end of its schedule without having to duplicate the schedule. This makes it easier to add extra stops to a mirrored schedule. Also, for twin-track (and higher) railways, the game will automatically detect which platform should be used on the return journey. This feature was designed and mostly written by Yobobandana.

The aim of this feature is to make the management of schedules easier.

Further, in Simutrans-Extended, it is possible to regulate the number of convoys per month departing from each stop on a line when a minimum load is set on any stop(s), as well as an offset to stop large numbers of convoys regularly departing from the same stop at once. These features were designed and written by Inkelyad.

The aim of this feature is to prevent bunching of vehicles in cases where the vehicles behind the first are travelling with a light load, making the spacing of vehicles more even, thus improving the regularity of departures and reducing the average waiting time, as well as making more efficient use of vehicles on a route.

Braking

In Simutrans-Standard, all vehicles of all types brake a fixed distance in before they need to stop and at a fixed and rapid rate. Railway signals reserve paths for trains when a train reaches four tiles in front of the signal. Convoys slow down when they are cornering, but not in advance of corners.

In Simutrans-Extended, have a brake force value. The deceleration of convoys rate is calculated on the basis of their speed, weight, rolling resistance (which can, unlike in Simutrans-Standard, be defined individually in the .dat files of each vehicle) and brake force. Convoys will begin to so that they can stop in time, meaning that convoys with better braking will be able to maintain higher average speeds. Railway signals will reserve a path enough tiles in advance so that the train reserving them can continue without slowing for the signal if the path in front of it is clear. Convoys will also slow down in advance of corners so that they are travelling at the maximum speed permitted by that corner when they enter it. This code has been mostly written by Bernd Gabriel.

The aim of this feature is to provide more realistic handling of the physical properties of moving vehicles such as have an impact on the achievable speed of transport in any given conditions, including providing realistic incentives for better braking power, better signalling and fewer corners.

Note that it is hoped in due course to have a more sophisticated (but optional) system of signalling in which the spacing of signals and the use of distant signals would be relevant to the speed at which trains are able to travel, and that cab signalling or moving block signalling would be necessary for trains to be able to travel faster than a certain speed.

Airports

In Simutrans-Standard, aircraft of any type can land at an airport of any type and runway of any length. There is no concept of a control tower (although some paksets have graphics for them, which are coded as extension buildings).

In Simutrans-Extended, unless otherwise selected in the simuconf.tab file of the pakset, an airport must have a control tower for aircraft to land or take off there. Further, each aircraft has a defined minimum runway length in meters, and cannot land or take off from a runway which is too short. A substantial part of the code for the latter feature was written by Bernd Gabriel.

The aim of this feature is to improve the realism of air transport, to make land and sea transport more competitive against air transport for shorter routes (especially in terms of operating cost) and to make the implementation of air transport networks more interesting and challenging.

Goods and passenger loading

In Simutrans-Standard, goods and passengers (including mail) load onto convoys in ascending order of the route distance of their destination: e.g., if a convoy's schedule is A>B>C>D, when loading at A, the convoy will load all the goods for B before any of the goods for C, and all of the goods for C before any of the goods for D. This is irrelevant if there is enough space on the convoy to load all the goods to all destinations, but is important when there is insufficient space.

In Simutrans-Extended, goods, mail and passengers will load onto convoys in the order in which they arrived, irrespective of the destination. This is intended more accurately to reflect reality, to cause waiting times to be recorded more accurately, to reduce the likelihood of discarding/refunds and to reduce unevenness of the distribution of goods to multiple destinations.

Industries' demand for goods

In Simutrans-Standard, the number of goods that can be in transit to any given industry at any given time is set by a fixed percentage applicable to all industries (note: as at the date of writing, in the nightly builds, but not release builds, this is varied depending on the generating industry's output storage). This can lead in some cases to large fluctuations in demand.

In Simutrans-Extended, the number of goods that can be in transit to any given industry at any one time is based on the proportion of the average trip time to deliver the goods to the time that it takes to consume the receiving industry's full store. The aim of this feature is to provide for more consistent and realistic demand.

Tall vehicles and bridges

In Simutrans-Standard, vehicles cannot travel under bridges of a single/half tile height over a way.

In Simutrans-Extended, some vehicles can and other vehicles cannot travel under bridges of a single/half tile height over a way. Whether a vehicle can travel under a low bridge depends on its height: this can be set by the pakset author with a specific setting in each vehicle's .dat file. When a vehicle is too tall to travel under a low bridge, this is indicated clearly to players when buying the vehicle in question. A low bridge cannot be built over a public right of way except by the public player.

The aim of this feature is to make a meaningful distinction between tall and less tall vehicles (e.g. single and double decker 'buses or sailing ships and barges), and also to give greater utility to lower bridges over ways.

 

3. Multi-player features

Revenue sharing

In Simutrans-Standard, it is possible for players' convoys to travel over other players' ways. Payment for this is calculated either by reference to a proportion of that convoy's running costs (which are charged to the player running over the other player's way, and paid to that other player) and/or a percentage of the cost of the way on which it runs. It is not possible to apportion the revenue between different players.

In Simutrans-Extended, in addition to the two methods of charging for the use of other players' ways in Standard, it is also possible to apportion the revenue between players. So, for example, if player A's barge travels 50km on player A's canal in one trip, and 50km on player B's canal, and the revenue percentage is set to 50%, 25% of the revenue generated by that trip will be paid by player A to player B (50% of the revenue of 50% of the journey).

The aim of this feature is to simulate the way in which transport operators were in fact charged for using other transport operators' canals and railways in the 19th century, and to allow for players to build ways with the intention of letting other players use them, knowing that they will be able to share in the profits generated.

Access permissions

In Simutrans-Standard, players cannot connect to other players' ways. Players can connect to public ways, and can make their ways and stations public. Public ways and stations' maintenance costs are paid by the public service player, and can only be deleted by the public service player. Players can place gates on their ways to prevent access by other players at particular points. When connected, players can always send their convoys over other players' ways unless prevented from doing so by a gate.

In Simutrans-Extended, it is possible for players to give other players permission to access their ways. When a player is granted access, he or she may connect to the ways of the player who granted access, and send convoys over the ways of that player. If access is withdrawn, even a connected player is not able to send convoys over another player's ways, without the use of gates. Additionally (and optionally), private players can no longer pass off their ways and stations to be maintained at the public player's expense.

The aim of this feature is to make it easier to control which players access players' ways, and enable joint lines to be constructed between players without resort to using the public player.

Player colour saving

In Simutrans-Standard, players can change their colour, but this will not be saved with the game or transmitted over the network.

In Simutrans-Extended, the player colour is saved with a saved game and transmitted over the network.

The aim of this feature is to enable players to create a more distinctive identity in online games.

4. Miscellaneous

Automatic convoy replacing

In Simutrans-Standard, to change the vehicles in a convoy, each convoy must be sent to the depot by hand and upgraded manually.

In Simutrans-Extended, it is possible to replace every convoy of a certain sort either in a line or in the whole game automatically, through an easy graphical user interface. This code was written by Isidoro.

The aim of this feature is to make it easier for players to replace a large number of convoys/vehicles at once.

Vehicle upgrading

In Simutrans-Standard, new vehicles can be bought and old ones sold, but vehicles cannot be upgraded to other vehicles.

In Simutrans-Extended, individual vehicles can be upgraded to other vehicles, to simulate refurbishment of vehicles. Refurbished vehicles might have a more powerful engine, or lower running cost, although they will still be the same basic vehicle. Upgrading a vehicle will generally be cheaper then buying a new vehicle. Some vehicles are only available as upgrades to other vehicles: others are available as stand alone vehicles, or upgrades. Only vehicles for which there is a specified upgrade (set in the pak files) can be upgraded.

The aim of this feature is to simulate more accurately the resource management elements of transportation, and to give players further interesting choices about how to manage their vehicle fleets, as well as to give more variety of vehicles.

City electrification

In Simutrans-Standard, it is possible to build electricity grids using power stations (treated as industries, and built by the public service player), substations and high voltage transmission lines. The only effect of these electricity grids is to increase production of industries: any industry connected to electricity substantially increases its productivity by a fixed proportion. Power stations will be built to match electricity demand by industries automatically. The percent of electricity demand that will be supplied depends on the "electricity percent" setting in the "new map" dialogue.

In Simutrans-Extended, it is also possible to connect cities to the power grid. This is done by placing a substation somewhere inside the city limits. Any industry within the city limits will automatically be connected to the power grid without having its own, separate substation. Cities will also consume electricity themselves. The amount of electricity that they consume depends on their size, and also varies over time, according to values set in a configuration file called electricity.tab. Cities connected to the electricity grid (and that have as much electricity as they demand) will grow faster than those not connected. The extent to which electricity makes a difference to city growth also varies with time, in the same proportions as power consumption.

Each city has a graph showing power demand and power consumption, and also a text display showing the total demand in megawatts. Note that the power demand graph will remain at zero unless there is a substation in the city, since that graph shows the amount of electricity demanded by the substation. The text display will show the city's theoretical power demand irrespective of whether there is a substation. All industries, power stations, substations and power lines now show their power output, consumption and capacity in megawatts. The amount of electricity consumed by industries can be adjusted by setting the "electricity_percent" value in the individual factory's .dat file. 100% represents the same amount of electricity consumption as in Simutrans-Standard. 17% is the default, which is thought to be a value that gives a more realistic proportion of power stations to industries. As with Simutrans-Standard, new power stations will be built to match demand, and demand both of industry and of cities will be taken into account.

The aim of this feature is to make the electricity grid system more complete and easy to understand, as well as providing an interesting additiona

Title: Re: Overview of Simutrans-Extended features
Post by: jamespetts on December 10, 2017, 04:48:41 PM

Part II

City placement

In Simutrans-Standard, cities are distributed evenly and randomly on the game terrain when a new game is first generated. A range of sizes of towns are automatically generated, but the only aspect of town size that the player can customise is the median size of the towns and the overall number of towns.

In Simutrans-Extended, there are additional options to determine the number of very large cities in comparison to the ordinary size of towns, to set cities in clusters, for towns to tend to be built more on lower ground than higher ground and for towns to be more likely to be built near rivers and the sea. Also, there are more likely to be rivers generated on high ground, increasing the total number of rivers generated. Most of this feature (with the exception of towns preferring to be built at a lower height) was written by Inkelyad.

The aim of these features is to enable a more realistic and interesting landscape to be generated, to allow, for example, river transport in times before canals or the grouping together of large urban areas whilst still allowing wide open spaces.

City size distribution

In Simutrans-Standard, cities are sized more or less randomly based on a median set when generating the game.

In Simutrans-Extended, city sizes are set according to Zipf's law (http://brenocon.com/blog/2009/05/zipfs-law-and-world-city-populations/) of city size distribution. The code for this feature was written by Richard Smith.

The aim of this feature is to make the landscape on which players play more realistic.

Note: As of circa 2017, this feature has been noted not to be working correctly. It is planned to fix this when town generation/growth is rewritten.

Liveries

In Simutrans-Standard, each type of vehicle has only one appearance, except that it can have different graphics for being empty or carrying different loads, if applicable.

In Simutrans-Extended, vehicles can have different liveries. Liveries are grouped in livery schemes (in each of which, there can be multiple liveries according to date, so that, for example, the scheme "British Railways" can have the liveries "BR Early", "BR Revised", "BR Blue", "BR Large Logo", etc.). Players can select which livery scheme applies to vehicles when bought in a depot, and can additionally re-assign livery schemes to lines.The aim of this feature is to improve the visual representation of historical vehicles over time. This feature has no economic effect.

Bridges and elevated ways

In Simutrans-Standard, bridges can have length and height restrictions, but these are optional. Height restrictions do not discriminate between height above and below water. Where the overall length of a bridge is not restricted, it is possible to build a bridge over a large stretch of open ocean. Further, elevated ways can be built over buildings of any height.

In Simutrans-Extended, bridges with unlimited length cannot be built over deep water (that is, water more than 1 tile below sea level). Further, elevated ways can only be built over buildings of a size of no greater than 2, and larger buildings cannot appear under existing elevated ways.

The aim of this feature is to prevent players building very long bridges over open seas which would not be possible to build in reality, at no greater cost than building bridges on land, which can distort water transport, and further to impose realistic restrictions on the use of elevated ways in heavily built-up areas, confining them to the suburbs of larger towns and cities, and providing incentive to use (more expensive) underground railways instead.

Terraforming

In Simutrans-Standard, it is possible to raise and lower land anywhere (with the exception that one cannot start raising/lowering land in open water). This allows even deep oceans to be bridged with artificial embankments.

In Simutrans-Extended, it is not possible to raise land - even indirectly by raising its neighbours - when it is more than 1 tile below sea level.

The aim of this feature is to prevent players from circumventing the challenge of dealing with seas and lakes by turning them into land.

City roads

In Simutrans-Standard, players are free to delete any city roads without restriction. This allows players to leave large numbers of city buildings disconnected from the city road network when building their networks. Further, players are allowed to build private roads in cities, which remain private and inaccessible to any other player's transport. The city speed limit is a hard-coded 50km/h.

In Simutrans-Extended, players may not delete city roads such as would leave city buildings disconnected from the city. Any road built in a built-up area of a city will be adopted by the city authorities and available to use by all players. The city speed limit will apply, and the city will pay for the maintenance of the road. The city speed limit is the speed limit of the current city road as defined by the pakset's simuconf.tab.

The aim of this feature is to require players to respect the integrity of cities when planning networks, so that players have to work around features already present rather than simply overriding them, and also to prevent players from unrealistically increasing the speed limit in built up areas or from excluding players from cities with private roads.

Settings overriding

In Simutrans-Standard, game settings are specified for new games in the configuration file simuconf.tab. When a game is generated, these values are saved in the saved game, so that, even if simuconf.tab is later changed, the settings in a game already created remain the same. These can, however, be changed using an the advanced settings GUI dialogue for each individual saved game.

In Simutrans-Experimental, it is possible to specify a simuconf.tab parameter (progdir_overrides_savegame_settings=1) to allow some settings in simuconf.tab to override settings in any saved game loaded when that parameter is so set. This does not affect online games, which will always load all of their settings from the saved game downloaded from the server.

The aim of this feature is to permit easier changing of saved game settings on previously generated saved games using simuconf.tab. This feature was entirely written by Nathaneal Nerode.