Rust compilation requires Godot editor restart #1
Comments
|
On linux I can rebuild the DLL fine but some things are not updated. For example I've seen that I need to restart godot (maybe there is another way to trigger a "refresh"?) when:
|
|
I am also seeing a very similar behavior on Linux. It makes sense because:
So, basically, reloading the game changes happens to work on Linux merely by accident. It was not intended in the design GDExtension. That's also why in Windows, the DLL is being locked and never freed, because the process does not expect it to ever change. It is generally a reasonable assumption to make for plugin development, but seriously hampers game development 😕 |
|
Btw, to reload signals etc from the DLL, it does work to do Project -> Reload current project 👍 I guess it's effectively the same as restarting godot but a bit more convenient. Also closing to project menu and opening the project again works. |
65: PR #1/5 Astolfo feature/builtin-scalar r=Bromeon a=RealAstolfo Co-authored-by: RealAstolfo <[email protected]>
|
I can confirm similar behavior on osx as well. I can leave editor open and recompile at will as long as iam not adding new end points essentially. In that case for editor to notice them project reload must be used. |
|
On Windows it is usually possible to move a locked file (so long as it remains on the same disk), which would allow the build to proceed. I no longer use Windows, so I can't confirm whether this would work in this case. If it does, you only need to move the file every time the editor starts. You could probably attempt to acquire a read lock in build.rs, or powershell, or something and move the file if that fails. |
|
The thing is that all GDExtension bindings currently suffer from this issue, so I'd rather not build a Rust-specific workaround. It would be nice if this were fixed in Godot itself. godotengine/godot-cpp#955 proposes an approach, but priorities have shifted again... I'll try to bring this up again 🙂 |
|
A fix for Windows DLLs has been merged in godotengine/godot#80188! Now all three main platforms allow to recompile Rust while the editor is open, which is really nice 😊 In other great news, an initial step towards hot reloading is being worked on in godotengine/godot#80284 🚀 |
|
Testing godotengine/godot#80284 and changing only compat things in gdext (https://github.com/LeaoLuciano/gdext/tree/hot-reload), it works (on linux): hot_reloading.mp4 |
|
Both
have been merged to Godot There will likely be some follow-up questions and improvements on hot reloading, but these can be addressed separately 🙂 |
The style is similar to GDScript's @rpc annotation, the macro can be used as follows: godot-rust#1 - Separate arguments: ```rust #[rpc(any_peer, reliable)] fn some_rpc(&mut self) { //.. } ``` Providing overlapping arguments generates a compile error. Any omitted arguments are set to their default values. godot-rust#2 - Provide an expression: ```rust const CONFIG: RpcArgs = RpcArgs { mode: RpcMode::Authority, ..RpcArgs::default() }; #[rpc(config = CONFIG_EXPR)] fn some_rpc(&mut self) { //.. } ``` Number godot-rust#2 is useful in case you want to reuse the configuration on multiple functions. Number godot-rust#2 is mutually exclusive with number godot-rust#1. --- The generated macro code works as follows: - Caches the configuration in a `ClassPlugin`. - On `__before_ready()`, searches for the configuration in the plugin, registering them with Node::rpc_config().
The style is similar to GDScript's @rpc annotation, the macro can be used as follows: godot-rust#1 - Separate arguments: ```rust #[rpc(any_peer, reliable)] fn some_rpc(&mut self) { //.. } ``` Providing overlapping arguments generates a compile error. Any omitted arguments are set to their default values. godot-rust#2 - Provide an expression: ```rust const CONFIG: RpcArgs = RpcArgs { mode: RpcMode::Authority, ..RpcArgs::default() }; #[rpc(config = CONFIG_EXPR)] fn some_rpc(&mut self) { //.. } ``` Number godot-rust#2 is useful in case you want to reuse the configuration on multiple functions. Number godot-rust#2 is mutually exclusive with number godot-rust#1. --- The generated macro code works as follows: - Caches the configuration in a `ClassPlugin`. - On `__before_ready()`, searches for the configuration in the plugin, registering them with Node::rpc_config().
The style is similar to GDScript's @rpc annotation, the macro can be used as follows: godot-rust#1 - Separate arguments: ```rust #[rpc(any_peer, reliable)] fn some_rpc(&mut self) { //.. } ``` Providing overlapping arguments generates a compile error. Any omitted arguments are set to their default values. godot-rust#2 - Provide an expression: ```rust const CONFIG: RpcArgs = RpcArgs { mode: RpcMode::Authority, ..RpcArgs::default() }; #[rpc(config = CONFIG_EXPR)] fn some_rpc(&mut self) { //.. } ``` Number godot-rust#2 is useful in case you want to reuse the configuration on multiple functions. Number godot-rust#2 is mutually exclusive with number godot-rust#1. --- The generated macro code works as follows: - Caches the configuration in a `ClassPlugin`. - On `__before_ready()`, searches for the configuration in the plugin, registering them with Node::rpc_config().
The style is similar to GDScript's @rpc annotation, the macro can be used as follows: godot-rust#1 - Separate arguments: ```rust #[rpc(any_peer, reliable)] fn some_rpc(&mut self) { //.. } ``` Providing overlapping arguments generates a compile error. Any omitted arguments are set to their default values. godot-rust#2 - Provide an expression: ```rust const CONFIG: RpcArgs = RpcArgs { mode: RpcMode::Authority, ..RpcArgs::default() }; #[rpc(config = CONFIG_EXPR)] fn some_rpc(&mut self) { //.. } ``` Number godot-rust#2 is useful in case you want to reuse the configuration on multiple functions. Number godot-rust#2 is mutually exclusive with number godot-rust#1. --- The generated macro code works as follows: - Caches the configuration in a `ClassPlugin`. - On `__before_ready()`, searches for the configuration in the plugin, registering them with Node::rpc_config().
The style is similar to GDScript's @rpc annotation, the macro can be used as follows: godot-rust#1 - Separate arguments: ```rust #[rpc(any_peer, reliable)] fn some_rpc(&mut self) { //.. } ``` Providing overlapping arguments generates a compile error. Any omitted arguments are set to their default values. godot-rust#2 - Provide an expression: ```rust const CONFIG: RpcArgs = RpcArgs { mode: RpcMode::Authority, ..RpcArgs::default() }; #[rpc(config = CONFIG_EXPR)] fn some_rpc(&mut self) { //.. } ``` Number godot-rust#2 is useful in case you want to reuse the configuration on multiple functions. Number godot-rust#2 is mutually exclusive with number godot-rust#1. --- The generated macro code works as follows: - Caches the configuration in a `ClassPlugin`. - On `__before_ready()`, searches for the configuration in the plugin, registering them with Node::rpc_config().
Upstream issue: godotengine/godot#66231
On Windows, the Godot editor "locks" a DLL containing a GDExtension library and releases it only after shutdown. Native code can thus not be recompiled as long as the editor remains open. Behavior on Linux and Mac is unclear (please let me know about your experiences).
This is a considerable limitation for game developers using GDExtension. Requiring the user to reload the editor on every change not only makes a very common workflow impossible, but is also a regression from GDNative, where reloading (for non-tool classes) could be achieved while the editor was out of focus -- even if it had its bugs.
We depend on Godot to provide a mechanism that allows dynamic libraries to be recompiled. Even without a full-featured hot reloading, a bit part of the problem could be alleviated by using the recompiled dynamic library for the launched application (not in-editor).
The text was updated successfully, but these errors were encountered: