Quantcast
Download
(3 Kb)
Download
Updated: 06/04/21 06:23 AM
Pictures
File Info
Compatibility:
Blackwood (7.0.5)
Flames of Ambition (6.3.5)
Updated:06/04/21 06:23 AM
Created:05/25/21 09:50 AM
Monthly downloads:527
Total downloads:528
Favorites:2
MD5:
7.0.5
LockpickNotifier
Version: 1.3
by: Rednas [More]

A simple add-on i made for myself, to notify my party members i found a chest in a dungeon.
Due to requests to share the add-on, i uploaded it here!
I hope you guys like it!

What does this addon do:
  • Detects when you try to pick a lock
  • If you try to pick a locked chest in a dungeon, it will automatically add a string to the party chat that you found a chest. (you only need to press Enter)

What can you configure (/lpn for the settings page):
  • When the add-on should be active (group dungeon, trail, neither or both)
    Default: Group Dungeons only
  • Your own text, use %s for the difficulty
    Default: Chest found, quality: %s
  • Your own alternatives for the chest difficulty
    Default: Simple, Intermediate, Advanced & Master


REQUIRED LIBRARIES:


Notice:
This add-on is made as a hobby project in my free time. I'm not a professional developer. I can't promise (regular) updates, (quick) bug fixes, that the add-on is bug free or 100% optimized. I however did my best to make it as useful as possible. This is also why I included the "AS IS" notice in the folder. I hope however that this add-on will be useful to someone.
;Changelog 1.3
; - Added Settings
; - Turn on/off in trial, group dungeon
; - Custom chest difficulty names
; - Custom string
; - Changed API version

V1.2:
  • Improved the chest detection (Thanks to other helpful authors)
  • It should now work with the EN, FR, DE and RU cliŽnt
  • Removed the capital from Quality.


V1.1:
added an unregister to the EVENT_ADD_ON_LOADED event
Archived Files (2)
File Name
Version
Size
Uploader
Date
1.2
2kB
Rednas
05/26/21 09:42 AM
1.1
1kB
Rednas
05/25/21 10:46 AM


Post A Reply Comment Options
Unread 06/11/21, 05:13 AM  
Rednas
AddOn Author - Click to view AddOns

Forum posts: 0
File comments: 4
Uploads: 2
Originally Posted by Huntardy
Is there a way to make the addon press enter for the user?
As far as i know it isn't possible with the API, because you could make spam addon's with it.
Report comment to moderator  
Reply With Quote
Unread 06/10/21, 08:46 PM  
Huntardy

Forum posts: 0
File comments: 1
Uploads: 0
Is there a way to make the addon press enter for the user?
Report comment to moderator  
Reply With Quote
Unread 05/26/21, 03:17 PM  
xgoku1
AddOn Author - Click to view AddOns

Forum posts: 5
File comments: 4
Uploads: 1
Originally Posted by Rednas
Thanks for the idea's, but for my add-on it's enough to know the difficulty of the dungeon. 0 is a delve, 1 and 2 are dungeons. Adding a lib or another way to detect if you are in a dungeon, should not be needed. (double tested it today, it only triggers in a dungeon)
Nice. Much better solution than my table check method, I'll use this as well - will save me a lot of trouble in the future. Thanks
Report comment to moderator  
Reply With Quote
Unread 05/26/21, 10:47 AM  
Baertram
 
Baertram's Avatar
AddOn Author - Click to view AddOns

Forum posts: 3536
File comments: 4321
Uploads: 68
Thanks, good to know! This eases the checks a lot imo.
Originally Posted by Rednas
Checked the public dungeons as well before i released it here, they also return 0. Rechecked it today before i submitted v1.2 and the ones i checked returned 0. So i kept this validation intact.

Originally Posted by Baertram
The dungeon can be also checked via IsUnitInDungeon("player") and "IsUnitGrouped("player") == true as you would port out of a real dungeon (non-delve) if you are not grouped (after 2 mins of time I think), or did they change that?
But the GetCurrentZoneDungeonDifficulty() idea should work even better then, if it always returns 1 or 2 for "real group dungeons" and 0 for delves. Need to check if this applies to PubDungeons as well.

Originally Posted by Rednas
Originally Posted by xgoku1
Just to add to what Baertram said, IsUnitInDungeon returns true even for a delve and public dungeon.

In my addon I check if the value of GetZoneId(GetUnitZoneIndex("player")) is in a table containing the ids of the dungeon to satisfy the conditional code (you can find the zoneId for dungeons from LibSets datasheet) - should be a language independent implementation

I also use the FISHING_MANAGER hack mentioned to correctly identify a chest, perhaps you can get some ideas from my code.

Not sure if multiple FISHING_MANAGER calls from different addons will conflict, from my testing it should be fine as long as they are not called with the exact same ms in the RegisterForUpdate registered function
Thanks for the idea's, but for my add-on it's enough to know the difficulty of the dungeon. 0 is a delve, 1 and 2 are dungeons. Adding a lib or another way to detect if you are in a dungeon, should not be needed. (double tested it today, it only triggers in a dungeon)

Thanks to Baertram, i was also able to update the chest detection. I will take a look at your add-on if i find any more difficulties
Report comment to moderator  
Reply With Quote
Unread 05/26/21, 10:46 AM  
Rednas
AddOn Author - Click to view AddOns

Forum posts: 0
File comments: 4
Uploads: 2
Checked the public dungeons as well before i released it here, they also return 0. Rechecked it today before i submitted v1.2 and the ones i checked returned 0. So i kept this validation intact.

Originally Posted by Baertram
The dungeon can be also checked via IsUnitInDungeon("player") and "IsUnitGrouped("player") == true as you would port out of a real dungeon (non-delve) if you are not grouped (after 2 mins of time I think), or did they change that?
But the GetCurrentZoneDungeonDifficulty() idea should work even better then, if it always returns 1 or 2 for "real group dungeons" and 0 for delves. Need to check if this applies to PubDungeons as well.

Originally Posted by Rednas
Originally Posted by xgoku1
Just to add to what Baertram said, IsUnitInDungeon returns true even for a delve and public dungeon.

In my addon I check if the value of GetZoneId(GetUnitZoneIndex("player")) is in a table containing the ids of the dungeon to satisfy the conditional code (you can find the zoneId for dungeons from LibSets datasheet) - should be a language independent implementation

I also use the FISHING_MANAGER hack mentioned to correctly identify a chest, perhaps you can get some ideas from my code.

Not sure if multiple FISHING_MANAGER calls from different addons will conflict, from my testing it should be fine as long as they are not called with the exact same ms in the RegisterForUpdate registered function
Thanks for the idea's, but for my add-on it's enough to know the difficulty of the dungeon. 0 is a delve, 1 and 2 are dungeons. Adding a lib or another way to detect if you are in a dungeon, should not be needed. (double tested it today, it only triggers in a dungeon)

Thanks to Baertram, i was also able to update the chest detection. I will take a look at your add-on if i find any more difficulties
Report comment to moderator  
Reply With Quote
Unread 05/26/21, 10:32 AM  
Baertram
 
Baertram's Avatar
AddOn Author - Click to view AddOns

Forum posts: 3536
File comments: 4321
Uploads: 68
The dungeon can be also checked via IsUnitInDungeon("player") and "IsUnitGrouped("player") == true as you would port out of a real dungeon (non-delve) if you are not grouped (after 2 mins of time I think), or did they change that?
But the GetCurrentZoneDungeonDifficulty() idea should work even better then, if it always returns 1 or 2 for "real group dungeons" and 0 for delves. Need to check if this applies to PubDungeons as well.

Originally Posted by Rednas
Originally Posted by xgoku1
Just to add to what Baertram said, IsUnitInDungeon returns true even for a delve and public dungeon.

In my addon I check if the value of GetZoneId(GetUnitZoneIndex("player")) is in a table containing the ids of the dungeon to satisfy the conditional code (you can find the zoneId for dungeons from LibSets datasheet) - should be a language independent implementation

I also use the FISHING_MANAGER hack mentioned to correctly identify a chest, perhaps you can get some ideas from my code.

Not sure if multiple FISHING_MANAGER calls from different addons will conflict, from my testing it should be fine as long as they are not called with the exact same ms in the RegisterForUpdate registered function
Thanks for the idea's, but for my add-on it's enough to know the difficulty of the dungeon. 0 is a delve, 1 and 2 are dungeons. Adding a lib or another way to detect if you are in a dungeon, should not be needed. (double tested it today, it only triggers in a dungeon)

Thanks to Baertram, i was also able to update the chest detection. I will take a look at your add-on if i find any more difficulties
Last edited by Baertram : 05/26/21 at 10:35 AM.
Report comment to moderator  
Reply With Quote
Unread 05/26/21, 09:46 AM  
Rednas
AddOn Author - Click to view AddOns

Forum posts: 0
File comments: 4
Uploads: 2
Originally Posted by xgoku1
Just to add to what Baertram said, IsUnitInDungeon returns true even for a delve and public dungeon.

In my addon I check if the value of GetZoneId(GetUnitZoneIndex("player")) is in a table containing the ids of the dungeon to satisfy the conditional code (you can find the zoneId for dungeons from LibSets datasheet) - should be a language independent implementation

I also use the FISHING_MANAGER hack mentioned to correctly identify a chest, perhaps you can get some ideas from my code.

Not sure if multiple FISHING_MANAGER calls from different addons will conflict, from my testing it should be fine as long as they are not called with the exact same ms in the RegisterForUpdate registered function
Thanks for the idea's, but for my add-on it's enough to know the difficulty of the dungeon. 0 is a delve, 1 and 2 are dungeons. Adding a lib or another way to detect if you are in a dungeon, should not be needed. (double tested it today, it only triggers in a dungeon)

Thanks to Baertram, i was also able to update the chest detection. I will take a look at your add-on if i find any more difficulties
Last edited by Rednas : 05/26/21 at 09:48 AM.
Report comment to moderator  
Reply With Quote
Unread 05/26/21, 08:37 AM  
xgoku1
AddOn Author - Click to view AddOns

Forum posts: 5
File comments: 4
Uploads: 1
Just to add to what Baertram said, IsUnitInDungeon returns true even for a delve and public dungeon.

In my addon I check if the value of GetZoneId(GetUnitZoneIndex("player")) is in a table containing the ids of the dungeon to satisfy the conditional code (you can find the zoneId for dungeons from LibSets datasheet) - should be a language independent implementation

I also use the FISHING_MANAGER hack mentioned to correctly identify a chest, perhaps you can get some ideas from my code.

Not sure if multiple FISHING_MANAGER calls from different addons will conflict, from my testing it should be fine as long as they are not called with the exact same ms in the RegisterForUpdate registered function
Report comment to moderator  
Reply With Quote
Unread 05/26/21, 06:04 AM  
Trinity Is My Name

Forum posts: 0
File comments: 27
Uploads: 0
Smile Such A Useful Addon! Thanks So Much!

Thanks so much for this! I run a lot of dungeons and this Addon helps immensely!
Report comment to moderator  
Reply With Quote
Unread 05/25/21, 10:16 AM  
Baertram
 
Baertram's Avatar
AddOn Author - Click to view AddOns

Forum posts: 3536
File comments: 4321
Uploads: 68
Btw via the interactionManager (the FISHING_MANAGER is a "hack" to point to the interacton manager, as it seems to be the global variable given we can use for it) one can indentify chests. They are "not owned" and their actionText will be GetString(SI_GAMECAMERAACTIONTYPE12) ("Unlock").

Lua Code:
  1. local myAddonInteractionData = {}
  2. SecurePostHook(FISHING_MANAGER, "StartInteraction", function(...)
  3.         myAddonInteractionData = {}
  4.     myAddonInteractionData.action, myAddonInteractionData.name, myAddonInteractionData.blockedNode, myAddonInteractionData.isOwned = GetGameCameraInteractableActionInfo()
  5. end)

In your EVENT_LOCKPICK_STARTED then e.g. do something like:
Lua Code:
  1. function LPN.StartLockpick(event)
  2.   --Abort if we are not in a dungeon or if we are in a raid
  3.   if not IsUnitInDungeon("player") or IsPlayerInRaid() then return end
  4.   --Check if the last interaction was with an unowned item and if the text was "Unlock"
  5.   if myAddonInteractionData.isOwned or myAddonInteractionData.action ~= GetString(SI_GAMECAMERAACTIONTYPE12) then
  6.     --reset the variables
  7.     myAddonInteractionData = {}
  8.     --Abort here
  9.     return
  10.    end
  11. ...
  12. --Your other code here but without the boss checks as this should be handled via the interactionManager isOwned and actionText now above!
  13. end

Maybe you are able to strip the boss name check this way (as you only check for English names and not also German, French, and Russian (the other official languages of this game!) as it hopefully will not fire for a door opening as the text is different than "Unlock" (GetString(SI_GAMECAMERAACTIONTYPE12)). And using the string constant SI_GAMECAMERAACTIONTYPE12, which is translated properly in the supported languages, will be an easier way so you ONLY need to check once at the lockpick event callback function if you are in a dungeon:


You only need to test if FISHING_MANAGER:StartInteraction is fired before the event_lockpick_start but I think I remember it must be.

Small performance improvement:
Do not check if the player is in combat each time in your loop! Just do it once at the start of the function as it will be enough. The combat state most likely will not change in the few ms the source code needs to run through your callback function.
Same for other IsUnit checks. If not needed inside the loop (like get the boss 1, 2, 3) it should be done before and stored in a locla variable if you need to re-use it more than 1 time in your following code.
Last edited by Baertram : 05/25/21 at 10:23 AM.
Report comment to moderator  
Reply With Quote
Unread 05/25/21, 10:14 AM  
Rednas
AddOn Author - Click to view AddOns

Forum posts: 0
File comments: 4
Uploads: 2
Originally Posted by Baertram
Thanks for the addon.
You should Unregister the EVENT_ADD_ON_LOADED after your addon was found again as it else will fire again for each of your addons, and will run your addonName comparison then each time again, for nothing.

Lua Code:
  1. function LPN.OnAddOnLoaded(event, addonName)
  2.   if addonName == LPN.name then
  3.     --EVENT_ADD_ON_LOADED will be called for EACH of your installed addons and libs 1 time! So unregister it again after your addon was determined via the if addonName == LPN.name then check
  4.     EVENT_MANAGER:UnregisterForEvent(LPN.name, EVENT_ADD_ON_LOADED)
  5.     LPN:Initialize()
  6.   end
  7. end
  8.  
  9. EVENT_MANAGER:RegisterForEvent(LPN.name, EVENT_ADD_ON_LOADED, LPN.OnAddOnLoaded)
Thanks for the suggestion, i will add it to the add-on. Totally forgot about it!
Report comment to moderator  
Reply With Quote
Unread 05/25/21, 10:08 AM  
Baertram
 
Baertram's Avatar
AddOn Author - Click to view AddOns

Forum posts: 3536
File comments: 4321
Uploads: 68
Thanks for the addon.
You should Unregister the EVENT_ADD_ON_LOADED after your addon was found again as it else will fire again for each of your addons, and will run your addonName comparison then each time again, for nothing.

Lua Code:
  1. function LPN.OnAddOnLoaded(event, addonName)
  2.   if addonName == LPN.name then
  3.     --EVENT_ADD_ON_LOADED will be called for EACH of your installed addons and libs 1 time! So unregister it again after your addon was determined via the if addonName == LPN.name then check
  4.     EVENT_MANAGER:UnregisterForEvent(LPN.name, EVENT_ADD_ON_LOADED)
  5.     LPN:Initialize()
  6.   end
  7. end
  8.  
  9. EVENT_MANAGER:RegisterForEvent(LPN.name, EVENT_ADD_ON_LOADED, LPN.OnAddOnLoaded)
Last edited by Baertram : 05/25/21 at 10:16 AM.
Report comment to moderator  
Reply With Quote
Post A Reply



Category Jump: