04/15/14, 03:51 PM | #1 |
Literal World Pos
GetMapPlayerPosition
I get it, but it changes when I change the map. Obviously, the command literally says get the player position on the map. How about a normalized, or non-normalized position regardless of what map I have selected, for the actual current map I am in? I can not find anything along those lines, which is rather mind blowing. The next step is to be able to determine the distance to a POI, but for that I need an actual calculated position in the map o.0 Anyone have a suggestion? |
|
04/15/14, 04:04 PM | #2 |
You could try
index = GetCurrentMapIndex() - but there is a chance it will return a nil value for some reason And then it looks like this will get you more info name, mapType, mapContentType = GetMapInfo(luaindex index) These are listed in the WIKI for more information. |
|
04/15/14, 04:09 PM | #3 | |
And that returns the same information. If I change the map to Tamriel I get that index because the Map was last set on Tamriel (zoomed out). If I select Oblivion, etc... it is the same problem. The functions are tied to the in-game map's last state, not the literal world position, or even zone. You get conflicting results using the playerzone calls or the mapname calls. One can give you discrete sub-zone names, the other the "country". Like Daggerfall versus Daggerfall Marketplace. In either case, neither of those translate to any X,Z coordinates, nor can I find anything that can do so. I had toyed with adding pins to the compass, but a perfect example is Quests. They already have pins, and you can already get their normalized X,Z coords. But if you try to make a distance to quest function, depending on what map the player had open in the global map, the distances are completely wrong. Last edited by Joviex : 04/15/14 at 04:16 PM. |
||
04/15/14, 04:32 PM | #4 |
GetMapPlayerPosition has always returned the position of the character in the world.
GetMapName will return the current map's name. If of course the map has been changed it may report a different location to where the player is, which is probably why SetMapToPlayerPosition function was created for. So far my tests, during my weeks long work at getting pins on the map for my gatherer addon, have been pretty consistent with SetMapToPlayerPosition, GetMapName and GetMapPlayerPosition. Pins I place at those locations stay consistent at those locations regardless of current zoneing. Pins I place on the map using GetUnitZone mess up when zooming. GetUnitZone is the other zone retrieval function but as it seems you may have found out, this returns a slightly different location zone. So: SetMapToPlayerPosition() mapName = GetMapName() x,y, heading or z = GetMapPlayerPosition() |
|
04/15/14, 04:35 PM | #5 | |
It also seems weird to do this per .5 or even 1s tic to update positions based on distance to quest. Strangely odd workflow, but I will see how these pan out. Thanks for the help. |
||
04/15/14, 06:03 PM | #6 | |
GetMapPlayerPosition returns the position of the player in the world normalized to the last selected map in the map viewer panel. I can not find that function, but I assume you mean: SetMapToPlayerLocation Using this function does not seem to work (even with a SET_MAP_RESULT_MAP_CHANGED result code). If you zoom the map, and then use this function, it moves the player to some offset on the global map you left on the map screen. Again, the same problem all the GetMap* SetMap* functions seem to have is they are relative to the last map selected in the map view. The internal API has a ton of functionality in the Map* section of ZO's own codebase: Game0000.dat\esoui\ingame\map\worldmap.lua But like I said, all internal, all local defines, buried behind the panel. The other issue is sub-parts of quests. Quests have a POI, and the "tasks" also have a POI. But the Quest API only allows you to get the Quest POI via the questIndex, and not any of the sub-pieces. Which means making a distance to "true" POI of the current quest conditions/task impossible. The map POI API also has zero way to access the sub-POIs (exposed). Again, internally they have the poi_manager class that could readily (and is obviously used) do so. |
||
04/15/14, 08:44 PM | #7 | ||||||
Of course I don't have the map open while harvesting so I haven't seen the effect with the map open and I haven't deliberately changed to a different map to see if there is a difference. Thanks for point this out. I will have to test this before I make any major changes to my addon.
Are you sure there isn't one of those ZO_Object related objects floating around that are designed for use like that. I myself use the ZO_WorldMapPins object to instantiate my own map pins. It may be meaningless but hopefully a lot of the functionality is dealt with by ZO_WorldMapPins and all I have to do is send it the customised data and layout. And as of Sunday night it was working great. |
|||||||
04/16/14, 12:07 PM | #8 | |
ZO_WorldMapPins is an object definition, yes. You can instance that all day long. They have their own instance, internally buried behind a local "g_mapWorldMapPins". Since I cannot get to that, the only way would be to access the API functions that manipulate it. Since there are no direct manipulation points for the sub-quest tasks (maybe the objectives as you suggest, though on a first pass I see nothing to get objective POIs, only things for the AvA map, which also do not have location(s) on them.) They do have normalized.x and .y in the ZO_WorldMapPin (not Pins, Pins is the manager). So if you can use the manager to get the quest pins, those quest pins have the X,Y in them. The only outside chance is that instancing a ZO_WorldMapPins object would be a Singleton, but I dont see that defined in such a way as to only return the current i.e. global, MapPinManager. I will try to "instance" a ZO_WorldMapPins? Perhaps it is a singleton of some sort and I just cant see where that happens. If that is the case, problem most likely solved since you can manipulate the entire set of POIs at that point. |
||
04/16/14, 01:51 PM | #9 | |
local addonName = "XrysGatherer" local addonVersion = "0.0.9a" I cant find any reference to ZO_WorldMapPins so I assume this is a local only copy? Perhaps I have the wrong addon? |
||
04/16/14, 05:20 PM | #10 |
Sorry, my gatherer addon at present doesn't use the co-ordinates to make map pins yet as I only just got my test addon working Sunday night and haven't had a chance in hell to do anything after work this week. The idea is to incorporate the map pin stuff soon and hopefully soon compass pins.
You're quite welcome to play about with the attached test addon I wrote and got working with the help of Shinni reviewing and pointing out sections that were missing vital info. The data doesn't save across log in's though as my test was really with the map pins rather than the data as I have that in the gatherer addon. As to the ZO_WorldMapPins I stumbled across looking at zgoo and tried it out. Not sure if it makes a difference using that instead of ZO_Object yet but that is my next test. Without access to that ESO Lua source some of what we do is guess work and trial and error. |
|
04/16/14, 10:04 PM | #11 | |
Hey thanks! This is great. Will start digging in. Yeah I wish they would just open the .dat format instead of "someone" having to decompile it. |
||
ESOUI » Developer Discussions » General Authoring Discussion » Literal World Pos |
«
Previous Thread
|
Next Thread
»
|
Display Modes |
Linear Mode |
Switch to Hybrid Mode |
Switch to Threaded Mode |
|
|