User Tools

Site Tools


lines:xatc

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
lines:xatc [2019/10/29 10:45]
141.76.180.151 describe lua interpreter [orwell]
lines:xatc [2019/11/04 12:36] (current)
141.76.180.151 start motivation [orwell]
Line 7: Line 7:
  
 This is a roadmap. Suggestions,​ ideas and improvements are welcome This is a roadmap. Suggestions,​ ideas and improvements are welcome
 +
 +===== Motivation =====
 +
 +At the moment, there exist two systems for controlling trains automatedly. They somewhat work hand-in-hand,​ but have individual design flaws:
 +
 +==== Simple ATC ====
 +This is the first ATC system that ever existed in advtrains, and has not changed much since then.
 +  * Commands are purely assigned to the train. The train is responsible for parsing and executing the commands.
 +   * This means that there'​s no way to determine where the command came from
 +  * The syntax relies on 1-letter command codes and simple RegEx matching. It is not extensible.
 +   * In particular, it is impossible to integrate more advanced commands like setting in/outside text or setting routes
 +   * Commands have to be one-liners
  
 ===== Constraints ===== ===== Constraints =====
Line 13: Line 25:
   * Should be easy to use for newcomers (not pure Lua)   * Should be easy to use for newcomers (not pure Lua)
   * Setups should be copyable, and there should be a way to modularize setups ("​templates"/"​functions"​)   * Setups should be copyable, and there should be a way to modularize setups ("​templates"/"​functions"​)
 +  * Commands are given out by stationary components, but are associated and functional even when the train is no longer at the commanding location (like LuaATC currently enforces). In a later stage, it should also be possible to assign xATC programs purely to trains (see H#124)
  
 The following things should be doable through xATC: The following things should be doable through xATC:
Line 70: Line 83:
 ==== Lua Interpreter Implementation details ==== ==== Lua Interpreter Implementation details ====
  
-The code written in xATC is untrusted, since it is possibly written by untrusted users. We therefore build a somewhat custom Lua interpreteras follows:+The code written in xATC is untrusted, since it is possibly written by untrusted users. We therefore build a somewhat custom Lua interpreter
 + 
 +How this code is parsed and executed is not yet decided. This is a matter of where to lay the boundary between custom parsing and Lua compiling. 
 + 
 +A first suggestion looks as follows:
   * Every line is considered an instruction or a block start/end (we won't support ; to separate multiple commands per line for now)   * Every line is considered an instruction or a block start/end (we won't support ; to separate multiple commands per line for now)
   * The global instruction structure is parsed by custom code   * The global instruction structure is parsed by custom code
Line 76: Line 93:
   * Instructions are only allowed to be in "​Assignment"​ or "​Function Call" format. It should not be possible to construct things like '​(function() evil_stuff end)()'​   * Instructions are only allowed to be in "​Assignment"​ or "​Function Call" format. It should not be possible to construct things like '​(function() evil_stuff end)()'​
  
-In order to support ​"wait()" ​callsthe code is assembled as coroutineIt yield()s: +Perhaps the exact syntax and semantics of "​wait" ​functions will be changed in this draftthis is yet unclearThere needs to be a way to continue a halted "​thread"​ from saved data, which effectively prevents us from using coroutines. The simplest way would be to abandon ​wait() ​altogether, but this violates ​the "​simplicity"​ constraint.
-  * when wait() ​with no arguments is called (it leaves a remark for the scheduler for what it waits) +
-  * at the start of each loop iteration (to prevent semi-endless loops aka 'for i=1,​1000000000 do')+
  
 A possible '​wait_for("​Event"​)'​ function could allow for quasi-procedural operation, doing things like A possible '​wait_for("​Event"​)'​ function could allow for quasi-procedural operation, doing things like
lines/xatc.txt · Last modified: 2019/11/04 12:36 by 141.76.180.151