Stop replacing plot poles when we die

[AngelEyes_666]

Its very annoying. Its pointless cause, even when we arrive at base after respawn, we usually can easily replace it if we have the means. Its not like making us replace it even does anything, its just a time consuming inconvenience. Why do we have this? If its important, are there other options besides this we can adopt instead?

[Sandbird]

Tweak the script to instead of using CharacterID to use CharacterUID.....so its always 'true'...even if the player dies and his characterID changes...it doesnt matter....It will be based on his fixed characterUID.

[GhostTown]

Where and what script do we change this at?

[Achmed]

I'm sure there is a post on the forum about it already somewhere

[Tobias Solem]

I'm sure there is a post on the forum about it already somewhere

 

Not really, there however are solutions implemented on some servers for this. Just not publically available code.

[fr1nk]

I think the next best thing to attaching plot poles to player ID is transferring ownership across character death.

 

Nasdero wrote a SQL trigger for this:

 

[Sandbird]

i'll give you an example...open your fn_self_actions.sqf

Search for : dayz_characterID, and here are mine
 

_ownerID = _cursorTarget getVariable ["CharacterID","0"];
.......
if(_isModular and (dayz_playerUID == _ownerID)) then {  // dayz_characterID
if (_ownerID == dayz_playerUID) then {    //Change dayz_characterID to dayz_playerUID for perma owner

These are just a few....basically you have to search each major file for dayz_characterID and change it to dayz_playerUID.

 

From my player_upgrade.sqf (for upgrading modular buildings)

	// check if friendly to owner
	if(dayz_playerUID == _ownerID) then { //dayz_characterID

From player_packTent.sqf

if(_ownerID != dayz_playerUID) exitWith {DZE_ActionInProgress = false; s_player_packtent = -1; cutText [localize "str_fail_tent_pack", "PLAIN DOWN"];}; //dayz_characterID

you get what i mean right?

Its a painful thing....and all together you gotta make 20-35 changes of that value....its custom for every server so cant really help you further...I had to painfully test every singe function on the server that i changed.....but after that smooth as hell.

I did it for everything: basebuilding, upgrades, downgrades, removals, fn_selfactions, pack tent

[GhostTown]

i'll give you an example...open your fn_self_actions.sqf

Search for : dayz_characterID, and here are mine

 

_ownerID = _cursorTarget getVariable ["CharacterID","0"];
.......
if(_isModular and (dayz_playerUID == _ownerID)) then {  // dayz_characterID
if (_ownerID == dayz_playerUID) then {    //Change dayz_characterID to dayz_playerUID for perma owner

These are just a few....basically you have to search each major file for dayz_characterID and change it to dayz_playerUID.

 

From my player_upgrade.sqf (for upgrading modular buildings)

	// check if friendly to owner
	if(dayz_playerUID == _ownerID) then { //dayz_characterID

From player_packTent.sqf

if(_ownerID != dayz_playerUID) exitWith {DZE_ActionInProgress = false; s_player_packtent = -1; cutText [localize "str_fail_tent_pack", "PLAIN DOWN"];}; //dayz_characterID

you get what i mean right?

Its a painful thing....and all together you gotta make 20-35 changes of that value....its custom for every server so cant really help you further...I had to painfully test every singe function on the server that i changed.....but after that smooth as hell.

I did it for everything: basebuilding, upgrades, downgrades, removals, fn_selfactions, pack tent

My head hurts already.

[Sandbird]

My head hurts already.

 

Change dayz_characterID to dayz_playerUID, how hard is that seriously.

[GhostTown]

Change dayz_characterID to dayz_playerUID, how hard is that seriously.

I was joking lol

and I just dont really know what all files I should look in.

[Sandbird]

Just get Notepad++ and search for dayz_characterID in your folder of your mission.pbo...should find like 20-30 occurrences. Grab one file (for example anything that has to do with remove) and change the values to dayz_playerUID, and test it....and move on to the next one....just grab an action and test it ...dont just mass replace everything.

For online debugging when it come with stuff like that, this is what i do.

Make an .sqf file in your root mission folder called admins.sqf.

Inside add your UID like this:
["133333138"];

 

Then on top your fn_self_actions.sqf add this line 

_adminPlayer = call compile preProcessFileLineNumbers "admins.sqf";

Search for : // Allow Owner to lock and unlock vehicle

and above it add :

    if((typeOf(cursortarget) == "Plastic_Pole_EP1_DZ") and (player distance _cursorTarget < 3)) then {
        if ((getPlayerUID player) in _adminPlayer) then {
            cutText [format["Plot Pole Owner PUID is: %1",_ownerID], "PLAIN DOWN"];
        };
    };

like i said my _ownerID value is :   _ownerID = _cursorTarget getVariable ["CharacterID","0"];

 

This way when you are inside the game and you look at a plot pole it will give you the owner's UID.

Helps alot when people claim, thats their base and try to get an admin to remove the plot pole :P

 

But yeah...everything based on the UID is making life easier....worth the trouble really.

[BetterDeadThanZed]

Its very annoying. Its pointless cause, even when we arrive at base after respawn, we usually can easily replace it if we have the means. Its not like making us replace it even does anything, its just a time consuming inconvenience. Why do we have this? If its important, are there other options besides this we can adopt instead?

[RimBlock]

Whilst changing the buildables linkage to playerUID rather then characterID is possible (I have just released a mod to do it ), there are potential issues.

 

From my mod info

Warning - Limitations.
1. This solution has a limitation, the same as all solutions I have seen to deal with this issue.  The unique player id (playerUID) which you can think of as your game serial number can be linked to multiple characterIDs.  If you die, your characterID changes and your playerUID is linked to it.  The limitation comes about because the PlayerUID is stored as a text field (numbers with possible text) and the characterID is stored in a number field with a limitation of a max number of 2147483647 (unsigned).  There may be a small possibility than any solution using the playerIUD to substitute the characterID may possibly hit this limiting number.  If this occurs you will get an 1264 - Out of Range DB error.


2.  In some cases, the playerUID is now being generated with letters included.  Due to this the mod converts these letters to the number 9 (one for each letter).  There is a slim possibility that this will not result in a unique number.

In my view the object_data table is now quite limiting and I would prefer to see and object_data table along with a ownership table and am object type table.  The ownership table could deal with who owns the object with options for palyerUID or characterIDs, the object_type table could hold the type of object (eg. buildable, magazine, vehicle etc) so you could quickly reference and update all buildables or all vehicles and leave the rest alone.

 

The problem is that this would then stray further from the main DayZ hive structure and make any DayZ updates harder to integrate in to Epoch.

 

A stopgap measure could be to convert characterID from unsigned int to bigint allowing a much larger number and a bit of room to build unique ids from converted playerUIDs.

 

RB

[Mercules]

 Also, removing plot poles IS hard to do. You end up breaking multiple toolboxes and crowbars and even then you might not succeed.

 

That certainly isn't true. Most of the time nothing breaks and when it does it is typically one broken tool, unless I am beating the odds over and over and over.

[TheFarix]

That certainly isn't true. Most of the time nothing breaks and when it does it is typically one broken tool, unless I am beating the odds over and over and over.

 

There is a 47% change of breaking a took during an attempt to pull up a plot pole, so you probably are beating the odds.

[RimBlock]

There is a 47% change of breaking a took during an attempt to pull up a plot pole, so you probably are beating the odds.

 

Would be interested to know how you worked that out.

 

The logic I have is that there is a 10% chance of tool breakage per stage.  

 

Each item has 3 stages unless redefined by the DZE_StaticConstructionCount variable.

 

If you own the item or are friendly then you have the original number of stages to remove.  

 

If not then the number of stages doubles (i.e. 6 by default).

 

Ref: removes.sqf - no version number in the file.  Modes can change the rules so all bets are off then.

[TheFarix]

10% change to break a tool each stage means 90% success rate per stage.

Since you frequently pull up the plot poll after you die, you have to go through 6 stages to pull one up

So the success rate goes like this:

First stage: 90% (100 * 90%)

Second stage: 81% (90 * 90%)

Third stage: 72.9% (81 * 90%)

Fourth stage: 65.61% (72.9 * 90%)

Fifth stage: 59.049% (65.61 * 90%)

Sixth stage: 53.1441% (59.049 * 90%)

That gives you an approximate 53% success rate, which means that the failure rate is 47%.

[Cramps2]

I think the point is being missed from the OP.

 

None of the players I've met like the current mechanic, every single one of them would prefer vanilla epoch to have plot pole ownership span player deaths.  That's why the post was put in feedback, not any of the scripting channels.

 

I agree, and I'm sure plenty of people would be happy to +1 this idea.  But it's not our mod - this is merely feedback :D

[RimBlock]

10% change to break a tool each stage means 90% success rate per stage.

Since you frequently pull up the plot poll after you die, you have to go through 6 stages to pull one up

So the success rate goes like this:

First stage: 90% (100 * 90%)

Second stage: 81% (90 * 90%)

Third stage: 72.9% (81 * 90%)

Fourth stage: 65.61% (72.9 * 90%)

Fifth stage: 59.049% (65.61 * 90%)

Sixth stage: 53.1441% (59.049 * 90%)

That gives you an approximate 53% success rate, which means that the failure rate is 47%.

 

Thanks,

 

Been a long time since I have played around with distribution.

 

Found a binominal online calc though   :) .

 

RB

[RimBlock]

I think the point is being missed from the OP.

 

None of the players I've met like the current mechanic, every single one of them would prefer vanilla epoch to have plot pole ownership span player deaths.  That's why the post was put in feedback, not any of the scripting channels.

 

I agree, and I'm sure plenty of people would be happy to +1 this idea.  But it's not our mod - this is merely feedback :D

 

Sure and if there was enough recorded (following, thanks, views etc) of the Plot Pole mods then it may give an indication to the developers of the popularity and they may then put some work in to it.

 

Putting the PlayerUID in place of the CharacterUID with the current structure of the hive is not a great idea long term for the reasons I have posted and, however much I like the idea, If I was building the Epoch mod then I would prefer not to touch it.  I would look at a redesign of the hive to better suit the purpose as people are trying to shoehorn a lot of functionality in to the the object_data table whose structure was not designed for it.

 

A simple example is that you can not tag cars or safes to players.  If you have the combination / key then you can make off with them.  This may seem reasonable but you cannot then work out which safes / cars etc belong to which player which limits the possibilities where as a hive redesign would expand on them but would be a lot of work.

 

Potentially you could create an object_data_extended table and link back to the object_data table via objectID.  The Epoch team have added the trader tables to the hive so there is a precedent but it would need to be well planned to avoid the need to keep adding new fields to it.

 

The second course is that DayZ was intended to be a "Die and you loose it all" type game and tying the player rather than the character to the plot pole breaks that underlying fundamental concept.

 

You are right though, this is just feedback and ultimately it is up to the dev team to decide on what features they are prepared and able to give the community build up around it.

 

RB