AutoKey() function broken in R11?
-
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 -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 03/11/2008 at 06:05, xxxxxxxx wrote:
Howdy,
OK, thanks. ;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 07:14, xxxxxxxx wrote:
Howdy,
Well, upon further investigation I found the scale problem elsewhere in my code.
Yee-Ha! Now my tag has it's own AutoKey() function working perfectly in R9.6, R10 and R11!
Thanks, Matthias, for all your help and patience.
Adios,
Cactus Dan -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 10/03/2009 at 09:51, xxxxxxxx wrote:
Hi Dan,
For your information, it turned out that AutoKey works for Tbaselist4D types only. Tags are of Tbaselist2d type. This should be fixed in a future update of Cinema.
cheers,
Matthias -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 10/03/2009 at 10:06, xxxxxxxx wrote:
Howdy,
Thanks.
Adios,
Cactus Dan -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 12/10/2009 at 03:33, xxxxxxxx wrote:
FYI, this is fixed in CINEMA 4D R11.5.
cheers,
Matthias -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 12/10/2009 at 07:13, xxxxxxxx wrote:
Howdy,
Thanks Matthias. ;o)
Adios,
Cactus Dan