aboutsummaryrefslogtreecommitdiff
path: root/serialize_lib
diff options
context:
space:
mode:
authororwell96 <orwell@bleipb.de>2021-03-13 11:29:17 +0100
committerorwell96 <orwell@bleipb.de>2021-03-13 11:29:17 +0100
commitb82e10051d69730b7459cceae4e4e8719b4445d0 (patch)
treef41e9d62af66a580a2b6574ebb26f602e3e2c2ae /serialize_lib
parent682ff59906218a78f0fa7408ab05ed5746d732e2 (diff)
Remove serialize_lib in order to re-add it as subtree
Diffstat (limited to 'serialize_lib')
-rw-r--r--serialize_lib/atomic.lua217
-rw-r--r--serialize_lib/init.lua74
-rw-r--r--serialize_lib/mod.conf1
-rw-r--r--serialize_lib/readme.md7
-rw-r--r--serialize_lib/serialize.lua269
-rw-r--r--serialize_lib/settingtypes.txt12
-rw-r--r--serialize_lib/tests/serialize_spec.lua123
7 files changed, 0 insertions, 703 deletions
diff --git a/serialize_lib/atomic.lua b/serialize_lib/atomic.lua
deleted file mode 100644
index 182cf42..0000000
--- a/serialize_lib/atomic.lua
+++ /dev/null
@@ -1,217 +0,0 @@
--- atomic.lua
--- Utilities for transaction-like handling of serialized state files
--- Also for multiple files that must be synchronous, as advtrains currently requires.
-
-
--- Managing files and backups
--- ==========================
-
---[[
-The plain scheme just overwrites the file in place. This however poses problems when we are interrupted right within
-the write, so we have incomplete data. So, the following scheme is applied:
-Unix:
-1. writes to <filename>.new
-2. moves <filename>.new to <filename>, clobbering previous file
-Windows:
-1. writes to <filename>.new
-2. delete <filename>
-3. moves <filename>.new to <filename>
-
-We count a new version of the state as "committed" after stage 2.
-
-During loading, we apply the following order of precedence:
-1. <filename>
-2. <filename>.new (windows only, in case we were interrupted just before 3. when saving)
-
-
-All of these functions return either true on success or nil, error on error.
-]]--
-
-local ser = serialize_lib.serialize
-
-local windows_mode = false
-
--- == local functions ==
-
-local function save_atomic_move_file(filename)
- --2. if windows mode, delete main file
- if windows_mode then
- local delsucc, err = os.remove(filename)
- if not delsucc then
- serialize_lib.log_warn("Unable to delete old savefile '"..filename.."':")
- serialize_lib.log_warn(err)
- serialize_lib.log_info("Trying to replace the save file anyway now...")
- end
- end
-
- --3. move file
- local mvsucc, err = os.rename(filename..".new", filename)
- if not mvsucc then
- if minetest.settings:get_bool("serialize_lib_no_auto_windows_mode") or windows_mode then
- serialize_lib.log_error("Unable to replace save file '"..filename.."':")
- serialize_lib.log_error(err)
- return nil, err
- else
- -- enable windows mode and try again
- serialize_lib.log_info("Unable to replace save file '"..filename.."' by direct renaming:")
- serialize_lib.log_info(err)
- serialize_lib.log_info("Enabling Windows mode for atomic saving...")
- windows_mode = true
- return save_atomic_move_file(filename)
- end
- end
-
- return true
-end
-
-local function open_file_and_save_callback(callback, filename)
- local file, err = io.open(filename, "w")
- if not file then
- error("Failed opening file '"..filename.."' for write:\n"..err)
- end
-
- callback(file)
- return true
-end
-
-local function open_file_and_load_callback(filename, callback)
- local file, err = io.open(filename, "r")
- if not file then
- error("Failed opening file '"..filename.."' for read:\n"..err)
- end
-
- return callback(file)
-end
-
--- == public functions ==
-
--- Load a saved state (according to comment above)
--- if 'callback' is nil: reads serialized table.
--- returns the read table, or nil,err on error
--- if 'callback' is a function (signature func(file_handle) ):
--- Counterpart to save_atomic with function argument. Opens the file and calls callback on it.
--- If the callback function throws an error, and strict loading is enabled, that error is propagated.
--- The callback's first return value is returned by load_atomic
-function serialize_lib.load_atomic(filename, callback)
-
- local cbfunc = callback or ser.read_from_fd
-
- -- try <filename>
- local file, ret = io.open(filename, "r")
- if file then
- -- read the file using the callback
- local success
- success, ret = pcall(cbfunc, file)
- if success then
- return ret
- end
- end
-
- if minetest.settings:get_bool("serialize_lib_strict_loading") then
- serialize_lib.save_lock = true
- error("Loading data from file '"..filename.."' failed:\n"
- ..ret.."\nDisable Strict Loading to ignore.")
- end
-
- serialize_lib.log_warn("Loading data from file '"..filename.."' failed, trying .new fallback:")
- serialize_lib.log_warn(ret)
-
- -- try <filename>.new
- file, ret = io.open(filename..".new", "r")
- if file then
- -- read the file using the callback
- local success
- success, ret = pcall(cbfunc, file)
- if success then
- return ret
- end
- end
-
- serialize_lib.log_error("Unable to load data from '"..filename..".new':")
- serialize_lib.log_error(ret)
- serialize_lib.log_error("Note: This message is normal when the mod is loaded the first time on this world.")
-
- return nil, ret
-end
-
--- Save a file atomically (as described above)
--- 'data' is the data to be saved (when a callback is used, this can be nil)
--- if 'callback' is nil:
--- data must be a table, and is serialized into the file
--- if 'callback' is a function (signature func(data, file_handle) ):
--- Opens the file and calls callback on it. The 'data' argument is the data passed to save_atomic().
--- If the callback function throws an error, and strict loading is enabled, that error is propagated.
--- The callback's first return value is returned by load_atomic
--- Important: the callback must close the file in all cases!
-function serialize_lib.save_atomic(data, filename, callback, config)
- if serialize_lib.save_lock then
- serialize_lib.log_warn("Instructed to save '"..filename.."', but save lock is active!")
- return nil
- end
-
- local cbfunc = callback or ser.write_to_fd
-
- local file, ret = io.open(filename..".new", "w")
- if file then
- -- save the file using the callback
- local success
- success, ret = pcall(cbfunc, data, file)
- if success then
- return save_atomic_move_file(filename)
- end
- end
- serialize_lib.log_error("Unable to save data to '"..filename..".new':")
- serialize_lib.log_error(ret)
- return nil, ret
-end
-
-
--- Saves multiple files synchronously. First writes all data to all <filename>.new files,
--- then moves all files in quick succession to avoid inconsistent backups.
--- parts_table is a table where the keys are used as part of the filename and the values
--- are the respective data written to it.
--- e.g. if parts_table={foo={...}, bar={...}}, then <filename_prefix>foo and <filename_prefix>bar are written out.
--- if 'callbacks_table' is defined, it is consulted for callbacks the same way save_atomic does.
--- example: if callbacks_table = {foo = func()...}, then the callback is used during writing of file 'foo' (but not for 'bar')
--- Note however that you must at least insert a "true" in the parts_table if you don't use the data argument.
--- Important: the callback must close the file in all cases!
-function serialize_lib.save_atomic_multiple(parts_table, filename_prefix, callbacks_table, config)
- if serialize_lib.save_lock then
- serialize_lib.log_warn("Instructed to save '"..filename_prefix.."' (multiple), but save lock is active!")
- return nil
- end
-
- for subfile, data in pairs(parts_table) do
- local filename = filename_prefix..subfile
- local cbfunc = ser.write_to_fd
- if callbacks_table and callbacks_table[subfile] then
- cbfunc = callbacks_table[subfile]
- end
-
- local success = false
- local file, ret = io.open(filename..".new", "w")
- if file then
- -- save the file using the callback
- success, ret = pcall(cbfunc, data, file, config)
- end
-
- if not success then
- serialize_lib.log_error("Unable to save data to '"..filename..".new':")
- serialize_lib.log_error(ret)
- return nil, ret
- end
- end
-
- local first_error
- for file, _ in pairs(parts_table) do
- local filename = filename_prefix..file
- local succ, err = save_atomic_move_file(filename)
- if not succ and not first_error then
- first_error = err
- end
- end
-
- return not first_error, first_error -- either true,nil or nil,error
-end
-
-
diff --git a/serialize_lib/init.lua b/serialize_lib/init.lua
deleted file mode 100644
index 20ffa4d..0000000
--- a/serialize_lib/init.lua
+++ /dev/null
@@ -1,74 +0,0 @@
--- serialize_lib
---[[
- Copyright (C) 2020 Moritz Blei (orwell96) and contributors
-
- This program is free software: you can redistribute it and/or modify
- it under the terms of the GNU Affero General Public License as
- published by the Free Software Foundation, either version 3 of the
- License, or (at your option) any later version.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU Affero General Public License for more details.
-]]--
-
-serialize_lib = {}
-
---[[ Configuration table
-Whenever asked for a "config", the following table structure is expected:
-config = {
- skip_empty_tables = false -- if true, does not store empty tables
- -- On next read, keys that mapped to empty tables resolve to nil
- -- Used by: write_table_to_file
-}
-Not all functions use all of the parameters, so you can simplify your config sometimes
-]]
-
--- log utils
--- =========
-
-
-function serialize_lib.log_error(text)
- minetest.log("error", "[serialize_lib] ("..(minetest.get_current_modname() or "?").."): "..(text or "<nil>"))
-end
-function serialize_lib.log_warn(text)
- minetest.log("warning", "[serialize_lib] ("..(minetest.get_current_modname() or "?").."): "..(text or "<nil>"))
-end
-function serialize_lib.log_info(text)
- minetest.log("action", "[serialize_lib] ("..(minetest.get_current_modname() or "?").."): "..(text or "<nil>"))
-end
-function serialize_lib.log_debug(text)
- minetest.log("action", "[serialize_lib] ("..(minetest.get_current_modname() or "?")..") DEBUG: "..(text or "<nil>"))
-end
-
--- basic serialization/deserialization
--- ===================================
-
-local mp = minetest.get_modpath(minetest.get_current_modname())
-serialize_lib.serialize = dofile(mp.."/serialize.lua")
-dofile(mp.."/atomic.lua")
-
-local ser = serialize_lib.serialize
-
--- Opens the passed filename, and returns deserialized table
--- When an error occurs, logs an error and returns false
-function serialize_lib.read_table_from_file(filename)
- local succ, ret = pcall(ser.read_from_file, filename)
- if not succ then
- serialize_lib.log_error(ret)
- end
- return ret
-end
-
--- Writes table into file
--- When an error occurs, logs an error and returns false
-function serialize_lib.write_table_to_file(root_table, filename)
- local succ, ret = pcall(ser.write_to_file, root_table, filename)
- if not succ then
- serialize_lib.log_error(ret)
- end
- return ret
-end
-
-
diff --git a/serialize_lib/mod.conf b/serialize_lib/mod.conf
deleted file mode 100644
index ac3a1bd..0000000
--- a/serialize_lib/mod.conf
+++ /dev/null
@@ -1 +0,0 @@
-name = serialize_lib
diff --git a/serialize_lib/readme.md b/serialize_lib/readme.md
deleted file mode 100644
index ac364b8..0000000
--- a/serialize_lib/readme.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# serialize_lib
-A Minetest mod library for safely storing large amounts of data in on-disk files.
-Created out of the need to have a robust data store for advtrains.
-
-The main purpose is to load and store large Lua table structures into files, without loading everything in memory and exhausting the function constant limit of LuaJIT.
-
-Also contains various utilities to handle files on disk in a safe manner, retain multiple versions of the same file a.s.o. \ No newline at end of file
diff --git a/serialize_lib/serialize.lua b/serialize_lib/serialize.lua
deleted file mode 100644
index 12a26c4..0000000
--- a/serialize_lib/serialize.lua
+++ /dev/null
@@ -1,269 +0,0 @@
--- serialize.lua
--- Lua-conformant library file that has no minetest dependencies
--- Contains the serialization and deserialization routines
-
---[[
-
-Structure of entry:
-[keytype][key]:[valuetype][val]
-Types:
- B - bool
- -> 0=false, 1=true
- S - string
- -> see below
- N - number
- -> thing compatible with tonumber()
-Table:
-[keytype][key]:T
-... content is nested in table until the matching
-E
-
-example:
-LUA_SER v=1 {
-Skey:Svalue key = "value",
-N1:Seins [1] = "eins",
-B1:T [true] = {
-Sa:Sb a = "b",
-Sc:B0 c = false,
-E }
-E }
-
-String representations:
-In strings the following characters are escaped by &
-'&' -> '&&'
-(line break) -> '&n'
-(CR) -> '&r' --> required?
-':' -> '&:'
-All other characters are unchanged as they bear no special meaning.
-]]
-
-local write_table, literal_to_string, escape_chars, table_is_empty
-
-function table_is_empty(t)
- for _,_ in pairs(t) do
- return false
- end
- return true
-end
-
-function write_table(t, file, config)
- local ks, vs, writeit, istable
- for key, value in pairs(t) do
- ks = value_to_string(key, false)
- writeit = true
- istable = type(value)=="table"
-
- if istable then
- vs = "T"
- if config and config.skip_empty_tables then
- writeit = not table_is_empty(value)
- end
- else
- vs = value_to_string(value, true)
- end
-
- if writeit then
- file:write(ks..":"..vs.."\n")
-
- if istable then
- write_table(value, file, config)
- file:write("E\n")
- end
- end
- end
-end
-
-function value_to_string(t)
- if type(t)=="table" then
- file:close()
- error("Can not serialize a table in the key position!")
- elseif type(t)=="boolean" then
- if t then
- return "B1"
- else
- return "B0"
- end
- elseif type(t)=="number" then
- return "N"..t
- elseif type(t)=="string" then
- return "S"..escape_chars(t)
- else
- --error("Can not serialize '"..type(t).."' type!")
- return "S<function>"
- end
- return str
-end
-
-function escape_chars(str)
- local rstr = string.gsub(str, "&", "&&")
- rstr = string.gsub(rstr, ":", "&:")
- rstr = string.gsub(rstr, "\n", "&n")
- return rstr
-end
-
-------
-
-local read_table, string_to_value, unescape_chars
-
-function read_table(t, file)
- local line, ks, vs, kv, vv, vt
- while true do
- line = file:read("*l")
- if not line then
- file:close()
- error("Unexpected EOF or read error!")
- end
-
- if line=="E" then
- -- done with this table
- return
- end
- ks, vs = string.match(line, "^(.*[^&]):(.+)$")
- if not ks or not vs then
- file:close()
- error("Unable to parse line: '"..line.."'!")
- end
- kv = string_to_value(ks)
- vv, vt = string_to_value(vs, true)
- if vt then
- read_table(vv, file)
- end
- -- put read value in table
- t[kv] = vv
- end
-end
-
--- returns: value, is_table
-function string_to_value(str, table_allow)
- local first = string.sub(str, 1,1)
- local rest = string.sub(str, 2)
- if first=="T" then
- if table_allow then
- return {}, true
- else
- file:close()
- error("Table not allowed in key component!")
- end
- elseif first=="N" then
- local num = tonumber(rest)
- if num then
- return num
- else
- file:close()
- error("Unable to parse number: '"..rest.."'!")
- end
- elseif first=="B" then
- if rest=="0" then
- return false
- elseif rest=="1" then
- return true
- else
- file:close()
- error("Unable to parse boolean: '"..rest.."'!")
- end
- elseif first=="S" then
- return unescape_chars(rest)
- else
- file:close()
- error("Unknown literal type '"..first.."' for literal '"..str.."'!")
- end
-end
-
-function unescape_chars(str) --TODO
- local rstr = string.gsub(str, "&:", ":")
- rstr = string.gsub(rstr, "&n", "\n")
- rstr = string.gsub(rstr, "&&", "&")
- return rstr
-end
-
-------
-
---[[
-config = {
- skip_empty_tables = false -- if true, does not store empty tables
- -- On next read, keys that mapped to empty tables resolve to nil
-}
-]]
-
--- Writes the passed table into the passed file descriptor, and closes the file
-local function write_to_fd(root_table, file, config)
- file:write("LUA_SER v=1\n")
- write_table(root_table, file, config)
- file:write("E\nEND_SER\n")
- file:close()
-end
-
--- Reads the file contents from the passed file descriptor and returns the table on success
--- Throws errors when something is wrong. Closes the file.
--- config: see above
-local function read_from_fd(file)
- local first_line = file:read("*l")
- if first_line ~= "LUA_SER v=1" then
- file:close()
- error("Expected header, got '"..first_line.."' instead!")
- end
- local t = {}
- read_table(t, file)
- local last_line = file:read("*l")
- file:close()
- if last_line ~= "END_SER" then
- error("Missing END_SER, got '"..last_line.."' instead!")
- end
- return t
-end
-
--- Opens the passed filename and serializes root_table into it
--- config: see above
-function write_to_file(root_table, filename, config)
- -- try opening the file
- local file, err = io.open(filename, "w")
- if not file then
- error("Failed opening file '"..filename.."' for write:\n"..err)
- end
-
- write_to_fd(root_table, file, config)
- return true
-end
-
--- Opens the passed filename, and returns its deserialized contents
-function read_from_file(filename)
- -- try opening the file
- local file, err = io.open(filename, "r")
- if not file then
- error("Failed opening file '"..filename.."' for read:\n"..err)
- end
-
- return read_from_fd(file)
-end
-
---[[ simple unit test
-local testtable = {
- key = "value",
- [1] = "eins",
- [true] = {
- a = "b",
- c = false,
- },
- ["es:cape1"] = "foo:bar",
- ["es&ca\npe2"] = "baz&bam\nbim",
- ["es&&ca&\npe3"] = "baz&&bam&\nbim",
- ["es&:cape4"] = "foo\n:bar"
-}
-local config = {}
---write_to_file(testtable, "test_out", config)
-local t = read_from_file("test_out")
-write_to_file(t, "test_out_2", config)
-local t2 = read_from_file("test_out_2")
-write_to_file(t2, "test_out_3", config)
-
--- test_out_2 and test_out_3 should be equal
-
---]]
-
-
-return {
- read_from_fd = read_from_fd,
- write_to_fd = write_to_fd,
- read_from_file = read_from_file,
- write_to_file = write_to_file,
-}
diff --git a/serialize_lib/settingtypes.txt b/serialize_lib/settingtypes.txt
deleted file mode 100644
index 3a565a6..0000000
--- a/serialize_lib/settingtypes.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-# Enable strict file loading mode
-# If enabled, if any error occurs during loading of a file using the 'atomic' API,
-# an error is thrown. You probably need to disable this option for initial loading after
-# creating the world.
-serialize_lib_strict_loading (Strict loading) bool false
-
-# Do not automatically switch to "Windows mode" when saving atomically
-# Normally, when renaming <filename>.new to <filename> fails, serialize_lib automatically
-# switches to a mode where it deletes <filename> prior to moving. Enable this option to prevent
-# this behavior and abort saving instead.
-serialize_lib_no_auto_windows_mode (No automatic Windows Mode) bool false
-
diff --git a/serialize_lib/tests/serialize_spec.lua b/serialize_lib/tests/serialize_spec.lua
deleted file mode 100644
index ccc3a67..0000000
--- a/serialize_lib/tests/serialize_spec.lua
+++ /dev/null
@@ -1,123 +0,0 @@
--- test the serialization function
-
-
-package.path = "../?.lua;" .. package.path
-
-
-ser = require("serialize")
-
-
-local mock_file = {}
-_G.mock_file = mock_file
-function mock_file:read(arg)
- if arg == "*l" then
- local l = self.lines[self.pointer or 1]
- self.pointer = (self.pointer or 1) + 1
- return l
- end
-end
-
-function mock_file:close()
- return nil
-end
-
-function mock_file:write(text)
- self.content = self.content..text
-end
-
-function mock_file:create(lines)
- local f = {}
- setmetatable(f, mock_file)
- f.lines = lines or {}
- f.write = self.write
- f.close = self.close
- f.read = self.read
- f.content = ""
- return f
-end
-
-
-local testtable = {
- key = "value",
- [1] = "eins",
- [true] = {
- a = "b",
- c = false,
- },
- ["es:cape1"] = "foo:bar",
- ["es&ca\npe2"] = "baz&bam\nbim",
- ["es&&ca&\npe3"] = "baz&&bam&\nbim",
- ["es&:cape4"] = "foo\n:bar"
-}
-local testser = [[LUA_SER v=1
-B1:T
-Sa:Sb
-Sc:B0
-E
-Skey:Svalue
-Ses&&&&ca&&&npe3:Sbaz&&&&bam&&&nbim
-N1:Seins
-Ses&&&:cape4:Sfoo&n&:bar
-Ses&&ca&npe2:Sbaz&&bam&nbim
-Ses&:cape1:Sfoo&:bar
-E
-END_SER
-]]
-
-local function check_write(tb, conf)
- f = mock_file:create()
- ser.write_to_fd(tb, f, conf or {})
- return f.content
-end
-
-function string:split()
- local fields = {}
- self:gsub("[^\n]+", function(c) fields[#fields+1] = c end)
- return fields
-end
-
-local function check_read(text)
- f = mock_file:create(text:split())
- return ser.read_from_fd(f)
-end
-
-local noskip = [[LUA_SER v=1
-N1:T
-E
-E
-END_SER
-]]
-local skip = [[LUA_SER v=1
-E
-END_SER
-]]
-
-describe("write_to_fd", function()
- it("serializes a table correctly", function()
- assert.equals(check_write(testtable), testser)
- end)
- it("does not skip empty tables", function()
- assert.equals(check_write({{}}),noskip)
- end)
- it("skips empty tables when needed", function()
-
- assert.equals(check_write({{}},{skip_empty_tables=true}),skip)
- end)
-end)
-
-describe("read_from_fd", function ()
- it("reads a table correctly", function()
- assert.same(check_read(testser),testtable)
- end)
- it("handles some edge cases correctly", function()
- assert.same(check_read(noskip), {{}})
- assert.same(check_read(skip), {})
- end)
- it("Read back table", function()
- local tb = {}
- for k=1,262 do
- tb[k] = { "Foo", "bar", k}
- end
- assert.same(check_read(check_write(tb)), tb)
- end)
-end)
alt="PIC" > <!--l. 90--><p class="noindent" >Now you have assigned the TCB node to a rail. Right-click the TCB node once again. This will bring up a form which looks as follows: <!--l. 93--><p class="noindent" ><img src="1_home_moritz_Home_Projekte_Minetest_minetest_m____lyx_img_Bildschirmfoto_2018-08-30_14-26-35.png" alt="PIC" > <!--l. 95--><p class="noindent" >You see that the form is divided in side A and side B. To designate where each side is, a marker is displayed on the rail. You can always make this marker show up by punching the TCB node, and remove it by punching the marker. Both sides are shown as &#8220;End of interlocking&#8221;. This means that there is no track section set up at this place. <!--l. 101--><p class="noindent" >You should repeat this procedure once again a few meters away from the first TCB to create a second TCB on the same track. <!--l. 104--><p class="noindent" ><img src="2_home_moritz_Home_Projekte_Minetest_minetest_m____lyx_img_Bildschirmfoto_2018-08-30_14-32-48.png" alt="PIC" > <!--l. 106--><p class="noindent" >Once you have both bordering TCBs set up, you can now create the actual track section. To do this: <ol class="enumerate1" > <li class="enumerate" id="x1-12x1">Right-click one of the TCBs </li> <li class="enumerate" id="x1-14x2">Locate the correct side (A or B) to create the track section </li> <li class="enumerate" id="x1-16x3">Click &#8220;Create interlocked Track Section&#8221; in the formspec on the chosen side.</li></ol> <!--l. 114--><p class="noindent" >Now, the text on the formspec has changed. It shows something like this: <!--l. 117--><p class="noindent" ><img src="3_home_moritz_Home_Projekte_Minetest_minetest_m____lyx_img_Bildschirmfoto_2018-08-30_14-27-25.png" alt="PIC" > <!--l. 119--><p class="noindent" >Clicking &#8220;Show Track Section&#8221; brings up another formspec: <!--l. 121--><p class="noindent" ><img src="4_home_moritz_Home_Projekte_Minetest_minetest_m____lyx_img_Bildschirmfoto_2018-08-30_14-28-32.png" alt="PIC" > <!--l. 123--><p class="noindent" >On the top, you see a list of all TCBs that border this track section. In your case, there should be two TCBs listed. If there&#8217;s only one, head over to <a href="#x1-17r2">2.2<!--tex4ht:ref: subsec:Long-track-sections, --></a>. You should now select a name for the track section, to identify it later. <!--l. 128--><p class="noindent" >The same procedure is applicable when you create a turnout track section, except that you have to set up three or more TCBs. <!--l. 131--><p class="noindent" >The AdvTrains interlocking system allows you to add more TCBs after you have created a track section. This works without problems in most cases. For example, you can easily insert a turnout into an already set-up track section and create another TCB behind it, and AdvTrains will automatically detect the existing track section. Problems arise only if you try to insert a TCB in-between a section, in which case both sides of the TCB will end up assigned to the same section. The code currently does not handle this case properly, so try to avoid this situation by all means. As a last resort, you can always dissolve a faulty track section, as described in the next chapter. <!--l. 142--><p class="noindent" > <a id="x1-17r2"></a> <!--l. 142--><p class="noindent" ><span class="ecsx-1200">2.2</span> <span class="ecsx-1200">Long</span> <span class="ecsx-1200">track</span> <span class="ecsx-1200">sections,</span> <span class="ecsx-1200">crossings</span> <span class="ecsx-1200">and</span> <span class="ecsx-1200">other</span> <span class="ecsx-1200">edge</span> <span class="ecsx-1200">cases</span> <a id="Q1-1-0"></a> <!--l. 144--><p class="noindent" > <a id="x1-18r1"></a> <!--l. 144--><p class="noindent" ><span class="ecsx-1000">2.2.1</span> <span class="ecsx-1000">Very</span> <span class="ecsx-1000">long</span> <span class="ecsx-1000">track</span> <span class="ecsx-1000">sections</span> <a id="Q1-1-0"></a> <!--l. 146--><p class="noindent" >If you try to set up a track section that is longer than 1000 nodes, advtrains won&#8217;t recognize the TCB at the other end because of a safety limit in the traverser function, which is supposed to prevent deadlocks. This case has happened when the Track Section overview screen only shows one TCB in the list. The procedure for this is as follows: <ol class="enumerate1" > <li class="enumerate" id="x1-20x1">Go to the second TCB (the one that wasn&#8217;t recognized). It should show &#8220;End of Interlocking&#8221; on the relevant side. </li> <li class="enumerate" id="x1-22x2">Click &#8220;Create interlocked track section&#8221;. The section created will be different from the one that is already present. </li> <li class="enumerate" id="x1-24x3">In the track section overview, click &#8220;Join into other section&#8221; </li> <li class="enumerate" id="x1-26x4">Go back to the first TCB, bring up the Track Section overview screen of the first track section and click &#8220;Join with ???&#8221;</li></ol> <!--l. 160--><p class="noindent" >The other, missing TCB should now appear in the list. If you accidentally started such a joining procedure, click the &#8220;X&#8221; button on the right. <!--l. 164--><p class="noindent" > <a id="x1-27r2"></a> <!--l. 164--><p class="noindent" ><span class="ecsx-1000">2.2.2</span> <span class="ecsx-1000">Rail</span> <span class="ecsx-1000">crosses</span> <a id="Q1-1-0"></a> <!--l. 166--><p class="noindent" >Since rail crosses are created by laying tracks across each other without logical connection, there&#8217;s no way for advtrains to know whether rails cross each other. <!--l. 170--><p class="noindent" >Rail crossings in interlocking systems are always one single track section, which in most cases has 4 TCBs adjacent. <!--l. 173--><p class="noindent" ><img src="5_home_moritz_Home_Projekte_Minetest_minetest_m____lyx_img_Bildschirmfoto_2018-08-30_14-51-25.png" alt="PIC" > <!--l. 175--><p class="noindent" >The procedure is quite similar to the one for long sections: First, create two track sections for the branches, and then use the &#8220;Join&#8221; function to merge both sections into one. <!--l. 179--><p class="noindent" > <a id="x1-28r3"></a> <!--l. 179--><p class="noindent" ><span class="ecsx-1000">2.2.3</span> <span class="ecsx-1000">Deleting</span> <span class="ecsx-1000">and</span> <span class="ecsx-1000">re-adding</span> <span class="ecsx-1000">single</span> <span class="ecsx-1000">TCBs</span> <span class="ecsx-1000">to</span> <span class="ecsx-1000">a</span> <span class="ecsx-1000">section</span> <a id="Q1-1-0"></a> <!--l. 181--><p class="noindent" >In some occasions, for example when you remove a siding or a crossover, it can be necessary to unassign a TCB from a track section. There are multiple ways to do this: <ul class="itemize1"> <li class="itemize">In the TCB form, click the &#8220;Remove from section&#8221; button </li> <li class="itemize">In the track section form, first select the TCB in the list and then click &#8220;Unlink selected TCB&#8221;</li></ul> <!--l. 189--><p class="noindent" >The result is that the TCB shows &#8220;End of Interlocking&#8221; and the section does not list the TCB as an endpoint anymore. <!--l. 192--><p class="noindent" >The other case is adding a siding or a crossover, in which case one or more TCBs still show &#8220;End of Interlocking&#8221; although they should be part of a section: <ul class="itemize1"> <li class="itemize">Go to another TCB that is registered in the track section and click &#8220;Update near TCBs&#8221; </li> <li class="itemize">If that did not work, follow the procedure of creating a long track section</li></ul> <!--l. 202--><p class="noindent" > <a id="x1-29r4"></a> <!--l. 202--><p class="noindent" ><span class="ecsx-1000">2.2.4</span> <span class="ecsx-1000">Dissolving</span> <span class="ecsx-1000">sections</span> <a id="Q1-1-0"></a> <!--l. 204--><p class="noindent" >If you made a mistake setting up something and you don&#8217;t see any other way to fix a misconfigured track section, you can always delete it using the &#8220;Dissolve section&#8221; button. This operation removes the track section and sets all TCBs that previously belonged to the section as &#8220;End of Interlocking&#8221;. This will always work and lets you start over new with setting up track sections. <!--l. 211--><p class="noindent" > <a id="x1-30r3"></a> <!--l. 211--><p class="noindent" ><span class="ecsx-1200">2.3</span> <span class="ecsx-1200">Interlocking</span> <span class="ecsx-1200">patterns</span> <a id="Q1-1-0"></a> <!--l. 213--><p class="noindent" >Have a look at the following images. They show you how you can set up sections so that reasonable train moves are possible. <!--l. 216--><p class="noindent" >You should settle on a naming scheme for your sections. This way, you can determine the source of an issue faster <!--l. 219--><p class="noindent" > <a id="x1-31r3"></a> <!--l. 219--><p class="noindent" ><span class="ecsx-1200">3</span> <span class="ecsx-1200">Signals</span> <span class="ecsx-1200">and</span> <span class="ecsx-1200">routes</span> <a id="Q1-1-0"></a> <!--l. 221--><p class="noindent" >Signals are appliances that can give instructions to trains. That can be the permission to proceed, a speed restriction, or other information. <!--l. 224--><p class="noindent" >There are 2 types of signals: <ul class="itemize1"> <li class="itemize">Static signals always display the same information to the train. This can be a speed restriction (or the end of one), a disallowal to proceed as shunt move or similar things. In most cases, these are signs. </li> <li class="itemize">Dynamic signals are what most people would call a &#8220;signal&#8221;. Its function is to inform trains about whether and at which speed they can proceed into the next section safely.</li></ul> <!--l. 234--><p class="noindent" > <a id="x1-32r1"></a> <!--l. 234--><p class="noindent" ><span class="ecsx-1200">3.1</span> <span class="ecsx-1200">Signal</span> <span class="ecsx-1200">Influence</span> <span class="ecsx-1200">Point</span> <a id="Q1-1-0"></a> <!--l. 236--><p class="noindent" >Every signal is associated to a track on which the instruction should be followed. Signals are usually placed right next to the track on the right side. Human observers do know then that the signal belongs to the track left of it, however, train safety systems (like the one in advtrains) can not. <!--l. 242--><p class="noindent" >This is the reason why a so-called &#8220;influence point&#8221; needs to be assigned to any signal that should actually give instructions to trains, should the driver (if even there is one) fail to recognize the instructions. <!--l. 247--><p class="noindent" >Depending on the signal and the mod that adds the signal, there are different ways to configure this. Signals integrated into advtrains behave as follows: <ul class="itemize1"> <li class="itemize">Static signals and all red-green light signals from core advtrains that are not assigned to a TCB can be configured by holding the &#8220;Use&#8221; key and then right-clicking the signal </li> <li class="itemize">All signals that are assigned to a TCB can be configured by first right-clicking them, then selecting &#8220;Influence Point&#8221; in the signalling formspec.</li></ul> <!--l. 258--><p class="noindent" >The small formspec that opens allows you to set and later view or clear the Influence Point. To set the influence point, click the &#8220;Set&#8221; button, face towards the signal and punch a rail about 2m in front of the signal. A small marker will be shown, indicating success. To cancel setting an influence point, punch anything other. (note that then the influence point remains unset, regardless of its previous state) <!--l. 266--><p class="noindent" >The advtrains-internal train safety system ensures that the train always obeys any restrictions imposed by signals, if (and only if) the influence point is set properly. <!--l. 270--><p class="noindent" > <a id="x1-33r2"></a> <!--l. 270--><p class="noindent" ><span class="ecsx-1200">3.2</span> <span class="ecsx-1200">Signal</span> <span class="ecsx-1200">Aspects</span> <a id="Q1-1-0"></a> <!--l. 272--><p class="noindent" >While static signals are mainly used for speed restrictions, the interesting ones are variable signals. Of course, you can always control any variable signal by traditional means (mesecons, digiline, right-click) if the signal allows it, but that misses the point of this interlocking system. <!--l. 277--><p class="noindent" >A signal aspect is a piece of information that a signal shows to the train driver. It contains information about whether and at what speed the driver may proceed at the signal. <!--l. 281--><p class="noindent" >Every signal, both static and dynamic ones, imposes a certain aspect to trains passing the signal. For static signals, this is always the same aspect, such as &#8220;Proceed at speed of 8&#8221; or &#8220;Shunt moves may not pass&#8221;. Dynamic signals, however, can display multiple different aspects. The default for them is always as restrictive as possible, mostly &#8220;Halt!&#8221;. <!--l. 288--><p class="noindent" >You should know that both static and dynamic signals use exactly the same properties for signal aspects. There is no difference in the meaning of the aspect definitions. <!--l. 292--><p class="noindent" >In the following sections, we will talk about main signals. By this, we mean a variable signal that can display both a &#8220;Danger&#8221; aspect (trains are not allowed to proceed) and at least one &#8220;Proceed&#8221; aspect (train may proceed as train/shunt move, with optional speed restriction), which act as an &#8220;entry signal&#8221; for one or multiple routes. <!--l. 299--><p class="noindent" > <a id="x1-34r3"></a> <!--l. 299--><p class="noindent" ><span class="ecsx-1200">3.3</span> <span class="ecsx-1200">Train</span> <span class="ecsx-1200">moves</span> <span class="ecsx-1200">and</span> <span class="ecsx-1200">Shunt</span> <span class="ecsx-1200">Moves</span> <a id="Q1-1-0"></a> <ul class="itemize1"> <li class="itemize">A &#8220;Train move&#8221; is a train that is running, going to run on or coming from a main line between stations, passing through or stopping at a station. Train moves can expect that there are no obstacles on the route and they can proceed at the maximum permitted speed of the line. This is the regular operation mode for trains. Shunt signals have no meaning for train moves. </li> <li class="itemize">A &#8220;Shunt move&#8221; is a train that moves within a station and/or is coupling or decoupling wagons or engines. A shunt move may never leave a station except into a siding. Also, shunt moves may drive at a maximum speed of 6 speed units, because it is usually not ensured that the path is free of obstacles. (however, advtrains ensures that every route is free of railway vehicles, even shunt routes)</li></ul> <!--l. 314--><p class="noindent" >There are also 2 general types of signals: Main signals and Shunt signals. While main signals have a meaning for all types of trains, Shunt signals only have to be followed by shunt moves. Usually, Shunt signals that are on a train move route are set to a Proceed aspect as well. <!--l. 320--><p class="noindent" >When a train reverses, its mode automatically changes to &#8220;shunt move&#8221; until it passes a main signal that shows &#8220;Proceed as train move&#8221;, which is usually designated by a green light. From this point on, it can accelerate to maximum permitted speed. <!--l. 325--><p class="noindent" >Some main signals, like the ones from the Ks signals mod included by default, can also display &#8220;Proceed as shunt move&#8221;, which is designated by 2 white lights along with the red light. Once a train passes this signal, it becomes a shunt move. <!--l. 330--><p class="noindent" > <a id="x1-35r4"></a> <!--l. 330--><p class="noindent" ><span class="ecsx-1200">3.4</span> <span class="ecsx-1200">The</span> <span class="ecsx-1200">concept</span> <span class="ecsx-1200">of</span> <span class="ecsx-1200">routes</span> <a id="Q1-1-0"></a> <!--l. 332--><p class="noindent" >A so-called route is a locked path between two main signals, which locks all turnouts in the correct position. Its purpose is to offer a train a path on which it can safely proceed without interfering with any other train. A route always incorporates and locks one to multiple track sections, starting with the one that lies directly behind the &#8220;entry&#8221; signal. <!--l. 339--><p class="noindent" >Example: Imagine a station with 2 platforms on a single track running line. We are looking at signal A. You probably want trains coming from the right to go into platform 1 or into platform 2, so you need to program 2 routes. <!--l. 344--><p class="noindent" ><img src="6_home_moritz_Home_Projekte_Minetest_minetest_mods_advtrains_assets_lyx_img_route_ex1.png" alt="PIC" > <!--l. 346--><p class="noindent" >This leads us to the most important aspect of route programming: Routes always start at a signal (A) and end at a signal facing in the <span class="ecbx-1000">same direction </span>(D and E), not at an opposite-facing signal (B and C). There are only few exceptions, we&#8217;ll cover this later. <!--l. 351--><p class="noindent" >When you set a route to make a train proceed on it, the interlocking system ensures that: <ul class="itemize1"> <li class="itemize">There are no rail vehicles on the route </li> <li class="itemize">All turnouts are set to the correct position and it is impossible to move them </li> <li class="itemize">No other routes can be set that would in any way conflict with this route</li></ul> <!--l. 360--><p class="noindent" >For this to work, you need to specify all track sections the train will pass along, as well as the positions of all turnouts that need to be locked. Those are not only the turnouts that lay directly on the train&#8217;s route, but also some turnouts on adjacent tracks, the so-called flank protection. <!--l. 366--><p class="noindent" >The purpose of flank protection is to prevent runaway trains and/or wagons to pass into a route. This is achieved by setting nearby turnouts to a position that points &#8220;away&#8221; from the route. Example: <!--l. 370--><p class="noindent" ><img src="7_home_moritz_Home_Projekte_Minetest_minetest_mods_advtrains_assets_lyx_img_route_ex2.png" alt="PIC" > <!--l. 372--><p class="noindent" >The upper turnout, of course, needs to be locked in straight (normal) position, while the lower one is not relevant for the route itself. But what if the lower turnout was set to the diverging (reverse) position and the driver of another train approaching signal B fails to see the red light? This train would crash into the first one. To minimise danger, that other train would need to be routed towards signal D. <!--l. 379--><p class="noindent" >There are, of course, situations, where both positions of a turnout would conflict with a route equally. In those situations, there&#8217;s nothing you can do and no flank lock needs to be set. <!--l. 383--><p class="noindent" > <a id="x1-36r5"></a> <!--l. 383--><p class="noindent" ><span class="ecsx-1200">3.5</span> <span class="ecsx-1200">Assigning</span> <span class="ecsx-1200">main</span> <span class="ecsx-1200">signals</span> <span class="ecsx-1200">to</span> <span class="ecsx-1200">TCBs</span> <a id="Q1-1-0"></a> <!--l. 385--><p class="noindent" >Main signals in the advtrains interlocking system are positioned - like in real life - at the border of track sections, because routes also start and end there. For advtrains to know from which signal which routes can be set, you need to assign the signal to a TCB. <!--l. 390--><p class="noindent" >To do this, perform the following steps: <ol class="enumerate1" > <li class="enumerate" id="x1-38x1">If not already happened, set up a TCB (you don&#8217;t need to, but are advised to, configure track sections there) </li> <li class="enumerate" id="x1-40x2">Place the signal a few meters in front of the TCB, so that trains stopping at the signal do never pass the TCB </li> <li class="enumerate" id="x1-42x3">Locate the side of the TCB which points in the direction that trains will proceed past the signal, as shown in the figure below. </li> <li class="enumerate" id="x1-44x4">Right-click the TCB, and click &#8220;Assign a signal&#8221; on this side. </li> <li class="enumerate" id="x1-46x5">Punch the signal.</li></ol> <!--l. 401--><p class="noindent" ><img src="8_home_moritz_Home_Projekte_Minetest_minetest_mods_advtrains_assets_lyx_img_assign_signal.png" alt="PIC" > <!--l. 403--><p class="noindent" >If you haven&#8217;t set an influence point for the signal yet, the influence point formspec automatically opens. <!--l. 406--><p class="noindent" >You can assign a signal to each side of a TCB. This is, for example, useful when creating block sections on a bi-directional main running line. <!--l. 410--><p class="noindent" >Only main signals can ever be assigned to TCBs, because static ones can either not display &#8220;Danger&#8221; or do not permit to proceed at all. <!--l. 414--><p class="noindent" > <a id="x1-47r6"></a> <!--l. 414--><p class="noindent" ><span class="ecsx-1200">3.6</span> <span class="ecsx-1200">Shunt</span> <span class="ecsx-1200">routes</span> <a id="Q1-1-0"></a> <!--l. 417--><p class="noindent" ><span class="ecbx-1000">The information in this section is subject to future change because of safety issues!</span> <!--l. 419--><p class="noindent" >Operating railways is not all about driving trains around. Coupling, decoupling and moving single engines, wagons or groups of wagons across a station, called shunting, also plays an important role. <!--l. 423--><p class="noindent" >Remember what we said about routes: There must be no rail vehicles on the route. So what if you have some goods wagons ready on a siding, and want to couple an engine to it? You can not set a regular route into the siding, because it is occupied. <!--l. 428--><p class="noindent" >The solution is to program a second route into the siding, but with the difference that it already ends at the rear-facing signal of it, so it doesn&#8217;t include the siding section itself: <!--l. 432--><p class="noindent" ><img src="9_home_moritz_Home_Projekte_Minetest_minetest_mods_advtrains_assets_lyx_img_route_ex3.png" alt="PIC" > <!--l. 434--><p class="noindent" >The Sht2 route then needs to show a shunt aspect, which instructs the driver to proceed slowly and watch out for vehicles on the route. See later on for how to set this up. <!--l. 438--><p class="noindent" >Shunt routes like this are, so far, the only exception to the &#8220;Routes should end at a signal facing the same direction&#8221; rule. <!--l. 441--><p class="noindent" > <a id="x1-48r7"></a> <!--l. 441--><p class="noindent" ><span class="ecsx-1200">3.7</span> <span class="ecsx-1200">Route</span> <span class="ecsx-1200">Release</span> <a id="Q1-1-0"></a> <!--l. 443--><p class="noindent" >In early real-life interlocking systems, routes either had to be cancelled by the signalman after the train had passed the route, or there was a single release contact at the end of the route. However, as interlocking systems evolved and the position of trains is now roughly known by the track sections, portions of the route can be freed as soon as the train has left the corresponding section. <!--l. 450--><p class="noindent" >AdvTrains has chosen a modern approach to route releasing. Each turnout lock is associated to a track section belonging to the route&#8217;s path. Once the train leaves this section, all assigned locks are also freed. <!--l. 454--><p class="noindent" >Please note that reversing a train outside of stations is not only discouraged, but also very dangerous, because even real-world interlocking system do not expect this. There is a clear, human-sense rule that you should never reverse the driving direction of a train while on a main line or on a turnout. Else, you can be considered a terrorist. (quote from professional!) <!--l. 461--><p class="noindent" > <a id="x1-49r8"></a> <!--l. 461--><p class="noindent" ><span class="ecsx-1200">3.8</span> <span class="ecsx-1200">Programming</span> <span class="ecsx-1200">a</span> <span class="ecsx-1200">route</span> <a id="Q1-1-0"></a> <!--l. 463--><p class="noindent" >The route programming procedure is quite straightforward if you&#8217;ve read the previous sections and understood how routes should be set. <!--l. 466--><p class="noindent" >Routes always start at a main signal. You must have assigned the signal to a TCB, as described earlier. <!--l. 469--><p class="noindent" >When you right-click the main signal, it no longer changes its aspect. Instead, a formspec pops up, showing you an (empty) list of routes with the possibility to set them or to create new routes. Click the &#8220;Create new route&#8221; button to start programming a new route. <!--l. 474--><p class="noindent" >The form closes, and an arrow is displayed on the TCB. You are now in &#8220;Route Programming&#8221; mode, programming the first track section of the route. Now: <ul class="itemize1"> <li class="itemize">Put any turnouts you need to lock in the correct position (e.g. by right-clicking them). This includes flank protection. </li> <li class="itemize">Punch them. This makes a marker with a blue lock symbol appear. </li> <li class="itemize">If you punch a turnout again, or punch the marker, you can remove the lock again. </li> <li class="itemize">When you&#8217;ve locked all turnouts in the current section, go to and punch the TCB that is the border to the next track section the train proceeds into.</li></ul> <!--l. 487--><p class="noindent" >Depending on the situation, you are now offered some possibilities to proceed: <ul class="itemize1"> <li class="itemize">Click the &#8220;Advance to next section&#8221; button if your route consists of more sections with turnouts to lock, and you need to continue programming. Follow the above steps to set locks for the next section.</li></ul> <!--l. 494--><p class="noindent" >Once you&#8217;ve clicked the &#8220;Advance&#8221; button, the lock markers change to a red lock symbol, telling they can&#8217;t be changed anymore. Repeat the above procedure until you are ready to complete the programming procedure: <ul class="itemize1"> <li class="itemize">Click the &#8220;Finish route HERE&#8221; button when you&#8217;ve set up the locks for the last track section of the route and punched the final TCB (the one with the next signal). You will be asked for a route name and your route will be saved. </li> <li class="itemize">The &#8220;Finish route at end of NEXT section&#8221; button (third button) is an useful quickhand to make the route proceed one more section. Using this button is equivalent to first clicking the &#8220;Advance&#8221; button, then flying to the end of the next track section and finishing the route there. You can not (officially) set turnout locks in the final section using this method.</li></ul> <!--l. 510--><p class="noindent" >A few hints: <ul class="itemize1"> <li class="itemize">If you accidentally advanced the route wrongly, you can use the &#8220;Step back one section&#8221; button to undo this. </li> <li class="itemize">If you want to stop programming the entire route without saving it, use the &#8220;Cancel route programming&#8221; button. </li> <li class="itemize">The third button is especially useful for programming simple block sections on a main running line, since you can stay at the starting signal (punch starting TCB and select third button). </li> <li class="itemize">If a route should end in a dead end, you MUST use the &#8220;Finish in NEXT section&#8221; button, because there is no final TCB that you could punch. </li> <li class="itemize">The third button does NOT work on sections with more than 2 exits, because the system won&#8217;t be able to determine the final TCB of the route then.</li></ul> <!--l. 527--><p class="noindent" > <a id="x1-50r9"></a> <!--l. 527--><p class="noindent" ><span class="ecsx-1200">3.9</span> <span class="ecsx-1200">Route</span> <span class="ecsx-1200">information</span> <span class="ecsx-1200">screen</span> <a id="Q1-1-0"></a> <!--l. 529--><p class="noindent" ><img src="10_home_moritz_Home_Projekte_Minetest_minetest_____lyx_img_Bildschirmfoto_2019-01-15_19-28-09.png" alt="PIC" > <!--l. 531--><p class="noindent" >This is the screen that appears when you click &#8220;Edit Route&#8221;. It lets you change the route name and delete the route. Also, it shows a summary of the route and its elements. <!--l. 535--><p class="noindent" >The route summary lists information per track section on the route, so the line starting with &#8220;1&#8221; is the first section of the route. <!--l. 538--><p class="noindent" >The ARS rule list and its purpose is explained later. <!--l. 540--><p class="noindent" > <a id="x1-51r10"></a> <!--l. 540--><p class="noindent" ><span class="ecsx-1200">3.10</span> <span class="ecsx-1200">Specifying</span> <span class="ecsx-1200">signal</span> <span class="ecsx-1200">aspects</span> <a id="Q1-1-0"></a> <!--l. 542--><p class="noindent" >By default, newly programmed routes show an aspect that comes closest to &#8220;Proceed at maximum speed&#8221;. However, it can be desirable to change this behavior, like when the route passes a diverging turnout, the train should be signalled to drive slower, or the route is a shunt route and therefore only &#8220;Shunting allowed&#8221; should be shown. <!--l. 548--><p class="noindent" >This is the purpose of the &#8220;Change Aspect&#8221; button in the route info screen. <!--l. 551--><p class="noindent" >Signal aspects in advtrains consist of 4 sections: main (Information for train moves), dst (Distant signal information, not implemented yet), shunt (Information for shunt moves) and info (additional information, currently not in use). <ul class="itemize1"> <li class="itemize">Train may proceed as train move at maximum speed: &#8220;main: free, speed -1&#8221; </li> <li class="itemize">Train may proceed as train move at speed of 8: &#8220;main: free, speed 8&#8221; </li> <li class="itemize">Train may proceed as shunt move: &#8220;shunt: free&#8221;</li></ul> <!--l. 562--><p class="noindent" >There&#8217;s a field in the &#8220;shunt&#8221; part of signal aspects that is not displayed in the GUI, but is of potential interest to developers of signal addons: shunt.proceed_as_main. <ul class="itemize1"> <li class="itemize">A train move can always become a shunt move by passing a signal that shows &#8220;Halt for train moves, shunting permitted&#8221; </li> <li class="itemize">A shunt move can only pass a signal saying &#8220;Proceed as train move, shunting not permitted&#8221; when proceed_as_main is true.</li></ul> <!--l. 571--><p class="noindent" >The property is used by the Limit Of Shunt sign, where proceed_as_main is set to false. Shunt moves have to stop in front of it, while train moves are signalled &#8220;Proceed&#8221;. Regular main signals that show &#8220;green&#8221; have the field set to true, so that all trains can pass it. <!--l. 577--><p class="noindent" > <a id="x1-52r4"></a> <!--l. 577--><p class="noindent" ><span class="ecsx-1200">4</span> <span class="ecsx-1200">Interlocking</span> <span class="ecsx-1200">system</span> <span class="ecsx-1200">operation</span> <a id="Q1-1-0"></a> <!--l. 579--><p class="noindent" >Setting up the interlocking for a portion of a railway network requires some time, experience and planning, but once done, there&#8217;s not much to do anymore to make trains run on your, now safer, railway. This section covers some useful practices to route trains across your network. <!--l. 584--><p class="noindent" >At the moment, routes can either be set by clicking the signal or via LuaATC, or by using the &#8220;Remote Routesetting&#8221; button from the Onboard Computer. It is planned to control this via a &#8220;signal box&#8221; view based on the currently broken itrainmap. <!--l. 589--><p class="noindent" > <a id="x1-53r1"></a> <!--l. 589--><p class="noindent" ><span class="ecsx-1200">4.1</span> <span class="ecsx-1200">Train</span> <span class="ecsx-1200">Safety</span> <span class="ecsx-1200">System</span> <a id="Q1-1-0"></a> <!--l. 591--><p class="noindent" >The Train Safety System, called &#8220;LZB&#8221; in the code (from the german term Linienzugbeeinflussung, although this is a completely different system), ensures that trains obey any restrictions imposed by signals when influence points are set. This way, it is not possible to pass signals at danger or to bypass speed restrictions. <!--l. 597--><p class="noindent" >It is possible to overrun red signals, if a route is cancelled while a train is approaching. Real interlocking systems use a mechanism called Approach locking for this, however, as of now, there&#8217;s no similar system in this mod. If a red signal is overrun, the train brakes using emergency brake (&#8220;BB&#8221;) and can not be moved any further. You should then examine the situation and drive the train backwards out of the section. <!--l. 605--><p class="noindent" > <a id="x1-54r2"></a> <!--l. 605--><p class="noindent" ><span class="ecsx-1200">4.2</span> <span class="ecsx-1200">Simple</span> <span class="ecsx-1200">route</span> <span class="ecsx-1200">setting</span> <span class="ecsx-1200">and</span> <span class="ecsx-1200">cancelling</span> <a id="Q1-1-0"></a> <!--l. 607--><p class="noindent" >To set a route, simply right-click the signal, select a route and click &#8220;set route&#8221;. If there are no conflicts, the signal turns green and the train is allowed to proceed. <!--l. 611--><p class="noindent" >It may be possible that the route can not be set, because one or more other routes conflict with the current one, or a section is blocked. In this case, the signal stays red, and the conflicting item is shown in the formspec. As soon as the conflict is resolved (by cancellation or release of the conflicting route, or the section becoming free), the requested route will be set and the signal turns green. <!--l. 618--><p class="noindent" >If a route is either requested or set, it can be cancelled from the signalling formspec. This means that all turnouts and sections are released, and the signal reverts back to red. This of course only works when the train has not passed the signal yet. There is no mechanism for Approach Locking. <!--l. 624--><p class="noindent" > <a id="x1-55r3"></a> <!--l. 624--><p class="noindent" ><span class="ecsx-1200">4.3</span> <span class="ecsx-1200">Automatic</span> <span class="ecsx-1200">Working</span> <a id="Q1-1-0"></a> <!--l. 626--><p class="noindent" >Block signals on main running lines usually only have a single route to set, the one proceeding along the main line. Their purpose is only to show whether there are trains in the next section. So, it would be convenient if this only route would set itself again after a train passed. <!--l. 632--><p class="noindent" >This is what Automatic Working is for. Set a route, click &#8220;Enable Automatic Working&#8221;, and as soon as a train passes, the route is automatically re-set. <!--l. 636--><p class="noindent" >This function is nearly identical to SimSig automatic signals. It can also be useful on a line with high traffic, when there&#8217;s a low-frequented access to a siding. You&#8217;d enable automatic working for the main route and cancel it only when you need a train to go into the siding. <!--l. 641--><p class="noindent" > <a id="x1-56r4"></a> <!--l. 641--><p class="noindent" ><span class="ecsx-1200">4.4</span> <span class="ecsx-1200">Automatic</span> <span class="ecsx-1200">Route</span> <span class="ecsx-1200">Setting</span> <span class="ecsx-1200">(ARS)</span> <a id="Q1-1-0"></a> <!--l. 643--><p class="noindent" >As interlocking systems evolved, the goal always was to offload work from the human to the system, automating things. Modern interlocking systems can automatically set routes based on a pre-programmed routing table for each particular train. Since one outstanding feature of Advtrains is it&#8217;s high degree of automation, it has a similar system to automatically set routes for a train depending on certain parameters. <!--l. 650--><p class="noindent" >Every train in Advtrains has 2 internal properties that can be set through the Onboard Computer of every engine in the train, the &#8220;Line&#8221; and the &#8220;Routing Code&#8221; <ul class="itemize1"> <li class="itemize">The &#8220;Line&#8221; property is supposed to distinguish trains of multiple lines that share a track. </li> <li class="itemize">The &#8220;Routing Code&#8221; property is supposed to tell the target of a train or which route it should take to reach the target</li></ul> <!--l. 659--><p class="noindent" >Examples: <!--l. 661--><p class="noindent" ><img src="11_home_moritz_Home_Projekte_Minetest_minetest_mods_advtrains_assets_lyx_img_arslin_ex1.png" alt="PIC" > <!--l. 663--><p class="noindent" >Both lines share the section between Blackbirdshire and Parktown. To divert them again, they can save their line number in the &#8220;Line&#8221; field. <!--l. 667--><p class="noindent" ><img src="12_home_moritz_Home_Projekte_Minetest_minetest_mods_advtrains_assets_lyx_img_arslin_ex2.png" alt="PIC" > <!--l. 669--><p class="noindent" >Some trains should go to B, some to C, the direction can be set with a routing code. <!--l. 672--><p class="noindent" >One single routing code should not contain spaces. You can set multiple routing codes by just separating them with spaces in the Routing Code field. So, &#8220;Stn Ori&#8221; would be matched by ARS rules either containing &#8220;Stn&#8221; or &#8220;Ori&#8221;. This does not work for lines. <!--l. 677--><p class="noindent" > <a id="x1-57r1"></a> <!--l. 677--><p class="noindent" ><span class="ecsx-1000">4.4.1</span> <span class="ecsx-1000">Writing</span> <span class="ecsx-1000">ARS</span> <span class="ecsx-1000">Rules</span> <a id="Q1-1-0"></a> <!--l. 679--><p class="noindent" >Every route of every signal can be given a set of ARS rules. A single ARS rule can either match a line or a routing code (combinations, e.g. and&#8217;s, are not yet supported). The first rule in the first route that matches any of the properties of the train is selected, and that route is set for the train. <!--l. 685--><p class="noindent" ><img src="13_home_moritz_Home_Projekte_Minetest_minetest_mods_advtrains_assets_lyx_img_ars_ex1.png" alt="PIC" > <!--l. 687--><p class="noindent" >You can add an asterisk (&#8220;*&#8221;) to the ARS rules of one route. That route then becomes the default route. <!--l. 690--><p class="noindent" >If no explicit ARS rule matches the train, then the default route is chosen and set. If there is no default route, nothing happens and the signal remains red. <!--l. 694--><p class="noindent" > <a id="x1-58r2"></a> <!--l. 694--><p class="noindent" ><span class="ecsx-1000">4.4.2</span> <span class="ecsx-1000">Using</span> <span class="ecsx-1000">ARS</span> <a id="Q1-1-0"></a>