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.
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:
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.
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.
Some questions come to mind.
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.
--- 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.
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.
--- 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
WorldMapPins[pin] = Pin
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?
--- 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.
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.
-- Need to show pins every time player reloads UI
-- These are internal functions
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.
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/
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.