RimBlock

v2.2.3 uploaded with the small fixes outlined in
 
First post updated.

Ok, actually, let me confirm tonight.  I def have it in my head that they are but the details are a little fuzzy about the testing as it was a while ago.  I will recheck.
 
Personally I would rather remove based on last updated than the numeric value as if they are not reused then they should be else the number is just going to keep going up.

If you would like me to send you my modded P4L / snap_pro I would be happy to do so. I had to remove the P4L though atm as I just implemented this:  and Overwatch into my server, so have to go through and check all the files as I would rather have P4L than not have it tbh,
 
I will have a coding session later and post here a complete merged P4L & Snap_Pro if Rim / Ray is ok with that of course!
 
Pry

Hmm interesting, I had issues like that but once I updated ML100 files (or whatever they are called). It worked without Issue. I'm running Server 2012 RTM.
 
In regards to help! I really would like to give back... It's been so much fun setting up a server, and I couldn't of done it without people like you.. I'll create a install video this weekend.

The dedicated build leaves the server_monitor.sqf on the server side only (not in the mission).  The hosted build is for people with hosters that have no access to the server folder and so cannot place it serverside.
 
The dedicated has the server_monitor.sqf in a folder rather than in the dayz_server.pbo as I would think people would rather I concentrate on fixing bugs than writing a gide on how to extract a file from a pbo, what software to use, how to load it back in and then troubleshoot issues that arise concerning whatever PBO extraction package people use and the process of getting the file out and loading a new file in. 
 
Changing it in the server.pbo also changes the signiture which did not seem to cause any issues when I tried but may in future or possibly with one for the antihack set of scripts which I do not use.
 
Tl;Dnr: Easier to support, troubleshoot and amend the server_monitor.sqf on the server outside of the pbo.  Can concentrate on bug fixes rather than unpbo support.  Put it in the pbo if desired.  Will work fine and change the link in the init.sqf.
 
As this should be going in to the core Epoch build it will be in the dayz_server.pbo file in the end anyway :) .

Ladies and gentlemen.
 
vbawol will allow it to be included as part of the standard Epoch build after I have converted it so it can be turned on or off via a variable  :D .
 
I need to finish the debugging, add the maintenance, optionise it (turn it on or off via a config variable), testing etc and then I will push it to the DayZ Epoch build so everyone will have it as standard and can choose to turn it on or off as they prefer.
 
There is a bit of work to do so don't hold your breath and please continue with this mod build for now.  It will also help to iron out some of the bugs before merging.

Ladies and gentlemen.
 
vbawol will allow it to be included as part of the standard Epoch build after I have converted it so it can be turned on or off via a variable  :D .
 
I need to finish the debugging, add the maintenance, optionise it (turn it on or off via a config variable), testing etc and then I will push it to the DayZ Epoch build so everyone will have it as standard and can choose to turn it on or off as they prefer.
 
There is a bit of work to do so don't hold your breath and please continue with this mod build for now.  It will also help to iron out some of the bugs before merging.

Ladies and gentlemen.
 
vbawol will allow it to be included as part of the standard Epoch build after I have converted it so it can be turned on or off via a variable  :D .
 
I need to finish the debugging, add the maintenance, optionise it (turn it on or off via a config variable), testing etc and then I will push it to the DayZ Epoch build so everyone will have it as standard and can choose to turn it on or off as they prefer.
 
There is a bit of work to do so don't hold your breath and please continue with this mod build for now.  It will also help to iron out some of the bugs before merging.

Ladies and gentlemen.
 
vbawol will allow it to be included as part of the standard Epoch build after I have converted it so it can be turned on or off via a variable  :D .
 
I need to finish the debugging, add the maintenance, optionise it (turn it on or off via a config variable), testing etc and then I will push it to the DayZ Epoch build so everyone will have it as standard and can choose to turn it on or off as they prefer.
 
There is a bit of work to do so don't hold your breath and please continue with this mod build for now.  It will also help to iron out some of the bugs before merging.

And also i'm assuming that server monitor is supposed to be used to change stuff in server pbo not kept in mission?

Thanks for your input WEREWOLF, firstly A3 Epoch is a mod developed by me (AWOL), Skaronator, Axeman, Sequisha, and Kiory. All of us are part of this modding community you speak of.   DayZ Epoch was conceived and developed by me (AWOL) with the goal to make something others would want to play for more that two weeks as I felt DayZ Mod lacked staying power. Now that was relatively easy to do considering that Rocket had already made a really good mod to base Epoch on. Most other mods at the time locked down server files and made exclusive deals etc. and I did the exact opposite and released DayZ Epoch 100% open source for the community.   Doing this with A3 Epoch is not as simple as you may think considering that A3 Epoch has been coded from scratch just for Arma 3. To clarify we simply need time to develop this mod and want to get proper feedback on the mod so we can make it even better.    My end goal is to make the A3 Epoch Mod into something that everyone will want to run as a base mod for what it offers much like DayZ Epoch does now (ala overpoch). After we provide a stable and feature filled experience additional custom work will be welcomed.   A3 Epoch will be structured and coded in a way that encourages custom additions to be properly coded so that they do not rely on overriding our files (this will make updating easier).

Plot for Life v1.1 - Does not work with the SteamID.
Plot for Life v2 - Works with the SteamID - Released 2nd July 2014 :D.

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.

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 ;) .

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.

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.

Tested (ARMA II OA - 125548 with SteamID and Epoch 1.0.5);
Place plot pole.
Build cinder doorway.
Build metal floor.
Restart server.
Remove metal floor.
Remove option appears.
Upgrade option appears.
 
Also not tested;
Upgrade buildable.
Downgrade buildable.
Safe build / open / lock / pack.
Tent build / pack.
 
Early BETA (for 1.0.5)
 
Please only download for initial testing.  This is likely to have bugs in it.  Please only install on a test system with test data.
 
A Plot for Life 2.0 BETA.rar
 
Download and extract to your mpmission/map/ folder.  No DB changes required.  Note the DZE_debug is set to true so hopefully you will see some error info if you hit any bugs in your client RPT file.
 
Please report any bugs here along with a description of what you did, what the issue is, if you can repeat it and any other mods you have installed (pref none). 

Plot For Life v2.5 with Snap Pro v1.4.1 & Precise Base Building 1.0.4 (Built for Epoch 1.0.5.1)   Current Version Note: If you are also going to use other building mods (Vector build etc) then please check the other mods have been updated to work with v2.5 before installing.  If they have not then please use A Plot for Life v2.35 which can be downloaded from the links further down this post.   Dropbox: A Plot for Life v2.5 GitHub: A Plot for Life v2.5   V2.4 -> 2.5 upgrade.    1. Download and replace the following files in MPMissions\[Mapname]\Custom\Compile. fn_check_owner.sqf fn_find_plots.sqf 2. Download and merge (see the diffmerge tutorial links further down) the server files found in $SERVERHOME\custom (changes are fairly minimal).   That is it.   New features. Merged in Precise Base Building from his kind permission.  Please show your appreciation to him as well.
  Core Features. The whole system is is switchable between characterID and PlayerUID by setting a variable. All items built after the mod is installed with have the PlayerUID and the characterID stored for ownership checking (locked buildables will only have the PlayerUID stored as the characterID field is used for the lock code). Includes the 1.0.5.2. code to allow either SteamID or BIS PUID (written by icomrade). You can turn on the plot boundary from the plot pole and remove it.  Currently I am using the road cones with lights on top which are also visible at night.  They can be changed. Take Ownership is available from the plot pole to the plot poles owner and allows them to take ownership of all buildables in range excluding  locked storage (safes / lockboxes), tents, locked doors.  This can be changed as it is all controlled via variables.  The core idea is that this will align peoples bases to the new system for steamID storage on legacy bases.  It also means that raiders can raid a base, replace the plot pole, take ownership and not get full access to locked areas but not have 6 cycles to remove stuff etc after taking over.  Depending on the size of the base, number of objects etc this could put a bit of load on the server / DB.  It is also turn off or on-able via a variable so you can set it only to allow players to realign their bases and then disable the option. New function to check ownership or friendly status of a given object. Merged with Snap Pro and Modular build framework with permission from Raymix Please show you appreciation to Raymix as well). Uses the modular build system.
New functions to reduce instances of common code in the building system.  Both are small and precompiled.
fn_check_owner.sqf to check ownership and friendly status
fn_find_plots to get all nearby plot poles and return a count and the nearest alive one (if one exists).
Optimised code changing nearestobjects to nearEntities.
Added delay in the Take Ownership function so the Hiveext / DB does not get spammed when taking ownership of large bases.
Player_build.sqf is no longer used at all and had been removed from the distribution.
Optimised code what has saved between 20k & 30k in the mission package size.
  Install Instructions are in the zip file (A Plot for Life v2.5).   Guides on how to use Diffmerge and how to integrate scripts together.   Please backup your databases and thoroughly test before putting live.   Report any bugs / suggestions in the thread.   Previous version 2.35 Dropbox: A Plot for Life v2.35 & Snap Pro (by Raymix) v1.4.1 GitHub (v2.35 stable): A Plot for Life v2.35 & Snap Pro (by Raymix) v1.4.1   Outstanding issues None reported. Next Version: 3.0
Include a action menu (scroll wheel menu) for plot options and builder / owner management ()  
Beta Testing
As it seems theres no with an interest to do any beta testing I need to sweeten the deal.  Anyone who helps with beta testing will get access to boobytrapping doors 4 weeks before it is released publicly.  The 4 weeks will start from the v2.4 release date and will include any bug fixing period.  
 
Boobytrapping Doors - If you have a hand grenade then you can upgrade a locked door to boobytrap it.  If the incorrect door code is entered then the hand grenade will be dropped at the position the player was when they boobytrapped the door (make sure you are on the correct side of the door when setting the trap  ;) ).
 
 
Releases   Naming convention  

 
Previous releases (Majors)
 


  Use and Distribution License details.   This mod is licensed under the DayZ Mod License Share Alike (DML) license.   Usage For people wishing to use the mod for their own servers, please use away.  If advertising the mod as a feature of your servers then a shoutout and a linkback to here would be appreciated but is not a requirement.   Distribution For people wishing to modify and distribute my code for this mod, the requirements are different. 1. You contact me and ask (common courtesy really). 2. You make it clear who the original creator is and provide a link to this thread.   Included mods. A Plot for Life v2.35 (Rimblock). <- is fine.
 
Included mods.
A Plot for Life
 
"credits to each addon / script creator" <- is not.
 
3. The person distributing the mod explicitly states that they are responsible for any issues with their modified version of the mod and not the original creator (i.e. me).
 
4. Any other requirements under the  DayZ Mod License Share Alike (DML) license.
 

Firstly thanks to Brockie for putting a step by step guide together as an easy reference.
 
I did step 9 between 5 & 6 so when it verified the integrety, it downloaded the beta exes.
 
I did not need steps 8 of 11 (run the game to main menu) but the game had been running previously on the desktop machine so it seems the new Beta is not dependant on the reg keys created on the first run or is compatible with the ones placed there by previous versions.
 
I then copied over the ARMA2OA folder to the server, made the changes to the config files (steps 15 -> 19) although I found the requiredSecureId = 2; was already set in the 1.0.5 mod files already.
 
On starting, my ARMA2OA server console would be spamed by "reading from file" messages.
 
To resolve this I needed to copy the ARMA2/addons folder over to the server and place in the same folder as the ARMA2 OA files and it now works.
 
One cavaet is that I saw ARMA2 listed twice in the expansions menu.  I unchecked one and restarted and the expansions seem to have sorted themselves out fine.
 
I don't use DayZ Commander, I don't have Steam installed on my server and I don't use anti-hacks (apart from those built in to Epoch).
 
@Brockie
 
Axel (Epoch Dev) removed the steps 12 & 13 as not required.
 
The Bell expansions are also not required but seem to come as standard.  I have never activated them myself but may give them a go if they are working fine on Epoch.

Just an update on the server install.
 
I also had to copy over my ARMA2/addons folder over to the servers game folder else when starting Epoch I get lots of errors in the config.bin and it cannot find lots of assets.
 
I have all the expansions (BAF / ACR / PMC) so that may be the difference

Yep, same issue as with mine.  Saving playerUIDs to the characterID field is just not possible anymore (SteamID = 16 chars from what I have seen, characterID field is 11 digits).
 
OtterNas3 and I had been discussing moving away from saving in the characterID column for a number of weeks now and came to agreement on a solution.  I have spent most of the day working on it for my mod and will have a chat with Otter so we can align.  No point both of us reinventing each others work and we can both troubleshoot the common base code.  Mine is just about ready for my first alpha test.

Unless you update the buildables characterID to the linked playerUIDs current alive characterID on login (if needed).
 
Not the neatest solution but it may be a reasonable 'tactical fix' for the short term until a more robust long term fix is put in place.  Actually, thinking about it, apart from a slowdown on logging in, that could be done in maybe one or two sqf files and the rest would not need to be changed at all.  We would not need to link the playerUID to the buildables but just keep the buildables updated with the players most current alive character.  Only problem I can see is if a player has two alive characters (multi character mod from AxeCop for example).
 
Hmm, something to sleep on.

On 999 calls.
 
You seem to be missing the point I have been making about trying to secure them, either that or you are deliberately ignoring it.  Whilst the dev team on Epoch have put in great work I do not count them as the "end all" authority on 999 calls or hiveext.  If you don't mind, I would like to take a look myself. 
 
You may not like the idea and that is fine.  You stating that they should not be used or even investigated closer at all because the Epoch team does not want to use them 'for security reasons' seems very closed minded.
 
For securing 999 calls, various techniques could include
Locking down the sql query ('key' parameter) passed to server_functions.sqf by validating before firing to the DB much as you would to try and protect against sql injection attacks. Further lock down the queries with only parameters being passed from the client calls in the key parameter to the server_hivereadwrite function and then that 'key' parameter is checked, verified and if seems valid is inserted in to canned sql queries in the server side functions to create the final sql query to be fired at the DB. Each server could have their own canned sql queries. Neither are particually hard to do and will give, if implemented correctly, a secure use of the calls. 
 
Even without those restrictions, damage limitation can also be enforced by limiting the functions the Epoch DB user account has.  As standard it should not be able to do much more than UID (update, insert and delete) to a limited set of tables.  I read somewhere about people being concerned that 999 calls could be used to drop tables.  Why would the Epoch DB account have access to that command ?.  The only reason I can think of would be because the person setting up the account was not aware of best practices for secure application account creation and no guide seems to have been produced as part of the Epoch install.
 
On repurposing fields.
 
We seem to have different definitions on the term solution then.  "Low hanging fruit" is a term commonly used in project scoping meetings and leveraging the currently available resources are just that.  It gives people a working solution whilst developers are working on a better implementation.
 
The tag friendly system does the same with the players currentstate field.  This is part of the Epoch release put out by the Epoch dev team. 
 
On new calls.
 
Last I read (which you linked to) was "If I have time, I could dust off my C++ skills..." which would indicate nothing has been done.  If you have started working on this then fantastic.  It would be good to see what progress you have made.
 
For the rest...
 
Fully agree.  As an IT project manager by trade I am finding it quite hard to not try and better organise the effort but as this is Zupas baby and, TBH, I have enough work on my plate and would rather just help out here and there.  I am happy to offer suggestions, as I have, and people can take them or leave them.  OPne major concern is that there seems to be no list of deliverables, schedule of when donators are expected to donate or how the donations are expected to be split between the people working on this.  There also seems to be no organisation on team meetings (when, what is on the agenda etc).
 
Whilst it is great that you are looking to expand the hiveext.dll for this project, I am looking to see how the hiveext.dll could be leveraged to provide better DB interaction for all mods without people needing to go to ARMA2NET.
 
For custom calls, a more open solution would be
Being able to write parameters to a set table via one hive call and then calling a stored procedure with another. The stored procedure would then only take data from the table the first call writes to. This would depend more heavily on sql procedures for results which some are not so comfortable with but would lock the sql code away on the DB server rather than in scripts.
 
Creating a custom call to modify only a set table is great but will you then be creating more custom calls for any other tables that any other mods would like as / when requested by other mod makers ?.

On 999 calls.
 
You seem to be missing the point I have been making about trying to secure them, either that or you are deliberately ignoring it.  Whilst the dev team on Epoch have put in great work I do not count them as the "end all" authority on 999 calls or hiveext.  If you don't mind, I would like to take a look myself. 
 
You may not like the idea and that is fine.  You stating that they should not be used or even investigated closer at all because the Epoch team does not want to use them 'for security reasons' seems very closed minded.
 
For securing 999 calls, various techniques could include
Locking down the sql query ('key' parameter) passed to server_functions.sqf by validating before firing to the DB much as you would to try and protect against sql injection attacks. Further lock down the queries with only parameters being passed from the client calls in the key parameter to the server_hivereadwrite function and then that 'key' parameter is checked, verified and if seems valid is inserted in to canned sql queries in the server side functions to create the final sql query to be fired at the DB. Each server could have their own canned sql queries. Neither are particually hard to do and will give, if implemented correctly, a secure use of the calls. 
 
Even without those restrictions, damage limitation can also be enforced by limiting the functions the Epoch DB user account has.  As standard it should not be able to do much more than UID (update, insert and delete) to a limited set of tables.  I read somewhere about people being concerned that 999 calls could be used to drop tables.  Why would the Epoch DB account have access to that command ?.  The only reason I can think of would be because the person setting up the account was not aware of best practices for secure application account creation and no guide seems to have been produced as part of the Epoch install.
 
On repurposing fields.
 
We seem to have different definitions on the term solution then.  "Low hanging fruit" is a term commonly used in project scoping meetings and leveraging the currently available resources are just that.  It gives people a working solution whilst developers are working on a better implementation.
 
The tag friendly system does the same with the players currentstate field.  This is part of the Epoch release put out by the Epoch dev team. 
 
On new calls.
 
Last I read (which you linked to) was "If I have time, I could dust off my C++ skills..." which would indicate nothing has been done.  If you have started working on this then fantastic.  It would be good to see what progress you have made.
 
For the rest...
 
Fully agree.  As an IT project manager by trade I am finding it quite hard to not try and better organise the effort but as this is Zupas baby and, TBH, I have enough work on my plate and would rather just help out here and there.  I am happy to offer suggestions, as I have, and people can take them or leave them.  OPne major concern is that there seems to be no list of deliverables, schedule of when donators are expected to donate or how the donations are expected to be split between the people working on this.  There also seems to be no organisation on team meetings (when, what is on the agenda etc).
 
Whilst it is great that you are looking to expand the hiveext.dll for this project, I am looking to see how the hiveext.dll could be leveraged to provide better DB interaction for all mods without people needing to go to ARMA2NET.
 
For custom calls, a more open solution would be
Being able to write parameters to a set table via one hive call and then calling a stored procedure with another. The stored procedure would then only take data from the table the first call writes to. This would depend more heavily on sql procedures for results which some are not so comfortable with but would lock the sql code away on the DB server rather than in scripts.
 
Creating a custom call to modify only a set table is great but will you then be creating more custom calls for any other tables that any other mods would like as / when requested by other mod makers ?.

If ZUPA is willing to share the .dll with the 999 call then I will have a look to see if it can be leveraged safely.  I do have some ideas that should work and keep control firmly in the server owners pocket.