AutoKey() function broken in R11?

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 04/09/2008 at 06:25, xxxxxxxx wrote:

Howdy,

Please, I really need an answer on this. :o(

Is there a new restriction in R11 as to when the AutoKey() function can be called in the pipeline?

The way I have it set up now in my tag is: the TagData::Execute() function sets some flags when it detects changes, then a MessageData plugin polls for EVMSG_CHANGE, and sends a custom message to the tag, where it checks for auto key mode on and checks the flags and then calls the AutoKey() function if needed. I've added GePrint() statements to track the flow, and everything prints to the console properly. But, no keys are set. :o(

It was working in R9.6 and R10, but it's not working in R11. Is it because I'm calling the AutoKey() function from the TagData::Message() function? And if so where should the AutoKey() function be called?

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 04/09/2008 at 07:18, xxxxxxxx wrote:

Could you maybe post some code snipets because the function itself seems to work fine. I will try to get you an answer asap.

cheers,
Matthias

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 04/09/2008 at 08:12, xxxxxxxx wrote:

Howdy,

OK, this is the code in the TagData::Message() function where it receives the custom message to call the AutoKey() function:

> \> if(IsCommandEnabled(IDM_AUTOKEYS) && IsCommandChecked(IDM_AUTOKEYS)) \> { \>      if(tData->GetBool(ADD_KEY)) \>      { \>           AutoAlloc<AliasTrans> trans; \>           BaseTag \*tClone = (BaseTag\* )tag->GetClone(0,trans); \>           if(tClone) \>           { \>                BaseContainer \*tcData = tClone->GetDataInstance(); \>                if(tcData) \>                { \>                     tcData->SetVector(TRANS_POS,tData->GetVector(OLD_POS)); \>                     tcData->SetVector(TRANS_SCA,tData->GetVector(OLD_SCA)); \>                     tcData->SetVector(TRANS_ROT,tData->GetVector(OLD_ROT)); \>                      \>                     doc->AutoKey(tClone,tag,FALSE,FALSE,FALSE,FALSE,IsCommandChecked(IDM_A\_PARAMETER),FALSE); \>                } \>                BaseTag::Free(tClone); \>           } \>      } \> } \>

I added GePrint() statements before and after setting the cloned tag's parameters to the old values like this:

> \> GePrint("before: TRANS_POS = "+VectorToString(tcData->GetVector(TRANS_POS)) \>           +"; OLD_POS = "+VectorToString(tData->GetVector(OLD_POS))); \> tcData->SetVector(TRANS_POS,tData->GetVector(OLD_POS)); \> tcData->SetVector(TRANS_SCA,tData->GetVector(OLD_SCA)); \> tcData->SetVector(TRANS_ROT,tData->GetVector(OLD_ROT)); \> GePrint("before: TRANS_POS = "+VectorToString(tcData->GetVector(TRANS_POS)) \>           +"; OLD_POS = "+VectorToString(tData->GetVector(OLD_POS))); \>

... and the values are printed correctly.

Everything works fine in R10, it sets the auto keys perfectly, but not in R11 (demo version). :o(

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 08/09/2008 at 06:03, xxxxxxxx wrote:

Howdy,

Any word yet?

Why is it not setting a key? The GePrint() statements show that the parameter values are being changed properly so that the cloned tag's parameters are different from the tag's parameters. The AutoKey() function should set a key if the parameters are different, right?

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 08/09/2008 at 07:50, xxxxxxxx wrote:

Hi Dan,

No final answer yet but at least I can now confirm this here too. I filed a bug report.

cheers,
Matthias

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 08/09/2008 at 08:11, xxxxxxxx wrote:

Howdy,

Ah, OK. Thanks. Keep me posted. ;o)

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 09/09/2008 at 18:48, xxxxxxxx wrote:

Howdy,

Have you found out if it is actually a bug? Or is it some sort of optimization in R11 that ends up not allowing the function to be called from there?

If it is definitely a bug, then I will release my code as is. But, if I need to be calling that function from somewhere else, can you get an example how to do properly?

Thanks.

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 10/09/2008 at 01:25, xxxxxxxx wrote:

Sorry, I have no confirmation from the developers yet.

cheers,
Matthias

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 11/09/2008 at 07:37, xxxxxxxx wrote:

Howdy,

Well, I reckon it's time to put on your best "Clint Eastwood" and pay them a visit. :oD

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 11/09/2008 at 07:42, xxxxxxxx wrote:

Lol, yeah, I guess so. But what I think it's probably a bug related to the new NLA system which changed some stuff under the hood.

cheers,
Matthias

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 11/09/2008 at 07:53, xxxxxxxx wrote:

Howdy,

Yeah, that's what I was thinking, too.

I may just go ahead and release the plugin, and then release an update when it gets fixed. ;o)

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 02/10/2008 at 11:00, xxxxxxxx wrote:

Howdy,

Any word yet?

I've heard that an update was announced, but I haven't upgraded to R11 yet so I have no way of checking. :o(

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 28/10/2008 at 10:03, xxxxxxxx wrote:

Howdy,

So, have you received any answer from the developers on this, yet?

I'm using the AutoKey() function in a few other plugins and when it's called from a command it seems to work fine. It just doesn't want to work when called from the Message() function of a tag. :o(

Should I create a special command plugin, call it from a MessageData() plugin and have the command call the AutoKey() function to get this to work in R11? Because calling AutoKey() from a command seems to be OK.

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 29/10/2008 at 01:23, xxxxxxxx wrote:

As I said I have reported it as a bug. It is filed in our bug database, now I can only wait.

You could try the MessageData plugin approach, let us now how it works out.

cheers,
Matthias

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 30/10/2008 at 08:55, xxxxxxxx wrote:

Howdy,

Well, no luck again. :o(

Calling AutoKey() from a CommandData() via a MessageData() works in R9.6 and R10 but not in R11.

It's as though in R11, you simply can not auto key a tag's parameter by moving an object in the viewport. You can only auto key a tag's parameter by manually changing the parameter in the tag's AM. That's sad because it totally destroys a unique convenience feature of my plugin. :o(

I'm sure that auto-keying a tag's parameter by moving an object in the viewport isn't something that you would normally need to do, under normal circumstances, so I doubt that fixing that bug would be high on the bug fixing priority list.

Do you think it would be possible for me to write my own AutoKey() function, and do you have any tips on how I would go about that?

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 31/10/2008 at 17:18, xxxxxxxx wrote:

Howdy,

Well, I'm making some progress on writing my own auto key function that is specific to my tag, but there is something puzzling about the Scale parameter. It seems that it's not detecting a change. I'm using the VectorEqual() function like this:

> if(!VectorEqual(tcData->GetVector(TRANS_SCA),tData->GetVector(TRANS_SCA),0.01))

tcData is the "undo" cloned tag's BaseContainer, and tData is the tag's BaseContainer.

The AM resource is set up exactly like it is in the obase.res file:

>           GROUP \>           { \>                LAYOUTGROUP; COLUMNS 3; \>                GROUP { VECTOR TRANS_POS { UNIT METER; ANIM ON; CUSTOMGUI SUBDESCRIPTION; } } \>                GROUP { VECTOR TRANS_SCA { STEP 0.01; ANIM ON; CUSTOMGUI SUBDESCRIPTION; } } \>                GROUP { VECTOR TRANS_ROT { UNIT DEGREE; ANIM ON; CUSTOMGUI SUBDESCRIPTION; } } \>           }

(you can see that I used 0.01 in the VectorEqual() function because the step is set to 0.01 in the .res file)

But, it's not detecting a difference in the scale until the scale is at least over 3.0. Is there anything in particular that is different about scale. The VectorEqual() function detects differences in position and rotation perfectly (to 0.001), but not scale. Why is that?

I've even noticed that when using the api's AutoKey() function (which worked in R10) that it would set scale keys when only the rotation changed. Something seems amiss there. :o(

Any clues?

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 01/11/2008 at 08:45, xxxxxxxx wrote:

Howdy,

Any idea on the scale issue?

Also I have another question regarding Undo. I've added:

> \> doc->AddUndo(UNDO_NEW,track); \>

after inserting the track and then added:

> \> doc->AddUndo(UNDO_CHANGE,track); \>

before setting a key value.

Is this the correct way to handle the undo? I can't tell for sure from the SDK documentation. I'm assuming that since the track is "inserted" the undo should come after with an "UNDO_NEW", but I'm not sure about the key whether the undo should be on the key itself with "UNDO_NEW" or if it should be on the track with "UNDO_CHANGE".

It seems to work OK (not crashing) the way I have it, but I just want to double check to make sure it's correct. ;o)

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 03/11/2008 at 04:04, xxxxxxxx wrote:

Sorry, I can not confirm the scale problem, this is working fine here using your description example. Maybe there is something wrong in your code creating the cloned container?

As for the undo handling, you call UNDO_NEW after allocating and inserting. You call UNDO_CHANGE before you do any change.

cheers,
Matthias

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 03/11/2008 at 05:12, xxxxxxxx wrote:

Howdy,

> Quote: Originally posted by Matthias Bober on 03 November 2008
>
> * * *
>
> Sorry, I can not confirm the scale problem, this is working fine here using your description example. Maybe there is something wrong in your code creating the cloned container?
>
>
> * * *

This is the thing that is puzzling me because the code is the same for creating the position and rotation cloned containers. I'll have to investigate elsewhere. :o(

> Quote: Originally posted by Matthias Bober on 03 November 2008
>
> * * *
>
> As for the undo handling, you call UNDO_NEW after allocating and inserting. You call UNDO_CHANGE before you do any change.
>
>
> * * *

Right. That's what I got from the SDK Documentation, I just wanted to confirm if my assumption that adding a key to a track was considered a "change" to the track. Is my assumption correct?

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 03/11/2008 at 05:29, xxxxxxxx wrote:

You should use UNDO_NEW on the things you insert. So if you inserting keys you should use the pointer to the key in AddUndo().

cheers,
Matthias