Brief summary of issue / Description of requested feature:
Story time. I came back to Mudlet and discovered an oddity in a UI I'd written a couple months ago. The code creates a series of Geyser labels and miniConsoles with parent-child relationships that all roll up to a single Geyser Container. However when the system initializes and creates this UI, some elements would be displaced. The same elements every time, always by the same suspiciously even amounts (eg 50% of the width of the container and 10% of its height) that were used as constraints in nearby code. Weirdly, despite being visibly misaligned, Mudlet didn't seem to believe the elements were where my eyes said they were. Examining the Geyser constraints via the x & y properties on the items said that the elements were in their proper locations. Calling :flash() on the elements caused flashes that were displaced from the visible elements that the method was being called on. Even more weird was the fact that I could fix all of this with the following line of code:
parentContainer:move(parentContainer.x, parentContainer.y)
... literally just moving the topmost container to where it should already be, at which point suddenly all the misaligned elements would sort themselves out (but it wouldn't work immediately after creating the elements, I had to run it from the command line or aliases). An alternative way to fix it was by resizing the Mudlet window, at which point everything snapped into place.
All of this could still be the purview of some horrifying code I cooked up (and still might be), but after all this I was bothered by the nagging feeling that when I'd written this UI a couple months ago it didn't suffer from this bug, and so I reinstalled past versions of Mudlet and loaded a profile with the offending code to test. As it turns out this bug (which is 100% reproducible with my code) is only present AFTER version 3.10.1 (possibly also after 3.10.2, but I couldn't find a Windows installer for that version). The bug (or changed behavior) was introduced sometime between 3.10.1, which worked, and 3.11.0, which did not. I also verified that 3.13.0 and 3.12.0 also suffer from this issue.
I will try to narrow down the offending snippet and provide it here, but I'm out of time and will have to tackle it another day.
Brief summary of issue / Description of requested feature:
Story time. I came back to Mudlet and discovered an oddity in a UI I'd written a couple months ago. The code creates a series of Geyser labels and miniConsoles with parent-child relationships that all roll up to a single Geyser Container. However when the system initializes and creates this UI, some elements would be displaced. The same elements every time, always by the same suspiciously even amounts (eg 50% of the width of the container and 10% of its height) that were used as constraints in nearby code. Weirdly, despite being visibly misaligned, Mudlet didn't seem to believe the elements were where my eyes said they were. Examining the Geyser constraints via the x & y properties on the items said that the elements were in their proper locations. Calling :flash() on the elements caused flashes that were displaced from the visible elements that the method was being called on. Even more weird was the fact that I could fix all of this with the following line of code:
parentContainer:move(parentContainer.x, parentContainer.y)... literally just moving the topmost container to where it should already be, at which point suddenly all the misaligned elements would sort themselves out (but it wouldn't work immediately after creating the elements, I had to run it from the command line or aliases). An alternative way to fix it was by resizing the Mudlet window, at which point everything snapped into place.
All of this could still be the purview of some horrifying code I cooked up (and still might be), but after all this I was bothered by the nagging feeling that when I'd written this UI a couple months ago it didn't suffer from this bug, and so I reinstalled past versions of Mudlet and loaded a profile with the offending code to test. As it turns out this bug (which is 100% reproducible with my code) is only present AFTER version 3.10.1 (possibly also after 3.10.2, but I couldn't find a Windows installer for that version). The bug (or changed behavior) was introduced sometime between 3.10.1, which worked, and 3.11.0, which did not. I also verified that 3.13.0 and 3.12.0 also suffer from this issue.
I will try to narrow down the offending snippet and provide it here, but I'm out of time and will have to tackle it another day.