godotengine / godotengine/godot

Godot Editor forgets about GDExtension properties on extension reload, depending on the .gdextension file.

Open
#96,403 4 comments 0 reactions 0 assignees View on GitHub
bug topic:gdextension
Dominant language
C++
Stars
117k
Forks
26.8k
PR merge metrics
PR metrics pending

Description

### Tested versions

Reproducible in Godot 4.3.

### System information

Godot v4.3.stable - macOS 13.6.7 - Vulkan (Forward+) - dedicated AMD Radeon RX 6600 XT - 11th Gen Intel(R) Core(TM) i7-11700K @ 3.60GHz (16 Threads)

I have not tested 4.4-dev in-depth yet.

### Issue description

The format of the .gdextension file currently affects how 'well' the Godot editor is able to reload a GDExtension.
In the case that it is 'improperly' reloaded, the editor forgets about all properties / functions of the extension. Class names are retained. When the game is launched, it works as expected in all cases.

**Example of an error screen:**
```
--- Debugging process stopped ---
res://main.gd:6 - Parse Error: Static function "test_function()" not found in base "GDScriptNativeClass".
res://main.gd:6 - Parse Error: Static function "test_function()" not found in base "GDScriptNativeClass".
[...]
```

![SCR-20240831-suol](https://github.com/user-attachments/assets/fed2c3c4-23cd-4bf6-ad15-700f1234251b)
![SCR-20240831-suqj](https://github.com/user-attachments/assets/30c00496-fd43-4c06-8566-17758e1251b7)

### Cases

At this point, I am _reasonably_ sure I can properly categorize the behavior into 3 camps:

When pointing directly to a `.framework` bundle, in all cases the editor forgets about the properties after a single click. It probably reloads instantly and fails the reload:
```ini
# All these cases behave the same way:
macos/numdot.macos.template_debug.x86_64.framework
./macos/numdot.macos.template_debug.x86_64.framework
res://addons/numdot/macos/numdot.macos.template_debug.x86_64.framework
res://./addons/numdot/macos/numdot.macos.template_debug.x86_64.framework
```

When pointing to a binary directly, the editor retains knowledge of the properties until the binary is rebuild. Then, it fails the reload:
```ini
# All these cases behave the same way:
macos/numdot.macos.template_debug.x86_64.framework/numdot.macos.template_debug.x86_64
res://addons/numdot/macos/numdot.macos.template_debug.x86_64.framework/numdot.macos.template_debug.x86_64
macos/numdot.macos.template_debug.x86_64.dylib
res://addons/numdot/macos/numdot.macos.template_debug.x86_64.dylib
```

When pointing to the binary directly, using a path that starts with `./`, knowledge of the binary is retained. However, changes to the documentation are only reloaded when the editor is unfocused and focused again:
```ini
# These cases behave the same way:
./macos/numdot.macos.template_debug.x86_64.framework/numdot.macos.template_debug.x86_64
res://./addons/numdot/macos/numdot.macos.template_debug.x86_64.framework/numdot.macos.template_debug.x86_64
./macos/numdot.macos.template_debug.x86_64.dylib
res://./addons/numdot/macos/numdot.macos.template_debug.x86_64.dylib
```

### Steps to reproduce

1) Create a blank gdextension with https://github.com/godotengine/godot-cpp
2) Register a static method via `godot::ClassDB::bind_static_method("GDExample", D_METHOD("example_function"), &GDExample::example_function);`
3) Open the godot editor
4) Run the game
5) Observe the amnesia

### Minimal reproduction project (MRP)

https://github.com/Ivorforce/gdextension-staticmethod-amnesia

Contributor guide

Open the contributing guide

Research direction

Reproduce the issue with the linked gdextension-staticmethod-amnesia minimal project, following the listed .gdextension path cases and reload steps. Since no Godot source file or test is named, trace the editor's GDExtension reload handling and verify that properties and static functions remain available after extension and binary rebuilds.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
game-dev
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.