Posted October 16, 2016 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 1 Share this post Link to post Share on other sites
Posted October 16, 2016 7 minutes ago, OceanRefuge said: sound intended to me ? what, are you joking? Share this post Link to post Share on other sites
Posted October 16, 2016 (edited) my bad read below Edited October 16, 2016 by polarbear looked at WU code Share this post Link to post Share on other sites
Posted October 16, 2016 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
Posted October 16, 2016 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
Posted October 16, 2016 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
Posted October 16, 2016 (edited) Edited October 16, 2016 by OceanRefuge Share this post Link to post Share on other sites
Posted October 16, 2016 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
Posted October 16, 2016 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
Posted October 16, 2016 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
Posted October 16, 2016 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
Posted October 16, 2016 (edited) 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 October 16, 2016 by polarbear Share this post Link to post Share on other sites
Posted October 16, 2016 (edited) . Edited October 16, 2016 by polarbear Share this post Link to post Share on other sites
Posted October 16, 2016 (edited) 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 October 16, 2016 by polarbear Share this post Link to post Share on other sites
Posted October 16, 2016 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. 1 Share this post Link to post Share on other sites
Posted October 16, 2016 Added to the list for the devs. Thanks for the details. 3 Share this post Link to post Share on other sites
Posted August 15, 2018 Fixed: https://forum.wurmonline.com/index.php?/topic/164791-patch-notes-14aug18/ Share this post Link to post Share on other sites