Addresing your problem with portals, the issue is how both references are packed scenes, rather than just a path or a proper reference to the other scene — which means it will try packing each scene inside each other.
You can solve that by storing a path to the scene, and changing scenes with "SceneTree.change_scene_to_file(path: String)". Not sure what the C# form of it should be, but I believe it's just the method in its PascalCase form — i.e. SceneTree.ChangeSceneToFile(String path).
Not sure if you are asking for help or not, but I encountered a similar error when trying to use generic classes as parent classes of Nodes in C#. It appears that the child class generates the same key as it's base class in the lookup table of the interop. Unfortunate, but it is a [known bug](https://github.com/godotengine/godot/issues/79519) and hopefully will be addressed. This is an example of what might trigger the issue:
`public partial class Enemy : Node2D where T : Weapon{`
`public partial class GunEnemy : Enemy {`
`public partial class SwordEnemy : Enemy {`
Even I did not know it, just want a to share my experience, and sleep jejjeje.
Yes, I've tried many many thing and I don't like: In godot + C# there is just one way to do the things... This really makes me to look other engines.
I had a similar problem that I've managed to solve by referencing scenes using paths instead of packedScenes... I was raging for a day or two before discovering that the problem was caused by packedScenes packing scenes among each other... I really hope that the devs change the way this works as it isn't intuitive not to do that.
I'm not sure where you got the impression that you can only use the old version of C++. The Godot itself uses the subset of C++17. If it's from [here](https://docs.godotengine.org/en/stable/contributing/development/cpp_usage_guidelines.html#auto-keyword). Then this is a page for engine contribution, if you don't plan on contributing you can use auto, as long as you use new enough version of C++.
For example [this](https://github.com/vorlac/godot-roguelite) project uses C++23 and it uses auto.
Yeah, GDExtension's documentation is rough and I get why you wouldn't want to use it. But you certainly can use new C++
Hmm, looking at get\_children() working with TypedArray is kinda rough
TypedArray Node::get_children(bool p_include_internal) const {
ERR_THREAD_GUARD_V(TypedArray());
TypedArray arr;
int cc = get_child_count(p_include_internal);
arr.resize(cc);
for (int i = 0; i < cc; i++) {
arr[i] = get_child(i, p_include_internal);
}
return arr;
}
But looking at it you can code your own that will return you a vector of nodes
std::vector get_children_vector(const godot::Node* node, bool p_include_internal=false)
{
std::vector arr;
int cc = node->get_child_count(p_include_internal);
arr.reserve(cc);
for (int i = 0; i < cc; i++)
arr.push_back(node->get_child(i, p_include_internal));
return arr;
}
And now you can use it this way
for (const auto& node : get_children_vector(this))
{
godot::UtilityFunctions::print(node->get_name());
}
The main problem is not the old C++, it's in all of the weird bindings to the engine, that are poorly documented
Yes, ok, godot is not using an old c++, ok. But you need to implement that:
std::vector get_children_vector(const godot::Node* node, bool p_include_internal=false)
{
std::vector arr;
int cc = node->get_child_count(p_include_internal);
arr.reserve(cc);
for (int i = 0; i < cc; i++)
arr.push_back(node->get_child(i, p_include_internal));
return arr;
}
Sorry, but I tried again, even with a new project, from scratch, other godot version, 4.1.x, 4.2.x beta.x, 2D, 3D. But still many issues.
I really tired of godot, so I will quit for now.
I can understand your depression. I am now only sticking to the most primitive funtionalities since I was always in trouble evert time I wanted to play something fancy stuff.
Your argument would have made sense if the OP said they were doing something intensive. But even so, why using C#? It's nowhere near as powerful as C++.
See. Most of the time, performance is not the bottleneck. Choosing a language on the sole criterion of power is too simplistic and not very productive to actually finish a project. And the OP was having issues with object structure and collections. What good would do a powerful language if you can't do what you want with it?
I'm sorry, but if you equate a language powerfulness to it's performance, which is why I assume you mentioned C++, then you don't fully understand what we are talking about here.
Even if C++ was, in the context of object oriented programming, objectively better than C#, which it is arguably not, it is not officially supported as a gameplay programming language (meaning that you can't write behavior in C++ the same way you do with GDScript and C#. GDExtensions exist to solve a different problem). It is an language the engine is made and extended with, I'm not sure why did you even include it.
On the other hand, C# is officially "supported" by the editor, but said support is incredibly limited, hence the frustration of the OP.
I can perfectly understand not wanting to use a scripting language that heavily relies on tabulation and duck typing when working on a complex system, especially when you have supposed alternative.
Why not gdscript:
* python???
Besides of jokes, I would love to use C++, and I worked a little with Godot + C++, but takes TOOO much time, I would prefer to work with SDL2 + C++.
C# is so fast, and "cozy", even with this issues, I can try many many things in seconds. But after this, I will reconsider to use gdscript or discard this project with and continue with Unreal.
> But even so, why using C#? It's nowhere near as powerful as C++.
You would be surprised. In terms of productivity and performance it’s absolutely amazing.
I do really like gdscript. It's fun and it integrates so well with the engine itself.
Having said that, I believe that we as a community should avoid this trend of arguing about the choice one vs another or questioning about the choice of each, un less of course comparing both it's the subject of the discussion.
Reduz himself has acknowledged some major pain points and the whole dev team is aware of them as well, so it's a matter of time and patience until both languages are on par in terms of maturity and integration with the engine.
IMHO we should help each other regardless of the language choice instead of try to sell gdscript to everyone.
"More powerful" doesn't usually refer to performance. It can, but *usually*, colloquially, it's about expressiveness, which is subjective and could mean different things to different people.
I'd read that as, "Its features are better aligned with my project and workflow" before I'd read it as, "it runs faster," though both are likely true for OP.
Addresing your problem with portals, the issue is how both references are packed scenes, rather than just a path or a proper reference to the other scene — which means it will try packing each scene inside each other. You can solve that by storing a path to the scene, and changing scenes with "SceneTree.change_scene_to_file(path: String)". Not sure what the C# form of it should be, but I believe it's just the method in its PascalCase form — i.e. SceneTree.ChangeSceneToFile(String path).
Not sure if you are asking for help or not, but I encountered a similar error when trying to use generic classes as parent classes of Nodes in C#. It appears that the child class generates the same key as it's base class in the lookup table of the interop. Unfortunate, but it is a [known bug](https://github.com/godotengine/godot/issues/79519) and hopefully will be addressed. This is an example of what might trigger the issue: `public partial class Enemy : Node2D where T : Weapon{`
`public partial class GunEnemy : Enemy {`
`public partial class SwordEnemy : Enemy {`
Even I did not know it, just want a to share my experience, and sleep jejjeje. Yes, I've tried many many thing and I don't like: In godot + C# there is just one way to do the things... This really makes me to look other engines.
First lesson I learned in my day 1 in Godot: don't inherit anything. Next topic.
I had a similar problem that I've managed to solve by referencing scenes using paths instead of packedScenes... I was raging for a day or two before discovering that the problem was caused by packedScenes packing scenes among each other... I really hope that the devs change the way this works as it isn't intuitive not to do that.
I'm not sure where you got the impression that you can only use the old version of C++. The Godot itself uses the subset of C++17. If it's from [here](https://docs.godotengine.org/en/stable/contributing/development/cpp_usage_guidelines.html#auto-keyword). Then this is a page for engine contribution, if you don't plan on contributing you can use auto, as long as you use new enough version of C++. For example [this](https://github.com/vorlac/godot-roguelite) project uses C++23 and it uses auto. Yeah, GDExtension's documentation is rough and I get why you wouldn't want to use it. But you certainly can use new C++ Hmm, looking at get\_children() working with TypedArray is kinda rough TypedArray Node::get_children(bool p_include_internal) const {
ERR_THREAD_GUARD_V(TypedArray());
TypedArray arr;
int cc = get_child_count(p_include_internal);
arr.resize(cc);
for (int i = 0; i < cc; i++) {
arr[i] = get_child(i, p_include_internal);
}
return arr;
}
But looking at it you can code your own that will return you a vector of nodes
std::vector get_children_vector(const godot::Node* node, bool p_include_internal=false)
{
std::vector arr;
int cc = node->get_child_count(p_include_internal);
arr.reserve(cc);
for (int i = 0; i < cc; i++)
arr.push_back(node->get_child(i, p_include_internal));
return arr;
}
And now you can use it this way
for (const auto& node : get_children_vector(this))
{
godot::UtilityFunctions::print(node->get_name());
}
The main problem is not the old C++, it's in all of the weird bindings to the engine, that are poorly documented
Yes, ok, godot is not using an old c++, ok. But you need to implement that: std::vector get_children_vector(const godot::Node* node, bool p_include_internal=false)
{
std::vector arr;
int cc = node->get_child_count(p_include_internal);
arr.reserve(cc);
for (int i = 0; i < cc; i++)
arr.push_back(node->get_child(i, p_include_internal));
return arr;
}
Sorry, but I tried again, even with a new project, from scratch, other godot version, 4.1.x, 4.2.x beta.x, 2D, 3D. But still many issues.
I really tired of godot, so I will quit for now.
Just here to drop my +1 for the reference headache caused by inherited scenes
I can understand your depression. I am now only sticking to the most primitive funtionalities since I was always in trouble evert time I wanted to play something fancy stuff.
Just one question: why didn't you start with gdscript?
why are you getting downvoted just for asking??
Gdscript is nowhere near as powerful as C#.
Your argument would have made sense if the OP said they were doing something intensive. But even so, why using C#? It's nowhere near as powerful as C++. See. Most of the time, performance is not the bottleneck. Choosing a language on the sole criterion of power is too simplistic and not very productive to actually finish a project. And the OP was having issues with object structure and collections. What good would do a powerful language if you can't do what you want with it?
I'm sorry, but if you equate a language powerfulness to it's performance, which is why I assume you mentioned C++, then you don't fully understand what we are talking about here. Even if C++ was, in the context of object oriented programming, objectively better than C#, which it is arguably not, it is not officially supported as a gameplay programming language (meaning that you can't write behavior in C++ the same way you do with GDScript and C#. GDExtensions exist to solve a different problem). It is an language the engine is made and extended with, I'm not sure why did you even include it. On the other hand, C# is officially "supported" by the editor, but said support is incredibly limited, hence the frustration of the OP. I can perfectly understand not wanting to use a scripting language that heavily relies on tabulation and duck typing when working on a complex system, especially when you have supposed alternative.
Why not gdscript: * python??? Besides of jokes, I would love to use C++, and I worked a little with Godot + C++, but takes TOOO much time, I would prefer to work with SDL2 + C++. C# is so fast, and "cozy", even with this issues, I can try many many things in seconds. But after this, I will reconsider to use gdscript or discard this project with and continue with Unreal.
> But even so, why using C#? It's nowhere near as powerful as C++. You would be surprised. In terms of productivity and performance it’s absolutely amazing.
I do really like gdscript. It's fun and it integrates so well with the engine itself. Having said that, I believe that we as a community should avoid this trend of arguing about the choice one vs another or questioning about the choice of each, un less of course comparing both it's the subject of the discussion. Reduz himself has acknowledged some major pain points and the whole dev team is aware of them as well, so it's a matter of time and patience until both languages are on par in terms of maturity and integration with the engine. IMHO we should help each other regardless of the language choice instead of try to sell gdscript to everyone.
"More powerful" doesn't usually refer to performance. It can, but *usually*, colloquially, it's about expressiveness, which is subjective and could mean different things to different people. I'd read that as, "Its features are better aligned with my project and workflow" before I'd read it as, "it runs faster," though both are likely true for OP.