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 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 -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 03/11/2008 at 05:54, xxxxxxxx wrote:
Howdy,
OK, so are you saying that this is wrong:
>
\> doc->AddUndo(UNDO_CHANGE,trackX); \> CKey \*keyX = trackX->GetCurve()->AddKey(time); if (!keyX) return FALSE; \> keyX->SetValue(trackX->GetCurve(),value.x); \>... and it should be like this?:
>
\> CKey \*keyX = trackX->GetCurve()->AddKey(time); if (!keyX) return FALSE; \> keyX->SetValue(trackX->GetCurve(),value.x); \> doc->AddUndo(UNDO_NEW, keyX); \>The confusing part for me is that it's adding a new key, but the function name to add the key doesn't have the word "Insert" in it. So my assumption was since it wasn't an "Insert" or an "Alloc" function, then use the first example with UNDO_CHANGE.
Sorry, but sometimes my obsessive compulsiveness surfaces and causes these little problems of comprehension. :oD
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 06:03, xxxxxxxx wrote:
As soon as you are creating an object and insert it into something you have to use this object with AddUndo() and UNDO_NEW. I agree it can be a bit confusing sometimes. But if you think about it the AddKey() function is doing exactly this, allocating and inserting keys
So yes this would be the correct one:
>
\> Key \*keyX = trackX->GetCurve()->AddKey(time); if (!keyX) return FALSE; \> doc->AddUndo(UNDO_NEW, keyX); \> keyX->SetValue(trackX->GetCurve(),value.x); \>cheers,
Matthias