RimBlock
-
Posts
1140 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Articles
Posts posted by RimBlock
-
-
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).
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.
-
Have noticed a few issues in 1.0.5
- No map marker for my player (have map but not GPS or compass). Worked in 1.0.4.2
- Eye and Ear symbols missing from user UI. Worked in 1.0.4.2
- Exit menu counts down as normal. When abort is clicked the the confirmation box appears and the underlying previous menu starts the countdown again (no affect on exiting). Worked in 1.0.4.2.
Not sure if cleared in 1.0.5.1
Anyone else seen these ?.
-
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.
-
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.
-
Existing vehicles and safes or newly bought / placed ones ?.
-
-
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.
-
Start ARMA 2 OA and it will take you to a menu with Multiplayer, Options, Player Profile, Expansions and Exit.
-
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
-
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.
-
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.
-
vbawol has suggested we may be able to change the characterID column to a bigint which would fix all of these types of issues with the SteamID being too big. Obviously needs testing fully.
Update: Does not work. The hiveext.dll has the field hard coded as a int. vbawol will take a look. I have provided the details int he bug report.
-
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 ?.
-
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.
-
What I may be able to do as a stop gap for the time being is put together some SQL so you can convert the already built items back from PlayerUIDs to CharacterIDs so you can just take out the mod and contine running the server.
I can only link back to the BIS playerUIDs though so you would still need to link the new SteamID characterIDs to the buildables afterwards just as anyone without the Plot For Life mod has to.
If this would be helpful for you then let me know and I will get something sorted out ASAP tonight. If not I will continue working on v2.
-
not looking good so far, come through Rim!
Whenever I load in my server (using this script/mod) I load in with a black screen. Any advice?
All help is appreciated, I really am trying hard to fix it but left with no other options but to ask for help here. :(
Guys,
There seems to be quite a bit of confusion.
Two things are going on at the same time.
- Epoch release 1.0.5.1
- Steam (mandatory) release of ARMA 2 OA which changes from BIS playerUIDs -> SteamIDs for identifying players.
Item 1.
Low concern and priority (see below).
Item 2.
Mod breaker.
Why is this so.
The BIS PlayerUID fits in the object_data characterID field (with a little conversion from text to number as the filed is number only).
The SteamID is 16 characters long and will not fit in the object_data characterID field (it is an integer field with a max size of 11 digits).
How does the issue manifest.
Hive errors as the code is trying to put data too big to fit in the characterID field.
But why was this not fixed before the Steam change.
BetterDeadThanZed was kind enough to point it out when it was discovered two days ago on the 28th June.
So what needs to be done to fix it.
It cannot be fixed in its current incarnation. One of two options are curently available.
- Store the SteamID of the owning player in a different DB field in the object_data table.
- Use a custom hiveext.dll which enables more open DB communication so custom tables can be added and then utilised by sqf scripts.
So which direction is this mod going in.
Option 1 I had already been discussing with OtterNas3 when discussing collaboration on various future projects before all these issues with SteamIDs came up. We had already come to a conclusion on a good candidate field to store the data and roughed out a theory on how to do manage that data. As the basic groundwork is already thought out, for the sake of a faster turnaround, I will be doing that.
How far have you got.
I have a first cut of the code and am just starting Alpha testing (checking the techniques work as expected / finding any typos or missed ';' and making sure basic functionality works).
When can we get our hands on it.
After I have finished Alpha testing I will release a test zip for Beta testing for those who want to take a look and partisipate. After a bit of Beta testing, if the results look good, then I will release PlotForLife v2.
Will it be backwords compatible with v1/v1.1
No. I will have to write a bit of SQL code to put the owners SteamID in to the new field being used of storing it in PlotForLife v2. I hope to release that shortly after the PlotForLife v2 Beta but the main code is my current main focus.
But when will it be ready.
Sorry, no ETA as of yet. Please bear in mind that I also work and have family commitments but I am aware that this is very important to a lot of you and I am spending as much time as I can to get this out as fast and as safely as possible.
What about option 2.
Option 2 I will explore after PlotForLife v2 is out as it will be the better solution but currently has some risks which I need to fully test and build in safeguards against before asking anyone to put it on their servers. Safety is a major concern for me.
I will also put this information on the first page and take out the install info and download links to safe people installing and it not working.
Keep an eye on this thread as I will post updates as reguarly as possible to keep you all up to date.
-
Immaterial.
It does not work with the new version of ARMA 2 OA we are all being forced to move to due to changes Steam is requiring.
-
First cut is almost ready for its first run.
I hope to have this also include tent and vaults (safes) which were still tied to characterIDs in the precious releases.
Currently there are 17 files that need amendment. I will release as a zip :) . If all goes well I may have a beta ready for late in the coming week. It will need a fair amount of testing as it touches the fn_selfactions and compiles.sqf quite a bit.
Have had a play with he new hiveext.dll and have finally managed to get a status response back but needs more work so will look at that for a future update after I get this one out due to the urgency.
-
I put a suggestion up a page back which is quick and easy and will help record players playerUID before the change
I see no better possibilities at the moment but that would be better than nothing.
-
I've tested this with Epoch 1.0.5.1 and Arma 2 125402 and although the helipad is being created in the game, it's not being written to the database. Is this due to the new UID's, which are quite long?
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.
-
What is the current stable version of ARMA OA being pushed out via Steam ?. Just want to get a feel on who many are likely to get affected.
Yep, if the SteamID is now being used, the object_datas characterID field cannot hold it due to size.
I have just started working on a solution now (9am where I am). Will update on progress later.
-
Have you tested to confirm your GUID is not being tied to the SteamID in the new patch ?. Tay Tay appears to have done so in the other thread as you know.
Maybe he bought a disc version and the change to Steam changed the GUID linking it to a Steam key or vice versa. Don't know, have not tested so cannot say for sure.
-
Hi MGM,
I have not seen or touched Overwatch or the Overpoch variations so really cannot comment if this will work for it. Personally, if you are not currently running a server then I would not start now (am delaying making my server public too) until the switch to Steam is complete and the dust has settled or your new players are going to see a number of issues and assume it is your server and not the background changes that are causing the problems.
I would wait for the Plot for Life v2 if you are not running a server yet. If you have 1.1 working fine then you could use that but a new method will be used for storing owner info so you will have to go through a conversion process from 1.1 -> 2.
-
Someone over in the just confirmed that the new steam beta uses new Battleeye GUIDs so we cannot even link PlayerUID -> battleeye GUID -> SteamID.
Unless Steam / BIS release a tool for server owners it looks like it will have to be a manual process.
How about logging the playerUID in the users ARMA2OA.RPT file via a line in the init.sqf for your mission and you can then tell them to send you the log so you can confirm their playerUID. Add a value to it (i.e. 100 or something) in the sqf to help prevent people trying to spoof others PlayerUIDs they may see somewhere. The number in the log is not their playerUID but you just deduct the number you added in the SQF and you then have it, May have to turn on the DZE_Debug option to get it logging though which could then report other things the player can see. The change would be manual but at least the info needed is logged without needing the user to do anything.
Incoming Steam Update with SteamID + Databases, Server admin discussion
in General Discussion.
Posted
Just picked up about the "getPlayerUIDOld" on the bug report. This may be good for converting old players characters to new SteamIDs but as new players will not have BIS PlayerUIDs I cannot see how it will work for them.
Does anyone have any info on how it actually works and if it just defaults to the SteamID if the player has no legacy PlayerUID value ?.