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

[RimBlock]

Well, well, well....

 

This guy above (who posted as I was writing this :D ) has just filed a bug report on GitHub suggesting a change to the characterID field size and vbawol has suggested trying changing the object_data.characterID to a bigint.  That would allow the steamID to fit inside without any changes needing to be made to the mod at all.....

 

As long as there is no gotchas in the hiveext.dll code on field size or type, then that would be a massive win.

[RimBlock]

 

Would performing this sql-statement on the object_data table help?

 

(beware, I did not yet test it)

ALTER TABLE object_data MODIFY COLUMN CharacterID bigint

 

Quite possibly.  Just this moment have seen your bug report on GitHub (and have added to it).

 

Will test tonight.  should be home in around 3 hours.  I have all my fingers and toes crossed.  If it works I can go back to my v2 using an extended hiveext.dll and all Plot For Life v1.1 users only have to run the alter table command to get their systems working again.

 

Anyone seen any letters in the SteamIDs or are they all numeric ?.

[RC_Robio]

Seriously, the above would be a life saver. Watching this thread develop. Also where could someone find their steam id? 

[Pro_Speedy]

I'm guessing this ID would require us to change things like infiSTAR id's and Loadout ID's and Goodl uck Rimblock getting this working for Steam

[ekroemer]

This https://developer.valvesoftware.com/wiki/SteamID seems to suggest integer (as they are performing calculatiions with it)

 

@Pro_Speedy: I can confirm that regarding InfiStar it's sufficient to simply exchange the old ID for the new, no type constraints, here.

[RimBlock]

Please do note that this may fix the mod but it will not convert BIS PlayerUIDs to SteamIDs.  That, currently, is manual work as there is nothing found so far to link the two.

[RimBlock]

This https://developer.valvesoftware.com/wiki/SteamID seems to suggest integer (as they are performing calculatiions with it)

 

@Pro_Speedy: I can confirm that regarding InfiStar it's sufficient to simply exchange the old ID for the new, no type constraints, here.

 

Thanks for the link.

 

As Represented in Computer Programs

When represented internally in computer programs the X, Y and Z components (see the section titled 'As Represented Textually') are all packed into a 64-bit data structure.

• The low 32 bits represents the ID number for the account (the "account number").
• The next 20 bits represents the instance of the account. It is usually set to 1 for user accounts.
• The next 4 bits represents the type of account.
• The next 8 bits represents the "Universe" the steam account belongs to.

 

 

If they are all numeric then bing, bang, boom... just change the field DB datatype and you are good to go. 

 

The simplist answers are always the best.  :D .

 

Have also updated OtterNas3s thread for his Evac mod as this should also fix that too.

[RimBlock]

Seriously, the above would be a life saver. Watching this thread develop. Also where could someone find their steam id? 

 

You should be able to see it in-game from the main menu.  Not sure what sub-menu but maybe under options.  I am sure someone else has the specifics.

 

Update:  It is off the main menu under player profile -> profile name -> [edit] to view

[ekroemer]

 

Please do note that this may fix the mod but it will not convert BIS PlayerUIDs to SteamIDs. That, currently, is manual work as there is nothing found so far to link the two.

...and there won't be.

 

The 2 numbers are completely unconnected and while one might write a set of sql statements that would match character names, replace the UID in the old character and delete the new one, this would barf at duplicate player names and still need user interaction (new character needs to be logged out when being deleted).

 

So, not worth the hassle to even try, imo.

[RC_Robio]

Going to sound like a noob here. When you say in game menu, do you mean steam server browser, or the in-game Arma server browser? I have always used Arma 2 Launcher to join games or fire up Dayz Commander every once in a while.

Thanks.

[RimBlock]

Start ARMA 2 OA and it will take you to a menu with Multiplayer, Options, Player Profile, Expansions and Exit. 

[RimBlock]

Alter table sql

 ALTER TABLE `DATABASENAME`.`object_data` CHANGE COLUMN `CharacterID` `CharacterID` BIGINT UNSIGNED NOT NULL DEFAULT '0' ;

DATABASENAME = You Epoch Database Name.

 

Updating to the latest Beta with SteamID identifier.  Will update on base testing after done.  I am testing with the original Plot For Life v1.1 for Epoch 1.0.5.  If that works then will update and test for 1.0.5.1.

[ekroemer]

Copy from my GitHub 'bug' report:

 

This approach doesn't work for me when trying to ID-lock safes or vehicles

I tried my simple statement and RimBlocks variant and while it seems to have no detrimental effect on the DB it doesn't work either: neither vehicles nor safes can be opened.

 

Details:

• phpMyAdmins overview listing of the tables rows shows my full 17 digit Steam-ID as CharacterID
• the detailed edit screen of one entry correctly says "CharacterID bigint(20) unsigned"
• but shows a 17 digit entry whose last 2 digits are incorrect (300 instead of 341 in my case)
• ingame InfiStars 'i' info of an object shows a 10 digit number: 2^11-1, that may just be the printf truncating but given that I cannot unlock, I doubt that.

And now?

[RimBlock]

Existing vehicles and safes or newly bought / placed ones ?.

[RimBlock]

Ok, for my part.  I can still get in my existing keyed vehicle (no reason why this would not work).

 

I cannot build items though as I am still getting the same 308 error

 

CHILD:308:11:Plastic_Pole_EP1_DZ:0:99999999999999999:[180.934,[9261.58,13422.5,0.101837]]:[]:[]:0:926161342251181:

 

The 999... is where my 17 digit SteamID would be.

 

I am concerned that the HiveExt.dll my have that field defined as an int which means it cannot handle the 17 character SteamID in that field.  Need to look at the C++ code which is not my area really although I can have a trawl through to see what I can find.

 

Update:

 

Yep, the characterID for a 308 call is listed as

int characterId = Sqf::GetIntAny(params.at(3));

sqf.h file has 

int GetIntAny(const Value& val);

Conversely, the ObjectUID field which is a bigint in the DB as default is defined as

Int64 uniqueId = Sqf::GetBigInt(params.at(8));

Defined in the same header file as 

Int64 GetBigInt(const Value& val);

So from what I can tell, the DB field is limited by the HiveExt.dll :mellow: .

 

Also updated the bug report with this info.

 

vbawol may take a look at modifying the hiveext.dll to support.  Fingers crossed.

[ekroemer]

Existing vehicles, but maybe I haven't made myself clear:

 

The normal key (4 digit CharacterID, normally) still works fine.

But when I overwrite this (in the DB) with the SteamID (just as I did with the PlayerUID before), I cannot open it.

Normally I would expect to be able to open it without a key or, in case of the safes, without having to enter the code.

[RimBlock]

Ok,  understood but outside of the functionality of this mod.

 

Good to note though.  I always just align to a single key for all my vehicles.

 

The hiveext will be truncating on read and failing on write to the DB hence the issues.

[BetterDeadThanZed]

Maybe you can convince vbawol to make the use of the UID standard for building instead of Character ID :)

[ekroemer]

Ok,  understood but outside of the functionality of this mod.

Yes, I know, but it's the same underlying problem.

 

 

The hiveext will be truncating on read and failing on write to the DB hence the issues.

I'm afraid so, I hope the devs can do something about this, hence my plea on GitHub....

[cen]

Tried to use that SQL query but tested and it still doesn't write the objects to the database.

[McPimpin]

Can you give some instructions on how to revert this? 

[BetterDeadThanZed]

Can you give some instructions on how to revert this? 

 

If you use a full copy of the compiles.sqf, then you'll need to revert the changes you made, otherwise if you are using a second, custom compiles.sqf, just remove the lines you added.

[RimBlock]

Tried to use that SQL query but tested and it still doesn't write the objects to the database.

 

Check out the No solution is currently found.  Still working on it.

 

BIS have released a new command in the latest beta called "GetPlayerUIDOld".  On the face of it, this sounds great and the Epoch team have already made some changes to the base code (with an optional switch to turn it on or not).

 

I have concerns that it will not handle new players who do not have a BIS PlayerUID in the server DB already and suspect using it for anything other than scripting a conversion from PlayerUID -> SteamID for existing players will most likely break.  I could very well be wrong (and sorta hope I am) but there seems to be no info on its functionality and a lot of knee jerking going on.

 

I have asked the question concerning new players in the GitHub issues list and have also asked on the BIS OA Beta thread so we can get some clarity.

[RimBlock]

First alpha test with putting the SteamID in the worldspace object_data field seems to be good.

 

I have built a plot pole and cinder garage door and it has saved them to the DB with my SteamID in the correct place (the plot pole ownership worked for building the cinder garage door).  Still lots to test but it seems positive so far. 

[RimBlock]

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