mreichi

Thank you for testing. This means that is really is not worth using it then.

How do you know? He clearly states there is no difference from a wall just standing there and this.

All the freedom in configs. This is only an advantage for mission makers. What about mods? What is the real advantage of this? If it is not better for performance, then I really do not see a use of this for mods.

What is the difference between a vehicle of simulation type house and this? Only, that it cannot take damage and that you can load a p3d directly? We can already do this today. Please tell me :) Does it have any advantage for the consumer?

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

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" Example #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, Bastian