Oh well... after some testing around with your test level set (nice main screen, by the way ![;-)]( "Wink")
), I know what's going in here.
And yes, the observed behaviour in this case is indeed unexpected, and to be honest, it looks like buggy behaviour in most use cases.![:(]( "Sad")
The thing is that the ".draw_order" attribute is in fact used to sort both animations ("anim_1" .. "anim_x") and animation parts ("anim_x.part_1" .. "anim_x.part_y") before processing them. This is used to draw animations just in the determined order, drawing animations with a higher number over those with a lower number.
So far, so good. BUT: This also means that animation parts of the same animation, but with different ".draw_order", are also processed in that order. Yes, this is as close to being a program bug as can be, as this is simply not expected in most cases. The only sane reason to do things that way is when you have an animation with several parts that are all displayed at the same time (using ".anim_mode: all" for the main animation), but that should use a certain draw order. In this case, the "part number" does not matter, as all parts are displayed in this case. But the sad truth is that animation parts are sorted by "draw order" before being sorted by their part number. (But in this case, using the part number to determine the draw order would just work as fine.)
In your example level set, just add a line "global.anim_1.part_8.TITLE_2.draw_order: 4", and everything works as expected. (That is, all parts had a "draw order", but not "part_8", so it got sorted to an unexpected position!)
I think I really should change this!![:?]( "Confused")
), I know what's going in here.And yes, the observed behaviour in this case is indeed unexpected, and to be honest, it looks like buggy behaviour in most use cases.
The thing is that the ".draw_order" attribute is in fact used to sort both animations ("anim_1" .. "anim_x") and animation parts ("anim_x.part_1" .. "anim_x.part_y") before processing them. This is used to draw animations just in the determined order, drawing animations with a higher number over those with a lower number.
So far, so good. BUT: This also means that animation parts of the same animation, but with different ".draw_order", are also processed in that order. Yes, this is as close to being a program bug as can be, as this is simply not expected in most cases. The only sane reason to do things that way is when you have an animation with several parts that are all displayed at the same time (using ".anim_mode: all" for the main animation), but that should use a certain draw order. In this case, the "part number" does not matter, as all parts are displayed in this case. But the sad truth is that animation parts are sorted by "draw order" before being sorted by their part number. (But in this case, using the part number to determine the draw order would just work as fine.)
In your example level set, just add a line "global.anim_1.part_8.TITLE_2.draw_order: 4", and everything works as expected. (That is, all parts had a "draw order", but not "part_8", so it got sorted to an unexpected position!)
I think I really should change this!
Statistics: Posted by Holger — Sat Dec 09, 2023 6:04 pm