I had this issue back in Godot 3.5 and hoped that it’d be gone, but Panels and some other Control Nodes still resize magically when executing another scene. This is such weird behaviour, that I have no idea where it might come from. Has anyone ever seen such a thing happen before? Here is a video of the bug in acton: https://piped.kavin.rocks/watch?v=79DYDT5qngk

  • shotgun_crab@lemmy.worldEnglish
    4·
    1 year ago

    Looks like a bug. Try creating a minimal reproduction project with just these 2 scenes and creating an issue on GitHub. Don’t forget to mention that it happens in both Godot 3 and 4. Best of luck.

  • tabular@lemmy.worldEnglish
    2·
    1 year ago

    "Control

    Base class for all UI-related nodes. Control features a bounding rectangle that defines its extents, an anchor position relative to its parent control or the current viewport, and offsets relative to the anchor. The offsets update automatically when the node, any of its parents, or the screen size change."

    Could it have something to do with the screen changing size, or changing of it parent node (or grandparent node)?

    • Smorty [she/her]OP
      2·
      1 year ago

      I am not changing any of the window size parameters. They are all set in the project settings and I leave them alone. When I scale the window in runtime, everything scales exactly as I want it, so that’s not a problem. Nowhere in my code do I set or change the size of any control node.

      My main problem is the thing I pointed out in the video. In the “level_base” scene, the blue texture at the bottom keeps scaling up when running a totally different scene. The only thing I could see making these changes in the base_level scene, would be the base_level.gd script which is a tool script. But even that only puts textures in places and does not touch the scale or size of anything. Do you think this is an actual bug I should report, or is this just me doing something silly and that makes this problem occur?

      • tabular@lemmy.worldEnglish
        4·
        1 year ago

        If you recreate the issue in a new project with only the needed nodes and it’s still happening then it’s more likely to be a bug than something you’ve done. After watching the video I’d suspect there is a bug because I don’t think it should change like that. If you can better understand when the bug happens then you may be able to find a bug report already exists.

      • Feyter@programming.devM
        1·
        1 year ago

        This is just a guess but it could be that (re)setting the texture of an control node May also reset it’s size since I think it tries to stick as close as possible on the original texture resolution.

        Is the size a different when you set it to a different texture? Maybe the same image but with lower res?

        • Smorty [she/her]OP
          2·
          1 year ago

          Clever thought, but no, the code doesn’t change any of those textures, it just changes the character portrait and the background image, which both don’t mess up anything. They are still where they are supposed to be. Thank you either way!

  • I Cast Fist@programming.devEnglish
    2·
    1 year ago

    From a glance, I’d tell you to take a look at the Hbox Bottom -> Bottom first, the one that has both a Control and the BallsCounter. These box container nodes will auto expand to fit all content.

    An alternative would be scaling that Bottom node, instead of resizing it.

  • Cid@lemmy.sdf.org
    1·
    1 year ago

    My guess is it’s likely not a bug but an unexpected (by you) interaction of the tool script with whatever layout you’re doing.

    If you can post example code demonstrating the problem someone will probably be able to pinpoint what’s happening.