GET/SET Loadout (saves and loads pretty much everything)

[R3vo 2654]

You can simply use  initPlayerLocal.sqf  instead of onPlayerKilled.sqf to save the initial loadout.  

[Grester 40]

You can simply use  initPlayerLocal.sqf  instead of onPlayerKilled.sqf to save the initial loadout.  

Yeah but using a custom arsenal loadout setup on mission runtime that's the problem. Like I explained, a player goes to arsenal, loads his favorite loadout and proceeds to mission. I don't wish to use a preset loadout. Thus my brainstorming ideas.

[R3vo 2654]

Yeah but using a custom arsenal loadout setup on mission runtime that's the problem. Like I explained, a player goes to arsenal, loads his favorite loadout and proceeds to mission. I don't wish to use a preset loadout. Thus my brainstorming ideas.

 

Oh okay, I missed that. Would need to check whether there is a variable one could check to see if the Arsenal was closed.

[IndeedPete 1038]

I believe there is. For example, we were using scripted EHs to check if the player has the correct radio(s) once he closes the Arsenal:

[missionNamespace, "arsenalClosed", {	
	_baseRadio = player getVariable ["STAF_BaseRadio", ""];
	_addRadio = player getVariable ["STAF_AdditionalRadio", ""];
	
	if ((_baseRadio != "") && {{(toLower _x) find _baseRadio >= 0} count (assignedItems player) == 0}) then {
		player linkItem _baseRadio;
	};
	
	if ((_addRadio != "") && {{(toLower _x) find _addRadio >= 0} count (items player) == 0}) then {
		player addItem _addRadio;
	};
}] call BIS_fnc_addScriptedEventHandler;

[Grester 40]

I believe there is. For example, we were using scripted EHs to check if the player has the correct radio(s) once he closes the Arsenal:

Alright gonna give it a try, the thing is...

A) is this supposed to be a local "general/game" EH since it isn't really "watching" a player's actions?

 

B )  So it should be safe to place in initPlayerLocal.sqf or is there a better suggestion?

Since the scripts will involve the player which is owned by the player or...

 

C) is this a bad idea since according to https://community.bistudio.com/wiki/setUnitLoadout this command is considered global and thus calling it locally wouldn't work properly or it would be fine since it would potentially end up being broadcast for the entire server?

 

Edit: I'm guessing C shouldn't matter because what B does is simply attach the EH to the player not actually running the snippet that's part of it.

[IndeedPete 1038]

Alright gonna give it a try, the thing is...

A) is this supposed to be a local "general/game" EH since it isn't really "watching" a player's actions?

 

B )  So it should be safe to place in initPlayerLocal.sqf or is there a better suggestion?

Since the scripts will involve the player which is owned by the player or...

 

C) is this a bad idea since according to https://community.bistudio.com/wiki/setUnitLoadout this command is considered global and thus calling it locally wouldn't work properly or it would be fine since it would potentially end up being broadcast for the entire server?

 

Edit: I'm guessing C shouldn't matter because what B does is simply attach the EH to the player not actually running the snippet that's part of it.

 

A) The Arsenal function itself sets a variable (arsenalClosed) this EH will react to. I'd double check it though since we used this function I posted in combination with the XLA Fixed Arsenal mod which alters / is based on the vanilla Arsenal. I can't tell for sure if the EH will work with the vanilla Arsenal as well.

 

B) Run client-side. So initPlayerLocal.sqf is fine.

 

C) It says both arguments and effects are global so you don't have to worry about any network issues if you use it like described in B).

[Larrow 2820]

A) is this supposed to be a local "general/game" EH since it isn't really "watching" a player's actions?

Correct its not watching the player but waiting for a call to callScriptedEventHandler with reference to a namespace and variable, in this case missionNamespace and "arsenalClosed".

Think of it a little like a c# delegate, you queue up code/functions to run associated with a namespace and variable reference, when that reference is called all code/functions are executed.

In this case BIS_fnc_arsenal automatically calls missionNamespace "arsenalOpened"/"arsenalClosed" for you by design.

B ) InitPlayerLocal would be best as these SEHs are only called locally to each client, although associated with a namespace and variable they are not hooked into publicVariable. The namespace and variable are literally just a reference locally to where the code/fucntions to run have been stored.

C ) Would be fine, as the SEH is only being called locally AG will be ok as the argument, and your likely to be using player here, can be anywhere and EG is need anyway to tell all clients that the units(player) inventory has changed.

[Grester 40]

Works flawlessly, no errors at all. Tested on 3den MP by being killed with unchanged loadout after arsenal visit and manual forced respawn with changed loadout after arsenal visit.

 

Kudos to R3vo and IndeedPete. Final result:

 

initPlayerLocal.sqf

[missionNamespace, "arsenalClosed", {	
	player setVariable ["Saved_Loadout",getUnitLoadout player];
}] call BIS_fnc_addScriptedEventHandler;

onPlayerRespawn.sqf (unchanged original file from R3vo)

player setUnitLoadout (player getVariable ["Saved_Loadout",[]]);

PS: R3vo may I suggest you add this to the next 3den Enhanced update? :lol:

[MisterCat 27]

onPlayerKilled.sqf

player setVariable ["Saved_Loadout",getUnitLoadout player];

onPlayerRespawn.sqf

player setUnitLoadout (player getVariable ["Saved_Loadout",[]]);

Create both files and put them into your mission folder.

 

Is this still working? I can't get it to work

[killzone_kid 1330]

Is this still working? I can't get it to work

It shouldnt work if the new player object is different object, since the variable with loadout would be set on another object. Try missionNamespace instead of player with set/getVariable

[MisterCat 27]

Thanks :) Works perfectly

[Larrow 2820]

Works fine for me.

 

It shouldnt work if the new player object is different object, since the variable with loadout would be set on another object. Try missionNamespace instead of player with set/getVariable

Players namespace vars are transferred and has been this way since the end of beta when it was fixed.

I did go looking for a citation but could not find one from way back then. Yet there was a time early on when some tasks would get lost because the players namespace was not transferring over properly and tasks assigned to a player are kept in their namespace.

For example try

player setVariable [ "test", "This is a test" ];

player addEventHandler [ "Killed", {
	player setVariable [ "loadout", getUnitLoadout player ];
}];

player addEventHandler [ "Respawn", {
	params[
		"_unit",
		"_corpse"
	];
	hint format[ "Player is new object\n%1\n\nSaved Loadout\n%2\n\nTest message\n%3",
		_unit != _corpse,
		_unit getVariable[ "loadout", "not set" ],
		_unit getVariable[ "test", "not set" ]
		];
}];

and then respawn from the menu or kill yourself. It will hint that player is in fact a new object, yet the variables are available.

Unless your doing something weird with the player object all its namespace vars should be transferred over by the engine.