Jump to content
aeroson

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

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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;

  • Like 2

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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:

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

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

×