Richard.biely

You need to make sure you have the mod installed on your system. This mod has to match the version that is installed on the server, too.

This most likely means, you are running your server using "-mod=@HVP" while not doing the same on your client (or if you do, your client does not have the data).

Any mods listed in your server's "-mod=" param are necessary to exist on clients as well. Mods listed in "-servermod=" are server-side and therefore not necessary to exist on connecting clients.

As it is stated in the very first post of this thread, dubbing_radio_f_data.pbo and air_f_rtd.pbo are two old and deprecated files which might still be present in your Addons folder because Steam does not autoclean them. Please, try to remove these files from your server and you should be able to connect. Because these files should no longer exist, removing them from your client will not do any harm, too. I hope this will help to solve your issue 🙂

If you were so kind and provided us with a crash dump then maybe we'll be able to do something about it ;)

Unfortunately, 64-bit Linux binaries are not yet ready. We'll try to bring it to you as soon as possible the next year, though :)

To make things slightly more organized here, this thread serves as a place to collect feedback for Arma 3's new 64-bit executables published on Dev-Branch. Do not hesitate to share any of your thoughts and issues found while using them. Thank you!

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. 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'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.

Description updated: https://community.bistudio.com/wiki/CfgRemoteExec It says that the function/command sent via remoteExec is allowed to be jipped (0=it is not, 1=it is). If it's not and you try to call remoteExec ["func",0,true/"myjipid"], remoteExec won't execute (this specific behaviour will work properly starting tommorow :) ).

This has nothing to do with remoteExec.txt

My bad. This function does not exist in dev. Imagine anything else in its stead. I can see no reason for that (does no difference for me and I don't see why it should).

Well, bis_fnc_mp actually spawns the function and hence I don't think it behaved any different than it does now. Running something like this might prove me right (or not :) ): fn = { t2 = "(2) " + str diag_tickTime; hint t2; DBG_ignoreLocks [player]; t3 = "(3) " + str diag_tickTime; hint t3; }; t1 = "(1) " + str diag_tickTime; hint t1; {call fn;} remoteExec/remoteExecCall ["bis_fnc_call"]; t4 = "(4) " + str diag_tickTime; hint t4; // (1) 575.971 // (2) 576.006 // (3) 576.006 // (4) 575.971

While this might sound like a good idea (and it is :)) I'm afraid it would increase complexity of configuration a lot without adding much value in general. All our scripted commands have their parameters validated (fingers crossed) and if there are any which don't we'll fix that. Order is fixed. Imagine you'd want to create a soldier and equip him with a weapon. Packets arriving in an oposite order wouldn't do much good in this case. IsReliable will be considered because it might help save some traffic. I think this could be solved by something like: Server/Client { Commands/Functions { class switchMove{ allowedTargets=-2 }; // clients only class switchMove{ allowedTargets=0 }; // anyone class switchMove{ allowedTargets=2 }; // server only } }; with allowedTargets=0 being the default value. Mode parameter is about whether or not the set of commands/functions is enabled. Let's not change it's meaning completely. I think it does its job just fine for now. I think that the previous paragraph covers this question as well. Multiple orders of arguments were considered along with the one you suggested. In the end, however, we decided to stich with the WITH WHAT WHERE WHEN approach. One of the main reason being this way we can have a relatively fixed code on the right side and variable code on the left side (called scripted command/function arguments). Good suggestion. This is already considered. We have yet to decide in what way to deliver this datum to receiver's side, though. It's most likely going to be some sort of an event handler which you'll be able to register to. I think executing this in a more demanding scenario should result in a mesurable difference. RemoteExec runs in scheduled environment whereas RemoteExecCall is executed in one go. Therefore, RemoteExec can (but does not have to) take more time to execute.

RemoteExec executes the script in scheduled environment (it spawns the script) and hence "hint str z" might be executed sooner than remoteExec itself. However, I assume your question actually targeted remoteExecCall (which executes the script by calling it) with your question. The main reason is that, even tough it calls the script, there are currently other elements involved delaying its real execution. So while it's true it executes the scripted function/command by calling it, it is not a replacement for calling the command/function directly at the moment (it is not called right away). This should not pose a problem as BIS_fnc_MP behaves in the same way in this regard. If you don't like this behavior, you're more than welcome to share your thoughts and opinions on a forum thread dedicated specifically to remote execution.

What exectly does not work for you, please?