Jump to content

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


Recommended Posts

Have just thought of a way to align the playerUIDs of the buildables to the new system without changing the DB records.  Too late for me to implement tonight but will look at putting it in tomorrow with any bug fixes I can from those reported.

 

Note that this will not realign items from playerUID to SteamID.  Once I have a better idea of the getplayeroldUID I may be able to use that to do the job but it may slowdown for the first person to login as all the realigned items will need to be written back to the DB.  After the first realignment it will work as normal.  Will take a look at this tomorrow. 

Link to comment
Share on other sites

It should be fairly easy to tie ownership of buildables in plot range of the nearest plot pole to a targetted player or action activator.

 

The problem is making it persistant as most of the buildables are not re-saved to the DB after they are first placed and saved (excluding up / downgrades).  To make this persistant I would need to force an object swap DB call for each buildable item in range requiring an ownership change which would be quite heavy on internet and DB resources.

 

Maybe a staggered ownership change (1 item every 10 seconds or something).  Someone taking ownership of a big base with XXX parts will take some time but at least this way it will not kill the server for everyone.

 

Maybe an option for the plot pole owner to take ownership of all buildables within range from a plot pole action.  This action only appears if any buildables not owned are within range.  This would mean that the owner would need to place a new plot pole if changing from playerUID to SteamID but would be a much cleaner way of doing it.

 

Any other thoughts, concerns or views on this guys ?.

Link to comment
Share on other sites

I had a play around with the method FramendYannick posted here.

I just increased it to the last 9 digits of your steamid instead of 8 (thanks to Dami for pointing out that I could lol) to be that extra bit more secure.

It is working well with the building mods I am using.

 

Yeah, I saw the post on GitHub this morning.  A pretty good solution allowing the use of the characterID field to continue to be used to hold playerUIDs.  Using the 9 digits give you a million unique ids out of just under 2.15 billion possibles.  That should be pretty robust I would have thought.

 

Now I have done the work to move the unique id over to the worldspace field I am happy to leave it there.  The reason is that chopping up the uniqueid (be it PlayerUID with possible characters or the SteamID) and putting it in a numeric field designed for characterIDs and already being leveraged for keys and lockable codes is something I wanted to move away from anyway.  This SteamID issue has just forced my hand a little, but the move to using a nested variable in the Worldspace field allows me to store the full 17 digit SteamID and have plenty of space over for other enhancements  With it being a text field it is actually fairly easy (surprisingly so once I worked out and tested the technique) to nest more arrays in the end.  Car keys, door combos and safe codes could all have their own arrays rather than sharing the characterID field and having possible conflicts.  Of course this is all future designs and none is required but would be nice to have.  Once this is proved stable and the bugs are ironed out I may look at moving the key code etc and saving the characterID field just for characterIDs.  One other good point of doing this is that the code could also be setup to allow server owners to choose between the ownership being player or character based as both bits of information will coexist within the buildables record. 

 

If the post from Framend had gone up before last weekend I would have probably gone that way but I am happy to have gone the way I have now.

 

One issue that may come up though is for tagged friendly as there will be a limit on the number of friendly SteamIDs that can be stored in the currentstate character_date table if all 17 digits are being stored ;) .

Link to comment
Share on other sites

Update

 

Tested (ARMA II OA - 125548 with SteamID and Epoch 1.0.5);

Place plot pole.

Build cinder doorway.

Build metal floor.

Restart server - Items correctly saved to DB and persistent.

Remove metal floor.

Upgrade cinder wall.

Build tent.

Pack tent (only available after reboot - Need to check the code).

Upgrade garage doorway with lock

Unlock door

Lock door

Downgrade garage door (remove lock).

Safe build / open / lock / pack.

 

Safe locking and unlocking requires no code for the safe owner by default, only for third parties :D .

 

Basic testing complete.  Only a couple of paths found incorrect and fixed.  No other issues found.

Link to comment
Share on other sites

First full v2 release is now up.

 

Code is also on GitHub

 

See first post for both.

 

Please let me know of any issues.

 

I will update to Epoch 1.0.5.2 when it is released, which should be very soon.

 

I am also looking at any possibility of realigning playerUID to SteamID but am currently not sure if it will be possible.

Link to comment
Share on other sites

My players have begun building again under their new UID's. Is there a new SQL query that will align those items already built once I've added this back into my server?

 

I will have a look tomorrow at putting something together.

 

Presumably your situation is...

 

Player -> buildable is linked via characterID in the object_date.characterID field (i.e. standard way it is done) ?

Link to comment
Share on other sites

I will have a look tomorrow at putting something together.

 

Presumably your situation is...

 

Player -> buildable is linked via characterID in the object_date.characterID field (i.e. standard way it is done) ?

 

Yes. There probably are some items that were built under the old UID's too, but I just recently wiped the database so there probably aren't too many of those.

Link to comment
Share on other sites

I installed this on a fresh 1.0.5.1 build. I place a plotpole  and I cannot remove my plotpole without 1 of 6 tries and breaking my toolbox.

I cannot build after placing the plotpole.  I get cannot build without plotpole.

 

When you say you installed this on a 1.0.5.1 build, do you mean you took the 1.0.5 version and installed it on Epoch 1.0.5.1 as I do not have a 1.0.5.1 version (1.0.5.2 should be out very soo so will align the next update to that) or did you look at the changes I have made to the files and applied them to the 1.0.5.1 version of the files ?.

 

What are the characterID and worldspace values for the plot pole in the DB ?.

Link to comment
Share on other sites

When you say you installed this on a 1.0.5.1 build, do you mean you took the 1.0.5 version and installed it on Epoch 1.0.5.1 as I do not have a 1.0.5.1 version (1.0.5.2 should be out very soo so will align the next update to that) or did you look at the changes I have made to the files and applied them to the 1.0.5.1 version of the files ?.

 

What are the characterID and worldspace values for the plot pole in the DB ?.

 

 

I am using DayZ_Epoch_Server_1.0.5.1_Release

I then installed your mod from this post. Version 2

Does it not work with this version?

 

e97s.png

34	76561198084911985	11	2014-07-02 21:56:31	2014-07-02 22:01:19	[["ItemFlashlight","ItemGPS","ItemCrowbar","ItemEtool","ItemToolbox"],["ItemPainkiller","30m_plot_kit","ItemVault","ItemBandage"]]	["DZ_Patrol_Pack_EP1",[[],[]],[[],[]]]	[116,[2189.88,14163.7,0.002]]	[false,false,false,false,false,false,false,12000,[],[0,0],0,[34.535,21.29]]	1	1	2014-07-02 21:56:31	2014-07-02 21:56:31	0	0	38692	2	["","aidlpercmstpsnonwnondnon_player_idlesteady03",37,[]]	0	Survivor2_DZ	0	2500	0

Link to comment
Share on other sites

 

I am using DayZ_Epoch_Server_1.0.5.1_Release

I then installed your mod from this post. Version 2

Does it not work with this version?

34	76561198084911985	11	2014-07-02 21:56:31	2014-07-02 22:01:19	[["ItemFlashlight","ItemGPS","ItemCrowbar","ItemEtool","ItemToolbox"],["ItemPainkiller","30m_plot_kit","ItemVault","ItemBandage"]]	["DZ_Patrol_Pack_EP1",[[],[]],[[],[]]]	[116,[2189.88,14163.7,0.002]]	[false,false,false,false,false,false,false,12000,[],[0,0],0,[34.535,21.29]]	1	1	2014-07-02 21:56:31	2014-07-02 21:56:31	0	0	38692	2	["","aidlpercmstpsnonwnondnon_player_idlesteady03",37,[]]	0	Survivor2_DZ	0	2500	0

 

Not tested on on 1.0.5.1 as I started coding this on 1.0.5 and then a day or so later 1.0.5.1 came out and 1.0.5.2 is due any day now so better to change to 1.0.5.2 as by the time I have changed it for 1.0.5.1 it is likey not the current version.

 

I tried to highlight the fact it was for 1.0.5 in the file name and in the release history

 

Plot for Life v2 (DZE 1.0.5) - Release.

 

V2 (ARMA II OA 125548 with SteamID - Epoch 1.0.5)

 

Sorry, I was not clear.  I meant the characterID and Worldspace variables for the plot pole you placed but could not build with in the object_data table of the DB.  Post the whole line if easier.

Link to comment
Share on other sites

Not tested on on 1.0.5.1 as I started coding this on 1.0.5 and then a day or so later 1.0.5.1 came out and 1.0.5.2 is due any day now so better to change to 1.0.5.2 as by the time I have changed it for 1.0.5.1 it is likey not the current version.

 

I tried to highlight the fact it was for 1.0.5 in the file name and in the release history

 

Plot for Life v2 (DZE 1.0.5) - Release.

 

V2 (ARMA II OA 125548 with SteamID - Epoch 1.0.5)

 

Sorry, I was not clear.  I meant the characterID and Worldspace variables for the plot pole you placed but could not build with in the object_data table of the DB.  Post the whole line is easier.

 

Sorry.. How do i get what your looking for?  do you need a screenshot of my character_data mysql tables? ohh object_data one sec

Link to comment
Share on other sites

Is this what you need?

ix2u.png

 

d71w.png

 

Probably, where you are hosting is blocked where I work but have taken a quick look on my phone ;) .

 

The first screens shot and the last one are of the plot pole.  What did you do in between that caused the record to change ?.  The second one looks good.  Your playerUID (the SteamID) is now saved in the worldspace field.

Link to comment
Share on other sites

Am I missing something or are the installation instructions missing from the download? I'm not finding anything here on the post or on the Git either. I would love to try it but...

 

Bao

 

My bad.  The install is super easy if you do not have any other mods installed.

 

I have added install instructions at the top (just extract the zip file to the right directory and then play).

Link to comment
Share on other sites

Probably, where you are hosting is blocked where I work but have taken a quick look on my phone ;) .

 

The first screens shot and the last one are of the plot pole.  What did you do in between that caused the record to change ?.  The second one looks good.  Your playerUID (the SteamID) is now saved in the worldspace field.

I didn't do anything but drag the column to the right to make it larger so that the entire worldspace was viewable for the screenshot.

Link to comment
Share on other sites

Ok, so the first and last screenshot of the object_data plot pole entry is the same but the last one has the fields expanded.  May be worth taking the first one out then :) .

 

Anyhow, the data is correct in the DB by the looks of it so it is saving the buildables fine but it would appear the check for ownership of the closest plot pole may be having difficulties. 

 

Have a look at the player_build.sqf in the custom/PlotForLifev2 directory.

 

Look around the 150 line position for something like the following (it will be different as this is the original Epoch code as I cannot download my mod from where I am at the moment)

// check nearby plots ownership && then for friend status
_nearestPole = _findNearestPole select 0;

// Find owner
_ownerID = _nearestPole getVariable ["CharacterID","0"];

// diag_log format["DEBUG BUILDING: %1 = %2", dayz_characterID, _ownerID];

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

Post back what that actual code is in that file on your server please.

Link to comment
Share on other sites

Ok, so the first and last screenshot of the object_data plot pole entry is the same but the last one has the fields expanded.  May be worth taking the first one out then :) .

 

Anyhow, the data is correct in the DB by the looks of it so it is saving the buildables fine but it would appear the check for ownership of the closest plot pole may be having difficulties. 

 

Have a look at the player_build.sqf in the custom/PlotForLifev2 directory.

 

Look around the 150 line position for something like the following (it will be different as this is the original Epoch code as I cannot download my mod from where I am at the moment)

// check nearby plots ownership && then for friend status
_nearestPole = _findNearestPole select 0;

// Find owner
_ownerID = _nearestPole getVariable ["CharacterID","0"];

// diag_log format["DEBUG BUILDING: %1 = %2", dayz_characterID, _ownerID];

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

Post back what that actual code is in that file on your server please.

Here is what i have.

// check nearby plots ownership && then for friend status
	_nearestPole = _findNearestPole select 0;

	// Find owner
	_ownerID = _nearestPole getVariable ["ownerPUID","0"];

	// diag_log format["DEBUG BUILDING: %1 = %2", dayz_characterID, _ownerID];

	// check if friendly to owner
	if(_playerUID == _ownerID) then {  //Keep ownership
Link to comment
Share on other sites

Ok, the code looks like the latest version and nothing is jumping out at me.

 

Plot Pole is saving to the DB correctly.

Code to check owner is as expected (there was a slight change between the BETA and Release in that code block).

Only other thing would be population of the plot pole [objectPUID] variable but I would need some diag_log lines to report the values to check that.

 

Anything in the client RPT file (usually something like c:\users\[Windows account]\local\appdata\ARMA2OA).

Link to comment
Share on other sites

Issue confirmed.  

 

Just checking the code now.

 

Found a bug that stopped you building after placing a plot pole until the server rebooted: Fixed.

Looking at not being able to remove items:  False alarm.  My character had no crowbar  :lol: .

 

Just rezipping.

 

Also did a diffmerge and the only file with any differences from 1.0.5.1 was the server_monitor.sqf which I have now brought up to date so this version is for Epoch 1.0.5.1.

 

First post updated.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...