I am implementing a pair of background tileset masks in my level, one using the <define> feature and the other using the custom width and height detection. When loading the level after having both tilesets in place, I get a crash with the "Index was out of range" exception in the log.txt, attached for further context. By loading only individual tilesets I was able to determine that ID 1 has this issue. While I ordinarily expect this to mean I have defined an out of bounds co-ordinate on the tilesheet, I have not found an excessive value or typo doublechecking the co-ordinate definitions. Is there a different error or typo that could result in the same exception?
#"Index was out of range" exception loading a level after implementing tilesets
sly chasm
weary plume
I am implementing a pair of background tileset masks in my level, one using the ...
doesn't the <set mask="XXX-XXX-XXX" tiles="0,5"/> need to be <set mask="XXX-X1X-XXX" tiles="0,5"/>
sly chasm
ill try change this definition but hypothetically it should be fine as an X, as X as a definition includes all tiles including 0
it should function identically to x but be considered less specific so be lowest priority
weary plume
right
is missing the centre and padding definitions also alright? I notice the id="2" one has those
sly chasm
yes, i purposefully disclude center and padding definitions as they override any tiles that are completely surrounded, which i would otherwise want to use the B definition to mask textures against
again a specificity issue unfortunately. i used to have to make the tileset ignore the ids the definition was testing to avoid this issue, but my testing for the foreground tileset has made it apparent that lack of center and padding definitions no longer result in a crash
ill define a center and padding mask just in case to test
the center and padding definitions fixed the issue; im not sure why i came to my conclusion then. thanks for the help
ill have to reconsider how i mask tilesets into eachother unfortunately, but thats ok
weary plume
it could also be a difference between foreground and background tiles for some weird reason but unsure 🤷♀️
fwiw @drowsy briar might be decent to ask about some of this stuff since they've already delved into how everest actually handles tilesets in the first place
sly chasm
if defining priority of masks that use the define feature is impossible, it would be really helpful to remove the necessity of center and padding masks and have a distinct texture or exception for a tile that does not meet a valid mask. this is coming from someone who does not understand why lack of these definitions results in this specific exception though so im not sure it's that simple
yeah, weirdly my foreground tileset functions without a padding or center definition
weary plume
defining the priority of masks is definitely possible, currently everest just indiscriminately runs it's sorting function - by just making that a possible to disable you instanteously have self defined mask order 
sly chasm
i know that is possible, i understand the priority is literally just a list of 1,0,x and a custom definition, custom definitions just being lowest right now
the trouble is that comparing specificity of a custom definition to a 1 or 0 mask results in the possibility of ideally being in distinct orders. displacing the custom definition priority would work in some cases and not others
this is because a custom definition can contain id 0, which is specifically not handled by mask 1, and that mask 0 can be expanded by the ignores tag while custom definitions still detect ignored tiles