LibMapPins-1.0 is a fresh, new alternative take on placing pins or icons on the world and mini maps.
Astrolabe-1.0 is good, but isn't actively maintained, only getting the occasional passive update. Further, the latest updates are on the developer stub, where the casual user has no idea how to find or use.
Therefore, I present to the community this library, which has the following differences:
Uses LibStub and CallbackHandler-1.0 rather than DongleStub
Embedded/mixed-in functions
Open source and community updated
Open SVN where anyone can commit updates, improvements, fixes, etc
Slimmer and more lightweight, not trying to do everything
Supports Metric and Imperial distances
Place icons in battlegrounds
The API and callbacks are a work in progress, and subject to change before final release. That said, anyone can work on LibMapPins-1.0; I don't have to be the only author, nor do I want to be the only author.
For example, the .docmeta is something I am not familiar with, and if someone beats me to getting it working, go for it! Likewise adding APIs or callbacks. Everyone is welcome!
Still lots and lots to do. I haven't even thought about mini map code yet; there is still many APIs dealing with the world map that need adding or adjusting. Then there are the utility APIs like getting distance and direction to pin.
Anyway, I see a few people have downloaded this, and I'm curious if I'm on the right track. Feedback, or way too early?
How about DeletePinsByMapID and DeleteAllPins functions to get the rest of the things in the TomTom pin/arrow right-click menu?
What is the difference between a minimap pin and a world map pin? Wouldn't the minimap just be a window through which you'd see world map pins as you arrived near their location? I just see the CreateMinimapPin function in the mixins table, so I'm not sure what the signature was going to be like.
As I just learned, just today, that libraries can't have saved variables, are you going to require consumers of the library to dedicate a section of their variables to dehydrated pin information (persisted, maybe, with some kind of Save/Load functions that they would need to call on ADDON_LOADED and PLAYER_LOGOUT or...)(...maybe the library would take a handle on the config section and update it constantly rather than loading once and saving once...)?
Both of those are going in; I just haven't written the code to handle them.
I'm not sure, as I haven't started the minimap pin code. I would like to keep minimap pins and world map pins as separate APIs, but we'll see as I dig in.
If you look at the code, LMP registers PLAYER_ENTERING_WORLD and re-places every pin. There is no need for AddOns to handle that sort of thing, as it should be done library-side.
Libraries can have saved variables, although it is not recommended. DataStore is arguably a set of library files, and it has saved variables. Probably not the best example, however.
Nice to see some downloads, and people checking out the progress. Sorry for the lack of forward movement during the long weekend. I had company over.
I assume, since I have not done any in-game testing, there are bugs galore. I don't plan on testing until some more APIs are coded.
Speaking of author requirements, I do have hooks to CallbackHandler-1.0, but thus far haven't seen a need to fire any callbacks. Does anyone have suggestions, or does LibMapPins even need them? I know Astrolabe has callbacks, but I'm using it as an inspiration, not a code base.
[LIST=1]
Libraries can have saved variables, although it is not recommended. DataStore is arguably a set of library files, and it has saved variables. Probably not the best example, however.
DataStore is not an embeddable library; what you're writing is, so it cannot have saved variables, and I can't really think of any reason why you'd need it to. Most addons that would use this kind of thing are going to be using a static database -- eg. the locations of mailboxes or herb nodes -- which would be pointless to duplicate in your saved variables. Plus, if you were saving all the data yourself, you'd need to introduce a lot of additional complexity to keep each addon's data separate, and allow arbitrary extra data to be stored with each location (for example, an herb node addon may want to store info on how many times you've seen an active node at each location), etc. Better just to let each addon handle its own business, and you just provide the tools.
Phanx, you mistake me. LMP does not have saved variables, nor will it ever have them for exactly the reason you mentioned.
Any AddOns that use the lib will have to save their data themselves. All the lib does is control placement, visibility, and other tools. There is an internal table for pin data, but that is stuff the lib needs, and it is not saved to disc.
My (sadly out-of-date) addon ZoneDefense used Astrolabe to place icons and animations on the world map but I had to build a sort of wrapper (which I called Astronomer) to facilitate actually displaying them in an intelligent manner. That is, I wanted a fire-and-forget function to place an icon on the world map at a given world location which stayed accurate even if the player changed maps. It had to notice when the selected map changed, automatically hiding the icon when its world location was no longer shown to the player, or move the icon to other positions on the map frame when the map was zoomed in or out so the desired world location was shown at a different relative position (coordinate translation). (Moving the icon like this was optional; you could also set it up so it was just hidden if the current map was not the specific one the icon was assigned to. I also put in some more advanced features, like changing the scale and transparency based on whether the current map was the one the icon was assigned to, so for instance, the icon could get smaller as you zoom out from the zone map to the continent map to the Azeroth map.)
Will this library handle anything like this? If so, I would request that some sort of callback be used when an icon is adjusted (allowing addon authors to use that to do the advanced things I mentioned above, for instance, should the library not do this natively -- or other "fancy" things if it does handle them).
If this is too much for this library, will it at least have the feature Astrolabe did which allowed me to translate a given coordinate on one map to a coordinate on another map? That's pretty much make or break when it comes to my purposes with addons like ZoneDefense.
I hadn't thought about setting the scale based on map zoom, or hiding the pins when the viewed map changed. However, I can do the first, I would think the second ought to be automatic. If not, that is something I can look into.
There definitely will be be travel, distance, and time APIs. One thing I'd like to do for these is return either Metric or Imperial distances, defaulting to Metric. Most of the WoW subscriber base uses that system.
Since you have some working knowledge regarding map pins or icons, feel free to contribute. The repository is open, and LibMapPins is open source, and most importantly, I had hoped that the author community would help drive this project.
Can you clarify the difference between metric and imperial?
I know that in locale enUS the spell Penance has 40 yd range.
However, in deDE it has 40 Meter Reichweite (translation: 40 meter range).
That being said, it seems to me that 1 gameyard = 1 gamemeter, hence the distinction is not needed. Or are you talking about kilometers and (imperial) miles?
I don't think this is something the library needs, just return gameyard/meters, if anyone wants to display them in miles they can do the translation themselves.
Also, you might want to have a look at a library I created for my personal use (and did not bother to upload yet as it is still in early stage).
It does not display anything, it just a way for me to transfer data between my data source addons and my map addon. It is completely orthogonal to Astrolabe, and LibMapPins at its current stage.
I am not sure where exactly you want to go with LibMapPins, so this is just to give you an idea what I did. http://www.wowace.com/paste/8623/
1 gameyard = 1 gamemeter, hence the distinction is not needed.
This, and if you're returning display text (as opposed to a number only) then rather than asking the addon to specify what they'd like to call this unit of measurement, just use the proper unit name for the user's locale, eg "yards" in English, "metros" in Spanish, etc.
First, I have not abandoned LibMapPins; patch 5.4 and my job are keeping me really busy.
I did not know that the game equates yards with metres as an exact exchange. How very odd, but whatever. I can just leave it as generic game distance, as you pointed out.
I downloaded LibMapMetaData-1.0 and will check it out.
In the meantime, the repo is still open, should anyone besides me want to commit changes or updates. This being an experimental alpha at this point, if things do get changed to the point of breaking APIs or callbacks, it shouldn't hurt.
Some questions come to mind.
1.
Why is the Minimap/Worldmap pin handling and the coordinate translation one library?
While pin placement needs coordinate translation to be usefull, coordinate translation does not need to know about pin management.
Personally I would split this into two libraries, at least into two files.
2.
Concerning
--- Place an icon on the world map frame.
-- @paramsig icon, x, y, mapID[,mapFloor]
-- @param icon Path to icon file (string)
-- @param x Horizontal XX.xx coordinate for the icon (number)
-- @param y Vertical YY.yy coordinate for the icon (number)
-- @param mapID The mapID (number)
-- @param mapFloor The map floor, default 0 (number) optional
-- @usage -- Put an icon in Cleft of Shadow, Orgrimmar
-- local pin = MyAddOn:CreatePinByMapID(icon, 22.84, 13.56, 321, 1)
-- @return pin Shown on the world map, table of input values
local function CreatePinByMapID(icon, x, y, mapID, mapFloor)
2.1: I would suggest adding texture coordinates. When trying to reuse existing blizzard POI textures I noticed that many of them have a couple of icons per texture. Without texture coordinates they are unusable.
2.2: why do you specify x and y in percent (i.e, range [0,100]) rather than range [0,1] as Astrolabe does? I think this might cause confusion. In anyway this should be documented more clearly, e.g.:
-- @param x Horizontal XX.xx coordinate for the icon (number in range [0,100] where 0 is the leftmost part of the map and 100 is the rightmost part)
2.3: For y coordinates it should be documented whether 0 is top or bottom.
(For x this is also good, but less necessary, as X generally starts with 0 on the left side)
2.4: You should probably add a reference to areaId for the mapID parameter.
3.
return error(major.. "You cannot attach a pin to this map", 2)
I don't think error ever returns, the return keyword will never be executed.
4.
--- Set a world pin's height. Do not call :SetHeight() directly
-- because UI reloads will forget the setting.
-- @param pin The world pin to adjust
-- @param height Number in pixels
local function SetWorldPinHeight(pin, height)
local Pin = WorldMapPins[pin]
if Pin then
Pin.height = height
Pin:SetHeight(height)
WorldMapPins[pin] = Pin
end
end
I don't think I get what you are trying to tell me here.
Of course after a reload everything is gone, unless you had savedvariables. But since this is a library, it does not have saved variables.
So what purpose does saving the height have?
5.
--- Hide all world map pins and labels.
-- @usage MyAddOn:HideAllWorldPins()
local function HideAllWorldPins()
What purpose could this function have? Is it intended to only hide the pins from one addon? (Doesn't look that way)
If not, why should I care about other addon's pins? In fact, it might be annoying if some other addon hides my pins from time to time.
I think this definitely needs to be limited to addon scope.
6.
local function FindWorldIcon(icon)
This is a search by texture. Assuming some addon like Gatherer/GatherMate would use your library, this will, for example, return one copper node per zone.
7.
-- Need to show pins every time player reloads UI
-- These are internal functions
function lib:PLAYER_ENTERING_WORLD()
Unless I am seriously overlooking something, this is pointless, as WorldMapPins will be an empty table after every reload.
This is totally ok though, your library does not need to store pins, thats the addons responsibility.
In fact it would be awkward if I decide to disable e.g. Gatherer, do a reload, and the ores/herbs wer still there.
I hope you are not overwhelmed with the feedback.
In general I think we need to invest a bit more time defining the purpose and API before implementing stuff.
Some questions come to mind.
1.
Why is the Minimap/Worldmap pin handling and the coordinate translation one library?
While pin placement needs coordinate translation to be usefull, coordinate translation does not need to know about pin management.
Personally I would split this into two libraries, at least into two files.
I was actually thinking about this. Zygor gave me the idea of a library that handles traveling. IE: fastest, use every trick; lazy, use flight masters; scenic, mount up and go your own way. That sort of thing. If done, then it would definitely be a separate library.
--- Place an icon on the world map frame.
-- @paramsig icon, x, y, mapID[,mapFloor]
-- @param icon Path to icon file (string)
-- @param x Horizontal XX.xx coordinate for the icon (number)
-- @param y Vertical YY.yy coordinate for the icon (number)
-- @param mapID The mapID (number)
-- @param mapFloor The map floor, default 0 (number) optional
-- @usage -- Put an icon in Cleft of Shadow, Orgrimmar
-- local pin = MyAddOn:CreatePinByMapID(icon, 22.84, 13.56, 321, 1)
-- @return pin Shown on the world map, table of input values
local function CreatePinByMapID(icon, x, y, mapID, mapFloor)
2.1: I would suggest adding texture coordinates. When trying to reuse existing blizzard POI textures I noticed that many of them have a couple of icons per texture. Without texture coordinates they are unusable.
2.2: why do you specify x and y in percent (i.e, range [0,100]) rather than range [0,1] as Astrolabe does? I think this might cause confusion. In anyway this should be documented more clearly, e.g.:
-- @param x Horizontal XX.xx coordinate for the icon (number in range [0,100] where 0 is the leftmost part of the map and 100 is the rightmost part)
2.3: For y coordinates it should be documented whether 0 is top or bottom.
(For x this is also good, but less necessary, as X generally starts with 0 on the left side)
2.4: You should probably add a reference to areaId for the mapID parameter.
Texture coordinates sounds very useful, and I get why you would want them.
The X and Y in percent rather than 0-1 is because users are more familiar with that method. When looking at Mapster, Atlas, or other map, or TomTom, both cursor and player coordinates are given in percentages. It is just my way of keeping things simple.
--- Set a world pin's height. Do not call :SetHeight() directly
-- because UI reloads will forget the setting.
-- @param pin The world pin to adjust
-- @param height Number in pixels
local function SetWorldPinHeight(pin, height)
local Pin = WorldMapPins[pin]
if Pin then
Pin.height = height
Pin:SetHeight(height)
WorldMapPins[pin] = Pin
end
end
I don't think I get what you are trying to tell me here.
Of course after a reload everything is gone, unless you had savedvariables. But since this is a library, it does not have saved variables.
So what purpose does saving the height have?
I haven't tested to make certain, but that, and similar APIs, I had hoped, would still get applied when PLAYER_ENTERING_WORLD fires when the lib parses WorldMapPins and reattaches the pins to the world map. Of course, if WorldMapPins is wiped out, then all those APIs become rather useless, and can be deleted from the library.
--- Hide all world map pins and labels.
-- @usage MyAddOn:HideAllWorldPins()
local function HideAllWorldPins()
What purpose could this function have? Is it intended to only hide the pins from one addon? (Doesn't look that way)
If not, why should I care about other addon's pins? In fact, it might be annoying if some other addon hides my pins from time to time.
I think this definitely needs to be limited to addon scope.
It was intended so one AddOn can hide all the pins, regardless of which AddOns created them. Let's say you have HandyNotes and GatherMate2, and one or both used LibMapPins. HandyNotes could have an option toggle that hides all pins, leaving a clean world map. But perhaps having it on a per-AddOn basis might be better. Or have both a global hide and a per-AddOn hide (and show).
This is a search by texture. Assuming some addon like Gatherer/GatherMate would use your library, this will, for example, return one copper node per zone.
This API I am not happy with. The idea here was that in MyAddOn, you would indeed be able to find one pin among the possible hundreds or thousands. Something like "find me the repair guy in Shrine of Seven Stars". My goal was being able to hook into the travel system discussed above so you could set a waypoint directly to a single pin. But as I said, I am not happy with how it is turning out.
-- Need to show pins every time player reloads UI
-- These are internal functions
function lib:PLAYER_ENTERING_WORLD()
Unless I am seriously overlooking something, this is pointless, as WorldMapPins will be an empty table after every reload.
This is totally ok though, your library does not need to store pins, thats the addons responsibility.
In fact it would be awkward if I decide to disable e.g. Gatherer, do a reload, and the ores/herbs wer still there.
I wasn't sure if WorldMapPins would become an empty table, so this code is there "just in case", mainly because I haven't tested the necessity.
I hope you are not overwhelmed with the feedback.
In general I think we need to invest a bit more time defining the purpose and API before implementing stuff.
I am all ears. There is zero point in writing this if it doesn't work the way people would want it to work.
I was actually thinking about this. Zygor gave me the idea of a library that handles traveling. IE: fastest, use every trick; lazy, use flight masters; scenic, mount up and go your own way. That sort of thing. If done, then it would definitely be a separate library.
The point is, smaller libraries are easier to maintain. If blizz adds a new continent (which is probably only a question of time, Astrolabe needs to be changed. The coordinate translation part of LMP would also need to be changed. However the minimap/worldmap pin placement can probably stay the same, that does not depend on the actual zones or zone data.
So splitting this might improve maintanabilty.
The X and Y in percent rather than 0-1 is because users are more familiar with that method. When looking at Mapster, Atlas, or other map, or TomTom, both cursor and player coordinates are given in percentages. It is just my way of keeping things simple.
Maybe. But you should not confuse addon users with library users. The average TomTom user will probably never use your library directly. When defining specification for an API it is more important to care about authors, cause they will use the API. Astrolabe uses the range [0,1] for example.
However, this is not something I feel strongly about. In the end its just a factor 100, as long as it is documented I can work with that.
Probably we mean the same thing: http://wowprogramming.com/docs/api/GetCurrentMapAreaID and http://wowpedia.org/MapID are the same. What I meant is we should add a reference, for example these two links, to the documentation so everyone understands what a "mapID" is.
In particular we should point out that is neithera zoneIndex, a mapTextureName nor a localized map name.
I haven't tested to make certain, but that, and similar APIs, I had hoped, would still get applied when PLAYER_ENTERING_WORLD fires when the lib parses WorldMapPins and reattaches the pins to the world map. Of course, if WorldMapPins is wiped out, then all those APIs become rather useless, and can be deleted from the library.
I am pretty sure that after a reload everything is gone from memory.
This API I am not happy with. The idea here was that in MyAddOn, you would indeed be able to find one pin among the possible hundreds or thousands. Something like "find me the repair guy in Shrine of Seven Stars". My goal was being able to hook into the travel system discussed above so you could set a waypoint directly to a single pin. But as I said, I am not happy with how it is turning out.
I see. Well. You want to do a lookup. That makes sense. But I am not sure if thats the right way to do this. I would at least suggest to use another field.
(LibMapMetaData has for example a class field, which is intended for classifying locations).
Also I would think that for most cases an iterate method would be sufficient.
We might also add a wrapper for a map reduce.
However I still think you want to solve too many distinct problems with one library.
I am all ears. There is zero point in writing this if it doesn't work the way people would want it to work.
Its difficult to estimate what people want.
I am personally looking for two things:
1.
A way to transform zone coordinates to continent coordinates (where a continent is the largest area which can be travelled using free movement (including (flying) mounts, swimming, walking, excluding taxi, portals)). For example every instance (dungeon, raid, scenario, battleground, arena, ...) is a continent, as is Pandaria, Kalimdor, Outland, Northrend, The Eastern Kingdoms.
Also the other way round: Given a location, find every map this is in.
For example if you are in stormwing this would return at least a location in Stormwind, Elwynn forest and Eastern Kingdoms.
2.
An easy way to add information from LibMapMetaData to the worldmap and minimap.
These two things do not have to be the same library.
To understand why I need that, let me illustrate what addons I created:
There is GraveLogMap, which is a map addon. It can display icons, lines and areas from LibMapMetaData.
There is MapMetaData_OtherPlayers. It provides icons for the position of your group and guild members (the second using LibGuildPositions).
There is MapMetaData_Quests which provides the locations of quests.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorAstrolabe-1.0 is good, but isn't actively maintained, only getting the occasional passive update. Further, the latest updates are on the developer stub, where the casual user has no idea how to find or use.
Therefore, I present to the community this library, which has the following differences:
- Uses LibStub and CallbackHandler-1.0 rather than DongleStub
- Embedded/mixed-in functions
- Open source and community updated
- Open SVN where anyone can commit updates, improvements, fixes, etc
- Slimmer and more lightweight, not trying to do everything
- Supports Metric and Imperial distances
- Place icons in battlegrounds
The API and callbacks are a work in progress, and subject to change before final release. That said, anyone can work on LibMapPins-1.0; I don't have to be the only author, nor do I want to be the only author.For example, the .docmeta is something I am not familiar with, and if someone beats me to getting it working, go for it! Likewise adding APIs or callbacks. Everyone is welcome!
Cross-post on WowInterface's forums.
-
View User Profile
-
View Posts
-
Send Message
Forum Moderator-
View User Profile
-
View Posts
-
Send Message
Forum Moderator-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorAnyway, I see a few people have downloaded this, and I'm curious if I'm on the right track. Feedback, or way too early?
-
View User Profile
-
View Posts
-
Send Message
Forum Moderator- Both of those are going in; I just haven't written the code to handle them.
- I'm not sure, as I haven't started the minimap pin code. I would like to keep minimap pins and world map pins as separate APIs, but we'll see as I dig in.
- If you look at the code, LMP registers PLAYER_ENTERING_WORLD and re-places every pin. There is no need for AddOns to handle that sort of thing, as it should be done library-side.
- Libraries can have saved variables, although it is not recommended. DataStore is arguably a set of library files, and it has saved variables. Probably not the best example, however.
Nice to see some downloads, and people checking out the progress. Sorry for the lack of forward movement during the long weekend. I had company over.I assume, since I have not done any in-game testing, there are bugs galore. I don't plan on testing until some more APIs are coded.
Speaking of author requirements, I do have hooks to CallbackHandler-1.0, but thus far haven't seen a need to fire any callbacks. Does anyone have suggestions, or does LibMapPins even need them? I know Astrolabe has callbacks, but I'm using it as an inspiration, not a code base.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorDataStore is not an embeddable library; what you're writing is, so it cannot have saved variables, and I can't really think of any reason why you'd need it to. Most addons that would use this kind of thing are going to be using a static database -- eg. the locations of mailboxes or herb nodes -- which would be pointless to duplicate in your saved variables. Plus, if you were saving all the data yourself, you'd need to introduce a lot of additional complexity to keep each addon's data separate, and allow arbitrary extra data to be stored with each location (for example, an herb node addon may want to store info on how many times you've seen an active node at each location), etc. Better just to let each addon handle its own business, and you just provide the tools.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorAny AddOns that use the lib will have to save their data themselves. All the lib does is control placement, visibility, and other tools. There is an internal table for pin data, but that is stuff the lib needs, and it is not saved to disc.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWill this library handle anything like this? If so, I would request that some sort of callback be used when an icon is adjusted (allowing addon authors to use that to do the advanced things I mentioned above, for instance, should the library not do this natively -- or other "fancy" things if it does handle them).
If this is too much for this library, will it at least have the feature Astrolabe did which allowed me to translate a given coordinate on one map to a coordinate on another map? That's pretty much make or break when it comes to my purposes with addons like ZoneDefense.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorThere definitely will be be travel, distance, and time APIs. One thing I'd like to do for these is return either Metric or Imperial distances, defaulting to Metric. Most of the WoW subscriber base uses that system.
Since you have some working knowledge regarding map pins or icons, feel free to contribute. The repository is open, and LibMapPins is open source, and most importantly, I had hoped that the author community would help drive this project.
I know that in locale enUS the spell Penance has 40 yd range.
However, in deDE it has 40 Meter Reichweite (translation: 40 meter range).
That being said, it seems to me that 1 gameyard = 1 gamemeter, hence the distinction is not needed. Or are you talking about kilometers and (imperial) miles?
I don't think this is something the library needs, just return gameyard/meters, if anyone wants to display them in miles they can do the translation themselves.
It does not display anything, it just a way for me to transfer data between my data source addons and my map addon. It is completely orthogonal to Astrolabe, and LibMapPins at its current stage.
I am not sure where exactly you want to go with LibMapPins, so this is just to give you an idea what I did.
http://www.wowace.com/paste/8623/
This, and if you're returning display text (as opposed to a number only) then rather than asking the addon to specify what they'd like to call this unit of measurement, just use the proper unit name for the user's locale, eg "yards" in English, "metros" in Spanish, etc.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorI did not know that the game equates yards with metres as an exact exchange. How very odd, but whatever. I can just leave it as generic game distance, as you pointed out.
I downloaded LibMapMetaData-1.0 and will check it out.
In the meantime, the repo is still open, should anyone besides me want to commit changes or updates. This being an experimental alpha at this point, if things do get changed to the point of breaking APIs or callbacks, it shouldn't hurt.
Everything? The minimap stuff? The coordinate translation stuff?
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorThe minimap needs support, and I haven't written that yet, and yes to time/distance/direction to pins and between pins.
1.
Why is the Minimap/Worldmap pin handling and the coordinate translation one library?
While pin placement needs coordinate translation to be usefull, coordinate translation does not need to know about pin management.
Personally I would split this into two libraries, at least into two files.
2.
Concerning
2.1: I would suggest adding texture coordinates. When trying to reuse existing blizzard POI textures I noticed that many of them have a couple of icons per texture. Without texture coordinates they are unusable.
2.2: why do you specify x and y in percent (i.e, range [0,100]) rather than range [0,1] as Astrolabe does? I think this might cause confusion. In anyway this should be documented more clearly, e.g.:
2.3: For y coordinates it should be documented whether 0 is top or bottom.
(For x this is also good, but less necessary, as X generally starts with 0 on the left side)
2.4: You should probably add a reference to areaId for the mapID parameter.
3.
I don't think error ever returns, the return keyword will never be executed.
4.
I don't think I get what you are trying to tell me here.
Of course after a reload everything is gone, unless you had savedvariables. But since this is a library, it does not have saved variables.
So what purpose does saving the height have?
5.
What purpose could this function have? Is it intended to only hide the pins from one addon? (Doesn't look that way)
If not, why should I care about other addon's pins? In fact, it might be annoying if some other addon hides my pins from time to time.
I think this definitely needs to be limited to addon scope.
6.
This is a search by texture. Assuming some addon like Gatherer/GatherMate would use your library, this will, for example, return one copper node per zone.
7.
Unless I am seriously overlooking something, this is pointless, as WorldMapPins will be an empty table after every reload.
This is totally ok though, your library does not need to store pins, thats the addons responsibility.
In fact it would be awkward if I decide to disable e.g. Gatherer, do a reload, and the ores/herbs wer still there.
I hope you are not overwhelmed with the feedback.
In general I think we need to invest a bit more time defining the purpose and API before implementing stuff.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorTexture coordinates sounds very useful, and I get why you would want them.
The X and Y in percent rather than 0-1 is because users are more familiar with that method. When looking at Mapster, Atlas, or other map, or TomTom, both cursor and player coordinates are given in percentages. It is just my way of keeping things simple.
I agree about documenting. Could use improvement.
areaID? What am I not knowing?
Those should probably just be
I haven't tested to make certain, but that, and similar APIs, I had hoped, would still get applied when PLAYER_ENTERING_WORLD fires when the lib parses WorldMapPins and reattaches the pins to the world map. Of course, if WorldMapPins is wiped out, then all those APIs become rather useless, and can be deleted from the library.
It was intended so one AddOn can hide all the pins, regardless of which AddOns created them. Let's say you have HandyNotes and GatherMate2, and one or both used LibMapPins. HandyNotes could have an option toggle that hides all pins, leaving a clean world map. But perhaps having it on a per-AddOn basis might be better. Or have both a global hide and a per-AddOn hide (and show).
This API I am not happy with. The idea here was that in MyAddOn, you would indeed be able to find one pin among the possible hundreds or thousands. Something like "find me the repair guy in Shrine of Seven Stars". My goal was being able to hook into the travel system discussed above so you could set a waypoint directly to a single pin. But as I said, I am not happy with how it is turning out.
I wasn't sure if WorldMapPins would become an empty table, so this code is there "just in case", mainly because I haven't tested the necessity.
I am all ears. There is zero point in writing this if it doesn't work the way people would want it to work.
The point is, smaller libraries are easier to maintain. If blizz adds a new continent (which is probably only a question of time, Astrolabe needs to be changed. The coordinate translation part of LMP would also need to be changed. However the minimap/worldmap pin placement can probably stay the same, that does not depend on the actual zones or zone data.
So splitting this might improve maintanabilty.
Maybe. But you should not confuse addon users with library users. The average TomTom user will probably never use your library directly. When defining specification for an API it is more important to care about authors, cause they will use the API. Astrolabe uses the range [0,1] for example.
However, this is not something I feel strongly about. In the end its just a factor 100, as long as it is documented I can work with that.
Probably we mean the same thing:
http://wowprogramming.com/docs/api/GetCurrentMapAreaID and http://wowpedia.org/MapID are the same. What I meant is we should add a reference, for example these two links, to the documentation so everyone understands what a "mapID" is.
In particular we should point out that is neithera zoneIndex, a mapTextureName nor a localized map name.
I am pretty sure that after a reload everything is gone from memory.
I see. Well. You want to do a lookup. That makes sense. But I am not sure if thats the right way to do this. I would at least suggest to use another field.
(LibMapMetaData has for example a class field, which is intended for classifying locations).
Also I would think that for most cases an iterate method would be sufficient.
We might also add a wrapper for a map reduce.
However I still think you want to solve too many distinct problems with one library.
Its difficult to estimate what people want.
I am personally looking for two things:
1.
A way to transform zone coordinates to continent coordinates (where a continent is the largest area which can be travelled using free movement (including (flying) mounts, swimming, walking, excluding taxi, portals)). For example every instance (dungeon, raid, scenario, battleground, arena, ...) is a continent, as is Pandaria, Kalimdor, Outland, Northrend, The Eastern Kingdoms.
Also the other way round: Given a location, find every map this is in.
For example if you are in stormwing this would return at least a location in Stormwind, Elwynn forest and Eastern Kingdoms.
2.
An easy way to add information from LibMapMetaData to the worldmap and minimap.
These two things do not have to be the same library.
To understand why I need that, let me illustrate what addons I created:
There is GraveLogMap, which is a map addon. It can display icons, lines and areas from LibMapMetaData.
There is MapMetaData_OtherPlayers. It provides icons for the position of your group and guild members (the second using LibGuildPositions).
There is MapMetaData_Quests which provides the locations of quests.