Your two lines

GetObjects(kid)
objList += kid

make no sense. The first one calls the recursion but then throws the result away as it is not stored anywhere (objList is a local variable for the function, not a global, and does not exist beyond the context of the current method execution). The second tries to extend a list by a single object instead of another list (the operator += works like extend, not like append) and fails because it cannot iterate through a single object. (Even if you had used the append method or listified kid it would still fail logically because you have already added the kid in the recursion call and then threw it all away.)

What you need to do is extend the local objList by the result list of the recursion call:

objList += GetObjects(kid)

or in context,

import c4d
from c4d import gui

def GetObjects(obj):
      objList = [obj]
      for kid in obj.GetChildren(): 
          objList += GetObjects(kid)
      return objList # should return the parent/selected obejct and all its chidlren

def main():
    test = doc.SearchObject("shoulder_jnt")          
    ikJointChain = GetObjects(test)
    print ikJointChain

if __name__=='__main__':
    main()

Now we are at a point where angels fear to tread...

I can't say what exactly the Start/EndUndo system is doing when not properly used in one level, but it definitely doesn't work in a way that supports nesting. Here I just tried a small modification of my previous scripts:

import c4d

def main():
    doc.StartUndo();
    obj = doc.GetFirstObject();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");

    doc.StartUndo();
    obj = obj.GetNext();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    doc.EndUndo();

    doc.StartUndo();
    obj = obj.GetNext();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    doc.EndUndo();

    obj = obj.GetNext();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");

    obj = obj.GetNext();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    doc.EndUndo();
    c4d.EventAdd();

if __name__=='__main__':
    main()

I used the same sequence of five renames, but I nested rename 2+3 into a new Start/EndUndo without closing the outer first.
If you apply Ctrl-Z on that, you will find that the first Ctrl-Z reverses the last three renames (NOT just the last 2), one more Ctrl-Z reverses the second rename, and one more the first. That means that an undo step goes back to the last StartUndo (not EndUndo) that the programmer has set. Any nesting is ignored.

I did a few more nesting experiments but I'm not posting them here as they all point to the same behavior. I do not get any errors though, even if I completely botch the sequence - two StartUndo in a row, AddUndo before StartUndo, AddUndo after EndUndo... it actually still works, but with the little limitation that each StartUndo that I issue will break up the sequence and require a new Ctrl-Z to undo. (I am not going into full reverse engineering here now - it would be nice if the documentation could tell us how error cases and nesting are actually handled, though.)

That means that if you have commands that internally perform an Start/EndUndo, you will not be able to get out of the additional Ctrl-Z. Same, I guess, if you issue a StartUndo inside of a function that you wish to reuse (although that may be a problem more suitable for libraries).

You may argue that this is a design flaw. A nested Start/EndUndo could actually be treated like a single subcommand, with a Ctrl-Z working only on the highest level - which would revert the results of a functionality from the view of the outermost Start/EndUndo, while all nested Start/EndUndo pairs on lower levels do not affect the reversal (so you could use a CallCommand including its internal Undos without enforcing another Ctrl-Z in the end). I'm just not sure whether C4D could handle this conceptually, as it would be easy to lose yourself in a tree of Start/EndUndos throughout the program.

Anyway. Your best bet may actually be to skip the CallCommands if possible and perform the necessary change by yourself, so you have a better control over the Undo sequences.
Or you can issue a feature request for a CallCommand with an additional parameter that allows you to suppress the Start/EndUndos that are added internally.

@bentraje I am not using Maya so I can't say anything about that. As a programmer though, I know that there ain't nothing like no free launch... uh, lunch. If Maya is able to undo/redo automatically, then the Python API needs to have that functionality built in (automatic call of something like StartUndo at the beginning, EndUndo at the end, and every API call has an AddUndo integrated. That is possible, yes. You have to pay a price for it though, both in development time (of the API programmers) and in execution time. Maybe that is a good tradeoff; I can't judge that. It's certainly easier for the Python programmer

Personally, I admit that I am a lazy pig and often don't integrate any undo in my scripts. But it is not that difficult as you make it sound right now. You would only have to add an AddUndo at points where you really make a change to the object tree (or related internal data). The actual calculations are unaffected. If you have a really complicated script, it would be best if you create it in layers, with the changes made to the object tree being at as high level in the call hierarchy as possible. This allows for safe exits and controlled error situations. (But we're far off topic now.)

No, you would not need to press Ctrl-Z five times. Look at the following:

import c4d

def main():
    doc.StartUndo();
    obj = doc.GetFirstObject();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    obj = obj.GetNext();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    obj = obj.GetNext();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    obj = obj.GetNext();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    obj = obj.GetNext();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    doc.EndUndo();
    c4d.EventAdd();

if __name__=='__main__':
    main()

(warning: If you execute this script you MUST have 5 objects at top level, or the thing will crash.)
Try it, it will rename the objects; one Ctrl-Z is enough to revert all changes.
Now compare this with the following:

import c4d

def main():
    doc.StartUndo();
    obj = doc.GetFirstObject();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    doc.EndUndo();
    doc.StartUndo();
    obj = obj.GetNext();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    doc.EndUndo();
    doc.StartUndo();
    obj = obj.GetNext();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    doc.EndUndo();
    doc.StartUndo();
    obj = obj.GetNext();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    doc.EndUndo();
    doc.StartUndo();
    obj = obj.GetNext();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    doc.EndUndo();
    c4d.EventAdd();

if __name__=='__main__':
    main()

Here, each AddUndo is encapsulated into a Start/EndUndo block. Now use the script and undo - you will find that each undo only reverts one rename!
So, the Start/EndUndo blocks are the ones that control the "container" that is reverted by Ctrl-Z (as mentioned in my previous post). If you want to revert everything at once, just encapsule the whole execution of the script in the main() function with a Start/EndUndo block. It is not necessary to repeat this block with every method you write.

Now have a look at the following:

import c4d

def main():
    doc.StartUndo();
    obj = doc.GetFirstObject();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    obj = obj.GetNext();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    obj = obj.GetNext();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    doc.EndUndo();
    obj = obj.GetNext();
    obj.SetName("Renamed!");
    obj = obj.GetNext();
    obj.SetName("Renamed!");
    c4d.EventAdd();

if __name__=='__main__':
    main()

Execute and undo... Ooops! Only three renames were reverted! As obvious from the script, two renames are outside of the Start/EndUndo block and have no AddUndo either, so Ctrl-Z will not affect these.

I leave further exploration to you, but I fear you will not get a super simple undo automation as in Maya.

@bentraje Nope. Only the Start/EndUndo containers determine how often you need to hit Ctrl-Z. Not the AddUndos that you issue in between, or the type of these AddUndos. Look at the following:

import c4d

def main():
    doc.StartUndo()
    cube = c4d.BaseObject(c4d.Ocube)
    doc.InsertObject(cube, None, None)
    doc.AddUndo(c4d.UNDOTYPE_NEW, cube)
    sphere = c4d.BaseObject(c4d.Osphere)
    doc.InsertObject(sphere, cube, None)
    doc.AddUndo(c4d.UNDOTYPE_NEW, sphere)
    plat = c4d.BaseObject(c4d.Oplatonic)
    doc.InsertObject(plat, None, sphere)
    doc.AddUndo(c4d.UNDOTYPE_NEW, plat)
    doc.EndUndo()
    c4d.EventAdd()

if __name__=='__main__':
    main()

This code creates a hierarchy of three objects, each with their own AddUndo but all in the same Start/EndUndo block. That means all three objects will be removed at one single Ctrl-Z. Try it.

Also, if you cut out the generation of the objects and put it into a method, this will change nothing, it will just make the Start/EndUndo bracket in your code more visible:

import c4d

def create():
    cube = c4d.BaseObject(c4d.Ocube)
    doc.InsertObject(cube, None, None)
    doc.AddUndo(c4d.UNDOTYPE_NEW, cube)
    sphere = c4d.BaseObject(c4d.Osphere)
    doc.InsertObject(sphere, cube, None)
    doc.AddUndo(c4d.UNDOTYPE_NEW, sphere)
    plat = c4d.BaseObject(c4d.Oplatonic)
    doc.InsertObject(plat, None, sphere)
    doc.AddUndo(c4d.UNDOTYPE_NEW, plat)
        
def main():
    doc.StartUndo()
    create()
    doc.EndUndo()
    c4d.EventAdd()

if __name__=='__main__':
    main()

So you can just do that and put the Start/EndUndo bracket in the top call, and then work your way through your code by only using the proper AddUndos.

Now you will ask, why the different undo types? This helps C4D to determine the extent of change that will be done (mostly, AddUndo comes before the change...), and therefore minimize the amount of data stored in the undo list. For example, if you only change a flag on a polygon object with 100 000 polys, then it would be an excessive waste to store the full object in the undo list. It's quite sufficient to store the BaseContainer, or even a single value from that container, to revert and redo the change. (Keep in mind that you don't just want to undo but at times also to redo an undone operation.)

If you know what the AddUndo really stores for future Undos and Redos, you can save yourself some AddUndos. Try the following code:

import c4d

def create():
    cube = c4d.BaseObject(c4d.Ocube)
    doc.InsertObject(cube, None, None)
    doc.AddUndo(c4d.UNDOTYPE_NEW, cube)
    sphere = c4d.BaseObject(c4d.Osphere)
    doc.InsertObject(sphere, cube, None)
    plat = c4d.BaseObject(c4d.Oplatonic)
    doc.InsertObject(plat, None, sphere)
        
def main():
    doc.StartUndo()
    create()
    doc.EndUndo()
    c4d.EventAdd()

if __name__=='__main__':
    main()

There is only one AddUndo while three objects are generated. But since the two other new objects are linked as children of the first new object, the whole substructure will behave as one - if you undo, you will still see all three objects disappear, and - more important! - if you redo, all three will appear again!

Now, I have no access to the C4D undo code, but obviously the undo cuts the new object from the hierarchy including everything that is attached to it, and keeps the structure intact for a later redo.

If you had linked one of the child objects somewhere else, you would need an additional AddUndo for it, naturally. E.g. if you create the Platonic as top level object, it would no longer be affected by the Undo of a parent object.

@bentraje The Python tag must be evaluated in every redraw of the scene (not just on every frame but far more often; try this by insert a Print in the code...) because it may not just depend on variables but on values from the scene (e.g. "if the object X is placed farther away than 1000 units then move object Y to..."). Keeping track of original values and comparing them with current values like this is nigh impossible (requiring analysis of code semantics), so the tag will be simply re-evaluated whenever encountered.

You can insert an "early exit" in the tag, of course, by testing for changed variables yourself (as you as programmer have more information on the semantics than the Python interpreter/compiler). But you will need to store the values to compare with somewhere, and you will need to take into account that the execution may not happen in frame sequence (e.g. when the user scrubs the timeline backwards).

As for the original question, I tend to put calculations into Python nodes inside the XPresso because plain math calc creates TONS of XPresso nodes that tend to become very confusing. On the other side I keep XPresso nodes whenever I want to see the affected objects in the circuit directly, or when I need a GUI for adapting something (e.g. Range Mapper with spline interface), or when the node does complicated things that I don't want to reprogram in Python (Hair intersection? ... nah, never used that ). When the whole thing is easier to maintain as a Python tag in the end, I put it into the tag...

So it's not so much a question of whether the execution is faster, it's pure convenience of the result for me.

You are probably in need of GetModelingAxis() which reacts to object selections or polygon/edge/point selections.

Here's how I determine the pivot for CollieMouse, which is supposed to be the same pivot that the built-in transformation functionality is using:

	BaseObject* objcenter = doc->GetRealActiveObject(nullptr, nullptr); // GetActiveObject() fails with multiple selections?
	if (objcenter != nullptr)
	{
		Matrix centermat = objcenter->GetModelingAxis(doc);
		pivot = centermat.off;
	}

Note: This is R19 C++, but I can see GetModelingAxis in R20 Python as well.

If this is not what you're looking for, you can take a point as vector, transform this vector by the object's world matrix, and get the world "matrix" for the point. If you need more than one point, use the average of those points.

Actually, Python works differently from C++. A "global" variable there is only global for the current execution context. In Python, variables are not declared; Python creates them when they are first used ("first" meaning, there is no such variable in the current execution context already).

Where a C++ global variable is created at compile time and represents one location in memory throughout, Python globals are created at runtime in their context. Cinema 4D has one context per Python element, so if you are accustomed to C++ globals, the following will irritate you:

• Create two objects with a Python tag
• Write the following code into the tags:

import c4d

def main():
    global x

    if doc.GetTime().GetFrame(doc.GetFps()) == 0:
        x = 1
        print "Tag 0 x set to 1"
    else:
        print "Tag 0 x = ", x
        x += 1

for one tag, and

import c4d

def main():
    global x

    if doc.GetTime().GetFrame(doc.GetFps()) == 0:
        x = 0.5
        print "Tag 1 x set to 1/2"
    else:
        print "Tag 1 x = ", x
        x += 1

for the other. Obviously, the first tag counts on full integers and the second on halfs, both are reset on frame 0.

The output amounts to

Tag 0 x set to 1
Tag 1 x set to 1/2
Tag 0 x =  1
Tag 1 x =  0.5
Tag 0 x =  2
Tag 1 x =  1.5
Tag 0 x =  3
Tag 1 x =  2.5
Tag 0 x =  4
Tag 1 x =  3.5
Tag 0 x =  5
Tag 1 x =  4.5
Tag 0 x =  6
Tag 1 x =  5.5
Tag 0 x =  7
Tag 1 x =  6.5
Tag 0 x =  8
Tag 1 x =  7.5
Tag 0 x =  9
Tag 1 x =  8.5
Tag 0 x =  10
Tag 1 x =  9.5

Obviously, although both tags claim a global x, they access different x's. That's because their contexts are different. Which also means that they cannot exchange data through globals this way. (You can try with an external module that you import, but I don't have time to verify that at the moment.)

If all you want is to store a value between executions of a tag, this is easy to implement this way. However:

• You must make sure that Python creates the variable at some point. Here, I did that through a first value setting at frame 0. Which also means that every time the timeline passes through 0, the value is reset.
• You must pay attention to the evaluation of the object tree. I chose a tag here since the tag is evaluated with the tree every time. That is NOT the case for a generator, as there are caching mechanisms at work.
• You must take care of situations like "jumping around in the timeline", replaying backwards, setting the time explicitly through some other plugin, and such.

Since the OP has asked explicitly for scripts, I would like to add: @m_adam 's "Global" method will not work for scripts, as their Python scope is (apparently) only valid for the current execution. It does work for Python tags and XPresso Python nodes where the scope seems to exist for the lifetime of the tag.

If you work with tags/nodes and have actual variables to store in the globals, you need to account for the timing and the frequency of execution (e.g. do not rely that the next execution is actually the next frame). This will not apply for one-time executions like an initialization, but even there you may want to determine an anchor point (e.g. at frame 0) where the value is reset or calculated for the first time.

@bentraje Meh, I just noticed my first code is not a good example because of what I later wrote. Since the top object of the created hierarchy is already determining the fate of the subobjects, the additional AddUndos have no true function. That does not make it wrong but it does not properly prove what I claim

Try the following:

import c4d

def create():
    cube = c4d.BaseObject(c4d.Ocube)
    doc.InsertObject(cube, None, None)
    doc.AddUndo(c4d.UNDOTYPE_NEW, cube)
    sphere = c4d.BaseObject(c4d.Osphere)
    doc.InsertObject(sphere, None, None)
    doc.AddUndo(c4d.UNDOTYPE_NEW, sphere)
    plat = c4d.BaseObject(c4d.Oplatonic)
    doc.InsertObject(plat, None, None)
    doc.AddUndo(c4d.UNDOTYPE_NEW, plat)
        
def main():
    doc.StartUndo()
    create()
    doc.EndUndo()
    c4d.EventAdd()

if __name__=='__main__':
    main()

Here, the three objects are created independently on top level, yet still all disappear with one CTRL-Z.

(And again, this is true for all types of AddUndo.)

@bentraje Yeah, the second part was meant just in case you have need for a manual process. GetModelingAxis() takes multiselections of elements into account.
However, I believe GetModelingAxis() works by selected mode (as you can have different selections for points, polys, and edges in parallel depending on whether the point, poly, edge, or object mode is active. So if you explicitly need the point selection and use the method in a script, you may want to switch to the point mode before using GetModelingAxis(). (Also, the actual modeling axis can be changed by the tools, so caution is in order. Personally, this is the behavior I needed, so I didn't make any big experiments.)

(Yes, I notice that the thread has been closed, and marked as solved, and I probably shouldn't barge in, but it seems the original script error has never been addressed, so I must mansplain because that's the obnoxious guy I am.)

Two points:

1. The error in the script above is that the index used in SetUseNet is wrong.
   The indices in the BatchRender element list begin at 0, so the first valid index is 0, and the last is GetElementCount()-1.
   dBatchCount starts as GetElementCount(), which is fine as counter, but as an index, it is the first unused index.
   Then this counter is increased += 1, so now it is the second unused index after the list.
   When AddFile is called with that index, it simply adds the file as last element because it cannot leave empty gaps in the list. It returns True although it didn't use the desired index - it used index-1.
   Now SetUseNet is called with the same index. The reason it fails is that this index is not the index that AddFile actually used. This index is not even valid. There is no element with that index. So, nothing happens.
   If you use dBatchCount-1 as index at this point, or simply never increase dBatchCount in the first place, the script works fine.

2. The actual API error is that SetUseNet does not raise an IndexError as the docs claim.
   (Other methods like GetElementStatus do.)

Okay, I go annoy someone else now.

Your file name / path is missing the quote marks.

(Can't check the indents as the code is not properly formatted.)

operator * does not work for you?

@hexbob6 said in Best practices for a plugin containing multiple commands:

The plugin itself allows a custom way of navigating the editor/user selected camera based on custom created Command Data commands. For example, the user presses the 'A' key (arbitrary) to move the camera to one position, the 'B' key (also arbitrary) to move it to another, etc.
I'm curious as to what the recommended best practices are for creating these custom commands as I couldn't find many examples of Command Data plugins that create multiple commands in the sdk or forum examples. The immediately obvious way is to create and register multiple c4d.plugins.CommandData classes within the main .pyp file

Well, as you're asking for best practises, let me put forward a few thoughts.

As Ferdinand already said, it is indeed necessary to give every command its own ID. (And its own icon.) That allows the system to recognize that command everywhere (as you progress, you will find that the ID of a plugin can also be used to identify portions of the saved file, e.g. for an Object plugin) and to include it in the menu, as icon, or as a dialog that can be embedded in a layout and reopened at starting time.

However, the technical prerequisites do not necessarily mirror what's best for the user. Since you use that camera example: Sure, you can let the user press a specific key for each action (or a specific icon in the layout). But this will force the user to remember all these keys, and it will block these keys for any other functionality (regardless of what keys these are). (Or it will take up space in the GUI, if you use the icons.) That raises the question whether single commands really are the way to go for that usecase.

An alternative would be to have a single command, which then opens a menu with all available cameras and/or the possibility to switch to the next/prev camera. This would only need one registered ID with Maxon, since the menu IDs are an internal matter of the single plugin.

Or you can open a dialog instead, where you have buttons / lists for the cameras. You may even have input fields there to pass parameters to the plugin. Here too, all functions would be called through "plugin-local" IDs, and you only need one ID with Maxon (and you occupy only one icon in the layout, or one key on the keyboard... unless, of course, you want to embed that dialog in the layout, which naturally is the user's preference).

Maybe "camera" as example is not quite novel as C4D has the "Use Camera" icon already built in (which lists all scene cameras) so this is pretty much done already.

The other question is whether the functionality is really needed in praxis. I remember that I had the GRIP tools (at that time written in COFFEE if I remember correctly) which had commands to go to the next/previous camera. Later (after the demise of COFFEE) I thought I would miss these, and programmed equivalent scripts in Python. These were indeed separate scripts so you could put them on separate keys for immediate access.

Now, with the hundreds of functions to put on keys, I was at three-letter shortcuts already, so "next camera" would map to V-C-arrow right, and "previous camera" would map to V-C-arrow left (V as in view, C as in camera). You may imagine how many different shortcuts I had (and even though they are logically arranged, I struggle with Modeling Command shortcuts to this day).

And then I finally found that I don't even use "next/prev camera" commands all that often, because I rarely want to go to a camera that just happens to be the next in the object tree, but more often want to switch to a specific camera - for which the "Use Camera" pop-up icon would be fine. Duh!

On the other hand, I also wrote commands to skip in the timeline - 2, 5 or 10 frames forward/backward, or a second forward/backward - these are indeed all commands with separate IDs, and they are all icons in my timeslider! Plus I actually use them Thus, you see that it is not always "wrong" to go with single commands.

---

I am just mentioning that anecdote to underline the importance of usecase analysis and UX design. Whether you really need separate commands, or rather lump it all together under one menu / dialog, depends on how often you use that functionality, how quickly you want to access it with the mouse (layout/icons), how urgent keyboard shortcuts are for this, and how much you want to automate. So, there is no all-encompassing best practice, but rather a situational one:

1. If you need a function at your fingertips, or hop between similar functions quickly, a separate command makes much sense (like the timeline jumping I mentioned) which can be used as keyboard shortcut or as icon.

2. If you have a number of functions that are related (and may be expanded in the future), then you are often better off with a menu. This will only require one ID / one key / one icon to be called up. But on the other side the user will need two interactions (call the menu, select from the menu) to get to the actual function.

3. If you have functions that relate to dynamic data (e.g. call a specific camera), then you cannot go with single commands, as the number of commands is static with your source code. E.g. if you program two camera command slots, you have a command for camera A and a command for camera B, but a potential camera C would not have a slot left! (If you can use the word "slot" in your usecase description, it's a clear sign for this case )
   In that case, you need to go with a dynamic menu or dialog that can catch any number of "slots".

4. If you need to enter additional data, like a parameter, to execute the command, then a dialog is the way to go. E.g. you want to select certain polygons by their slope, then you need a number field where you can specify that slope. Depending on the command, you may want a modal or a non-modal dialog.

5. Finally, if your functionality is highly dynamic and interactive, you can think of doing a tool plugin, where user interactions directly lead to a visible and changeable result. This is advanced magic, though.

Go ahead with the camera commands for practice, but keep an eye on those pesky usecases and how you want the user to interact with the actual functionality; doing is still the best learning.

---

Learn more about Python for C4D scripting:
https://www.patreon.com/cairyn

DTYPE_LONG can be used with SetGeData if the track category is CTRACK_CATEGORY_DATA, see the third post in this thread. This is the only ambiguous datatype at the moment, and as other datatypes wouldn't make sense with SetValue I think it will remain the only one. But I do claim that the category of the track determines whether you need to use SetValue or SetGeData. (That is almost the same in effect... but in case of DTYPE_LONG not quite.)

@ferdinand said in What's really happening inside a CKey?:

I have just updated the Python docs regarding the class CKey. These changes will be reflected in an upcoming release of the Python SDK.

Thank you!

One minor thing for you and to avoid confusion for future readers of this thread: The information brought forwards here that keys of type DTYPE_BOOL must be written with CKey.SetValue() is incorrect.

Hmm, I just tried finding where that was claimed, can't see it right now. Anyway, if you go by the track's CATEGORY, you can easily make the distinction between SetValue and SetGeData. That would work even in ambiguous cases.

okay, I finally got around to put up the scripts to Gumroad. If you want to know exactly what functionalities I implemented there, you can read the description, they are listed one by one:
https://app.gumroad.com/cairyn
The scripts are free, so you can even download them just for giggles.
As described in the prior post, it is not possible to add any of these to the Object Manager while using arrow keys, not even with (theoretically unused) Ctrl- and Alt-combinations.

TL;DR I want to assign a set of scripts that allow me a C4D-globally consistent set of functionalities to "walk the tree".

Long version:

This has to do with the whole arrow key usability concept. These are bound to the OM, and ONLY to the OM, because they use the current OM's specific settings: they skip objects that are not visible (possibly by layer), and skip child trees that are folded (which is a setting valid only for this specific OM as the folding can be different for each open OM).

Now, if you concentrate only on the OM this makes even sense, for the most part: the tree structure is treated as a linearized array of visible objects so moving the "cursor" (a single selection) up and down by arrow key just behaves like in a text: next line, previous line, regardless of the tree depth structure. So if you have a child tree open, the down arrow will take you not to the hierarchically next object but to the child.

Now that is not yet an issue. It makes sense in the context of a single OM if you take into account that the "cursor" moves over the visible elements, so it's WYSIWYG. Fine, locally.

-- But now the actual issues I have:

The first issue arises from the present local behavior. The shift-arrow key functionality to expand a selection moves through the unfolded (open branch) children as well; it selects the next visible element which may either be a child or a successor. Yes, this is consistent with the non-qualified behavior, and it is also consistent with the shift-click range selection. I can see the intent.

But it serves no purpose. As far as I remember, I have never encountered a situation where I wanted to expand-select objects in that way. Either I want to select only the objects on one level - then the functionality should not select the children too. Or I want to select the children but not the parent. Or I want to select all the children recursively - for which there is a separate function, and the expand-select wouldn't work because it skips folded branches.

So, it may be consistent but it's useless. I want a different behavior, which I already have scripts for, but I can't assign them in the OM because the arrow keys are hardcoded.

The second issue is the fact that the OM arrow key behavior is local to the OM. You don't have the same arrow key functionality available in the viewport. You cannot recreate the default behavior in the viewport without scripting, because it is hardcoded on the OM and not available as function in the Customize Command window so you cannot assign it yourself globally. And even if you could, the OM behavior is based on the local properties of a specific OM (status of the folded branches) so it would make no sense.

Nevertheless, I like to have arrow keys available in the viewport. E.g. if you select an object by clicking, but you need the parent of that object instead, so you use arrow-left to get up in the hierarchy. (Sure, you can use the Ctrl-right click method but that works only for objects with a visual representation; it will e.g. show you an SDS but not a Symmetry parent or a Null parent.) Or: You want to select some siblings of the object you clicked; yes you can select them all by clicking but it's far easier by using shift-arrow up/down to expand the selection.

Now I scripted that behavior and assigned it in the viewport (global shortcut, actually), no problem. (I will release the 20 scripts for free on Gumroad shortly if you want to have a look what I'd like in functionality.) All is well...

...except of course that the scripted behavior does not extend to the OM, because there the keys are hardcoded, and the OM-specific functionality can neither be overridden nor removed. So I now have arrow keys that work differently depending on what window is active.

We can argue a lot about whether the arrow keys in the OM are more intuitive the way they are... and I might even agree, and limit myself to overwriting the useless shift-arrow key selection expansion, and add some Ctrl- and Alt- combinations for additional functionality. But I can't even do that! Because the hardcoded functions trigger even if Ctrl or Alt are pressed, and eat up the keystroke for themselves instead of calling the script with that qualifier. So, you cannot add ANY arrow key assignment to the OM. ARRRGGH!

Which brings me directly to the third issue, and I would even go so far as call it a bug. Ah feh, I'd call the 2nd issue a bug already.

Try assigning a global multi-key shortcut using an arrow key in the Customize Command window. This works, e.g. S~Right to select the child of the currently selected object (one of my scripts, but you can use any other command). Do it in the viewport. Null problemo, works fine. Do it in the OM. ...

... it gets weird after opening the tooltip that shows all the followup keys for this multi-key shortcut. Pressing the arrow key (although listed correctly in that tooltip shortcut list) triggers the OM's hardcoded functionality but does not close the tooltip. Pressing the arrow key again closes the tooltip, triggers the hardcoded functionality again, but leaves the internal keystroke system in a curious state, because when I try it again, I see the tooltip for S~S, which probably means that the system still remembers the S stroke from the previous time, and now adds it again.

sigh

Okay, it's something I can live with, at least it doesn't crash. But I don't see why the OM arrow keys are hardcoded at all, instead of working the same way any other functionality works with keyboard shortcuts. There doesn't seem to be anything special about them. (Yes, they use the current OM state but that should not be an issue for a Maxon programmer who has all the neat functions to determine the last used OM - which I don't have as the API doesn't reveal them.)

@m_magalhaes Thanks, I found that thread while researching, but as the original issue is the hardcoding of keys in the OM, it didn't solve the problem... I suppose Maxon will not swap the hardcoded keys for proper shortcut assignments controllable through the Customize Commands window, so I have to live with the limitation

@m_magalhaes Thank you! So, no wonder I'm not finding constants for that

Pity about the arrow keys, I wish they were redefinable. That must be an ancient limitation, as 99% of functions can be reassigned.

Point 4) is interesting, I suppose there is some 8 bit keymap for Russian and Greek. Makes me think about CJK ideograms, but sadly I don't know enough about Asian I18N to guess whether it's relevant