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

[RimBlock]

Hi,

 

All fixes are included in the instructions on the first post so you should not have to apply any others. 

 

The instructions in the first post work fine if applied to a Epoch 1.0.4.2 server with no other mods installed.  Other mods may cause conflicts depending on how they are programmed.  I cannot verify this mod with all other mods out there but I am happy to try and help you get it working with whatever else you may have installed if I have the details I need to do so.

 

Do you have any other mods installed ?.

In what way does it not work, what does not happen that should after you tag each other ?.

 

RB

[VentZer0]

I realized that, when I installed everything I did everything by the numbers from the OP.
I have lots of other mods installed, but only that uses tag friendly in any way, which is the Radiocommunication mod.

When I try to tag anyone, nothing happens, thats it. I get the option but nothing happens when we tag eachother, building on other friendly plotpoles doesnt work either it seems.

[RimBlock]

Does a message come up about someone wanting to tag you for the other player when you tag them ?.  Does it come up when they tag you ?.

 

What is the value in the currentstate field of the character_data table for your character and the other persons character in the database.

 

When you tag each other, nothing actually happens apart from a message coming up about you tagging and waiting for them to accept (and vice versa when they try to tag).

 

Did you run the SQL to realign all the historical owner ids for buildables in the DB ?.

 

What is the characterID columns vale for the plot pole the friendly is trying to build by ?.

 

Does the radiocom mod touch the player_tagfriendly.sqf file and if so what does that .sqf file now look like ?.

 

If you login and are friendly to the plot poles owner but the owner is not there you will not be able to build on their plot.  There is (vanilla Epoch) code int he fn_damageactions.sqf that means you need to look at the friendly owner before you can build on their plot each time you login.  This value that is set when you look at them (_friendlyto) is not saved when you logout.  I guess this is to make sure the owner is around before you can build on their plot as a safeguard to friendlies going crazy and building stuff everywhere without the owner knowledge.  This functionality is standard Epoch and not added as part of my mod though. 

[Rob E]

Item 4:

 

Change to

fnc_usec_selfActions = compile preprocessFileLineNumbers "compile\ConvertpUID\fn_selfActions.sqf"; //Checks which actions for self

 

Is the Path supposed to be "custom\ConvertpUID\fn_selfActions.sqf";   ?

[RimBlock]

 

Item 4:

 

Change to

fnc_usec_selfActions = compile preprocessFileLineNumbers "compile\ConvertpUID\fn_selfActions.sqf"; //Checks which actions for self

 

Is the Path supposed to be "custom\ConvertpUID\fn_selfActions.sqf";   ?

 

 

Yep it should be.  Not sure how that is still incorrect but regardless I have now changed it.

 

Thanks

[ReDBaroN]

One quick question before I install this mod. I saw this brought up earlier in the thread but, couldn't see the definitive answer....

Will tagged friends be friends after death? I know death currently resets tags so I'm just a bit worried about traitors wreaking havoc.

I would really love to get this installed on my server to finally close down all the 'admin delete' calls' and may even still do it anyway...

[RimBlock]

Yes... and no...  :) .

 

post last paragraph.

 

Short and sweet version...

 

Yes players will still be tagged friendly as the playerUID is saved in the DB.  Anything non-vanilla Epoch that uses the tag friendly system would need a small amendment to work (see post as an example).

 

The reason I say no is because as standard in Epoch, even if you are tagged friendly, you need to look at the plot owner to be able to build on their plot each time you login as the friendly playerUIDs are moved to a friendlyTo variable when friendlies look at each other and this friendlyTo variable is used for the building system.  The friendlyTo variable is also not persistant (not saved in the DB).  The variable only needs to be set once per login (look at the owner you are friendly to and you can build on their plot until you log out).

 

This would be easy to change but it is put there by the Epoch team, I presume, to stop manic building if the plot owner is not around when a friendly logs in.  Once I put in a "remove friendly" option, it would most likely be safe to remove the friendlyTo check.. 

[oOSmokyOo]

Very Nice Work, it works perfect.

 

Thumbs up  ;)

[ReDBaroN]

Thanks Rimblock, this will be my next mission as soon as I have cleared down some final errors kicked up by upgrading to arma 1.63.112555.

[RimBlock]

Thanks guys.

 

Seems pretty stable now the bugs in the code and release instructions are all worked out.

 

I am just wrangling with GitHub at the moment and will probably make it availabe there (and then finally get round to putting it n a zip file for new builders).

 

The Better Refueling stuff is a bit of a beast to get working at the moment (lots of possible combinations to deal with) and is taking up the majority of my time.

[justchil]

I have a dumb question I'm pretty sure I already know the answer to...

This would allow players to be able to remove items such as concrete walls and such since it remains tied to their playerUID instead of characterID correct?

[RimBlock]

I have a dumb question I'm pretty sure I already know the answer to...

This would allow players to be able to remove items such as concrete walls and such since it remains tied to their playerUID instead of characterID correct?

 

Anything that is usually removable before the mod will be removable after the mod by the player (rather than by the character pre mod) or a tagged friendly after they both have looked at each other at least once since login.

 

Themod just changes the reference used (PlayerUID rather than CharacterID) but not any of the other functionality.

[justchil]

Seems to work well.  Pretty much everyone on my server is now saying codes to doors and such no longer work D:

 

Rolled back the SQL I'll be happy with buildings from this point forward having this feature.  I think it has something to do with not keeping dead players maybe.  It set about 700-800 objects to new objectID (out of 8000).  I don't think you'd want to set them on things with keys/codes though.

[RimBlock]

What is the highest characterid in your db ?

Do you clear out the character_data table to free up new characterids ?.

How many doors have codes lower than the highest characterid ?.

I can see how the historical realignment may cause issues with door locks on a server with a large player base. Safes would be more tricky to affect. They use 4 digits so having a live player with a characterid that also matches a safe combo should be unlikely.

The realignment matches object_data characterids with valid player characterids. This would indicate you have some overlap.

I will amend the sql to exclude a few classes for lockables, test and then post it up. Should be a quick fix.

[justchil]

Highest CharID is: 23198

 

I run this EVENT every 5 days:

 

DELETE FROM `character_data`

USING character_data, character_data AS tmpcharacter_data

WHERE NOT character_data.CharacterID=tmpcharacter_data.CharacterID

AND character_data.CharacterID<tmpcharacter_data.CharacterID

AND (character_data.PlayerUID=tmpcharacter_data.PlayerUID);

 

I ran:

 

SELECT * FROM `object_data` 

where classname like '%doorlocked%'

and objectID < '23198'

 

16 results.

 

Just in case this is what you wanted (no coffee yet)

 

SELECT * FROM `object_data` 

where classname like '%doorlocked%'

and characterID < '23198'

 

113 results (all of them)

 

 

Please let me know if there is anything further I can provide.  My server is pretty busy and high PVP.  Players are fairly understanding but they would raise hell if I deleted bases / completely wiped profiles.  If all else fails they are fine with "everything going forward" will be bound by playerUID.   

 

Cheers for the mod it is working great :)

[RimBlock]

THanks for the info,

 

Can you please also check for the "VaultStorageLocked" as safes use 4 digi codes and so will most likely be affected.

 

The sql you are using to clear down I am trying to understand.  It would help to know what you want to keep in the character_data table.

 

DELETE FROM `character_data`

USING character_data, character_data AS tmpcharacter_data

WHERE NOT character_data.CharacterID=tmpcharacter_data.CharacterID  --> Where characterid is not the same as the temp copy characterid

AND character_data.CharacterID<tmpcharacter_data.CharacterID  --> Where characterid is less than the temp copy characterid (This would also satisfy the above clause as well). 

AND (character_data.PlayerUID=tmpcharacter_data.PlayerUID); --> Where the playerUID linked to the characterID is the same as the temp copy PlayerUID.

 

My guess is that you want to keep the most recent characterid for each playerUID and delete the rest. 

 

One issue would be that you are not concerned if the characterID is alive or not so if you free up some characterIDs and ARMA II starts reusing them then your housekeeping will delete them as thay are not the highest characterID related to a playerUID.

 

If this is the case then I would be tempted to (not actual code, just a concept as I have no MySQL to test on where I currently am).  <-- code now tested and should work.

delete from character_data
using character_data, (select playerUID, characterid, max(last_updated) from 
character_data group by playerUID) as temp_character_data
where character_data.playerUID = temp_character_data.playerUID 
and character_data.characterID <> temp_character_data.characterid;

That should delete all but the most recent characterID for each playerUID.

 

You could run the code below to give an idea of the items that would be deleted.

select *
from character_data, (select playerUID, characterid, max(last_updated) from character_data group by playerUID) as temp_character_data
where character_data.playerUID = temp_character_data.playerUID
and character_data.characterID <> temp_character_data.characterid;

Run the following to give an idea of what will be kept.

select playerUID, characterid, max(last_updated) 
from character_data 
group by playerUID;

I would be interested to know how many accounts are selected with the above query.

 

It may be worth thinking about how long to keep a players account available or a player who joined one time and never comes back will always have their account in your DB.  3 month or 6 month old may be good benchmarks.

 

I don't have the volume of user records to play with large numbers of character records as I am not running a public server but I should get my GBit line around the 21st June and will probably put a test server up then to gather some 'wild' data and letting people join in with the mod testing when they are ready for beta.

 

Glad the rest is working well for you and your players :) . 

[cen]

There is no playerUID column in the database. Those SQL queries throw syntax errors.

[RimBlock]

Did you read 

 

If this is the case then I would be tempted to (not actual code, just a concept as I have no MySQL to test on where I currently am).

 

 

Ok, I have given it a quick run and apart from the fact that lastupdated should be last_updated and object_data should be character_data (been working a lot with object_data table for my current WIP mod so I blame muscle memory) it was actually pretty good as it was from memory with no ref to the db tables and fields available when I wrote it  ;) .

 

Above code amended now.  

[oOSmokyOo]

Hello everybody, i have a little problem.

 

For example: When i build a Wall, i cant upgrade the Wall. The following Message displayed InGame: Unable to build plotpole is nerby. But why? Its my pole...

 

When i remove the pole then i can upgrade the Wall but not build another Wall.

 

Anyone an idea what i make wrong in the Installation? 

[Pro_Speedy]

Not sure if this related, but since i added this my Evac chopper no longer works it seems to work the first time but stops working

 

May this be related to the Evac getting the CharacterID?

[RimBlock]

Not sure if this related, but since i added this my Evac chopper no longer works it seems to work the first time but stops working

 

May this be related to the Evac getting the CharacterID?

Most likely. Whilst I can not ensure this will work with all mods out there I will try to help.

If you can find out where it is getting the characterid and why then I can try to suggest some options.

[RimBlock]

Hello everybody, i have a little problem.

 

For example: When i build a Wall, i cant upgrade the Wall. The following Message displayed InGame: Unable to build plotpole is nerby. But why? Its my pole...

 

When i remove the pole then i can upgrade the Wall but not build another Wall.

 

Anyone an idea what i make wrong in the Installation?

Will have a look at the code tomorrow to see if I can give you a few places to look.

[Mugzy]

Not sure if this related, but since i added this my Evac chopper no longer works it seems to work the first time but stops working

 

May this be related to the Evac getting the CharacterID?

 

I have the same issue with EVAC choppers and we are not running this mod yet.  On our server it works till the person has died, then it does not work anymore.

[oOSmokyOo]

Will have a look at the code tomorrow to see if I can give you a few places to look.

 

Thanks for your answer, i have found the problem. 

 

It was my mistake. ;)

[Pro_Speedy]

I have the same issue with EVAC choppers and we are not running this mod yet.  On our server it works till the person has died, then it does not work anymore.

 

Please let me know if you find a sloution