Heya!
This post is more related to how do I currently work and not that much related to TinkerFlow itself!
Currently, I have some problems with Windows, Godot .NET, and TinkerFlow. I cannot debug it as much as I would like, and it maybe is also interesting for you.
When I start the TinkerFlow example application on Windows, nothing happens except a pile of error messages and the like.
We are debugging it to figure out the specific cause. So far we know the problem does not exist on Linux with Godot .NET. That leaves two possibilities, it is something specific to Windows, or something higher up, for example, the TinkerFlow plugin itself.
Two issues look related, like the godot-proposals#11819 asks for a solid solution to the “ALC unload failure” that C# developers hit. The other one is the Newtonsoft.Json#2414, where Json.NET is not unload friendly. So Newtonsoft.Json might be the problem here.
If we find a solution, we will document it so other people can use it too. But It seems like we have to exclude Newtonsoft anyway.
The web build is blocked#
Godot .NET has another restriction, and this one is a real blocker here. It cannot build for the web at the moment. So we are looking at the alternatives.
2Dogs is a good working solution for Godot .NET builds, and it works like intended by the 2Dogs devs <3. But it would still have the problem that the GD-Godot editor could not use TinkerFlow with this. So, One option is a native lib.
We can turn the C# code into a binding, a DLL container that Godot can then use from GDScript or C++. That is possible, but it sits deep in the programming layer. The problem is the native binary, the DLL itself. It cannot be built for the web either, so this option inherits the same disadvantage.
What we are trying now#
The other option is to build TinkerFlow itself as a native library in C++ or GDScript. At least the runtime part, the piece that runs when a process is loaded.
We are asking around in the community and watching the Godot forum and the updates on the .NET version. Right now this blocks the whole construct, including the samples. I expect the web build will work for Godot .NET in the future.
Until then we have to work around it, or just not support web for now.
Consoles, Android, and macOS#
Godot .NET also has porting problems on other platforms, as we heard from several sides. For TinkerFlow itself that is not a problem yet. But if people use TinkerFlow to build a game (which is possible!), TinkerFlow has to run on every platform they target.
By platforms, I mostly mean consoles like Nintendo Switch, PlayStation or Xbox. Android already works, so we can build a VR app for Android. Apple is unclear at the moment, partly because we have no devices to test with, including also the Apple Vision Pro…
The plan if we move to GDScript or C++#
Several people told us that GDScript or C++ is probably the better alternative. If that turns out to be true, the plan is to finish TinkerFlow on Godot .NET first. Once the components work as we hope, port it piece by piece second. The runtime goes first, in GDScript or C++. After that comes the editor for Godot.
We don’t want a workflow where in Godot .NET is the application built, and then needs to be ported to GD-Godot for each deployment. That is also why we would try to port at least the project itself, so we keep the connection to VR Builder.
We are testing and will keep you updated. If you have a hint where we should look, or an opinion on whether we should move to GDScript or C++, tell us. It would also help other people to know how to handle this and how the porting works.
Thankies for reading and see you at the next blog post!