Make the module more resilient to invalid states. Many of the previous explicit crashes got replaced by errors that won't stop the engine execution.
If something goes wrong somewhere in the initialization of the module, a helpful message will appear on-screen before falling back to a Godot with only JVM placeholders.
In debug/tool mode, it's even possible to start the game using JVM scripts that are not built yet. In such case, the script is just not created and only the naked native object will remain (Errors are still thrown in such cases).
GDKotlin got explicit initialization states and a custom error message exists for almost each of them (when the cause is likely a basic one) in case an issue was encountered.
If the final state is invalid, GDkotlin will be immediately freed and unloaded. The languages and resource loader are still registered to Godot, even in the case of an invalid state, so users can manipulate JVM scripts in the editor without a JAVA_HOME, embedded JRE, boostrap.jar or main.jar (They will have an alert appearing on-screen when the engine starts).
Note that the last part of the initialization still has to be done in GdjLanguage. This final step fetches all the Jvm Scripts from Kotlin to C++ as well as sending all method pointers from C++ to Kotlin.
This latter detail matters because this operation requires all classes to be initialized in Godot, so we can't do it as part of the module initialization itself, even using the latest initialization enum value in it. Sadly Godot doesn't have a "afterAll" phase for module initialization.
Make the module more resilient to invalid states. Many of the previous explicit crashes got replaced by errors that won't stop the engine execution. If something goes wrong somewhere in the initialization of the module, a helpful message will appear on-screen before falling back to a Godot with only JVM placeholders. In debug/tool mode, it's even possible to start the game using JVM scripts that are not built yet. In such case, the script is just not created and only the naked native object will remain (Errors are still thrown in such cases).
GDKotlin got explicit initialization states and a custom error message exists for almost each of them (when the cause is likely a basic one) in case an issue was encountered. If the final state is invalid, GDkotlin will be immediately freed and unloaded. The languages and resource loader are still registered to Godot, even in the case of an invalid state, so users can manipulate JVM scripts in the editor without a JAVA_HOME, embedded JRE, boostrap.jar or main.jar (They will have an alert appearing on-screen when the engine starts).
Note that the last part of the initialization still has to be done in GdjLanguage. This final step fetches all the Jvm Scripts from Kotlin to C++ as well as sending all method pointers from C++ to Kotlin. This latter detail matters because this operation requires all classes to be initialized in Godot, so we can't do it as part of the module initialization itself, even using the latest initialization enum value in it. Sadly Godot doesn't have a "afterAll" phase for module initialization.