When using constraints the target bone of a constraint is linked to the bone ID rather than the name of the bone... even though that is how it is selected.
So... if you have a bunch of bones created "later" in the list and delete a bone above a bone used as a target in a constraint the ID of each bone changes and the constraint target is shifted to the next bone or the bone that now has that ID.
Any LUA experts willing to take a look at the scripts associated with this to see if it might be fixable?
I looked at the select bone tool... there is all that stuff at the bottom about calling the dialogue for bone constraints... and it does reference the bone ID instead of the name... I don't even know if it could select based on name.
Unfortunately there doesn't seem to be anything in relation to what happens when a bone is deleted. That is the main issue. When a bone is removed from the list of bones, Moho just reorganizes the internal table of bones... not taking into account that constraints are relying on the previous list.
-Vern
Help! Bone constraint bug... can this be fixed with LUA?
Moderators: Víctor Paredes, Belgarath, slowtiger
I think it may be possible to store the name-based parent-constraints-relationship for all the bones on a layer, and restore this relationships on a later point (after deleting a bone).
The question is: when do you want to save and restore this data..
- via a script in the menu
- via an embedded layer script (always save, exept when the bondCount is decreased, then restore)
It's no problem to write those functions i think, but it's harder to find a nice way to work with them
I'm working on a Copy/Paste bone script (almost finished, just busy with the final touch), and there are the parent-child relationships also stored on a name-base, because the BoneID's don't match if you don't copy all the bones
The question is: when do you want to save and restore this data..
- via a script in the menu
- via an embedded layer script (always save, exept when the bondCount is decreased, then restore)
It's no problem to write those functions i think, but it's harder to find a nice way to work with them
I'm working on a Copy/Paste bone script (almost finished, just busy with the final touch), and there are the parent-child relationships also stored on a name-base, because the BoneID's don't match if you don't copy all the bones
portfolio :: http://www.thanarie.nl/thanarie/
work :: http://www.mediamonks.com/
moho :: http://www.thanarie.nl/moho/
work :: http://www.mediamonks.com/
moho :: http://www.thanarie.nl/moho/
The only time I would need this would be when I delete a bone. It wouldn't be something I would use a lot.
For instance right now... I have a file with about 60 bones. Half are constrained. I want* to delete 2 bones... <sigh>... that would be about 30 bones I have to select and change 2 constraints on each...
... so... I just moved the two unwanted bones "out of the way" and reduced their influence to 0 and ignore them for now. Not a great solution.
It seems to me that if some kind of "storage" in a layer would be needed to acomplish this... it would be better done with an application update at some future date. I was thinking it could be done by modifying the existing tools... but this is probably not possible.
* I just realized that in many cases I would be able to "reuse" bones by pushing them off to the side... and later if I need a new bone use one of those instead. This a suitable if not elegant workaround and there may be some benefit to the environment since it could be considered "recycling".
-Vern
For instance right now... I have a file with about 60 bones. Half are constrained. I want* to delete 2 bones... <sigh>... that would be about 30 bones I have to select and change 2 constraints on each...
... so... I just moved the two unwanted bones "out of the way" and reduced their influence to 0 and ignore them for now. Not a great solution.
It seems to me that if some kind of "storage" in a layer would be needed to acomplish this... it would be better done with an application update at some future date. I was thinking it could be done by modifying the existing tools... but this is probably not possible.
* I just realized that in many cases I would be able to "reuse" bones by pushing them off to the side... and later if I need a new bone use one of those instead. This a suitable if not elegant workaround and there may be some benefit to the environment since it could be considered "recycling".
-Vern
That is a nice workaround indeed
Sure this things must be in the program. It's strange that the ID's are changing when you delete one. An ID is an unique identifier for an object, and must not be changed 'automatically'.
It hasn't anything to do with the tools (also because deleting is not a tool), the skeleton is the problem
You don't want the script anymore?
Sure this things must be in the program. It's strange that the ID's are changing when you delete one. An ID is an unique identifier for an object, and must not be changed 'automatically'.
It hasn't anything to do with the tools (also because deleting is not a tool), the skeleton is the problem
You don't want the script anymore?
portfolio :: http://www.thanarie.nl/thanarie/
work :: http://www.mediamonks.com/
moho :: http://www.thanarie.nl/moho/
work :: http://www.mediamonks.com/
moho :: http://www.thanarie.nl/moho/
Well... now that my workaround is working so well...
I would hate to see anyone waste precious time on a script of this sort when there are many other things more worthy.
I see this as a bug in the application. I have reported it as such.
Before I had the brain storm to NOT delete the bones and reuse them... it was giving me nightmares... now... not so much. In fact it is a really good work around even if there are some stray unused bones. I just give them names like... "unused 1", "go-away-now 6" or "die already 4".
Thanks for the input but I think I don't need it now. Sometimes writing these posts causes the solution to appear.
I came up with another solution... if I know right off the bat I plan to do a ton of constraining... I will make sure to create the bones IN THE RIGHT ORDER... if done right I shouldn't have as much trouble... uh... hopefully.
-Vern
I would hate to see anyone waste precious time on a script of this sort when there are many other things more worthy.
I see this as a bug in the application. I have reported it as such.
Before I had the brain storm to NOT delete the bones and reuse them... it was giving me nightmares... now... not so much. In fact it is a really good work around even if there are some stray unused bones. I just give them names like... "unused 1", "go-away-now 6" or "die already 4".
Thanks for the input but I think I don't need it now. Sometimes writing these posts causes the solution to appear.
I came up with another solution... if I know right off the bat I plan to do a ton of constraining... I will make sure to create the bones IN THE RIGHT ORDER... if done right I shouldn't have as much trouble... uh... hopefully.
-Vern
I'm bumping this up again.
I have a file with 151 bones. They should be in groups in the list but there is no way to do that without losing all of the constraints.
Not sure what I need to happen, but I would like a way to change the order of bones in the list so all of my "lip bones" and all of my "eyebrow" bones are in the same spot in the list for easy access.
Using the copy/paste bones script wouldn't really work since it doesn't copy the constraints anyway.
Also my solution for "extra" bones kind of sucks about now. It would be nice to delete bones with out losing the constraints to other bones.
In the mean time I am going to look at a text editor solution.
-vern
I have a file with 151 bones. They should be in groups in the list but there is no way to do that without losing all of the constraints.
Not sure what I need to happen, but I would like a way to change the order of bones in the list so all of my "lip bones" and all of my "eyebrow" bones are in the same spot in the list for easy access.
Using the copy/paste bones script wouldn't really work since it doesn't copy the constraints anyway.
Also my solution for "extra" bones kind of sucks about now. It would be nice to delete bones with out losing the constraints to other bones.
In the mean time I am going to look at a text editor solution.
-vern