Jump to content

Richard.biely

BI Developer
  • Content Count

    17
  • Joined

  • Last visited

  • Medals

Community Reputation

35 Excellent

3 Followers

About Richard.biely

  • Rank
    BI Developer

Profile Information

  • Gender
    Male

Recent Profile Visitors

774 profile views
  1. Richard.biely

    1.90 update - Troubleshooting

    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.
  2. Richard.biely

    1.90 update - Troubleshooting

    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).
  3. Richard.biely

    1.90 update - Troubleshooting

    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.
  4. Richard.biely

    1.90 update - Troubleshooting

    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 🙂
  5. Richard.biely

    64-bit Executables Feedback

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

    64-bit Executables Feedback

    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 :)
  7. 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!
  8. Richard.biely

    Remote Execution Enhancements

    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.
  9. Richard.biely

    Remote Execution Enhancements

    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 :) ).
  10. Richard.biely

    Remote Execution Enhancements

    This has nothing to do with remoteExec.txt
  11. Richard.biely

    Remote Execution Enhancements

    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).
  12. Richard.biely

    Remote Execution Enhancements

    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
  13. Richard.biely

    Remote Execution Enhancements

    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.
  14. Richard.biely

    The new remoteExec command

    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.
  15. Richard.biely

    The new remoteExec command

    What exectly does not work for you, please?
×