Receipe: Move a rails vehicle - minimum script

  • In this article you will learn what your newly imported rail vehicle must be able to do at least in order to move across a map.

    The prerequisite for this script is that you have defined two bogies with two axles each for your vehicle. You can find out how to do this here.


    The complete script, ready for import, is attached to this article. Just use it!


    In the following, we will go through the individual sections to hopefully provide lasting understanding.


    According to this article about the basics of our script system, the first section is for the declaration of variables and buttons. LOTUS relies on the vehicle having the numbers of bogies and axles defined here. Here it is explained how exactly the two types of variables work and what range of values they support. The first digit basically marks the index of the bogie, the second digit that of the axle of the bogie, both 0-based.


    So we have the traction force and the braking force - respectively for the bogies with index 0 and 1 at their respective axles with index 0 and 1.


    Furthermore, the standardised buttons with which the vehicle can be addressed were taken from this article. For our project, the buttons for accelerator, brake and emergency brake are sufficient.


    Code
    1. var
    2. _throttle: boolean;
    3. _brake: boolean;
    4. _maxbrake: boolean;

    This is followed by the area of the local variables, i.e. those that are valid for the following script. These variables do not follow any LOTUS-wide conventions, but perhaps the conventions for low-maintenance code or whatever religion you follow. I have added an underscore here to visually distinguish these variable names from the public buttons. The underscore is not conventional!


    We need these three variables of type boolean (a variable that can take the states TRUE and FALSE) to perform script-wide actions that depend on these three state variables.


    With the declaration at this point, the variables are known to the entire script, but not beyond. It is not possible to use them, for example, in the vehicle configuration (to control textures, meshes or animations with them).


    A procedure with this name is always called by LOTUS itself, namely once per frame. The exact functioning of this procedure is explained here. Roughly speaking, processing should take place in this procedure. Procedures are initiated and carried out here.


    Here, too, a variable declaration is found in the first place. Variables declared here can only be used for the associated procedure, not beyond it. Here we use certain conditions to determine which forces act on the mentioned bogie axles. Since this is supposed to be a very simple script, the acting forces are simply dependent on the state of the variables declared in the previous step. For the traction force throttleforce 40000 (Newton) in case of _throttle, i.e. when accelerating, -40000 when braking _brake or 0 if nothing like that happens. The traction force is positive in the normal direction and negative in the opposite direction, just when braking and reversing.


    In case of emergency braking _maxbrake, the braking force brakeforce is used. Don't get confused now: The braking force basically already acts in the opposite direction of the traction force, so it does NOT have to be negative, it can only be positive!


    Then the forces determined in this way are assigned to the public variables expected by LOTUS. Since we have two forces on two bogies with two axles each, we have to assign a total of 8 variables: The traction force for all four axles and the braking force for all four axles.


    LOTUS will internally, after completing this procedure, process the described variables and draw the necessary conclusions for the physics engine, such as forward motion, backward motion or stopping, rolling, etc.


    A procedure with this name and these parameters is also called automatically by LOTUS. The parameters, i.e. variables and constants, which are filled when the procedure is called, can only be used within this procedure. In addition, further variables could be declared that are only used within the procedure. However, this is not necessary and not the case here.


    As you can easily see, LOTUS sends the identifier for the key pressed by the player under the parameter id. These were previously declared almost at the top of the script under the PUBLIC_BUTTONS. Now, when this procedure is called, it queries which of the three buttons was pressed or released. If they were pressed, the parameter value is set to true, i.e. TRUE, if the button was released, it is set to false. For vehicles with more than one driver's station, the index of the cockpit from which the command was sent is also passed - but this is irrelevant for our minimal script.


    At this point we now control the state of the variables declared script-wide above. We want these variables to reflect the state of whether the player is pressing or releasing a key. Therefore, the variables declared script-wide above simply assume the state that the player specifies by pressing or releasing a key.


    This closes the circle to the previous section on Simstep, where the state of the variables _brake, _throttle and _emergency brake are queried and translated accordingly into the traction force and braking force and written to the axles.


    Code
    1. end.

    Even the most beautiful script must come to an end. And that is what it does here at this point after the work is done with the little word end..