Trainz/Rules

Driver Commands

 * See also: Notation's, and glossary's & main topics: Driver Commands and Session Editor.
 * A Driver command is a rule class likely first seen in a Driver session encapsulated in a little graphic rectangle with icons representing (fronting for) a re-entrant scriptlet in Trainz extensible GameScript language. Most AI-Driver Commands are simple and easy to follow. Go to this or that trackmark, navigate to such and such a business, load or unload there, and wait for some event, and similar taskings. We hope to cover these in some depth in Driver Commands, but mention them here so that the new Trainzer can realize they are much the same technology as the Session Rules that appear elsewhere in a session's program flow. The biggest difference is the Driver Commands are enqueued, meaning their execution is linear&mdash;the first rule must execute before the next has a shot at being in control; that must finish before the third gets up to bat. Being 'on deck', like in baseball, means you can't affect the gameplay yet. One must come up to bat for your chance!

Rules overview
Many Session Rules (formally), differ most from the smaller list of 'Driver commands' by taking inputs or instructions (including dynamically defined runtime assessed values) so they can interact with the Trainz World's (Map+Session created) virtual reality. They provide or use built-in software 'hooks' (variables and re-entrant calls to services)allowing dynamic operations and interactive behavior in a session. A rule which tests a condition is a 'gate keeper' &mdash; a block requiring a trigger, or TRUE Condition to be satisfied before any rule indented (under (after) it cannot take control until the trigger reports a True situation, allowing conditional flow then and only then to the rules under the trigger rule.

Behind the scenes, the framework, tasks, testings, and scoring are handled by interactive rules defined by the session writer CC. A list of useable 'Driver Commands' is defined early [these enable the Driver Command Rules a human can give to the AI Drivers in the scenario, or constrain choices to a specific few], in the 'initialization parts' of a session, so will vary when driving different sessions.
 * (Other initialization examples: Time session begins [night, day, hour], weather and variability, derailment [easy to realistic] and driver mode specification [User's choice, or fixed CAB mode or DCC emulation]
 * Various rules represent program flow controls, status reporting and testing components, and display outputs to the CC writing a session. There are well over 1,000 rules of various kinds on the DLS. Fire up Content Manager and take a look yourself.
 * To the session writer, the s are building blocks and possess 'hooks' that allow dynamic digital interfacing with the virtual world's map elements. Session Rules often allow definition and value initialization of other parameters hooked into run-time software.  To a rule writer CC, a rule is a stand-alone asset, written to fulfill a general need or allow a certain sort of task dynamically within the gameplay of a session. These often operate more effectively with specific assets made by the CC or one of his associates. They can be sorted by category in CM.


 * The scriptlets may be thought of as a subprogram, which in each can take various definitions or associations which the session runtime software needs. These code defined hooks are needed to associate a route or consist element to a Test of a state, or track values such as scoring in dynamic gameplay. The inclusion of Rules and their parameters is specified when a Driver Session is created in Surveyor, and in it's session editor API.Driver Command rules are commands placed in a 's command queue (list) that are executed in that order.


 * Rule editing
 * Many Rules open an entry applet when 'edited' (Programmed, defined, initialized, or specified would be more accurate, but 'edit' is the button's label) after added to or when encountered in a Session sequence. The editing of a Rule is the session designer/editor CC's way to define parameters to pass into the runtime interface in the Driver GUI Module, possibly to directly change of some element (e.g. junctions, signals states) in a &mdash;or get from the map rendering game software by the setting up of an association a  ''for a software state-check, or to keep a counter style score.


 * See also:,.