Suggested DB Enhancement: Update Owner of Plot Pole(s)

[uro666]

Database trigger to automatically update CharacterID's on classname 'Plastic_Pole_EP1_DZ'

Would stop players having to deconstruct and rebuild plot-poles to maintain thier bases.

I know death is part of the game, but it's one of those niggly things that bugs me about the plot poles :)

Maybe add it as an optional SQL script? As I understand some people like having to have to deconstruct/destroy plotpoles to be able to build again ;)

Code:

DELIMITER ;
DROP TRIGGER IF EXISTS dayz_epoch.`update_owner`;
DELIMITER //
CREATE TRIGGER dayz_epoch.`update_owner`
AFTER INSERT ON dayz_epoch.character_data
FOR EACH ROW
BEGIN
UPDATE dayz_epoch.object_data SET CharacterID= NEW.CharacterID WHERE CharacterID IN
(SELECT CharacterID FROM player_login WHERE PlayerUID= NEW.PlayerUID)
AND Classname = 'Plastic_Pole_EP1_DZ';
END//
DELIMITER ;

[thebigcarp321]

I agree. We have a no pvp server and our players like having a permanent residence.

[uro666]

@vbawol Would coding this into the HiveExt.dll be an option ?

Binary logging is enabled on quite a lot of server hosting companies SQL servers and therefore triggers like this would not be allowed.

[Skaronator]

Would be easier to change the CharID to PlayerUID in the Place scripts.

[jostster]

This will require the server to be restarted before the player can build.

[jostster]

@Uro1 see http://epochmod.com/forum/index.php?/topic/9366-keep-your-plot-pole-after-you-die/

[uro666]

The trigger I posted doesn't require a restart, but doesn't work with binary logging unfortunately, which it would seem a lot of server hosting companies run thier mysql with.

I'll test the above later with binary logging, the only way something like this could make it into epoch would be if it is available to everyone as an option.

If server hosting companies have the feature blocked I can see why the dev team haven't already added this.

Edit:

There is one reply in that thread which states "use is not allowed on stored procedures". Which is the same report the database gave me when I tried my original post on a server host, as opposed to a dedicated server.

A DB trigger, is a DB triggger, which will not work with binary logging, which was my first thought when I looked at that thread.

[jostster]

What I am saying is for the user to be able to build after a death, the server will need to be restarted so that the object data that is stored in memory on the server is updated with the new character ID

[IjoreanGrey]

We had a system like this on the KillingZedz.net server, it causes massive lag. When a new player joins, or a new character is created the server will lag anywhere from 1-30 seconds. Binding plot poles to the UID is a much more effective option.

[jostster]

I have yet to see any lag issues on my 2 servers

[GeneralTragedy]

Why not incorporate this? :)

http://epochmod.com/forum/index.php?/topic/9552-howtorelease-tie-playeruid-to-all-buildable-objects-keep-plot-pole-after-death-no-sql-triggers-update-16042014/

[Darklordd]

easier as Skaronator said change charid to playeruid and more better for DB cleanup

[uro666]

It could be setup as an init.sqf variable DZE_PlotpoleToUID = true; If it was coded into the mod then would save bringing so many files mission side to create a workaround for it There's already a ton of forum threads about this now and various different ways of doing it.

@vbawol any chance of adding a variable for the option of tying to playeruid instead of character id ?

As mentioned above it would make db cleanups a ton easier as admins would only have to search for the applicable player uid instead of trawling through the db looking for positional data, or using an admin tools for base removal.

plus most hosted servers don't have the option of adding my trigger due to the way gsp's setup thier databases. binary logging etc. as my way is done in real time.

[hogscraper]

I have the work around going on my test server where I had to manually change all instances in code of get character id to call custom get player id function. This is a long route to do but simple route of simply changing over to use player id from start would mean having to save player id to database wouldn't it? Would doing this mean a db wipe? You would have to delete character id column, (length 11), and replace with player id column, (length 20) to ensure players with newer or longer player ids didn't throw errors on write to column. Not sure of easy way for server admins to incorporate without losing ownership of everything already in db unless maybe a new column could be tacked onto the end of the line so the entry has both ids?

[RimBlock]

Having just written a mod (http://epochmod.com/forum/index.php?/topic/11042-release-a-plot-for-life-v11-keep-your-buildables-on-death-keep-historic-buildables-turn-on-boundary-markers-from-plot-pole/) based on the idea of tying playerUIDs to the characterID field of the object_data table I would strongly advise against it.

The PlayerUID DB field is varchar(20) and the CharacterID field is integer. Not only is the integer field limited to 11 digits in the hive, the max integer number is 2147483648. With BIS now adding characters to the PlayerUIDs, they would have to be converted to numeric which can lead to either blowing the max int value or ending up with a potentially non unique id.

I will be writing a new mod using the characterID field for the plot pole as an id field for all buildables linked to it. The owner and authorised builders will be stored in the inventory field of the plot pole as a two level array. The Inventory field is a long text with a max character limit around 2 billion.

[GeneralTragedy]

I like your solution, but I'm not sure it is feasible for most servers. The reason is because most dayz hosting providers (HFBServers and Dayz.st for sure...) don't allow the ability to create and use functions in the database for security reasons. So, that would "break" your functionality for a significant number of servers.

[RimBlock]

My Plot for Life mod only uses the DB function to realign histocally built items to the new playerUID system (i.e. one time use). I may be able to write a script to do this available to a nominated playerUID which they can run once and then disable via an init.sqf variable. That would take out the need for any DB code.

The proposed solution would be pure script based. It may also be possible to update the historical stuff via script rather than DB functions although it would not be quite as simple to write :-).

[icomrade]

Should be a non-issue now when using the Plot For Life mod now included with 1.0.6