Free 'Use parent bones' script.

Dodgy · Post by **Dodgy** » Fri Oct 24, 2008 3:07 pm

I don't know if anyone has done this, or is actually interested, but I've written an embedded script which allows bones in a switch layer to mimic bones with the same names in the switch's parent. This means you can animate bones in one layer, without having to select the switch layer and then animate it's bones as well. If it can't find a bone's name match in the parent layer, it ignores it, so you can animate bones separately in the switch layer too. It nests, so you can have switch layers within bone layers within switch layers.
It copies the bone strength, length, bone offset, position, angle and scale values from the parent, so you can adjust all of those in the parent and the matching bones in the children will update.

Would anyone be interested in it?

slice11217 · Post by **slice11217** » Fri Oct 24, 2008 3:12 pm

count me in! I wonder if this could be used in conjunction with the boneposes script. ...Anyone?

rylleman · Post by **rylleman** » Fri Oct 24, 2008 5:32 pm

Very much so indeed!
If you want to post it I would be very thankful to you.

funksmaname · Post by **funksmaname** » Fri Oct 24, 2008 5:45 pm

post it you big teaser

Dodgy · Post by **Dodgy** » Sat Oct 25, 2008 7:29 am

Here it is:

http://www.mikegreen.name/Lscripts.html ... ent_Master

Let me know if you have any problems etc.

synthsin75 · Post by **synthsin75** » Sat Oct 25, 2008 3:00 pm

Thanks a lot! We've needed this for a long time. I'm surprised how simple that script is. I can't believe no one else has ever done that.

Newbies especially are always asking if bones can reach internal groups. Now they can!

How hard would it be to make this even more flexible? Like make it where it keeps checking the next parent layer up until it finds bones. That way any amount of nesting could be used.

Dodgy · Post by **Dodgy** » Sun Oct 26, 2008 5:37 am

I'm surprised too

It might be possible to choose any layer, but this might conflict if you have multiple chars loaded with the same layer names. Maybe just search up the tree for a named layer?

synthsin75 · Post by **synthsin75** » Sun Oct 26, 2008 5:53 am

I was going to try modify your script to use extensions on the layer names. The only thing is that this would require both the 'skel' and 'skelpar' layers to have the script embedded.

I tried to make it look for further parent layers, but for some reason anything beyond the 'ParentSkeleton' appears to be considered 'userdata'. I couldn't find a way around that.

But I'm no scripting pro yet. From your site, it looks like you have a lot more experience.

chucky · Post by **chucky** » Sun Oct 26, 2008 11:29 am

That's excellent thanks DODGY,
That bake motion looks very useful too, I wish I had seen that a few weeks ago.
.....can it bake dynamics?

heyvern · Post by **heyvern** » Sun Oct 26, 2008 9:16 pm

synthsin75 wrote: I tried to make it look for further parent layers, but for some reason anything beyond the 'ParentSkeleton' appears to be considered 'userdata'. I couldn't find a way around that.

You need to find the "parent of the parent of the parent...". I'm not sure AS scripting can go "that far" up the chain of layers and have access to the skeleton of the layer. I seem to recall doing this when I was working on bone groups and bone colorizing... I will check to see. I am pretty sure that getting the skeleton of any layer other then the layer with the script and its parent is impossible.

I am VERY intrigued... I might take another look to see how far the "layer parent" script ref can go. If you "convert" the "parent" object to a regular layer object you should be able to access the skeleton. I vaguely recall trying this without any results.

-------

In the script reference the "parent layer" is EXACTLY the same as the layer with the script. This means you have access to the skeleton of that parent layer. Normally you have no access to a layers skeleton.

The "skeleton" of a bone layer USUALLY exists only for the layer selected or the layer with a script. A layer object is a specific thing so you can get a layer by counting the layer list and selecting a layer by ID or using names and comparing layer names to IDs, but you still can't access the bones in that layer UNLESS it is the layer WITH the script (or the parent).

That is the big problem with a lot of this stuff. A layer with a script has a parent layer which can contain a skeleton object you can access. That is why you often need two scripts for things like this. My "Bone Slave" script had to have two scripts because of this. Each script refers to that specific layer and its skeleton.

Sorry for the confusing explanation...

-vern

synthsin75 · Post by **synthsin75** » Sun Oct 26, 2008 11:18 pm

No problem Vern, I followed most of that, I think.

I've modified Dodgy's script so that any two (or more) bone layers, anywhere in the project, all with the same script embedded, will be controlled by the embedded layer with a specific extension. So far I haven't been able to tie in the layer names, so any bones that share the same bone names in these embedded layers are condemned to follow the controlling layer's bones. Luckily that can be easily remedied by the user changing these bone names.

Also, since I haven't tied it to the layer names yet, all these layer can have any name at all. It is just the extension on the embedded layer's name that determines the controlling layer, and no extension on the embedded layers being controlled.

I'd rather it be tied to the layer names, but studying meshinstance, it looks like I'd have to jump through a lot of hoops to get one script to do that for all layers.

I'm still trying to work it out, but if anyone is inerested in this version, I'd be happy to share it. (At least as soon as I'm pretty sure it doesn't have any fatal flaws.)

synthsin75 · Post by **synthsin75** » Sun Oct 26, 2008 11:37 pm

Vern, I just read this bit from your master/slave bone thread:

Fazek wrote:It is also possible to use a global variable to exchange common parameters between layers with a 'calculated' name, use _G[string_variable_or_expression].

WHOA! You can get variables from different layers with the same layer script embedded?! Is this true? Does that mean that you can use variables assigned on one layer in another?

p.s. Dodgy, sorry if I'm highjacking your thread (and script idea, though I assume this is just a different implementation of Vern's).

heyvern · Post by **heyvern** » Mon Oct 27, 2008 6:46 am

I think so Synth but only up to a certain point.

The real issue is what you can do with the global variables "content". If for instance a global shared variable has a reference to a bone ID and you access this variable on a DIFFERENT bone layer it isn't going to look for the bone from the ORIGINAL layer, it would apply that variable reference to the current layer.

You can't really get bone info from one layer to another (unless you use the parent layer which is different). I actually just discovered that parent layer skeleton scripting thing very recently myself. It is very cool but I haven't really seen how far it can go yet.

The way I use the global variables was if the bones on two layers were the same name, same ID etc, the skeletons are identical, I could use the reference to a bone on one layer that moved or rotated and apply that rotation to the exact same bone on another layer. They match.

This is why my original master/slave bone scripts had performance issues. I had to store ALL the bones properties in a separate lua table in order to "share" that data with another layer. You don't actually read the bone properties from the original bone on another layer, you are reading it from a global table variable that was created by the script in the other layer.

The more bones you have the more klunky the script performance became as it constantly reads back and forth from that global table variable.

Accessing the PARENT layer skeleton works great because using the layer parent reference you are accessing the "real" bone or skeleton itself from a child or parent layer directly. It's as if that bone on a parent layer were actually in the child layer or visa versa. Much faster, much more efficient. You can access the bone properties the same way you get any bone properties on a bone layer.

Currently there is no way to access the skeleton of any other bone layer from an embedded script in a layer. The skeleton and its bones only exists for THAT layer. Even if you put the skeleton in a variable it won't work because on another layer that skeleton isn't accessible (I've tried... believe me I've tried). Using the parent layer skeleton is the only way this can be done.

In one of my original copy/past bones scripts I used a trick. The script would actually change the selected layer so I could access the bones to be copied. I had it set up to to choose the layer to copy bones from. It would switch to that layer, create a reference table, switch back to the "paste" bone layer and paste the bones using the table reference. It was the only way to get that info.

-vern

synthsin75 · Post by **synthsin75** » Mon Oct 27, 2008 12:29 pm

I assume you did that layer switching for a menu script? I tried using 'SetSelLayer' but I didn't seem too friendly for running every frame in a layer script.

----------------------

My current modification of this script doesn't update immediately (a problem I think you had with your Master/slave bone script). I'm debating trying to use more meshinstance code, but it works well enough now.

Oh yeah, Dodgy, I'll still make plenty of use of your original script since it leaves the parent bone layer free to have another script embedded. Once again, thanks.