Layer/Tier problem on PTS (apparently)

[Masteroshi430]

Hi all,
I went on the PTS to test my QuickMapNav addon (draws links with area names on the map) and it looks like it now draws the text under the map so we can't see it and click it anymore.
Sometimes it randomly works as usual though.
I use CT label

self.alikrGle = WINDOW_MANAGER:CreateControl(nil, self.control, CT_LABEL)

and this

self.alikrGle:SetHandler("OnMouseUp", function(self, button, upInside, ctrl, alt, shift, command)
    if upInside then
     ZO_WorldMap_SetMapByIndex(2)
    end
end)

I tried to play with SetDrawLayer but I don't know how many layers are there and which one to choose...
Any idea how I can fix this?

[Baertram]

One way to find the info would be: Wiki, search, layer
LMGTFY: https://wiki.esoui.com/w/index.php?t...rawlayer&go=Go

Solinur has added a every good exaplanation "Drawing Order" there recently (https://wiki.esoui.com/Controls#Rend...FLayer.2FLevel) and I have linked it everywhere where the DrawLayerr, DrawLevel and DrawTier are used.

btw: DrawTier is the important part, after that DrawLayer, then DrawLevel:

I've added that to the PTS API101035 thread too: https://www.esoui.com/forums/showthread.php?p=45812, post #4 includes the info from ZOs + Solinur's explanation at the Wiki.



A good way to find such info will be to check the API function files and the Wiki for the search terms. If you need to find something about DrawLayer search in the API txt doc. files and you'll find the possible constants to use, which then can be used to search further in the ZOs source code e.g.

h5. DrawLayer
* DL_BACKGROUND
* DL_CONTROLS
* DL_OVERLAY
* DL_TEXT


h5. DrawTier
* DT_HIGH
* DT_LOW
* DT_MEDIUM
* DT_PARENT

[Masteroshi430]

Thanks for the infos Beartram,
Whether or not I add DrawLayer, DrawTier and DrawLevel, (I added it on only one control to test)
all textlinks are displayed a first (or sometimes not... The random part is disturbing) but when I right click to get to a bigger map (e. g. Tamriel or The Aurbis or parent zone) all textlinks are then displayed under the map and it stays like that.

[Baertram]

Looks like the map update then uses a SetDrawTier and layer and level to bring the map on the top again.
So you also need to update your labels again at that point if they are not anchored to the same map control and would just stay the same they were before.

Maybe this sort of stuff would help, if not too performance intensive:

CALLBACK_MANAGER:RegisterCallbacks("OnWorldMapChanged", function() 
 --update your DrawTier of the controls again, maybe a bit delayed by 1 frame if needed via zo_callLater(function() 
    --Update here 
   end, 0 )
end)

But I'm unsure if this is the correct callback for your rightclicking, maybe it fires too often and you should simple react on the rightclick event and set your clicked control/all needed controls on top again (maybe delayed).

[Masteroshi430]

About the "OnWorldMapChanged" callback that's already how the addon works.
I've tried to set the draw tier, layer and level values after that (I use to set them on init) but same results.

By using GetDrawLayer() etc, I can confirm that the controls draw tier, layer and level are set but ignored once I have right clicked to go to a parent map, if I don't right click and navigate from map to map through the links provided by the addon it works as usual.

[Baertram]

Is the right click changing the DrawTier, DrawLayer or DrawLevel?
Compare the tier, layer and level of the worldmap to your "base" controls (the shown labels/clickable links or the custom control you have parented them as childs to, if it is not the WorldMap which is the parent).

If not:
The map might just become "the same" tier, layer and level (or a hgher level!) and thus the controls fall behind the map again by this.
It's what I understood is the reason that the controls sometimes vanish, or that the texture controls are still shown but a clickable button all of sudden is behind the texture and not clickable anymore then.

Search the worldmap code for SetDrawTier or SetDrawLayer or SetDrawLevel, maybe you'll find the exact values that are set to the map as the map changes/updates. And you just need to set the same to your controls then and increase the drawlevel by 1 to show it on top again.

What ZOSDanBatson wrote about it:

Essentially when you experience these issues, it just means you need to increase the tier layer or level of the thing. The level of the two competing controls was ambiguous, and its just a matter of which one happens to show up in the tree first when testing. You need to remove the ambiguity. Since the launch of the game, textures have a default layer of background, which is under controls, because when that decision was made, it was decided that of course you would never want to render a texture overtop of something like a button or a label, because it would cover it, making the label/button/etc pointless. But that can also be a pain in situations like this. Changing it so that textures an no longer defauted to background would be more explicit but at thise point would throw everything into complete and utter disarray. It was annoying for us too, we had to fix a lot of places where we had been lazily not resolving the ambiguity because it "didnt hurt anything" and it caused bugs we had to fix. But the new hit testing logic can't work the old way anymore, and only the old way resolved the ambiguity passively If you have a texture and a non texture both with default layers, and they overlap eachother, and they're both mouse enabled, you're gonna have a bad time, because textures by default are BACKGROUND, and you need to move the texture's layer up You need to decide which one you want on top of the other

[Masteroshi430]

Just posting data collected for "science"... While looking for a solution

ZO_WorldMapScroll
DrawTier 0
DrawLayer 1
DrawLevel 0

ZO_WorldMapContainer
DrawTier 1
DrawLayer 1
DrawLevel 0

map tiles
DrawTier 1
DrawLayer 0
DrawLevel 0

[Masteroshi430]

Ah I have it fixed :
I was setting DrawTier DrawLayer and DrawLevel on a child control while doing nothing to the parent control,
once I modified these values for the parent control it started working well.