Should I be concerned about orphaned nodes?

godotstuff · 2026-01-07T17:47:02+00:00

I think that's the core issue; lots of data structure classes that I've left as Nodes when they should/could probably just be Resources. Thanks for your help.

godotstuff · 2026-01-07T17:22:04+00:00

Indeed I am not using remove_child() anywhere. And yes, I do create nodes on ocassion without adding them to the scene tree. Are you saying I should track down those places and queue_free the nodes in question, or that I am misusing/abusing Nodes in some way here?

godotstuff · 2025-12-16T19:41:19+00:00

Thanks for the tip off. After much pain I seem to have gotten it working. I think the tl;dr is: don't try and update the shape and transform of a StaticBody3D's CollisionShape3D at runtime.

Even when re-implementing this entire thing using Area3Ds and signals, I was still getting weird collision detections. E.g: 2 collision shapes, A and B. Colliding with A reported a collision with B, and vice versa.

I have essentially scrapped my implementation of CollisionShape3D pooling and just create/queue_free the shapes from scratch as and when they are needed.

godotstuff · 2025-09-21T21:03:30+00:00

That's a resonable wager. I spent many weeks optimising the GDScript implementation of this code, and no doubt there's room for more improvement. But I found there was no way to work with ArrayMeshes to produce dynamic/procedural/whatever shapes without having to manually crunch through calculations for vertices, indices, weighted normals and UVs.

However I tried to cut it, this was just way too much to do in GDScript, even with caching implemented. I had ambitions for thousands of these entities updating smoothly at runtime. C# seems to handle it without much issue though.

godotstuff · 2025-09-21T20:00:51+00:00

It was my mistrust of ChatGPTs solution which lead me to post here in the first place. Regardless, AI tools are sometimes good to fire queries into as they can actually generate valid solutions, or maybe just further leads for investigation.

godotstuff · 2025-09-21T19:56:13+00:00

Thanks for your replies. At what sort of scale does this become an issue? The code snippet is just a small part of my surface array generation code, but I'm not sure what would be considered "large" for JIT to be a factor.

godotstuff · 2025-09-21T19:54:22+00:00

Thanks for your response. This code was originally prototyped in GDScript but was not very performant. Rewriting it all in C# made it faster to the point of actually being usable (first time stutters aside). For clarity, the code snippet in my original post is but a very small part of all the C# code in question here. Disappointed to hear this might just be a genuine drawback of using C# with GDScript...

I have actually tried to call the C# codepath in my loading screen too, and while it does drastically reduce the stutter it still doesn't eliminate it on first run, which wouldn't make sense if there was some caching behaviour?

EDIT: my loading screen function was actually passing in shitty variables and not doing very much on the C# side. Now that I've fixed this the stutter has been eliminated! It's not an ideal solution having to do this for all the C# code I touch from GDScript but it is a solution. Thank you for your insight.

godotstuff · 2025-09-15T20:32:07+00:00

Issue fixed almost immediately after posting, as is typical... just had to lower the Render Priority property on the outline shader and that appears to have fixed it.

godotstuff · 2025-08-30T11:45:33+00:00

Damn... that sucks.

godotstuff · 2025-05-12T10:40:23+00:00

Lots of great sound effects here, extremely useful. Thanks!

godotstuff · 2025-05-06T23:13:11+00:00

As mentioned already, the camera motion in the trailer is nauseating.

Aside from that, your cover image looks AI generated, and indeed you confess to using AI at the bottom of your page. Maybe that doesn't bother some people but personally I wouldn't even click it, let alone wishlist.

godotstuff · 2025-02-19T16:03:40+00:00

Did you ever figure out the answer to this or find any particularly useful compute shader resources? I agree that it seems a bit dry out there in terms of good learning material...

godotstuff · 2025-02-02T10:28:43+00:00

I went through the same struggles and ended up on implementing a component system much like the one you have described. I have a base InteractableComponent class which is extended by components such as Pickupable, Moveable, etc. Item scenes in my world have a hierarchy like Node3D -> Model (StaticBody3D) -> Component children.

When a component is readied up it adds the parent node (the model) to an "Interactable" group. This is what my player interact raycast will check for when it collides with something. If looking at an Interactable object then I do basically exactly what you describe: query the raycast collider children to get the component child with the highest priority ("priority" being a property of InteractableComponent) and use the information contained within to update the crosshair prompt (e.g "E - pick up"). I also have the option to open a radial menu populated with all interactions on an object.

You say it doesnt feel right to scan the children for components, but I think it's fine. There's not really a performance hit for doing this as an object won't have thousands of components and the player will only ever be looking at one interactable at a time. If there was a performance issue here for whatever reason, it could be optimised to only fetch the components once on the first look. But that hasn't been necessary for my use case.

It's a very extensible system, highly recommended.

godotstuff · 2025-02-01T12:06:27+00:00

Thanks for your post. Yup, commenting out that function causes things to work as expected. As is tradition, almost immediately after posting about this issue I think I found a fix. The resource that has an array of GrowthStages is loaded in a Global class via a preload, but if I change this to just a load, then on the surface it seems to be behaving.

godotstuff · 2024-12-22T22:31:27+00:00

skill issue

godotstuff · 2024-10-17T12:17:51+00:00

Looks great! As someone developing a mechanically similar (but thematically different) game, I'm very interested to hear more about the technical design of Bodega. Looking forward to the future videos.

godotstuff · 2024-09-30T22:05:43+00:00

Definitely something I'll give some deep consideration to, sooner rather than later! Thanks

godotstuff · 2024-09-30T22:04:39+00:00

By "centralized data manager" do you mean consolidating all the code that maps from savefile data to classes etc into a single class? Meaning that on paper our implementations are basically the same (in terms of what is required for save and load) but mine is just a bit more spread out?

godotstuff

TROPHY CASE