Authors CurseForge

This is the technical "package" answer I needed btw: "move-folders:" in pkgmeta.

Perhaps I should just consider getting away from using the wowace localization web-site tools?

Hermes has a "core" engine addon, a separate "UI" module, and then multiple modules for the UI itself.

Basically, I have something like:
Hermes [core]
Hermes [UI]
Hermes [UI-OptionalModule1]
Hermes [UI-OptionalModule2]
Hermes [UI-OptionalModule3]

I'm not sure the best practice for packaging up and shipping my addon. My concerns are maintenance, localization, intuitiveness, and not making things a pain for my users.

Right now I ship the "UI" as a module including with Hermes. But two things have always bugged me:

1. It's never been obvious to my users that the UI is actually a separate module which can be enabled/disabled (as exposed through Hermes configuration options). Yes, there are reasons to do this.
2. Localization gets ugly. I probably have 40 locale strings for Hermes, and 100 for the UI. I use the locale generation support here and I hate how these are both lumped together.

If I shipped the UI as a separate addon, then it would probably make point #1 above more clear to users, as they'd literally see two Hermes related addons in their addon list. It would (presumably) also allow me to split up localization between the two since I assume I'd have to make a new project for the UI on curse.

Then come the modules for the UI. Because they can be fairly extensive, I'd really like to be able to prevent them from loading. Which means also packaging them up as addons instead of modules included with the UI addon (this way the user can uncheck them in the blizzard addon list)

I guess my questions are:
1. If I make everything a completely separate addon (core, UI, and UI modules) what kind of problems am I going to be causing myself or my users?
2. Assuming I make one "package" for Hermes and all it's separate addons, how do I make it so that the UI and it's related addons aren't listed on curse? I would only want to release Hermes as one single package.

I'm unclear how curse packaging handles this but I know I can find examples (DBM perhaps?)

You ideas work. I tested them out. I'm not thrilled with having to create an OnUpdate handler. But it IS a solution and I'm grateful for that (yes, it works with EnableMouse(false))

Hi,

This is in regard to my addon Hermes.

I have multiple requests to make the buttons I show completely click through.

I know that doing this causes it to be click through:

frame:EnableMouse(false)

My problem however is that I also need to be able to know when the mouse has hovered over the frame...

frame:SetScript("OnEnter", OnCellEnter)
frame:SetScript("OnLeave", OnCellLeave)

The issue is that if I disable mouse input, then it also prevents those two handlers from firing.



In the image above, when you hover over a button, that tooltip shows. I need to make it so that the buttons are click through (you can click things behind it like mobs or other players or whatever) but still show the tooltip.

Important Note: It's not actually a "Button" that I'm triggering the mouseover on, it's a regular frame that the button resides in.

Help!!

Quote from myrroddin

If you want to check any player for any type of self resurrection, you could have used LibResComm-1.0's CanRes callback.

Correct me if I'm wrong, but I believe each player needs an addon with the mentioned library in order to detect/send res information among players?

I recently ran into an issue, not the same as yours, but where testing was a challenge. I ended up mocking/emulating the wow game a bit. If you addon is well structured, it's sometimes possible to do this using some timers, custom datasets, etc. It all depends on your addon.

In my case, I needed to test how my code detects a Shaman dying that also has a soulstone on them (I was implementing support to detect Reincarnation). I ended up basically cheating and making my addon think that I had a Shaman in the group that had a SS on them. Because the entry point was the COMBAT_LOG_EVENT_UNFILTERED event, I just manually made fake entries there in the order I wanted to be able to test out my program's logic.

Good luck!

Thanks Adirelle, I made no assumption about which comes first in my code. Only that all subsequent events for the same spell and player are ignored after the first (I only handle the two sub-events mentioned)

The only assumption I did make (which is the risky one) is that there will never be a cast spell in between events triggered by the prior one. That's the part that's hard to test. Worst case, my code will just handle a bit more events than it should which won't cause any significant harm.

Thanks for the help. That was very much appreciated. I went ahead and coded it with results of your tests and did some local testing. I won't be sure how well this worked until I get some bug reports :P

I have two questions that are difficult to answer while testing COMBAT_LOG_EVENT_UNFILTERED.

1. If a spell fires both SPELL_AURA_APPLIED and SPELL_CAST_SUCCESS, will it always fire SPELL_AURA_APPLIED before SPELL_CAST_SUCCESS or can it sometimes fire in a different order?

2. If it's a spell that fires both of the above events, is it ever possible for another spell to fire either of those events before the first spell finished firing SPELL_AURA_APPLIED/SPELL_CAST_SUCCESS

Thanks for your help!

I'm seeking assistance from a couple people outside of my guild to help test some recent Hermes changes. I don't know if there's anyone familiar with (uses) Hermes, but if you are and do, I'd love some alpha testers.

I added support to monitor combat log for non Hermes users. It's a complex feature with a lot of interesting sync'ing going on. I'm currently concerned with accuracy and not performance.

I believe the biggest issue is that this new feature is going to be confusing to use and configure. That's where I'd like the most feedback. Thanks for any help you can give. I'm purposefully being vague and not giving much detail. Hoping for a blind test I guess :)

This version is a good one to use for now: http://wow.curseforge.com/addons/hermes/files/65-r67/

I am assuming the author wrote a tool or something to parse out spellid's from talents. I can't get that fancy since I don't have access to the player at the time of inspection to suck the name out.

I ended up just splitting my spell info into 4 tables to keep memory down; trees, tree, name, and rank.

Kinda like this...

["HUNTER"] = {
	["trees"] = {
		"Beast Mastery",
		"Marksmanship",
		"Survival",
	},
	["tree"] = {
		1,
		1,
		2,
		2,
		3,
		3,
	},
	["name"] = {
		"Improved Kill Command",
		"One with Nature",
		"Improved Steady Shot",
		"Careful Aim",
		"Silencing Shot",
		"Concussive Barrage",
	},
	["rank"] = {
		2,
		3,
		3,
		2,
		2,
		3,
	},
},

The names and ranks don't match up in the example but you get the idea.

Thanks for the tip and code sample, I'll check it out. At this point I think I'm relegated to optimizing my table structure (which sounds like the approach you took).

My requirement is to be able to present the user with a list of all up to date and localized talent information. Currently this includes talent tree names, all talent names, and max talent rank for each talent.

Right now I accomplish this via LibGroupTalents-1.0. As soon as I get talent information for a class I haven't seen before, I cache it via global SavedVariables.

This works perfectly well for me. However, because the talent information is stored in SavedVariables, it's a considerable bump in memory usage for my addon. For all alliance classes this is somewhere around 2000 lines in the saved variables file. I'm not sure how much memory it's using but there are a lot of strings.

Before I proceed with my current approach, I'm wondering if there are some other libs or some technique I'm missing that can allow me to meet my requirements without having to cache these values. Ideally, I could get talent names when needed and not have to cache them at all. But Blizzard doesn't seem to provide talent info API's unless you're inspecting someone.

Thanks for any help.

Line 1642 is looking for:

siteData[DS["Aerie Peak Digsite"]]

So this is probably returning nil

DS["Aerie Peak Digsite"]

Double check to make sure the library is loading corrctly and then double check that it knows the site you're asking for.

Quote from egingell

Also, I'm 60% sure the GUID is not always the same for the same player. I'm unsure when they change, possibly when the server reboots, or maybe even when you relog.

Can someone confirm this? It wasn't what I expected and am working on something that is using player guid.