Consolidating my embedded layer scripts...

Moho allows users to write new tools and plugins. Discuss scripting ideas and problems here.

Moderators: Fahim, Distinct Sun, Víctor Paredes, erey, Belgarath, slowtiger

User avatar
heyvern
Posts: 6964
Joined: Fri Sep 02, 2005 4:49 am

Consolidating my embedded layer scripts...

Post by heyvern » Tue Jan 15, 2008 6:53 am

Since my bone group script with saved preference file is working so well now (found a few bugs I am fixing) I plan to incorporate the same system to some of my embedded layer scripts.

This will eliminate the need to embed layer scripts at all to gain added functionality.

For instance I was talking with a forum member who had trouble setting up my "flipper" layer script for using TransRotate and RotateTrans, etc. It is complicated because of all the special bone names and some bugs I missed.

If I put the functionality of that script into a single utility script and link that to a tool or pop up menu you won't need to give bones special names. Just select them, click a custom button or run a menu script and assign new constraint properties to them. I may even be able to add this to the bone select tool menu and just expand the constraint pop up window to include my new constraints.

I can also incorporate my physics scripting into this system. I can also keep each "feature" in a separate utility script for easier updating. If you don't have one script installed it won't effect the others.

I am hoping by streamlining the scripts in this way it will be easier to implement and be more "invisible" to the user. Like "real" features "built in" to the application. This will also allow the embedded layer script option to be used for something else.

I will keep you posted on my progress.

-vern
funksmaname
Posts: 3107
Joined: Tue May 29, 2007 11:31 am
Location: Nelson, New Zealand

Post by funksmaname » Tue Jan 15, 2008 10:28 am

*drool*
You rock.
ulrik
Posts: 1072
Joined: Thu Aug 11, 2005 10:32 pm
Location: Stockholm Sweden
Contact:

Post by ulrik » Tue Jan 15, 2008 10:42 am

Heyvern, if you manage to do this I'll buy you a beer and salute you! :D
User avatar
jahnocli
Posts: 3340
Joined: Fri Oct 29, 2004 2:13 pm
Location: UK

Post by jahnocli » Tue Jan 15, 2008 11:29 am

GO GO GO!!!
You can't have everything. Where would you put it?
User avatar
heyvern
Posts: 6964
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern » Tue Jan 15, 2008 1:15 pm

I know this can be done. It is a fact. My bone grouping script proves this. I just hope I have the skills to pull it off for everything else.

I hope Smith Micro is listening. If the scripting were "expanded" just a touch a few lua programmers could "recreate" the whole application. I wish I could get some help from them... $$$. Just kidding but not really. ;)

It would be like a "hybrid" commercial/open source application. Buy the pro version and then add in all the custom tools as they get developed or just create your own. Over time incorporate them into the base application. You have the best of both worlds. A company to manage the programs marketing and development and a bunch of tinkerers like me to add in cool stuff they don't have time for or never thought of.

Just tonight (this morning?) while working on a new character I added 3 new bone functions to one of my layer scripts to fix something. A bit of code to constrain scaling. A bit of code so I can translate flexible bound layers with a single bone. Now I can scale eyeballs for perspective on a head turn and still move them around inside the eye using bone/layer translation. I changed some code so that parented bones with constraints go in the same direction as the constraint target.

If I get all of this in ONE utility script I can update these things faster and easier.

-vern
User avatar
heyvern
Posts: 6964
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern » Wed Jan 16, 2008 9:49 pm

It's going well! I plan to use my "RotateTrans" scripts as the prototype. Here is the layout for the menu pop up. I use this to plan it out and thought I would share it:

Image

-vern
Ovjeh
Posts: 26
Joined: Tue Nov 07, 2006 11:53 pm

Post by Ovjeh » Thu Jan 17, 2008 12:17 am

I can only welcome this! more constraints, more possibilities.

And more possibilities in a frendlier UI is a big bonus.


-
Last edited by Ovjeh on Fri Jan 18, 2008 1:21 pm, edited 1 time in total.
User avatar
synthsin75
Posts: 7103
Joined: Mon Jan 14, 2008 11:20 pm
Location: Oklahoma
Contact:

Post by synthsin75 » Fri Jan 18, 2008 3:35 am

For instance I was talking with a forum member who had trouble setting up my "flipper" layer script for using TransRotate and RotateTrans, etc. It is complicated because of all the special bone names and some bugs I missed.
Glad to be of assistance. It's always nice to know my newbie questions are good for something. Sounds great. Keep up the good work Vern.
User avatar
heyvern
Posts: 6964
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern » Fri Jan 18, 2008 5:28 am

"newbie" questions often lead to some amazing techniques and discoveries I might never uncover fiddling on my own. Please don't hold back.

-vern
User avatar
heyvern
Posts: 6964
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern » Fri Jan 18, 2008 6:18 am

I've decided I don't like AS constraints. They don't allow a bone with a constraint to be moved or rotated. I want a "new" constraint that will "add" the USER applied motion of the bone to the constraint. So if a bone has a translation constraint, you can still move it your self. The other bone's translation is ADDED to that translation, like an "offset".

Currently a key is still created when you try to move a bone with a constraint. This movement isn't "applied" but the key and value is still there. The trick is to ADD that to the constraint instead of "ignoring" it.

I'm going to create my own scripted constraints replacing the built in ones to do this.

I'm also experimenting with a "combo" constraint that is promising. It allows a bone to be constrained to two different bones. The difference is "split" so the bone can balance between the two. This will be incorporated into my utility script. Assign two master bones to the same slave bone and the control is divided between them (50%).

Actually if this works as planned you could have a bone constrained to 5 bones and the motion is split equally.

-vern
User avatar
synthsin75
Posts: 7103
Joined: Mon Jan 14, 2008 11:20 pm
Location: Oklahoma
Contact:

Post by synthsin75 » Fri Jan 18, 2008 1:43 pm

I was just wondering if a script could be made that would create a multilayer bone. Create it on one bone layer and have it appear on all nested bone layers. Then this 'one' bone could be controlled from any of its layers. Just a thought.
User avatar
heyvern
Posts: 6964
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern » Wed Jan 23, 2008 8:24 am

Well I'm a bit disappointed to say the least.

All my great plans seem to be for naught. Layer scripts are "special". Each time the frame advances or something "happens" the layer script "runs" and moves bones, moves points, etc, updating the display. A layer script is "always running".

There doesn't seem to be any way to transfer this "constant loading" of code by a layer script to a utility or tool script to apply bone positioning as I hoped. Strange that this works fine for my bone groups script, but it is using a totally different function. Applying changes to a bone's properties just won't "stick" inside a utility script. The bones move until you click elsewhere like on a bone or the time line then the default settings of the layer take over again. I can put the "hard work" and repeating functions of the code inside a utility but a layer script would still be needed to activate them.

A layer script overrides the "properties" of elements on that layer. It is a part of the layer so any changes made by the script will always be displayed that way. If I try to move this code to a utility script I have no way to "run it" constantly to override the default position of bones.

There is a solution but I don't like it very much at all. It requires the user to move the start of all animation to frame 2 and my script would apply these custom modifications as keys to frame 1 so they propagate through the time line. I've used this trick with layer depth movements for changing the layering of arms based on bone motion. it works great but I just don't like the idea of going outside the "standard" use of AS in this way.

This solution works for me... but I don't know if it would be a good idea for others to change how they use the program just for these advancements.

I haven't completely given up but it doesn't look good at the moment.

-vern
User avatar
heyvern
Posts: 6964
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern » Wed Jan 23, 2008 12:42 pm

I have given up.

Unless I learn otherwise from Mike or someone else, this just won't work. Dagnabbit. There is just no way I can find to run a script on each frame, constantly during changes, unless it is a layer script. Tools don't work because they only run when you "do" something. This is what layer scripts were created for after all. Back to layer scripts I guess or else try that "frame 1" key trick. I have trouble with that trick though since I have to track and modify keys before and after the frame for each bone.

I may still put these into a utility script. The layer scripts to use them would only need to be a few lines in length or just one line actually, to call all the "stuff". I could even create a "template" file for standard AS users with the script already linked.. ick, don't like that at all.

I was so confident. Drawing bone groups worked great with a utility script. I just don't get it.

I give up... and then I keep thinking maybe I'm missing something... I've tried everything. Maybe it's my code. <sigh>

-vern
User avatar
synthsin75
Posts: 7103
Joined: Mon Jan 14, 2008 11:20 pm
Location: Oklahoma
Contact:

Post by synthsin75 » Wed Jan 23, 2008 11:59 pm

So, if I understand you, tool and menu scripts create content while only layer scripts can modify ( after the fact)? Well if you can still consolidate your layer scripts that would be helpful. If you only have to embed one script that covers all of your scripts, then you wouldn't have to pick and choose. With a utility that reloads it on openning maybe? I don't know how much is possible.
The only real draw back to using layer scripts is that I have to look up the directions and naming conventions. I'm sure I'd remember these eventually, but what if there were like a menu script that would create the needed bones complete with naming conventions. Albeit generic, like _.flip. Then all one would have to do is embed the consolidated script and adjust and resize the bones as needed.
Like I said though, I don't know what I'm talking about. Just dreaming probably.
User avatar
heyvern
Posts: 6964
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern » Thu Jan 24, 2008 5:11 am

My original "consolidation" concept is still valid. I still plan to do this.

The only problem is that you would have to use a layer script to use these new functions. Everything else would work the same. No need to name bones a special name, a menu script to assign the constraints etc etc. It all will work as planned but you need a teeeeny tiiiiny short one line of code in a simple layer script to "activate" it.

What is happening is that my original concept of putting it all in a utility script ONLY... with out a layer script... "worked"... just not the way it needs to.. the same way a layer script works. A utility script only runs ONCE when the application loads and then each function runs ONCE each time it is called.

In order to do what I REALLY wanted to do I need the "constant" running of a layer script. A layer script runs all the time. It runs when the time line goes to a new frame, it runs when you drag a bone, it runs when you click in the time line or change tools. It runs each time you scroll or zoom the window... etc etc.

I can't mimic that behavior any other way. So I still plan to consolidate the scripts into a utility function, but I can't eliminate the need for a layer script.

-vern
Post Reply