Moho Forum

Experts,

I'm having a few issues with something that I'm probably making much harder than it should be. First of all, for some reason I can't set a key on a shape fill color. Can anyone tell me why this:

shape.fMyStyle.fFillCol:AddKey( self.currentFrame )

gives me an error? (All the other shape operations work fine -- this one says "Argument #2 is nil -- number expected" but I didn't think there were two arguments for this function to AddKey).

Second, and perhaps more importantly, I can change a shape's color by doing this:

shape.fMyStyle.fFillCol:SetValue(0, fColor)

and manipulating the RGB values of fColor to my heart's content. All well and good... UNTIL I set a key on that shape. Now as soon as the shape is keyed I can no longer use that function (well, I don't get an error message, it just doesn't work) on that frame or any other frame.

Actually -- it's even weirder than that. It definitely *seems* to work "behind the scenes". Which is to say the RGB values of the shape fill do change in the local variable structure:

local fColor = shape.fMyStyle.fFillCol:GetValue(0):AsColorStruct()

and are accessible and changeable (I can print them out as I repeatedly call the function) but they are definitely NOT what is coloring the shape (it's very weird, I know). Without a key they are IN the shape and behave as you'd expect -- with a key they can't be altered or even accessed correctly (because what I get are the "old" values).

It's almost as if there are two separate entities, the "normal" color values of that shape and if a key is set a "keyed" set of values (that I have no way of getting at).

Any help will prevent me from losing what's left of my mind.

Mike,

Sorry, no help here. I haven't played with those functions yet. If you want to share a script that uses these, maybe I can troubleshoot it.

Just a guess here, but it looks like you are trying to keyframe the style instead of the shape fill channel. Styles do have their own (behind the scenes) timeline, so to speak.

I think the reason it is complaining about "Argument #2 is nil -- number expected" is because it is missing the animation channel number. Just a guess though.

Wes,

I don't think it has anything to do with a style, because all the scripting examples I see that talk about setting fill colors (or fill keys) always use that same syntax (with the shape.fMyStyle designation). And it works irrespective of style.

I didn't want to bother you personally because I know you're working on a lot, but I may email you and share what I'm trying (I'm also a little embarrassed that I can't get this working because on the surface it seems like a no-brainer).

Maybe Vern has worked with shape stuff like this and will chime in to help.

Instead of this:
try this instead:
moho.frame is the current frame. It's the only way I know how to get the current frame. I think you have "currentFrame" confused with this:
That's something different and changes the frame you are on to another frame.

-----

If you don't figure it out I give me a little time to figure this out for you. I think I know what the trouble is for getting and setting values I just have to check some old scripts to see how I did it.

Here's a tip: if there is no key frame you can't "get" the value of a key frame at that frame. You need to get the "value" not the "animated value". I don't know if this is the problem in your case.

From my experience getting values and setting values can be VERY different. Sometimes even the values for both are different and can't just be "stuck in" like you expect.

Colors are a freaking pain in the arse (for me anyway) . I've never done anything with it with key framing, only for my bone coloring interface (drove me batty).

-vern

Thanks, Vern. The tip is useful.

Wes has fixed my script for me (yeah!) and I'll post it here for any interested once I have all the bells and whistles.

The process has convinced me more than ever that your wish for more AS exposure in LUA is not only important, but should be the number one wish item for us all. There may only be a handful of people who write scripts, but the power is tremendous and I suspect we can add more functionality to AS than Mike ever dreamed of.

You're welcome Mike.

I can't wait to see if there are more script functions in the next version. I want to wait for the next version before doing to much with this stuff. It seems like a waste of time to work around a lot of problems if the next version has new stuff. If it doesn't... back to working around problems.

Wait till you see the interface "live text" I created. I had planned to use it to label bones and put "instructions" in files. It only displays in the interface (doesn't render). It uses the same script as my bone coloring/grouping script but I added a very simple block "alphabet" using the scripted draw method. It's a "vector" font.

So the script takes the bone name and draws it alongside the bone. It still needs some work (it's buggy) and it's a royal pain to install. Screen can get a little cluttered if you have a lot of bones.

I can see using this script to create on screen "widgets" and "icons". It should actually be possible to track mouse movement and "animate" scripted drawn elements (like dragging a widget to move a bone). This could cut down on the number of bones needed. Replace "control" bones with interface "widgets". There's a TON of things that could be done. Barely scratched the surface.

-vern

I remmember from my Gmax days ((Gmax is a free limited version of 3dsMax (based on Max 4.26 IIRC))
there were scripts that would take 3d model, made wireframe of it and export all vertex data to a file. Than this chunk of data could be used in scripts for creating custom non-renderable rigging controls. It would be cool to have function that could make same thing with vector art in AS and then to "trick" application that custom shapes are bones.


--