Detail/Minimap alignment OR Minimap Indoor Transparency

[Doskious]

Not quite sure if this is a bug, or just an unavoidable aspect of the way things work...

I really like having the Minimap folded into and overlaying the Carbonite map, and I really like the Carbonite Map's minimap-like detail option. I've found, though, that leaving the minimap partially or totally transparent is somewhat problematic for indoor areas (where Carbonite's Detail map is not defined), as the minimap doesn't seem to display the actual indoor map area unless it's fully visible. However, if set to 100% visibility, while properly displaying indoor area maps, in the outdoors the minimap overlay is noticeably offset from the Carbonite Detail Map. This is most obvious while moving, but is observable in a number of locations while stationary. In all cases, from what I can tell, the Carbonite Detail Map seems to be offset slightly West and South, compared to the image displayed in the Minimap.

I'm sure that this is an issue of tertiary importance at best, but it would be really spiffy if the detail layer and the minimap could be properly aligned, OR, the minimap be allowed to take conditional transparency options (100% transparent outdoors, 100% visible indoors). (Or anything else that might address this, I dunno.)

Or is this {Detail/Minimap alignment OR Minimap Indoor Transparency} issue only affecting me, and if so what might I be able to do about that? ^_^;

[semlar]

Let me preface this by saying I haven't worked with carbonite, but I have done extensive work with the map system.

The indoor minimap transparency issue is unavoidable, it can only be fully hidden or visible.

The alignment issue sounds like a miscalculation in carbonite. Even indoors the minimap lines up no-problem with the map:


This is a bad example because it doesn't look like I lined it up correctly (if they were, the other textures would be even bigger), but it's the only indoor shot with terrain tiles I have right now. They *can* be lined up, but the problem is it still looks looks like crap because the terrain tiles are completely separate from the textures they use indoors.


Outdoors there's no reason it shouldn't line up:

[Doskious]

I have discovered something interesting in the genesis of the following screenshots...

When my pointer is not hovering over the Carbonite map, the minimap overlay is clearly offest.

When my pointer is over the minimap, however, the minimap overlay pops into alignment. Note, in the second image, the two red dots - these represent the locations that my character is identified as being at, the right one when the pointer is over the Carbonite map, the left when it's not. >.> Sense, it makes none...

[semlar]

That actually does make some sense if you understand how your coordinates on the map are determined.

Basically, if you're hovering over the zone it's as if you're looking at the normal zone map, but when you mouse off I believe it's zooming out to the continent level.

You'll notice your player coordinates actually change there at the top left from (86.1, 21.6) to (86.6, 21.9).

There are a few potential reasons for this that I can think of:

1. The zone map's position on the continent map is incorrect
2. The zone map's size is incorrect
3. The continent's offsets or size are incorrect

If it helps to understand, this is kind of a rough example of how the zone maps fit together on top of the continent map:


Your coordinates at the zone level are counted from the top left of the zone map and are accurate, but your coordinates at the continent level have to be scaled down and translated over to calculate what your zone coordinates should be since it can only request your position from one map at a time.

[Doskious]

And everything makes sense now. ^_^

Thanks very much for the cogent explanation. From what you've said and what I can tell this behavior is Working As Intended, and the offset that results from the difference between continental coordinates and zone coordinates is very likely an unavoidable product of the best possible implementation of the intended mapping functionality. Which is fine!

Assuming this to be the case, then, I'd humbly like to request the implementation of a variable-state transparency setting for the minimap, allowing it to be configured to use one transparency setting while the character is "outside" and another while the character is "inside". (Knowing something about programming, I would hope that this would not be too challenging to implement, as I would hope that such an implementation could be hooked on the same function that presently detects when the character in indoors and allows the minimap to dock in those cases. I would also hope that such an implementation would be separate from the setting to dock while indoors, though.)

[semlar]

It's definitely possible to translate between the two coordinates, but you need the exact sizes and offsets of the two maps. I'm guessing somewhere in carbonite they have the numbers a little off, and they really must be pretty close because it's not off by that much considering the scale.

[Rythal]

the scale is right, it's the XY that is off by a tiny bit... I knew it was but it was so close to correct I left it alone to move onto the next zone and get it finished faster for everyone.
---
nm just reread what you said .. you ment the entire maps scale, not the scale translations between the maps, so yeah everything you said is right... it's very close, but off by like .3 or so on the Y and between 1-2 on the X from the screenshots he posted

[Doskious]

Presumably, different zones could experience different offsets, depending on the relative accuracy of their X,Y placement numbers.

Not that this is huge, or objectionable, even; you've done splendidly, Rythal.

...
That said, the finicky perfectionist in me is very interested in going into the code to make the changes necessary to get the XY coordinates to match up nicely...

In NxMapData.lua, am I correct in thinking that the Pandaria worldmap zone definition numbers (starting at line 1658, ZoneID 6001, Dread Wastes?) follow the earlier indicated format of {Name, Scale, OriginX, OriginY, ...}?

Also, I think that my screenshots may simply be identifying the offsets between the Valley of the Four Winds map and the Kransarang Wilds map, as even in the second image, the southern edge of the minimap is visibly offset from the Carbonite map underneath - check the riverbanks. So it would seem that the ideal way to resolve the X,Y Coordinates would be to try to obtain a third-party minimap-based coordinate reporting display, and use that output to tweak each zone map into a proper fit. ^_^;

Unless there are objections, I plan to try to do this. Leveling my Hunter was ... frustrating at times. :P

[Chmee]

Originally Posted by Doskious Presumably, different zones could experience different offsets, depending on the relative accuracy of their X,Y placement numbers.

The problem, I suspect, is that the formulas used to calculate the offsets assume the geometry is Euclidean, and it's not. The surface of a planet is not a Euclidean space.

[Rythal]

The times when your standing still, and it moves between when your moused over the map, and not ... that's because the XY is off.

the 6001-6012 XY is the part that would be changed to adjust it.

The scale is correct for all of them, zone scale for every map in carbonite uses the formula "zone overlay width * 2 / 1000".

[Doskious]

I have not tampered with the Scale entry for any zone, but the map positioning does not seem to change in response to my alteration of the X and/or Y values in the Carbonite data file - are the values in the data file in the same unit measure as the coordinates in the game, or is there a multiplier at work to convert from measurable ingame coordinate offsets to Carbonite data X,Y values? Or are those X,Y values in Carbonite measures of yardage, rather than coordinates? :P Sorry to be bothersome, and I plan to tinker anyway, so no worries if you don't get back on this, actually, I'm sure I'll figure it out.

(Note, I did delete my cache folder in an attempt to make it reload the images and reconstruct the map, but I don't know if that was necessary, or if it should work at all - regardless of if it should, it did not seem to.)

[Rythal]

shouldn't be necessary to delete cache.. I never did.

The X & Y are relative to the full map so there's no multipliers at work

When i did them originally, I stood in the zone I was working on, then moved my mouse in and out of the map window so I could see the 2 red dots reflecting where carbonite thought I was, and where the game thought I was... then I adjusted the numbers starting with 500 at a time.. then 100.. 50.. 10.. 5.. until the 2 dots lined up... I never got down to the 1 or .1 levels so at some map scales the dots line fine, but when your zoomed close / detailed map .. they no longer line up perfectly.

[Doskious]

Corrected values obtained for Kun-lai, Vale of Eternal Blossoms. Tired Dosk is tired, more ##s later this week. Work coding > game coding :P The numbers needed more tweaking than I expected, but less than I feared: Nice work, Rythal, getting it that close to start with. (My numbers may not be perfect, but they still cause the minimap to line up nicely at high magnification.)

Name="Kun-Lai Summit",
12.516666015625,
---> -1014.5, 363.5,

Name="Vale of Eternal Blossoms",
5.06666796875,
---> -542.5,1097,

[semlar]

Sorry I don't know what format the carbonite values are in, but if you can figure out how to convert them these are exact measurements from my map in yards:

Pandaria x=8752.860352 y=6679.160156 width=15515.300293 height=10343.540039
Kun-Lai Summit x=4839.583008 y=5618.750000 width=6258.333008 height=4172.916992
The Jade Forest x=1452.083008 y=3652.083008 width=6983.333008 height=4654.166992
Vale of Eternal Blossoms x=2481.250000 y=1947.916992 width=2533.333984 height=1687.500977
The Veiled Stair x=812.500000 y=1689.583008 width=1793.750000 height=1195.833008
Valley of the Four Winds x=2679.166992 y=1095.833008 width=3925.000977 height=2616.666992
Krasarang Wilds x=2947.916992 y=-110.416023 width=4687.500977 height=3124.999992
Dread Wastes x=6139.583008 y=1416.666992 width=5352.083008 height=3568.750977
Townlong Steppes x=7079.166016 y=4558.333008 width=5743.749023 height=3829.166016

X and Y represent the top left corner of each map.

To get the percentage offset of kun-lai summit within pandaria you would do..
( 8752.860352 - 4839.583008 ) / 15515.300293 = 0.25222053522
or ( pandaria's x - zone x ) / pandaria's width = horizontal % offset of left edge of zone within continent.

It's possible you may not even be able to convert them to whatever carbonite uses, but here they are anyway.



Oh yeah, and the minimap textures themselves are just little squares that are placed next to each other in a grid like this..


I didn't think about it before but it's possible they're offset slightly from what they should be. From the description it's more likely just the maps though.

[Doskious]

Oh, most excellent, thanks! With the adjustments I've eyeballed for VoEB and K-LS, and Rythal's assurances (easily supported by community use without complaint) of the solidity of the Carbonite map Scale metrics, I'll easily be able to identify the relationship between your numbers and the ones in Carbonite. This will save me rather a lot of headache from switching in and out of the game...

(Whenever two sets of measurements are used to describe a common set of subjects, it's always possible to establish a relation between the two measurement sets, even if it must be expressed in a form restricted to the frame of reference of each individual measured subject. ... Put another way, the fact that both sets of numbers are describing the same concept means that the concept itself by definition serves to map one set of measurements to the other, in some regular and mathematically expressible fashion. ... In this case, the Zone Map for each set of Zone measurements is that mapping, and all I have to do is line up the numbers and observe the mathematical function that relates them. Which mayn't sound all that easy to you, but I assure you it's bread and butter to me. Mathematician, away! <whoosh>)

[semlar]

I took a look at MapGenAreas in NxMapData.lua and converted my values based on some points on other continents. I hope these are accurate since they don't really line up with your numbers.

[206] = {13.96666601563, -290.416601562, -730.416601562, "thejadeforest"}
[207] = {7.85000195313, -535.833398438, -219.166601563, "valleyofthefourwinds"}
[208] = {12.51666601563, -967.916601562, -1123.750000000, "kunlaisummit"}
[209] = {11.48749804688, -1415.833203125, -911.666601562, "townlongsteppes"}
[210] = {9.37500195313, -589.583398438, 22.083204651, "krasarangwilds"}
[211] = {10.70416601563, -1227.916601563, -283.333398438, "dreadwastes"}
[212] = {5.06666796875, -496.250000000, -389.583398438, "valeofeternalblossoms"}
[223] = {3.58750000000, -162.500000000, -337.916601562, "theveiledstair"}

Nevermind, I see why they don't line up. Your values are from the MapInfo table and I'm not really sure what they represent, but maybe my datas will help anyway.

Oh, I also generated a scale and offsets for the shrines, again based on the MapGenAreas table, but have no idea how carbonite might handle them.

[224] = {0.52000195312, -75.000097656, -179.933398437, "shrineofsevenstars"}
[225] = {0.518, -212.7, -361.766674805, "shrineoftwomoons"}

[Doskious]

And I'm back.

Numbers have been crunched, sigmas have been limited, standard deviations have been determined. (Or I shot from the hip twice because the numbers were small enough; given the results, nobody but me can say for certain. ^_^)

So ... the first number in the Carbonite Zone Map data record, that I've been calling "scale" based on commented notations in the code, appears to be precisely derived from the zone map width in yards as taken from semlar's first batch of measurements in yards. (Rythal probably already knew this.) The exact formula is: Scale = ZoneMapWidthInYards/500

Cheered by this corroboration of a fairly simple relation between the Carbonite data and the yardage supplied by semlar, I proceeded to examine the various ways that the two sets could be juxtaposed. After some experimentation, I noted what appeared to be the indication of a ratio-relation between the "approximate" values supplied by Rythal (roughly derived, but good enough for most purposes) for Carbonite's X-axis measure and semlar's indicated x-value for each zone. On a hunch, based on old commented out code in the LUA file, I compared the yardage x-value divided by 5 to the listed Carbonite values. The relation was immediately more apparent, but there appeared to be a uniform offset, which I've determined to be approximately -46.25. The formula, then, to derive Carbonite X-axis measures is: Xmeasure = [(ZoneXcoordInYards)/5] - 46.25

To correct the Y-axis measure, I quickly determined that it was not an identical function. In order to get the Y-axis measure out of the Yardage values, I first obtained a yardage value for what I think of as the Zone Y-Coordinate Offset. This is the distance in yards from the listed Y-Coordinate for the Continent map. This value, divided by 5 again, yielded a similarly clear relation with a uniform offset. The Y-coordinate offset value seems to be approximately 151.2. The formula, then, to derive the Carbonite Y-axis measure is: ([(PandariaYcoordInYards) - (ZoneYcoordInYards)]/5) + 151.2

Note, my analysis ignored the other non-Pandaria numbers and derivations entirely, and I can make no representation or assurance that the methods described above will work as stated for other data sets. (Glancing at the zone data for other expansions, it seems to me that over time a number of different methods have been used to develop this data.) Further, I can offer no explanation as to the significance (if any) of the indicated offset values. I can confirm that, when implemented, the accuracy of the minimap overlay to the underlying detail layer is exceptionally high.

In the interests of providing an easy-to-implement result, I've pasted the full block of Pandaria zone data with the enhanced X,Y coordinates, suitable for copy/pasting into NxMapData.lua, lines 1658 to 1721 (inclusive):

	[6001] = {
		Name="Dread Wastes",
		10.704166015625,
		-1274.1666, 1203.698633,
		Overlay = "dreadwastes",
		Fish = 525,
	},
	[6002] = {
		Name="Krasarang Wilds",
		9.375001953125,
		-635.8334, 1509.115236,
		Overlay = "krasarang",
		Fish = 525,
	},
	[6003] = {
		Name="Kun-Lai Summit",
		12.516666015625,
		-1014.1666, 363.2820312,
		Overlay = "kunlaisummit",
		Fish = 525,
	},
	[6004] = {
		Name="Shrine of Seven Stars",
		0.1,
		0,0,
		City = True,
	},
	[6005] = {
		Name="Shrine of Two Moons",
		0.1,
		0,0,		
		City = True,
	},
    [6006] = {
		Name="The Jade Forest",
		13.966666015625,
		-336.6666,756.6154296,
		Overlay = "thejadeforest",
		Fish = 525,
	},
	[6007] = {
		Name="The Veiled Stair",
		3.5875,
		-208.75,1149.11543,
		Overlay = "thehiddenpass",
		Fish = 525,
	},
	[6008] = {
		Name="Townlong Steppes",
		11.487498046875,
		-1462.0832,575.3654296,
		Overlay = "townlongwastes",
		Fish = 525,
	},
	[6009] = {
		Name="Vale of Eternal Blossoms",
		5.06666796875,
		-542.5,1097.448633,
		Overlay = "valeofeternalblossoms",
		Fish = 525,
	},
	[6010] = {
		Name="Valley of the Four Winds",
		7.850001953125,
		-582.0834,1267.86543,
		Overlay = "valleyofthefourwinds",
		Fish = 525,
	},