Standard module slots

  • In this article all LOTUS-wide standard module slots informations are listed.

    General concerning PIS

    Thanks to the broadcast system it is always possible that self-created on-board computers and self-created displays transmit more data than those listed here! In this way a more complex FIS can of course be set up on the existing vehicles.


    However, the broadcast transmissions and receptions listed here are those which must be used if newly developed modules are to be compatible with the standard content modules.

    1 Outside displays

    A distinction is always made between master displays, which contain all script logic and write commands, and slave displays, which do not contain any internal logic, but only receive the texture index from the master matrix, so that they use the same texture as the master display (and thus display the same). The advantage here is that only one single texture is generated, which is then shared by all ads.

    1.1 Geometry

    The displays are flat and aligned to the center of the actual matrix. They are aligned like the front matrix. The important thing is that they are a bit too wide and a bit too high for the display box of the GT6N, so that there are no gaps and they can be used on other cars.

    • Front display on the bus: TERMINUSDISPLAY_LARGE (no slave provided)


    • Front display for GT6N (as master) and side displays for bus and GT6N (each as slave): TERMINUSDISPLAY and TERMINUSDISPLAY_SLAVE

    Attention: We changed the height of the top edge!


    • Line display for GT6N and bus (slave only): LINEDISPLAY_SLAVE

    Attention: We changed the height of the top edge!



    (the Z-coordinates of the line display are identical to those of the side display)

    • Narrow display for line and destination, e.g. for busses, which also display the destination at the rear (slave only): TERMINUSDIRPLAY_SLAVE_NARROW

    Attention: We changed the width of the actual display section.



    (the Z-coordinates of the narrow display are identical to those of the page display)

    • Pure destination display, e.g. for buses with split side displays (slave only): TERMINUSONLYDISPLAY_SLAVE


    The dimensions are identical to those of the page display, except of course for the width of the display itself - this results from the scaling and height of the pure target display.

    1.2 Script communication (Master)

    The following commands are received via broadcast under the BusID "PIS":

    • LINE (integer): Receives as value the line number (without any course or special character information!). There will be an immediate conversion into a string considering the current special character code based on the PIS group and then the display will be updated.
    • TERMINUS_LISTINDEX (integer): Receives the index as a Value (not the code!) of the just selected destination stop. The corresponding strings are taken from the FIS group and the display is immediately updated based on these strings.
    • SPECIALCHAR (integer): Receives as Value the special character code. The display is not updated.

    The following command is received via broadcast under the bus ID "GEN":

    • LIGHT (single): The brightness of the display illumination is received as a value and written to the appropriate variable.
    • MAINSWITCH (integer): An on/off command (1 or 0) is received as a value and switches the display on or off. This command is usually only processed by LED or LCD displays, which can "switch off" accordingly. Of course, pure roll tape, flipdot or drop sheet displays do not need this command.

    The following command is received directly from the vehicle:

    • INITSTRING (string): The string to be written to the display if nothing else is to be written (e.g. reset IBIS to 0).

    1.3 Script communication (Slave)

    The only commands that the slave displays receive directly are the LIGHT and the MAINSWITCH broadcast. Otherwise there are "internal" broadcasts between the displays, but these do not need to be standardized. Here, only the displays have to be coordinated with each other.

    2 Inside displays

    For the indoor displays, the same master-slave system is used as for the outdoor displays. The module class for the masters is STOPDISPLAY_MASTER, that of the slaves STOPDISPLAY_SLAVE.

    2.1 Geometry

    The interior display shown is that of the GT6N. However, the DL will get other interior displays, but their specifications will be the same.


    2.2 Script communication

    Important: At the moment the displays still receive the hold request via broadcast. But this will have to be changed, so that different stop request states can be displayed in different areas! For this reason the stop request specification is not listed here yet.


    The following commands are received by broadcast via the BusID "PIS":

    • STOP_SEQ (integer): The "position" of the current stop in the stop list of the currently set route ("what number stops is it")
    • ROUTE_LISTINDEX (integer): The index of the set route
    • TERMINUS_LISTINDEX (integer): The index of the set target
    • LINE (integer): The set line
    • DOORSOPEN (integer): A 1 is received when door release is given

    3 IBIS / Bordcomputer GT6N

    The module class for the GT6N on-board computer is IBIS_GT6N.

    3.1 Geometry

    The size and orientation of the IBIS can be seen in the following graphic; the Z-axis points in the direction of the observer, the IBIS lies "on the ground" so to speak:


    3.2 Script communication

    IBIS sends the requests to indoor and outdoor displays via broadcasts, which are distributed under the BusID "PIS":

    • LINE (integer): Sends as value the line number (without any course or special character information!) which is to be displayed on the displays. The update of the displays is hereby requested.
    • TERMINUS_LISTINDEX (integer): Sends as Value the index (not the code!) of the just selected destination stop to be displayed on the displays. The update of the displays is hereby requested.
    • SPECIALCHAR (integer): Sends as Value the special character code. The conversion of this code into a special character string is done in the matrix. The matrix update is not requested! Only one of the upper messages triggers the display update.
    • ROUTE_LISTINDEX (integer): Index of the currently set route, especially for the interior displays
    • STOP_SEQ (integer): Sends the information which stop is to be displayed, whereby the number of stops along the current route is transmitted.

    Also via broadcast, the IBIS sends the commands for the acoustic announcements, which are executed by the vehicle main script, also via the BusID "PIS":

    • ANNOUNCE_USERID and ANNOUNCE_SUBID (both integer): First the UserID of the Sound ContentID must be transmitted, then the SubID. As soon as the SubID has been transferred, the announcement must start.

    If a crossover is to be set, the device sends the following command via direct transmission:

    • SWITCH (integer): The direction is coded as follows: 0 = left, 1 = right, 2 = straight ahead

    The following commands are sent via an explicit message from the vehicle to the device (no broadcast!):

    • MAINSWITCH (integer): Value = 0 switches the device off, Value = 1 switches it on.
    • VELOCITY (single): How fast does the vehicle roll/move (m/s) ? Negative values must be provided for reverse.
    • ATBUSSTOP (integer): Is the vehicle at a bus stop, e.g. determined by the door release? 0 = no, 1 = yes.

    If different systems of ECUs/displays are to be installed, additional broadcast commands can be inserted without any problems; due to the broadcast characteristics, these do not have to be compatible with or considered by the GT6N main script.

    4 Input device and ticket printer at busses

    The module class for the ND313 on-board computer is ITCS_TERMINAL.

    4.1 Geometry

    The origin of the device must be placed in the center. The alignment is shown in the following graphic:


    4.2 Script communication

    The script communication is the same as with the GT6N ECU (except for the switch commands, of course ;-) )

    5 Motor

    Especially for vehicles with combustion engine (road vehicle or diesel locomotive or railcar) the engine with its sound is moved to a separate module, so that one has the possibility to install an alternative engine (different horsepower, different behaviour and/or different sound) without any problems. The module system will probably not be used with electric motors, because here the control plays a much bigger role, both in power and sound. Here, vehicle constants are more likely to be used.


    The module class for a classic engine is ENGINE_PISTON (i.e. piston engine, i.e. gasoline or diesel engine). In any case, the class ENGINE_ELECTRIC is defined for electric motors and the class ENGINE_TURBINE for gas turbines.

    5.1 Geometry

    The geometry is completely irrelevant, since this is not about any kind of representation! If you want to realize a motor flap that can be opened, the mesh placed behind it must be supplied by the bus itself! Usually you use a very small cube on the side of the motor module and place the module slot somewhere on the side of the bus so that it is not visible, but the sound can still be heard from the right direction.

    5.2 Script communication

    All communication is done without broadcasts and always takes place via the vehicle itself. There is no direct communication between engine and transmission:

    • Once during the first SimStep run, the engine sends the moment of inertia with INV_J (single) so that the powertrain can expect this in its behavior.
    • Permanently the motor sends with M (single in Newtonmeters) the actual torque it can deliver (which is calculated by accelerator pedal position, engine speed etc.)
    • Permanently the engine receives with THROTTLE (single, from 0 to 1) the actual throttle position (but what really reaches the engine, including the intervention of ASR etc.)
    • Permanently the engine receives with RPM (single, in rotations per second) the current speed, which is given by the drive train at the engine flange
    • Permanently the engine receives with STARTERSHUFF (integer) the position of starter and engine stop: 1 = starter should be active, -1 = engine stop should be active, 0 = nothing

    6 Gearbox

    The gear box module controls how the power is applied to the wheels and how fast the engine rotates, depending on the converter, clutch and gear engaged. The module class is GEARBOX, whether it is a manual or automatic transmission.

    6.1 Geometry

    Here it is the same as with the motor: The position must be correct so that the sound can be heard from the right direction, but the mesh must be hidden and chosen accordingly small.

    6.2 Script communication

    The transmission also works without broadcasts and communication is always routed via the vehicle itself:

    • With MODE (integer), the transmission continuously transmits the current mode (-1 = R, 0 = N, 1 = 1, 2 = 1+2, 3 = 1+2+3, 4 = D), i.e. the mode in which the transmission is actually in. For example, there is a latency between pressing the gear selector button and changing the mode in the transmission. Or the transmission does not switch to mode D at all (even if the gear selector button is pressed) when the engine is not running.
    • The transmission sends a permanent message with GEAR_CURRENT (integer) to indicate which gear is actually engaged. (-1 = reverse, 0 = idle, 1 = 1st gear, 2 = 2nd gear, etc.)
    • Permanently the gearbox sends with RPM_INPUT (single, revolutions per minute) the number of revolutions which the gearbox input has, i.e. the shaft towards the engine. This is the value, which is transmitted from the vehicle to the engine.
    • The transmission sends permanently with M_OUTPUT (single, Newtonmeter) which torque is generated at the transmission output. This value has to be converted by the vehicle according to the installed differential (where usually another gear ratio is installed) and the wheel diameter to calculate the force of the wheels with which they should drive the bus.
    • The transmission receives with MODE (integer) which mode should be set. The value is coded like the transmission information of the same name (see above).
    • With RETARDER (integer), the gear unit receives which retarder stage is to be activated.
    • With INV_J_INPUT (single) the gear unit receives the inertia of the motor (plus any additional components)
    • The gear unit receives with RPM_OUTPUT (single, revolutions per minute), which speed the gear unit output should have. Since the gear output is permanently connected to the differential and wheels, the vehicle script has to convert the speed of the wheels via the wheel diameter and the differential ratio to the gear. This information then reaches the gearbox.
    • The transmission receives the torque delivered by the engine with M_INPUT (single, Newtonmeter)
    • The transmission receives with THROTTLE (single, 0...1) the position of the accelerator pedal, because the shift points depend on it.

    7 Ticket validator

    Those who wish can also configure their validators in a modular way. Please observe the following conventions:

    • class: TICKETSTAMPER
    • Geometry: Slit in the direction of the positive Y-axis, center "bottom back":


    ATTENTION: Our vehicles have no modular validators so far.