godot: Godot 4 .Net - Loading / Assigning a script exported from another project fails with error ("Cannot instance script because the associated class could not be found")

I’m sorry you feel they way, but you’re not gonna get any promises that bugs will be fixed anywhere, not here, not with Unity, or any other commercial project, sure they have more resources, but no one can, or should, promise that bugs will be fixed. There’s plenty of bugs that have been present in bit commercial projects for years.

It’s of course not optimal, but this is a community driven project, based on best efforts and voluntary work. We who contribute here, save for a few people who actually are paid in various ways or sponsored, get no direct reward. And some of us spend significant portions of our spare time doing it, because we want to, and demand nothing in return. And I’m not complaining or demanding praise or thanks, just frankly stating what many of us who make this engine possible do and feel.

And honestly it’s disheartening when people complain over having an entirely free engine, with no royalty, no restrictions, and a massive community that pretty much every single day make improvements on some part of it, and it isn’t perfect.

I wasn’t telling you “if you want it fixed then fix it yourself”, I said “if you can help with this you are welcome to!”… And responded to your attitude that implied that bugs reported in this engine are not worked on, responded to, and resolved.

Quite honestly, this is one of the most disappointing answers that you could have given. Yes, I am aware that the bug is labeled as still open. Yes, I am aware that hoping that there was progress on the bug was a long shot. Yes, I am aware that every project is going to have bugs and broken features. No, I am not going to invest the significant amount of time it would take to learn the engine systems and implement the feature myself.

Godot as a whole is positioning itself to be a viable alternative to engines such as Unity and especially Unreal Engine when it comes to developing 2D games or 3D games that don’t require AAA visuals. However, wanting to have broader appeal means that you can’t hide behind the “We’re open source, so fix it yourself!” non-answer if you want to be taken seriously. You may consider that answer acceptable from the perspective of an open source project contributor, but it is significantly less so from an outsider’s perspective.

Would it be possible for me to learn enough about the engine and implement the feature myself? Perhaps. But that’s certainly not always going to be the case, especially since Godot is a beginner friendly engine by nature of having strong 2D support. It’s not unreasonable to think that some beginner developer might implement a game in Godot and then decide to learn how to make it moddable and encounter this issue. I would not expect someone with minimal programming experience to dive into Godot’s code and implement such a feature themselves.

As it stands, I have very little invested in Godot at the moment. I would like to invest more time into Godot. But answers such as this are not encouraging. Releasing DLC or making a game moddable is not some obscure use case for game developers. If such a feature is so fundamentally broken that it flat out doesn’t work, how many other features should I expect to come across that flat out don’t work either? I am not willing to invest the considerable amount of time it would take to release a well polished game if the platform I am working with is simply going to tell me to implement or fix it myself any time I come across a bug or broken feature.

Is this getting fixed in 4.2

Godot is a community ran project and bugs are fixed on best effort basis. If there is no one skilled enough in the area to fix, there is no fix… sadly.

Unfortunately from what I understand C# is one of the areas where it’s currently lacking (the two major c# guys decided to go on holidays or just take a break). (The other area where there’s a dearth of contributors is physics)

It would be appreciated if we could get some communication regarding this bug.

While the docs pages says this works like that and the page claims to be up to date, it is also wrong.

This feature has simply never been implemented after the move to .NET 6 for Godot 4.

https://github.com/OrdinaryGizmos/godot/commit/afa885888475372a34624e6394f8a93af1511322

I found a fix. The issue is that for Godot to know that there are scripts in your DLL, it has to call Godot.Bridge.ScriptManagerBridge.LookupScriptsInAssembly(assembly);

Further complicating the matter, the AssemblyAttribute that it looks for is AssemblyHasScriptsAttribute and this is loaded from GodotSharp.dll in a different AssemblyLoadContext than the game.

My patch adds a custom resolver to the Main.cs file in the mono glue that loads GodotSharp.dll (or any dependencies) into the correct AssemblyLoadContext.

After loading the assembly you will need to call Godot.Bridge.ScriptManagerBridge.LookupScriptsInAssembly(assembly);

This was tested on Godot 4.2-dev6 for my game. I plan on opening a pull request.

UPDATE: This fix in the commit is only for tools enabled builds. I am working on a fix for exported releases.

NEW UPDATE: I upgraded to 4.2-beta5 and rewrote my changes. You shouldn’t need to modify the engine code at all. All you need to do when loading a DLL is the following 3 lines. In this case dllFile is a byte[] that I preloaded.

        var context = AssemblyLoadContext.GetLoadContext(typeof(Godot.Bridge.ScriptManagerBridge).Assembly);
        var assembly = context.LoadFromStream(new MemoryStream(dllFile));
        Godot.Bridge.ScriptManagerBridge.LookupScriptsInAssembly(assembly);

@Heremeus Can you try out these three lines and see if that fixes it for you?