Are you using the modulate property to achieve transparency? Modulate propagates to all CanvasItem descendents of the node you set it on. You can instead try using the self_modulate property (docs.godotengine.org/en/stable/cl...), which doesn't affect child nodes.

You can actually use varyings to do that in godot! From docs.godotengine.org/en/stable/tu... :

"It's also possible to send data from fragment to light processors using varying keyword. To do so you can assign it in the fragment and later use it in the light function."

TextureProgressBar has circular fill modes, but the ProgressBar node doesn't.

You can implement either a ResourceFormatLoader script or an EditorImportPlugin to do this. The difference between them is that the loader loads a resource directly from the input file (so, a CSV in your case) while an importer generates a new internal resource file from it, which is then loaded.

So trying to load scene.tscn will fail, and only Scene.tscn will work. You can read a bit more about this at docs.godotengine.org/en/stable/tu...

This might also be a case sensitivity issue. Windows is, by default, case insensitive. So if you have a Scene.tscn, and try to load it from the editor as scene.tscn, it'll work, since the editor will ask windows for the file. On an exported project, the pck (res://) stuff is case sensitive, though.

In that case, you have access to the Container Sizing settings instead, which acts as hints to how the container will layout this node (the fill/shrink/expand settings)

They appear if Layout Mode is set to Anchors, and Anchor Preset to custom. Anchors allow you to set the size and position of a control node relative to its parent control. If a Control is a child of a Container, the container controls the node's layout, so you can't use those options.

You could probably simplify this to a plugin that adds a button on the toolbar to toggle the property on the viewport, so you can just use any AudioListerner3D normally (and avoid messing up the editor state too much).

@tool extends AudioListener3D @warning_ignore("unused_private_class_variable") @export_tool_button("Toggle Current") var _make_current = toggle_current func toggle_current() -> void: var v := EditorInterface.get_edited_scene_root().get_parent() as SubViewport if not is_instance_valid(v): return if is_current(): clear_current() v.audio_listener_enable_3d = false else: make_current() v.audio_listener_enable_3d = true

Ok, I figured it out. Enabling `audio_listener_enable_3d` on the parent node (a subviewport) of the edited scene root allows the listener to work. Note that this isn't any of the viewports returned by EditorInterface.get_editor_viewport_3d(). This script works for me.

Wait, I just noticed it was 3d, not 2d.

I just did a quick test, and simply enabling `Current` on an AudioListener2D node in the editor seems to use that as the listener, instead of the camera.

"The X axis is horizontal and points to the right, the Y axis is vertical and points up and the Z axis points towards the outside of the front face of the screen. In this system, coordinates behind the screen have negative Z values. " Followed by an illustration of the coordinate systems, with the colors changed from the traditional ones. The X axis is green, the Y axis is blue and the Z axis is red (Traditionally, X is red, Y is green and Z is blue)

@freya.bsky.social I thought you might enjoy this gem from the Android sensors documentation (I was extremely confused reading the description and comparing it to the image before I actually looked at the axis labels)

Strictly speaking, the most basic node that has a 2d transform (and therefore can do 2d transform propagation) is CanvasItem, the parent class of both Node2D and Control. So, mixing Control nodes and Node2Ds works nicely (for example, to have a label following a character around, or a health bar)

(In some ways, having a Node2D as a child of a Node is similar to setting the top_level property on the Node2D to true)

So, if you have a Node2D -> Node -> Area2D scene, and the Area2D position is set to something like Vector2(15, 10) or whatever, it'll have that position in global space, regardless of what the Node2D's position is. if the middle Node was a Node2D, the Area2D's position would be relative to it.

Quick note: Area2D (and any other Node2D) do spawn properly when children of a base Node. However, because a base Node does not have a transform (position, etc), it does propagate transforms, and its children are in 'global space', and do not follow any Node2D parent the bare Node might have.

I'm curious If inlining it is faster than using the built in line_intersects_line function in the Geometry2D singleton ( docs.godotengine.org/en/stable/cl... )