RimBlock

There are usually multiple reasons why it won't happen.  The most obvious are;
Cash, either competition prizes of just being the most popular to keep those donations coming in. Kudos for working with a popular mod. Control of the mod makers vision (like MeshCarver with the Stalker map he has been working for years on). What with BIS bringing out the new rules on monetization, which also includes script code, if anyone wanted the option then they would need permission from all contributors.  Bigger the collaboration, bigger the headache in the future. 
 
Innovations usually happen faster when there is competition.

I emailed BI and have just received a response.  Kudos to BI for taking the time to respond to these sort of queries.
 
Note, these relate to only Bohemia Interactive assets and not any mod assetts (objects, models, scripts etc) as that is determined by the mod makers.
 
[Question]
Are the following definitions correct from a BIS point of view ?.
 
Donation: A transfer of something to the benefit of the recipient (usually money to help keep servers running in this case).
Shops (in-game or via websites etc): Places where people pay for in-game items.
 
[Response]
Agreed. Donation with counter value is a sale, not donation. Donation == no counter value.
 
[Question] - This one has already been sorted out with posts in the BI thread between me emailing and the response coming back.
If I write some code to allow the refilling of magazines (no new objects but purely sqf code) then if someone uses that code, do they need to request my permission before allowing monetization of their mod ?.
 
[Response]
Yes
 
[Question]
  If my code uses some generic scripts provided by another modder then does the mod team wanting to monetize need to get permission from myself and the other modder who provided the utility sqf scripts ?.  I am sure you can see where this is going… how far down the chain of contributors does a mod team need to go before they can be sure all required approvals are in ?.
 
[Response]
Depends on the license of generic script. Your are creating derivative works so you need to observe the license of the original work.
 
[Question]
The other concern with this is that if someone contributes a small addition to a number of mods and the mod teams later wanted to allow monetization then that contributor could hold the mod teams to ransom.
 
[Response]
If he did not allow it in the first place, then they need to either remove his work or get his permission.
 
[Question]
If there is disagreement on the creator of some code then how will this be handled ?.


[Response]
It will be handled on case by case basis.  It might be difficult, but if we are not sure we may just take the monetization permission away for both parties.
 
I did ask another question about selling items and their definition of in game advantage (ie. you can sell a car as long as the specs are the same as one that can be found or you cannot sell a car as buying is an advantage already).  The response seemed to contradict a post by BI on the thread so I have just replied and asked for confirmation.  Will post the results when a reponse is received.
 

I emailed BI and have just received a response.  Kudos to BI for taking the time to respond to these sort of queries.
 
Note, these relate to only Bohemia Interactive assets and not any mod assetts (objects, models, scripts etc) as that is determined by the mod makers.
 
[Question]
Are the following definitions correct from a BIS point of view ?.
 
Donation: A transfer of something to the benefit of the recipient (usually money to help keep servers running in this case).
Shops (in-game or via websites etc): Places where people pay for in-game items.
 
[Response]
Agreed. Donation with counter value is a sale, not donation. Donation == no counter value.
 
[Question] - This one has already been sorted out with posts in the BI thread between me emailing and the response coming back.
If I write some code to allow the refilling of magazines (no new objects but purely sqf code) then if someone uses that code, do they need to request my permission before allowing monetization of their mod ?.
 
[Response]
Yes
 
[Question]
  If my code uses some generic scripts provided by another modder then does the mod team wanting to monetize need to get permission from myself and the other modder who provided the utility sqf scripts ?.  I am sure you can see where this is going… how far down the chain of contributors does a mod team need to go before they can be sure all required approvals are in ?.
 
[Response]
Depends on the license of generic script. Your are creating derivative works so you need to observe the license of the original work.
 
[Question]
The other concern with this is that if someone contributes a small addition to a number of mods and the mod teams later wanted to allow monetization then that contributor could hold the mod teams to ransom.
 
[Response]
If he did not allow it in the first place, then they need to either remove his work or get his permission.
 
[Question]
If there is disagreement on the creator of some code then how will this be handled ?.


[Response]
It will be handled on case by case basis.  It might be difficult, but if we are not sure we may just take the monetization permission away for both parties.
 
I did ask another question about selling items and their definition of in game advantage (ie. you can sell a car as long as the specs are the same as one that can be found or you cannot sell a car as buying is an advantage already).  The response seemed to contradict a post by BI on the thread so I have just replied and asked for confirmation.  Will post the results when a reponse is received.
 

A Plot for Life is not really very complicated but it does small touches to lots of files so there are lots of chances to miss a ; or } or something else 2 hen merging.

If it gets I to the core Epoch build then all of that will go away for people.

Not quite so simple.
 
The weight for items are hard coded in the R3F_realism mod.  They can be found here (GitHub version).
 
These then combine with the tiredness side of things to work out when you will have different tiredness affects.  The levels at which blackout and all the different factors that affect them (player stance, weight, speed etc) are all in the R3F_TIRED_Configuration.sqf file (GitHub Version).
 
For a quick fix, maybe look at changing the blackout value or adding it as a variable in the variables.sqf file and change the realism mod so it references the variable rather than having it hard coded.
 
As the realism is external it may be worth taking a quick look at the GNU General Public License it is under to make sure there are no issues with changing the code, especially if you are going to make it available to others.

I will not be supplying a step by step guide to all the changes in the 42 files.
 
I will be putting this up for inclusion in the core Epoch files (again) so they should be included with Epoch 1.0.5.2 (1.0.6) when it finally arrives.  Some people are actively working on testing the latest RC so there is still hope.

Currently nothing to do with Epoch (A2 / A3) has permission to be sold or be provided as perks for donators.  This is true whether the items are available without paying or not.
 
Bases built using Epoch items are covered in the above statement.  The ability to make them indestructible is also included. 
 
Only BIS assets are covered by the new rules.  Everything else (models/objects, scripts, ingame mechanics (like currency) ) are only allowed for monetization with the express permission of the creator(s) (this, in the case of Epoch includes all the projects contributors and not just the Epoch dev team).
 
If any servers are not compliant, BIS have warned that they will investigate and take action (if found non-compliant) which could include legal and technical methods (no details on what they may be that I have yet seen).  BIS have also not stated how quickly they will investigate and going by historical evidence many are dubious as to whether they will actually do anything.

MySQL DB backup v1.1.
 
Note: This script is included in the DayZEpoch 1.0.6 distribution (when released).
 
What is it.
 
This is a Windows batch file (.bat) which will backup your MYSql database(s) for you.  If you add it to Windows scheduler it can also run automatically at a frequency you define (every 15 minutes for example).
 
Features.
 
- Backup tables, triggers and events.
- Housekeeps old backups after user defined number of days.
- Resulting .sql files can be loaded in to a SQL client and run against a MYSQL database to recreate the structure and data from the backed up database.
- Server DateTime format independant (works for MM/DD/YYYY or DD/MM/YYYY date formats).
- Can be scheduled with Windows scheduler.
 
How to use it.
 
Create a .bat file (call it something like DB_Backup.bat) and paste the following in to it.
@REM *** PARAMETERS/VARIABLES *** SET BackupDir="[Where you want to save the backups]" SET mysqldir="C:\Program Files\MySQL\MySQL Server 5.6\bin" SET mysqlschema=[Your DB schema name] SET mysqlpassword=[your DB password] SET mysqluser=[your DB user login] SET housekeepafter=5 for /F "usebackq tokens=1,2 delims==" %%i in (`wmic os get LocalDateTime /VALUE 2^>NUL`) do if '.%%i.'=='.LocalDateTime.' SET ldt=%%j set datestamp=%ldt:~0,4%-%ldt:~4,2%-%ldt:~6,2%.%ldt:~8,2%-%ldt:~10,2%-%ldt:~12,2% @REM *** EXECUTION ***@REM Change to mysqldir c: cd %mysqldir% @REM dump/backup ALL database, this is all in one line mysqldump -u %mysqluser% -p%mysqlpassword% --databases %mysqlschema% --routines --events --triggers --quick >%BackupDir%\%mysqlschema%_backup.%datestamp%.sql @REM - Housekeeping forfiles -p %BackupDir% -s -m *.sql -d -%housekeepafter% -c "cmd /c del @path"   Configuration   Input your DB connection details and desired backup save location.  All details that need changing are in []. Make the changes without the [].    e.g. SET mysqlschema=[Your DB schema name] may change to  SET mysqlschema=EpochDB   SET BackupDir="[Where you want to save the backups]" May change to  SET BackupDir="c:\DB-Backups"   Housekeeping will clear any .sql files that are over housekeepafter number of days old.   You may need to confirm the MySQL path for the mysqldump exe as it may depend on your provider.   Add "read" (without "") at the end of the file to require an input for debugging.  This allows you to check the test backup is ok and troubleshoot any issues.  Remove it when automating or the .bat file will never close.  Automation can be done via Windows task scheduler.  Create a basic task and then edit the tasks parameters after creating if you want to backup more than once a day.  The option is only available after the task is created.  
Revision History.
 
Current version: v1.1
 
Changes:
 - Amended code to cope with US & UK date formats when calculating the resulting .sql files datetimestamp included in the filename.
 
Previous versions:
v1.0: Initial version.
 
Possible future improvements.
 
I may add an option to compress (zip) the files if there is enough interest.
 

FIrstly, these threads, from a attempt to force a change, are doomed to failure just like the threads requesting the A2 Epoch hiveext.dll be amended with lots of good reasons for doing so were.  History shows that the Epoch team are very unlikely to change anything to do with the undelying core tech choices once that choice is made.
 
Bottom line is that it is their mod and their choice.
 
These threads can, however, bring forward some interesting discussion points amoung the chaff.
 
 
Any chance of these benchmarks being published so we can see them.  Would be very interested.
 
 
Performance should not always measured purely on speed.
 
Rule number one: Best fit for the purpose.
 
Most sensible people would not buy, even if they could, a rocket car to get their monthly supermarket shopping :) .
 
Personally, off the top of my head, I would measure performance for an Arma mods persistant layer on (in no particular order);
Speed of communication (TPS)
Supportability (within A3 Epoch server management scope)
Stability
Support (for the technology by the releasing entity)
Ease of connectivity / maintenance of connectivity (between persistant store and Arma).
 
We chose extDB for our A3 mod based on these above criteria.
 
====================
 
@Everyone.
 
I have yet to see an investigation that points to MySQL being a bottleneck to A2 Epoch that is able to rule out;
1. The A2 engine callext function being a limiting factor.
2. The Hiveext.dll being a limiting factor.
3. The underlying server hardware being a limiting factor.
 
If anyone knows of any investigations that have then I would love to know as they would be very interesting.
 
Unfortunately when there is a slowdown with data that has to be pulled from an external source, in A2 at least, the common knee jerk reaction is that it is the DB server that is the problem.  The DB being the choke point may not be the case and TBH I would be very surprised if it was with MySQL.
 
Would be interesting to see;
1.  if there is a difference between the hiveext.dll and extDB.dll (I believe someone was porting over A2 EPoch to extDB) for trader slowdown using the same MySQL DB. 
2. If a MySQL DB hosted on a ram disk still has the same issue.

To clear up any confusion...
 
A Plot for Life.
 
For Plot Owners
A Plot for life allows you to build on any plot you own including after death. 
 
For people tagged as friendly
It also alows you to build on someone elses plot if you have them tagged as friendly and after you look at the owners game character one time after logging in (each time you login).  This is to prevent people building on plots you own without you at least being aware some building is going on (a 'friend' deciding to grief your base cannot do so if they login and cannot look at your game character that session).  That feature is standard Epoch.
 
Take Ownership (can be turned on or off)
Takes ownership of all buildable items and assigns these items to the current plot pole owner.  If someone else has built something on your plot then you don't have to do 6 cycles to remove it (friendlies take twice as long to remove as the items owner in standard Epoch).  You also need ownership rights to remove the majority of buildables.  You can raid and hold a base but cannot build and remove as if it was built by you unless you are able to take ownership (unless other custom mods have changed the standard Epoch behaviour).  Locked items are excluded from the take ownership function meaning you still have to tran and break in to safes and locked doors.
 
Open doors and safes you own without needing to supply a combination.
This was a feature half implemented in Epoch but which could not be fully enabled due to how the object ownership data was stored with lockable items.  That has been fixed with A Plot for Life so owners do not need to provide codes for locks they own but still do for locks they do not own.
 
Merged with Precise Base Building and Snap Build Pro.
No need to install these mods seperately as they are already included merged and ready to run.  A new version of Vector Building is also completing testing to be compatible with A Plot for Life v2.5 and should be out soon.
 
Code optimisation.
During the development and maturity of A Plot for life, various other bits of the Epoch building system code have been 'tweeked' to make them more efficient.  Some common code blocks have been given their own external functions to cut down on code duplication and reduce file size. 
 
Plot management adds a nice simple GUI for plot builder management, enables building after death and removes the need for plot friendlies to 'see' the plot owners each time they login before they can start building.  It also has a version that integrates with the Single Currency system for paying for maintenance. 
 
Using both together is pretty simple and gives the functionality of A Plot for Life with a nice simple GUI for builder managment.
 
A scroll wheel system for builder management (add / remove builders, turn build rights on / off without builder removal etc), is planned for the next version of A Plot for Life but there is no current ETA (ie. it will not be soon).  I am currently spending some time on our new Arma 3 mod - Dominion.

To clear up any confusion...
 
A Plot for Life.
 
For Plot Owners
A Plot for life allows you to build on any plot you own including after death. 
 
For people tagged as friendly
It also alows you to build on someone elses plot if you have them tagged as friendly and after you look at the owners game character one time after logging in (each time you login).  This is to prevent people building on plots you own without you at least being aware some building is going on (a 'friend' deciding to grief your base cannot do so if they login and cannot look at your game character that session).  That feature is standard Epoch.
 
Take Ownership (can be turned on or off)
Takes ownership of all buildable items and assigns these items to the current plot pole owner.  If someone else has built something on your plot then you don't have to do 6 cycles to remove it (friendlies take twice as long to remove as the items owner in standard Epoch).  You also need ownership rights to remove the majority of buildables.  You can raid and hold a base but cannot build and remove as if it was built by you unless you are able to take ownership (unless other custom mods have changed the standard Epoch behaviour).  Locked items are excluded from the take ownership function meaning you still have to tran and break in to safes and locked doors.
 
Open doors and safes you own without needing to supply a combination.
This was a feature half implemented in Epoch but which could not be fully enabled due to how the object ownership data was stored with lockable items.  That has been fixed with A Plot for Life so owners do not need to provide codes for locks they own but still do for locks they do not own.
 
Merged with Precise Base Building and Snap Build Pro.
No need to install these mods seperately as they are already included merged and ready to run.  A new version of Vector Building is also completing testing to be compatible with A Plot for Life v2.5 and should be out soon.
 
Code optimisation.
During the development and maturity of A Plot for life, various other bits of the Epoch building system code have been 'tweeked' to make them more efficient.  Some common code blocks have been given their own external functions to cut down on code duplication and reduce file size. 
 
Plot management adds a nice simple GUI for plot builder management, enables building after death and removes the need for plot friendlies to 'see' the plot owners each time they login before they can start building.  It also has a version that integrates with the Single Currency system for paying for maintenance. 
 
Using both together is pretty simple and gives the functionality of A Plot for Life with a nice simple GUI for builder managment.
 
A scroll wheel system for builder management (add / remove builders, turn build rights on / off without builder removal etc), is planned for the next version of A Plot for Life but there is no current ETA (ie. it will not be soon).  I am currently spending some time on our new Arma 3 mod - Dominion.

Edit the first post, go to [more reply options] and then you should be able to edit the title :) .

Edit the first post, go to [more reply options] and then you should be able to edit the title :) .

Have a look on the first post for links on how to use diffmerge to combine.

Cool,
 
Ok so for debugging.....
 
Right, think I have seen the issue....
 
Open fn_check_owner.sqf (under compiles folder).
 
Find
if (_playerUID in _friendlies) then { Change to 
if (_ObjectOwner in _friendlies) then { Let me know if that fixes it and if so I will amend the Github and Dropbox code and release the fix.

You would need to change
_classnameProtected = "Wooden_shed_DZ"; into
_classnameProtected = ""; _ProtectedClasses = []; // put in all the classes you want to protect. You would then need to put all after
_vehiclePlayer = (Vehicle Player); In a count loop (ie. { ....... }count _ProtectedClasses ;) and add after it
_classnameProtected = _x; The
}count _ProtectedClasses; needs to go before the last
}; That would probably work for multiple classes.

Have just rewritten a script for MatthewK to try and help out (thread ) and though I would release for all to enjoy.
 
Set the _classnameProtected to a class name of an object you want to protect.  Classnames are types of objects.  In the code below it is all wooden DZ sheds. 
 
Save the following as something (i.e. mpmissions\[MAP NAME]\Custom\RingOfProtection\RingOfProtection.sqf)
// Ring of Protection by RimBlock (http://epochmod.com/forum/index.php?/user/12612-rimblock/) // // This script will allow you to set two rings around an object (vehicle, building, player). The first ring will create a warning, the second will kill the player. // // Completely rewritten from initial code by [MIC] Murcielago. Private ["_n","_classnameProtected","_nearbyProtected","_vehiclePlayer","_nearestProtected","_warningRange","_deathRange","_nearbyProtected","_aliveNearbyProtected"]; _n = 0; _warningRange = 20; _deathRange = 7; _classnameProtected = "Wooden_shed_DZ"; While {True} Do { _nearbyProtected = []; _aliveNearbyProtected = []; _nearestProtected = ""; _vehiclePlayer = (Vehicle Player); _nearbyProtected = nearestObjects [_vehiclePlayer, [_classnameProtected], _warningRange]; if ((count _nearbyProtected) >= 1) then { { if (alive _x) then { _aliveNearbyProtected set [(count _aliveNearbyProtected),_x]; }; }count _nearbyProtected; if ((count _aliveNearbyProtected) >= 1) then{ _nearestProtected = _aliveNearbyProtected select 0; If ((_vehiclePlayer Distance _nearestProtected) < _deathRange) Then {Player Setdamage 1;}; If ((_n == 0) && {_vehiclePlayer Distance _nearestProtected >= _deathRange}) Then { TitleText ["[WARNING]: Entering restricted area. Continuing will result in death.","PLAIN"]; }; _n = _n + 0.05; }; }; Sleep 0.05; If ( _n > 1 ) Then { _n = 0; }; }; Put the following in your custom compiles.sqf (just after "progressLoadingScreen 0.8;" should work).
ringOfProtection = compile preprocessFileLineNumbers "Custom\RingOfProtection\RingOfProtection.sqf";     Call it (probably from the init.sqf)  after the line "_playerMonitor = ..." with
[] spawn ringOfProtection; Note this is likely to have at least a small impact on each player.
 
Possible future upgrade:
 It could probably be addapted to a single item (i.e. admin base) but the item would need to be tagged (i.e. with a setvariable item "Protected" true type but of code) and then after the item classname is detected in range, the variable can be checked to see if that one in particular is protected.
 

Epoch Better Refueling.
 
GIThub: Better Refueling.
Dropbox: Better Refueling.
 
Overall status: This is now a work in progress. 
Current Phase being worked on: Phase 1 & 2 [Fuel truck Beta released].
 
Overview
This is a  mod aimed at improving the fuel pump / fuel truck setup in Epoch. 
 
Current release.
Realistic fuel capacity for air and sea vehicles (an AH6 is faster to fill than a Blackhawk for example). Faster flood fill for large vehicles from the fuel truck. Refueling 'cycles' depend on capacity from the fuel truck. Choose which vehicle in range to refuel from the fuel truck. Fully configurable via variables.  You can change Flood fill vehicle list (default is realistic vehicles) Vehicle capacities (default is actual vehicles fuel capacities) Fuel Truck fueling litres / cycle (default would be realistic if one cycle = 1 minute - which it does not) Flood fill litres / cycle (default would be realistic if one cycle = 1 minute - which it does not) Fuel truck refuel range. This project is being done in my own spare time and will be provided to all, free of charge.  Peoples entitlement level is directly relational to the cost :D.
 
I am very happy to have others join me in creating this mod. I firmly believe in pooling resources from the community to make a better end product. If you wish to join me then let me know here or PM me. All contributors will be listed here and in the readme file that will come with the mod download.  Contributors can, of course, remain anonymous if they prefer.
 
Planned features by phase
(current status in []);
 



 
Install Instructions
 



 
Other contributors to this project.
 



 
Comments, suggestions, desirables all welcome. 
 
RB

Nope, I don't want you to do anything.
 
If you wish to use my mod that has taken many hours to put together and that I am giving to the community for free then yes, you have to actually do a bit of work.   If you use diffmerge the process is fairly simple and Raymix has produced a video guide which actually includes a older version of this mod as an example. 
 
Why not write some instructions yourself to share with the community, you know, giving something back.  Strangely, of the few people who have commented there is not a step by step guide, no one has made the effort to actually create one in order to help others when I have suggested it.
 
Me, I am spending my spare time (the time not spent working in my regular job, or doing stuff with my wife and kids).
Bug fixing issues reported.
Adding improvements for the next two versions for this mod, testing and releasing.
Writing and Releasing other scripts / mods.
Helping others here, on Skype and via PM with various problesm, quite a few of them having nothing to do with this mod.
Working on our A3 Dominion mod (most mod makers stop with the A2Epoch mods when they move to working with A3.  I have not done that).

Hiya,
 
From a DB point of view there is no difference between v2.34 and v2.4.  You should just be able to load your object table straight in and it will work.  For A Plot for Life, the buildables will still belong to the right players (the SteamID used is the same on all servers).  I suspect it will all work TBH without needing to Take Ownership.  Copying all the DB tables over should make sure it will all work fine.  v2.4 is really just a big tidy up of the code to reduce size and make it easier for people to integrate with other mods.  There are a few small additions but functionality and the way the scripts implement it is pretty much the same.
 
Test if you can first but you should be pretty safe.

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.
 

The easiest way to try and find out what is causing the problem is by using the diag log format command to report on what the variable is before it errors on that line.  It may produce quite a lot of debug lines in the client RPT file but it will show you what is getting passed to that line in the variables and will help to track back.
 
Something like
diag_log format["[fn_selfactions] Line 653 [dayz_combination: %1], [_ownerID: %2], [_playerUID: %3]",dayz_combination, _ownerID, _playerUID]; At line 653 of the fn_selfactions.sqf file.
 
When the bug hits, take a look at what the values were.

The RPT file you posted said the error was on line 654 of your fn_selfactions.sqf file.  Putting the diag_log line in before that error (the if statement) will report what the error is.  If you have changed the fn_selfactions.sqf file so the error is no longer on line 654 then you will need to work oput where to put the diag_log line to match..  

attachto command ;) .
 
You can supply an offset to central point or a predefined attach point (if you know them). 
 
setVectorDir and setVectorUp (or setVectorDirAndUp) should allow for correct facing of the object.
 
Have fun :D .

I am saying exactly what I said.  I built the mod for Epoch and not for Overpoch.  Whether it works for Overpoch or not 'out of the box' is something I do not know as I have never tried.
 
What I do know is that a number of people run it on Overpoch servers but I do not know what, if anything, they changed to get it to work.  I also know that I do not support installations on Overpoch.
 
If someone wants to try amending A Plot for Life so it will work on Overpoch.
 
Saying lockboxes and vaults do not work with A Plot for Life installed without saying it is on Overpoch (which it was never designed to work on) seems a little unclear.  If it was not working on Epoch then it would be something I would look in to and try to rectify if I could recreate the issue.
 
If you search my thread for the A Plot for Life mod for "Overpoch" then you would probably get an idea of people who may be able to help.