RimBlock
-
Posts
1140 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Articles
Posts posted by RimBlock
-
-
Ok,
Have rewritten it. Cant test it from where I am but give it a go.
The script now
- Checks for alive "HeliHEmpty"s within the warning range (rather than trying to find one in the whole map).
- Only if any are found it then checks if any are alive.
- If an alive heli is within range it checks if the player is in the warning or death zone and either kills them or warns them every second.
- Warning and death ranges are now variables for easy fine turning.
- Variables are defined and initalised.
Private ["_n","_nearbyHeliEmpty","_aliveNearbyHeliEmpty","_vehiclePlayer","_nearestHeliEmpty","_warningRange","_deathRange"]; _n = 0; _warningRange = 20; _deathRange = 7; While {True} Do { _nearbyHeliEmpty = []; _aliveNearbyHeliEmpty = []; _nearestHeliEmpty = ""; _vehiclePlayer = Vehicle Player; _nearbyHeliEmpty = nearestObjects [_vehiclePlayer, ["HeliHEmpty"], _warningRange]; if ((count _nearbyHeliEmpty) > 1) then { { if (alive _x) then { _aliveNearbyHeliEmpty set [(count _aliveNearbyHeliEmpty),_x]; }; }count _nearbyHeliEmpty; if ((count _aliveNearbyHeliEmpty) > 1) then{ _nearestHeliEmpty = _aliveNearbyHeliEmpty select 0; If ((_vehiclePlayer Distance _nearestHeliEmpty) < _deathRange) Then {Player Setdamage 1;}; If ((_n == 0) && {_vehiclePlayer Distance _nearestHeliEmpty >= _deathRange}) Then { TitleText ["\n\n\n" + Localize "STR_Limited_Area_Warning","PLAIN"]; }; _n = _n + 0.05; }; }; Sleep 0.05; If ( _n > 1 ) Then { _n = 0; }; };Let me know if you get any errors and I will have a quick look.
-
The issues are not always with the lines listed in the RPT files. Those lines look reasonible at first browse but wihout the whole script if it hard to pinpoint the actual bug(s).
You may also want to change the 'and' to && and look at using lazy evaluation for slight performance improvements.
-
Hi Rimblock, I think we're getting closer then...yes, the dupes were definitely happening at the bigger bases that were on or near the object max I have of 160 per pole.
The 3 attempts makes sense now as we had witnessed there being multiple objects at the same location, not just dupes but, trebles and a couple of quadruples. This explains some 440 odd on the first pass, 40 odd on the second, 12 I think on the last and nothing thereafter.
I don't think we are having any antihack issues as from memory that was more a problem about nuke check and he altered the way that works so was never a problem for me always updating the latest updates very quickly.
Do you think the door locks zeroing is to do with the skin change bug in 1051 then? I tried f3cUK's fix before and had problems but, may give that another spin...?
As mentioned, this mod only takes the players characterID or the objects current characterID if it a locked door and puts it in. It does not calculate or generate a characterID. Id something else has zero'd either of those then the problem will show up with the take ownership but it is not the cause.
for the take ownership, add the following (to slow it down a bit).
find
PVDZE_obj_Delete = [_objectID, _objectUID, player]; publicVariableServer "PVDZE_obj_Delete";
change to
sleep 0.001; PVDZE_obj_Delete = [_objectID, _objectUID, player]; publicVariableServer "PVDZE_obj_Delete"; sleep 0.001;
This will slow things down and we can see if that is the issue.
Note a 160 item base could take just over 1/3 of a second to change ownership.
Think you could be right on the antihack. IIrc it kicks on mass deletions.
-
people looking for an alternative are leaning towards extDB. It is used in Altis-Life (A3) and I am working with it for the A3 mod I am working on at the moment. It is fairly well locked down (the lockdown is fully server owner controllable rather than mod maker imposed) and is meant to have good performance (I have yet to test). My advice would be to take a look in that direction.
-
Branch 2.4_Dev created.
- Removed option to turn off A Plot for Life. This was added for inclusion in the Epoch mod core files and requires a lot of checking to see if it is on or off. Removing the option from the mod cuts down a bit of code (smaller mission file size) and makes it easier to maintain.
- Added new function fnc_find_plots. This function gets nearby plots, checks if they are alive, returns the distance (plot radius), count of nearby plotpoles and also returns the nearest alive plot pole. This reduces a lot of duplicate code in a lot of the player building files.
- Amended the modular build files to pass variables more. This is so variables are obtained and checked in one place and passed between the scripts rather than re-obtained again.
- Integrated fnc_check_owner and fnc_find_plots in to modular build.
Next stage is testing and basic bug fixing (syntax etc) before being available for public beta.
-
@Detour,
Short answer is no :) .
Long answer...
This goes back to something that happened earlier this year. Originally GameSpy handled multiplayer matching and BIS (Bohemia Interactive Sturios) calculated the unique playerUIDs based on peoples game keys. For the first round of plot player, rather than character, ownership by WGC GeekGarage, that the playerUID could be stored in the CharacterID field rather than the characterID. A Plot for Life built upon this ground work and just optimised the code a bit (better processing / conversion of the string playerUID to a number for DB storage).
Earlier in 2014 Gamespy anounced it would be closing its servers and BIS moved over to Steam. Steam use its own unique player identifier which is much longer than the original BIS one and so would not fit in the CharacterID field. Whilst VBAwol suggested extending the DB field initially I found that the HiveExt.dll code was hard coded to keep the charID field the same size as the original DB field (i.e. int). Details of that investigation can be found here.
Whilst there was initial talk of changing the HiveExt.dll, BIS released a function to create the old BIS PlayerUID for a player and a new function was added to Epoch 1.0.5.2 to do this. 1.0.5.2 was never released and has now been renamed 1.0.6. THe HiveExt.dll is meant to also be amended for 1.0.6 but as the Epoch teams main focus is now on A3 Epoch, a number of people doubt if there will be any future releases of DayZ Poch (A2), especially as previously the Epoch team had said an earlier version would be their last.
To this end I found the Woldspace field had a lot of room to spare so ported A Plot for Life over to using that field. This has a number of advantages including locked doors now could also have ownership and the door lock code stored. The same was true for safes. Owners of safes and locked doors could automatically have them unlock (no code needed) etc. Others have followed suit and have also been leveraging the worldspace field and now it is getting a little cluttered but is still working pretty well.
There is really no advantage to be had from trying to put the SteamID in the characterID field and a number of dissadvantages. Ideaily, if I do move the plot take ownership over to using the extDB connector (rather than HiveExt.dll) then the ownership could use a completely different table and the A2 Epoch code could be made a lot more efficent. Wouldspace coords could also be stored much better and negate the need for various convertions in code and vectors could also be easily incorporated in their own field. It would seem the better way forwards. Someone else is already looking at writing interface code so it can replace the HiveExt.dll. This may be the first step although I cannot help but think that rewriting the Epoch finctions to use the strengths of extDB rather than pulling extDB down to the level of Hiveext.dll would be a better way to go, all be it a much larger task. A discussion on the different available hive connectors is
-
@ ReDBaroN
The sql was designed to delete only the single oldest per objectuid per run. It is a lot safer and simpler that way. Multiple duplicates would mean multiple runs.
Do you know the object count for the bases affected. If they are high then I am wondering if the hiveext.dll may be getting overloaded as it is being given hit with object count ×2 (delete & insert) in a very short space of time.
I may look at using @extdb for this as I can then just fire an update sql to change the ownership rather than the locked down @hiveext. Would open up a lot more options too. I have around 70% of the code ready to go as we are using Google it for our A3 Dominion mod so it would help that progress as well. It would also potentially mean we could get rid of the object uid completely and use the objectid returned from the DB.
you could try adding a sleep 0.01 between the delete and publish PV calls in the Plot _ take _ ownership. Sqf file which will slow it down a bit.
also, if it is a big base being affected, is infinistar or some anti hack blocking ?.
I will maybe put up some sql triggers which will catch the dupes when they happen and a copy of the plot take ownership with more debugging so we can track this down later today.
-
Here the File you Requested!
private ["_class","_uid","_charID","_object","_worldspace","_key","_allowed"];//[dayz_characterID,_tent,[_dir,_location],"TentStorage"]_charID = _this select 0;_object = _this select 1;_worldspace = _this select 2;_class = _this select 3;_allowed = [_object, "Server"] call check_publishobject;if (!_allowed) exitWith { deleteVehicle _object; };//diag_log ("PUBLISH: Attempt " + str(_object));//get UID_uid = _worldspace call dayz_objectUID2;_worldspace set [0, (_worldspace select 0) call KK_fnc_floatToString];_worldspace set [1, (_worldspace select 1) call KK_fnc_positionToString];//Send request_key = format["CHILD:308:%1:%2:%3:%4:%5:%6:%7:%8:%9:",dayZ_instance, _class, 0 , _charID, _worldspace, [], [], 0,_uid];//diag_log ("HIVE: WRITE: "+ str(_key));_key call server_hiveWrite;_object setVariable ["lastUpdate",time];_object setVariable ["ObjectUID", _uid,true];// _object setVariable ["CharacterID",_charID,true];if (DZE_GodModeBase) then {_object addEventHandler ["HandleDamage", {false}];}else{_object addMPEventHandler ["MPKilled",{_this call object_handleServerKilled;}];};// Test disabling simulation server side on buildables only._object enableSimulation false;PVDZE_serverObjectMonitor set [count PVDZE_serverObjectMonitor,_object];//diag_log ("PUBLISH: Created " + (_class) + " with ID " + _uid);Here the FullPublish if neededprivate ["_class","_uid","_charID","_object","_worldspace","_key","_allowed"];_charID = _this select 0;_object = _this select 1;_worldspace = _this select 2;_class = _this select 3;_inventory = _this select 4;_hitpoints = _this select 5;_damage = _this select 6;_fuel = _this select 7;_allowed = [_object, "Server"] call check_publishobject;if (!_allowed) exitWith { deleteVehicle _object; };diag_log ("PUBLISH: Attempt " + str(_object));//get UID_uid = _worldspace call dayz_objectUID2;//Send request_key = format["CHILD:308:%1:%2:%3:%4:%5:%6:%7:%8:%9:",dayZ_instance, _class, _damage, _charID, _worldspace, _inventory, _hitpoints, _fuel,_uid];//diag_log ("HIVE: WRITE: "+ str(_key));_key call server_hiveWrite;_object setVariable ["lastUpdate",time];_object setVariable ["ObjectUID", _uid,true];// _object setVariable ["CharacterID",_charID,true];if (DZE_GodModeBase) then {_object addEventHandler ["HandleDamage", {false}];}else{_object addMPEventHandler ["MPKilled",{_this call object_handleServerKilled;}];};// Test disabling simulation server side on buildables only._object enableSimulation false;PVDZE_serverObjectMonitor set [count PVDZE_serverObjectMonitor,_object];diag_log ("PUBLISH: Created " + (_class) + " with ID " + _uid);Thanks allot for your help regarding this issue.If I can be of any Support towards projects please do let me know.Best Regards,HuppabubbaFirstly add the extra lines from precise base building in to the server_publishFullObject.sqf
Find
_uid = _worldspace call dayz_objectUID2;
Change to
_uid = _worldspace call dayz_objectUID2; _worldspace set [0, (_worldspace select 0) call KK_fnc_floatToString]; _worldspace set [1, (_worldspace select 1) call KK_fnc_positionToString];
That should sort out the saving of precise base building part of the worldspace variable.
I will have a look at the other issues tomorrow.
-
Updated version to v2.35 which just has the last couple of bug fixes in it. If you have been tracking the last 4-5 pages then you have probably got the bug fixes already. This is because some people may be running on older versions of the v2.34 code and be unaware of the fixes put in without a version number change.
I have reorganised the Git to take out the version number from the path to also help with clarity of the version. The text file has the version number and the Git now has three types of branch.
- Master - Latest stable release.
- A Plot for Life vXXXX Stable - Stable branch for each release.
- A Plot for Life vXXXX Dev - Development branch for each release.
I may add a beta branch at some point.
-
Cool, looks like Buck0 is sorted via Skype. He had a line missing in Player_upgrade.sqf hence the 'upgrade' to a full cinder wall was having issues.
-
The format of the worldspace field looks very wrong.
:[139.599,[7723.07,4005.73,-1.95541],]:[]:[]:0:7723140057196140:
It should be (for only having A Plot for Life installed).
:[direction[X,Y,Z],SteamID]:
I don't suppose you have something like vector building or painting walls installed by any chance ;) .
-
-
Call me dumb/noob.. but that's the @dayz_epoch_server, right?
Put it in the same folder that you have put @dayz_epoch and @dayz_epoch_server in on the server.
-
Rimblock, thanks again for the SQL above. I have now had a look at the results and have some more bad news. It looks like the duping is still happening since I turned off take ownership.
Could this be lag related?
I only ask as its seems to have happened at the same time we have had a high player count....EDIT: I still wonder about lag relation but, having looked further it seems to be happening at off peak times as well.
EDIT2: Also Rimblock in answer to your earlier question about a door management script, no we don't. We do however, have a modified player_unlockDoor.sqf for combo lock brute force penalty. I am going to switch that off and see whether there is any change to the locks zeroing problem. No errors in the hivelog
Ok, so if you can confirm that turning off the Take Ownership function removes the option from the plot pole then it would appear your duplication is not due to the Take Ownership function.
Have a check and see what type of worldspace format the duplication is happening on to see if there is a pattern as mentioned above.
The door lock code issue I believe is unrelated to taking ownership as taking ownership either sets the characterID field as what the game objects characterID field already is or sets it to the players characterID. The only way it could set it to 0 is if the characterID for that player is 0 or the characterID of the object is also already 0.
Your RPT files would also be helpful.
-
I have done everything to the T in the instructions and im getting this error
2:18:54 Warning Message: Script custom\init\server_functions.sqf not found
2:18:54 Warning Message: Script custom\system\server_monitor.sqf not found
Someone please help, i have tried everything i know to change the path and the destination i don't know whatelse to do.. from what i understand.. correct me if im wrong please, the server root directory would be the server.pbo yes? If not i have tried putting it in the folder that the pbo is in and also the folder the addons, keys folders and the hiveext file is.... If someone knows what im doing wrong I'd greatly appreciate it!
Put the custom folder in the server root directory (the one with the ArmA2OA executable in).
-
Sadly without precise build, everything is all over the place once the server reboots. And I am not talking about 4 or 5mm but holes the size ppl can walk through walls. No idea why.
But thank you and I hope you find something really easy :)
Best Regards
Post up a copy of your server_publishObject.sqf . I am presuming that it has been amended from the original one for precise / vector building. I will see if I can implement those changes in.
This is the problem with multiple mods from different people sealing with the positioning. When saving objects I now need to take account of the fact that precise building and / or vector building may also be added.
If someone has vector and precise building added then you could have items with;
Vanilla Epoch worldspace
- A Plot for Life worldspace
- Vector worldspace
- Precise worldspace
- Vector worldspace and A Plot for Life worldspace
- Precise worldspace and A Plot for Life worldspace
- Vector and precise worldspace
- Vector and precise worldspace and A Plot for Life worldspace
So your DB records could have 7 different worldspace format combinations depending on the mods installed and when they were installed.
From the PDF you posted, it seems (after looking on a computer rather than my mobile at 12:30am :) ).
Original wall = Precise building.
New plot pole = Precise building & vector building & A Plot for Life.
New wall = A Plot for Life.
2nd New plot pole = Precise building & vector building & A Plot for Life.
New wall deletion = missing.
2nd New wall = A Plot for Life.
If the deletion is missing I would expect to see an error in the RPT files on the client (of the person taking ownership) or server. Providing a copy of those would be very helpful (probably).
-
Hi RimBlock,
hope this is enough Information that can be helpfull.
I skipped the last bit of restarting the server as you can already see 2 Items in the Database.
Best Regards
Huppabubba
You have precise building installed. This means the objectuid is different for the new item compared to the legacy item which was built without it. Remember the objectuid is based on the workspace coordinates. They are different in the legacy and the first new item. This means the new item cannot be deleted as the objectuid recalculated by the object publish script and applied to.the object won't match the db record.
Without precise building this should work fine. I will take a quick look tomorrow to see if there is an easy solution.
-
SQL to remove duplicate objects.
Backup your DB first (My Windows batch file db backup script can behttp://epochmod.com/forum/index.php?/topic/14161-release-mysql-db-backup-v11/?hl=backup#entry120478). Load the db on to a test server and test before applying to a live server if possible.
Create a list of objectIDs where there is more than one ObjectUID (list only the oldest objectIDs where there are multiples).
CREATE TEMPORARY TABLE temp_object_delete select min(objectID) as objectID from object_data where characterID <> 0 group by ObjectUID having count(ObjectUID) > 1;
Select objects from the object_data table where the objectIDs match those in the new temp table (so you can review them).
select * from object_data where objectID in (select objectID from temp_object_delete);
Delete objects from the object_data table where the objectIDs match those in the new temp table.
delete from object_data where objectID in (select objectID from temp_object_delete);
Drop the temp table once no longer needed (it can be used to reference against your backup if incorrect items were removed).
drop table temp_object_delete;
-
Stuck at the office at the moment but will have a quick look when home.
-
Ok,
The way it works is that the object in the game world is not deleted but just updated. The object in the DB needs to be deleted and recreated as the hiveext.dll does not have a call to update the fields we need to update.
For this reason, the process goes like this.
Find all objects in range of the plot pole.
for each one
- Check if in list of objects where ownership can be changed
- If true, delete DB copy of object.
- Update game object details.
- Publish new DB object with game object details.
The big issue (one of them) with the hiveext.dll calls is that a lot of them are one way. Object calls are one way apart from the call to load all objects fromt he DB (occurs on server startup). This means that the server starts and loads the objects fromt he DB. The game world objects then act as 'master' copies and updates are pushed to the DB (but not read). The unique identifier of objects is the ObjectID but this is created at the DB level (incremental field - new row added then that field just goes up X numbers). The problem is that this autogenerated ObjectID cannot get back in to the game world so in the game a second ID is created called the ObjectUID. This is generated based on the objects location in the game world and so should be pretty unique as well.
For the scripts that handle deleting or saving records from the DB, they will reference them via the ObjectID first if > 0 or the ObjectUID if no ObjectID is specified. The previous duplication was due to the objectID not being zeroed after the DB object was deleted.
i.e. the game world object still had the objects objectID. When someone came to take ownership again the deletion was attempted on the old objectID which no longer existed and so the object being taken over was not deleted and a new object was added to the DB. On server restart, both objects were loaded from the DB hence the duplication. This was corrected by the additional line detailed a few posts back.
So that explains why there is only one wall in game until reboot.
The concern is why there are two records in the DB even after zeroing the ObjectID in the ingame object after DB deletion.
Would really need to see the pre-state DB objects, the state after 1x take ownership and after 2nd take ownership.
I am sort of leaning towards the DB not being able to keep up at this stage so may need to put in a small delay between objects to see if that helps. Not seeing any logical reason for it not to work at the moment.
-
You will need to merge the variables and compiles files with your existing custom ones and then link to the merged version. You can run two versions at the same time but you are then defining the same fnctions / variables twice (waste of server effort) and anything that is common in both versions of variables / compiles will only take what the 2nd file defines it as (in load order so last defenition is the one that sticks).
Grab a copy of diffmerge and search for Raymixs tutorial on using it. Should be fairly straightforward if only those two files need to be merged.
-
Hi RimBlock, I can confirm that we are seeing locked doors duplicated as well. We also seem to be having an intermittent problem of door codes being set to 000 after take ownership.
We are trying to recreate the issue but failing at the moment. This is just what we are getting from player reports and then confirming the issue.
We'll try and narrow it down and report back.
EDIT: Seems like walls are also still duping although, intermittently. Still trying to narrow down when it's happening...
Door codes resetting to 0's is pretty strange as they should be either the lock code or the players characterID. Are you using any door management scripts ?.
Ok, now to add some debugging code.
In Plot_take_ownership.sqf
Find
_objectUID = _object getVariable ["ObjectUID","0"];
Change to
_objectUID = _object getVariable ["ObjectUID","0"]; diag_log text "-----------------------"; diag_log format["[Plot Take Ownership] Deleting object [ObjectID = %1] [ObjectUID = %2]",objectID, objectUID];
Find
_fuel = fuel _object;
Replace with
_fuel = fuel _object; diag_log format["[Plot Take Ownership] Creating object [CharID = %1] [Object = %2]",_charID,_object,_worldspace]; diag_log format["[Plot Take Ownership] Creating object [Classname = %1] [Inventory = %2]",_classname, _inventory]; diag_log format["[Plot Take Ownership] Creating object [Hitpoints = %1] [Damage = %2] [Fuel = %3]", _hitpoints, _damage, _fuel]; diag_log text "-----------------------";
Putting the audit triggers on the object_data table will make it easier to see what is happening with the old and new objects at a DB level and what do the RPT files say for creation and deletion. Any errors in the Hiveext.log file at all ?.
-
Ok, looks good.
Do you get the problem after one person takes ownership and then the server reboots or only if one person takes ownership and then someone else takes ownership again and then the server reboots ?.
Would be good to see a couple of the objects DB records as original, after first take ownership and then after second take ownership.
-
My Original Post
Hi there,
I seem to have stumpled appon something that I have not yet seen in the last 49 pages. (sorry again if I missed it)
Following Scripts are running on this server (stable)
-infistar
-plotpole4life (pp4l)
-snapbuild
-vectors
-precisebuild
-doormanagment
The problem is the following:
I have a base that was build prior to pp4l Life times.
So my Player 1 goes up and builds his PlotPole and takes ownership of all items within,
so far so good all works and it is registered in the Database. The Doors with Eyscan work as the should. (these depend on the PUID for them to work that is why I can tell the Take Ownership has worked)
Now Player 2 comes up and removes the newly set PlotPole of Player 1 and reuses it and builds it up again to take ownership. (within a few Minutes)
So far so good all worked well. Everything is written to the database and the doors work as they did with Player 1.
Now there is a Server Restart,
After Server Restart all Items have doubled, once for Player 1 and once for Player 2. So Basically I have everybuidlable Double.
(ALL THIS HAPPENED WITHIN 5-10MINUTES)
Is this a known Issue? Have I overseen something? Do you need any files to varify my potential wrong doing?
Or is it that ownership taken items are not deleted out of the database? Or was the Time were this all happened, to FAST, for the Database to sync?
Best Regards,
Huppabubba
Additional Information
As stated I have gone through the code and found that nothing is out of sync with your latest files.
Everything works like a charm.
The only Problem is this duplicating.
If you need me to test it like redbaron did I would defiantly do so as soon as I have time!
Thanks for your time
A copy of the plot_take_ownership.sqf file would be good.
This was an issue that RedBaron found and the extra line in that sqf file fixed it.
Any errors in your server or client RPT files ?.
Post them up here in spoiler tags please as I cannot access pastebin etc from the office ;)
[Release] - A Plot for life v2.5. Keep your buildables on death. Take plot ownership
in A2: Epoch Mods (1.0.5.1)
Posted
A Plot for Life does not touch character logging in or creation, it only handles the entitlement checks for building and tagging friendlies.
If a variable starts with a '_' then it is local to that script only. As the original scripts for Epoch have grown up through multiple people contributing there are cases of consistancy being broken so one script may use PlayerUID and another may use PlayerID. I have tried to fit in with this rather than change them all as it means less editing for anyone applying my mod to their own setup. _playerUID in player_build.sqf will not affect _PlayerUID in player_building_downgrad.sqf for example.
Get/set variable commands attach variables to objects (vehicles / player characters / buildings etc). In this manner, a value can be passed / queried by any script that has access to the object. If one script changes it then all other scripts will see the new value after the change has been made. A Plot for Life attaches the OwnerUID to buildable objects as a reference to who owns it.
Variables with no '_' in front of the name are global to your machine. All scripts can reference them and change them on your machine. They are usually initially defined in variables.sqf and are usually overridden in the mission init.sqf if the server owner wishes to do so. A common example of this would be the dayz_characterID which holds the characterID of the players character and is set in the player_monitor.fsm (which monitors the players character and fires off scripts in various circumstances).
I would suggest also checking your server rpt files as well and I also came across a thread today which looks like it could relate