Suggestion for better export.lua to allow multiple plugins - ED Forums
 


Notices

Reply
 
Thread Tools Display Modes
Old 01-26-2020, 09:46 PM   #1
Ozone42
Junior Member
 
Join Date: Dec 2018
Posts: 13
Default Suggestion for better export.lua to allow multiple plugins

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?
Ozone42 is offline   Reply With Quote
Old 01-27-2020, 03:56 PM   #2
AnarchyZG
Junior Member
 
Join Date: May 2018
Posts: 53
Default

You have my vote
__________________

Check out MATRIC and forget about keyboard shortcuts
AnarchyZG is offline   Reply With Quote
Old 01-27-2020, 06:46 PM   #3
ICS_Vortex
ED Partners
 
ICS_Vortex's Avatar
 
Join Date: Feb 2012
Location: Ukraine, Stary Sambor
Posts: 10,271
Send a message via ICQ to ICS_Vortex
Default

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

Quote:
net.dostring_in("export", "dofile(lfs.writedir()..[[Scripts\\Hooks\\dcs_stats\\StatisticsExport.lua]])");
from GameGui `onSimulationStart` callback.

Last edited by ICS_Vortex; 01-27-2020 at 06:48 PM.
ICS_Vortex is offline   Reply With Quote
Old 01-31-2020, 09:53 PM   #4
Vyrtuoz
ED Partners
 
Vyrtuoz's Avatar
 
Join Date: May 2006
Posts: 692
Default

I agree Ozone, the way export.lua is working, is definitely not reliable.

I really like your idea to fix the problem Vortex! Going to do this in Tacview 1.8.3, I am tired of corrupted export.lua
__________________
Vyrtuoz is offline   Reply With Quote
Old 02-02-2020, 12:24 PM   #5
Ozone42
Junior Member
 
Join Date: Dec 2018
Posts: 13
Default

Quote:
Originally Posted by ICS_Vortex View Post
How about DCS GameGUI Hooks and dostring_in('export', 'path_to_custom_export.lua')?
I'm not familiar with this. I'd appreciate if you can share a pointer with more information so I can read about it.
Ozone42 is offline   Reply With Quote
Old 02-02-2020, 01:19 PM   #6
ICS_Vortex
ED Partners
 
ICS_Vortex's Avatar
 
Join Date: Feb 2012
Location: Ukraine, Stary Sambor
Posts: 10,271
Send a message via ICQ to ICS_Vortex
Default

Quote:
Originally Posted by Ozone42 View Post
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

Code:
    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...
Attached Thumbnails
Click image for larger version

Name:	GameGUIExportInit.jpg
Views:	33
Size:	290.3 KB
ID:	226431  

Last edited by ICS_Vortex; 02-02-2020 at 01:33 PM.
ICS_Vortex is offline   Reply With Quote
Old 02-02-2020, 02:48 PM   #7
derammo
Member
 
Join Date: May 2013
Posts: 152
Default

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.
derammo is offline   Reply With Quote
Old 02-02-2020, 02:51 PM   #8
derammo
Member
 
Join Date: May 2013
Posts: 152
Default

Ozone42: what plugin do you develop? Would love to see your code, since your request indicates you know the pain
derammo is offline   Reply With Quote
Old 02-04-2020, 07:45 PM   #9
Ozone42
Junior Member
 
Join Date: Dec 2018
Posts: 13
Default

Quote:
Originally Posted by ICS_Vortex View Post
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.
Quote:
Originally Posted by derammo View Post
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).

Last edited by Ozone42; 02-04-2020 at 07:47 PM.
Ozone42 is offline   Reply With Quote
Old 02-21-2020, 06:22 PM   #10
Ozone42
Junior Member
 
Join Date: Dec 2018
Posts: 13
Default

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.
Ozone42 is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT. The time now is 11:35 AM. vBulletin Skin by ForumMonkeys. Powered by vBulletin®.
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.