export.lua mess hard to maintain

[bumblebomb]

With several 3rd party programs hooking into DCS I constantly run into trouble after updates.

TacView overwrites it, Vaicom messes with it, SRS gets kicked by other programs' shenanigans ever so often.

 

How about a startup parser that loops over seperate files like:

 

 

vaicom.export.lua

srs.export.lua

rsmapper.export.lua

...

 

so they don't interfere?

[c0ff]

This is already implemented with the hook scripts.

The documentation is in API\DCS_ControlAPI.html

[c0ff]

I guess, in order for people to use the new API, we have to drop the support for the old ways

[bumblebomb]

Please. It's like herding dwarves.

[Ciribob]

This is already implemented with the hook scripts.

The documentation is in API\DCS_ControlAPI.html

 

Can you give some more details?

 

SRS uses both Hooks GameGUI and Export.lua

 

With export.lua everyone that hooks has to a good citizen - but not all scripts are

 

For example SRS export.lua line is just

 

pcall(function() local dcsSr=require('lfs');dofile(dcsSr.writedir()..[[Mods\Services\DCS-SRS\Scripts\DCS-SimpleRadioStandalone.lua]]); end,nil);

To try to catch any loading errors

 

In the file itself the two functions are:

 

-- Prev Export functions from other hooks
local _prevExport = {}
_prevExport.LuaExportActivityNextEvent = LuaExportActivityNextEvent
_prevExport.LuaExportBeforeNextFrame = LuaExportBeforeNextFrame

LuaExportActivityNextEvent = function(tCurrent)
   local tNext = tCurrent + 0.1 
   

   local _status, _result = pcall(function()

       -- SOME CODE
   end)

   if not _status then
       SR.log('ERROR: ' .. _result)
   end


   local _status, _result = pcall(function()
       -- Call original function if it exists / other hooks before me
       if _prevExport.LuaExportActivityNextEvent then
           _prevExport.LuaExportActivityNextEvent(tCurrent)
       end

   end)

   if not _status then
       SR.log('ERROR Calling other LuaExportActivityNextEvent from another script: ' .. _result)
   end


   return tNext
end


LuaExportBeforeNextFrame = function()

   -- read from socket
   local _status, _result = pcall(function()

            --- SOME CODE
   end)

   if not _status then
       SR.log('ERROR LuaExportBeforeNextFrame SRS: ' .. _result)
   end

   -- call original
   _status, _result = pcall(function()
       -- Call original function if it exists
       if _prevExport.LuaExportBeforeNextFrame then
           _prevExport.LuaExportBeforeNextFrame()
       end
   end)

   if not _status then
       SR.log('ERROR Calling other LuaExportBeforeNextFrame from another script: ' .. _result)
   end

end

 

Saving any existing LuaExportBeforeNextFrame and then calling my version, then passing back up the chain so all the other scripts hanging off work

 

The issue is others dont always properly handle errors on their end - causing all the scripts in the chain to break.

 

Could Export.lua be done in the same way as GameGUI where you have multiple gamegui luas?

 

Is that already in place and if so, how do we name the file?

[c0ff]

Could Export.lua be done in the same way as GameGUI where you have multiple gamegui luas?

 

Is that already in place and if so, how do we name the file?

 

Hooks have almost all Export API calls available to them. If you miss any functionality, please tell.

[Ciribob]

Hooks have almost all Export API calls available to them. If you miss any functionality, please tell.

 

That I didnt know... Thank you!

 

Calls in Export I currently use are:

 

 

• Loading Terrain using local terrain = require('terrain') and a load of other imports to get terrain to load. Needed for terrain.isVisible call for Line of Sight calculations
  
• LoGetSelfData()
  
• LoGetPlayerPlaneId()
  
• LoGetCameraPosition()
  
• LoLoCoordinatesToGeoCoordinates(point)
  
• GetDevice with get_argument_value & get_frequency() & get_modulation()
  
• list_indication(indicator_id)
  

 

Are these all available? If so I'll move all that over to the Hook and stop using the export.lua entirely

 

Not sure TacView or any other author knows that they can exclusively use the Hooks environment and ignore the export one

 

Thank you!

[c0ff]

Are these all available? If so I'll move all that over to the Hook and stop using the export.lua entirely

 

They should be. I've just checked the code and Export.* contains all the API available in Export.lua, except for a couple of deprecated functions (which you definitely do not use).

[c0ff]

Yep, the list of functions in API/DCS_ControlAPI.html#export-api needs an update, but the actual list is the same as in Export.lua by design.

[Ciribob]

Yep, the list of functions in API/DCS_ControlAPI.html#export-api needs an update, but the actual list is the same as in Export.lua by design.

Thank you! This made my week :)

 

Sent from my HD1903 using Tapatalk

[Ciribob]

Hooks have almost all Export API calls available to them. If you miss any functionality, please tell.

 

Ok sorry one is missing - or I'm misunderstanding how to use it

 

In the Export.lua there is

 

list_indication

 

I use this to to read the UFC in the hornet to work out the state of MIDS and Guard on a radio (same in Harrier and F16). This is also used extensively by DCS-BIOS for Home cockpits

 

in the GameGUI environment I found an undocumented call

 

Export.GetIndicator()

 

Which returns something with the same parameters as list_indication - for example for the Hornet list_indication(6) is the upfront UFC

 

I cant figure out what methods it has in order to read the value of the indicator

 

Any pointers?

 

Edit: the returned object has 3 methods - but none of which seem to return any data. As such list_indication is still needed from the Export.lua environment.

 

Is there any chance this could be added as Export.list_indication in the newer GameGUI environment? This would allow DCS-BIOS, SRS and others to migrate fully to GameGUI (i think)

Edited September 13, 2020 by Ciribob

[Ciribob]

One last bump @c0ff :)

 

If list_indicators is added, DCS-BIOS (or any cockpit integration) plus SRS can be gone using GameGUI / hooks and migrate away from Export.lua

 

Understood this is not a priority in any way though!

 

Sent from my HD1903 using Tapatalk

[Bailey]

I know that other games export all that data to a central location so that devs/moders can cherry pick the data they need instead of messing with an export.lua to "ask" for the stuff they need, possible interrupting other necessary or critical game functions. Moving away form the export.lua method would be awesome for established and new devs.

[Blackfyre]

@c0ff, any updates on `list_indication` function? It is available in Export environment and isn't in Hook and it is a major missing feature of the hooks. 

[jmossr]

You can access list_indication from within Hook like this:

local function executeLuaIn(env, lua)
    local ret, success = dostring_in(env, lua)
    if success then
        return ret or success, nil
    else
        return nil, ret
    end
end

local indication, error = executeLuaIn('export', 'return list_indication(0)')

[Ciribob]

You can access list_indication from within Hook like this:
local function executeLuaIn(env, lua)
    local ret, success = dostring_in(env, lua)
    if success then
        return ret or success, nil
    else
        return nil, ret
    end
end
local indication, error = executeLuaIn('export', 'return list_indication(0)')

Try it when you're in multiplayer but not the host and pretty sure it doesn't work then from my last test

It will work in single player or multiplayer if you're the host.

Sent from my Pixel 7 Pro using Tapatalk