Jump to content
  • 0

Duping Fix

Guest

Asked by Guest,

 Share

Question

13 answers to this question

Recommended Posts

  • 0
raymix Newbie

raymix

Posted
Posted

I just found this http://pastebin.com/MrfqevXN but not sure on how to implement it.

 

By the way is there anything in the logs that I can keep an eye out for in terms of the logout version of this issue. I'm not really sure which one I should be looking in, RPT? BE logs? Hive?

Here's full tutorial. Works like a charm

 

Although people can still disconnect dupe, haven't seen fix for that yet

 

Possible solutions?:

*Do not save gear array when backpack is in the vehicle - remove ability to store full backpacks. Just like if you were to put one in a safe and lock it, backpack would be emptied.

*Give backpacks unique objectID, attached to it's owner, delete if duplicate ID

*Force refresh loot info (at least within distance) upon joining. Guess some things could be brought client side.

*Upon losing connection knockout client side

*Upon losing connection run closeDialog inside while loop on everything except ESC dialog. Basically it will close any GUI element that is not ESC menu, disabling ability to open gear and store bpack. Must be ran locally ofc.

Link to comment
Share on other sites
  • 0
RimBlock Newbie

RimBlock

Posted
Posted

Warn the user that if they logoff while disconnected they will lose any pending changes.

 

I tend to agree that object which can store other objects should have their own object_data record so they can be better tracked to make sure they are not duped.

 

Macas script (if it is the same as was orginially posted here) is centered around checking pre and post vault lock to make sure the souce and destination inventories have not changed in-between.  There is still a potential for cheating though as a third party could unload the safe during the vault and their inventory is not under the checks.  It would be tricky to execute as you cannot lock / unlock with another player within a set distance but may still be feasible.  There was also the possibility of someone adding or taking from the locking players inventory (possibly innocently or without the locking players knowledge) whilst they are locking the safe and getting them flagged as trying to cheat.  Macas soluion also had emphasis on reporting those who tried to perform the duping.

 

I personally believe in closing the holes and am not too concerned on reporting on opportunists who try to exploit them.  I dont report everyone who port scans my firewall to their ISPs for example.

 

The suggestion to disable someone accessing the gear while the safe is locking was made on the original thread here (since deleted when Maca got banned) but Maca did not seem interested in engaging in any discussion around that line.

 

Having just scanned through the current vaultlock.sqf code, it seems the process is

  • Check if safe already being locked by player.
  • Check the safe still exists.
  • Play animation
  • Check safe is not being locked by someone else.
  • Check player knows the combination.
  • Create a new locked safe.
  • Place the new safe.
  • Copy the unlocked safe contents to it.
  • Delete the unlocked safe.

Easiest fix would probably be to amend dayz_code/actions/dayz_spaceInterrupt.sqf and add code to check if the cursotTarget object is being locked.

 

This is not tested.  Use at your own risk (this means it if turns your computer blue, gives you uncontrolable bowel movements or turns your mother in to a unstopable ninja killing machine, or anything else unexpected I am not liable ;) ).  Something like the following may work.

 
Find
if ((_dikCode in actionKeys "Gear") and (vehicle 
player != player) and !_shift and !_ctrl and !_alt && !dialog) then 
{
createGearDialog [player, 
"RscDisplayGear"];
_handled = true;
};
Change to
if ((_dikCode in actionKeys "Gear") and (vehicleplayer != player) and !_shift and !_ctrl and !_alt && !dialog) then{
  _Cobj = cursorTarget;
  _CobjType = typeOf _Cobj;
  _Cobjectname = getText(configFile >> "CfgVehicles" >> _CobjType >> ("displayname");
  if (_Cobjectname = "safe")then {
    if(s_player_lockvault < 1) 
      then{  createGearDialog [player, "RscDisplayGear"];
      _handled = true;
    };
  }else{ 
    createGearDialog [player, "RscDisplayGear"];
    _handled = true;
  };
};

Find

private 
["_dikCode","_handled","_primaryWeapon","_secondaryWeapon","_nearbyObjects","_nill","_shift","_ctrl","_alt","_dropPrimary","_dropSecondary","_iItem","_removed","_iPos","_radius","_item"];

Change to

private
["_dikCode","_handled","_primaryWeapon","_secondaryWeapon","_nearbyObjects","_nill","_shift","_ctrl","_alt","_dropPrimary","_dropSecondary","_iItem","_removed","_iPos","_radius","_item", 
"Cobj","CobjType","CobjectName"];

What that should do is disable the lockers gear dialogue whilst the lock vault script is running. 

 

THere is an object variable used as a flag to denote the safe is being locked ("packing") but it is only set after the animation...

 

Again, this is code I have written away from any test server so I have no way of confirming it works in any way, but logically it should be sound.  It can also probably be improved upon so if anyone else wants to chip in then please go right ahead.

 

RB

Link to comment
Share on other sites
  • 0
THEbookie Newbie

THEbookie

Posted
Posted

Alright I can't tell if this works as people lock there safes and get kicked for "pubic variable restriction #3" ever after i put the PVDZE_lockVault inside my filter could someone tell me where in the filter it should go? or maybe show me yours  ;)

Link to comment
Share on other sites
  • 0
Just_R Newbie

Just_R

Posted
Posted

This is just a side note:

 

another Maca addition to this community. . . maybe his last? 

 

Very sad.

Warn the user that if they logoff while disconnected they will lose any pending changes.

 

I tend to agree that object which can store other objects should have their own object_data record so they can be better tracked to make sure they are not duped.

 

Macas script (if it is the same as was orginially posted here) is centered around checking pre and post vault lock to make sure the souce and destination inventories have not changed in-between.  There is still a potential for cheating though as a third party could unload the safe during the vault and their inventory is not under the checks.  It would be tricky to execute as you cannot lock / unlock with another player within a set distance but may still be feasible.  There was also the possibility of someone adding or taking from the locking players inventory (possibly innocently or without the locking players knowledge) whilst they are locking the safe and getting them flagged as trying to cheat.  Macas soluion also had emphasis on reporting those who tried to perform the duping.

 

I personally believe in closing the holes and am not too concerned on reporting on opportunists who try to exploit them.  I dont report everyone who port scans my firewall to their ISPs for example.

 

The suggestion to disable someone accessing the gear while the safe is locking was made on the original thread here (since deleted when Maca got banned) but Maca did not seem interested in engaging in any discussion around that line.

 

Having just scanned through the current vaultlock.sqf code, it seems the process is

  • Check if safe already being locked by player.
  • Check the safe still exists.
  • Play animation
  • Check safe is not being locked by someone else.
  • Check player knows the combination.
  • Create a new locked safe.
  • Place the new safe.
  • Copy the unlocked safe contents to it.
  • Delete the unlocked safe.

Easiest fix would probably be to amend dayz_code/actions/dayz_spaceInterrupt.sqf and add code to check if the cursotTarget object is being locked.

 

This is not tested.  Use at your own risk (this means it if turns your computer blue, gives you uncontrolable bowel movements or turns your mother in to a unstopable ninja killing machine, or anything else unexpected I am not liable ;) ).  Something like the following may work.

 
Find
if ((_dikCode in actionKeys "Gear") and (vehicle 
player != player) and !_shift and !_ctrl and !_alt && !dialog) then 
{
createGearDialog [player, 
"RscDisplayGear"];
_handled = true;
};
Change to
if ((_dikCode in actionKeys "Gear") and (vehicleplayer != player) and !_shift and !_ctrl and !_alt && !dialog) then{
  _Cobj = cursorTarget;
  _CobjType = typeOf _Cobj;
  _Cobjectname = getText(configFile >> "CfgVehicles" >> _CobjType >> ("displayname");
  if (_Cobjectname = "safe")then {
    if(s_player_lockvault < 1) 
      then{  createGearDialog [player, "RscDisplayGear"];
      _handled = true;
    };
  }else{ 
    createGearDialog [player, "RscDisplayGear"];
    _handled = true;
  };
};

Find

private 
["_dikCode","_handled","_primaryWeapon","_secondaryWeapon","_nearbyObjects","_nill","_shift","_ctrl","_alt","_dropPrimary","_dropSecondary","_iItem","_removed","_iPos","_radius","_item"];

Change to

private
["_dikCode","_handled","_primaryWeapon","_secondaryWeapon","_nearbyObjects","_nill","_shift","_ctrl","_alt","_dropPrimary","_dropSecondary","_iItem","_removed","_iPos","_radius","_item", 
"Cobj","CobjType","CobjectName"];

What that should do is disable the lockers gear dialogue whilst the lock vault script is running. 

 

THere is an object variable used as a flag to denote the safe is being locked ("packing") but it is only set after the animation...

 

Again, this is code I have written away from any test server so I have no way of confirming it works in any way, but logically it should be sound.  It can also probably be improved upon so if anyone else wants to chip in then please go right ahead.

 

RB

Link to comment
Share on other sites
  • 0
Just_R Newbie

Just_R

Posted
Posted

Did they fix the place the safe down within the 1 minute mark? once the server hits 1 minute apparently it lags and if someone places a safe they get that safe and one in their inventory that they originally started with.

 

 

The duplication method when disconnecting is a pain the ass, we catch between 5-15 per day doing it!

Only thing to look out for is player **** is losing connection, then quickly spectate.

Link to comment
Share on other sites
  • 0
deicide Newbie

deicide

Posted
Posted

Alright I can't tell if this works as people lock there safes and get kicked for "pubic variable restriction #3" ever after i put the PVDZE_lockVault inside my filter could someone tell me where in the filter it should go? or maybe show me yours  ;)

 

You needed to add that as an exception in the first filter. I think you added a new filter making BE kick for its use. since that file should not have a 3rd line to get kicked for a #3 error.

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share
Go to question listing
  • Advertisement

  • Discord

×
×
  • Create New...