MigCustProps debug and extra handling
This commit is contained in:
Nathan
@@ -11861,8 +11861,6 @@ Let me search for Gitea workflow files in the AmazonCharacterTools project.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="generic" data-tool-name="glob_file_search">
|
||||
@@ -11906,8 +11904,6 @@ Found the Gitea workflow and docker-compose in AmazonCharacterTools. Let me read
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="read" data-tool-name="read_file_v2">
|
||||
@@ -11981,7 +11977,6 @@ Let me check Dynamic-Link-Manager structure for dirs and top-level files.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Checking Dynamic-Link-Manager layout to match the zip structure:
|
||||
|
||||
|
||||
@@ -12053,7 +12048,6 @@ Creating the workflow and the docker-compose. For docker-compose I'll mirror the
|
||||
|
||||
---
|
||||
|
||||
|
||||
Adding `.gitea/workflows/release.yml` and `.gitea/docker-compose.runner.yml` to mirror AmazonCharacterTools.
|
||||
|
||||
|
||||
@@ -12086,8 +12080,6 @@ I'll add a docker-compose.runner.yml that mirrors the structure but is clearly f
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="write" data-tool-name="edit_file_v2">
|
||||
@@ -12111,7 +12103,6 @@ No need to run linters on YAML. I'll summarize for the user.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Summary of what was added to mirror your AMZNCharacterTools setup:
|
||||
|
||||
**1. `.gitea/workflows/release.yml`**
|
||||
@@ -12154,8 +12145,6 @@ I need to:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="read" data-tool-name="read_file_v2">
|
||||
@@ -12206,8 +12195,6 @@ PowerShell doesn't use `cd /d`. I need to use Set-Location or cd without /d. Als
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="shell" data-tool-name="run_terminal_command_v2">
|
||||
@@ -12258,3 +12245,861 @@ redefine and fix migrate basebody shapkeys
|
||||
|
||||
---
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
No CHANGELOG exists - I'll create CHANGELOG.md. I'll bump version to 0.1.0 in blender_manifest.toml and write a concise changelog summarizing these 9 commits in a standard format (e.g. Keep a Changelog style).
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="write" data-tool-name="edit_file_v2">
|
||||
|
||||
<details><summary>Tool use: **edit_file_v2** • Edit file: T:\Dynamic-Link-Manager\blender_manifest.toml</summary>
|
||||
|
||||
</details>
|
||||
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="write" data-tool-name="edit_file_v2">
|
||||
|
||||
<details><summary>Tool use: **edit_file_v2** • Edit file: T:\Dynamic-Link-Manager\CHANGELOG.md</summary>
|
||||
|
||||
</details>
|
||||
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
Done. I bumped version to 0.1.0 and created CHANGELOG.md with a concise summary of the 9 commits grouped into Added/Changed/Fixed. The date I used is 2026-02-19 from the user_info. I didn't add a link for [0.1.0] since there's no release yet; the user can add comparison links later if they want.
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
Summary of changes:
|
||||
|
||||
**Version**
|
||||
- `blender_manifest.toml`: `version` set from `0.0.2` to `0.1.0`.
|
||||
|
||||
**CHANGELOG.md**
|
||||
- New file, format similar to Keep a Changelog.
|
||||
- **Added:** Gitea workflow/runner, tweak tools (arms/legs/both), MigNLA action-slot copy and debug, NLAMig AnimLayers and strip timing, operator icons, BaseBody shape-key slot/original preference and override.
|
||||
- **Changed:** Canonical operator labels and docs, BaseBody step rework, shorter button labels.
|
||||
- **Fixed:** BaseBody lib override, value copy, and original/slot lookup.
|
||||
|
||||
Entries are grouped by type (Added/Changed/Fixed) rather than by commit. If you want a different date or link for `[0.1.0]`, say how you’d like it.
|
||||
|
||||
---
|
||||
|
||||
_**User**_
|
||||
|
||||
MigCustProps does not migrate the settings of properties like bpy.data.objects["Kennedy"].pose.bones["Settings"]["Devices"]. The point of the operator is to copy the overridden settings from one rig to another, including IK/FK switches, so that they match.
|
||||
|
||||
---
|
||||
|
||||
_**Agent (model default, mode Agent)**_
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
The user is saying that MigCustProps (the custom properties migration step) doesn't migrate settings like `bpy.data.objects["Kennedy"].pose.bones["Settings"]["Devices"]`. These appear to be nested/custom property structures - not just simple key-value pairs on the bone, but possibly ID properties or nested property groups (e.g. "Devices" could be a property group with sub-properties).
|
||||
|
||||
The goal is to copy "overridden settings" from one rig to another, including things like IK/FK switches, so both rigs match.
|
||||
|
||||
Let me look at the current MigCustProps implementation to understand what it copies and what it might be missing.
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="unknown" data-tool-name="ripgrep_raw_search">
|
||||
<details>
|
||||
<summary>Tool use: **ripgrep_raw_search**</summary>
|
||||
|
||||
|
||||
Parameters:
|
||||
|
||||
```json
|
||||
{
|
||||
"pattern": "run_mig_cust_props|MigCustProps|custom.propert",
|
||||
"path": "T:\\Dynamic-Link-Manager",
|
||||
"caseInsensitive": false
|
||||
}
|
||||
```
|
||||
Additional data:
|
||||
|
||||
```json
|
||||
{
|
||||
"isPruned": true,
|
||||
"pattern": "run_mig_cust_props|MigCustProps|custom.propert",
|
||||
"path": "T:\\Dynamic-Link-Manager",
|
||||
"outputMode": "content",
|
||||
"totalFiles": 5,
|
||||
"totalMatches": 57,
|
||||
"topFiles": [
|
||||
{
|
||||
"uri": "ui/panels.py",
|
||||
"matchCount": 1
|
||||
},
|
||||
{
|
||||
"uri": "ops/migrator.py",
|
||||
"matchCount": 2
|
||||
},
|
||||
{
|
||||
"uri": "CHANGELOG.md",
|
||||
"matchCount": 1
|
||||
},
|
||||
{
|
||||
"uri": "ui/operators.py",
|
||||
"matchCount": 10
|
||||
},
|
||||
{
|
||||
"uri": ".specstory/history/2026-02-18_23-39Z-character-migrator-workflow-integration.md",
|
||||
"matchCount": 43
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
Status: **completed**
|
||||
|
||||
|
||||
</details>
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="read" data-tool-name="read_file_v2">
|
||||
<details><summary>Tool use: **read_file_v2** • Read file: T:\Dynamic-Link-Manager\ops\migrator.py</summary>
|
||||
|
||||
</details>
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
I need to read the full run_mig_cust_props function to see what it currently does - it likely only copies top-level id_properties and skips nested structures like ["Devices"] which might be ID property groups or RNA/UI-defined nested properties.
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="read" data-tool-name="read_file_v2">
|
||||
<details><summary>Tool use: **read_file_v2** • Read file: T:\Dynamic-Link-Manager\ops\migrator.py</summary>
|
||||
|
||||
</details>
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
The current code does:
|
||||
```python
|
||||
for key in list(pbone.keys()):
|
||||
if key in EXCLUDE_PROPS:
|
||||
continue
|
||||
try:
|
||||
rbone[key] = pbone[key]
|
||||
except Exception:
|
||||
pass
|
||||
```
|
||||
|
||||
So it only copies top-level keys from the pose bone's id_properties (the `[]` accessor). When the user says `pose.bones["Settings"]["Devices"]`, "Devices" might be:
|
||||
1. A nested id property (a group/dict-like structure) - in Blender ID properties can be nested; you get them via `pbone["Settings"]` which might return an IDProperty group that has a "Devices" sub-key.
|
||||
2. Or "Settings" is the bone name and ["Devices"] is a key on that bone - so it's `pose.bones["Settings"]["Devices"]` = one key "Devices" on the Settings bone. So we do copy pbone[key] for key in pbone.keys(). So "Devices" would be copied if it's a direct key. Unless "Devices" is not a direct key but a nested structure - i.e. the value at pbone["Devices"] might be an IDPropertyGroup and we're doing a shallow copy (reference) and the rep rig might need a deep copy of the group's contents. Or the issue is that pbone["Settings"] exists and is a property group, and we copy it with rbone["Settings"] = pbone["Settings"] - but that might copy by reference or might not copy nested overrides.
|
||||
|
||||
Let me search for how Blender ID properties work with nested groups - in Blender, id_properties can be IDPropertyGroup (nested). When you assign rbone["Settings"] = pbone["Settings"], you might be copying a reference, or Blender might not allow assigning a group from another data-block. So we likely need to recursively copy ID property groups: for each key, if the value is an IDPropertyGroup (or dict-like with .keys()), iterate and copy sub-properties; otherwise assign the value.
|
||||
|
||||
I'll need to use Blender's ID property API. In Blender:
|
||||
- `obj.keys()` gives top-level key names
|
||||
- `obj["key"]` can be a value or an IDPropertyGroup
|
||||
- To copy a group we may need to clear the rep's group and copy item by item, or use a recursive approach
|
||||
|
||||
Checking Blender API for id_properties - we have id_properties_clear(), id_properties_ensure(). For copying nested: we can iterate with .items() or .keys() and for each value check if it's a "group" (has .keys() or is IDPropertyGroup) and recurse.
|
||||
|
||||
Let me look up how to deep-copy ID properties in Blender. Actually in Blender 4.x, IDPropertyGroup values might support .keys() and iteration. So the approach:
|
||||
1. For each key on orig pose bone (and optionally on orig armature object):
|
||||
2. If key in EXCLUDE_PROPS, skip
|
||||
3. val = orig[key]
|
||||
4. If val is a group (has 'keys' and not a string): recursively set rep[key] to a new group or clear and copy each sub-key
|
||||
5. Else: rep[key] = val
|
||||
|
||||
We also need to copy from the armature object, not just pose bones - the user said "settings of properties" and "IK/FK switches". Rigify often puts settings on a "Settings" bone. So pose.bones["Settings"]["Devices"] means bone named "Settings" has a custom property "Devices". So we're already iterating pose bones. The issue is that when we do rbone["Devices"] = pbone["Devices"], if "Devices" is an IDPropertyGroup (nested), the assignment might fail or only do a shallow copy. So we need recursive copy for nested ID properties.
|
||||
|
||||
Let me also copy from the armature object (orig/rep) not just pose bones - the spec said "copy the overridden settings from one rig to another". So object-level custom props too.
|
||||
|
||||
Implementation plan:
|
||||
1. Add a helper that deep-copies one id property value to another (handling IDPropertyGroup by recursing).
|
||||
2. In run_mig_cust_props: copy object-level custom props (orig -> rep) for the armature object, then for each pose bone copy all keys (with recursive copy for groups).
|
||||
3. EXCLUDE_PROPS stays.
|
||||
|
||||
Blender IDPropertyGroup: in bpy, when you do group = obj["key"] and group is a group, you can do group.keys(), group["subkey"] = value. To copy we'd do:
|
||||
for k in orig_group.keys():
|
||||
if hasattr(orig_group[k], 'keys') and callable(getattr(orig_group[k], 'keys')) and orig_group[k] is not None and not isinstance(orig_group[k], str):
|
||||
# nested group - ensure rep has group and recurse
|
||||
if k not in rep_group:
|
||||
rep_group[k] = {} # might need Blender API to add empty group
|
||||
copy_id_prop_recursive(orig_group[k], rep_group[k])
|
||||
else:
|
||||
rep_group[k] = orig_group[k]
|
||||
|
||||
Actually in Blender, you don't create an empty group with `rep_group[k] = {}` - you might need to use id_properties_ensure or the group might be created when you assign the first sub-item. Let me check - in Blender Python, idprop.types might have something. Actually the standard approach is: when copying a nested group, you iterate the source and set each key on the destination. If the destination key doesn't exist, setting rep_group[k] = value might auto-create it. If value is a group, we need to ensure rep_group has a group at k - in Blender, rep_group[k] = {} might create an IDPropertyGroup. I'll try:
|
||||
try:
|
||||
for k in orig_group.keys():
|
||||
v = orig_group[k]
|
||||
if hasattr(v, 'keys') and callable(v.keys) and not isinstance(v, (str, bytes)):
|
||||
if k not in rep_group:
|
||||
rep_group[k] = {}
|
||||
copy_id_prop_recursive(v, rep_group[k])
|
||||
else:
|
||||
rep_group[k] = v
|
||||
except Exception:
|
||||
pass
|
||||
|
||||
We need to handle the case where rep_group[k] already exists and is a group - then we recurse into it. So:
|
||||
def copy_id_prop_recursive(orig_val, rep_parent, rep_key):
|
||||
# rep_parent[rep_key] = copy of orig_val
|
||||
if orig_val is None:
|
||||
return
|
||||
if hasattr(orig_val, 'keys') and callable(getattr(orig_val, 'keys')) and not isinstance(orig_val, (str, bytes)):
|
||||
# It's a group
|
||||
if rep_key not in rep_parent:
|
||||
rep_parent[rep_key] = {} # Blender might accept this for new group
|
||||
rep_group = rep_parent[rep_key]
|
||||
for k in orig_val.keys():
|
||||
copy_id_prop_recursive(orig_val[k], rep_group, k)
|
||||
else:
|
||||
rep_parent[rep_key] = orig_val
|
||||
|
||||
Actually we're copying from one bone to another, so we have orig_bone and rep_bone. For each key in orig_bone:
|
||||
copy_id_prop_recursive(orig_bone[key], rep_bone, key)
|
||||
|
||||
So the signature could be: copy_id_prop_value(orig_val, rep_container, key) where we set rep_container[key] = copy of orig_val (recursively if group).
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
Checking how Blender exposes nested ID properties (e.g. property groups):
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="search" data-tool-name="web_search">
|
||||
<details>
|
||||
<summary>Tool use: **web_search** • Searched web `undefined` • **1** results</summary>
|
||||
|
||||
| Title | URL | Chunk |
|
||||
|-------|-----|-------|
|
||||
| Web search results for query: Blender Python IDPropertyGroup nested copy id_properties | | Links:<br/>1. [Add Custom Properties using Python](https://blender.stackexchange.com/questions/282242/add-custom-properties-using-python)<br/>2. [IDPropertyGroup(bpy_struct) — Blender v2.54 - UNSTABLE API documentation](https://docs.blender.org/api/blender_python_api_2_54_0/bpy.types.IDPropertyGroup.html)<br/>3. [Class IDGroup](https://docs.blender.org/api/248PythonDoc/IDProp.IDGroup-class.html)<br/>4. [Cannot assign dictionary to existing IdPropertyGroup](https://projects.blender.org/blender/blender/issues/126599)<br/>5. [Deep Dive into Blender's ID Properties](https://renderday.com/blog/deep-dive-into-blenders-id-properties)<br/><br/># Blender Python IDPropertyGroup: Nested Copy and id_properties<br/><br/>## Key Information on IDPropertyGroup<br/><br/>IDPropertyGroup is a Blender type that represents a group (dictionary) of ID properties.[2] It serves as a container for custom properties that can be attached to data-blocks like objects, scenes, and meshes.[5]<br/><br/>## Working with Nested Properties<br/><br/>ID properties support nested structures. You can create subgroups within property groups using dictionary syntax:[3]<br/><br/>```python<br/>group['a subgroup'] = \{"float": 0.0, "an int": 1.0, "an array": [1, 2],<br/>"another subgroup": \{"a": 0.0, "str": "bleh"\}}<br/>```<br/><br/>This allows for hierarchical organization of custom properties.[3]<br/><br/>## Copying Nested IDPropertyGroups<br/><br/>**Important Limitation:** There is a known issue with copying nested IDPropertyGroups. You cannot directly assign a dictionary to an existing IDPropertyGroup using the `update()` method if it contains nested group properties.[4] For example:<br/><br/>```python<br/>d = C.scene['cycles'].to_dict()<br/>C.scene['cycles'].update(d) # Raises: TypeError: Cannot assign a 'dict' value to the existing 'dicing_camera' Group IDProperty<br/>```<br/><br/>This limitation exists because IDPropertyGroups are now statically typed in recent Blender versions, preventing direct dictionary assignment to existing nested group properties.[4]<br/><br/>## Accessing Properties<br/><br/>Custom properties can be accessed via bracket notation on data-blocks or their data objects, and support iteration and dictionary-like operations including `keys()`, `values()`, `pop()`, and `update()` methods.[3] |
|
||||
|
||||
</details>
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
So we can use .to_dict() to get a (possibly nested) dict and then we need to set values recursively. The issue is "Cannot assign a 'dict' value to the existing ... Group IDProperty" - so we can't just rep_group.update(orig_dict). We need to set leaf values one by one. So:
|
||||
1. Get orig value
|
||||
2. If it's a group (has .keys() or is IDPropertyGroup), for each key in orig, recursively set rep[key] = copy(orig[key]). When setting rep[key], if it's a nested group we might need to create the group first - in Blender, rep[key] = {} might create an empty group, then we fill it.
|
||||
3. If it's a leaf (int, float, string, etc.), rep[key] = orig_val
|
||||
|
||||
Let me try a recursive approach that only assigns leaf values when we're at a group, and for groups we do:
|
||||
- if key not in rep or rep[key] is not a group: rep[key] = {} (or get empty group)
|
||||
- then for each k in orig.keys(): recurse copy(orig[k], rep[k])
|
||||
|
||||
Actually the safe way is: for each key in orig, get the value. If the value has .keys() (is a group), then we need rep[key] to be a group - so try rep[key] = {} to create one if needed, then recurse. If the value is a leaf, rep[key] = value.
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
Error fetching URL, status code: 404 Not Found
|
||||
|
||||
---
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
Let me try IDProperty in the API or search for to_dict.
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="unknown" data-tool-name="ripgrep_raw_search">
|
||||
<details>
|
||||
<summary>Tool use: **ripgrep_raw_search**</summary>
|
||||
|
||||
|
||||
Parameters:
|
||||
|
||||
```json
|
||||
{
|
||||
"pattern": "to_dict|\\.keys\\(\\)|id_propert",
|
||||
"path": "T:\\Dynamic-Link-Manager",
|
||||
"caseInsensitive": false
|
||||
}
|
||||
```
|
||||
Additional data:
|
||||
|
||||
```json
|
||||
{
|
||||
"isPruned": true,
|
||||
"pattern": "to_dict|\\.keys\\(\\)|id_propert",
|
||||
"path": "T:\\Dynamic-Link-Manager",
|
||||
"outputMode": "content",
|
||||
"totalFiles": 4,
|
||||
"totalMatches": 16,
|
||||
"topFiles": [
|
||||
{
|
||||
"uri": ".specstory\\history\\2026-02-18_23-39Z-character-migrator-workflow-integration.md",
|
||||
"matchCount": 7
|
||||
},
|
||||
{
|
||||
"uri": "ops/migrator.py",
|
||||
"matchCount": 1
|
||||
},
|
||||
{
|
||||
"uri": ".specstory/history/2026-02-18_23-39Z-character-migrator-workflow-integration.md",
|
||||
"matchCount": 7
|
||||
},
|
||||
{
|
||||
"uri": ".specstory/history/2026-02-19_18-53Z-blendfile-local-datablocks-analysis.md",
|
||||
"matchCount": 1
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
Status: **completed**
|
||||
|
||||
|
||||
</details>
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
I'll implement a recursive copy. In Blender, ID properties that are groups can be detected by checking if the value has a .keys() method (and isn't a string). When we copy a group we need to set each sub-key. If the sub-value is also a group, we may need to create an empty group on the rep side - in Blender, assigning an empty dict might work: rep_container[key] = {}. Let me implement and use try/except for robustness. I'll also copy object-level (armature) custom props so that any settings on the armature object are migrated too.
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
Implementing recursive copy of nested ID property groups and copying armature-level custom props.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="write" data-tool-name="edit_file_v2">
|
||||
|
||||
<details><summary>Tool use: **edit_file_v2** • Edit file: T:\Dynamic-Link-Manager\ops\migrator.py</summary>
|
||||
|
||||
</details>
|
||||
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
Done. I've:
|
||||
1. Added _is_id_prop_group(val) to detect nested ID property groups (has .keys() and isn't str/bytes).
|
||||
2. Added _copy_id_prop_recursive(orig_container, rep_container, key) that copies one key: if the value is a group, ensure rep has a group at that key (rep_container[key] = {}) then recurse for each sub-key; else assign the leaf value.
|
||||
3. Added _copy_custom_props_from(orig_obj, rep_obj) that iterates keys (excluding EXCLUDE_PROPS) and calls _copy_id_prop_recursive for each.
|
||||
4. run_mig_cust_props now: copies armature object-level custom props first, then for each matching pose bone copies all custom props (including nested like ["Devices"] under ["Settings"]).
|
||||
|
||||
Let me verify there are no linter errors.
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="unknown" data-tool-name="read_lints">
|
||||
<details>
|
||||
<summary>Tool use: **read_lints**</summary>
|
||||
|
||||
|
||||
Parameters:
|
||||
|
||||
```json
|
||||
{
|
||||
"paths": [
|
||||
"T:\\Dynamic-Link-Manager\\ops\\migrator.py"
|
||||
]
|
||||
}
|
||||
```
|
||||
Result:
|
||||
|
||||
```json
|
||||
{
|
||||
"linterErrorsByFile": [
|
||||
{
|
||||
"relativeWorkspacePath": "T:\\Dynamic-Link-Manager\\ops\\migrator.py"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
Status: **completed**
|
||||
|
||||
|
||||
</details>
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
Good. One potential issue: in Blender, creating an empty group with rep_container[key] = {} might not work on all versions - some might require a different API. If the rep already has a group at that key (e.g. from the linked rig), we just recurse into it. If it doesn't, we try rep_container[key] = {}. If that fails, we could fall back to only copying leaf values when the rep already has the same structure. The try/except will swallow errors. If the user reports that nested groups still don't copy, we might need to use id_properties_ensure or a different method. For now this should handle the common case.
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
Summary of changes:
|
||||
|
||||
**1. Nested ID property groups**
|
||||
- **`_is_id_prop_group(val)`** – Treats a value as a group if it has a `.keys()` and is not a string/bytes.
|
||||
- **`_copy_id_prop_recursive(orig_container, rep_container, key)`** – For each key, if the value is a group it ensures `rep_container[key]` exists (as `{}` if needed), then recurses. Otherwise it does a direct assign so values like IK/FK and nested settings (e.g. `Settings` → `Devices`) are copied.
|
||||
|
||||
**2. Armature object custom props**
|
||||
- Custom properties on the armature object are copied first (e.g. `orig["..."]` → `rep["..."]`), then per–pose bone props as before.
|
||||
|
||||
**3. Single entry point**
|
||||
- **`_copy_custom_props_from(orig_obj, rep_obj)`** – Runs over all keys (still skipping `_RNA_UI`, `rigify_type`, `rigify_parameters`) and uses the recursive copy for each.
|
||||
|
||||
So for something like `pose.bones["Settings"]["Devices"]`, the code now copies the whole `Settings` group (including `Devices` and any other nested keys) from the original to the replacement, so overridden settings and IK/FK switches are migrated. Reload the add-on and run MigCustProps again to test.
|
||||
|
||||
---
|
||||
|
||||
_**User**_
|
||||
|
||||
@c:\Users\Nathan\.cursor\projects\t-Dynamic-Link-Manager\terminals\3.txt still didn't work.
|
||||
|
||||
---
|
||||
|
||||
_**Agent (model default, mode Agent)**_
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
The user says MigCustProps still didn't work - the nested settings like pose.bones["Settings"]["Devices"] are still not being copied. Let me read the terminal to see if there are any error messages or debug output, and then investigate how Blender's ID properties work for nested groups - maybe we need a different approach (e.g. to_dict() and then set leaf values, or use a different API).
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="read" data-tool-name="read_file_v2">
|
||||
<details><summary>Tool use: **read_file_v2** • Read file: c:\Users\Nathan\.cursor\projects\t-Dynamic-Link-Manager\terminals\3.txt</summary>
|
||||
|
||||
</details>
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="read" data-tool-name="read_file_v2">
|
||||
<details><summary>Tool use: **read_file_v2** • Read file: T:\Dynamic-Link-Manager\ops\migrator.py</summary>
|
||||
|
||||
</details>
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
The terminal doesn't show any Python errors from our code - "Custom properties done." runs. So the issue might be:
|
||||
|
||||
1. **RNA/registered properties, not ID properties**: The user said `bpy.data.objects["Kennedy"].pose.bones["Settings"]["Devices"]`. In Rigify/addons, "Settings" and "Devices" might not be id_properties (the bracket `[]` custom props) but **RNA properties** - i.e. registered PropertyGroup on the pose bone. So they'd be accessed as `pose.bones["Settings"].Devices` (attribute) or via `bl_rna.properties`. Our code only copies `obj.keys()` which are ID properties. If "Devices" is an RNA property (e.g. a BooleanProperty or EnumProperty on a PropertyGroup), it won't be in `.keys()`.
|
||||
|
||||
2. **Path is different**: Maybe the structure is `pose.bones["Settings"]` has a property group with a sub-property `Devices` - so it's RNA: `pose.bones["Settings"].get("Devices")` might not work; it could be `pose.bones["Settings"].devices` or part of the rig's registered properties.
|
||||
|
||||
So we need to also copy **RNA properties** from the pose bones (and possibly the armature object) - i.e. iterate over `bl_rna.properties` or the properties that are on the data-block and copy their values. The challenge is that RNA properties are defined by the addon (Rigify, etc.) and we don't know the exact structure. We can try:
|
||||
- For each pose bone and the armature object: iterate over `item.bl_rna.properties` and for each property that is not read-only and is not the default "rna_type" etc., get the value from orig and set it on rep. But we must skip ID block references (pointers) that point to the orig armature or its bones.
|
||||
- Or use a more generic approach: copy all properties from orig to rep that exist on both and are writable.
|
||||
|
||||
Let me search for how Rigify stores Settings/Devices - it might be a PropertyGroup on the bone.
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
Checking whether "Settings"/"Devices" are RNA (registered) properties rather than ID properties — they wouldn't appear in `.keys()`.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="search" data-tool-name="web_search">
|
||||
<details>
|
||||
<summary>Tool use: **web_search** • Searched web `undefined` • **1** results</summary>
|
||||
|
||||
| Title | URL | Chunk |
|
||||
|-------|-----|-------|
|
||||
| Web search results for query: Blender Rigify Settings bone PropertyGroup RNA properties pose bone | | Links:<br/>1. [Rigify - Blender 5.0 Manual](https://docs.blender.org/manual/en/latest/addons/rigging/rigify/index.html)<br/>2. [Implementing a Rig ¶](https://developer.blender.org/docs/features/animation/rigify/rig_class/)<br/>3. [UI Script Generator - Blender Developer Documentation](https://developer.blender.org/docs/features/animation/rigify/script_generator)<br/>4. [Bone Utilities (rigify.utils.bones) ¶](https://developer.blender.org/docs/features/animation/rigify/utils/bones/)<br/>5. [Mechanism Utilities (rigify.utils.mechanism) ¶](https://developer.blender.org/docs/features/animation/rigify/utils/mechanism/)<br/><br/># Rigify Settings and Bone Properties in Blender<br/><br/>## Parameter Properties<br/><br/>Rigify rig components access configuration through a `params` field, which is a parameter property collection for each rig component.[2] These parameters are typically defined as PropertyGroup RNA properties that customize the behavior of individual rig types.<br/><br/>## Pose Bone Properties<br/><br/>When working with pose bones in Rigify, the `BaseRig` class is initialized with a `pose_bone` parameter.[2] The framework provides utilities to access and manipulate pose bone properties:<br/><br/>- `get_bone(name)` returns either a `PoseBone` or `EditBone` depending on the current mode[2][4]<br/>- `copy_bone_properties()` copies pose mode properties from one bone to another, including rotation mode, locks, and custom properties[4]<br/><br/>## Custom Properties<br/><br/>Rigify provides mechanisms for creating and managing custom properties on bones:[5]<br/><br/>- `make_property()` creates custom properties with configurable ranges, defaults, and descriptions<br/>- `copy_custom_properties()` transfers properties between objects with optional driver linking<br/>- `copy_custom_properties_with_ui()` copies properties and automatically generates UI panel entries<br/><br/>## Bone Storage<br/><br/>The `bones` field uses a `BoneDict` dictionary structure that allows attribute-style access to bone names, storing them organized by type (ORG, CTRL, MCH, DEF).[2][4] This enables structured management of the various bone categories generated during rig creation. |
|
||||
|
||||
</details>
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="search" data-tool-name="web_search">
|
||||
<details>
|
||||
<summary>Tool use: **web_search** • Searched web `undefined` • **1** results</summary>
|
||||
|
||||
| Title | URL | Chunk |
|
||||
|-------|-----|-------|
|
||||
| Web search results for query: Blender Python copy all properties from one object to another bl_rna.properties | | Links:<br/>1. [Copy Custom Properties from one object to another](https://blender.stackexchange.com/questions/24001/copy-custom-properties-from-one-object-to-another/24004)<br/>2. [Add Custom Properties using Python](https://blender.stackexchange.com/questions/282242/add-custom-properties-using-python)<br/>3. [The Object object](https://docs.blender.org/api/236PythonDoc/Object.Object-class.html)<br/>4. [How do I copy a property from an active object to selected objects?](https://blender.stackexchange.com/questions/1177/how-do-i-copy-a-property-from-an-active-object-to-selected-objects)<br/>5. [Timeline for answer to Copy Custom Properties from one object to another by CodeManX](https://blender.stackexchange.com/posts/24004/timeline)<br/><br/># Copying Properties in Blender Python<br/><br/>## Custom Properties<br/><br/>To copy custom properties from one object to another using `bl_rna.properties`, access the `_RNA_UI` metadata:[1]<br/><br/>```python<br/>import bpy<br/><br/>source_obj = bpy.context.object<br/>target_objs = bpy.context.selected_editable_objects<br/><br/>try:<br/> props = source_obj["_RNA_UI"]<br/>except KeyError:<br/> pass<br/>else:<br/> for obj in target_objs:<br/> if obj == source_obj:<br/> continue<br/> for prop in props.keys():<br/> obj[prop] = source_obj[prop]<br/>```<br/><br/>The `_RNA_UI` dictionary contains metadata about custom properties. You must catch `KeyError` because `_RNA_UI` doesn't exist until custom properties are created.[1]<br/><br/>Alternatively, iterate directly over `Object.keys()`, though this may copy additional API-defined properties like `cycles_visibility`.[1]<br/><br/>## UI Methods<br/><br/>For individual properties in the Properties panel, you can:[4]<br/>- **Right-click** a property and select **Copy To Selected**<br/>- **Alt+click** a property to update it across all selected objects simultaneously<br/><br/>## Legacy API<br/><br/>The older Blender Python API included a `copyAllPropertiesTo()` method on Object classes,[3] though this approach is not available in modern Blender versions. |
|
||||
|
||||
</details>
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
So Rigify uses PropertyGroup RNA properties. The user's path `pose.bones["Settings"]["Devices"]` - in Blender, if "Settings" is a bone name and "Devices" is a custom property on that bone, then `["Devices"]` would be id_properties. But if "Devices" is a nested group, we handle that. The issue might be that in Blender 5 / Rigify, these could be **RNA properties** on the bone - i.e. the bone has a PropertyGroup that has a "Devices" attribute. So we'd need to copy via getattr/setattr for properties that exist on the type.
|
||||
|
||||
Let me try adding RNA property copying: for pose bones and the armature object, iterate over `bl_rna.properties` and for each property that is readable and writable and not a pointer to an ID that we shouldn't copy, copy the value. We need to be careful:
|
||||
- Skip `rna_type` and other internal props
|
||||
- For pointer properties, we might need to skip or retarget (e.g. if it points to the orig armature)
|
||||
- For nested PropertyGroups, we need to recurse
|
||||
|
||||
Actually in Blender, when you have a PropertyGroup on a bone, you access it as bone["Settings"] if it's an id property, or bone.settings if it's RNA. The user explicitly said bone["Settings"]["Devices"] - so they're using bracket notation. That could mean:
|
||||
1. ID property "Settings" which is a group containing "Devices" - we handle that
|
||||
2. Or it could be that in Blender Python, bone["Settings"] returns something that also supports ["Devices"] - so Settings might be an ID property group with a key "Devices". So our recursive copy should work unless rep_container[key] = {} fails to create a new group on the rep (e.g. Blender doesn't allow assigning a plain dict).
|
||||
|
||||
Let me check - in Blender, when you do rep_bone["Settings"] = {}, does it create an IDPropertyGroup? Or do we need to use idprop.types to create a group? I'll search for that.
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="search" data-tool-name="web_search">
|
||||
<details>
|
||||
<summary>Tool use: **web_search** • Searched web `undefined` • **1** results</summary>
|
||||
|
||||
| Title | URL | Chunk |
|
||||
|-------|-----|-------|
|
||||
| Web search results for query: Blender Python idprop create IDPropertyGroup assign empty group pose bone | | Links:<br/>1. [Class IDGroup](https://docs.blender.org/api/246PythonDoc/IDProp.IDGroup-class.html)<br/>2. [PropertyGroup(bpy_struct) ¶](https://docs.blender.org/api/current/bpy.types.PropertyGroup.html)<br/>3. [ID Property Access (idprop.types) ¶](https://docs.blender.org/api/blender_python_api_2_78_release/idprop.types.html)<br/>4. [Deep Dive into Blender's ID Properties](https://renderday.com/blog/deep-dive-into-blenders-id-properties)<br/>5. [IDPropertyGroup(bpy_struct) — Blender v2.54 - UNSTABLE API documentation](https://docs.blender.org/api/blender_python_api_2_54_0/bpy.types.IDPropertyGroup.html)<br/><br/># Creating Empty IDPropertyGroups on Pose Bones in Blender Python<br/><br/>To create an empty IDPropertyGroup and assign it to a pose bone, you can use dictionary-style syntax on the bone's ID properties.[1][3]<br/><br/>## Basic Approach<br/><br/>You can create an empty group by assigning an empty dictionary to a pose bone's custom properties:[1]<br/><br/>```python<br/>pose_bone['my_group'] = \{}<br/>```<br/><br/>This creates an empty IDPropertyGroup that you can then populate with additional properties.<br/><br/>## Working with IDPropertyGroups<br/><br/>Once created, IDPropertyGroups support standard dictionary-like operations:[3]<br/><br/>- **Add properties**: `group['property_name'] = value`<br/>- **Access properties**: `value = group['property_name']`<br/>- **Clear all members**: `group.clear()`<br/>- **Get keys/values**: `group.keys()`, `group.values()`<br/>- **Update**: `group.update(other_dict)` or `group.update(other_group)`<br/><br/>## Example with Pose Bones<br/><br/>```python<br/># Get a pose bone<br/>pose_bone = armature.pose.bones['bone_name']<br/><br/># Create an empty IDPropertyGroup<br/>pose_bone['custom_group'] = \{}<br/><br/># Add properties to it<br/>pose_bone['custom_group']['float_prop'] = 1.5<br/>pose_bone['custom_group']['int_prop'] = 42<br/>```<br/><br/>IDPropertyGroups can also contain nested groups by assigning dictionaries with nested dictionary values.[1] |
|
||||
|
||||
</details>
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="unknown" data-tool-name="ripgrep_raw_search">
|
||||
<details>
|
||||
<summary>Tool use: **ripgrep_raw_search**</summary>
|
||||
|
||||
|
||||
Parameters:
|
||||
|
||||
```json
|
||||
{
|
||||
"pattern": "idprop|IDProperty",
|
||||
"path": "T:\\Dynamic-Link-Manager",
|
||||
"caseInsensitive": false
|
||||
}
|
||||
```
|
||||
Additional data:
|
||||
|
||||
```json
|
||||
{
|
||||
"isPruned": true,
|
||||
"pattern": "idprop|IDProperty",
|
||||
"path": "T:\\Dynamic-Link-Manager",
|
||||
"outputMode": "content",
|
||||
"totalFiles": 1,
|
||||
"totalMatches": 14,
|
||||
"topFiles": [
|
||||
{
|
||||
"uri": ".specstory\\history\\2026-02-18_23-39Z-character-migrator-workflow-integration.md",
|
||||
"matchCount": 14
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
Status: **completed**
|
||||
|
||||
|
||||
</details>
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
So assigning rep_container[key] = {} is supposed to create an empty group. The issue might be:
|
||||
1. The replacement bone might not have the key "Settings" at all - it's a linked rig so the rep might have the default (library) data and we're trying to set rep_bone["Settings"] = {} but the rep might already have "Settings" from the library as a read-only or linked group that we can't overwrite.
|
||||
2. Or the orig has "Settings" as an ID property group but when we read orig_val.keys() we get something different (e.g. Rigify might use RNA PropertyGroup for Settings, not ID props - so bone["Settings"] might not be in bone.keys()).
|
||||
|
||||
Let me check: in Blender, do PropertyGroup values appear in .keys()? If Rigify defines a PropertyGroup on the bone (RNA), then the bone would have an attribute like bone.settings (or bone["Settings"] if they use the same name for the id property). Actually the user said explicitly pose.bones["Settings"]["Devices"] - so they're using bracket notation. So either it's id_properties (then "Settings" would be in .keys()) or it's a mix - e.g. "Settings" is the bone name and the bone has an id property "Devices". So we'd have pose.bones["Settings"].keys() containing "Devices". So we do copy that. Unless the rep bone is linked and doesn't allow writing to certain keys?
|
||||
|
||||
Let me try two things:
|
||||
1. Add RNA property copying: for each writable RNA property on the bone/object that exists on both orig and rep, copy the value. This would copy PropertyGroup values (we need to recurse into nested PropertyGroups).
|
||||
2. Use to_dict() if available to serialize the orig id props and then set leaf values on rep - to avoid the "assign dict to existing group" issue.
|
||||
|
||||
For (1), we'd do something like:
|
||||
for prop_name in orig.bl_rna.properties.keys():
|
||||
if prop_name in ('rna_type', ...): continue
|
||||
prop = orig.bl_rna.properties[prop_name]
|
||||
if prop.is_readonly: continue
|
||||
try:
|
||||
val = getattr(orig, prop_name)
|
||||
if is_pointer(val) and val == orig: continue # don't copy self-ref
|
||||
setattr(rep, prop_name, val)
|
||||
except: pass
|
||||
|
||||
But copying pointer properties to the rep could set rep.something = orig_armature which is wrong. So we need to only copy non-pointer properties, or retarget pointers. For now let's try copying only simple types and recurse into PropertyGroups (structs that have bl_rna.properties). So: if the value is a bpy_struct (has bl_rna), recurse and copy each sub-property. Otherwise if it's a simple type, copy.
|
||||
|
||||
I'll implement RNA property copying: for object and each pose bone, copy writable RNA properties, recursing into nested structs (PropertyGroups). Skip pointer properties that point to IDs we're not retargeting. This way both id_properties (bracket) and RNA properties (attribute) get copied.
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
Checking whether "Settings"/"Devices" are RNA (registered) properties — they wouldn't appear in `.keys()`. Adding copying of RNA properties (e.g. Rigify's PropertyGroups) and debug logging.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="read" data-tool-name="read_file_v2">
|
||||
<details><summary>Tool use: **read_file_v2** • Read file: T:\Dynamic-Link-Manager\ops\migrator.py</summary>
|
||||
|
||||
</details>
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
I'll add:
|
||||
1. Copy RNA properties (bl_rna.properties) - for PoseBone and Object we iterate properties that are not readonly and not pointer (or we skip pointers to avoid cross-ref issues), and copy. For nested PropertyGroup we recurse.
|
||||
2. Debug prints so we can see what keys exist on the Settings bone and whether any copy fails.
|
||||
|
||||
Rigify's Settings bone often has properties defined via RNA (PropertyGroup subclasses). So we need to copy those. How to detect a "nested" RNA struct: if getattr(val, 'bl_rna', None) and hasattr(val, 'bl_rna') and hasattr(val.bl_rna, 'properties'), then it's a bpy_struct and we can iterate val.bl_rna.properties and copy each.
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
Adding RNA property copying (for Rigify-style PropertyGroups like Settings/Devices) and optional debug output.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="write" data-tool-name="edit_file_v2">
|
||||
|
||||
<details><summary>Tool use: **edit_file_v2** • Edit file: T:\Dynamic-Link-Manager\ops\migrator.py</summary>
|
||||
|
||||
</details>
|
||||
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
I'm skipping POINTER type in the else branch - but for nested structs we do recurse. So PropertyGroup (which is a struct, not a POINTER to an ID) should be detected by _is_rna_struct and we recurse. Let me check: in Blender, PropertyGroup subclasses are bpy_struct, so they have bl_rna.properties. So when we have bone["Settings"] or bone.settings (RNA), the value might be a PoseBone or a custom PropertyGroup. PoseBone has bl_rna - so _is_rna_struct(bone) is True. So we iterate bone.bl_rna.properties. One of them might be "Devices" or a group that contains "Devices". So we need to recurse when the value is a struct. I did that. But wait - we're skipping POINTER. In Blender RNA, a PropertyGroup is typically a nested struct (not a pointer). So the type might be not POINTER. Let me leave as is. If "Devices" is a collection or an enum, we copy it. If it's a nested PropertyGroup, we recurse.
|
||||
|
||||
One issue: rep_val = getattr(rep_item, prop_name, None) - for a nested struct, rep_val might be the same type (e.g. a PropertyGroup). We then recurse _copy_rna_props_recursive(orig_val, rep_val, ...). So we copy each sub-property. Good.
|
||||
|
||||
Let me double-check: we don't copy POINTER at all. So if any setting is a pointer to an armature/bone we skip it. That's safe. For nested structs we recurse. So Settings (if it's a PropertyGroup on the bone) would be a property whose value is a struct; we get rep_val = rep_bone.Settings (or getattr(rep_bone, "Settings", None)), and if rep_val is not None we recurse into it, copying all properties of that group (e.g. Devices, etc.).
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="unknown" data-tool-name="read_lints">
|
||||
<details>
|
||||
<summary>Tool use: **read_lints**</summary>
|
||||
|
||||
|
||||
Parameters:
|
||||
|
||||
```json
|
||||
{
|
||||
"paths": [
|
||||
"T:\\Dynamic-Link-Manager\\ops\\migrator.py"
|
||||
]
|
||||
}
|
||||
```
|
||||
Result:
|
||||
|
||||
```json
|
||||
{
|
||||
"linterErrorsByFile": [
|
||||
{
|
||||
"relativeWorkspacePath": "T:\\Dynamic-Link-Manager\\ops\\migrator.py"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
Status: **completed**
|
||||
|
||||
|
||||
</details>
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
One more thing: the replacement rig might be linked from a library. In that case, RNA properties on the rep might be read-only (library override). So setattr(rep_item, prop_name, orig_val) could fail. We already have try/except and print the error - that will show in the terminal. If the user sees "library override" or "read-only" errors, they might need to ensure the rep rig (or its bones) are overridden first. I won't change that now; the debug print will help.
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
Summary of what was added:
|
||||
|
||||
**1. RNA property copying (for Rigify-style Settings/Devices)**
|
||||
- **`_is_rna_struct(val)`** – Detects bpy_structs that have `bl_rna.properties` (e.g. PropertyGroups).
|
||||
- **`_copy_rna_props_recursive(orig_item, rep_item, path)`** – Walks all writable RNA properties on `orig_item` and copies them to `rep_item`.
|
||||
- Skips `rna_type`, `name`, and readonly properties.
|
||||
- If a property value is a nested struct (e.g. Settings), it recurses so sub-properties like Devices are copied.
|
||||
- Skips POINTER properties so we don’t copy references to the original armature/bones.
|
||||
- **`run_mig_cust_props`** now:
|
||||
- Copies ID props (bracket custom props) as before.
|
||||
- Copies RNA props on the armature object.
|
||||
- For each pose bone, copies ID props then RNA props (so both `bone["Settings"]["Devices"]`-style and Rigify PropertyGroups are handled).
|
||||
|
||||
**2. Debug logging**
|
||||
- If an id_prop or RNA copy fails, the exception is printed as `[DLM MigCustProps] id_prop 'key': ...` or `[DLM MigCustProps] RNA path.prop: ...`.
|
||||
- In the terminal you can see whether failure is from ID props, RNA props, or library override (read-only) on the rep.
|
||||
|
||||
Reload the add-on and run MigCustProps again. If the rep rig is still linked, override the armature (or the Kennedy object) so its RNA properties are editable; any remaining copy errors will show in the console.
|
||||
|
||||
---
|
||||
|
||||
_**User**_
|
||||
|
||||
@c:\Users\Nathan\.cursor\projects\t-Dynamic-Link-Manager\terminals\3.txt that's extremely broken.
|
||||
|
||||
---
|
||||
|
||||
_**Agent (model default, mode Agent)**_
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
The user says the MigCustProps change is "extremely broken". I need to read the terminal to see what errors or bad behavior occurred, then revert or fix the custom properties logic.
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="read" data-tool-name="read_file_v2">
|
||||
<details><summary>Tool use: **read_file_v2** • Read file: c:\Users\Nathan\.cursor\projects\t-Dynamic-Link-Manager\terminals\3.txt</summary>
|
||||
|
||||
</details>
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
I see the problem. The RNA copy is recursing into **everything** on the pose bone, including `custom_shape` (the bone's display mesh) and then into `custom_shape.data` (the Mesh datablock), and trying to copy Mesh properties like `texspace_location` which are read-only. That's wrong and triggers tons of errors. It also may be triggering updates/callbacks that break other addons (pose_shape_keys, auto_rig_pro).
|
||||
|
||||
Fix: **Remove the RNA copying entirely** and only keep the ID property (bracket) copy, including the recursive nested ID groups. The RNA approach was too broad—it copied display/mesh/structural props we should never touch. Settings/Devices might still be id_properties; if they're not, we need a much more targeted approach (e.g. only copy RNA on a known "Settings" bone or known property names), not a full bl_rna walk.
|
||||
|
||||
I'll revert to just ID properties: keep _copy_id_prop_recursive and _copy_custom_props_from, remove _is_rna_struct, _copy_rna_props_recursive, and the calls to _copy_rna_props_recursive from run_mig_cust_props. Also remove the debug print from _copy_id_prop_recursive (or leave it as pass to avoid logging every minor failure). That restores safe behavior.
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reverting the RNA copy: it recursed into pose-bone RNA (e.g. `custom_shape` → Mesh) and tried to copy read-only Mesh props, causing errors and addon breakage. Restricting to ID properties only (keep recursive ID group copy, remove all RNA copying).
|
||||
|
||||
|
||||
---
|
||||
|
||||
<tool-use data-tool-type="write" data-tool-name="edit_file_v2">
|
||||
|
||||
<details><summary>Tool use: **edit_file_v2** • Edit file: T:\Dynamic-Link-Manager\ops\migrator.py</summary>
|
||||
|
||||
</details>
|
||||
|
||||
</tool-use>
|
||||
|
||||
---
|
||||
|
||||
<think><details><summary>Thought Process</summary>
|
||||
|
||||
Good. I've removed all RNA copying. The migrator now only copies ID properties (bracket custom props), including nested groups. That won't touch custom_shape, Mesh data, or trigger those addon errors. If Settings/Devices are stored as ID properties on the bone, they'll be copied. If they're RNA (Rigify PropertyGroup), they won't be—but we can't safely do a full RNA walk without recursing into things like custom_shape.data. A future fix for Settings/Devices could be a very narrow RNA copy only for a specific bone name (e.g. "Settings") and specific property names, but I won't add that now since it was so broken.
|
||||
</details></think>
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reverted the RNA-based copying so MigCustProps no longer touches anything except **ID properties** (custom props you set with `obj["key"]`), including nested groups.
|
||||
|
||||
**What was wrong**
|
||||
- The RNA pass walked **every** RNA property on each pose bone and recursed into sub-structs.
|
||||
- That included things like `custom_shape` → `custom_shape.data` (Mesh), and it tried to copy read-only Mesh props (`texspace_location`, `texspace_size`), which caused the `[DLM MigCustProps] RNA bone:...custom_shape.data...` errors.
|
||||
- Copying those also triggered updates (e.g. pose_shape_keys, auto_rig_pro) and led to “Error: Unable to execute 'Edit Mode'”.
|
||||
|
||||
**What’s in place now**
|
||||
- **Only ID properties** are copied: `orig.keys()` / `rep[key] = ...`, with recursion when a value is an ID property group (so nested entries like `bone["Settings"]["Devices"]` are still copied if they are ID props).
|
||||
- No more RNA iteration, so no more recursing into `custom_shape`, Mesh, etc.
|
||||
|
||||
So MigCustProps is back to the previous, safe behavior: copy bracket custom props and their nested groups only. If “Settings”/“Devices” on the Kennedy rig are **RNA** (e.g. a Rigify PropertyGroup), they won’t be copied by this; supporting those would need a very limited, explicit copy (e.g. only for a “Settings” bone and a fixed list of property names), not a full RNA walk.
|
||||
|
||||
---
|
||||
|
||||
_**User**_
|
||||
|
||||
@c:\Users\Nathan\.cursor\projects\t-Dynamic-Link-Manager\terminals\3.txt add debug, it's not adding the custprops. use blendermcp to view my scene if you need to.
|
||||
|
||||
---
|
||||
|
||||
|
||||
+61
-8
@@ -167,19 +167,72 @@ def run_mig_nla(orig, rep, report=None):
|
||||
EXCLUDE_PROPS = {"_RNA_UI", "rigify_type", "rigify_parameters"}
|
||||
|
||||
|
||||
def _is_id_prop_group(val):
|
||||
"""True if val is an ID property group (nested dict-like), not a leaf or string."""
|
||||
if val is None or isinstance(val, (str, bytes)):
|
||||
return False
|
||||
return callable(getattr(val, "keys", None))
|
||||
|
||||
|
||||
def _copy_id_prop_recursive(orig_container, rep_container, key, debug_path="", debug=False):
|
||||
"""Copy one id property from orig_container[key] into rep_container[key] (recursive for groups)."""
|
||||
if key not in orig_container:
|
||||
return
|
||||
orig_val = orig_container[key]
|
||||
try:
|
||||
if _is_id_prop_group(orig_val):
|
||||
if key not in rep_container:
|
||||
rep_container[key] = {}
|
||||
rep_group = rep_container[key]
|
||||
for k in list(orig_val.keys()):
|
||||
_copy_id_prop_recursive(orig_val, rep_group, k, f"{debug_path}.{key}", debug)
|
||||
if debug:
|
||||
print(f"[DLM MigCustProps] group {debug_path}.{key!r}: copied {len(orig_val.keys())} sub-keys")
|
||||
else:
|
||||
rep_container[key] = orig_val
|
||||
if debug:
|
||||
print(f"[DLM MigCustProps] leaf {debug_path}.{key!r} = {orig_val!r}")
|
||||
except Exception as e:
|
||||
print(f"[DLM MigCustProps] FAILED {debug_path}.{key!r}: {e}")
|
||||
|
||||
|
||||
def _copy_custom_props_from(orig_obj, rep_obj, debug_label="", debug=False):
|
||||
"""Copy all custom props from orig_obj to rep_obj (object or pose bone), including nested groups."""
|
||||
keys = [k for k in orig_obj.keys() if k not in EXCLUDE_PROPS]
|
||||
if debug and keys:
|
||||
print(f"[DLM MigCustProps] {debug_label} keys: {keys}")
|
||||
for key in keys:
|
||||
_copy_id_prop_recursive(orig_obj, rep_obj, key, debug_label, debug)
|
||||
|
||||
|
||||
def run_mig_cust_props(orig, rep):
|
||||
"""Custom properties: copy pose-bone custom props, exclude rigify internals."""
|
||||
"""Custom properties: copy overridden settings (ID props only, incl. nested e.g. Settings/Devices) from orig to rep."""
|
||||
debug = True
|
||||
print(f"[DLM MigCustProps] orig={orig.name!r} rep={rep.name!r}")
|
||||
# Armature object
|
||||
o_keys = list(orig.keys())
|
||||
print(f"[DLM MigCustProps] armature orig keys (all): {o_keys}")
|
||||
_copy_custom_props_from(orig, rep, f"obj:{orig.name}", debug)
|
||||
# Bones with any id props
|
||||
bones_with_keys = [(pb.name, list(pb.keys())) for pb in orig.pose.bones if pb.keys()]
|
||||
print(f"[DLM MigCustProps] bones with id_props: {bones_with_keys}")
|
||||
for pbone in orig.pose.bones:
|
||||
if pbone.name not in rep.pose.bones:
|
||||
continue
|
||||
rbone = rep.pose.bones[pbone.name]
|
||||
for key in list(pbone.keys()):
|
||||
if key in EXCLUDE_PROPS:
|
||||
continue
|
||||
try:
|
||||
rbone[key] = pbone[key]
|
||||
except Exception:
|
||||
pass
|
||||
_copy_custom_props_from(pbone, rbone, f"bone:{pbone.name}", debug)
|
||||
# After: rep armature and Settings bone if present
|
||||
print(f"[DLM MigCustProps] rep armature keys after: {list(rep.keys())}")
|
||||
if "Settings" in rep.pose.bones:
|
||||
sb = rep.pose.bones["Settings"]
|
||||
print(f"[DLM MigCustProps] rep bone Settings keys after: {list(sb.keys())}")
|
||||
if sb.keys():
|
||||
for k in sb.keys():
|
||||
v = sb[k]
|
||||
if _is_id_prop_group(v):
|
||||
print(f"[DLM MigCustProps] Settings[{k!r}] (group) keys: {list(v.keys())}")
|
||||
else:
|
||||
print(f"[DLM MigCustProps] Settings[{k!r}] = {v!r}")
|
||||
|
||||
|
||||
def run_mig_bone_const(orig, rep, orig_to_rep):
|
||||
|
||||
Reference in New Issue
Block a user