search

godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
91.01k stars 21.17k forks source link

TextureProgressBar has always visible Gizmo when setting Fill Mode to 4, 5 or 8 #96859

Open KaenguruuDev opened 2 months ago

KaenguruuDev commented 2 months ago

Tested versions

Reproducible in: v4.3.stable.mono.official [77dcf97d8] (Latest)

System information

Godot v4.3.stable.mono - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Ti (NVIDIA; 32.0.15.6094) - AMD Ryzen 7 5800X 8-Core Processor (16 Threads)

Issue description

When selecting either "Clockwise", "Counter Clockwise" or "Clockwise and Counter Clockwise" as the FillMode, a cross is displayed in the center of the rect. This does not disappear, even when selecting another node or left clicking somewhere else in the scene view. Additionally, the crosshair is also visible when the TextureProgressBar node is used in an EditorPlugin. image image

Steps to reproduce

  1. Add a TextureProgressBar to your scene.
  2. Set it's Fill Mode to either "Clockwise", "Counter Clockwise" or "Clockwise and Counter Clockwise"
  3. A crosshair will show up in the center. If you now click somewhere else or select another node, it will not disappear.

Minimal reproduction project (MRP)

Mrp.zip

AThousandShips commented 2 months ago

This is done by design, but should probably be something you can configure, and not do when used in plugins etc: https://github.com/godotengine/godot/blob/4788f54d9767425bf5435b1cc940885d357795c5/scene/gui/texture_progress_bar.cpp#L538-L553

KaenguruuDev commented 1 month ago

A few questions:

  1. What is the purpose of that reference cross?
  2. Should Plugins be handled like if the node was in an actual "game scene"?
  3. Would it make sense if it was more an option to enable the reference cross independent from what FillMode is selected?
AThousandShips commented 1 month ago

1) It's to help you align things I'd say 2) That would be hard, though we could use is_part_of_edited_scene, will see if I can test that out some 3) I'd say that'd be the most useful solution

arkology commented 1 month ago

I think this maybe could be reworked to use Marker2D as internal node.

arkology commented 1 month ago

I made dirty but working prototype and this is how it may look:

4.4dev2 Prototype
1024x1024 Godot_v4 4-dev2_win64_Lksr6p93Qr godot windows editor dev x86_64_PLyyQBxnf3
48x48 Godot_v4 4-dev2_win64_duNiAhNCOF godot windows editor dev x86_64_6ZL3ie810C

And you should be able to access crosshair from code as internal Marker2D child node.

I change crosshair visibility inside set_fill_mode(), so you should be able to change Marker2D visibility after setting fill mode.

arkology commented 1 month ago

Another possible solution - add editor-only metadata to set crosshair visibility.

KaenguruuDev commented 1 month ago

Sorry for not answering for so long I got distracted again. Does your prototype allow for disabling the crosshair even in the normal editor (without having to attatch a tool script or something to the node)?

arkology commented 1 month ago

Sorry for not answering for so long I got distracted again. Does your prototype allow for disabling the crosshair even in the normal editor (without having to attatch a tool script or something to the node)?

No, I did not add/change any methods. You still should change visibility of internal Marker2D node using script. Having additional parameters or methods for this looks like overkill. Also there is controversial moment - should it be always added (for consistency) or only for editor? Moreover, Marker2D is Node2D and TextureProgressBar is Control. So this is not an ideal solution at the moment, and the implementation details should be discussed in more detail.

arkology commented 1 week ago

Oh, it looks like this problem was reported a few years ago. See https://github.com/godotengine/godot/issues/46266