Jump to content

Suggestion for better export.lua to allow multiple plugins


Ozone42

Recommended Posts

Currently when making a plugin via the Export.lua interface, the plugin author must save the LuaExport functions of any eventual other plugin, before calling its own LuaExports. When the plugin is done with its own work, it must call the saved LuaExport functions of the other plugin. This is something every plugin author must do if you want multiple plugins to function simultaneously. More or less exactly the same LuaExport copying code is done over and over again by every author. If some plugin author decides not to do this chaining, then other plugins will not be called and thus not function. This also means that every plugin must edit the same Export.lua file which may break it.

 

 

I suggest that Eagle Dynamics implements better support for multiple plugins, so that each plugin author does not have implement this functionality (and edit Export.lua). I think this could easily be done in a backwards compatible way:

 

  1. DCS first looks for a folder named "Saved Games\DCS\Scripts\Exports".
  2. If there is such a folder, then it traverses each subfolder in the Exports folder and looks for a file named Export.lua.
  3. If such a file exists, it will call the LuaExport functions in that file.
  4. After this is done, it continues as it does today and calls the LuaExport functions in the file "Saved Games\DCS\Scripts\Export.lua".

This way plugin author would just make their own folder and have an Export.lua file without bothering about implementing the LuaExport function chaining and editing the top Export.lua. The directory structure would be something like:

 

  • Saved Games\DCS\Scripts\
    • Export.lua
    • Exports\
      • Plugin1\
        • Export.lua

         

        [*]AnotherPlugin\

        • Export.lua

         

        [*]AndOneMorePlugin\

        • Export.lua

         

       

     

 

Where Plugin1, AnotherPlugin, AndOneMorePlugin are different plugins from potentially different authors.

 

 

What do you say Eagle Dynamics and plugin authors?

  • Like 1
Link to comment
Share on other sites

How about DCS GameGUI Hooks and dostring_in('export', 'path_to_custom_export.lua')?

I do it like

 

net.dostring_in("export", "dofile(lfs.writedir()..[[scripts\\Hooks\\dcs_stats\\StatisticsExport.lua]])");

 

from GameGui `onSimulationStart` callback.


Edited by ICS_Vortex

PC: i9-10850K ~5.2GHz / Asus Rog Strix H490 Gaming, Asus GTX1080 Rog Strix Gaming OC, HyperX Fury RGB 32Gb RAM 3200MHz, SSD 512Gb, HDD 1Tb, Windows 10 x64. 2 x Samsung Curved 32" 

VirpilControls software engineer

 

Link to comment
Share on other sites

I'm not familiar with this. I'd appreciate if you can share a pointer with more information so I can read about it.

 

Just use code below

 

   net.dostring_in("export", "dofile(lfs.writedir()..[[scripts\\Hooks\\pluginFolder\\PluginExportFile.lua]])");

 

to start Export script from GameGUI hooks script.

Hooks script API you can find in DCS API folder of the simulator.

 

Can't give you any other pointers. I found that solution somewhere in google. Can't remember where...


Edited by ICS_Vortex

PC: i9-10850K ~5.2GHz / Asus Rog Strix H490 Gaming, Asus GTX1080 Rog Strix Gaming OC, HyperX Fury RGB 32Gb RAM 3200MHz, SSD 512Gb, HDD 1Tb, Windows 10 x64. 2 x Samsung Curved 32" 

VirpilControls software engineer

 

Link to comment
Share on other sites

This is very cool and I will consider it for Helios. That way, we each only have to have a separate hook file and nobody writes Export.lua. That is certainly more polite.

 

However, it does not address the OPs question. The request was for DCS to support multiple separate LuaExportActivityNextEvent to be registered without them having to chain each other and invariably screwing up each other's event time when they do it wrong :)

 

I don't hold any hope that part will ever happen. But at least not having to edit Export.lua from our "installers" or install instructions is a nice step forward. I will check into using just a hook for Helios that registers our dofile in the next version, which is all about exports anyway.

  • Like 1
Link to comment
Share on other sites

Hooks script API you can find in DCS API folder of the simulator.

 

Can't give you any other pointers.

Thanks! The DCS API folder and the documentation in there was what I was looking for. Was it there a year ago, or did I just miss it?

 

I only had quick look now, but this seems the way to go, just like you suggest.

Ozone42: what plugin do you develop? Would love to see your code, since your request indicates you know the pain :)

A year ago I wrote a plugin for physical simulator cockpit integration. I haven't documented it yet, so I didn't want to publish it. (And probably buggy, but works for my purposes.) Shortly after, I stopped playing DCS, but now I'm back in the game. :) I'll try to get some documentation done within a week or so, and then I'll give pointers.

 

And yes, I'm well aware of the existing solutions and I tried them and had a look at them, but in the end I wanted to do it my own way. My design goals were:

 

  • It should be easy to add support for new aircraft without extensive coding. Most of the gauges (game output) and controls (input) are already described in the DCS game files in a structured machine readable format. This information is utilized as much as possible to avoid manual programming of the same information.
  • A simple to use network protocol that can easily be integrated with various client software. This is achieved by sending all data as JSON. (If a more compact data format is needed, then support for CBOR can easily be added, since JSON can be encoded as CBOR.)
  • Avoid sending more data than needed. This is achieved by allowing the client to request which parameters should be exported, at what maximum frequency and with which precision (per gauge). Data is only sent when the information changes at the requested precision. For example, the IAS is within the game a floating point number that in practice changes for each rendered frame in the game. In most cases, it is sufficient for the client software to know the IAS without decimals, for example, at the resolution of 1 km/h or 1 knot. If the IAS stays with that one km/h then an update of the IAS is not sent to the client.
  • Keep the server side implementation fairly simple. (It's currently at about 600 lines of code).


Edited by Ozone42
Link to comment
Share on other sites

  • 3 weeks later...

I'm looking at this again. So, I only need to do net.dostring_in("export", "...") if I want to make any of my plugin data available to other scripts, is that right? Otherwise I should be fine just using onSimulationStart(), onSimulationStop() and onSimulationFrame()?

 

I saw this discussion on the same topic: https://forums.eagle.ru/showthread.php?t=228270&page=89

 

Why is onSimulationFrame() not sufficient for TacView, so that LuaExportAfterNextFrame() is needed? I'm asking because it indicates that there is something that I still don't understand, or have misunderstood. Unless TacView is making information available to other Export scripts, then I might understand.

Link to comment
Share on other sites

Thanks! The DCS API folder and the documentation in there was what I was looking for. Was it there a year ago, or did I just miss it?

 

I only had quick look now, but this seems the way to go, just like you suggest.

 

A year ago I wrote a plugin for physical simulator cockpit integration. I haven't documented it yet, so I didn't want to publish it. (And probably buggy, but works for my purposes.) Shortly after, I stopped playing DCS, but now I'm back in the game. :) I'll try to get some documentation done within a week or so, and then I'll give pointers.

 

And yes, I'm well aware of the existing solutions and I tried them and had a look at them, but in the end I wanted to do it my own way. My design goals were:

 

  • It should be easy to add support for new aircraft without extensive coding. Most of the gauges (game output) and controls (input) are already described in the DCS game files in a structured machine readable format. This information is utilized as much as possible to avoid manual programming of the same information.
  • A simple to use network protocol that can easily be integrated with various client software. This is achieved by sending all data as JSON. (If a more compact data format is needed, then support for CBOR can easily be added, since JSON can be encoded as CBOR.)
  • Avoid sending more data than needed. This is achieved by allowing the client to request which parameters should be exported, at what maximum frequency and with which precision (per gauge). Data is only sent when the information changes at the requested precision. For example, the IAS is within the game a floating point number that in practice changes for each rendered frame in the game. In most cases, it is sufficient for the client software to know the IAS without decimals, for example, at the resolution of 1 km/h or 1 knot. If the IAS stays with that one km/h then an update of the IAS is not sent to the client.
  • Keep the server side implementation fairly simple. (It's currently at about 600 lines of code).

 

Sorry for the late response. For some reason I didn't get notified on this thread (must have been user error) until the next reply. Your work sounds interesting.

 

I decided not to go the route of machine-extraction of the parameters from the aircraft Lua, because there is enough difference between different aircraft (or so I was assured by the folks doing it by hand today.) Finally, I realized that DCS-BIOS (specifically the DCSFlightPanels fork) has already extracted all the parameters for all the aircraft that exist and new ones as they come out. So I didn't think I could compete with that with automation, particularly for those cases where values are really better combined from multiple arguments in a callback function written by a human and then sent as one value.

 

So what I finally did was to write Lua that executes DCS-BIOS module definitions and then captures the details of what arguments are being exported and as what type. This way, I plan to reduce the effort duplication, so we can use this data in different ways. I don't want to say too much here so I don't end up promising things that I won't ever ship, but I will reach out to you in PM to see if you want to share the data.

 

Cheers,

derammo

Link to comment
Share on other sites

I think I got everything working using the Hooks method, except that I wasn't able to figure out how to call the list_indication() function in that environment. Any ideas?

Running net.dostring_in("export", "dofile(...)") on every frame to a onSimulationFrame() is probably not very resource friendly either. I don't need to, and I'm not currently doing it, but if somebody suggests that I call list_indication() that way, then I don't think it's a solution. I tried calling something like:

[font=Courier New][font=Arial][font=Verdana][font=Courier New][font=Arial][font=Verdana][font=Courier New]net.dostring_in("export", "list_inidication(1)")[/font][/font][/font][/font][/font][/font][/font]

But wasn't able to get it to return anything. How should it done? I also tried:

[font=Courier New][font=Arial][font=Verdana][font=Courier New][font=Arial][font=Verdana][font=Courier New]net.dostring_in("export", "print(1+2)")[/font][/font][/font][/font][/font][/font][/font]

But didn't get an output.

According to the documentation:

net.dostring_in(state, string) -> string

Executes a lua-string in a given internal lua-state and returns a string result

How do I get it to return a string result? Any simple example would help.

Link to comment
Share on other sites

There are also some downsides with using the Hooks compared to Export.lua:

 

  • One has to restart DCS for it to reread the Hooks scripts, compared to restarting the mission for Export.lua.
  • It seems like there is no error output in any logs if you make a mistake in your Hooks code. For Export.lua errors, the errors are log in the dcs.log file.

These two things makes development slower. For the time being, I think I have to go on and use the Export.lua because of these issues, and because I have not been able to solve the list_inidication() thing.

 

It looks like that currently there is no ideal solution, or then I don't just know how to use the available API interfaces, and would be grateful for any help and advice.

Link to comment
Share on other sites

There are also some downsides with using the Hooks compared to Export.lua:

 

  • One has to restart DCS for it to reread the Hooks scripts, compared to restarting the mission for Export.lua.
  • It seems like there is no error output in any logs if you make a mistake in your Hooks code. For Export.lua errors, the errors are log in the dcs.log file.

These two things makes development slower. For the time being, I think I have to go on and use the Export.lua because of these issues, and because I have not been able to solve the list_inidication() thing.

 

It looks like that currently there is no ideal solution, or then I don't just know how to use the available API interfaces, and would be grateful for any help and advice.

 

 

I think I misunderstood, maybe. I though the proposed solution was to just run a script in the "export" context via the hook exactly one time, to install the normal LuaExportActivityNextEvent etc. handlers? If that isn't how this approach works, then it is suddenly a whole lot less interesting to me :). I was scheduling investigating and switching Helios to this approach in the medium time frame, but I haven't done the work yet.

Link to comment
Share on other sites

I think I misunderstood, maybe. I though the proposed solution was to just run a script in the "export" context via the hook exactly one time, to install the normal LuaExportActivityNextEvent etc. handlers? If that isn't how this approach works, then it is suddenly a whole lot less interesting to me :). I was scheduling investigating and switching Helios to this approach in the medium time frame, but I haven't done the work yet.

I think I misunderstood, and you got it right. Didn't think of that you can (propably?) install the normal LuaExport handlers that way. I haven't tried yet, but will.

Link to comment
Share on other sites

  • 3 years later...
On 2/24/2020 at 2:11 PM, derammo said:

 

 

I think I misunderstood, maybe. I though the proposed solution was to just run a script in the "export" context via the hook exactly one time, to install the normal LuaExportActivityNextEvent etc. handlers? If that isn't how this approach works, then it is suddenly a whole lot less interesting to me :). I was scheduling investigating and switching Helios to this approach in the medium time frame, but I haven't done the work yet.

I'd find myself running into this problem 2 years later.  I have two Lua files that both use the LuaExportStart()/...Stop()/...NextEvent().  Both are listed in the Export.lua file located in the Scripts folder.  Individually both files work great, but the minute I try to use both together in the Export.lua.... forget it.  One steps on the other or vise versa based on the order they are placed in the Export.lua file.

Maybe hooks is my solution?  One Lua script starts and writes to a folder that is sent off by a server using node.js and the other Lua script just writes locally and both are almost identical with the same functions use within but the file is named differently.  I cannot change the function name but maybe can have if, then conditions so they do not step on one another?

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...