RimBlock
-
Posts
1140 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Articles
Posts posted by RimBlock
-
-
I would think with the getPlayerUID if a player who doesn't have a PlayerUID it will report back the SteamID instead.
I wouldn't want to rely on the getPlayerUIDOld command for too long though, as it will be classed as legacy support, and like all legacy things they eventually get phased out over time as they are replaced with newer better things :)
Doh... You know when you have been coding Epoch sqf too much when you forget ARMA II OA does not need a persistant DB.
Yep, so as long as the underlying data is still accessable by ARMA II OA (i.e. the CD Key or something else) then both commands will work. It clicked when reading a response on the BIS forums and looking at the big picture. Thanks
Yep, fully agree with the legacy view.
-
Ok, the code looks like the latest version and nothing is jumping out at me.
Plot Pole is saving to the DB correctly.
Code to check owner is as expected (there was a slight change between the BETA and Release in that code block).
Only other thing would be population of the plot pole [objectPUID] variable but I would need some diag_log lines to report the values to check that.
Anything in the client RPT file (usually something like c:\users\[Windows account]\local\appdata\ARMA2OA).
-
-
Ok, so the first and last screenshot of the object_data plot pole entry is the same but the last one has the fields expanded. May be worth taking the first one out then :) .
Anyhow, the data is correct in the DB by the looks of it so it is saving the buildables fine but it would appear the check for ownership of the closest plot pole may be having difficulties.
Have a look at the player_build.sqf in the custom/PlotForLifev2 directory.
Look around the 150 line position for something like the following (it will be different as this is the original Epoch code as I cannot download my mod from where I am at the moment)
// check nearby plots ownership && then for friend status _nearestPole = _findNearestPole select 0; // Find owner _ownerID = _nearestPole getVariable ["CharacterID","0"]; // diag_log format["DEBUG BUILDING: %1 = %2", dayz_characterID, _ownerID]; // check if friendly to owner if(dayz_characterID == _ownerID) then { //Keep ownershipPost back what that actual code is in that file on your server please.
-
Am I missing something or are the installation instructions missing from the download? I'm not finding anything here on the post or on the Git either. I would love to try it but...
Bao
My bad. The install is super easy if you do not have any other mods installed.
I have added install instructions at the top (just extract the zip file to the right directory and then play).
-
Is this what you need?
Probably, where you are hosting is blocked where I work but have taken a quick look on my phone ;) .
The first screens shot and the last one are of the plot pole. What did you do in between that caused the record to change ?. The second one looks good. Your playerUID (the SteamID) is now saved in the worldspace field.
-
I am using DayZ_Epoch_Server_1.0.5.1_Release
I then installed your mod from this post. Version 2
Does it not work with this version?
34 76561198084911985 11 2014-07-02 21:56:31 2014-07-02 22:01:19 [["ItemFlashlight","ItemGPS","ItemCrowbar","ItemEtool","ItemToolbox"],["ItemPainkiller","30m_plot_kit","ItemVault","ItemBandage"]] ["DZ_Patrol_Pack_EP1",[[],[]],[[],[]]] [116,[2189.88,14163.7,0.002]] [false,false,false,false,false,false,false,12000,[],[0,0],0,[34.535,21.29]] 1 1 2014-07-02 21:56:31 2014-07-02 21:56:31 0 0 38692 2 ["","aidlpercmstpsnonwnondnon_player_idlesteady03",37,[]] 0 Survivor2_DZ 0 2500 0
Not tested on on 1.0.5.1 as I started coding this on 1.0.5 and then a day or so later 1.0.5.1 came out and 1.0.5.2 is due any day now so better to change to 1.0.5.2 as by the time I have changed it for 1.0.5.1 it is likey not the current version.
I tried to highlight the fact it was for 1.0.5 in the file name and in the release history
Plot for Life v2 (DZE 1.0.5) - Release.
V2 (ARMA II OA 125548 with SteamID - Epoch 1.0.5)
Sorry, I was not clear. I meant the characterID and Worldspace variables for the plot pole you placed but could not build with in the object_data table of the DB. Post the whole line if easier.
-
I like the idea and although I like the red and green, many a time I have totally missed the warnings on low food and drink, usually when building. This should help a lot.
Another option may be to graduate the grey going to white and back again which would better show the % between good and bad. The grey icon gradually fills up to white like the DayZ temp gauge goes from red to blue and back. Would have thought it should be fairly easy as it could use the same method with grey and white as DayZ does with red and blue (or transparent).
Nice job either way :) .
-
I installed this on a fresh 1.0.5.1 build. I place a plotpole and I cannot remove my plotpole without 1 of 6 tries and breaking my toolbox.
I cannot build after placing the plotpole. I get cannot build without plotpole.
When you say you installed this on a 1.0.5.1 build, do you mean you took the 1.0.5 version and installed it on Epoch 1.0.5.1 as I do not have a 1.0.5.1 version (1.0.5.2 should be out very soo so will align the next update to that) or did you look at the changes I have made to the files and applied them to the 1.0.5.1 version of the files ?.
What are the characterID and worldspace values for the plot pole in the DB ?.
-
My players have begun building again under their new UID's. Is there a new SQL query that will align those items already built once I've added this back into my server?
I will have a look tomorrow at putting something together.
Presumably your situation is...
Player -> buildable is linked via characterID in the object_date.characterID field (i.e. standard way it is done) ?
-
Just had the issue a couple of times today.
In my case, looking at the client RPT file I saw the message "Mission ended".
In my case there was a bug in the server_monitor.sqf (part of my own code) and the errors were not reported. Once the code was fixed the login worked fine.
-
First full v2 release is now up.
Code is also on GitHub
See first post for both.
Please let me know of any issues.
I will update to Epoch 1.0.5.2 when it is released, which should be very soon.
I am also looking at any possibility of realigning playerUID to SteamID but am currently not sure if it will be possible.
-
Update
Tested (ARMA II OA - 125548 with SteamID and Epoch 1.0.5);
Place plot pole.
Build cinder doorway.
Build metal floor.
Restart server - Items correctly saved to DB and persistent.
Remove metal floor.
Upgrade cinder wall.
Build tent.
Pack tent (only available after reboot - Need to check the code).
Upgrade garage doorway with lock
Unlock door
Lock door
Downgrade garage door (remove lock).
Safe build / open / lock / pack.
Safe locking and unlocking requires no code for the safe owner by default, only for third parties :D .
Basic testing complete. Only a couple of paths found incorrect and fixed. No other issues found.
-
I had a play around with the method FramendYannick posted here.
I just increased it to the last 9 digits of your steamid instead of 8 (thanks to Dami for pointing out that I could lol) to be that extra bit more secure.
It is working well with the building mods I am using.
Yeah, I saw the post on GitHub this morning. A pretty good solution allowing the use of the characterID field to continue to be used to hold playerUIDs. Using the 9 digits give you a million unique ids out of just under 2.15 billion possibles. That should be pretty robust I would have thought.
Now I have done the work to move the unique id over to the worldspace field I am happy to leave it there. The reason is that chopping up the uniqueid (be it PlayerUID with possible characters or the SteamID) and putting it in a numeric field designed for characterIDs and already being leveraged for keys and lockable codes is something I wanted to move away from anyway. This SteamID issue has just forced my hand a little, but the move to using a nested variable in the Worldspace field allows me to store the full 17 digit SteamID and have plenty of space over for other enhancements With it being a text field it is actually fairly easy (surprisingly so once I worked out and tested the technique) to nest more arrays in the end. Car keys, door combos and safe codes could all have their own arrays rather than sharing the characterID field and having possible conflicts. Of course this is all future designs and none is required but would be nice to have. Once this is proved stable and the bugs are ironed out I may look at moving the key code etc and saving the characterID field just for characterIDs. One other good point of doing this is that the code could also be setup to allow server owners to choose between the ownership being player or character based as both bits of information will coexist within the buildables record.
If the post from Framend had gone up before last weekend I would have probably gone that way but I am happy to have gone the way I have now.
One issue that may come up though is for tagged friendly as there will be a limit on the number of friendly SteamIDs that can be stored in the currentstate character_date table if all 17 digits are being stored ;) .
-
It should be fairly easy to tie ownership of buildables in plot range of the nearest plot pole to a targetted player or action activator.
The problem is making it persistant as most of the buildables are not re-saved to the DB after they are first placed and saved (excluding up / downgrades). To make this persistant I would need to force an object swap DB call for each buildable item in range requiring an ownership change which would be quite heavy on internet and DB resources.
Maybe a staggered ownership change (1 item every 10 seconds or something). Someone taking ownership of a big base with XXX parts will take some time but at least this way it will not kill the server for everyone.
Maybe an option for the plot pole owner to take ownership of all buildables within range from a plot pole action. This action only appears if any buildables not owned are within range. This would mean that the owner would need to place a new plot pole if changing from playerUID to SteamID but would be a much cleaner way of doing it.
Any other thoughts, concerns or views on this guys ?.
-
When using the new updates from Steam, it changes you over to the SteamID regardless of whether you had a BIS PlayerUID already. This causes you to start fresh with a new player.
If the admin knows your old BIS PlayerUID and your new SteamID they can give your old player the SteamID and delete the new SteamID entry therefore making your old character compatible with the new version of OA. Linking the old BIS PlayerUID and SteamID to a user is not easy but BIS have now released a new command with the 125548 Beta called getplayeroldUID although no info has really surficed from them on exactly what it does and there are reports of people getting stuck on loading the mission if the server is using this command and the connecting client is not on 125548.
If all the clients are on 125548 then, as part of the solution, you could put a line in the player login script to getplayerUID and getplayeroldUID and dump them to the RPT file via a diag_log command but you would still have to manually change the character_data table.
Personally I am waiting to find out a bit more on getplayeroldUID and for 125548 to become more mainstream.
On the blank screens with sound but no picture, I have also got this now and then. It seemed to sort itself out but I have been debugging my Plot for Life mod and so had realigned my character to the SteamID manually (removed the new Steam character) and a few other things so sorry but no real pointers on how I fixed it for me other than check your client and server versions match (and the clients of your userbase who are getting the issue) and try aligning their old character to the new SteamID and removing the newly created character.
As always, test on a non-live server first.
-
Have just thought of a way to align the playerUIDs of the buildables to the new system without changing the DB records. Too late for me to implement tonight but will look at putting it in tomorrow with any bug fixes I can from those reported.
Note that this will not realign items from playerUID to SteamID. Once I have a better idea of the getplayeroldUID I may be able to use that to do the job but it may slowdown for the first person to login as all the realigned items will need to be written back to the DB. After the first realignment it will work as normal. Will take a look at this tomorrow.
-
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.
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).
-
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.
-
It's about 50% complete right now, it kills zombles and knocks players out.
Next things i gotta add is -
Owner being able the check which fences are powered and which aren't. So they can position the generator properly.
Friendly tagging compatability. Don't wanna knock your friends out all the time, or maybe you do ;)
Some fixes i gotta do -
It seems that after the first ~2 knockouts it stops disabling user input, which is bad.
Improve the 'collision detection'. If you wanna call it that.
I gotta say though, this is the WORST thing ever to be testing. That sound :|
How about instead of checking every fence to see if it is on, just activate the plot markers but center them on the generator to give visable indicator of range. It is very simple to do. The script is comiles/object_showPlotRadius.sqf
-
Nice Detailed writeup.
A bit more detail on exactly what permissions are needed for the DB user would probably help new users.
Take a look at MySQL Workbench (comes as standard with MySQL) as it allows you to do server administration (start / stop / amend config files / user configuration / etc) as well as multi-tabbed sql sessions to multiple servers if desired. That will save having to install WAMP / XAMP and Heidi.
I also found that with the latest versions, only the Addons folder is needed from the ARMA 2 directory. Just copy this to the server folder and then copy in the ARMA II OA and @Epoch mod files.
Info on opening firewall ports would also probably be helpful to some.
Just went through the process last night hence this lot just happens to be fairly fresh in my head :) .
-
Wont the ingame multiplayer server browser list the servers ?.
Mine is in there but then mine is on my lan.
-
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.
-
Thanks guys.
ReDBaroN, you nailed the map marker issue. My previous version was running on regular. The 1.0.5 is defaulted to veteran (which I didn't change back to regular). That should sort that one out. Will put the other two up as issues on GitHub.
Ear and Eye icon missing - https://github.com/vbawol/DayZ-Epoch/issues/1378
Abort countdown strangeness - https://github.com/vbawol/DayZ-Epoch/issues/1379
Incoming Steam Update with SteamID + Databases, Server admin discussion
in General Discussion.
Posted
Agreed. Rather than using the playeroldUID to keep the playerUID valid, it should be used to convert old players to the new SteamID so the old playerUID can be phased out in a more controlled manner without people loosing everything.
It should be good for changing the buildables ownership in my mod from playerUID to SteamID but have not really thought on how it could be leveraged to convert player records.
How about on login;
Will have a look once my Plot For Life release is considered stable (few days hopefully).
oh, one other point. I have had the new BE exe flagged in Norton as a trojan virus. Seems sother have two on the BIS threads for the betas.