Changes to the behaviour of net.dostring_in()

[boomer92688]

I have no problem with the changes in terms of security for the general DCS user.  I have a HUGE problem with this being just dropped on all of us who run or help manage servers with no notice.  This should have been a preview build weeks (preferably months) in advance for us to be able to make changes and be ready for.  Instead we're stuck with our players going "why isn't the server updated" and we have to tell them "ED broke stuff again, we will get to it when we can."  

[Wing]

Would’ve been great to know about these changes that would effect our servers ahead of time… our Group flight night was a fail tonight due to this new “safeguard”. 

[nooneyouknow]

17 hours ago, Special K said:

 I agree that this is not great but it is how it is now.

 

Translation : "Too bad, so sad, sucks to be you."

[MnMailman]

51 minutes ago, nooneyouknow said:

Translation : "Too bad, so sad, sucks to be you."

"Thank you for your passion and support"  

[Dangerzone]

9 hours ago, boomer92688 said:

I have no problem with the changes in terms of security for the general DCS user.  I have a HUGE problem with this being just dropped on all of us who run or help manage servers with no notice.  This should have been a preview build weeks (preferably months) in advance for us to be able to make changes and be ready for.  Instead we're stuck with our players going "why isn't the server updated" and we have to tell them "ED broke stuff again, we will get to it when we can."  

I've previously suggested what I believe is a better solution: a true Open Beta—(implemented differently to before). Make it accessible only via command line, so only those with the tech knowledge of how to execute command lines, and also know the OB version number can install it. That way, it’s not used on production servers, and Open Beta versions don’t appear in the public server list—IP connect only. This would make it a genuine testing platform, not a general gameplay environment, and give us the time we need to adapt and see the upcoming changes and try them out. Sure - there will be some that push and opt to use it as a stable release, but it would be the minority. The previous OB didn't work because the majority used it as a stable release (and even ED recommended people use it for production in MP). 

I really feel we need a proper Open Beta for everyone’s sake. Far too many issues are being discovered in these new so called stable releases within hours, forcing hotfixes. That’s bad for both ED developers, who get blindsided and must scramble to patch, and for us, who have to react to breaking changes without warning. Let alone the image that it's putting out there of ED's quality. Let an Open Beta run for a couple of weeks—(1) to give content creators time to adapt, and (2) to apply necessary hotfixes—before pushing a public stable.

Just a pity that ED seems to disagree that there's issues for the community by working this way and believe everything is fine as is. Nothing needs changing, with "no plans to consider...". While all along I see what I feared when open beta disappeared. That the new and improved stable release would eventually degenerate to being what Open Beta was all along - with no real practical alternatives for public server content creators (that aren't in the CB team anyway) to be proactive, and just have to be reactive and rush about to deal with bugs, problems, or breaking changes at the last minute. 

[okopanja]

12 hours ago, cfrag said:

Won't run on a fresh, secure DCS install. It did so until yesterday.

OK, understood.

[PeeJott17]

@Special K Do you happen to know what needs to go into the autoexec.cfg to get the slot-blocker-script to run normally? The cfg-lines you provided fixed the progression-save-script but not the slot-blocker. I know, I'm disturbing your holiday, but if you happen to find the time between sunbathing and lunch, may-be you could just punch-in a few characters via your phone

Cheers,

PeeJott.

[Renko]

14 hours ago, cfrag said:

To run any mission that uses a script with dostring_in(). If they do not enable it, the formerly running mission stops with an error. Try this: 

Won't run on a fresh, secure DCS install. It did so until yesterday.

Now we have at least one entire single player campaign that needs you to have those lines in order to play.
I wonder if a user who adds this will remember to remove after playing 
 

Still unclear to me, sorry i'm a bit clueless with all this, but if i leave that autoexec.cfg after playing a trustworthy mission/campaign it could be an issue for me as user.
That I wouldn't have before this update? 
Sort of like leaving the door open

Edited yesterday at 07:49 AM by Renko

[Bealdor]

Looks like not even official campaign makers got a heads up about this change:

https://www.reddit.com/r/hoggit/s/mtkrficBwq

This is incredibly bad 

[BIGNEWY]

9 minutes ago, Bealdor said:

Looks like not even official campaign makers got a heads up about this change:

https://www.reddit.com/r/hoggit/s/mtkrficBwq

This is incredibly bad 

Campaign creators have access to the same closed beta release candidate as the testers. 

thank you 

[Bealdor]

My apologies, I hadn't seen that Nix already posted a fix for this issue.

I must say though that not including that fix/autoexec file in the patch itself is less than optimal to say the least.

[MARLAN_]

8 minutes ago, BIGNEWY said:

Campaign creators have access to the same closed beta release candidate as the testers. 

thank you 

So, are you saying this upcoming breaking change was well communicated to closed beta testers?

Why was this kept a secret from the rest of the community?

You realize how terrible of a practice it is for a company to release a breaking change without any notice, right?

Companies following best practice will deprecate features/API versions (meaning you can still use them, but you know they're going to be removed LATER) or at the bare minimum, give upcoming notice...

[BIGNEWY]

12 minutes ago, Bealdor said:

My apologies, I hadn't seen that Nix already posted a fix for this issue.

I must say though that not including that fix/autoexec file in the patch itself is less than optimal to say the least.

No problem, the team are looking at the feedback and what has been affected in the community. 

[HanuXXL]

Aw man... I've using also DML on my missions, as it is quite elegant, and now they are broke. And the fix is to ditch the missions, or use autoexec.cfg to open up my PC/Server? And to reverse engineer what parts of code I should allow? I cannot tell how should I do this, and I'm quite sure my squadmates are willing to hunt needed codebits from forums/reddit/etc. Even official campaigns are suffering this. 

I guess it's time to take some AWOL to wait and see if any decent implementation of this will arrive on later patches.

I sure hope that the very important community people, like @cfrag, do not get fed up and stop developing their tools.

[MARLAN_]

My Dynamic Weather script for DCS is now broken and I don't have the time to fix it in an instant with zero warning, so support for that tool is going to be dropped too. Oh well.

Edited yesterday at 08:57 AM by MARLAN_

[Special K]

vor 3 Stunden schrieb Dangerzone:

I've previously suggested what I believe is a better solution: a true Open Beta—(implemented differently to before). Make it accessible only via command line, so only those with the tech knowledge of how to execute command lines, and also know the OB version number can install it. That way, it’s not used on production servers, and Open Beta versions don’t appear in the public server list—IP connect only. This would make it a genuine testing platform, not a general gameplay environment, and give us the time we need to adapt and see the upcoming changes and try them out. Sure - there will be some that push and opt to use it as a stable release, but it would be the minority. The previous OB didn't work because the majority used it as a stable release (and even ED recommended people use it for production in MP). 

I really feel we need a proper Open Beta for everyone’s sake. Far too many issues are being discovered in these new so called stable releases within hours, forcing hotfixes. That’s bad for both ED developers, who get blindsided and must scramble to patch, and for us, who have to react to breaking changes without warning. Let alone the image that it's putting out there of ED's quality. Let an Open Beta run for a couple of weeks—(1) to give content creators time to adapt, and (2) to apply necessary hotfixes—before pushing a public stable.

Just a pity that ED seems to disagree that there's issues for the community by working this way and believe everything is fine as is. Nothing needs changing, with "no plans to consider...". While all along I see what I feared when open beta disappeared. That the new and improved stable release would eventually degenerate to being what Open Beta was all along - with no real practical alternatives for public server content creators (that aren't in the CB team anyway) to be proactive, and just have to be reactive and rush about to deal with bugs, problems, or breaking changes at the last minute. 

This is what the closed beta is.

If it would not be easily accessible and servers would not show up, who should run that and who should play on it? 

[Spartan111sqn]

where shall be located the autoexec file?, is as simple as put that file in a folder of the server and that's it?, for example in foothold or pretense do we have an issue?, at the moment I tested it and they run normally

 

[Special K]

vor 2 Stunden schrieb PeeJott17:

@Special K Do you happen to know what needs to go into the autoexec.cfg to get the slot-blocker-script to run normally? The cfg-lines you provided fixed the progression-save-script but not the slot-blocker. I know, I'm disturbing your holiday, but if you happen to find the time between sunbathing and lunch, may-be you could just punch-in a few characters via your phone

Cheers,

PeeJott.

Would need to see the script to tell.

Would wonder why any slot blocker needs that. Mine does not.

vor 1 Minute schrieb Spartan111sqn:

where shall be located the autoexec file?, is as simple as put that file in a folder of the server and that's it?, for example in foothold or pretense do we have an issue?, at the moment I tested it and they run normally

 

Look a bit up, I posted a sample that should work for 99% of all cases.

Goes into Saves Games\DCS\Config

[Special K]

vor 28 Minuten schrieb MARLAN_:

My Dynamic Weather script for DCS is now broken and I don't have the time to fix it in an instant with zero warning, so support for that tool is going to be dropped too. Oh well.

You don't need to fix anything in your scripts. People that use it just need to amend their autoexec.cfg like people need to amend MissionScripting.lua since ages already. As said I have provided one in here, costs you 2 mins to share it.

[Tippis]

8 hours ago, Special K said:

You don't need to fix anything in your scripts. People that use it just need to amend their autoexec.cfg like people need to amend MissionScripting.lua since ages already. As said I have provided one in here, costs you 2 mins to share it.

Your solution is unsafe and does the exact opposite of what this change is meant to accomplish.

[HanuXXL]

12 hours ago, cfrag said:

I have been issued a warning for posting here.

Have a nice day all

 

This should be quite enough if "we are waiting for the community opinion" or something like that was said in another thread. 

 

What I mean who could afford to to lose such contributor as cfrag has been?

[BB.]

Is the return value working?
I made a simple script to test, but the return value doesn't work.

hookServer.onPlayerTrySendChat = function(playerId, message, all)
	if string.find(message , [[\test]]) ~= nil then
		local a,b,c = net.dostring_in('mission', 'return 1,2,3')
		net.send_chat("a = " .. type(a) , true)
		net.send_chat("b = " .. type(b) , true)
		net.send_chat("c = " .. type(c) , true)
	end
end

 

[AvgeekJoe]

Small update here:

Let me know if you need anything more. 

[Actium]

On 7/22/2025 at 4:14 PM, BIGNEWY said:

net.dostring_in() can now return values, which means that one can pass information directly between the different zones like so:
 

a,b,c = net.dostring_in('mission', 'return 1,2,3')

4 hours ago, BB. said:

Is the return value working?
I made a simple script to test, but the return value doesn't work.

I can confirm that this does indeed not work as advertised. Running the following code from DCS.openbeta/Scripts/Hooks 

return {net.dostring_in("mission", "return 1,2,3")}

will yield the following return value:

[
	"1",
	true
]

 

Maybe there's a mixup with a_do_script() available from the mission environment/zone? See the recently updated %DCS_INSTALL_DIR%/API/Sim_ControlAPI.html:

Quote

• net.dostring_in(state, string) -> string

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

  This API is only allowed in the states listed in the local $WRITE_DIR/Config/autoexec.cfg:

  net.allow_unsafe_api = {
    "userhooks", -- will make the API visible in _$WRITE_DIR/Scripts/Hooks/*.lua_ scripts
    "scripting", -- enables the API in the mission scripting state. DANGEROUS!!!
    "gui", -- system hooks and GUI state
  }
  

  Only states with names listed in autoexec.cfg settings will be accessible as API targets:

  net.allow_dostring_in = {
    "mission", -- will allow executing net.dostring_in("scripting", "lua code")
  }
  

  NOTE: There's no need for net.dostring_in anymore. You can return values from a_do_script() mission scripting API directly:

    local a, b, c = a_do_script("return 1,2,3")
  

The a_do_script() change is also part of the 2.9.18.12722 changelog. However, it is also broken, despite being the second attempt [1, 2].

[ldnz]

1 hour ago, Actium said:

I can confirm that this does indeed not work as advertised. Running the following code from DCS.openbeta/Scripts/Hooks 

return {net.dostring_in("mission", "return 1,2,3")}

will yield the following return value:

[
	"1",
	true
]

 

Maybe there's a mixup with a_do_script() available from the mission environment/zone? See the recently updated %DCS_INSTALL_DIR%/API/Sim_ControlAPI.html:

The a_do_script() change is also part of the 2.9.18.12722 changelog. However, it is also broken, despite being the second attempt [1, 2].

I got this to work from the hooks environment:

return net.dostring_in('scripting', "local mps = world.getMarkPanels(); local mps2 = {}; for k,v in pairs(mps) do table.insert(mps2,v['text']); end; return table.concat(mps2, '|')")

It seems that only trivial return values are being passed - single number or string, no complex objects. 

I wish there was a way for this to work online too. I can't believe its not possible to get the mark panels which are literally user generated points, would be so handy for any DTC type tool (or in my case plotting board style nav kneeboard)