So, I’ve got a weird problem that I’m experiencing where TextLabels on SurfaceGuis are scaling when they really shouldn’t.
I have a part that is size (2,2,2) and a TextLabel attached to a SurfaceGui on it that is specifically set to not scale as the part changes size. The TextLabel’s size is {0,10},{0,10} and I have the TextScaled option set to false. Testing it out by changing the size of the part, all is well, as the text remains the same size regardless of how big I make the part. However, the problem is that this stops being true after the part’s size goes below (0.05,0.05,0.05). Once this happens, the text also begins to shrink, despite the fact that I’ve specifically written it to not do so. Now, this is a massive problem for me, as one of the main mechanics in my game enables the ScreenGui the frame it tweens the cube from size (2,2,2) to size (0.001,0.001,0.001) [Roblox doesn’t support true 0 for sizing], and as a result, the text is massive for the duration of the tween.
Some solutions I’ve thought of are to create a new part at the same coordinates and tween that one instead, or have a second part everywhere I need it just for showing the TextLabel when I need to call it, but I really hate both of these solutions as they are both heavily inefficient for the scale I’m using them at, and ultimately just ignore the main problem. I really have no idea how I’d go about fixing this as I’ve been thinking about this for a few weeks now and still haven’t thought of a desirable fix. Maybe this is actually a bug in the engine that nobody has encountered until now? Starting to feel that way with how I haven’t been able to find any solutions anywhere. Anyway, hopefully someone can figure out what’s been stumping me for a while now. Thanks!
Nobody seems to have tried to reply to me so I’ll provide a demonstration of the problem I’m experiencing here.
In the following video, I do nothing but tween the size of the cube, and yet despite how the text’s size remains constant for any cube size above 0.05, the text starts to shrink once you dip below a cube size of 0.05. The TextLabel is specifically set to not scale with the size of the cube.
I have no idea what is causing this and I’m thinking its a bug in the Roblox engine itself. As I said before, any ideas on how to fix this would be greatly appreciated!
I think there may be a limit to how many times bigger the SurfaceGui can be than the surface. You can test this by tryna make the SurfaceGui really big, and see if it starts dropping in size even quicker.
Hi! I’ve actually tried this, and while I don’t think you can edit the size of the SurfaceGui itself, this problem consistently occurs below a cube size of 0.05, regardless of the SurfaceGui’s PixelPerStud value (FixedSize forces scaling entirely so there’s no point in considering it), the size of the TextLabel, or the TextSize itself. I’ve also tested this with MeshParts as well, however it still produces the same results at specifically the size 0.05 mark.
I suppose a solution I could use would be to only go to a cube size of 0.05 and tween the transparency to 1 as well, however this is undesirable as in my game, this operation will be happening potentially hundreds to thousands of times at once, so any form of optimization is not only desired, but necessary.
Well, in that case, I’m not sure if there’s anything better you can do other that create an invisible part for every part that is supposed to be shrinking, which would hold the surface gui.
Tho this will most likely hit your performance. Depending on how your game works tho, if you go down this route, you might want to consider pooling the invisible parts & making the parts local, if you haven’t yet.
Ah, all parts are already local, although I’ve not heard of pooling them. Mind giving me a link to some docs? Also, I might go ahead and make a bug report out of this in the off chance that it would get fixed.
As a backup, I’ve thought to make the cube shrink to .005 instead and then make the transparency 1 right as the tween ends. I’d need to figure out how to cancel the tween if necessary but it might be the best solution I can make if this doesn’t turn out to be a bug.
Pooling in itself is a very simple idea. Instead of destroying the parts that are seemingly no longer needed, you just parent them to nil (or somewhere outside of workspace) and keep them around in a table somewhere, and when a new part is needed, you take one from the pool (if one is present) instead of creating a new part. This is usually better, since creating a whole new part has loads of overheads. And if you, for example, use visually the same parts in the pool, then you don’t even need to resize & color them again, which makes creating them even slightly faster.
1 Like
Ooh, that’s so simple yet I’ve never thought of that before! This could really help me out, and might also serve to fix some of the other minor visual errors I’ve been having. I’ll see about implementing a system that has a spare pool to call when needed. Thanks!
2 Likes