This shows you the differences between two versions of the page.
Next revision | Previous revision Next revision Both sides next revision | ||
dev:core:path [2020-04-14 12:48] orwell created |
dev:core:path [2020-06-24 12:26] orwell more documentation, note on invalidate_ahead |
||
---|---|---|---|
Line 26: | Line 26: | ||
A train is moved by advancing its index. It is important to note that the train' | A train is moved by advancing its index. It is important to note that the train' | ||
+ | |||
+ | ===== Distances ===== | ||
+ | |||
+ | It is important to keep in mind that the index has little to no relation to actual distances in the cartesian space. Depending on the track orientation, | ||
+ | |||
+ | To calculate an index for a given starting index and a given distance, you can use '' | ||
+ | |||
+ | ===== In train table ===== | ||
+ | The following tables in the train table are handled by the path system: | ||
+ | < | ||
+ | -- path - path positions. ' | ||
+ | -- is the node this item corresponds to, however, this will change in the future. | ||
+ | -- path_node - (reserved) | ||
+ | -- path_cn | ||
+ | -- path_cp | ||
+ | -- When the day comes on that path!=node, these will only be set if this index represents a transition between rail nodes | ||
+ | -- path_dist - The total distance of this path element from path element 0 | ||
+ | -- path_dir | ||
+ | --Variables: | ||
+ | -- path_speed | ||
+ | -- - If 0, the train will stop 0.1 indices before this path item (definable by LZB_ZERO_APPROACH_DIST in trainlogic.lua) | ||
+ | -- path_ext_f/ | ||
+ | -- path_trk_f/ | ||
+ | -- path_req_f/ | ||
+ | </ | ||
+ | |||
===== Path generation ===== | ===== Path generation ===== | ||
+ | The path is generated on the fly, as path items are requested. | ||
+ | |||
+ | Every call to '' | ||
+ | |||
+ | The path system deletes path items that are behind the train and no longer needed automatically. | ||
+ | |||
+ | ===== Invalidation and restoration ===== | ||
+ | |||
+ | Whenever the tracks in the world change (e.g. a switch is switched), it is required to update (say ' | ||
+ | |||
+ | //With the '' | ||
+ | |||
+ | A path invalidation clears all path-related tables and variables. They remain cleared until the next call to '' | ||
+ | |||
+ | To restore the path from save files or after a path invalidation, | ||
+ | |||
+ | < | ||
+ | train.last_pos -- the world position of the path item currently at floor(train.index) | ||
+ | train.last_connid = the connid of the track connection pointing forward | ||
+ | train.last_frac = the fractional part of train.index | ||
+ | </ | ||
+ | |||
+ | To restore, train.last_pos becomes path item 0, train.index becomes last_frac, and path generation continues in last_connid direction. This causes an index shift, which also prevents integer overflows. | ||
+ | |||
+ | Note that, to have an estimated rough position of a train, you can simply query '' | ||
+ | |||
+ | A path invalidation can also occur when LZB checkpoints change, see [[dev: | ||
+ | |||
+ | ===== Invalidate Ahead ===== | ||
+ | |||
+ | In order to prevent a complete path recalculation when a far-away rail changes, '' | ||
+ | |||
+ | Obviously, due to the way the path restoration works, this would cause problems when the starting index is behind the train' | ||
+ | |||
+ | '' | ||
+ | In the future, path_invalidate_ahead() is to be preferred over path_invalidate(). | ||