[Release] - A Plot for life v2.5. Keep your buildables on death. Take plot ownership

[RimBlock]

dayz_server.pbo has always contained server_monitor.sqf which is why there is no need to have two different versions of this mod. 

 

If they have access to mission.pbo then they have access to dayz_server.pbo as well.

 

 

Ok, now I see your point... and a good point it is :-).

 

I will take out the hosted version then.

 

Thanks Cen

[cen]

No problem man!

 

Great mod, I just need to get it working with all my mods now haha!

[cen]

OK got it all working now. Is there a way to remove the fact that the safe owner never has to enter a combination again?

[RimBlock]

Easiest, but not most efficent, way would be to

 

fn_selfactions.sqf

 

Find

_combi = player addAction [format[localize "STR_EPOCH_ACTIONS_OPEN",_text], 
"\z\addons\dayz_code\actions\vault_unlock.sqf",_cursorTarget, 0, false, true, "",""];

change to

_combi = player addAction [format[localize "STR_EPOCH_ACTIONS_OPEN",_text], 
"\z\addons\dayz_code\actions\vault_combination_1.sqf",_cursorTarget, 0, false, true, "",""];

All this does is mean that if you are the owner then you have to unlock using combination else unlock by combination.

 

The cleaner way would be to setup a variable in variables.sqf (say "_vaultOwnerMustUnlock") set it in variables.sqf as false for default (owners do not need to unlock via combination).

 

Put it in the init.sqf and set to true or false depending on preference.

 

in the fn_selfactions.sqf

 

find (around line 540)

_combi = player addAction [format[localize 
"STR_EPOCH_ACTIONS_OPEN",_text],"\z\addons\dayz_code\actions\vault_combination_1.sqf",_cursorTarget, 0, false, true, "",""];

Change to

if (_vaultOwnerMustUnlock) then{
  _combi = player addAction [format[localize 
"STR_EPOCH_ACTIONS_OPEN",_text],"\z\addons\dayz_code\actions\vault_combination_1.sqf",_cursorTarget, 0, false, true, "",""];
}else{
_combi = player addAction [format[localize 
"STR_EPOCH_ACTIONS_OPEN",_text],"\z\addons\dayz_code\actions\vault_unlock.sqf",_cursorTarget, 0, false, true, "",""];
};

That will sort out vault locking.

 

Vault packing also locks the vault before packing so you can do the same there if you wish (around line 565 in the same file).  A good rule of thumb is to look for "if(_characterID == dayz_combination || _ownerID == _playerUID) then {" in fn_selfactions.sqf and fn_damageactions.sqf for items only the owner can do.

[cen]

What I mean is that in default epoch when you die, even if you're an owner, you still need to unlock the safe again with a code.

 

When you die with this mod you don't have to enter the code again.

[RimBlock]

What I mean is that in default epoch when you die, even if you're an owner, you still need to unlock the safe again with a code.

 

When you die with this mod you don't have to enter the code again.

 

err, so for vaults, you want to track the safe code, the playerUID and the characterID so if a player dies you then can ask them to re-enter the code again.

 

The quick answer is not without a redesign and also storing the characterID as well.  I guess you could try to find a way to clear the ownerPUID of the vaults owned by a player if their character dies, possibly in the player_death.sqf but it is likely to be a fiar bit of work and troubleshooting.

 

Why are you looking to do this, out of interest ?. 

[cen]

This is how epoch does it by default. I don't want safe owners getting lazy and never having to remember their safe/lockbox codes.

 

I found a way to do it. Here is what I did:

 

• Removed player_lockVault.sqf
• Removed player_packVault.sqf
• Removed player_unlockVault.sqf

In fn_selfActions.sqf I defined a new variable for _ownerID

_ownerID = _cursorTarget getVariable ["ownerPUID","0"];
_ownerID2 = _cursorTarget getVariable ["CharacterID","0"];

This new var uses CharacterID instead of ownerPUID.

 

Then for all the vault actions I used the new var:

//Allow owner to unlock vault
	if((_typeOfCursorTarget in DZE_LockableStorage) && _ownerID2 != "0" && (player distance _cursorTarget < 3)) then {
		if (s_player_unlockvault < 0) then {
			if(_typeOfCursorTarget in DZE_LockedStorage) then {
				if(_ownerID2 == dayz_combination || _ownerID2 == dayz_playerUID) then {
					_combi = player addAction [format[localize "STR_EPOCH_ACTIONS_OPEN",_text], "\z\addons\dayz_code\actions\vault_unlock.sqf",_cursorTarget, 0, false, true, "",""];
					s_player_combi set [count s_player_combi,_combi];
				} else {
					_combi = player addAction [format[localize "STR_EPOCH_ACTIONS_UNLOCK",_text], "\z\addons\dayz_code\actions\vault_combination_1.sqf",_cursorTarget, 0, false, true, "",""];
					s_player_combi set [count s_player_combi,_combi];
				};
				s_player_unlockvault = 1;
			} else {
				if(_ownerID2 != dayz_combination && _ownerID2 != dayz_playerUID) then {
					_combi = player addAction [localize "STR_EPOCH_ACTIONS_RECOMBO", "\z\addons\dayz_code\actions\vault_combination_1.sqf",_cursorTarget, 0, false, true, "",""];
					s_player_combi set [count s_player_combi,_combi];
					s_player_unlockvault = 1;
				};
			};
		};
	} else {
		{player removeAction _x} count s_player_combi;s_player_combi = [];
		s_player_unlockvault = -1;
	};

	//Allow owner to pack vault
	if(_typeOfCursorTarget in DZE_UnLockedStorage && _ownerID2 != "0" && (player distance _cursorTarget < 3)) then {

		if (s_player_lockvault < 0) then {
			if(_ownerID2 == dayz_combination || _ownerID2 == dayz_playerUID) then {
				s_player_lockvault = player addAction [format[localize "STR_EPOCH_ACTIONS_LOCK",_text], "\z\addons\dayz_code\actions\vault_lock.sqf",_cursorTarget, 0, false, true, "",""];
			};
		};
		if (s_player_packvault < 0 && (_ownerID2 == dayz_combination || _ownerID2 == dayz_playerUID)) then {
			s_player_packvault = player addAction [format["<t color='#ff0000'>%1</t>",(format[localize "STR_EPOCH_ACTIONS_PACK",_text])], "\z\addons\dayz_code\actions\vault_pack.sqf",_cursorTarget, 0, false, true, "",""];
		};
	} else {
		player removeAction s_player_packvault;
		s_player_packvault = -1;
		player removeAction s_player_lockvault;
		s_player_lockvault = -1;
	};

Now when someone dies, they are forced to re-enter the combination of the vault/lockbox.

[RimBlock]

I see so you want to keep the vault stuff based on characterID and without a persistant player owner.

 

Yep that would do it then.

 

Of course, if they forget the code then you could just tell the owner to pack and place the safe and they will get a new one.  Having to empty it first is the price for forgetting the code in the first place ;) .

[Buck0]

Rim, would this work with the ckc change safe/door code script? I haven't looked at how you have set it up im not sure if you have changed the table that's used for handling codes

[RimBlock]

Hi Buck,

 

Not changed anything to do with the lock code generation so it should work fine.

 

One cavaet is that I do not see how DZE_Lock_Door is being populated and cannot download the mod from where I am to search the code.

[RimBlock]

If the code is now working well (will update the download file tonight) then I will be working on two other bits before caking the changes and pushing the to Epoch Git.

 

Functionise

• Medic animation
• Plot pole check

As you may have noticed, if looking throught the various buildable (and other) code, the medic animation is used quite a lot.  This means that a standard block of code is appearing in multiple files and doing more ro less the same thing.  I will be creating a seperate function that these scripts can call thus removing multiple sets of duplicate code from multiple files (small mission files and more efficent code usage).  I will be making it accept a number of parameters and this is where your input would be helpful.

 

Something like

Returns: true or false.  True = animation completed without abort.

 

Variables

_anim - Which animation to play.

_complete - Anim cycle completed (without abort).

Object: Object animation is for (i.e. trader, buildable, vehicle)

MaxDist: Max distance from object before auto-abort.

 

Anything else you think would be cool to add guys ?.

 

I will be doing the same for the plot pole ownership check as that code is repeated in a number of files but I think that one is pretty cut and dried on what it needs and what is returned.

[Buck0]

This is how epoch does it by default. I don't want safe owners getting lazy and never having to remember their safe/lockbox codes.

 

I found a way to do it. Here is what I did:

 

• Removed player_lockVault.sqf
• Removed player_packVault.sqf
• Removed player_unlockVault.sqf

In fn_selfActions.sqf I defined a new variable for _ownerID

_ownerID = _cursorTarget getVariable ["ownerPUID","0"];
_ownerID2 = _cursorTarget getVariable ["CharacterID","0"];

This new var uses CharacterID instead of ownerPUID.

 

Then for all the vault actions I used the new var:

//Allow owner to unlock vault
	if((_typeOfCursorTarget in DZE_LockableStorage) && _ownerID2 != "0" && (player distance _cursorTarget < 3)) then {
		if (s_player_unlockvault < 0) then {
			if(_typeOfCursorTarget in DZE_LockedStorage) then {
				if(_ownerID2 == dayz_combination || _ownerID2 == dayz_playerUID) then {
					_combi = player addAction [format[localize "STR_EPOCH_ACTIONS_OPEN",_text], "\z\addons\dayz_code\actions\vault_unlock.sqf",_cursorTarget, 0, false, true, "",""];
					s_player_combi set [count s_player_combi,_combi];
				} else {
					_combi = player addAction [format[localize "STR_EPOCH_ACTIONS_UNLOCK",_text], "\z\addons\dayz_code\actions\vault_combination_1.sqf",_cursorTarget, 0, false, true, "",""];
					s_player_combi set [count s_player_combi,_combi];
				};
				s_player_unlockvault = 1;
			} else {
				if(_ownerID2 != dayz_combination && _ownerID2 != dayz_playerUID) then {
					_combi = player addAction [localize "STR_EPOCH_ACTIONS_RECOMBO", "\z\addons\dayz_code\actions\vault_combination_1.sqf",_cursorTarget, 0, false, true, "",""];
					s_player_combi set [count s_player_combi,_combi];
					s_player_unlockvault = 1;
				};
			};
		};
	} else {
		{player removeAction _x} count s_player_combi;s_player_combi = [];
		s_player_unlockvault = -1;
	};

	//Allow owner to pack vault
	if(_typeOfCursorTarget in DZE_UnLockedStorage && _ownerID2 != "0" && (player distance _cursorTarget < 3)) then {

		if (s_player_lockvault < 0) then {
			if(_ownerID2 == dayz_combination || _ownerID2 == dayz_playerUID) then {
				s_player_lockvault = player addAction [format[localize "STR_EPOCH_ACTIONS_LOCK",_text], "\z\addons\dayz_code\actions\vault_lock.sqf",_cursorTarget, 0, false, true, "",""];
			};
		};
		if (s_player_packvault < 0 && (_ownerID2 == dayz_combination || _ownerID2 == dayz_playerUID)) then {
			s_player_packvault = player addAction [format["<t color='#ff0000'>%1</t>",(format[localize "STR_EPOCH_ACTIONS_PACK",_text])], "\z\addons\dayz_code\actions\vault_pack.sqf",_cursorTarget, 0, false, true, "",""];
		};
	} else {
		player removeAction s_player_packvault;
		s_player_packvault = -1;
		player removeAction s_player_lockvault;
		s_player_lockvault = -1;
	};

Now when someone dies, they are forced to re-enter the combination of the vault/lockbox.

 

so, that saves their id to it when they drop the safe, if they die they need to replace the safe to have "pid" unlock it seems

 

edit:: after testing, unless im missing something even if you fresh drop a safe, it doesnt save your pid as the combo

[cen]

I see so you want to keep the vault stuff based on characterID and without a persistant player owner.

 

Yep that would do it then.

 

Of course, if they forget the code then you could just tell the owner to pack and place the safe and they will get a new one.  Having to empty it first is the price for forgetting the code in the first place ;) .

 

They can't pack the safe if it's locked :D

 

But yes, in short the vault stuff needs to be based on CharacterID so that when they die (and receive a new CharacterID) it forces them to put in the code again.

 

Would like to see this as the default behavior since it's the way epoch does it, but I understand the approach you took since players are lazy :D

[cen]

so, that saves their id to it when they drop the safe, if they die they need to replace the safe to have "pid" unlock it seems

 

All I did was create a new variable (_ownerID2) that is tied to CharacterID instead of the new variable Rim created (ownerPUID)

 

What that means is that any time a safe is placed the "owner" doesn't need to enter the safe code to unlock it since it matches their characterID.

 

But if they die they get a new CharacterID so they are forced to re-enter the combination again.

[Buck0]

All I did was create a new variable (_ownerID2) that is tied to CharacterID instead of the new variable Rim created (ownerPUID)

 

What that means is that any time a safe is placed the "owner" doesn't need to enter the safe code to unlock it since it matches their characterID.

 

But if they die they get a new CharacterID so they are forced to re-enter the combination again.

 

hrms, i tried the change you made, it didn't seem to save the new character id and once locked, upon going to a second safe the first safe required a code again

 

i guess i messed up somewhere :P

[cen]

hrms, i tried the change you made, it didn't seem to save the new character id and once locked, upon going to a second safe the first safe required a code again

 

i guess i messed up somewhere :P

 

That's how it's intended to be. Once you unlock a different object (safe/lockbox) then you will need to re-enter the combination for the previous safe/lockbox.

[Buck0]

ohhh, i get ya cheers :P

[lowrey]

Err, none of those plot poles have an owner as far as this mod is concerned.  Which one was placed after the mod was installed ?.

 

 

Ok, so I set up a test server and started from scratch. Your Script and install worked without issue (no surprise there).

 

I then started adding other custom mods I use.

 

BINGO! I found the issue, it the snapping mod I’ve been using here:

 

[RELEASE] Build Snapping - Extended v1.6 (Updated 02/20/2014)

Link

 

Once I removed this mod your scripts worked again. Do you know why this may be breaking it? And is there a snapping mod you know that works with you scripts?

 

It’s 12 am here so I am gonna hit the sack. I’ll look over the snapping mod tomorrow to see if I can work it out.

 

Thanks so much for all your help and a great mod, your efforts and dedication do not go unnoticed!

 

Mike.

[RimBlock]

Ok, so I set up a test server and started from scratch. Your Script and install worked without issue (no surprise there).

 

I then started adding other custom mods I use.

 

BINGO! I found the issue, it the snapping mod I’ve been using here:

 

[RELEASE] Build Snapping - Extended v1.6 (Updated 02/20/2014)

Link

 

Once I removed this mod your scripts worked again. Do you know why this may be breaking it? And is there a snapping mod you know that works with you scripts?

 

It’s 12 am here so I am gonna hit the sack. I’ll look over the snapping mod tomorrow to see if I can work it out.

 

Thanks so much for all your help and a great mod, your efforts and dedication do not go unnoticed!

 

Mike.

 

 

Thanks Mike,

 

As I have just got this to a fairly stable state, I have not tried with any other mods yet, athough I have used the OtterNas3s version of snapping with the 1.1 version and found it to be very helpful. 

 

Raymix has just released his which allows most things to snap to each other (walls to floors, cinder to wood etc).  Looks good from the video so I will probably take a look at trying to get that working with this mod shortly.

 

Update: Reading through the thread, seems someone has got it working with A Plot for Life as well.

[McPimpin]

Ok, so I set up a test server and started from scratch. Your Script and install worked without issue (no surprise there).

 

I then started adding other custom mods I use.

 

BINGO! I found the issue, it the snapping mod I’ve been using here:

 

[RELEASE] Build Snapping - Extended v1.6 (Updated 02/20/2014)

Link

 

Once I removed this mod your scripts worked again. Do you know why this may be breaking it? And is there a snapping mod you know that works with you scripts?

 

It’s 12 am here so I am gonna hit the sack. I’ll look over the snapping mod tomorrow to see if I can work it out.

 

Thanks so much for all your help and a great mod, your efforts and dedication do not go unnoticed!

 

Mike.

There is a post in the that tells how to make it work. I think Pry posted a player_build.sqf that she modified that works.

[McPimpin]

Thanks Mike,

 

As I have just got this to a fairly stable state, I have not tried with any other mods yet, athough I have used the OtterNas3s version of snapping with the 1.1 version and found it to be very helpful. 

 

Raymix has just released his which allows most things to snap to each other (walls to floors, cinder to wood etc).  Looks good from the video so I will probably take a look at trying to get that working with this mod shortly.

 

Update: Reading through the thread, seems someone has got it working with A Plot for Life as well.

RimBlock,

 

I am haveing an issue with the plotpole on server restart.  if i place a plotpole i can remove it fine and build just fine.  If I restart the server It acts like its not mine and takes 1 of 6 and I cant build because it complains about needing a plotpole.

any Suggestions?

[RimBlock]

RimBlock,

 

I am haveing an issue with the plotpole on server restart.  if i place a plotpole i can remove it fine and build just fine.  If I restart the server It acts like its not mine and takes 1 of 6 and I cant build because it complains about needing a plotpole.

any Suggestions?

 

How about other items if you try to remove them or is it just the plot pole that does not see you as the owner for removal ?.

 

You are running v2.2.2 with the small manual fixes (see 1st post) ?.

[McPimpin]

How about other items if you try to remove them or is it just the plot pole that does not see you as the owner for removal ?.

 

You are running v2.2.2 with the small manual fixes (see 1st post) ?.

Yes the other objects act the same way, I have no remove option just upgrade.

Yes, I am running v2.2.2 but not sure about the fixes, will look into it.

 

Update: I checked and the fixes are in place with the same effect.

[cen]

Rim can you confirm a major bug for me.

 

If you unlock a door that is NOT yours (you don't own plot and are not tagged as friendly), you get the option to remove the lock from it.

 

Before you needed to have control of the plot pole (be owner) in order to remove locks.

 

I need to know if it's this mod or if it's my file edits.

[RimBlock]

Rim can you confirm a major bug for me.

 

If you unlock a door that is NOT yours (you don't own plot and are not tagged as friendly), you get the option to remove the lock from it.

 

Before you needed to have control of the plot pole (be owner) in order to remove locks.

 

I need to know if it's this mod or if it's my file edits.

 

Hi Cen,

 

It i is lunchtime here but will give it a try when I get home tonight.

 

Unlocking the door has no affect on ownership looking at the script. 

 

Looking at the code for fn_selfactions.sqf

// downgrade system
if((_isDestructable || _cursorTarget isKindOf "Land_DZE_WoodDoorLocked_Base" || _cursorTarget isKindOf "CinderWallDoorLocked_DZ_Base") && (DZE_Lock_Door == _ownerID)) then 
{
	if ((s_player_lastTarget select 1) != _cursorTarget) then {
		if (s_player_downgrade_build > 0) then {
			player removeAction s_player_downgrade_build;
			s_player_downgrade_build = -1;
		};
	};

	if (s_player_downgrade_build < 0) then {
		s_player_lastTarget set [1,_cursorTarget];
		s_player_downgrade_build = player addAction [format[localize "STR_EPOCH_ACTIONS_REMLOCK",_text], 
"\z\addons\dayz_code\actions\player_buildingDowngrade.sqf",_cursorTarget, -2, false, true, "",""];
	};
} else {
	player removeAction s_player_downgrade_build;
	s_player_downgrade_build = -1;
};

Seems it does not care who owns the object before allowing the downgrade option to appear (update: Just spotted the "DZE_Lock_Door == _ownerID". The ownerID is set as "_ownerID = _cursorTarget getVariable ["ownerPUID","0"];").  It really depends on how DZE_Lock_Door is being set.  Just checking through the code now.

 

Update 2:

Unlocking the door sets DZE_Lock_Door = "";.  Still should not create a match with the ownerPUID of the door though which reverts to 0 even if empty.

 

DZE_Lock_Door is not changed in fn_selfactions.sqf either.  It is just checked in there.