AngelEyes_666 Posted February 18, 2014 Report Share Posted February 18, 2014 Its very annoying. Its pointless cause, even when we arrive at base after respawn, we usually can easily replace it if we have the means. Its not like making us replace it even does anything, its just a time consuming inconvenience. Why do we have this? If its important, are there other options besides this we can adopt instead? Link to comment Share on other sites More sharing options...
Sandbird Posted February 18, 2014 Report Share Posted February 18, 2014 Tweak the script to instead of using CharacterID to use CharacterUID.....so its always 'true'...even if the player dies and his characterID changes...it doesnt matter....It will be based on his fixed characterUID. Link to comment Share on other sites More sharing options...
GhostTown Posted February 20, 2014 Report Share Posted February 20, 2014 Where and what script do we change this at? Link to comment Share on other sites More sharing options...
Achmed Posted February 20, 2014 Report Share Posted February 20, 2014 I'm sure there is a post on the forum about it already somewhere Link to comment Share on other sites More sharing options...
Tobias Solem Posted February 20, 2014 Report Share Posted February 20, 2014 I'm sure there is a post on the forum about it already somewhere Not really, there however are solutions implemented on some servers for this. Just not publically available code. Link to comment Share on other sites More sharing options...
fr1nk Posted February 20, 2014 Report Share Posted February 20, 2014 I think the next best thing to attaching plot poles to player ID is transferring ownership across character death. Nasdero wrote a SQL trigger for this: Link to comment Share on other sites More sharing options...
Sandbird Posted February 20, 2014 Report Share Posted February 20, 2014 i'll give you an example...open your fn_self_actions.sqf Search for : dayz_characterID, and here are mine _ownerID = _cursorTarget getVariable ["CharacterID","0"]; ....... if(_isModular and (dayz_playerUID == _ownerID)) then { // dayz_characterID if (_ownerID == dayz_playerUID) then { //Change dayz_characterID to dayz_playerUID for perma owner These are just a few....basically you have to search each major file for dayz_characterID and change it to dayz_playerUID. From my player_upgrade.sqf (for upgrading modular buildings) // check if friendly to owner if(dayz_playerUID == _ownerID) then { //dayz_characterID From player_packTent.sqf if(_ownerID != dayz_playerUID) exitWith {DZE_ActionInProgress = false; s_player_packtent = -1; cutText [localize "str_fail_tent_pack", "PLAIN DOWN"];}; //dayz_characterID you get what i mean right? Its a painful thing....and all together you gotta make 20-35 changes of that value....its custom for every server so cant really help you further...I had to painfully test every singe function on the server that i changed.....but after that smooth as hell. I did it for everything: basebuilding, upgrades, downgrades, removals, fn_selfactions, pack tent Link to comment Share on other sites More sharing options...
GhostTown Posted February 20, 2014 Report Share Posted February 20, 2014 i'll give you an example...open your fn_self_actions.sqf Search for : dayz_characterID, and here are mine _ownerID = _cursorTarget getVariable ["CharacterID","0"]; ....... if(_isModular and (dayz_playerUID == _ownerID)) then { // dayz_characterID if (_ownerID == dayz_playerUID) then { //Change dayz_characterID to dayz_playerUID for perma owner These are just a few....basically you have to search each major file for dayz_characterID and change it to dayz_playerUID. From my player_upgrade.sqf (for upgrading modular buildings) // check if friendly to owner if(dayz_playerUID == _ownerID) then { //dayz_characterID From player_packTent.sqf if(_ownerID != dayz_playerUID) exitWith {DZE_ActionInProgress = false; s_player_packtent = -1; cutText [localize "str_fail_tent_pack", "PLAIN DOWN"];}; //dayz_characterID you get what i mean right? Its a painful thing....and all together you gotta make 20-35 changes of that value....its custom for every server so cant really help you further...I had to painfully test every singe function on the server that i changed.....but after that smooth as hell. I did it for everything: basebuilding, upgrades, downgrades, removals, fn_selfactions, pack tent My head hurts already. Link to comment Share on other sites More sharing options...
Sandbird Posted February 21, 2014 Report Share Posted February 21, 2014 My head hurts already. Change dayz_characterID to dayz_playerUID, how hard is that seriously. Link to comment Share on other sites More sharing options...
GhostTown Posted February 21, 2014 Report Share Posted February 21, 2014 Change dayz_characterID to dayz_playerUID, how hard is that seriously. I was joking lol and I just dont really know what all files I should look in. Link to comment Share on other sites More sharing options...
Sandbird Posted February 21, 2014 Report Share Posted February 21, 2014 Just get Notepad++ and search for dayz_characterID in your folder of your mission.pbo...should find like 20-30 occurrences. Grab one file (for example anything that has to do with remove) and change the values to dayz_playerUID, and test it....and move on to the next one....just grab an action and test it ...dont just mass replace everything. For online debugging when it come with stuff like that, this is what i do. Make an .sqf file in your root mission folder called admins.sqf. Inside add your UID like this:["133333138"]; Then on top your fn_self_actions.sqf add this line _adminPlayer = call compile preProcessFileLineNumbers "admins.sqf"; Search for : // Allow Owner to lock and unlock vehicle and above it add : if((typeOf(cursortarget) == "Plastic_Pole_EP1_DZ") and (player distance _cursorTarget < 3)) then { if ((getPlayerUID player) in _adminPlayer) then { cutText [format["Plot Pole Owner PUID is: %1",_ownerID], "PLAIN DOWN"]; }; }; like i said my _ownerID value is : _ownerID = _cursorTarget getVariable ["CharacterID","0"]; This way when you are inside the game and you look at a plot pole it will give you the owner's UID. Helps alot when people claim, thats their base and try to get an admin to remove the plot pole :P But yeah...everything based on the UID is making life easier....worth the trouble really. Link to comment Share on other sites More sharing options...
BetterDeadThanZed Posted February 21, 2014 Report Share Posted February 21, 2014 Its very annoying. Its pointless cause, even when we arrive at base after respawn, we usually can easily replace it if we have the means. Its not like making us replace it even does anything, its just a time consuming inconvenience. Why do we have this? If its important, are there other options besides this we can adopt instead? Link to comment Share on other sites More sharing options...
RimBlock Posted May 11, 2014 Report Share Posted May 11, 2014 Whilst changing the buildables linkage to playerUID rather then characterID is possible (I have just released a mod to do it ), there are potential issues. From my mod info Warning - Limitations. 1. This solution has a limitation, the same as all solutions I have seen to deal with this issue. The unique player id (playerUID) which you can think of as your game serial number can be linked to multiple characterIDs. If you die, your characterID changes and your playerUID is linked to it. The limitation comes about because the PlayerUID is stored as a text field (numbers with possible text) and the characterID is stored in a number field with a limitation of a max number of 2147483647 (unsigned). There may be a small possibility than any solution using the playerIUD to substitute the characterID may possibly hit this limiting number. If this occurs you will get an 1264 - Out of Range DB error. 2. In some cases, the playerUID is now being generated with letters included. Due to this the mod converts these letters to the number 9 (one for each letter). There is a slim possibility that this will not result in a unique number. In my view the object_data table is now quite limiting and I would prefer to see and object_data table along with a ownership table and am object type table. The ownership table could deal with who owns the object with options for palyerUID or characterIDs, the object_type table could hold the type of object (eg. buildable, magazine, vehicle etc) so you could quickly reference and update all buildables or all vehicles and leave the rest alone. The problem is that this would then stray further from the main DayZ hive structure and make any DayZ updates harder to integrate in to Epoch. A stopgap measure could be to convert characterID from unsigned int to bigint allowing a much larger number and a bit of room to build unique ids from converted playerUIDs. RB Link to comment Share on other sites More sharing options...
Mercules Posted May 12, 2014 Report Share Posted May 12, 2014 Also, removing plot poles IS hard to do. You end up breaking multiple toolboxes and crowbars and even then you might not succeed. That certainly isn't true. Most of the time nothing breaks and when it does it is typically one broken tool, unless I am beating the odds over and over and over. Link to comment Share on other sites More sharing options...
TheFarix Posted May 12, 2014 Report Share Posted May 12, 2014 That certainly isn't true. Most of the time nothing breaks and when it does it is typically one broken tool, unless I am beating the odds over and over and over. There is a 47% change of breaking a took during an attempt to pull up a plot pole, so you probably are beating the odds. Link to comment Share on other sites More sharing options...
RimBlock Posted May 12, 2014 Report Share Posted May 12, 2014 There is a 47% change of breaking a took during an attempt to pull up a plot pole, so you probably are beating the odds. Would be interested to know how you worked that out. The logic I have is that there is a 10% chance of tool breakage per stage. Each item has 3 stages unless redefined by the DZE_StaticConstructionCount variable. If you own the item or are friendly then you have the original number of stages to remove. If not then the number of stages doubles (i.e. 6 by default). Ref: removes.sqf - no version number in the file. Modes can change the rules so all bets are off then. Link to comment Share on other sites More sharing options...
TheFarix Posted May 12, 2014 Report Share Posted May 12, 2014 10% change to break a tool each stage means 90% success rate per stage.Since you frequently pull up the plot poll after you die, you have to go through 6 stages to pull one upSo the success rate goes like this:First stage: 90% (100 * 90%)Second stage: 81% (90 * 90%)Third stage: 72.9% (81 * 90%)Fourth stage: 65.61% (72.9 * 90%)Fifth stage: 59.049% (65.61 * 90%)Sixth stage: 53.1441% (59.049 * 90%)That gives you an approximate 53% success rate, which means that the failure rate is 47%. Link to comment Share on other sites More sharing options...
Cramps2 Posted May 12, 2014 Report Share Posted May 12, 2014 I think the point is being missed from the OP. None of the players I've met like the current mechanic, every single one of them would prefer vanilla epoch to have plot pole ownership span player deaths. That's why the post was put in feedback, not any of the scripting channels. I agree, and I'm sure plenty of people would be happy to +1 this idea. But it's not our mod - this is merely feedback :D Link to comment Share on other sites More sharing options...
RimBlock Posted May 13, 2014 Report Share Posted May 13, 2014 10% change to break a tool each stage means 90% success rate per stage. Since you frequently pull up the plot poll after you die, you have to go through 6 stages to pull one up So the success rate goes like this: First stage: 90% (100 * 90%) Second stage: 81% (90 * 90%) Third stage: 72.9% (81 * 90%) Fourth stage: 65.61% (72.9 * 90%) Fifth stage: 59.049% (65.61 * 90%) Sixth stage: 53.1441% (59.049 * 90%) That gives you an approximate 53% success rate, which means that the failure rate is 47%. Thanks, Been a long time since I have played around with distribution. Found a binominal online calc though :) . RB Link to comment Share on other sites More sharing options...
RimBlock Posted May 13, 2014 Report Share Posted May 13, 2014 I think the point is being missed from the OP. None of the players I've met like the current mechanic, every single one of them would prefer vanilla epoch to have plot pole ownership span player deaths. That's why the post was put in feedback, not any of the scripting channels. I agree, and I'm sure plenty of people would be happy to +1 this idea. But it's not our mod - this is merely feedback :D Sure and if there was enough recorded (following, thanks, views etc) of the Plot Pole mods then it may give an indication to the developers of the popularity and they may then put some work in to it. Putting the PlayerUID in place of the CharacterUID with the current structure of the hive is not a great idea long term for the reasons I have posted and, however much I like the idea, If I was building the Epoch mod then I would prefer not to touch it. I would look at a redesign of the hive to better suit the purpose as people are trying to shoehorn a lot of functionality in to the the object_data table whose structure was not designed for it. A simple example is that you can not tag cars or safes to players. If you have the combination / key then you can make off with them. This may seem reasonable but you cannot then work out which safes / cars etc belong to which player which limits the possibilities where as a hive redesign would expand on them but would be a lot of work. Potentially you could create an object_data_extended table and link back to the object_data table via objectID. The Epoch team have added the trader tables to the hive so there is a precedent but it would need to be well planned to avoid the need to keep adding new fields to it. The second course is that DayZ was intended to be a "Die and you loose it all" type game and tying the player rather than the character to the plot pole breaks that underlying fundamental concept. You are right though, this is just feedback and ultimately it is up to the dev team to decide on what features they are prepared and able to give the community build up around it. RB Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now