You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The layer order for map gimmicks in many cases are incorrectly set up, presumably because the API doesn't account for the depthOffset (or scale) parameter. For example, on the Olympus map 30601, the depth offsets for gimmicks 30611, 30612, 30613, and 30614 (all of which appear simultaneously after clearing the Losbelt/quest 3000628) have the depthOffset values of 200, 0, -100, and -400, respectively. Since the app has the z-index for all map gimmicks set to -1, this causes the gimmicks to be displayed in numerical order, irregardless of what the depth offset is. For the most part this has very little impact, however for maps like Olympus specifically this causes the gimmick 30613 to display over the gimmicks of 30611 and 30612, even though it should be all the way towards the back, causing the overlapping gimmicks of 30611 and 30613 to display in the wrong order and show the wrong assets first. (Additionally for whatever reason, the gimmick 30614 doesn't even display as a toggle, even though the image asset is rendered properly compared to some other cases) This is even more egregious throughout the second map for the war 30602, which also has three broken gimmicks (not that I would even begin to know how to fix the assets for those).
More egregiously, while this doesn't tend to happen with more recent maps (since the gimmick file size is often now the same size as the map size itself) on older maps the x, y, depthOffset, andscale values are overlooked, causing the gimmicks to by default show up as the full size of the map. This is easiest to see on the E Pluribus Unum map, which has many small gimmicks that show up misaligned and at the wrong scale. Gimmick 10551 has an x and y values of 905 and 291, a depthOffset of -5, and a scale of 2000. This combined with the gimmick's appearance indicates it would ideally be hanging out around North Dakota at double its initial size, like this:
But on the map viewer it shows up like this instead:
Which is definitely not how it's supposed to appear.
The text was updated successfully, but these errors were encountered:
The layer order for map gimmicks in many cases are incorrectly set up, presumably because the API doesn't account for the
depthOffset
(orscale
) parameter. For example, on the Olympus map30601
, the depth offsets for gimmicks30611
,30612
,30613
, and30614
(all of which appear simultaneously after clearing the Losbelt/quest 3000628) have thedepthOffset
values of200
,0
,-100
, and-400
, respectively. Since the app has the z-index for all map gimmicks set to-1
, this causes the gimmicks to be displayed in numerical order, irregardless of what the depth offset is. For the most part this has very little impact, however for maps like Olympus specifically this causes the gimmick30613
to display over the gimmicks of30611
and30612
, even though it should be all the way towards the back, causing the overlapping gimmicks of30611
and30613
to display in the wrong order and show the wrong assets first. (Additionally for whatever reason, the gimmick30614
doesn't even display as a toggle, even though the image asset is rendered properly compared to some other cases) This is even more egregious throughout the second map for the war30602
, which also has three broken gimmicks (not that I would even begin to know how to fix the assets for those).More egregiously, while this doesn't tend to happen with more recent maps (since the gimmick file size is often now the same size as the map size itself) on older maps the
x
,y
,depthOffset
, andscale
values are overlooked, causing the gimmicks to by default show up as the full size of the map. This is easiest to see on the E Pluribus Unum map, which has many small gimmicks that show up misaligned and at the wrong scale. Gimmick10551
has anx
andy
values of905
and291
, adepthOffset
of-5
, and ascale
of2000
. This combined with the gimmick's appearance indicates it would ideally be hanging out around North Dakota at double its initial size, like this:But on the map viewer it shows up like this instead:
Which is definitely not how it's supposed to appear.
The text was updated successfully, but these errors were encountered: