Plugin dll

  • The Plugin-DLL contains the actual executable code of the plugin.

    For the communication with LOTUS, defined methods must be exported as required. The following section therefore explains exactly how variable access takes place and which methods are to be exported. In principle, however, there is great freedom when creating the DLL; for example, it is possible to display and use an additional window with VCL components.


    Since - apart from the "AOwner" - the use of objects/classes was waived, it is probably possible to develop the Plugin-DLL in another programming language than Object Pascal. But I only tested Object Pascal (Delphi). Accordingly, the following example is written in this programming language.


    But which methods have to be declared and exported in which concrete way to take over different communication tasks is explained with the following example. ATTENTION: The section "exports" is case sensitive!


    1 Initialization and finalization

    After loading the DLL, "PluginStart" is called. In this case a form is to be created; for this purpose the procedure offers the AOwner as parameter.


    Before unloading the DLL when closing LOTUS, "PluginFinalize" is called. In this example, the form is deleted from memory.


    Immediately after a vehicle is brought into focus - i.e. after the simulation has started, after a vehicle has been repositioned or when changing to another vehicle - and thus the DLL is to dock to the newly selected vehicle, the procedure "OnConnectingVehicle" is executed. This procedure passes as parameter the name of the newly selected vehicle. In this example, the name of the vehicle is written as title on the form.


    Before a vehicle is to be taken out of focus (also when changing, deleting or returning to the main menu), "OnUnconnectingVehicle" is executed.

    2 Read access

    The read access is done with the procedures "ReceiveVarBool", "ReceiveVarInt", "ReceiveVarFloat" and "ReceiveVarString". The first parameter is always "varindex: word", the second is "value: boolean", "integer", "single" or "shortstring", depending on the procedure.


    The procedure is as follows: LOTUS runs through the respective variable list in the plugin ini and calls the corresponding "ReceiveVar..." procedure and passes it the index of the variable in the *.ini list and the current value. Normally, a case construct is then used in the procedure to process the values of the variables differently.


    In the example, the procedure "ReceiveVarFloat" makes sure that the value of the variable, which is entered in the plugin ini in the [ReadingVarsFloat] section under "var.0", is written into the Label2 of the form and the Gauge1 is deflected accordingly.

    3 Write access

    Write access is done by triggering keyboard/gamecontroller events (thus simulating the pressure of key combinations or joystick buttons) and by triggering float events to which the new float value is attached (thus simulating the processing of joystick axes).


    In other words, the plugin interface works like a freely configurable and arbitrarily complex game controller. The event names are the same as for the configuration of keyboard and game controller.


    For the events there are the two functions "SetButton" and "SetFloat". Both pass the index (from the plugin ini) as parameter. The function can then return the desired value depending on the index. For this purpose a case construct is usually used. In this example in "SetButton" the first keyboard event in the list in the *.ini file is controlled by the variable "Form1.button1_pressed". In addition, the first float event in the list in the *.ini file in "SetFloat" is set according to the position of the "TrackBar1" controller.