Sign in to follow this  
Propheteer

[Fixed] Lockpicking interruption bug

Recommended Posts

If you are raiding a deed and picking a door, the defender and unlock and relock the door to constantly reset the attackers lockpick timer, making it impossible to lockpick

  • Like 1

Share this post


Link to post
Share on other sites
7 minutes ago, OceanRefuge said:

sound intended to me ?  

what, are you joking?

Share this post


Link to post
Share on other sites

my bad read below

Edited by polarbear
looked at WU code

Share this post


Link to post
Share on other sites
5 minutes ago, polarbear said:

if you unlock a door, it should interrupt the timer since there is no longer a lock there. so for code reasons it is intended. 

 

 To the OP: 

just because an opposite kingdom doesn't do something you like, does NOT mean it is a bug all of the time. Please stop wasting a dev's time and energy for something you think is a bug, when they could be fixing an actual bug. Your opinion is not a bug. If I could read java better I'd pull up the WU code, but we have Java experts here like keenan or budda that can do that, if it says in the code if someone unlocks the door (no lock there anymore, meaning nothing to pick) , then a person unlocks the door and it interrupts the timer then its not a bug. 

no, you're wrong

Share this post


Link to post
Share on other sites

i think proph is saying once you pick a lock on a house you get a timer saying the door will lock in 200 seconds.. etc.

 

the house owner/manager is then  able is able to manage the house writ even if he is 10 locals away..  unlock and lock the door resetting the lockpick timer to 0 at any time he wants

Share this post


Link to post
Share on other sites
1 minute ago, Mattown said:

no, you're wrong

just a no, please explain in an educational manor with the WU code, how its not intended, and not acting like a child. I don't mind an argument, but saying I'm wrong with no for front premises that can be proved by code is not logical

 

Share this post


Link to post
Share on other sites
10 minutes ago, polarbear said:

if you unlock a door, it should interrupt the timer since there is no longer a lock there. so for code reasons it is intended. 

 

 To the OP: 

just because an opposite kingdom doesn't do something you like, does NOT mean it is a bug all of the time. Please stop wasting a dev's time and energy for something you think is a bug, when they could be fixing an actual bug. Your opinion is not a bug. If I could read java better I'd pull up the WU code, but we have Java experts here like keenan or budda that can do that, if it says in the code if someone unlocks the door (no lock there anymore, meaning nothing to pick) , then a person unlocks the door and it interrupts the timer then its not a bug. 

 

 

So lockpicking should no longer be allowed for gatehouses if the mayor is present? Why not just outright remove the feature on enemy deeds in that case?

 

The "opposite kingdom" in this circumstance asked me politely to report it, so i did. Its not just something i think is a bug, it's something the enemy in question thinks is a bug and has reported before, and the players around me think is a bug. I don't think a feature should be removed because the mayor is present, especially in a scenario where it might be useful.

Share this post


Link to post
Share on other sites
10 minutes ago, polarbear said:

if you unlock a door, it should interrupt the timer since there is no longer a lock there. so for code reasons it is intended.

Wrong buddy.

 

Pick a lock (if you can) then examine the door. Post the event log.

Share this post


Link to post
Share on other sites

coming from mr  this tactic was used against us many many times while raiding jk deeds. i agree it should be changed but no one ever listened to us so i wish you luck

Share this post


Link to post
Share on other sites
4 minutes ago, hemrzz said:

i think proph is saying once you pick a lock on a house you get a timer saying the door will lock in 200 seconds.. etc.

 

the house owner/manager is then  able is able to manage the house writ even if he is 10 locals away..  unlock and lock the door resetting the lockpick timer to 0 at any time he wants

no hes saying that unlocking and relocking the door shouldn't interupt the lockpicking action itself, (which it has ALWAYS done)

 

Relocking a house door doesn't actually reset a "picked" door anyway

Share this post


Link to post
Share on other sites

I'm not saying unlocking/re-locking automatically is not a bug. I can agree that unlocking with a time is intended, but I'm sure somewhere in the code it checks if there is a "temp" lock on the door you can re-lock with out a timer. Honestly wouldn't mind if there was a timer after you unlock it to "re-lock it".

 

 

 

Edited by polarbear

Share this post


Link to post
Share on other sites

Ok. here we go 

 

 lockId = target.getLockId();
    }
    catch (NoSuchLockException nsl)
    {
      performer.getCommunicator().sendNormalServerMessage("The " + name + " has no lock to pick.", (byte)3);
      return true;
    }
    if (lockpick.getTemplateId() != 463)
    {
      performer.getCommunicator().sendNormalServerMessage("The " + lockpick.getName() + " can not be used as a lockpick.", (byte)3);
      return true;
    }
    if (target.isNotLockpickable())
    {
      performer.getCommunicator().sendNormalServerMessage("The " + name + " can not be lockpicked.", (byte)3);
      return true;
    }
    if (!target.isLocked())
    {
      performer.getCommunicator().sendNormalServerMessage("The " + name + " is not locked.", (byte)3);
      return true;

 

 

if there is no lock, it won't let you pick;

 

buf.append(permission("noLockpick", this.obj.isNotLockpickable(), "Not Lockpickable", this.obj.canDisableLockpicking(), "Tick to disallow lockpicking of this item.", "Item is always not lockpickable.", "Item cannot be made not-lockpickable (cannot have a lock?)"));  

 

It seems it is a bug since there technically atleast WU code clearly states that it can't be not lockpickable if the door has a lock.


  public boolean canBeUnlockedByKey(Item key)
  {
    Item doorlock = null;
    try
    {
      doorlock = Items.getItem(this.lock);
    }
    catch (NoSuchItemException nsi)
    {
      return false;
    }
    if (doorlock.isLocked())
    {
      if (doorlock.isUnlockedBy(key.getWurmId())) {
        return true;
      }
      return false;
    }
    return false;
  }
  
  public boolean canBeUnlockedBy(Creature creature)
  {
    return mayPass(creature);

 

When Item is unlocked, you can clearly pass through. because it was unlocked by (some player)

 

public abstract class Door
  implements MiscConstants, SoundNames, TimeConstants, PermissionsPlayerList.ISettings
{
  Wall wall;
  private static Logger logger = Logger.getLogger(Door.class.getName());
  long lock = -10L;
  long structure = -10L;
  boolean open = false;
  VolaTile outerTile;
  VolaTile innerTile;
  protected int startx;
  protected int starty;
  protected int endx;
  protected int endy;
  Set<Creature> creatures;
  Set<VirtualZone> watchers;

  short lockCounter = 0;
  boolean preAlertLockedStatus = false;
  String name = "";
  
  Door() {}
  
  Door(Wall _wall)
  {
    this.wall = _wall;
  }
  
  public final void setLockCounter(short newcounter)
  {
    if ((this.lockCounter <= 0) || (newcounter <= 0)) {
      playLockSound();
    }
    this.lockCounter = newcounter;
  }
  
  public short getLockCounter()
  {
    return this.lockCounter;
  }
  
  public String getLockCounterTime()
  {
    int m = this.lockCounter / 120;
    int s = this.lockCounter % 120 / 2;
    if (m > 0) {
      return m + " minutes and " + s + " seconds.";
    }
    return s + " seconds.";

 

 

It seems if the door already has a lock on it, and you unlock the door, it "removes the lock" and from the code above it states that if a door or item does not have a lock, it is no longer lock-pickable. But once it has a lock on it, the code does a check and sets the re-lock timer to 0 seconds. (in green). In red it is worded weirdly, but if its Pre- put lock on = false, I would assume that means if the door or item had previously no lock on it to attach the lock, the timer would not be the short timer of 0. 

 

Conclusion: Sad to say it is intended. 

If there is no lock on the door, it will interrupt the action, (stated above, and in code) and when the door is re-locked it checks if there was previously a lock on it or not, and if there was, then the timer is set to 0. 

Edited by polarbear

Share this post


Link to post
Share on other sites
1 hour ago, polarbear said:

Conclusion: Sad to say it is intended. 

If there is no lock on the door, it will interrupt the action, (stated above, and in code) and when the door is re-locked it checks if there was previously a lock on it or not, and if there was, then the timer is set to 0. 

 

Orrr its an oversight, but i'm sure the developers are capable of knowing what is intended or not in their own game. If its not an actual bug this thread will be ignored.

  • Like 1

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this