You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit e1d8310
Browse filesBrowse the repository at this point in the historyBrowse files
fix(skills): re-register driver functions on file load (#411)
driver_namespace is reset on every file load. The skill and snippet
registered the function only in register(), so the first file a user
opens evaluates the driver without it: NameError, the driver is disabled
(is_valid False), and it stays disabled even after the function is put
back. Measured on 4.5.11 and 5.2.1: z went from 2.4621 to 0.0 across a
save and reopen.
Both now re-register from a @Persistent load_post handler that also
resets driver.is_valid, with symmetric register/unregister. The skill's
compatibility table and common-mistakes list say why.
Closes#387
Signed-off-by: TMHSDigital <154358121+TMHSDigital@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The function name in `driver_namespace` must match the call in the expression. Register the function on add-on `register()` and remove it on `unregister()`:
117
+
The function name in `driver_namespace` must match the call in the expression.
118
+
119
+
`driver_namespace` is **reset on every file load**. Registering only in `register()` works until the user opens a file: the drivers then evaluate with the function missing, raise `NameError: name 'smooth_step' is not defined`, and are disabled (`driver.is_valid = False`). They stay disabled even after the function is added back. Re-register from a `@persistent``load_post` handler and re-enable the drivers there:
Extend the ID collections to wherever your add-on puts drivers (node groups, scenes, cameras). Measured on 4.5.11 and 5.2.1: without the handler, a saved and reopened file leaves the driver dead; with it, the driver evaluates again.
149
+
128
150
### Removing drivers
129
151
130
152
```python
@@ -263,6 +285,7 @@ The `exit_pre` handler list is new in Blender 5.1. On 4.5 LTS, fall back to OS-l
263
285
## Common AI mistakes
264
286
265
287
-**Calling Python functions in a driver expression without registering them.** Hits the security block. Either rewrite as math, or register via `bpy.app.driver_namespace`.
288
+
-**Registering a driver function only in `register()`.**`driver_namespace` is reset on file load, so the driver dies with `NameError` on the first file the user opens and stays disabled. Re-register and reset `driver.is_valid` from a `@persistent``load_post` handler.
266
289
-**Forgetting `@persistent` on handlers.** The handler vanishes on the next file load and the user thinks the add-on broke.
267
290
-**Doing real work inside `depsgraph_update_post`.** This handler fires on every depsgraph evaluation, which is many times per second during playback or interaction. Anything more than O(1) bookkeeping causes user-visible slowdown.
268
291
-**Recursively modifying the scene from a depsgraph handler.** The modification triggers another depsgraph evaluation, which calls the handler, which modifies the scene. Infinite loop, often manifesting as a hang.
@@ -276,7 +299,7 @@ The `exit_pre` handler list is new in Blender 5.1. On 4.5 LTS, fall back to OS-l
276
299
| --- | --- | --- |
277
300
|`exit_pre` handler | Not available | New in 5.1; use `atexit` fallback for 4.x |
278
301
|`save_pre` / `save_post` signature |`(filepath)` — a string |`(filepath)` — a string (unchanged) |
279
-
|`driver_namespace`| Available| Same |
302
+
|`driver_namespace`| Available; reset on file load | Same (re-register from `load_post`)|
0 commit comments