Determining when a Player Re-slots.

[Rommel92]

I know how to detect when a user disconnects, and on the contrary, its damn easy. However detecting when a player "re-slots' is beyond my comprehension... especially since I'm running the script on the client.

My guess is that if I want to detect it, I'll have to run the script on the server watching the client, because currently its just impossible I believe.

 

[i0n0s]

Just create an array with all known players.
When a player is a JIP player, he checks if he is present in that array, otherwise add himself to the array and make it public.
Revive is going that way.

[Rommel92]

Doesn't make sense.
I'm trying to detect if he was playing (not a JIP), he pushes escape->abort, back to lobby pushes ok again and is now back at spawn. His unit dissapears, but how can I get the server to monitor this, since a player is always objNull?  

Code: [Select]

/* Script by Rommel */

if!(R_Init)then{R_Init=true};

_unit = vehicle (_this select 0);
_damage=0;_pos=[];
_weaps=[];_mags=[];_rifle=false;

if(R_Client && !R_Server)exitWith{};

while {(!(isNull _unit))} do
{
_damage = getDammage _unit;
_pos = getPos _unit;
_weaps = weapons _unit;
_mags = magazines _unit;
if(_unit hasWeapon (primaryweapon _unit))then{_rifle=true};
sleep 1.0;
};
R_Array1=R_Array1 + [name _unit];
R_Array1=R_Array1 + [[_unit,_damage,_pos,_weaps,_mags,_rifle]];
publicVariable "R_Array1";


[i0n0s]

What should your script do? And why does it run on the server?

[Rommel92]

Doesn't matter, after talking to Sickboy on the problem, he's notified me its pretty damn close to useless to figure out a way for when the player leaves the mission and re-slots unless its on a heartbeat method. 

[ModestNovice]

how bout something like this?

in init.sqf

Code: [Select]

onPlayerConnected "[] execVM ""connected.sqf""";
if (isNil "Names_Array") then {Names_Array = []}else{};
[] execVM "playerWatch.sqf";

------------
connected.sqf

Code: [Select]

publicVariable "Names_Array";
------------


------------
playerWatch.sqf

Code: [Select]

Checked = false;
Names_Array = [];

for[{_i=0},{_i<1},{_i=_i}] do
{
if (!(name player in Names_Array)) then
{
Names_Array = Names_Array + [name player, vehicleVarName player];
};

if (name player in Names_Array) then
{
if (!Checked) then
{
_ind = Names_Array find name player;
_UserName = Names_Array select (_ind + 1);
player groupChat format ["Slot: %1", _UserName];
Checked = true;
};
};

CInd = Names_Array find name player;
CUserName = Names_Array select (CInd + 1);

if (vehicleVarName player != CUserName) then
{
Names_Array set [CInd + 1, vehicleVarName player];
publicVariable "Names_Array";
Checked = false;
};
Sleep 0.4;
};------------

[Synide]

Doesn't matter, after talking to Sickboy on the problem, he's notified me its pretty damn close to useless to figure out a way for when the player leaves the mission and re-slots unless its on a heartbeat method. 

Your sentence is a little confusing.


Anyway, s'bit irrelevant. You can achieve what you want, without too much difficulty.

1. you can detect JIP.
2. you can detect if they are there at mission startup or not, so not JIP.
3. you can detect when they disconnect.
4. you can detect when they connect.
5. you can detect what character unit either a StartUp player is in or a JIP player is in.
6. you can detect if the new JIP'ing player is in the same or differing unit's body.
7. I denote players that are there at mission startup as 'mp_client' players, I denote jip'ing players as 'jip_client' players.
8. When a 'mp_client' (a player that was there at mission startup) hits the disconnect button and gets returned to the lobby and selects the same or a differing unit they always become a 'jip_client'.

All of the above can be done. Not easily, it requires a little gymnastics. But, is very much achieveable - I gaurantee it.
You do not need 'watching' thread's or anything that keeps a constant intermittent 'eye on players'. You can do it all with the basic scripting functionality available.
Is it a 'useless' thing to do, quite frankly I dunno, that all depends on requirements really.

It's simply a case of identifying the relevant 'context' a player is in or was in and storing the relevant data in either an array or arrays server side only. Or, storing the data in keygety's database, if you want to use his tool. And, when a 'jip_client' gets in-mission prior to them gaining control over the unit simply seeing if there 'playername' is in this server-side array (or DB), if so then compare the units 'objectname' (vehicleVarName in most cases) that would also be stored along with there 'playername' to that of the stored 'objectname' value.

   If different, then they are jip'ing into a new unit.

[Rommel92]

When you join a dedicated (persistent) server, start up a mission, assuming you can check the variables the mission defines, your set up.
Now push ESC -> Abort -> (Choose another slot, say the member no.2 of the group you were in) -> I'm ready -> Ingame; if you immediately check the variables that were defined before the re-slotting, they will be the same as before.
You never disconnected/connected.
You never were a JIP.
You never left your client status.

You were just objNull for a small portion of the time you were on the server. Any scripts you were running have been terminated also.

[Synide]

Again, find it a little hard to follow your dialog. What are you saying?

It's irrelevant if the client/player is there at mission startup or not.
If they are there at mission startup, then they are what I call in a context state of 'mp_client'.
If they join an already running mission, then they are what I call in a context state of 'jip_client'.
If they are there at mission startup, and have consequently been determined to be of a context of 'mp_client' and then get disconnected completely from the server or they abort back to the Multiplayer Setup screen and select the same or a differing slot there context state immediately changes to 'jip_client'.

See the below init.sqf script for how the 'context' of a client/player computer can be deduced when the init.sqf is run.

To try and use your example.

Senario:

      When the person joins this persistent already running mission of yours.

      1. On their computer, their instance of ArmA will run the init.sqf.
          If the init.sqf looked something like...

         

Code: [Select]

Context="";
if (isServer) then
{
  Context="sp_server";
  if (isnull player) then {Context="mp_server";}
}
else
{
  Context="mp_client";
  if (isnull player) then {Context="jip_client";}
};

call compile preprocessFile "scripts\common\common.sqf";
call compile preprocessFile format["scripts\%1\%1.sqf",Context];

processInitCommands;
finishMissionInit;
      Then at the end of this script completing the variable 'Context' will be equal to 'jip_client'.
      If, on the other hand this client/player started up a mission on the dedi. then by the end of this init.sqf running their context would be 'mp_client'.


      2. At the end of the init phase a server-side only event will be triggered 'onPlayerConnected'.

      You can use either of these occurences to add the client/player's profile name + the unit they have chosen to a globally managed array. (Or, as I mentioned to Keygety's databases).


Senario:

      After running around in mission for a variable amount of time the player/client hits ESC->Abort, and selects another 'slot' from the Multiplayer Setup screen and then relaunches into the mission.

      1. At this point I cannot remember if the 'onPlayerConnected' fires again so you might not be able to use that, but the 'jip_client' script will definitely be run again.

       Which ever method you do choose to utilize, it is then simply a case of checking the 'global' array (or database) to see if there is an existing entry for the player/client profile name. eg. Synide. Then aqcuiring the currently stored unit name eg. 'W1' that may or may not be present.
Eg. The global array would look like this...

   aryPlayers=[[Synide,W1],[JoJo,W2],[FatBoy,W3]]

As the 'jip_client' script is being run again on the 2nd. entry to the mission, this script can compare the currently selected unit eg. W5 with whats in the array. And, if they differ then the player/client has selected a different 'slot'.

Simple really.