Item opener: tooltip scanning version #92
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
November 24, 2013 16:46
The BAG_UPDATE_DELAYED event fires after a batch of individual BAG_UPDATE events are sent out; this allows users to avoid over-processing from multiple changes such as "moved item" triggering several individual updates. In both cases the BAG_UPDATE event was used, this will have the same outcome but potentially trigger less work scanning bag content. Signed-off-by: Daniel Pittman <[email protected]>
This replaces the hard-coded item openers with a tooltip scanning version; instead of coding up a hand maintained list of items that can be opened we scan for the global string injected into the tooltip by WoW. This is reasonably fast, and only needs invocation when inventory changes. To avoid encoding complexities like lockboxes that become openable, but only after being picked, we don't cache data at present. In testing, this is fast enough that I am unable to detect either a frame rate drop cost from this change, or enough CPU use to register in a significant fashion in the built-in CPU profiling tools. The implementation is generic enough that it can be reused with more than one opener, and will only scan each item tooltip once no matter how many patterns are active on each change. Signed-off-by: Daniel Pittman <[email protected]>
|
Hey, thanks for actually implementing this. I finally got my subscription back up, so I was able to play with this. I've refactored it down a bunch, you can view the new version here: https://github.com/TekNoLogic/Cork/blob/master/modules/OpenableItems.lua |
|
Thanks. I will be studying the rewritten versions in more detail to try |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a "discussion" patch for replacing the current OpenableItems module. It is not yet ready to merge.
It uses a tooltip scanner, and the global string used to indicate if an item can be opened, to scan inventory items for opening rather than maintaining a human list. While not applicable to all attributes of items, this allows for basic tooltip based interaction with them items.
I have tested this in actual play, and simulated as many odd scenarios as I can envision, and can't currently break it. (Which, naturally, means that I will find an embarrassing bug the instance I click "send pull request" ;)
The approach is generic enough to extend to other attributes of items, which is quite deliberate: locked boxes are also identified with a global string, and I would like to implement a scanner for those next to automatically unlock them. (Some additional infrastructure and refactoring required, but the heart of the scanning engine will remain the same.)
It is also easy to change to allow multiple patterns, rather than just one, per actor; that just waits on an actual need.
I am uncertain if extending this to scan for, eg, combined items is a good plan. They don't use a uniform i18n global string, which means that we have no assurance that they will continue to work correctly once the next generation are released, and we have to handle i18n patterns ourselves. I like the idea, but I suspect that hand-maintained lists are better value overall.
If you like the principal I will finish off this work and update the pull request: rename the scanner to something more reasonable, remove the now redundant template and modules, and generally get it up to quality.
While I have a reasonable grasp of what I wanted to do, my WoW Lua programming experience is relatively limited; if there are potential trouble spots in the code let me know and I can fix those too.