Started by
Dranguinidae Opalux
on
Topic category: Troubleshooting, bugs, and solutions
The overlay element generates in a non-scalable way. Somewhere in generation code it is using hard numbers, it needs to be dynamic with resolution, otherwise you end up with overlay elements in the middle of the screen when playing fullscreen or with varying GUI scales.
I have fixed this before by editing my overlay element's code manually to reference the screen resolution, however every time I do this I inevitably step away from modding for a while and end up forgetting exactly what I changed and I'd really just rather not have to do that anymore.
Thank you for such an amazing modding tool, and thank you in advance for making overlays actually work/mean something lol
We do not have a solution, so if you did in fact find something that prevents the position of components from changing with scale, feel free to share.
I'll try and figure it out again. It should ultimately just be a matter of replacing static numbers with window height/width variables. I don't recall if the actual UI scale was something I factored in in the past so its possible whatever I found out will only fix it partially but whatever I find I'll add here in any case.
Minecraft.getInstance().gui.blit(event.getPoseStack(), posX + -207, posY + 95, 0, 0, 16, 16, 16, 16);
Ok so finding the actual solution is a challenge, this is the part I always forget because it has to do with specific numbers that I can't see, however this is the code inside a overlay element icon, determining its position.
PosX and Y are simply shorthand for w/2 and h/2 which are event.getWindow().getGuiScaledWidth(); and the one for height.
This sets the targeting aspect to ALWAYS be at the center of the screen, and the values added to PosX and Y are there to modify them from this 0,0 center-screen origin. This is great, but here is the flaw: where are we getting this adjustment value?
The adjustment values we see here (+ (-207) and + (95), in this case) are numbers, not variables, not percentages, they are integer numbers signifying literal pixel values, which means that they assume an inherent base window scale. I would guess they are being based on the actual mcreator gui's editor window positioning.
These numbers will remain accurate as long as minecraft's window remains similar in size/scale to that of mcreator's gui edit screen, however they will break anytime that it changes due to the fact that they expect a certain canvas size.
This is also why GUI scale messes it up. GUI scale is a multiplier based on literal screen pixel size. At scale 1, each pixel of the overlay GUI is literally a pixel on the screen. Because the values we currently use are also literal pixels, this causes everything at that scale to be very close to the middle, because 100-200 pixels is really not a lot on an HD monitor.
What I remember of my solution in the past involves turning these position adjustment values into percentages of actual screen space by guessing at the value MCreator is using behind the scenes in the GUI overlay element screen and then creating a value such as ((-207) / (My guess of how big the screen was)) * (Actual screen size) = (Position on the actual screen).
I suppose the reason why I have so much trouble remembering is that my guess for the MCreator element editor screen size is what I forget. I have used math to work it out before, at least fairly closely, but its a struggle to remember exactly how I arrived there. The above section is the important part from which a solution can be easily found though, especially if you are working from within the MCreator code scope, instead of the Mcreator element code scope.
Essentially, use scalable i.e. percentage values instead of literal ones, and it will function much more scalably.
Let me know if that made no sense lol
That looks hard enough, I think the best solution for low intelligence characters is to modify numbers til it fits my 1080p fullscreen.