Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Posts posted by mreichi

  1. I am not sure if this is already possible, but it would be nice to have the option to broadcast from the server to all client except a certain client.

    Example: Client A sends switchMove to server. By using normal broadcast the server would send to Client A, B and C. With my suggestion we could have a multicast sending it to Client B and C (since it doesnt make sense to send that message back to the sender).

  2. Hey,

    this is looking good! The new "target" parameter is really making our life easier. For example if you want to "switchMove" yourself we had to do fancy things so far.

    My suggestions are:


    params: Anything - function arguments. Variables can be local.

    I suggest extending the CfgRemoteExec so it contains the allowed number of parameters and their data types. If this is missing, abusers could just send weird stuff over the pipe. This will add another layer of security, since sending unexpected parameters will/could cause remote script errors. Like you could just do "deleteVehicle 'NOPE'" to crash a peer if there is no parameter validation.

    class CfgRemoteExec
    class Server
    	class Functions
                          class bis_fnc_Something 
                                 parameters = {"SCALAR", "STRING", "OBJECT", "GROUP"};


    new Parameters: isReliable / isOrdered / orderSlotId

    I have seen that there is a maximum package size that is used to determine if a UDP packet chain should be delivered reliable or not. Currently I am completely unaware if messages are delivered in order and reliable or not. But it would really really but very nice if one could control that behaviour. Most of the things will be reliable and ordered, but tiny non-important things can be send unreliable and unordered to lower the traffic/system load. For example: Broadcasting the server FPS to all clients every five seconds. This is a case where we really dont care if a packet is lost or delivered out of order.


    Changes for mode 1 / 1-turned on, taking whitelist into account

    When whitelisting is active, the authors have to add the functions/calls/messages to the config. Thats perfect. However, the parameters to steer the behaviour of where to send the packets to is still in the code. Thus abusers could send a message to everyone, even though its into intended to be delivered to the server by design.

    I suggest ignoring the parameters "target", "JIP"/"isPersistent" and "call" when in whitelisting mode and use the config values instead. Thus only the mod makers have full control to where to send the messages to, thus making it harder to abuse.

    For example "switchMove" would look like this in mode 0

    Good version:
    // Switch the move on all clients, since switchMove only has local effect
    [player, "Acts_treatingWounded03"] remoteExec ["switchMove", -2, false]; 
    Bad version:
    // Here I abuse this and send it to the server, so it will crash, since server doesnt like switchMove's
    [player, "Acts_treatingWounded03"] remoteExec ["switchMove"]; 

    Switch move with whitelisting turned on

    Good version:
    [player, "Acts_treatingWounded03"] remoteExec ["switchMove"]; // there is no need to define more parameters, they are in the config
    Bad version:
    [player, "Acts_treatingWounded03"] remoteExec ["switchMove", -2, false]; // errors out, parameters cannot be set


    Another suggestions is to define the allowed "directions" in the config file. If you whitelist "systemchat" you may want to allow this "SERVER->CLIENT" only, whilst "CLIENT->CLIENT" is not allowed. Maybe like this?

    #define REMOTE_EXEC_S2C 0      // Server to Client
    #define REMOTE_EXEC_C2S 1      // Client to Server
    #define REMOTE_EXEC_C2C 2      // Client (to Server) to Client


    Last but not least I suggest changing the order of the parameters for "remoteExec" a bit. Currently it is like that:

    "WITH" remoteExec "WHAT" "WHERE" "WHEN"

    I suggest

    "WHERE" remoteExec "WHAT" "WITH" "WHEN"


    #define NON_JIP false
    _myGroup remoteExec ["systemChat", ["Kappa!"], NON_JIP]


    Also, it would very very useful if you could add the "sender owner ID" as a parameter to remote calls. Currently there is no way to know which client send a message to the server. You have to do that manually right now.


    Looking forward to your response,