Jump to content
zozo

Remote Execution Enhancements

Recommended Posts

From the wiki:

Can be defined in Config.cpp or in campaign's or mission's Description.ext. The most local variant is used.

Would a CfgRemoteExec defined at mission level negatively affect any running addons that use remoteExec?

Share this post


Link to post
Share on other sites

is the new JIP queue feature significantly faster than BIS_fnc_MP's old persistence option?

Share this post


Link to post
Share on other sites

I ask allready at the wiki, but my post as (Will) was deleted.

It is possible to return the RETURN of the remote script. This seams for me the only cause to use this command.

Without this i must again write a scipt which send a request, a server script and a script which receive the request. Or i must use a publicVarHandler, a public var and must wait until the server script response....

It this possible or a to big feature...

- Will (shukari)

Share this post


Link to post
Share on other sites
From the wiki:

Would a CfgRemoteExec defined at mission level negatively affect any running addons that use remoteExec?

Yes, possibly. Mission designer always has the last word. Therefore, just like with any other addon out there, it's up to mission designers to keep an eye on this.

is the new JIP queue feature significantly faster than BIS_fnc_MP's old persistence option?

These two things are a synonym. The only difference is that the new approach we took is no longer scripted which alone already makes it faster. However, our main goal was security in the first place.

I ask allready at the wiki, but my post as (Will) was deleted.

It is possible to return the RETURN of the remote script. This seams for me the only cause to use this command.

Without this i must again write a scipt which send a request, a server script and a script which receive the request. Or i must use a publicVarHandler, a public var and must wait until the server script response....

It this possible or a to big feature...

- Will (shukari)

I'm afraid this won't be done and I don't think it's the only reason to use the command. See https://community.bistudio.com/wiki/remoteExecCall for more info.

Share this post


Link to post
Share on other sites

Cannot wait to play around with these.

remoteExecCall = unscheduled vs remoteExec = scheduled right?

Share this post


Link to post
Share on other sites
Cannot wait to play around with these.

remoteExecCall = unscheduled vs remoteExec = scheduled right?

Why wait? You can switch to dev anytime.

Share this post


Link to post
Share on other sites

Any new informations about sending the ownerID of the caller to the receiver...

Share this post


Link to post
Share on other sites

Any new informations about sending the ownerID of the caller to the receiver...

What would be better imo is a command that will return the clients ownerID, without having to broadcast it to the player manually with scripts.

Share this post


Link to post
Share on other sites

i will have immediate reason for you to update all your missions (and thus servers)

it seems, remoteExec is ENABLED by default (facepalm) if nothing is defined (by design to keep BIS_fnc_mp working)

double irony is that BIS_fnc_MP transition under new RemoteExec,RemoteExecCall is scheduled for 1.54 (so not yet in 1.50)

//note: old White-lists defined in CfgRemoteExecCommands , CfgRemoteExecFunctions

// are no longer supported ! They have been replaced with CfgRemoteExec

// add this ASAP to your description.ext

 

class CfgRemoteExec
{
        class Functions
        {
                mode = 0;
                jip = 0;
        };
        class Commands
        {
                mode=0;
        };
};
OR

https://www.dropbox.com/s/zmiej9gndjt3ssi/noRemoteExec_Server.pbo?dl=0

^this loaded via -serverMod= should work same as the description.ext update

Share this post


Link to post
Share on other sites

This has nothing to do with remoteExec.txt

Well looks like now it does. If I call the following:

"abc" remoteExec ["test123", 2];
BattlEye complains with this:

29.12.2015 01:06:42: AgentRev (****************) ******************************** - #0 "test123 "abc""
This was not needed. The remoteExec command is now ruined, as the need to whitelist stuff via BE's remoteexec.txt will open up holes for kiddies to send raw code to server via createUnit. I already have to whitelist "bis_fnc_execvm" out of the box because it's automatically called by functions_f\initfunctions.sqf on join for the initPlayerServer.sqf thingy.

Thanks, BIS. <_<

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×