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

[RimBlock]

Ok, putting in an idea for a change to the buildables placement mechanics.

 

Problem.

People being able to build flying bases.

Buildables dissapear if the builder moves more than 5mtrs from the starting build point.

Buildables not accurately getting position (still using [get/set]PosATL rather than FNC_GetPos and FNC_GetSetPos (the latter works correctly over sea and terrain).

 

Solution.

Buildable location will be measured from the plot pole to plot max size / 2 to calculate max distance before building is aborted.

Buildables cannot be built more than 45 mtrs above the ground / sea.

Change all legacy calls to newer FNC calls for positioning.

 

Results.

You should be able to start building and then walk around the whole plot (if so desired) without the buildable vanishing.

Buildables can only be up to a defined height (will be a global variable which is user overridable)

Building over water should work a bit better.

 

I will also look at putting in the local plot radius (proposed by f3cuk) at the same time.

 

Any comments or concerns then please shout out now.

[ReDBaroN]

Ok, putting in an idea for a change to the buildables placement mechanics.

 

Problem.

People being able to build flying bases.

Buildables dissapear if the builder moves more than 5mtrs from the starting build point.

Buildables not accurately getting position (still using [get/set]PosATL rather than FNC_GetPos and FNC_GetSetPos (the latter works correctly over sea and terrain).

 

Solution.

Buildable location will be measured from the plot pole to plot max size / 2 to calculate max distance before building is aborted.

Buildables cannot be built more than 45 mtrs above the ground / sea.

Change all legacy calls to newer FNC calls for positioning.

 

Results.

You should be able to start building and then walk around the whole plot (if so desired) without the buildable vanishing.

Buildables can only be up to a defined height (will be a global variable which is user overridable)

Building over water should work a bit better.

 

I will also look at putting in the local plot radius (proposed by f3cuk) at the same time.

 

Any comments or concerns then please shout out now.

Here's just a couple of questions off the top of my head:

• Some people like those flying bases, personally I don't like them as they're unrealistic and look naff but, I guess the variable would cover that as an option?
• I'm worried about lag on increasing the range of being able to build. I know with Build Snap Pro, Raymix put some notes that you can increase the range to build but, be careful as can lag. I'm not a coder, so maybe your way of doing it won't lag but, would need some reassurances there...?
• Currently some of my players, to exploit the distance to plot pole a little, will start the build at the very edge of the plot range and then walk the object out the extra 5m (or I thought it was 10m...?). So, how would this work with your proposal? Would this stop that, still allow it or, allow them to walk the object out further?

[ReDBaroN]

Ok, to drill down a bit on what appears to be working and what does not.

 

Old bases & Old friendly

Take ownership of base

Friendly cannot build before server reboot: Y/N

Friendly cannot build after server reboot: Y/N

 

Old bases & New friendly (post A Plot for Life install)

Take ownership of base

Friendly cannot build before server reboot: Y/N

Friendly cannot build after server reboot: Y/N

 

----

 

New bases (built post A Plot for Life install) & Old friendly

Take ownership of base

Friendly cannot build before server reboot: Y/N

Friendly cannot build after server reboot: Y/N

 

New bases (built post A Plot for Life install) & New friendly (post A Plot for Life install)

Take ownership of base

Friendly cannot build before server reboot: Y/N

Friendly cannot build after server reboot: Y/N

 

----

 

Own bases & New friendly (post A Plot for Life install)

Already owned base

Friendly cannot build before server reboot: Y/N

Friendly cannot build after server reboot: Y/N

 

Own bases & Old friendly

Already owned base

Friendly cannot build before server reboot: Y/N

Friendly cannot build after server reboot: Y/N

Thanks RimBlock, will grab one of my admin team and get these test results back to you soon as poss.

[RimBlock]

The proposal will not increase range 9 building but will correctly enforce it. Building range will be measured from the plot pole and not from the player's starting position so there would be no building range extension.

I guess it should be pretty easy to optionise it.

[Triage]

IS there a way to have more then one variables.sqf? Because I have one right now and if I overwrite it will break a lot of scripts.

[fr1nk]

Just use a text editor like DiffMerge and combine the two.

[Triage]

Thanks fr1nk, this program is really helpful.

[ReDBaroN]

RimBlock, just a quick update on our tests....they're looking a lot better for some reason which is good.... :)

 

We seem to now be unable to recreate the friendly not being able to build since yesterday early afternoon UK time. If we can reproduce it we'll post again here. I don't know why or how our results are coming in differently as the only change was a fresh drop of the live db into test but, all in all it appears to be working as expected currently. If we can recreate an issues again, we'll let you know.

 

One problem we are trying to nail down though is a random deletion of walls that have been newly built and not within 5 mins of server restart. We don't know of this happening in normal Epoch 1051 but are still running some tests to try and see if we can get a reproducible scenario. For now all we know is that it only seems to happen after restart on new bases built in the last restart cycle. In one test 3 out of 5 walls were deleted, in another 1 out of 35.... we are also trying to reproduce on our live server but, that slows us down a bit however, we haven't got it to happen there yet.

 

Sorry for being vague at the moment.....

 

Anyone else experiencing walls deleting on freshly built bases after a server restart?

[RimBlock]

Good to hear.  I have also seen issues disappear with a DB refresh.

 

For the vanishing buildables, you could add a trigger to the object_data table to log any deletions.  You will need to housekeep it as it will grow quickly but it will show what was deleted when and may give some insight as to any common features of the rows being deleted.

 

Save the following code in to a file and run it with your SQL client against a test DB  :) .  It should create a new table called object_audit and a new MySQL server event which will housekeep the object_audit table deleting anything older than 1 day (you can change this in the sql).

-- Audit table

DROP TABLE IF EXISTS `object_audit`;

CREATE TABLE IF NOT EXISTS `object_audit` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `tstamp` datetime, 
  `action` varchar(3),
  `ObjectID` int(11),
  `ObjectUID` bigint(24),
  `Instance` int(11),
  `Classname` varchar(50),
  `Datestamp` datetime,
  `LastUpdated` timestamp,
  `CharacterID` int(11),
  `Worldspace` varchar(128),
  `Inventory` longtext,
  `Hitpoints` varchar(512),
  `Fuel` double(13,5),
  `Damage` double(13,5),
  `notes` text,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

-- Delete trigger

DELIMITER ;
DROP TRIGGER IF EXISTS `deleteObjectAudit`;

DELIMITER //
CREATE TRIGGER `deleteObjectAudit`
AFTER DELETE ON object_data
FOR EACH ROW
BEGIN
	INSERT INTO object_audit (`tstamp`, `action`, `ObjectID`, `ObjectUID`, `Instance`, `Classname`, `Datestamp`, `LastUpdated`, `CharacterID`, `Worldspace`, `Inventory`, `Hitpoints`, `Fuel`, `Damage`, `notes`)
           select now(), "del", `ObjectID`, `ObjectUID`, `Instance`, `Classname`, `Datestamp`, `LastUpdated`, `CharacterID`, `Worldspace`, `Inventory`, `Hitpoints`, `Fuel`, `Damage`, "" from object_data where ObjectUID = OLD.ObjectUID;
END//
DELIMITER ;

-- Housekeeping

DROP EVENT IF EXISTS `housekeepObject_audit`;
DELIMITER ;;
CREATE EVENT `housekeepObject_audit` ON SCHEDULE EVERY 1 DAY COMMENT 'Housekeeps the player_alias table' DO DELETE FROM `object_audit` WHERE `tstamp` < DATE_SUB(CURRENT_TIMESTAMP, INTERVAL 30 DAY) 
;;
DELIMITER ;

 

I do have the code for insert and update triggers as well if anyone wants them.  They will add load to the MySQL server and the object_audit table will grow fast and will affect backup sizes unless the table is excluded from the DB backup.  Just shout if there is an interest.

 

I may have a beta player_build.sqf ready for testing today with;

1. Correct positioning over land or water.

2. Option to walk around the whole plot when building rather than being limited to 5 mtrs from build origin.

3. Walk around option can be turned off or on with a variable.

4. If no plot pole required then the 5mtr build range is retained (stops people running around with preview walls as bullet blockers).

5. 5mtr high limit from origin still in effect.

6. Allows an optional check for height above ground / sea max (prevent sky bases).

7. Can set max height to build plot poles (if 6. active).

8. Can set max height to build items that do not need plot poles (if 6. set).

9. Uses my new fn_check_owner.sqf to check ownership and friendly status (as take plot ownership does) - reduces code size in player_build.

 

Note: Player_build.sqf is not used in A Plot for Life if DZE_modularBuild is set to true.

 

I will release the player_build.sqf as a separate file for people who want to test.  If testing seems good / after fixing discovered bugs I will modify the modular build files with the changes, put it out for testing again and if all good will push out a new version of A Plot for Life with them included.

 

[ReDBaroN]

Hi RimBlock, we think we have nailed down the object delete to restart timing. Looks like there could have been some confusion our end on this. Basically on our tests, if we made 100% sure not to restart the server until more than 5 minutes since the last object was built we don't appear to be losing them anymore. I thought the 'everything going mad just before restart' thing wouldn't have still applied so much to an empty server on a dedicated box running at 47 server FPS but....there you go... We are still testing to make sure this is all it was. If not, we will use your SQL posted above. Thanks for that.

 

The friends thing is still there though but impossible to pin down on our testing. It seems that all the time when you tag friendly, the player steam id is correctly saved into current state on character data but, sometimes just doesn't work in game. However, from our tests, in all cases if the friend relogs when the problem occurs and looks at the owner again without needing to re tag, everything works as intended. So there's something a bit odd here but, at worst a relog fixes it. It's almost like the in game part of tag friendly is not quite working 100% although the db is spot on. Sometimes your friend's name doesn't show in green like normally when you look at them and that's when you get the problem. We have tested in our live server not running P4L and we don't get the same problem......

 

Any ideas on what may cause this as, I think the build and remove element of P4L is working fine. It's just something somewhere with friendly tagging that's working different to default epoch and not quite right in game until you relog...

[RimBlock]

Ok, thanks for the update.

 

On the issue of the tag friendly system, I am at a bit of a loss.  After tracking through the whole process last night there should not be any issues.  The only thing that is changed is whether to store the characterID or the SteamID in the players friendlies but the method for storing the actual value is the same as used in vanilla Epoch.

 

What is actually not working with the tag friendly.  Is it that the other players name does not come up as green after tagging or is there more not working with the friendly system ?.

 

The way it works in vanilla Epoch is that you tag someone as friendly and their characterID gets added to the friendlies variable (array) of your character (player) game object.  When that object is saved then the details are also saved in to the DB.  At the same time, the other players character gets a message that someone has tagged them and then they can do the same with the same results.  After this is done and both player characters have the other charactersID in their friendlies, and the next time (possibly the same time) the characters cursors touch the other player, they should light up as green and the below friendlyTo system is activated.

 

Having someone in your friendlies list does not mean they can build as you need to look at them once to mark them as friendly.  If you have the other character in your friendlies and the other character has your characterID in their friendlies then you both get each others characterID added you the each characters friendlyTo variable.  This then determines if the other player can build on your plot.  The important bit on this is that the friendlyTo details are not saved to the DB and so are not set unless you look at the other players character again.

 

You could add some diag_log lines in to the player_tagfriendly.sqf and player_updateGUI.sqf to see what the variables are but I am not currently seeing how A Plot for Life would cause a problem here.

 

If you can pin it down some more then that would help.

 

@everyone.

 

There is a new player_build.sqf up on my Git under the master branch (A Plot for Life v2.34 now has its own branch).  This is an early beta and requires updates to the A Plot for Life custom compiles.sqf (new save position function added) and variables.sqf (new variables for the new added functionality).  Both also up on my Git on the master branch.

 

To test it out;

1. Download those 3 files from my Git and replace the standard A Plot for Life files with them. 

2. Make sure you have set DZE_modularBuild to false (or don't set it as it defaults to false). 

3. Set the new variables as required 

  - DZE_BuildInPlotRadius: Valid values are true or false (default) and this turns on whether you can run around anywhere in the plot radius without the preview getting cancelled due to moving more than 5 mtrs.

  - DZE_BuildOnGround: Valid  values are true or false (default) and this turns on whether to false plot poles to be built at DZE_MaxPlotHeight and other items that do not need a plot pole to be built at a max DZE_MaxNoPlotNeededHeight height.  The default values are 0.5 and 15 (values are in metres and can be overridden in the init.sqf).

 

As this is only for the regular build system it will no use Snap Build Pro for this initial beta but if it is tested and works ok then I will merge the changes in to the modular build system that Snap Build Pro is also linked in to with this release.

 

Please report any bugs / feedback to this thread or put a post up in my Gits issue tracker.

 

I have also pushed up a new plot_take_Ownership.sqf file (slight amendment to use  FNC_GetPos for positions) and fn_check_owner.sqf (changed 'player' to '_player' which is passed to the script making it easier to use for checks agains other players for ownership as well as the calling player).  Both are very minor and will have no visible differences.

 

The full details of all the changes are listed in this Git commit.

[ftwbren]

Hi, when I login I get a black screen while spawning in.

 

Here is my report file - http://pastebin.com/JB0Ub68Q

 

I run scripts on my server that utilize the file given, I tried DiffMerge this time but still am unable to proceed. If it helps when I load in the database does not load, when I remove the script the database loads (hence the black screen?).

 

If there is an instruction list of what code to add to what files that would be greatly appreciated if someone could lend me that as this is an issue.

 

Help is much appreciated!

[RimBlock]

You have errors all over your rpt file including for stuff that has nothing to do with this mod

 

e.g.

Line 13: File nissan_350z\config.cpp, line 244: '/CfgVehicles/350zBase/Library.libTextDesc': Missing ';' prior '}'

 

You will need to go through them one by one and correct them.

 

You don't seem to have linked in the server_functions.sqf correctly

 

Line 401:  0:48:40 Warning Message: Script custom\init\server_functions.sqf not found

 

Your selfactions has issues.

Line 408:  0:48:40 File mpmissions\DayZ_Epoch_13.Tavi\custom\fn_selfActions.sqf, line 61

 

Than you have errors all over the server_monitor.sqf

Line 617 onwards: 0:48:43 File mpmissions\DayZ_Epoch_13.Tavi\custom\system\server_monitor.sqf, line 51

 

Fix the linking in of the server_functions.sqf and a lot of the errors may go away.

[ftwbren]

Thank you very much, I have fixed it now! :D

[ReDBaroN]

Hi RimBlock, we have found another couple of issues:

• Global death messages - seem to have started displaying, even though I currently have themset to false in the init. I have checked the new variables file and they are set to false if nil. I have also tried commenting them out altogether but that doesn't work. They seem to be a short version the just says....'XXX was killed'.
• Combat Indicator - after being in combat stays red even though no longer flashing and allows you to log out. If you relog this goes back to green. If you don't relog, it stays red forever....

Apart from our intermittent tag friendly problem, that's all I can find at the moment.

 

Any ideas on that one those 2?

 

Thanks

 

EDIT: Sorry problem one was my fault as I had the wrong profile file being read.

 

EDIT2: It looks like none of the gui stuff is working. blood doesn't go down when you're losing blood, food water don't show a gradual decline, the sight warning never appears and the noise indicator is jammed fully on. Also the combat indicator doesn't flash, it's just solid red. 

 

I'm wondering if this is something to do with your code preparing for the new gui in 1052...?

[RimBlock]

Check you are using the latest version of player_updategui.sqf. an older release had a version based off of the 1.0.5.2 version but this was corrected a while ago and the 1.0.5.1 based version is on Github and should also be in the Dropbox file.

If your version has dayz_dark_ui in it then it is the 1.0.5.2 version.

The version up on Github is working Fine.

[ReDBaroN]

Check you are using the latest version of player_updategui.sqf. an older release had a version based off of the 1.0.5.2 version but this was corrected a while ago and the 1.0.5.1 based version is on Github and should also be in the Dropbox file.

If your version has dayz_dark_ui in it then it is the 1.0.5.2 version.

The version up on Github is working Fine.

Damn, I went with dropbox....thought they were the same...

 

I have definitely seen dayz_dark_ui somewhere...

 

Is it just the one file to change or, are there a few?

[RimBlock]

Just the one IIRC.

 

The dropbox file should be in sync.  Can't check until tonight but the dropbox zip is created from the folder that is my local Github repo.

[LordCraven]

I'm a little bit confused. Sorry for my english and my Noob Question, but ive got a Problem

 

In the install notes is the part

 

*** Turn on options ***


Turn on A plot for Life (check ownership against SteamID).
DZE_APlotforLife = true;

Turn on Take Plot Ownership (take ownership of all items on a plot except locked items).  This can be used to realign old bases to the A Plot of Life ownership system or for raiding and taking over bases.
DZE_PlotOwnership = true;

Turn on Snap Build Pro and the modular player build framework.
DZE_modularBuild = true;

 

Im new in scripting and dont know where i have to insert this part.

[RimBlock]

These go in your init.sqf in your mpmissions\mapname folder

[ReDBaroN]

Hi RimBlock, from our initial tests even using the player_updategui.sqf. from your git, all of the functions are still not working.

 

I can't diffmerge on your latest git because it includes your new alpha changes which I don't want to start on yet as we were too near with moving the last version up to live and don't want to start from the beginning again.

 

Are you sure that there isn't anything else to change? We have literally only udpated the player_updategui.sqf. with the one from your github.

[RimBlock]

Change the branch on the git from 'master' to 'A Plot for Life v2.34'. That branch is frozen and does not have the new changes.

[ReDBaroN]

there's only one branch there that i can see...? Master..

[RimBlock]

Hmm, maybe I didn't push it to the Git, it is on my local Git.  Will check tonight.

 

Nothing much has changed in the master branch apart from player_build.sqf.  Compiles has an extra function but only player build uses it and there are a few more variables in variables.sqf.  Neither of the last two should cause any issues, just exclude player_build.sqf if you don't want the new beta changes.

 

Version 2.34 has its own frozen branch now on the Git.

[ReDBaroN]

Hi RimBlock, I have checked the 2.34 branch code with the version on my test server and they match.

 

We are definitely having problems with the gui.

 

Test results after server restart:

1. Combat indicator turns red when in combat, doesn't flash (like it does in default 1051) and doesn't go green again until you relog even though you are out of combat and can build, abort etc.
2. Blood indicator never decreases regardless of how low your blood goes. (tested from 12k down to 0)
3. Sight and sound indicators work as expected until combat indicator sticks on red when they lock on full
4. Food and drink indicators work as expected

Test results on relog after death:

1. Combat indicator turns red when in combat, doesn't flash (like it does in default 1051) and doesn't go green again until you relog even though you are out of combat and can build, abort etc.
2. Blood indicator never decreases regardless of how low your blood goes. (tested from 12k down to -650)
3. Sight and sound indicators locked on full even if you're not moving and laying prone
4. Food & drink never decrease

The biggest problem we have here is the food and drink indicators. Without these working, players are literally going to be dropping all over the server and asking for help. Blood, we're not too worried about as it's in our debug. Sight and sound we could live with as well as the combat indicator although this will bring up questions.

 

Any chance you could have another quick look? Or, is there any chance I could try your P4L version of the dark gui planned for 1052? See if that fixes it?

 

Thanks