net.dostring_in scripting environment

[xcom]

Does anyone know if using net.dostring_in() for scripting environment is available?

i.e

str, err = net.dostring_in("script", <lua code>)

 

or if there's a way to get data out of the scripting engine with minimal performance hit, other then using io and loadfile, or working with UDP/TCP sockets.

 

I know SPEED added this to an old wish list but not sure if anything was done with it, API documentation does not include any further information.

 

Thanks,

Xcom

[Grimes]

From DCS_ControlAPI.txt in your DCS install/API folder.

 

net.dostring_in(state, string) -> string
  Executes a lua-string in a given internal lua-state and returns a string result
  Valid state names are:
      'config': the state in which $INSTALL_DIR/Config/main.cfg is executed, as well as $WRITE_DIR/Config/autoexec.cfg
                used for configuration settings
      'mission': holds current mission
      'export': runs $WRITE_DIR/Scripts/Export.lua and the relevant export API

 

 

Mission is the mission scripting environment. Or were you asking if such a function existed solely within the mission environment and not elsewhere like net?

[xcom]

AFAIK, mission is for the mission environment and it can accept maybe some functions from the scripting environment, but it does not hold the scripting environment variables.

I want to get data back from the scripting environment to other environments, for example tables, strings etc...

[FSFIan]

What exactly is the "scripting" environment? Which files are being executed in its scope?

I was only aware of net, mission, config and export.

 

If you can define a function in the scripting environment and make it accessible from the mission environment, you might be able to use something like net.dostring_in("mission", "my_scripting_env_function(\"param 1\", \"param 2\")").

[xcom]

There is no "my_scripting_env_function" that I can run, it only works on the scripting engine functions AFAIK such as - trigger.misc.getUserFlag etc..

 

more info -

http://forums.eagle.ru/showthread.php?t=78058

 

Hope I got this wrong and It's possible.

 

Thanks for the assistance.

[FSFIan]

The environment that is used by net.dostring_in("mission", ...) seems to be the one where the Lua snippets from the mission file (i.e. the things that the Mission Editor autogenerates for trigger actions) are executed.

 

I have not found any way to use net.dostring_in to get data out of the mission scripting environment, other than reading and writing user flags the way Ciribob does it in the thread you linked to. You can get string data into the mission scripting environment with dostring_in("mission", [[a_do_script('some_var="mystring"')]]), but the only way to get string data out of it while avoiding file and network I/O would be to spawn a new group with a specific missionId and then use DCS.getUnitProperty(missionId, DCS.UNIT_GROUPNAME) to retrieve the group name, and I am pretty sure that would have a very significant performance impact.

Edited May 10, 2016 by [FSF]Ian

[xcom]

Thanks for the clarification, will this be added at any point?

I know it was requested by SPEED since 2011.

 

Also, Ciribob is not included in the thread I linked to, maybe you mixed it with another link.

[Actium]

On 5/10/2016 at 3:33 AM, FSFIan said:

You can get string data into the mission scripting environment with dostring_in("mission", [[a_do_script('some_var="mystring"')]]), but the only way to get string data out of it while avoiding file and network I/O would be to spawn a new group [...]

  As of DCS 2.9.13, a_do_script() finally has return value pass-thru:

Quote

Scripting API. Added possibility to pass args and return values from mission scripting a_do_script() and a_do_file() APIs.

Example code for the control/hooks environment that fetches a string value from the mission scripting environment:

return net.dostring_in("mission", [=[
    return a_do_script([[
        return "42"
    ]])
]=])

P.S.: Sorry for necro-posting. As these forum posts are DCS' scripting "documentation", it appeared appropriate to update said docs.

Edited Wednesday at 09:51 AM by Actium