View Single Post
04-24-14, 10:42 PM   #8
Digital_Utopia
A Flamescale Wyrmkin
 
Digital_Utopia's Avatar
AddOn Author - Click to view addons
Join Date: Jul 2012
Posts: 110
Originally Posted by semlar View Post
You shouldn't need to SetMapToCurrentZone every time another addon tries to change the map.

Even if you need to request information from the current map OnUpdate, you would only need to set the map once, gather your information, then allow the other addon to zoom out and do whatever it's doing without breaking yours because you already did what you needed to.

Without knowing what the other addon is or what it's doing, or what your addon needs to do it's difficult to suggest what the best course of action would be.
Ideally, yes. That's been my goal all along. Unfortunately, the ZCNA event fires on any change to the map whatsoever - actual zone changes, which was the (presumed) intent, player map navigation, and API functions that set the map (SetMapToCurrentZone, SetMapByID, and ZoomOut). So the problem here, essentially, is determining which of these results are accurate, and which are done by artificial means.

So while getting the proper zone at any one point is easy enough, continuing to get the proper zone is not. And I'm really not talking about the results of player interaction with the world map - that's a given, and an understandable concession.

When it comes to other addons, and actions taken while the WorldMap is closed, that's a bit different. Now, there's absolutely no big deal with changing the map, while it's closed, to get information from a different zone, so long as you set it back when you're done. The entire process would take less than a single frame, and other addons shouldn't be affected at all.

But in this case, the addon is actually strong-arming its map change. Meaning, as long as the player is in a micro dungeon, it will make sure the map stays zoomed out to the main area. And every time it does that, it will cause the ZCNA event to fire.

So if you step into Shrine of Two Moons, you'll get an initial ZCNA fire, with the areaID showing as 903. But then you'll immediately get another ZCNA fire, with the areaID showing as 811 (Vale). Now, storing the first one is easy enough, but what happens when the player steps out? The areaID will still be 811, and there's no way (I know of) to tell what caused the ZCNA event to fire.

My main goal is to simply create a addon-scoped, psuedo event & function, so the other parts of my addon can easily get map information on demand, or on change. Without having to register and filter Blizzard events for each section. It worked great by itself, and with every other addon I've got installed - except this one. /shrug

As far as the other addon goes - I'd prefer to keep the name to myself. My goal for this thread isn't to call out the author or the addon, but to express some mild irritation of having to compensate for it, and what it seems I had to do. I understand why they did this - so microdungeons could be treated like other inside areas, and not in their own zone - so outside map related items could still be shown while the player is inside. I get it, I really do - but if they're going to do that, it would be nice if they at least provided an addon-scoped table or function to provide the information they're essentially blocking by doing this. If not just go with Astrolabe, which can do this without such...methods.
__________________
  Reply With Quote