News:

Congratulations!
 You've won the News Item Lottery! Your prize? Reading this news item! :)

Dat file reference for: Vehicles and Ways

Started by Ves, January 18, 2016, 01:23:56 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ves

this guide applies to Simutrans-Extended version 12.x and above only.


Short comments on vehicle operations:

Way wear and automatic uograding:
Ways wear as convoys pass over them and the level of wear that each way can tolerate can be set in each way's .dat file using the wear_capacity=. The default value if not specified is 100,000,000.
The degree of wear exerted by each vehicle can then be set in each vehicle's .dat file, using the way_wear_factor=. By default, road and air vehicles (air vehicles acting like road vehicles on the ground) calculate their wear using the fourth power law based on the maximum axle load and an attempt to deduce the weight. Rail and allied vehicles default to a power of 2 (but query whether this should be a power of 1, i.e. linear). Water craft will default to zero, as water craft do not normally wear ways.
The wear is intended to be measured in 10,000ths of a standard axle load of 8t, meaning that if the vehicle has an axle load of 8t, the wear should be specified as 10000 per axle, and the ingame way wear for that axle should be exactly 1.

The condition of the way is indicated in the way information window and a new "wear" overlay for the minimap, and when the condition falls below a set fraction (default 1/7th, approx. 14%, setting in simuconf.tab), the way either auto-renews or, if player has insufficient funds, becomes degraded. If a way degrades, the speed limit will be reduced by half and if it degrades all the way to zero condition, the speed limit will be reduced to zero, making the way impassible.
By default, the way will auto renew to the same type unless it is obsolete, in which case the closest currently available type will be selected, however, a player can manually choose the type of way to which the way upgrades by SHIFT-dragging the new type of way over the old way. Auto renewing can also be disabled by SHIFT-dragging the way remover tool over the way and the way will behave in the same manners as when you have insufficient funds.
The player is warned up to once a month if a way needs renewing and the player has insufficient money with which to do so.
To create a mothballed way, use these values:
cost=0
maintenance=0
topspeed=0
max_weight=0
wear_capacity=0


Upgradeable way on bridges
The "way" and the "bridge" is now separated, so you can upgrade the way on top of the bridges without of tearing the entire bridge down. With this, one can upgrade to better ways on top of the bridge and keep the stucture. If the bridge graphics contains prepainted waygraphics (eg a wooden deck), has_own_way_graphics=1 should be defined so no way graphics are painted on the bridge.

Improved waterways
There are some parameters to put in the waterway datfiles to improve the behavior of boats. The setting "max_vehicles_on_tile=" will limit the number of boats traveling "on top" of each other to simulate smaller waterways. Also the "max_altitude=" is especially usefull for waterways (but can be used on all ways) as this will limit the height over sea level a waterway can be built (to eg prohibit a player from building a canal over a mountain). Lastly the topspeed_gradient_1= and topspeed_gradient_2= sets speedlimits on hills, which could simulate that a boat has to go through waterlocks in order to sail up in a river, however this can also be used on all ways. If set to zero, the hill will be unclimbable.

From version 11.x and earlier:

Way constraints
Way constraints are a way of making sure that only suitable vehicles use particular (usually specialist) ways. For example, way constraints can be used to create underground urban rail networks (such as the London Underground), which have tunnels too small for ordinary trains to fit through, but whose trains can also travel on the same tracks as ordinary trains. They can also be used, for example, to create specific sorts of electrification, so that AC electrified trains cannot run on DC electrified track, and vice versa.

Both vehicles and ways can have way constraints. There are two types of way constraints: permissive and prohibitive. Each pakset can have up to eight of each type of way constraint. A permissive way constraint means that the way permits a vehicle with the matching constraint to use it. For example, a permissive way constraint might be "DC electrification". DC electrified vehicles can only run on DC electrified ways. With a permissive constraint, if the vehicle has it, the way must have it. Permissive way constraints do not stop vehicles without the constraint from using them.

A prohibitive way constraint means that the way prohibits any vehicles that does not have a matching constraint from using them. For example, a prohibitive way constraint might be "tube tunnel". Only tube sized vehicles can fit into tube tunnels. With a prohibitive constraint, if the way has it, the vehicle must have it. Vehicles with prohibitive way constraints are not prohibited from using ways without a matching constraint.

Way constraints are numbered: so a vehicle with prohibitive way constraint 1 in its .dat file would be able to use a way with prohibitive way constraint 1 in its .dat file. Naming of the way constraints is achieved in the translation files. By default, the constraints are called "Permissive X" and "Prohibitive X", where X is a number between and including 0 and 7. The translation file is the [ISO-LANGUAGE].tab file (en.tab for English) for the specific pakset (not the one in the /simutrans/text directory). Here is a brief example from Pak.Britain-Ex:

Permissive 1
DC Electrification
Permissive 2
AC Electrification
...
Prohibitive 1
Tube tunnels
Prohibitive 2
Tramway
...

Upgrading
In Simutrans-Extended, as well as being replaced by other vehicles, vehicles can be upgraded to other vehicles. The vehicle retains its original identity, but is converted to being of a new type. This is useful to simulate, for example, major refurbishments of vehicles that give them substantially different characteristics, but while still retaining much of the original vehicle. Upgrading is generally cheaper than buying a vehicle new.

To make upgradeable vehicles in the .dat files, the vehicles to which the present vehicle can be upgraded should be specified in the vehicle's .dat file. For example, if a Petts Co. Mark I 'bus can be upgraded to a Petts Co. Mark I-A 'bus or the Petts Co. Mark I-B 'bus, the Mark I's .dat file should specify the Mark I-A and the Mark I-B. A special upgrade price can be specified: this is the price that the player pays to upgrade to that vehicle. So, suppose that the Mark I-A 'bus cost 10,000.00c to buy from new, but it costs only 5,000c to upgrade to it, the upgrade price in the Mark I-B would be specified as 5,000.00.
Some vehicles are only available as upgrades: this is to simulate vehicles that are substantially modified later in life without any examples of the modified type being built from new. Pakset/addon authors should be careful to make sure that there are enough vehicles available to buy new in every era, as players will not necessarily have all of the right type of vehicles to upgrade to vehicles that are available only as upgrades.

Catering
In Simutrans-Extended, it is possible to have a catering vehicle in a convoy. This is a vehicle in which food and drink is served to passengers during their journey, such as a buffet car on a train. Catering vehicles are useful in two ways: firstly, they earn their own revenue stream, and secondly, they increase the comfort level for the whole convoy.

There are five different catering levels, to simulate everything from a trolley service selling canned drinks and packets of crisps to luxury dining freshly cooked on board. The levels are represented by the numbers 1 to 5, 1 being the lowest and 5 being the highest. Specifying a catering level of 0 is equivalent to having no catering at all. If any number higher than 5 is specified, it will be truncated to 5.

The levels have the following meanings:

Level 1: Trolley service (+ 5 comfort)
Level 2: Miniature buffet (cold food only) (+ 10 comfort)
Level 3: Buffet selling hot food (+ 16 comfort)
Level 4: Full cooked meals (possibly including at-seat service) (+ 20 comfort)
Level 5: Pullman-style luxury dining. (+ 25 comfort)

The longer the journey (in time, not distance), the more useful that catering is (this can be calibrated fully in simuconf.tab). On shorter journeys, catering vehicles do not earn any revenue at all (but still contribute towards comfort of the whole convoy, which is itself less important on shorter journeys). As the distances get longer, so does the revenue that can be earned from catering facilities. On shorter journeys, the revenue that can be earned by higher levels is no greater than that which can be earned by lower levels. Only on the longest journeys do the highest levels of catering earn more than those below them.

To calibrate this feature effectively, it should be noted that, in real life, catering vehicles are more expensive to build and much more expensive to run than ordinary vehicles, and have a reduced passenger capacity (a catering vehicle can carry passengers at the same time, but need not do so). Also, when calibrating the comfort levels of longer distance vehicles, remember to take into account the fact that catering ought be added to longer distance journeys, and adjust accordingly. The catering revenue earned by the catering vehicle is based on the number of passengers in the whole convoy, not just the catering vehicle.

Mail vehicles have an equivalent of catering: the travelling post office. There are no different levels for travelling post office vehicles, and comfort is not relevant to mail. Like catering vehicles for passengers, they earn extra revenue for the whole convoy, and are more useful at longer than at shorter journeys (measured in time, not distance).

Liveries
In Simutrans-Extended, vehicles can have different liveries. Liveries are organised according to livery schemes. Individual liveries within livery schemes are distinguished by introduction date. Players select the livery scheme to apply to the convoy/line, and the appropriate livery is chosen according to the current date. Livery schemes are only available when the current date is later than the earliest livery introduction date in the scheme. The scheme itself has a retirement date, after which the scheme as a whole will no longer be available. Vehicles will retain their existing livery until the livery is changed manually. In future versions, it is anticipated that liveries will change automatically when the vehicle is overhauled (overhauls being a feature that it is planned to introduce in the future).

---

Notes to the dat parameters below:
All vehicles can use all paragraphs, if not specified otherwise.
{E} = Simutrans Experiemental parameter
{M} = A modified parameter from Simutrans Standard
{S} (or nothing specified) = Original Simutrans Standard parameter and can be further investigated here: Create Standard DAT files.


.dat parameters for vehicles:

obj=vehicle
name=
copyright=
intro_year=
intro_month=
retire_year=
retire_month=
speed=
length=
weight=
sound=


waytype:{S} The way this vehicle can travel (also see the section about way constraints)
waytype=road
waytype=track
waytype=tram_track
waytype=monorail_track
waytype=maglev_track
waytype=narrowgauge_track
waytype=water
waytype=air


range: {E} Kilometres that this vehicle can travel before it needs to stop at a station (waypoints doesnt count). If set to zero = unlimmited range.
range=

axles:{E} Number of axles this vehicle has. It is used to calculate axleload based on the vehicle weight. Default: 2
axles=

axle_load:{E} If the vehicle is known to have more weight on some axles than on others, the axle load can be specified separately instead of axles=. If zero is specified, the vehicle will be considered having legs instead of axles (ie a horse)
axle_load=

brake_force:{E} The brake force, in kiloNewtons, of this vehicle. Default if not specified: calculated based on the vehicle's weight. If set to zero, this is an unbraked vehicle.
brake_force=

rolling_resistance:{E} the rolling resistance, in Newtons per Kilogram, of the vehicle. Default if not specified: varies depending on the type of vehicle
rolling_resistance=

air_resistance:{E} The level of air resistance generated by this vehicle when moving: used for the physics engine. It is recommended to leave this blank unless the vehicle is properly streamlined (in which case, use the example value below). This value is 100x the value used internally and in most standard physics calculations to allow greater precision: for example, a value of 108 becomes 1.08. Defaults: (varies depending on the type of vehicle)
air_resistance=

way_wear_factor:{E} How much the vehicle "wears" the underlying way. The wear is intended to be measured in 10,000ths of a standard axle load of 8t.
way_wear_factor=

smoke:{S} Specifies the name of the smoke to use. How to create smoke.
smoke=

is_tall:{E} Specifies wether this vehicle is considered to be tall. Tall vehicles will not be able to pass under bridges which are only half heigth. This is intended to be used with double-decker 'buses and trams, sailing ships, etc. The idea is to give single decker 'buses and trams a function in the game.
is_tall=1

can_lead_from_rear:{E} (only rail vehicles) This vehicle has a drivers cab at the rear, meaning that if all vehicles in the train are bidirectional=1, the entire train can drive backwards, instead of the loco has to detach to the rear of the train.
can_lead_from_rear=1

DEPRECATED: Replaced by has_front_cab and has_rear_cab, but kept for backward compatibility.

has_front_cab
has_rear_cab:
{E} This defines wether the vehicle has a drivers cab at either end. A value of 1 means there is a cab, a value of 0 means there are no cab. The presence of a cab determines wether that end of the vehicle can function as the head of the convoy. If the parameter(s) is omitted, the default value will be -1, which means AUTO. If set to AUTO, Simutrans will automatically assign a cab to either end by looking at the constraints, the bidirectional parameter and the now deprecated can_lead_from_rear parameter.
has_front_cab=
has_rear_cab=

The truth table for the automatic cab assignment:





no constraint specifiedFront cab assignedRear cab assigned
constraint[prev]=noneFront cab assigned
constraint[next]=none & can_lead_from_rear=1Rear cab assigned
constraint[next]=none & bidirectional=1Rear cab assigned

bidirectional:{E} (only rail vehicles) This vehicle can drive in both directions with no need to turn around.
bidirectional=1

is_tilting:{E} (only rail vehicles) This vehicle will tilt during turns and can therefore take turns about 30% faster than normal vehicles.
is_tilting=1

minimum_runway_length:{E} (only aircrafts) The length in meters of the shortest runway at which this vehicle can land or take off. The distance in meters of a runway is calculated using the meters per tile value applicable to the particular game. Default or not specified: 0 (can use any runway).
minimum_runway_length=


Vehicle economy:

cost:{S} The cost of this vehicle in 1/100 of ingame SimuCredits.
cost=

runningcost:{S} The vehicle costs this amount for every Km in 1/100 of ingame SimuCredits.
runningcost=

fixed_maintenance:{E} The vehicle costs this amount of money every month even if it is not moving. specified in 1/100 of in game Simucredits.
fixed_maintenance=

increase_maintenance_after_years:{E} The number of years after a vehicle's retirement date that its maintenance costs (both fixed and per kilometre) increase. The default values are set in simuconf.tab.
increase_maintenance_after_years=

years_before_maintenance_max_reached:{E} The number of years after the vehicle's maintenance costs start to increase (under the above setting) before they reach their Maximilian level (specified in the below setting). Between these two dates, the maintenance costs are scaled linearly. The default values are set in simuconf.tab.
years_before_maintenance_max_reached=

increase_maintenance_by_percent:{E} The increase over the vehicle's base maintenance level, in percentage terms, that is applied at and after the date specified in the above setting. The default values are set in simuconf.tab.
increase_maintenance_by_percent=


Powered vehicles:

engine_type:{M} The different engine types available in Simutrans Extended:
engine_type=bio - Like animals or humans
engine_type=sail
engine_type=steam
engine_type=diesel
engine_type=petrol
engine_type=turbine - Internal combustion turbines, like jet and turborpop air engines.
engine_type=electric
engine_type=hydrogene
engine_type=fuel_cell
engine_type=battery

power:{S} In kw
power=

tractive_effort:{E} The tractive effort, in kiloNewtons, of this vehicle. This can be specified either as well as or instead of "power", and the other value will be calculated. Default if not specified: calculated according to a formula from "power".
tractive_effort=

gear:{S} It is used in Extended for allowing the use of accurate power of diesel engines and electric motors yet simulating the correct output power taking into account transmission inefficiencies.  Used as a percent (gear=80 = 80%). Default: 100.
gear=


Good and passenger carrying vehicles:

freight:{S} Specifies what good this vehicle can carry.
freight=

payload:{S} The amount of good this vehicle can carry. Used together with all non-class good (everything except passengers and mail).
payload=

payload[X]:{E} If "freight=Passagiere" or "freight=Post", you can have multiple classes of passenger or mail in a single vehicle. The amount specified in this entry is the amount of passengers or mail that defaults to travel on this particular class. Note that if you only want, say "payload[3]=" to have any capacity, you need to first list all the previous entries (see example).
payload[X]=

Example:
payload[0]=0
payload[1]=0
payload[2]=0
payload[3]=5


comfort:{E} How comfortable that this vehicle is. May be any number from 0 to 255 and is only relevant for passengers. This parameter can be used together with single classed vehicles, but vehicles with more classes should use the "comfort[X]=" version. Default: 100.
comfort=

comfort[X]:{E} As the above setting, this is only used on passenger vehicles. The X specify which class the comfort apply. There must exist one "comfort[X]=" as there are "payload[X]=" entries. For "empty" classes, a comfort value of 0 can be defined.
comfort[X]=

overcrowded_capacity:{E} The vehicle's additional capacity when payload is reached. This could eg in a bus be the standing capacity.
overcrowded_capacity=

catering_level:{E} whether this vehicle is a catering vehicle, and, if so, how well equipped that it is. May be any number between 0 and 5, where 0 is a non-catering vehicle, and 1 - 5 are progressively better equipped/more luxurious catering facilities. If the value is bigger than zero on a mail vehicle, it becomes a travelling post office. Setting catering_level on vehicles other than passenger or mail vehicles has no effect.
catering_level=

min_loading_time
max_loading_time:
{E} The minimum/maximum time, in game seconds (measured on the same scale as travelling times) that this vehicle takes to load. The loading time of a convoy is the loading time of the slowest loading vehicle in the convoy. If no passengers/goods board/alight, the loading time is the longest minimum loading time of any vehicle in the convoy. If the maximum possible number of passengers/goods board/alight, the loading time is the longest maximum loading time of any vehicle in the convoy. Between those two points, an intermediate number is interpolated on a linear scale.
min_loading_time=
max_loading_time=


mixed_load_prohibition:{E} Prohibiting the loading of different goods in the same good category. For example, if a bulk wagon has this setting and is loaded with coal, it cannot load anything but coal until it is completely emptied, and then it can be loaded with another bulk good.
mixed_load_prohibition=1


Upgrades and constraints:

available_only_as_upgrade:{E} Whether this vehicle is available only as an upgrade to from another vehicle, and therefore cannot be bought new.
available_only_as_upgrade=1

upgrade_price:{E} the price in 1/100th of a SimuCredit, that it costs to upgrade to this vehicle from any other vehicle. Default: the same as the purchase price of this particular vehicle.
upgrade_price=

upgrade[X]:{E} (Where X is a number in sequence, starting from 0, and being no higher than 255) A list of the vehicles to which the current vehicle can be upgraded.
Example:
upgrade[0]=petts-mk1a
upgrade[1]=petts-mk1b


way_constraint_permissive[X]=X:{E} (Where both X'es are the same number between 0 and 7 inclusive) Specifies a permissive way constraint affecting the vehicle, by number.
Example:
way_constraint_permissive[0]=0
way_constraint_permissive[3]=3


way_constraint_prohibitive[X]=X{E} (Where both X'es are the same number between 0 and 7 inclusive) Specifies a prohibitive way constraint affecting the vehicle, by number.
Example:
way_constraint_prohibitive[2]=2
way_constraint_prohibitive[7]=7


Difference between permissive and prohibitive:
The permissive and prohibitive constraints are used together with the ways. Eg, the permissive constraint no 2 in Pak128.Britain-Ex-0.9.1 are used as "AC Overhead Catenary", which means that a vehicle having specified way_constraint_permissive[2]=2 only can travel tracks that also has way_constraint_permissive[2]=2 defined.
The prohibitive constraints work the other way, eg prohibitive constraint no 2 used as "Tube tunnel", so ways coded with way_constraint_prohibitive[2]=2 only accepts trains also coded with that.


constraint[prev][X]
constraint[next][X]:
{M} (Where X is a number in sequence, starting from 0, and being no higher than 255) A list of vehicles or keywords to which the current vehicle must be put in front or behind.
If constraint[prev][X]=none or constraint[next][X]=none are used, it will be possible also to let no vehicle be in front or behind the current vehicle.
Specific for Simutrans Experiemental is constraint[prev][0]=any and constraint[next][0]=any (exactly that syntax) which means this vehicle cannot be at the rear or front of a convoy (there must be another vehicle behind this vehicle).
If not entry is made, any vehicle can be connected
Example 1:
constraint[prev][0]=Se_X2000_X2_1990
constraint[prev][1]=Se_X2000_UA2_1990
constraint[prev][2]=Se_X2000_UB2_1990
constraint[prev][3]=none

constraint[next][0]=Se_X2000_X2_1990
constraint[next][1]=Se_X2000_UA2_1990
constraint[next][2]=Se_X2000_UB2_1990

---
Example 2:
constraint[prev][0]=Se_Y1_1970
constraint[next][0]=any


Liveries:

liverytype[X]:{E} (Where X is a number in sequence, starting from 0, and being no higher than 255) The name of the livery defined in the livery section in simuconf.dat.
liverytype[X]= (Example: liverytype[0]=BR-Early)

Graphics representation:{M} If liverytype[X]= is not defined, the graphics definition will be like it currently is in Simutrans Standard (EmptyImage[E]= and FreightImage[4][E]=). But if liverytype[X]= is defined, the definitions of the graphics also get changed with the addition of [X] (where "X" should match the "X" specified in liverytype[X]) after the orientation expression:
Example:

EmptyImage[E][X]=

Liveries can then also be combined with freight images thus:
Example:
FreightImage[4][E][0]=

where the first number (4 here) is the number of the type of cargo, and the second (0 here) is the livery index.

Here is an example of a graphics definition section:


liverytype[0]=BR-Early
liverytype[1]=BR-Revised
liverytype[2]=BR-Blue

EmptyImage[E][0]=./images/br-cl47-green.0.0
EmptyImage[SE][0]=./images/br-cl47-green.0.1
EmptyImage[S][0]=./images/br-cl47-green.0.2
EmptyImage[SW][0]=./images/br-cl47-green.0.3
EmptyImage[W][0]=./images/br-cl47-green.0.4
EmptyImage[NW][0]=./images/br-cl47-green.0.5
EmptyImage[N][0]=./images/br-cl47-green.0.6
EmptyImage[NE][0]=./images/br-cl47-green.0.7

EmptyImage[E][1]=./images/br-cl47-b.0
EmptyImage[SE][1]=./images/br-cl47-b.1
EmptyImage[S][1]=./images/br-cl47-b.2
EmptyImage[SW][1]=./images/br-cl47-b.3
EmptyImage[W][1]=./images/br-cl47-b.4
EmptyImage[NW][1]=./images/br-cl47-b.5
EmptyImage[N][1]=./images/br-cl47-b.6
EmptyImage[NE][1]=./images/br-cl47-b.7

EmptyImage[E][2]=./images/br-cl47-green.1.0
EmptyImage[SE][2]=./images/br-cl47-green.1.1
EmptyImage[S][2]=./images/br-cl47-green.1.2
EmptyImage[SW][2]=./images/br-cl47-green.1.3
EmptyImage[W][2]=./images/br-cl47-green.1.4
EmptyImage[NW][2]=./images/br-cl47-green.1.5
EmptyImage[N][2]=./images/br-cl47-green.1.6
EmptyImage[NE][2]=./images/br-cl47-green.1.7



The Simuconf.tab also needs to be altered to make the liveries work, and for the example above, the below section is needed in simuconf.tab:


################################### Livery settings ##################################a
livery_scheme[0] = British-Railways
retire_year[0] = 1986
retire_month[0] = 6
livery[0][0] = BR-Early
intro_year[0][0] = 1948
intro_month[0][0] = 1
livery[0][1] = BR-Revised
intro_year[0][1] = 1956
intro_month[0][1] = 2
livery[0][2] = BR-Blue
intro_year[0][2] = 1966
intro_month[0][2] = 6


-----------------------

.dat parameters for ways, bridges and tunnels:

obj:{S} Defines wether this is a way, bridge or tunnel
obj=way
obj=bridge
obj=tunnel

Name=
copyright=
intro_year=
intro_month=
retire_year=
retire_month=
cost=
maintenance=


topspeed:{M} Specifies the topspeed that any vehicle may travel this way, bridge or tunnel. Note that for bridges and tunnels, the topspeed will be the lower of either the bridge/tunnel or the way on top.
topspeed=

topspeed_gradient_1
topspeed_gradient_2:
{E} The speed a vehicle may travel hills (1 beeing the half height/single incline, and 2 beeing the full height/dubble incline) on this way in km/h. A zero maximum speed will make the gradient impassible (useful for rivers).
topspeed_gradient_1=
topspeed_gradient_2=


max_weight:{M} For ways and tunnels, this specifies the maximum axle load in metric tonnes of vehicles which can traverse the way/tunnel. For bridges, specifies the maximum convoy weight (including load), divided by the maximum proportion of the convoy that can be on the bridge at any given moment, that can traverse the bridge. This setting has no effect on way objects, such as catenary. Note that a bridge can have both the total weight limit and a axle limit from the overlaying way. Default: 4,294,967,295 tonnes
max_weight=

wear_capacity:{E} (only ways and tunnels) How much "wear" this way or tunnel can handle. The wear is intended to be measured in 10,000ths of a standard axle load of 8t. The default value if not specified is 100,000,000
wear_capacity=

waytype:{S} Specifies which waytype, and therefore which kinds of vehicles that can travel this way. Also see the sections about system type and way constraints.
waytype=road
waytype=track
waytype=tram_track
waytype=monorail_track
waytype=maglev_track
waytype=water (canals and rivers)
waytype=air (Runways and taxiways)
waytype=power (Powerlines)

way_constraint_permissive[X]=X:{E} (Where both X'es are the same number between 0 and 7 inclusive) Specifies a permissive way constraint affecting the vehicle, by number.
Example:
way_constraint_permissive[0]=0
way_constraint_permissive[3]=3


way_constraint_prohibitive[X]=X{E} (Where both X'es are the same number between 0 and 7 inclusive) Specifies a prohibitive way constraint affecting the vehicle, by number.
Example:
way_constraint_prohibitive[2]=2
way_constraint_prohibitive[7]=7


system_type:{S} The result of the value set after system_type= will depend on which waytype this way is.
For waytype=road
system_type=0 = Normal
system_type=1 = Elevated
For waytype=track
system_type=0 = Normal
system_type=1 = Elevated
system_type=7 = Streetcar track
For waytype=moonorail_track
system_type=0 = Normal
system_type=1 = Elevated
For waytype=maglev_track
system_type=0 = Normal
system_type=1 = Elevated
For waytype=air
system_type=0 = Taxiway
system_type=1 = Runway
For waytype=water
system_type=0 = Canal
system_type=1 = Elevated canal
system_type=255 = River

upgrade_group:{E} (only ways) A value between 0 and ?? This is intended to be used with elevated ways to simulate a situation where all members of the upgrade group have the same elevated structure and differ only in the way on top of them. This is necessary because one cannot separate the elevated way and the way itself in the same way as one can with a bridge and its underlying way. However it can also be used for any sorts of way. The default group for all ways that do not have this value specified is 0.
upgrade_group=

way_only_cost:{E} (only ways) Upgrading from one way to another way within the same upgrade group incurs the "way_upgrade_cost" rather than the main price.
way_only_cost=

has_own_way_graphics:{E} (only bridges) Wether this bridge does not have the way graphics painted directly in the bridge graphichs. Default 1.
has_own_way_graphics=0

way:{E} (only bridges) Defines which way that should be defaultly built together with the bridge in combination with has_own_way_graphics=0.
way=

max_lenght:{S} (only bridges) (must be misspelled) The maximum length of the bridge in tiles.
max_lenght=

max_height:{S} (only bridges) The maximum height of the bridge in tiles. Must be a number between 1 and 7.
max_height=

pillar_distance:{S} (only bridges) Sets the distance in tiles betwen pillar graphics, if 0 every tile will have a pillar.
pillar_distance=

pillar_asymmetric:{S} (only bridges) This removes the pillar graphics at the ends of the bridge. Used when the pillars are not at the center of the tile.
pillar_asymmetric=1

max_vehicles_on_tile:{E} (only water ways) Customisable limit for the maximum number of vehicles that can be simultaneously on a waterway til (a river or canal), which is useful to simulate the limited capacity of smaller canals and rivers. Default is 251 - do not specify a higher value!
max_vehicles_on_tile=

max_altitude:{E} Sets the maximum altitude above sea level that this way can be built and is particularly useful for canals.
max_altitude=

Image definitions:{S} This is coded as in Simutrans Standard. To get snow graphics, replace the [ 0 ] with [ 1 ] (eg Image[N][1]=):

Some examples of way, bridge and tunnel graphics:

icon=> ./images/macadam_road.3.4
cursor=./images/macadam_road.3.5

Image[-][0]=./images/macadam_road.1.2
Image[N][0]=./images/macadam_road.1.5
Image[S][0]=./images/macadam_road.2.1
Image[E][0]=./images/macadam_road.2.2
Image[W][0]=./images/macadam_road.2.0
Image[NS][0]=./images/macadam_road.1.0
Image[EW][0]=./images/macadam_road.1.1
Image[NSE][0]=./images/macadam_road.0.2
Image[NSW][0]=./images/macadam_road.0.4
Image[NEW][0]=./images/macadam_road.0.1
Image[SEW][0]=./images/macadam_road.0.3
Image[NSEW][0]=./images/macadam_road.1.2
Image[NE][0]=./images/macadam_road.3.0
Image[SE][0]=./images/macadam_road.2.3
Image[NW][0]=./images/macadam_road.2.4
Image[SW][0]=./images/macadam_road.2.5
ImageUp[3][0]=./images/macadam_road.4.2
ImageUp[6][0]=./images/macadam_road.4.3
ImageUp[9][0]=./images/macadam_road.4.0
ImageUp[12][0]=./images/macadam_road.4.1
ImageUp2[3][0]=./images/macadam_road.1.3
ImageUp2[6][0]=./images/macadam_road.1.4
ImageUp2[9][0]=./images/macadam_road.0.0
ImageUp2[12][0]=./images/macadam_road.0.5
Diagonal[NE][0]=./images/macadam_road.3.6
Diagonal[SE][0]=./images/macadam_road.0.6
Diagonal[NW][0]=./images/macadam_road.1.6
Diagonal[SW][0]=./images/macadam_road.2.6




The Simutrans Standard Wiki about way graphics: Way Graphics Configuration


cursor=images/iron-girder-bridge.4.1
icon=> images/iron-girder-bridge.4.0
BackImage[NS][0]=images/iron-girder-bridge.0.5,0,32
FrontImage[NS][0]=images/iron-girder-bridge.1.5,0,32
BackImage[EW][0]=images/iron-girder-bridge.0.4,0,32
FrontImage[EW][0]=images/iron-girder-bridge.1.5,0,32
BackStart[N][0]=images/iron-girder-bridge.0.0,0,32
FrontStart[N][0]=images/iron-girder-bridge.1.0,0,32
BackStart[S][0]=images/iron-girder-bridge.0.2,0,32
FrontStart[S][0]=images/iron-girder-bridge.1.2,0,32
BackStart[E][0]=images/iron-girder-bridge.0.1,0,32
FrontStart[E][0]=images/iron-girder-bridge.1.1,0,32
BackStart[W][0]=images/iron-girder-bridge.0.3,0,32
FrontStart[W][0]=images/iron-girder-bridge.1.3,0,32
BackRamp[N][0]=images/iron-girder-bridge.0.6
BackRamp[S][0]=images/iron-girder-bridge.0.8
BackRamp[E][0]=images/iron-girder-bridge.0.9
BackRamp[W][0]=images/iron-girder-bridge.0.7
FrontRamp[N][0]=images/iron-girder-bridge.1.6
FrontRamp[S][0]=images/iron-girder-bridge.1.8
FrontRamp[E][0]=images/iron-girder-bridge.1.9
FrontRamp[W][0]=images/iron-girder-bridge.1.7
backPillar[S][0]=images/iron-girder-bridge.4.3
backPillar[W][0]=images/iron-girder-bridge.4.2
BackImage2[NS][0]=images/iron-girder-bridge.2.5,0,32
FrontImage2[NS][0]=images/iron-girder-bridge.3.5,0,32
BackImage2[EW][0]=images/iron-girder-bridge.2.4,0,32
FrontImage2[EW][0]=images/iron-girder-bridge.3.5,0,32
BackStart2[N][0]=images/iron-girder-bridge.2.0,0,32
FrontStart2[N][0]=images/iron-girder-bridge.3.0,0,32
BackStart2[S][0]=images/iron-girder-bridge.2.2,0,32
FrontStart2[S][0]=images/iron-girder-bridge.3.2,0,32
BackStart2[E][0]=images/iron-girder-bridge.2.1,0,32
FrontStart2[E][0]=images/iron-girder-bridge.3.1,0,32
BackStart2[W][0]=images/iron-girder-bridge.2.3,0,32
FrontStart2[W][0]=images/iron-girder-bridge.3.3,0,32
BackRamp2[N][0]=images/iron-girder-bridge.2.6
BackRamp2[S][0]=images/iron-girder-bridge.2.8
BackRamp2[E][0]=images/iron-girder-bridge.2.9
BackRamp2[W][0]=images/iron-girder-bridge.2.7
FrontRamp2[N][0]=images/iron-girder-bridge.3.6
FrontRamp2[S][0]=images/iron-girder-bridge.3.8
FrontRamp2[E][0]=images/iron-girder-bridge.3.9
FrontRamp2[W][0]=images/iron-girder-bridge.3.7
backPillar2[S][0]=images/iron-girder-bridge.4.5
backPillar2[W][0]=images/iron-girder-bridge.4.4




The Simutrans Standard Wiki about bridge graphics: Bridge Graphics Configuration


Image[-][0]=severn-tunnel.1.2
Image[N][0]=severn-tunnel.1.5
Image[S][0]=severn-tunnel.2.1
Image[E][0]=severn-tunnel.2.2
Image[W][0]=severn-tunnel.2.0
Image[NS][0]=severn-tunnel.1.0
Image[EW][0]=severn-tunnel.1.1
Image[NSE][0]=severn-tunnel.0.2
Image[NSW][0]=severn-tunnel.0.4
Image[NEW][0]=severn-tunnel.0.1
Image[SEW][0]=severn-tunnel.0.3
Image[NSEW][0]=severn-tunnel.1.2
Image[NE][0]=severn-tunnel.3.0
Image[SE][0]=severn-tunnel.2.3
Image[NW][0]=severn-tunnel.2.4
Image[SW][0]=severn-tunnel.2.5
ImageUp2[3][0]=severn-tunnel.1.3
ImageUp2[6][0]=severn-tunnel.1.4
ImageUp2[9][0]=severn-tunnel.0.0
ImageUp2[12][0]=severn-tunnel.0.5
ImageUp[3][0]=severn-tunnel.4.2
ImageUp[6][0]=severn-tunnel.4.3
ImageUp[9][0]=severn-tunnel.4.0
ImageUp[12][0]=severn-tunnel.4.1

# Front Images
FrontImage[NSE][0]=severn-tunnel.3.2
FrontImage[NSW][0]=severn-tunnel.3.4
FrontImage[NEW][0]=severn-tunnel.3.1
FrontImage[SEW][0]=severn-tunnel.3.3




The Simutrans Standard Wiki about tunnels: Tunnel Graphics Configuration


To be continued....

Edit:
21/1-2016 - Ves: Added info about smoke
6/1-2016 - Ves: Adjusted a detail about way wear
18/11-2016 - Ves: Added the two new traction types, "petrol" and "turbine"
10/1-2017 - Ves: Added information about the new is_tall=1
7/3-2018 - Ves: Added class information
1/2-2020 - Ves: Added info on  constraint[prev][0]=any, has_front/rear_cab and mixed_load_prohibition and lined out can_lead_from_rear

Vladki

air_resistance is a coefficient to calculate drag force: F= speed^2 * air_resistance
rolling_resistance is NOT in N/kg, but a dimensionless coeficient: F= weight * g * rolling_resistance


Vladki

A question about way_constraint_permissive[X]=X:

Is it possible to use this to code electric engines that can run under both AC and DC catenary and switch accordingly?
If I put two (or more) permissive constraints on vehicle, is it enough if the way has only one of them?

jamespetts

Ah, no - the way to encode dual voltage electric vehicles is not to give them any permissive constraint at all: they will be electric, requiring some electrification, but will not need any specific type.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Rollmaterial

Quote from: Vladki on March 26, 2017, 06:33:09 PM
air_resistance is a coefficient to calculate drag force: F= speed^2 * air_resistance
rolling_resistance is NOT in N/kg, but a dimensionless coeficient: F= weight * g * rolling_resistance
When trying to calculate acceleration using your formula for the rolling resistance I get negative acceleration distances and times. Are there any unit conversions I need to make?

Vladki

#5
Quote from: Rollmaterial on September 15, 2017, 07:17:16 PM
When trying to calculate acceleration using your formula for the rolling resistance I get negative acceleration distances and times. Are there any unit conversions I need to make?
The formulas should be using SI units (N, kg, m/s). But I am not exactly sure about the implementation in game. I'd have to check the code.

Edit: after a quick look into the code - there are conversions from km/h to m/s and back at many places. The formulas seem to be used with m/s, but they are at many places. It would need a big audit :( to be sure it it is not omitted somewhere. Perhaps it would be better to have all physics related variables in SI units and convert them only when reading from pak file and displaying on screen (then it would be easy to choose SI or historical/future units of your favorite empire (Roman, British, Galactic)

Ranran

Vehicle dat definition added in Extended 14.8.
After 14.8, it is determined from the constraint and various settings whether the vehicle can be at the top or the rear, and attributes are represented by symbols.
For example, the leading side is represented by a sharp nose or slanted edge.


has_front_cab = 1
has_rear_cab = 1

The default is -1, auto. Judge automatically from constraint.
Use 0 to make it clear that vehicle does not have a cab.
(The cab mentioned here indicates that it can be the front of convoy. For example, a carriage horse or a mail man is considered to have a cab.)

For example, a coach that can come behind a locomotive. In that case, a round end is displayed.
A value of 1 indicates that vehicle have a cab on the [front/rear] side, which can be at the front or rear of convoy. Expressed with a sharp nose or a slanted edge in the symbol.
This is exclusive with constraint[prev/next]=any setting.


constraint[prev][0]=any
constraint[next][0]=any like prev, this setting has been added.



mixed_load_prohibition=1
Prohibiting the loading of different goods in the same category.
For example, if the bulk wagon has this setting, it cannot load anything other than coal until all the coal is unloaded once the coal is loaded.
Default is 0.

Ves

Thanks for posting here, I will update the OP! I dont remember, but does the has_front_cab = 1 and has_rear_cab = 1 only apply to rail vehicles?

Ranran

Quote from: Ves on January 31, 2020, 07:07:09 PMdoes the has_front_cab = 1 and has_rear_cab = 1 only apply to rail vehicles?
No, it applies to all vehicles. However, non-bidirectional vehicles that run on a single car, such as many ships, planes, and motors do not need to be set as it is obvious.
For example, in this case

constraint[prev][0]=none
constraint[next][0]=none
bidirectional=0


It is sufficient to set them as needed, but they are more valuable for trains that are composed of many vehicles and are often reassembled.

EDIT:
I forgot to write one thing. can_lead_from_rear has been deprecated in exchange for cabs setting. The setting is converted to has_rear_cab = 1.

Vladki

Could you please explain in more detail how these new options work in comparison with old bidirectional and can lead from rear? What are the defaults if not specified? How do they affect train reversal? Is there a similar option for brake vans (or cars that can be last in train?

Ranran

All items that affect reversing in the item set in dat are expressed as symbols. This is a big difference from before. There was a vague point about the existence cab and role before. Whether a vehicle is powered or not is one of the factors that affect reversing order.
I think you were involved in the discussion on the algorithm for reversing. I haven't fiddled with the inversion algorithm since last summer.  I think that the behavior discussed at that time should be expected. Please confirm that the reversing operation is as expected while looking at the formation picture on convoy detail dialog.
I am not convinced that the operation is perfect, so various patterns need to be verified.

Ves

Quote from: Ranran on January 31, 2020, 09:54:20 PM
No, it applies to all vehicles. However, non-bidirectional vehicles that run on a single car, such as many ships, planes, and motors do not need to be set as it is obvious.
For example, in this case

constraint[prev][0]=none
constraint[next][0]=none
bidirectional=0


It is sufficient to set them as needed, but they are more valuable for trains that are composed of many vehicles and are often reassembled.
Ok, so you could use them for any waytype princippally?


Shall the "bidirectional" and "can lead from rear" be removed from the dat references? Alternatively have added a note disclaiming that those only exsist for legacy use?

jamespetts

It is better not to remove the references to deprecated keywords, rather to mark them as deprecated.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Ranran

QuoteOk, so you could use them for any waytype princippally?
Yes.

QuoteShall the "bidirectional" and "can lead from rear" be removed from the dat references? Alternatively have added a note disclaiming that those only exsist for legacy use?
"bidirectional" is still used. For example, even if you have a cab in front, there are differences like a steam locomotive and an EMU. It makes the difference between a pointed or slanted head in the picture.
Since "can lead from rear" was used until 14.7, I think it is better not to delete it. Can still be used for compatibility. I think it is better to describe as deprecated since 14.8.

Ves

Yes, true the bidirectional is still valid, I didnt think there...

I have crossed out the can_lead_from_rear and put the two new has_cab's next to it and removed the (only rail vehicles) Could you read through and check so it makes sense?

Ranran

#15
QuoteFor backward compatibility, if the paramenter is omitted the default value will be -1
-1 is for the sake of pakset author's work rather than for compatibility.  ;)
There are many examples where we do not need to define a cab.
If conflicting settings are made, constraint will take precedence.
So if cab setting is not important for the vehicle pakset author can ignore it.

EDIT:
Conversely, if there is no description in the constraint, you need to be careful whether there is a cab. In this case, the auto setting considers for compatibility that there is cab if it has power, and judges that there is no cab if it has no power. (However, the rear side is affected by bidirectionality.)
I don't think it is necessary to describe this in detail, as "auto is automatic"8)
Please report any flaws found in the system.

Ves

Ah, you are right!
However, I do think we should list exactly what conditions trigger what, as to avoid confusion as much as possible. Could you perhaps write how it judges in each case as a list?

Ranran

Too complicated to explain in writing (´・ω・`)
Check the code.
It is managed by flags and is determined comprehensively from the constraints, bidirectional and cab settings.
These flags are finally rendered as pictures.

Vladki

Checking the code to write documentation is bad approach. You should be able to describe your intentions how it should work. Then we can distinguish bugs from features. Also the discussion about reversal had many suggestions but no clear agreement on how it should work. Did you change the reversal algorithm? Or just added the displayed green bar?

Mariculous

Quote from: Ranran on February 01, 2020, 06:44:47 AMToo complicated to explain in writing
In that case it will also be too complicated to correctly guess the behavior from a pakset authorts perspective ;)

A table would really be useful.

Ves

The point of the OP is not that regular players should read it to understand the pakset, it is a lookup table for pakset authors, so they get their pakset the way they want it (although regular players might find it interesting too). Hence the importance of it being explained in detail, as otherwise, pakset authors might make mistakes based on bad assumptions.
Unfortunately, reading through the code to understand the feature is quite difficult (at least for me), so if you please could for instance make a logic table like this:

For a vehicle to be treated as has_front_cab=1 automatically, these conditions must be met:
Condition 1, condition 2, condition 3

For a vehicle to be treated as has_front_cab=0 automatically, these conditions must be met:
Condition 1, condition 2, condition 3

For a vehicle to be treated as has_rear_cab=1 automatically, these conditions must be met:
Condition 1, condition 2, condition 3

For a vehicle to be treated as has_rear_cab=0 automatically, these conditions must be met:
Condition 1, condition 2, condition 3

Then I perhaps can write it together in a more easy-read way if needed.

Ranran

#21
Quote from: Freahk on February 01, 2020, 10:37:48 AMA table would really be useful.
OK, I made the worksheet.
https://drive.google.com/open?id=18iIqYKYB7x15Rd4XMx0gtqMulssRVjZ4

Quote from: Ranran on January 31, 2020, 11:25:59 PMPlease confirm that the reversing operation is as expected while looking at the formation picture on convoy detail dialog.
I have to apologize. There was an element that could not be determined from figure.
"unconnectable" affects reverse order. I remember talking about this when discussing shapes. Some commented that it should not include too much information.
So whether the head and tail are "unconnectable" cannot be read from the shape.
But it should, of course, be at the front or end of the current convoy.

EDIT:
Correction in worksheet:
(1)
can_be_at_rear considers bidirectional :redx:
"can lead from rear" considers bidirectional

(2)
constraint has something but not include none
-> The flag for can_be_tail is standing. The leftmost yellow cell is wrong.
EDIT3: Worksheet updated

EDIT2:
In the debug build you can see information on bidirectional and whether the vehicle is reverse.
This is for checking the intermediate vehicle. It has nothing to do with basic reverse order behavior.
* indicates that the vehicle is reverse.
<  indicates that the vehicle is unidirectional (include intermediate).

Ves

Thanks, it does clarify. However, I suppose that all 19 entries are for when the has_front/rear_cab=auto? Is there a reason AUTO is displayed specifically in some of the entries only?

Ranran

This is to resolve the inconsistency. If there are inconsistencies, we do not know which value to trust. Neither image display nor reverse order will work properly.
The constraints tell a lot. Therefore, it may determine the role of the vehicle to some extent. This also works for backward compatibility.
AUTO attempts to automatically fill in parameters that are ambiguous when viewed as a whole.

Ves

I notice this entry:
constraint has none
... in the upper section does not generate a cab in the excel sheet. Is this true?

I higly assume that the presence of a cab is indeed used for when reversing, or at least is planned for that? Also, when the new recombination system is out, the presence of a cab should be quite vital.

Also, what does ... has cab(CLFR) mean?

Ranran

Quote from: Ves on February 01, 2020, 05:52:09 PMI notice this entry:
constraint has none
... in the upper section does not generate a cab in the excel sheet. Is this true?
No, a row is a condition for which a flag is set. Everything that matches the condition is executed. However, clearing the flag has priority as described.
If it finds constraint [n] = none, first turn ON the flag of can_be_at_tail.
Next, if it has has_cab=1, the flag of can_be_at_front will be ON.
CLFR meand can_lead_from_rear. In this case, it is considered to have a cab if its constraint has none (or no constraint setting). This exists for backward compatibility, but can_lead_from_rear is deprecated due to possible inaccuracies.

Ves

Ok, please take a look at the scheme I have made in the OP, is it correct?

Vladki

There is nothing like constraint[front]... The table does not make sense

Ves

Oh, terrible sorry, I got all mixed up in the terminology! I have changed the text to make sense now.

Ranran

I think we have to add this.

constraint[prev]=none & bidirectional=1Front cab assigned 
bidirectional = 0 displays a head with a missing upper left
bidirectional = 1 displays a sharp head.
Both have cab.

Ves

#30
Quote from: Ranran on February 01, 2020, 10:13:51 PM
I think we have to add this.

constraint[prev]=none & bidirectional=1Front cab assigned 
bidirectional = 0 displays a head with a missing upper left
bidirectional = 1 displays a sharp head.
Both have cab.
Aha ok. I got confused because when I asked this:
QuoteI notice this entry:
constraint has none
... in the upper section does not generate a cab in the excel sheet. Is this true?
.... I understood it as there should be no cab.

So this means that in either way, when constraint[prev]=none is specified, a cab is assigned. Correctly?
Is the table correct now?

Ranran

Ahh sorry, my lack of explanation and I also misunderstood.
In the case of AUTO:

constraint[prev]=none(or nothing set) & bidirectional=1 & powered vehicleFront cab assigned 
constraint[prev]=none(or nothing set) & bidirectional=1 & (not CLFR, this for Backward compatible) & non powered  
This should be the case because the above example is for backwards compatibility of locomotives. excel sheet may be wrong.

Vladki

Ranran - how could you implement it if you cannot describe it?

Ranran

All that is written in the code. However, it is difficult to explain it well and concisely. If I do it perfectly, it will be as long as explaining each line of code.
This is complicated, as I myself misunderstand.
I took the test many times in consideration of backward compatibility and repeated the verification, and it became the current form. But that is more than half year ago.

Ves

Its alright, Ranran. Its just you who know that code best, why we ask you how it works  :) This is also one of the reasons it is very good to have it written down in a truth table, so other can reference this information easily.

However, I get halfly confused by your examples :P

Perhaps we can make a quick truth table here, and you just fill in the blanks and add more parameters if there are more parameters involved. What we are interrested in is wether there is assigned a front cab or a rear cab:

1A) no constraints specified   bidirectional = 1   powered         can_lead_from_rear=1 =
1B) no constraints specified   bidirectional = 1   powered         can_lead_from_rear=0 =
1C) no constraints specified   bidirectional = 1   unpowered      can_lead_from_rear=1 =
1D) no constraints specified   bidirectional = 1   unpowered      can_lead_from_rear=0 =
1E) no constraints specified   bidirectional = 0   powered         can_lead_from_rear=1 =
1F) no constraints specified   bidirectional = 0   powered         can_lead_from_rear=0 =
1G) no constraints specified   bidirectional = 0   unpowered      can_lead_from_rear=1 =
1H) no constraints specified   bidirectional = 0   unpowered      can_lead_from_rear=0 =


2A) constraint[prev]=none      bidirectional = 1   powered         can_lead_from_rear=1 =
2B) constraint[prev]=none      bidirectional = 1   powered         can_lead_from_rear=0 =
2C) constraint[prev]=none      bidirectional = 1   unpowered      can_lead_from_rear=1 =
2D) constraint[prev]=none      bidirectional = 1   unpowered      can_lead_from_rear=0 =
2E) constraint[prev]=none      bidirectional = 0   powered         can_lead_from_rear=1 =
2F) constraint[prev]=none      bidirectional = 0   powered         can_lead_from_rear=0 =
2G) constraint[prev]=none      bidirectional = 0   unpowered      can_lead_from_rear=1 =
2H) constraint[prev]=none      bidirectional = 0   unpowered      can_lead_from_rear=0 =


3A) constraint[next]=none      bidirectional = 1   powered         can_lead_from_rear=1 =
3B) constraint[next]=none      bidirectional = 1   powered         can_lead_from_rear=0 =
3C) constraint[next]=none      bidirectional = 1   unpowered      can_lead_from_rear=1 =
3D) constraint[next]=none      bidirectional = 1   unpowered      can_lead_from_rear=0 =
3E) constraint[next]=none      bidirectional = 0   powered         can_lead_from_rear=1 =
3F) constraint[next]=none      bidirectional = 0   powered         can_lead_from_rear=0 =
3G) constraint[next]=none      bidirectional = 0   unpowered      can_lead_from_rear=1 =
3H) constraint[next]=none      bidirectional = 0   unpowered      can_lead_from_rear=0 =

I will then attempt to compile it down to a easy to read scheme in the OP.

Ranran

A good perspective.  ;)
I have prepared a pak configured as such. Insert the attached pak into pak.sweden and check the road depot.
I confirm this at today late night but check the results with your own eyes.
And it would be helpful to have an opinion on how it should be.
Because the algorithm may still have room for refinement.

Vladki

Have a look at road, ship and air depots. Some vehicles are <__), and some /__/
I have compared hovercrafts: sr-n6-winchester.dat and sr-n4-mountbatten-mk1.dat - there is no difference regarding constraints (non on both sides), and no use of bidirectional, CLFR, or has_cab... Yet they have different vehicle bar shape..   Frankly, I think that all cars, boats, and airplanes should be /__/.  As the cannot run backwards.   <__) shall be only for rail engines like american EMD F9A

Ranran

Those without a cab before in the above list were 1D, 2D and 3D.
Next, those without a cab at the rear were Unidirectional 1F, 2F, 3F, 1H, 2H, and 3H in addition to the 1D, 2D, and 3D described above.

Mariculous

Imho, the following would by logical:
"cab at front" cases
Logically, I would make the following propositions when driving forwards:
"no constraints specified" => "cab at front"
constraint[prev]=none => "can be at front" ~> true
has_front_cab=1 => "cab at front" ~> true
"cab at front" => "can be at the front" ~> true
"can be at the front" => "cab at front" ~> true
"cab at front" <=> "can be at the front" ~> true
"no cab at front" <=> "cannot be at the front" ~> true
"no cab at front" <=> "prev constraints defined" and "prev none constraint absent" ~> true

The above is only true when assuming that any vehicle is allowed to move forwards, which is currently always true.
That means a vehicle that can be at the front but doesn't have a cab there does not make sense as such a vehicle could not move forwards.
Further note I am aware that after reversal there might be a car at the "front", which is now the back, that does not have a front cab. From the old data we cannot distinguish front end cars from cabs.
Am I missing something here?

From the given information, the only thing we can say for sure about "can be at the front" is it depends. 3* cases, 3D in specific.
constraint[next]=none => "cab at front" ~> depends

"cab at rear cases"
The rear cab thing is slightly more complicated as we need to consider unidirectionality, there can be vehicles without a cab at the end and some combinations of parameters are contradictions.
It's easyer to say when we will not have a cab at rear.
Again logically, I would make the following propositions:
constraint[next]=none => "can be at rear" ~> true
"no constraints specified" => "can be at rear" ~> true
"can be at rear" and can_lead_from_rear=1 => "cab at rear" ~> true
"can be at rear" and can_lead_from_rear undefined and "powered" => "cab at rear" ~> true
"can be at rear" and can_lead_from_rear undefined and "unpowered" => "no cab at rear" ~> true
"can not be at rear" or can_lead_from_rear=0 => "no cab at rear" ~> true

Further:
can_lead_from_rear=1 and "can not be at rear"  ~> ↯
can_lead_from_rear=1 and unidirectional ~> ↯

In short
Thus, in short: 1* and 2* cases all have a front cab.
Purely from the 3* we don't know anything about the front cab.
Not covered in the table are cases with "prev" constraints defined but without a "constraint[prev]=none" defined. These don't have a front cab.

So 1D and 2D should have a front cab.

For 1* and 3* cases, the A, C, E cases have a cab at rear, B, D, F, H cases don't have a cab.
G is contradictions.
Purely from 2* cases we know B, D, F, H cases don't have a cab but the others depend.
Not covered in the table are with "next" constraints defined but without a "constraint[next]=none" either don't have a cab or are contradictions.
Also cases "with can_lead_from_rear" undefined are not covered. These behave like can_lead_from_rear=1 when powered and can_lead_from_rear=0 when unpowered.

So 1F, 3F, 1H and 3H should not have a rear cab.

Ves

Without considering how it could or should be, I attempt to distinguish the cases which is currently implemented. When that truth table is in place, we can much easier discuss what cases should generate cabs or not.

Quote from: Freahk on February 14, 2020, 07:14:24 PMG is contradictions.
I know, it is on the list just for consistency at the moment.

Quote from: Ranran on February 14, 2020, 01:49:49 PM
Those without a cab before in the above list were 1D, 2D and 3D.
Next, those without a cab at the rear were Unidirectional 1F, 2F, 3F, 1H, 2H, and 3H in addition to the 1D, 2D, and 3D described above.

So Ranran, are you saying this is how it works now:

1A) no constraints specified   bidirectional = 1   powered         can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
1B) no constraints specified   bidirectional = 1   powered         can_lead_from_rear=0 = HAS FRONT CAB   |   HAS REAR CAB
1C) no constraints specified   bidirectional = 1   unpowered      can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
1D) no constraints specified   bidirectional = 1   unpowered      can_lead_from_rear=0 =                                 |
1E) no constraints specified   bidirectional = 0   powered         can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
1F) no constraints specified   bidirectional = 0   powered         can_lead_from_rear=0 = HAS FRONT CAB   |
1G) no constraints specified   bidirectional = 0   unpowered      can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
1H) no constraints specified   bidirectional = 0   unpowered      can_lead_from_rear=0 = HAS FRONT CAB   |


2A) constraint[prev]=none      bidirectional = 1   powered         can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
2B) constraint[prev]=none      bidirectional = 1   powered         can_lead_from_rear=0 = HAS FRONT CAB   |   HAS REAR CAB
2C) constraint[prev]=none      bidirectional = 1   unpowered      can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
2D) constraint[prev]=none      bidirectional = 1   unpowered      can_lead_from_rear=0 =                                 |
2E) constraint[prev]=none      bidirectional = 0   powered         can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
2F) constraint[prev]=none      bidirectional = 0   powered         can_lead_from_rear=0 = HAS FRONT CAB   |
2G) constraint[prev]=none      bidirectional = 0   unpowered      can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
2H) constraint[prev]=none      bidirectional = 0   unpowered      can_lead_from_rear=0 = HAS FRONT CAB   |


3A) constraint[next]=none      bidirectional = 1   powered         can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
3B) constraint[next]=none      bidirectional = 1   powered         can_lead_from_rear=0 = HAS FRONT CAB   |   HAS REAR CAB
3C) constraint[next]=none      bidirectional = 1   unpowered      can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
3D) constraint[next]=none      bidirectional = 1   unpowered      can_lead_from_rear=0 =                                 |
3E) constraint[next]=none      bidirectional = 0   powered         can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
3F) constraint[next]=none      bidirectional = 0   powered         can_lead_from_rear=0 = HAS FRONT CAB   |
3G) constraint[next]=none      bidirectional = 0   unpowered      can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
3H) constraint[next]=none      bidirectional = 0   unpowered      can_lead_from_rear=0 = HAS FRONT CAB   |

When the truth table is correct, I will attempt ro write it down to a more generalized and slim truth table!

Vladki

Please is it possible to add defaults to ALL values in the first post?

I'm trying to understand the new reversal options and how the defaults behave. bidirectional, clfr, has_*_cab, and the connection to various constraints...
@Ranran would you be so kind and explain at least what is the meaning of the flags used in basic_constraint_prev/next ?


enum veh_basic_constraint_t {
cannot_be_at_end = 0,
can_be_head  = 1,
can_be_tail  = 2,
unconnectable = 4,
intermediate_unique = 8,
unknown_constraint = 128,
only_at_front =(can_be_head|unconnectable),
only_at_end = (can_be_tail|unconnectable) // this type always be bidirectional=0
};

I think that can_be_head is that it has drivers cab at the respective end, and that can_be_tail means that it can be the last vehicle in that direction (it is a brake van)
But what are the others? Especially the last combined flags: only_at_front only_at_tail. Can you show some real examples of what is what?

Also I had the feeling that the obsolete CLFR is translated to has_rear_cab, but apparently it is much more complicated. It explicitly enforces bidirectional=1 and effectively works as if the vehicle has both front and rear cabs. Which is not true for most of the vehicles that have CLFR=1. They usually have only the rear cab. I thought that if CLFR is deprecated, you would try to get rid of it ASAP and convert it to the new options, but you are still using it all over the code.

I think there is also some confusion caused by terminology. It seems that sometimes you use "END" for either end of train (front or rear), but sometimes only for the rear end.

Ranran

A new vehicle parameter was added earlier but is not listed yet.
https://forum.simutrans.com/index.php/topic,21492.msg199857.html#msg199857
Can james edit the first post and add it? I am not an English speaker.

p_accommodation[X] =
m_accommodation[X] =