Ozone42 Posted January 26, 2020 Share Posted January 26, 2020 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: DCS first looks for a folder named "Saved Games\DCS\Scripts\Exports". If there is such a folder, then it traverses each subfolder in the Exports folder and looks for a file named Export.lua. If such a file exists, it will call the LuaExport functions in that file. 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? 1 Link to comment Share on other sites More sharing options...
AnarchyZG Posted January 27, 2020 Share Posted January 27, 2020 You have my vote [sIGPIC][/sIGPIC] MATRIC developer Check out MATRIC and forget about keyboard shortcuts Link to comment Share on other sites More sharing options...
ICS_Vortex Posted January 27, 2020 Share Posted January 27, 2020 (edited) 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 January 27, 2020 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 More sharing options...
Vyrtuoz Posted January 31, 2020 Share Posted January 31, 2020 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 ;) Link to comment Share on other sites More sharing options...
Ozone42 Posted February 2, 2020 Author Share Posted February 2, 2020 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. Link to comment Share on other sites More sharing options...
ICS_Vortex Posted February 2, 2020 Share Posted February 2, 2020 (edited) 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 February 2, 2020 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 More sharing options...
derammo Posted February 2, 2020 Share Posted February 2, 2020 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. 1 Link to comment Share on other sites More sharing options...
derammo Posted February 2, 2020 Share Posted February 2, 2020 Ozone42: what plugin do you develop? Would love to see your code, since your request indicates you know the pain :) Link to comment Share on other sites More sharing options...
Ozone42 Posted February 4, 2020 Author Share Posted February 4, 2020 (edited) 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 February 4, 2020 by Ozone42 Link to comment Share on other sites More sharing options...
Ozone42 Posted February 21, 2020 Author Share Posted February 21, 2020 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 More sharing options...
derammo Posted February 21, 2020 Share Posted February 21, 2020 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 More sharing options...
Ozone42 Posted February 23, 2020 Author Share Posted February 23, 2020 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 More sharing options...
Ozone42 Posted February 24, 2020 Author Share Posted February 24, 2020 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 More sharing options...
derammo Posted February 24, 2020 Share Posted February 24, 2020 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 More sharing options...
Ozone42 Posted February 25, 2020 Author Share Posted February 25, 2020 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 More sharing options...
timothyboss Posted April 28, 2023 Share Posted April 28, 2023 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 More sharing options...
Recommended Posts