Jump to content
Sign in to follow this  
galzohar

Locality of units when JIPing during briefing?

Recommended Posts

Doing waitUntil {!isNull player} does not seem to be enough, it seems like the player still does not equal his own unit and/or that his unit is not local and thus the script that gives him weapons doesn't work. I have a sleep .1 in the script before checking for locality and giving him weapons so that it'll only happen after mission starts, and yet the script will not give him any weapons.

The script does work properly for players who are present at mission start and for JIP players (aka JIP players don't get weapons when they join into an existing AI unit as that AI unit already got those weapons when the mission started) - The only problem is with people joining during briefing.

I'm assuming sleep .1 makes the script only run after mission starts, correct me if I'm wrong please but it does seem to be the case.

I don't even want to know what happens in missions with respawn enabled and AI disabled, as there I won't even know at what point the actual player unit is created and assigned to the player...

Any help would be much appreciated, specifically explaining why I can't give weapons to a unit I JIPed into during briefing.

The script:

waitUntil {!isNil "isJIP"};
if (!isServer && isJIP) exitWith {};
if (!isServer) then
{
waitUntil {!isNull player};
};
waitUntil {!isNil "ace_sys_ruck"};
waitUntil {ace_sys_ruck};
sleep .1;
_unit = _this select 0;
_strLoadout = _this select 1;

if (!isNull player) then
{
if ((!isPlayer _unit) && (player == leader group _unit)) then
{
	waitUntil {local _unit};
};

if (_unit==player) then
{
	waitUntil {local _unit};
};
};

if (local _unit) then
{
removeAllWeapons _unit;
};

switch (_strLoadout) do
{   
case "FTL":
{
	if (local _unit) then
	{
		{_unit addMagazine "30Rnd_556x45_Stanag";} forEach [1,2,3,4,5,6,7];
     			_unit addWeapon "ACE_SOC_M4A1_Eotech";
		{_unit addMagazine "HandGrenade_West";} forEach [1,2];
		_unit addMagazine "SmokeShell";
		_unit addMagazine "SmokeShellGreen";
		_unit addMagazine "SmokeShellRed";
	};
};

case .....
};

if (local _unit) then
{
if (!(_unit hasWeapon "itemGPS")) then
{
	_unit addWeapon "itemGPS";
};
_unit addWeapon "binocular";
_primaryWeapon = primaryWeapon _unit;
_unit selectweapon _primaryWeapon;
// Fix for weapons with grenade launcher
_muzzles = getArray(configFile>>"cfgWeapons" >> _primaryWeapon >> "muzzles");
_unit selectWeapon (_muzzles select 0);
};

Where isJIP is defined on the server, set to false and then publicVariabled on mission initialization and every time a player connects, and is set to false 1 second after mission starts (by using [] spawn {sleep 1; isJIP=true;}; on the server.

Some more testing shows that the script fails only when the leader of the JIPing player is another player.

Edited by galzohar

Share this post


Link to post
Share on other sites

I always use

waitUntil { (player == player) };

intead of

waitUntil {!isNull player};

Don't know if there really is a big different but to me this alway's works like it should.

Also what exactly is

_unit = _this select 0;

If it's a A.I. unit in a player group then it may can be that it need's a bit longer to initialize and set the locallity of the unit.

In some of my latest teste A.I. leaded by a player need up to 1 sec. after a mission was started to be initialized correctly and to set local to the player ( leader ) by the engine.

Share this post


Link to post
Share on other sites
If it's a A.I. unit in a player group then it may can be that it need's a bit longer to initialize and set the locallity of the unit.

This is already taken into consideration if you actually read the rest of the script. The problem is not with AI, it is with players, and only when they JIP into a unit lead by a human player during the briefing. Everything else works fine flawlessly (or at least I have yet to seen it not work), whether the unit is a player or AI.

Share this post


Link to post
Share on other sites

Nobody has a clue what happens to players who JIP during briefing into a group with a human leader?

Share this post


Link to post
Share on other sites

Looks like the problem was this:

http://community.bistudio.com/wiki/6thSense.eu:EG

onPlayerConnected will process new players after they are connected to their player body. So JIP player connects, world initializes, he gets control of his character, now the onPlayerConnected fires on the server.

That means that the players who JIP during briefing don't fire the onPlayerConnected until it's too late and isJIP is already set to false.

But then again since isJIP was publicVariabled it should (as I just discovered) have its latest value broadcasted to the JIP player as soon as he joins, so I would assume that the broadcasting only happens after the onPlayerConnected is run, which in turn only happens after isJIP is set to false and is publicVariabled by the onPlayerConnected.

On another note, on the Zeus forums Killswitch suggested to just run all loadout scripts from the init lines (call, not spawn, so they are run before init.sqf) and at the time they will run all units will be local to the server and thus everything should work. I've done some testing today that tries to see when this could break by running lots of long loops in the init lines of units to see if the last unit in the initialization loses locality before its init line is run, but it was always local at that time no matter how much I was running. It seems that players can't even get into the briefing (in fact, they can't even finish downloading more than a few KB of the mission file and even if they have it already they will be stuck in "wait for host") until server finishes running all init lines of units. So unless anyone finds a reason for a unit to not be local to the server when its init line is ran, I'll be using that solution instead.

I'd still like to know what is an effective way to tell the difference between a JIP player and a non-JIP player. Using isNull player would be un-reliable because you never know when player stops being null (which means if you run a lot of scripts in parallel you could possibly break the script that checks if player is null/JIP or not). Player is definitely null during mission initialization (that is, when units' init lines are being run), but that is also true for non-JIP players.

Share this post


Link to post
Share on other sites

I didn't read this right through but I don't think I've experienced the problem you're having. There might be a number of reasons for that but one possibility is that my player initialisation includes:

<-- Other Code -->
while {IsNull player} do {Sleep 0.1;};
<-- Other Code -->
while {!Alive player} do {Sleep 0.1;};
<-- Other Code -->
<-- Do Loadout -->

For that matter why use isJIP at all? Why do you need to initialise JIP players differently?

Share this post


Link to post
Share on other sites

Because if you JIP into an AI unit that unit should already have its weapons assigned from when the mission started and thus the weapon script needs to not run - if it does he will get his weapons re-assigned every time he JIPs into the slot, which basically means unlimited ammo for everyone if they exploit it, and besides, it makes no sense.

In a mission with no JIPable AI slots there is obviously no problem.

Anyway as far as I can tell killswitch's solution works as the players cannot even get into the mission and start their initialization (and grab locality of their units) until the server finished its initialization. I could still use a confirmation on this but I ran some pretty intensive loops on the server's initialization (in units' init lines) and it does seem to be the case.

Would still like to know how to properly detect JIPs for possible future ideas unrelated to weapon loadouts...

Is it possible for a client to have time>0 at the same time as isNull player on a JIP client? Since during briefing everyone always have time==0 but at some point during the briefing they stop being null, then waitUntil {!isNull player}; if (time>0) then {isJIP=true;} else {isJIP=false}; should properly detect JIPs, however I'm afraid for players who JIP during briefing (who from my perspective do not count as JIP) would appear as JIP by this condition as they seem to remain null until the mission actually starts (which is what was causing the first problem).

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×