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.
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
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?
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
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.
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.
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.
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.
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.
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?
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
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!