RimBlock

Really ???  Who said that ?.
 
 
What mods have you produced free for the community ?.
 
So since the last update;
Config changes for realistic fuel values (air and sea vehicles).
Pushed realistic fuel values to the Epoch config files for air and sea vehicles which were merged by the Epoch dev team. Gamespy -> Steam fiasco resulting in;
A complete rewrite of A Plot for Life. Push for A Plot for Life to be added to the Epoch core build
An extensive rewrite of A Plot for Life to align it with Epoch 1.0.5.2 and to enable it to be an option to save people having to go through the hassle of merging files. Due to delays with Epoch 1.0.5.2 coming out and the Dev teams concentration on A3Epoch, convert to allow use as a standalone mod for 1.0.5.1.
A medium rewrite to allow people to use it with 1.0.5.1 as a mod. General discussions on the build functions.
Working with Raymix on the modular building framework for Epoch 1.0.5.2. Due to issues of merging various mods.
Built a merged version of A Plot for Life incorporating Snap Build pro and the Modular Building Framework (with Raymix s agreement), both optionised so they can be turned on or off. People having issues with historic bases having to be rebuilt if using A Plot for Life.
Built a Take ownership option and added it to A Plot for Life allowing base owners to realign their bases to the new system for recording base ownership. Plot pole markers having limited control.
Added the option to turn plot markers and turn them off again and changed them to lit road cones to help night building (sort of fun addition for a change).  
On top of that has been the code management (learning the basics of Github releases / branches etc), daily support for A Plot for Life releases including issues with merging other mods.  That is, of course, excluding normal work and family life.  Essentially the last 3 months have been pretty busy with a large proportion of my spare time being spent working on stuff for the Epoch community.
 
A Plot for Life is finally fairly stable and is unlikely to be added too going forwards (just bug fixes).  I have some time to get back to this now.  
 
Epoch 1.0.5.2 RC build (now changed to 1.0.6) being delayed time and time again means I cannot use the updated config files.  Although I can code around their need, I would then need to re-code again when they are released for better efficiency.
 
Your post and attitude makes me a lot less likely to spend any more of my own free time on this.  It also makes me a lot less likely to help you in one of your scripting help posts if I happen to come across any.
 
You could have just PM'd me for an update (like Hellwalker did) or asked me to update the thread via PM as I don't always catch individual thread updates, but no... you thought making that comment was by far the most intelligent and funny thing to do.
 
Good job moe.
 
I will take a look today to see if I can get the small rounding issues with the refueling from the fuel truck fixed and if so will release that part shortly.

Good one. RimBlock should release code so you could help him out finishing it, right? Because you are such a nice person and would love to contribute your free time to help develop this community.
I think that's an amazing idea, pretty sure Moe wouldn't mind spending few months learning to script to release something for free.

Really ???  Who said that ?.
 
 
What mods have you produced free for the community ?.
 
So since the last update;
Config changes for realistic fuel values (air and sea vehicles).
Pushed realistic fuel values to the Epoch config files for air and sea vehicles which were merged by the Epoch dev team. Gamespy -> Steam fiasco resulting in;
A complete rewrite of A Plot for Life. Push for A Plot for Life to be added to the Epoch core build
An extensive rewrite of A Plot for Life to align it with Epoch 1.0.5.2 and to enable it to be an option to save people having to go through the hassle of merging files. Due to delays with Epoch 1.0.5.2 coming out and the Dev teams concentration on A3Epoch, convert to allow use as a standalone mod for 1.0.5.1.
A medium rewrite to allow people to use it with 1.0.5.1 as a mod. General discussions on the build functions.
Working with Raymix on the modular building framework for Epoch 1.0.5.2. Due to issues of merging various mods.
Built a merged version of A Plot for Life incorporating Snap Build pro and the Modular Building Framework (with Raymix s agreement), both optionised so they can be turned on or off. People having issues with historic bases having to be rebuilt if using A Plot for Life.
Built a Take ownership option and added it to A Plot for Life allowing base owners to realign their bases to the new system for recording base ownership. Plot pole markers having limited control.
Added the option to turn plot markers and turn them off again and changed them to lit road cones to help night building (sort of fun addition for a change).  
On top of that has been the code management (learning the basics of Github releases / branches etc), daily support for A Plot for Life releases including issues with merging other mods.  That is, of course, excluding normal work and family life.  Essentially the last 3 months have been pretty busy with a large proportion of my spare time being spent working on stuff for the Epoch community.
 
A Plot for Life is finally fairly stable and is unlikely to be added too going forwards (just bug fixes).  I have some time to get back to this now.  
 
Epoch 1.0.5.2 RC build (now changed to 1.0.6) being delayed time and time again means I cannot use the updated config files.  Although I can code around their need, I would then need to re-code again when they are released for better efficiency.
 
Your post and attitude makes me a lot less likely to spend any more of my own free time on this.  It also makes me a lot less likely to help you in one of your scripting help posts if I happen to come across any.
 
You could have just PM'd me for an update (like Hellwalker did) or asked me to update the thread via PM as I don't always catch individual thread updates, but no... you thought making that comment was by far the most intelligent and funny thing to do.
 
Good job moe.
 
I will take a look today to see if I can get the small rounding issues with the refueling from the fuel truck fixed and if so will release that part shortly.

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.
 

What you have proposed is a way to read the values.  There is no unified way to write them though.  Some mods have modified the server object publish scripts and some just modify the worldspace data before it is sent to the server.  Something that is unified on both sides of the equation would be more balanced.
 
Having to scan the worldpace variable each time you want to save it to find the correct position for the data you want to save rather than using a lookup table (global array) to tell you the position to save that data (could be populated on server load I guess) would seem to be pretty inefficent.
 
A couple of other poiints on why a guide rather than a server pack may be better;
If the server owner only wants one or two of the mods, the clients still have to download all the mods code making a bigger download on connection (mission.pbo or code is not pbo'd). VBAwol has on the forums. Put a guide together on how to merge based on this framework.  I am sure there are lots of people out there who will be extremely grateful.
 
It would probably be prudent for someone to check the max data size for a buildable item (i.e. a safe) with max items, all having long names and sample info from all the mods and see if the ext.dll limit causes issues. 

Thanks for taking the time to look at the mod and solutions for people using infinistar.  Unfortunately the standard Epoch hiveext.dll does not allow updates that would allow me to just add ownership to the objects so I have to delete and recreate.
 
 
 
Yes.... and no.
 
The code that manages you being able to unlock locked items you own without needing the code has been in Epoch since 1.0.4.2 (possibly earlier but this is the version I started with).  The problem was that locked items had no ownership information stored as the cahracterID field was used for the locks code.
 
Moving the ownership info away from the characterID field now means the ownership of the locked item can be checked and the lock code is also stored :).  This results in the feature you are now seeing. 
 
There were some posts about it earlier in the thread and it is noted that some people would rather their players use door codes so they are forced to remember them (less admin resets).  The ideal solution (within the current framework) would be to have auto unlocking for the owner but allow them to manually change the lock code with an option in the action menu. 

Believe you suggested that and PoweredbyPot responded  I expect you would have to wait until the mods are all added to the next Dayz Epoch release (whenever that may be) if the mod makers wish them to be added.
 
@ calamity
 
Try taking a look at you dayz_spaceInterrupt.sqf .  Raymix is better placed to be able to advise you on this though.

@ havoc302
 
He said that efforts had been made (by myself) but just about no-one approached responded when the subject of collaboration was raised (to the point of not even replying).  Raymix was a notable exception and so we have been working together to make it easier for people installing both of our mods.
 
I have also instigated a suggesting a unified way of handling the worldspace field for different mods, which no one replied to for a month.  
 
It seems to me that, as I have been trying to get people to collaborate, coming to this thread where collaboration is happening and 'suggesting' that people should collaborate more is a bit counter productive.  Saying ' sounds to me like there wasn't much effort made' to the person who has made the effort is borderline offensive.  
 
Surely the suggestion should be made to the mod makers who have not shown any interest in collaborating rather than telling one of the only two guys who is collaborating that he should be making more effort.
 
Please remember we do this in our own spare time and provide these mods for free and then support them as best as we can.  Most mods take many hours to put together , test and debug.  Some people do not want to share the 'kudos' for creating a popular mod or loose full control of it which is why it is generally better to have them absorbed in to the core Epoch build although some mod makers would rather not have that done either.
 
If you feel that not enough effort is being made to get people collaborating then I would suggest you lead by example.  You can then supply all the effort needed getting all the mod makers you mentioned to put all their code in to a single mod.  Let me know when all the other mod makers sign up for it. 
 
I am going back to writing, testing and debugging my next mod whilst supporting this one, trying to manage 3 kids and an aircon servicing guy who is currently working on our aircon units.

I will have a quick browse a bit later but it is usually like trying to spot a needle in a 1000 line haystack.  Any .prt errors on server or client ?.  You can try using windiff or diffmerge to highlight the differences between your copy and the vanilla Epoch copy which may help.  Both are in the post "Tools..." linked in my sig below.
 
Spoiler tags are (spoiler) (/spoiler) -- replace () for []

New version up (v2.33) fully merged with Snap Pro v1.41.
 
Tested working with modular build framework and snap pro.
 
Links in the first post.  Install instructions in the download zip or on the Git (also linked in the first post).
 
Post up bugs as you find them please.
 
@Raymix,
 
I have added a new variable (global) for the path of snap_build.sqf as I see it is called from within itself.  This made it easy to define in the compiles.sqf once with the other modular / snap pro defines and that single define then takes effect wherever it is needed (took me a bit to track them down  ;)  ).
 
All files taken from your Git so should be the latest.  Your git and thread are also referenced in the install and the link on the first page.

Cheers Raymix. I will touch base with you on Sunday as my wife has just told me we are all going to Pulau Ubin for an overnight stay. I do have my laptop but am unsure of the connectivity there. Go to commune with nature, bring all your technology with you :).

Have a look at compile / ui_selectSlot.sqf.  That seems to control what is displayed in the gear gui when an item is selected and the option(s) available for that item.
 
Have fun ;) .

Anything listed like "STR_EPOCH_PLAYER_53" is defined in the stringtable.xml file.  This is used to centralise strings and allow for different language translations using the localize function.
 
If you want to override it then just change it to text in the fn_selfactions file for maintenance.
 
(DZE_PlotPole select 0) should hold the current set plot radius for the server.
 
For building the plot pole, this one is more tricky as I believe it is using the displayName from the class files.  Some class files can be redirected but the ones relating to the buildables cannot.
 
You could possibly redirect the code that gets the class entry description from the class files if the class is for plot poles and then inject your own description rather than take the one from the class displayName.  SHould be pretty simple but you may have to dig around a bit to find out which script does that when in the gear menu.

Thanks for the mention Zupa.
 
A chance to break in would be good as I have been playing around with the idea of bobby trapping a door with a frag mod :D ....
 
Just as an aside, I am just writing the instructions for my add-on for A Plot for Life which gives a plot owner the option to take ownership of all buildables on the plot (excluding safes, lockboxes, tents and locked doors - all configurable).
 
Meant mainly for people to align their old buildables to the A Plot for Life v2+ system but would also allow raiders to place their own pole and take ownership.
 
If you are using the inventory (wep / mag / backpack) fields then is should work fine.  

update object_data set lastupdated = now(),      datestamp = now() etc .....   Also works well.

I guess he did, but i still think he made a bad decision when choosing not to include it in the final release.
 
Imho it doesn't matter if it's insecure or not. Like you said if it's insecure, tell us why and tell us the possible pitfalls, don't restrict but teach. People are going to find other ways to do it, people have already found other ways to do it. Which has not resulted in making the situation any more secure, in fact, i think the situation is becoming less and less secure.
 
Why? People want stuff like gold coins and they are just going to use that Hiveext.dll even if they have no clue of what's inside. The mere fact that you suggested it to me without having tested it or knowing what's inside supports that statement. Compiled C++ code cannot be decompiled, so there is no way of knowing what is inside those DLL files which automatically makes them a huge risk.
 
The only thing not releasing 998/999 publicly has achieved is that we now have a lot of people working on essentially the same stuff and reinventing the wheel over and over again, whilst we could of had a lot of very talented people making mods based on those 998/999 calls and in the process getting better at making it secure as possible.

Zupa made a hiveext.dll with 998/999 calls available in the single currency thread
 
I am not using it and have not tested at all.
 
VBAwol has flip / flopped on the subject a number of times on Github and I can see his point of... to an extent.  Unfortunately just citing the age old "Its insecure" does not in anyway help quieten down the baying masses who would like to leverage it.
 
I have adked VBAwol and a few others who trot out the "Its insecure" line what is so insecure that cannot be managed with server side sqf and DB security / restrictions and have yet to hear any sort of answer from anyone on this.
 
TBH I think the problem is that Epoch is pitched or has evolved in to an almost 'one click' install meaning lots of people out there without very much technical knowledge are able to run their own servers.  This has helped Epochs popularity greatly and I would imagine VBAwol and the other devs would like to keep this door open.  Supplying a Hiveext.dll with 998 / 999 calls with Epoch opens up large risks for server owners without any grounding in DB security and server side sqf coding if they implement it or mods using it.  This then causes massive knock-on effects support wise for the mod and is likely to damage its reputation. 
 
The dev team are stretched thin at the moment with the A3 Epoch work, the Twitch streaming.  Pull requests and work on DayZ Epoch seems to have slowed down significantly (My A Plot for Life pull request is still sitting waiting for inclusion in the Epoch code ;)  ;) devs....).  Cant see anything official happening with the hive at all.
 
There are also other options out there as well as using Zupas Hiveext.dll with the 998/999 calls.  ARMA2Net is one which Sanbird has extensive knowledge of.
 
For the people saying "Just go and make your own version.".  The hiveext is built in c++ which is a whole new kettle of wax ( ;)) to scripting in sqf.  A lot of people dont have the skill set and the majority dont have the time to learn it (myself included) and so we have to rely on others who do.

Cool.  Np.
 
Little update...
 
I have spent a bit of time working on the plot boundary markers and have created the ability to turn on and off the plot markers from the plot pole.  The downside is that this seems not to be possible for the current plot sticks as nearestObjects cannot see them (suspect something to do with the config files for them).
 
To this end I have changed the objects to road cones which works quite well although they are collision aware so can be hit / knocked out of place / fall over etc.  Another option would be coloured balls like those used in Snap Build Pro (thanks Raymix for sharing the code).  In theory anything can be used and I have even thought about using barrels.  Having a number of fire barrels lit around the plot site at night would probably look pretty good but we need to be mindfull of the impact to the engine and possible free advantage some items may give players.
 
What I will probably do is setup the plot marker as a variable along with some recommended class names for them.  Obviously some objects will be just silly but it is up to the server owners to decide what they would like to use.  I will also add in a variable for frequency to enable people to have larger gaps between markers.
 
When created, the plot markers have ppMarker put in their inventory and on removal, all items matching the markers defined object class are checked to see if they have ppMarker in their inventory before removal.  THis should stop removal of any items of the same class on the plot that are not part of the plot marker ring.
 
------
 
Update: Have found a few example of lightpoint scriots which may enable me to make flashing lights on to of the road cones (for example).  I may even do a funky disco light show just for fun and set a variable so server owners can choose to turn it on or not, maybe for admin events, or even give the option to admins so they can turn it on from any plot pole.
 
Will finalise the code, get it up on GitHub and package a release.  The code should be pretty simple to implement.
 
Oh and for those asking why I am bothering with this....
 
1. Technical exercise and to see what can be done with lights.
2. As a warm up for a 'Take ownership' option on the plot pole for plot owners.  A number of the methods used for this will be used for that function as well.

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.
 

So finally got round to having a play on my live box with my Plot for Life and this mod (thanks to PryMarys merged player_build.sqf).
 
All appears to work well (after adding in the fn_selfactions variables to variables.sqf).
 
The snapping does seem a litle strange with it building up a slight offset which compounds the more you build (higher levels in my case).  Understandable with so many missmatched types of buildables to try and cope with.  My build still came out pretty good.
 
One thing that came out a bit problematic was stairs.  They seemed to have difficulty being rotated if not snapped.  I was trying to build a set of stairs to wone side of a metal floor panel.  I snapped to the center back point, with the stairs top, of the metal floor panel above.  I then picked up the stairs to move them sideways and the stairs then rotated 90 degrees after dragging them slightly.  I could then not re-rotate them to any anger apart from left -> right or right -> left.
 
Snapping objects also sometimes rotates them 90 or 180 degrees.  This is easy to rotate back to where they should be but is another action required.
 
Everything else seems ot work pretty well.
 
Any ability to set a default value as I am having to turn on snapping, then choose manual snapping, then choose the snap point to use for snapping.  It would be good to be able to defauly to Snap on -> manual snap so I would just have to choose the snap point ot use.

Sure, just with the statement on the first page saying A Plot for Life is not required, it seems a little confusing.  I did see the comment on your original thread which is why I was a little surprised.
 
The concept is good.  Just suggesting making the downsides or functionality a little clearer.  Some may not realise that "always" also means after death (i know, i know but it may not occur to some).
 
Sure people should not add them unless they trust them but then people are people and don't always do what would seem to be the most logical thing.  The off shoot is that the admins will probably have to deal with any griefing so it is probably worth letting them know before they install it that this feature of Epoch vanilla has also been changed.
 
A suggestion to help mitigate the open build policy for PlotPals...
 
How about setting a couple more variables.
 
PlotCanBuild (Covers the whole plot for everyone).
PlotPalCanBuild (Covers individual builders enabling individual builders rights to build to be turned on or off).
 
Would be easy to store them in the inventory field
[PlotCanBuild],[[steamID], [buildername], [Canbuild]]
 
Amend the gui with two more buttons, one for changing the PlotPals build rights and one to change the whole plots build rights for all (only changeable by the plot pole owner and admins).  Would add much greater control and granularity to build rights on the plot and should be pretty easy to implement.

How about...
 
Save to the DB, save the object texture file name in the inventory of the item, on server load, read the texture file and re apply before placing in the world ?.

How about...
 
Save to the DB, save the object texture file name in the inventory of the item, on server load, read the texture file and re apply before placing in the world ?.

Np  :) .
 
Update for A Plot for Life v2.3 - The pull request is now in for merging with the Epoch Git.

Put the key in your backpack, sell the vehicle, put the key back in your toolbelt (or does it take the key from the backpack as well) ?.
 
Failing that, have a look at the previous release and the current one with the change you highlighted and see what code was changed.  That would be a starting point and you may be able to reverse it.