{owner object} requires some object to be passed to the server or the server looping through playableUnits to find a remote object, typically the unit, connected to a player.
It may help script performance if there is a more direct way to find the client id. This information should already exist on the server. Just require access to it.
// description.ext
class CfgFunctions {
class CYC {
class pingpong {
class ping {
preInit = 1;
postInit = 0;
recompile = 0;
ext = ".sqf";
file = "ping.sqf";
};
class pong {
preInit = 1;
postInit = 0;
recompile = 0;
ext = ".sqf";
file = "pong.sqf";
};
};};
};
// ping.sqf
if (isDedicated) exitWith {};
sendPing = {
diag_log "sending ping";
ping = player;
while {isNil "pong"} do {
publicVariableServer "ping";
};
};
"pong" addPublicVariableEventHandler {
diag_log "pong detected"; diag_log (_this select 1);
};
};
// pong.sqf
if (!isDedicated) exitWith {};
"ping" addPublicVariableEventHandler {
_sender = _this select 1; diag_log format ["ping detected from %1",name _sender]; pong = "pong from publicVariable"; publicVariable "pong"; pong = "pong from publicVariableClient"; (owner _sender) publicVariableClient "pong"; diag_log "pong sent";
};
};
/*
On the client, ping will send to the server a player that does not yet exist during pre-Init.
On the server, the ping public variable listener will log the "player" who sent it, but because the player object sent does not yet exist, "name _sender" results in an error. Responding to the ping, the pong sent by the server using publicVariable will succeed whilst the pong sent by publicVariableClient will fail, evidently because "owner _sender" produces an erroneous value.
*/
Can you please clarify further on how "public variables do not work in preInit"?
The reproduction code shows that publicVariables DO work in preInit. The only aspect that does not seem to work is publicVariableClient, because there does not appear to be any means (at least ones that I know of) of identifying the clientId of a client in preInit. Most methods discussed rely on use of objects, playableUnits and the owner command. Yet, the same client in preInit is already able to send and receive messages using commands publicVariable and publicVariableServer.
I'm doubting my memory now, but I know for certain that using spawn causes the code to run late enough for it to no longer be preInit (you can verify this by trying to use paramsArray preInit on a client - it doesn't get PVd until time 0 - and then the same but spawning the code).
Will have to do some testing now.
I do agree that there should be a better way to get a clientID than the owner command, but I'm not really sure how. Maybe it could be added as another argument to the publicVariableEventHandler.
^ I think the above means this ticket can be closed (Since the client ID would be no use preInit anyway).
SilentSpike your sarcasm is funny but on these forums, these are srz ppl running a srz bznz. Xeno, Skaronator, KK and yourself even are expert scripters/developers.
preInit allows you to run scripts in an unscheduled environment, meaning it allows you to get all your initialization done, in the mission splash/startup screen before the game session starts.
Of course, you can also run scripts in an unscheduled environment using a mission event handler like Draw3D. However with Draw3D, the user's session has already started and if the script within Draw3D is computationally heavy, the user experience is temporarily suspended. Generally, doing this to the player is not good practice.
Hopefully BI will do something now. publicVariableServer and publicVariableClient are amazing client-server messaging tools. All it needs is a more direct way to identify clients and connections that works not just in preInit but everywhere else. Searching by name through playableUnits (if the server is initiating the messaging) or waiting for the client to send an object, typically {player}, so that the server can apply {owner} to it to extract the clientid, sounds "hacky".
The _id in onPlayerConnect corresponds to DirectPlay id, and cannot be used for publicVariableClient messaging. I am not even sure if onPlayerConnect has already fired whilst the new client session is still in preInit. Will test later.
I'm not quite sure you understand, I wasn't being sarcastic.
If you look at the comments of the issue posted by Xeno, you'll see that public variables do not work preInit (as confirmed by developer Karel Moricky). This behavior is intentional because why would public variables work preInit? It's being ran before anything is initialized so that doesn't make much sense when you think about it.
The reason your code works, is because you're using the spawn command. This delays the code long enough for it to no longer be ran in the preInit time interval.
I'm not quite sure I follow your line of thought with the unscheduled thing, it's pretty unrelated to this feature request and because you're spawning your code you're running it in a scheduled environment anyway.
Anyway, my point is that since nobody would ever use public variable preInit then there's no need for client ID's preInit.
I get your point that spawn pushes the execution to the scheduled environment i.e. postInit. What I still don't get is why you or BI feel there is no use case for client-server communications in unscheduled environment. Anyway, I am more accepting of the fact, after reading through KK's tutorial again, linked below:
http://killzonekid.com/arma-scripting-tutorials-code-performance/
Again, it's not related to the scheduled and unscheduled environments.
preInit/postInit/etc. are a matter of timing. The scheduled and unscheduled environments are a matter of execution.
You can happily communicate between machines in an unscheduled environment, you can't do so before the game has initialized (which is a design limitation, not a free variable).
Edit: Though yes, your new feature request reflects something that is feasible and I'd like to see implemented.
There is clientOwner command available now that should return client id regardless of player existence on the client. Also both onPlayerConnected and onPlayerDisconnected have _owner information for the joining/leaving client.
Does this resolve the issue?