GetPlayerMapPosition issue

[Grimsin]

why does GetPlayerMapPosition return 0's if you open the world map and view an area other then the one your in?

why is GetPlayerMapPosition hooked to the world map frame at all?

[Foxlit]

Originally Posted by Grimsin why does GetPlayerMapPosition return 0's if you open the world map and view an area other then the one your in?

Because you're not on the map you're currently viewing.

why is GetPlayerMapPosition hooked to the world map frame at all?

It's not so much tied to the world map frame as it is tied to the map API, which also happens to be what the world map frame is tied to.

Why? Because that API was designed to support the default world map frame in displaying positions of you and your raid members, as opposed to any other purpose.

[Grimsin]

yea but one would think that GetPlayerMapPosition would return your position even while viewing another zone.

Is there no work around for the issue? im pretty sure that i saw a cords addon that did not sit on zeros while the world map frame was open. Of course i also noticed that on some maps it does not show 0's but rather returns different cords lol.

[Foxlit]

Originally Posted by Grimsin yea but one would think that GetPlayerMapPosition would return your position even while viewing another zone.

It returns your position on the currently viewed map. If it were to return what you suggest, everyone would appear to be in every zone on the world map.

Is there no work around for the issue? im pretty sure that i saw a cords addon that did not sit on zeros while the world map frame was open. Of course i also noticed that on some maps it does not show 0's but rather returns different cords lol.

Change the world map zone before you query coordinates, and restore it when you're done. If you do that in the event processing cycle of a single frame, the player will be unaware that you ever changed the world map zone.

[Seerah]

Question is... Why do you need player coordinates while they're looking at the map?

[Grimsin]

well because your current cords are displayed below the minimap in my UI. everytime you open the world map to say look at other zones and the quests you have there the cords frame stops showing your cords and shows 00.00 00.00. and strangely for some zones it shows a dif cord all together not 0's.

and i had originally had it where it always showed your current location but a problem was noticed in the fact that when you would try to view certain zones on the world map it would jump back to your current zone. now i took that out but it reads the 00's when viewing the world map. and for a more specific example of what i was talking about with some zones not showing 0's if i go to thunderbluff and i open up the xroads it will change the cords, it does not read 0's but it does not read the proper cords of you current location. Now when i open thousand needles it gives me 0's instead of bogus cords. Also note that when i stand in TB and look at the Xroads it keeps registering movement on the cords frame but its not the right cords lol.

edit - an after thought to better explain serah.... i like to be able to see my current cords while running along looking at the big map to. i keep my world map on minimode all the time dont you?

[Grimsin]

this is what the code looks like right now

local GUICordsFrame = CreateFrame('Button', "GUICordsFrame", UIParent)
GUICordsFrame:SetPoint("BOTTOM", UIParent, "BOTTOM", 0, 0)
GUICordsFrame:SetHeight(11)
GUICordsFrame:SetWidth(80)
GUICordsFrame:RegisterForClicks('LeftButtonUp', 'RightButtonUp')

local GUICordsFrameBG = GUICordsFrame:CreateTexture(nil, "BACKGROUND")
GUICordsFrameBG:SetTexture(0, 0, 0, .8)
GUICordsFrameBG:SetAllPoints(GUICordsFrame)

local GUICordsFrameText = GUICordsFrame:CreateFontString(nil, "OVERLAY", "GameFontNormalSmall")
GUICordsFrameText:SetPoint("CENTER", GUICordsFrame, "CENTER", 0, 1)
GUICordsFrameText:SetTextColor(1, 1, 1, 1)
GUICordsFrameText:SetFont("Fonts\\FRIZQT__.TTF", 10, "NORMAL")
GUICordsFrameText:SetJustifyH("CENTER")

local UpdateInterval = 0.3
local TimeSinceLastUpdate = 0 
local x,y

GUICordsFrame:SetScript("OnUpdate", function(self, elapsed)
	
	TimeSinceLastUpdate = TimeSinceLastUpdate + elapsed
	
	while (TimeSinceLastUpdate > UpdateInterval) do
	
	x,y = GetPlayerMapPosition("player")

	GUICordsFrameText:SetFormattedText("%.2f  %.2f", 100*x, 100*y)
	
	TimeSinceLastUpdate = TimeSinceLastUpdate - UpdateInterval
	end
	end)

[Foxlit]

local UpdateInterval, TimeSinceLastUpdate, x, y = 0.3, 0;
GUICordsFrame:SetScript("OnUpdate", function(self, elapsed)
	TimeSinceLastUpdate = TimeSinceLastUpdate + elapsed
	while (TimeSinceLastUpdate > UpdateInterval) do
		x,y = GetPlayerMapPosition("player")
		GUICordsFrameText:SetFormattedText("%.2f  %.2f", 100*x, 100*y)
		TimeSinceLastUpdate = TimeSinceLastUpdate - UpdateInterval
	end
end)

Just on a general note, the while loop is entirely pointless and should be replaced by an if. Aside from that, we'll have to save which map is currently displayed, ask for the map of the zone the player is in, query coordinates, and then restore the old map:

local UpdateInterval, TimeSinceLastUpdate, x, y = 0.3, 0;
GUICordsFrame:SetScript("OnUpdate", function(self, elapsed)
    TimeSinceLastUpdate = TimeSinceLastUpdate + elapsed
    if TimeSinceLastUpdate < UpdateInterval then return end
    -- Copy current map state
    local continent, zone, dungeon = GetCurrentMapContinent(), GetCurrentMapZone(), GetCurrentMapDungeonLevel();
    -- Change map to display the zone the player is in.
    SetMapToCurrentZone();
    -- Grab our data
    TimeSinceLastUpdate, x, y = 0, GetPlayerMapPosition("player");
    -- Restore map state based on copied data
    SetMapZoom(continent, zone);
    if dungeon then SetDungeonMapLevel(dungeon); end
    -- Use retrieved coordinates however you like.
    GUICordsFrameText:SetFormattedText("%.2f  %.2f", 100*x, 100*y)
end)

[Grimsin]

the while was to prevent the delay on it returning your location to make the current readout more accurate. Your method worked perfectly btw thank you very much!

[Shadowed]

Originally Posted by Grimsin why does GetPlayerMapPosition return 0's if you open the world map and view an area other then the one your in? why is GetPlayerMapPosition hooked to the world map frame at all?

Nearly every (99.99%) of the Blizzard APi's are for Blizzard and used in their UI. The position APi doesn't return coords because then they don't need it to since they only need it when showing the players location on the currently visible map. It wouldn't be very helpful to say the player is at 50/30 when viewing the Icecrown map when they are actually in Wintergrasp.

If the API was designed with addon developers in mind, it would give you x, y and zone. Since it's not, you get the above. A lot of the API's you limitations are due to that.

[corveroth]

Originally Posted by Shadowed If the API was designed with addon developers in mind, it would give you x, y and zone.

More like, x, y, z, and zone. Z-coords would give a whole new dimension in which you could optimize path-finding for Gatherer, QuestHelper, etc.

[Grimsin]

its really surprising that we do not have a z read out already. One would think it would have been necessary for flying at some point.

[Seerah]

Blizzard has it. But we don't. It has been requested repeatedly. They have reasons for not giving access.

[Grimsin]

im sure they do, as i figured it would be necessary for the flying mounts. What would their reasons be though do you know? Other then the better pathing i cant think of any malicious or over advantageous uses for the z coord output.

[Shadowed]

Originally Posted by Grimsin im sure they do, as i figured it would be necessary for the flying mounts. What would their reasons be though do you know? Other then the better pathing i cant think of any malicious or over advantageous uses for the z coord output.

Botting I would imagine, since that's why they usually don't want to expose data in the API's.

[corveroth]

Of course, we aren't technically prevented from gathering Z-data. However, it would require a massive amount of manual data gathering, interpolation, and Pythagoras, and as I learned last time I proposed this, it would only work in flyable areas because your xy-speed is constant while you're on the ground (i.e. there's no xy-speed loss from moving vertically, so you can't work out your altitude delta).

Or you could write a program to generate a table from the map files, although I'm not sure how Blizz would feel about that one. Either way, it's a ton of data to be stored.