bhaz 0 Posted July 2, 2015 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
naizarak 4 Posted July 4, 2015 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
shukari 28 Posted July 5, 2015 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
Richard.biely 35 Posted July 8, 2015 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
whiztler 137 Posted July 15, 2015 Cannot wait to play around with these. remoteExecCall = unscheduled vs remoteExec = scheduled right? Share this post Link to post Share on other sites
killzone_kid 1332 Posted July 15, 2015 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
dna_uk 30 Posted July 25, 2015 http://feedback.arma3.com/view.php?id=24961 Share this post Link to post Share on other sites
shukari 28 Posted August 11, 2015 Any new informations about sending the ownerID of the caller to the receiver... Share this post Link to post Share on other sites
dna_uk 30 Posted August 12, 2015 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
Dwarden 1125 Posted September 4, 2015 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; }; }; ORhttps://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
AgentRev 22 Posted December 29, 2015 This has nothing to do with remoteExec.txtWell 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