ah, great. I should try the last solution first, next time ;-)

Looks just like mine, so no errors there.

Okay, last try for today: Is your plugin project in the project explorer displayed as bold text? If not, try context menu -> Set as start project (or however the menu point is called in English)

If that doesn't work either, I need to leave the issue to the specialists ;-)

Hmm, on second glance, the error message doesn't even seem to complain about your own plugin... it tries to start a .lib (statically linked library) from the obj directory, which has a cinema.framework name to boot.

Which it shouldn't do, given the fact that you set Cinema4D as start application. At the time when you start the debugger, this .lib should be linked to your cdl64 output already.

What do your settings say under Linker/Debugging? The tabs you show here seem perfectly fine to me...

(Yes, the g_prefspath is my home directory; if you're not using a custom environment, you don't need that parameter.)

You're apparently trying to start the plugin as program. As a plugin is a DLL, it cannot be started on its own. You need to set Cinema4D as the debugging host program.

Where did you put the file? As cld64 is a plugin, it needs to go in a folder with the plugin name together with the res folder, and the whole folder setup goes into the plugins folder of your home directory. (I guess you know that.)

If the folder is in the correct place: You probably have a register function somewhere that you call from your code. (Since the plugin works on one setup, this is apparently the case.)

Do you write some console output during the registration process that would help find the issue?

Do you link some other libraries dynamically to your code, which may be missing? For example, you may need the Visual C++ redistributables on the other computer. Try installing these there, as they are version sensitive.

Ahyup. If you add the following line after setting the driver but before removing the tag:

doc.ExecutePasses(None, True, True, True, c4d.BUILDFLAGS_0)

then the affected object will stay where it is. I would assume the explanation is that between creating and deleting the tag, you didn't give Cinema 4D the chance to actually apply the tag to the object (to move it to the target position). ExecutePasses will enforce the evaluation of the tree and therefore the tag, reposition the target object, and then you can delete the tag again.

EventAdd() doesn't seem to suffice here, as it only refreshes the GUI? I'll leave that for an actual Maxon person to explain ;-)

So, I checked that issue with a manual setup. I found that, indeed, removing an active PSR constraint will leave the affected object in the place where it was last. The original position is apparently lost.

Unfortunately, I was not yet able to make the "live" version do what your script seems to be doing (restoring the original position), with neither option from the script.

I can only guess that it has something to do with EventAdd() not being executed after the insertion. Will keep looking...

Okay, but what do you expect that script to do? You create a constraint - and then you throw the constraint away. Once you have thrown it away, it will no longer influence the scene and, naturally, do nothing.

Do you perhaps assume that the influence of a constraint permanently alters the position of the affected object?

Yes, C4DAtom.CheckType() in Python. Thanks for the confirmation, it bugged me that it was only in the Python doc but not in the C++ doc.

So, I normally use C4DAtom::IsInstanceOf() to get the C4D type of an object, as this function supports the plugin IDs. But in fact, in Python there is another function CheckType() in the same class... and I cannot see what the difference between both is. CheckType doesn't seem to exist in the C++ API.

CheckType returns True if you test against a base type like Obase, just like IsInstanceOf. In the Python documentation, the description for both functions is the same to the letter. Is CheckType just an alias, or is there a semantical difference?

In other posts here, people seem to use IsInstanceOf throughout. Python itself has its own type() and isinstance() functions for the actual class structure, so I am a bit confused now.