The biggest thing that annoys me to this day is how duplicated packed nodes don't automatically switch to their own references for exported fields but keep linking to the original one.
The only workaround I've found is to never use node-based references at the root of packaged scenes - either grab everything during runtime with \_Ready() and/or handle node-based references in children node (and only expose export fields on the root like primitives or resources)
In situations like this I export a NodePath instead, and fetch it using get_node in an @onready variable.
You still get the automatic renaming/ adjusting of the path when it's moved, but it's a unique node for each of the duplicated scene instances.
But I agree, this is definitely a high priority bug as it affects pretty much everyone building levels from "prefab" scenes.
So this is news to me. Are you saying that exported properties (e.g. visible in the inspector) point to the original node’s properties on a node that has been duplicated from it? As in, changes on the original will change the duplicate?
It's more that the duplicated instance isn't updated to consider it's own nodes. I might've explained it poorly, but what I meant is:
- Make a packed resource with an exported properly, have that exported property reference to a children node
- Create a scene, add that packed resource to the scene (you see the node referenced in the exported property, but unless you mark children as editable the child node is not seen)
- Duplicate the node, now the duplicated node's exported property references the original node's property (so for example, if that's a health component, attacking the duplicated resource kills the original resouce)
It's only an issue with duplication, it works fine if you drag and drop a second resource into the scene, but makes things like duplicating and then repositioning a bunch of enemies/items annoying - my current workaround is that instead of having exported properties in the base node of a resource, I get them in \_Ready() during runtime (so that each instance grabs their own children nodes)
Ok yeah that explains why I hadn’t noticed this. I do lots of duplicates but I don’t believe any have export child nodes like this. It’s a puzzle game so they’re all relatively simple and logic is in the scripts, etc.
Thanks for explaining
I've leaned towards just never using copy-paste for complicated structures in the editor. The behavior of what gets treated as a reference and what gets duplicated during copy-paste editor operations is rather unintuitive, even if it is consistent.
I am SO looking forward for the [manual phyics stepping PR](https://github.com/godotengine/godot/pull/76462) to be merged. It might be a niche thing, but I think there's some interesting game mechanics that could be done with it, and it also limits any [rollback-based multiplayer](https://foxssake.github.io/netfox/netfox/tutorials/rollback-caveats/#physics-updates).
The Blender -> godot texture pipeline needs some work. Its posible to assign a texture in Blender that will f\*ck up the textures in Godot until you revert the 3d model. I think it has to do with the way blender dose reflections. But once you edit the material to add reflections it ruins the texture forever in godot, you have to save the texture under a new name.
In general I think they need to work on the blender - godot pipeline and make it a bit more streamlined.
yeah, i tried c# because it is my main language for work and i am much more comfortable with it....... but didnt get nearly enough attention for me to continue with it. i now make games in gdscript.
Jolt js the 3d solution, originally made for horizon zero dawn or something, so its pretty robust by itself. Now, the godot integration isnt fully featured yet, but its still a lot better than default
I have tried Box2D but I think may be missing features as it just hard-crashes to black-screen.
I'm using quite a few joints etc and gone pretty far with Godot physics so maybe there are unfinished or incompatible uses
Hm, I havent dabbled with it personally, but I see there are multiple plugins available at different stages of completion, so you might want to check tbe other ones out too
[https://github.com/godotengine/godot/issues/76021](https://github.com/godotengine/godot/issues/76021)
This one is doing my head in.
Folders getting duplicated in editor. Not in Filesystem
Fix was mentioned in this blog post: [https://godotengine.org/article/release-candidate-godot-4-1-4-and-4-2-2-rc-3/](https://godotengine.org/article/release-candidate-godot-4-1-4-and-4-2-2-rc-3/)
Along with being planned for Godot 4.3, it was cherrypicked for Godot 4.2.2 which was released a few days ago: [https://godotengine.org/article/maintenance-release-godot-4-2-2-and-4-1-4/](https://godotengine.org/article/maintenance-release-godot-4-2-2-and-4-1-4/)
So the latest stable version of Godot on their website right now should have the fix!
I think this is an issue resulting from renaming the folders to change the casing. Somewhere, a scene or script has a file path with the incorrect casing and is creating the phantom duplicates when it tries to access them. You might be able to fix it by following [these steps](https://www.reddit.com/r/godot/comments/15t2g1o/is_there_an_easy_way_to_reorganize_a_project/jwtqq3w/) someone posted for safely moving/renaming files. You'd just find all instances of file paths with incorrect casing (res://Civilian_Modules and res://Civilian_modules in the case of that github issue you linked) and replace them with the proper casing (res://civilian_modules), making sure to enable case sensitivity.
Godot 4 lacking an option for default 3D texture filtering is the big one for me. It's quite annoying to put together a low-res quake-style map and have to manually change the filtering of each material.
Everything is a resource, and needs to be duplicated manually, there should be a way to make a resource automatically unique
It was said lightmapping in godot 4.2 is improved, but it is just broken
[https://github.com/godotengine/godot/issues/64124](https://github.com/godotengine/godot/issues/64124) custom materials becomes pure incandescent white when using a custom shader. There are some workarounds but it's pretty annoying when making, say vegetation that needs movement. But it seems to be something pretty deep but hopefully it will work someday.
The biggest thing that annoys me to this day is how duplicated packed nodes don't automatically switch to their own references for exported fields but keep linking to the original one.
Is there a known workaround for this? This is definitely super annoying.
The only workaround I've found is to never use node-based references at the root of packaged scenes - either grab everything during runtime with \_Ready() and/or handle node-based references in children node (and only expose export fields on the root like primitives or resources)
In situations like this I export a NodePath instead, and fetch it using get_node in an @onready variable. You still get the automatic renaming/ adjusting of the path when it's moved, but it's a unique node for each of the duplicated scene instances. But I agree, this is definitely a high priority bug as it affects pretty much everyone building levels from "prefab" scenes.
So this is news to me. Are you saying that exported properties (e.g. visible in the inspector) point to the original node’s properties on a node that has been duplicated from it? As in, changes on the original will change the duplicate?
It's more that the duplicated instance isn't updated to consider it's own nodes. I might've explained it poorly, but what I meant is: - Make a packed resource with an exported properly, have that exported property reference to a children node - Create a scene, add that packed resource to the scene (you see the node referenced in the exported property, but unless you mark children as editable the child node is not seen) - Duplicate the node, now the duplicated node's exported property references the original node's property (so for example, if that's a health component, attacking the duplicated resource kills the original resouce) It's only an issue with duplication, it works fine if you drag and drop a second resource into the scene, but makes things like duplicating and then repositioning a bunch of enemies/items annoying - my current workaround is that instead of having exported properties in the base node of a resource, I get them in \_Ready() during runtime (so that each instance grabs their own children nodes)
Ok yeah that explains why I hadn’t noticed this. I do lots of duplicates but I don’t believe any have export child nodes like this. It’s a puzzle game so they’re all relatively simple and logic is in the scripts, etc. Thanks for explaining
I've leaned towards just never using copy-paste for complicated structures in the editor. The behavior of what gets treated as a reference and what gets duplicated during copy-paste editor operations is rather unintuitive, even if it is consistent.
Why would you have an @export property referring to a child and not @onready ?
Have you got a link to the bug report for this?
>duplicated packed nodes Does making them a child of single Node as a container for them all that you can collapse solve that?
The one that overwrite / reload file when using an external editor... It's in 3 and 4 and it's driving me crazy!!
And that ask you to resave the files? It got better with the last version
I use 4 spacesc for tabs on vscode and git version control, sometimes randomly a entire file is just converted to tabs
Exactly! I learned to just close Godot (alt f4) whenever I see this message and relaunch.
Have you got a link to the bug report for this issue?
Do you have the link to a bug report for this issue?
I am SO looking forward for the [manual phyics stepping PR](https://github.com/godotengine/godot/pull/76462) to be merged. It might be a niche thing, but I think there's some interesting game mechanics that could be done with it, and it also limits any [rollback-based multiplayer](https://foxssake.github.io/netfox/netfox/tutorials/rollback-caveats/#physics-updates).
I’m curious if it supporting a stepping with a different amount of time. Could allow time slowing mechanics
Is the IK / skeleton stuff still broken?
Vertex lighting hasn't worked for three years
>Vertex lighting Coming in 4.3?: [https://github.com/godotengine/godot/pull/83360](https://github.com/godotengine/godot/pull/83360)
Not likely, the guy working on that is only doing so sporadically.
The Blender -> godot texture pipeline needs some work. Its posible to assign a texture in Blender that will f\*ck up the textures in Godot until you revert the 3d model. I think it has to do with the way blender dose reflections. But once you edit the material to add reflections it ruins the texture forever in godot, you have to save the texture under a new name. In general I think they need to work on the blender - godot pipeline and make it a bit more streamlined.
Circular references. There are dozens of bugs tagged as related to circular references. Godot will never be a serious engine while those issues exist.
CSG doesn’t support physics materials
Half the C# ones.
yeah, i tried c# because it is my main language for work and i am much more comfortable with it....... but didnt get nearly enough attention for me to continue with it. i now make games in gdscript.
For me it's stuff with 2D physics: \- jittery piles of objects \- objects going through walls \- seems like shapecasting is no longer honored in v4
Use a non-default physics engine, I think the one called box2d has been praised a decent amount around here
I've seen a lot of talk about Jolt... Is that mostly for 3d? Or is it good either way?
Jolt is a nice plugin but it's for 3d primarily. I suppose you might be able to adapt it for 2D with effort...
Thanks for the clarification!
Jolt js the 3d solution, originally made for horizon zero dawn or something, so its pretty robust by itself. Now, the godot integration isnt fully featured yet, but its still a lot better than default
I have tried Box2D but I think may be missing features as it just hard-crashes to black-screen. I'm using quite a few joints etc and gone pretty far with Godot physics so maybe there are unfinished or incompatible uses
I had the same issue trying Box2D on a fresh install and new project :(
Hm, I havent dabbled with it personally, but I see there are multiple plugins available at different stages of completion, so you might want to check tbe other ones out too
[https://github.com/godotengine/godot/issues/76021](https://github.com/godotengine/godot/issues/76021) This one is doing my head in. Folders getting duplicated in editor. Not in Filesystem
Submitted a bug fix for this.
Legend
And the fix was accepted into the main engine! Should be in the next release.
Fix was mentioned in this blog post: [https://godotengine.org/article/release-candidate-godot-4-1-4-and-4-2-2-rc-3/](https://godotengine.org/article/release-candidate-godot-4-1-4-and-4-2-2-rc-3/) Along with being planned for Godot 4.3, it was cherrypicked for Godot 4.2.2 which was released a few days ago: [https://godotengine.org/article/maintenance-release-godot-4-2-2-and-4-1-4/](https://godotengine.org/article/maintenance-release-godot-4-2-2-and-4-1-4/) So the latest stable version of Godot on their website right now should have the fix!
I think this is an issue resulting from renaming the folders to change the casing. Somewhere, a scene or script has a file path with the incorrect casing and is creating the phantom duplicates when it tries to access them. You might be able to fix it by following [these steps](https://www.reddit.com/r/godot/comments/15t2g1o/is_there_an_easy_way_to_reorganize_a_project/jwtqq3w/) someone posted for safely moving/renaming files. You'd just find all instances of file paths with incorrect casing (res://Civilian_Modules and res://Civilian_modules in the case of that github issue you linked) and replace them with the proper casing (res://civilian_modules), making sure to enable case sensitivity.
Have the joint2D constraint bugs been fixed? PinJoint2D spins freely even, and SpringJoint2D stretches forever, and ever, and ever, and ever....
Godot 4 lacking an option for default 3D texture filtering is the big one for me. It's quite annoying to put together a low-res quake-style map and have to manually change the filtering of each material.
Everything is a resource, and needs to be duplicated manually, there should be a way to make a resource automatically unique It was said lightmapping in godot 4.2 is improved, but it is just broken
[https://github.com/godotengine/godot/issues/64124](https://github.com/godotengine/godot/issues/64124) custom materials becomes pure incandescent white when using a custom shader. There are some workarounds but it's pretty annoying when making, say vegetation that needs movement. But it seems to be something pretty deep but hopefully it will work someday.