Licensing Manual

So when I catch it in the Message method ,with c4d.C4DPL_STARTACTIVITY
how do I deactivate the plugin in case the license check went wrong?

Cheers,
Lasse

I tried your plugin in 2025.3.1 (Build 2025_3_1_dec42f629989_1872501510) Win and 2025.3.0 (Build 2025_3_0_dd53fd5fe589_1867889325) OSX (closest version I got on my Mac) with a student license and it just loads fine.

GUI Operations in Boot Phase

I noticed that you are creating dialogs and doing file operations while Cinema 4D is booting (i.e., likely within the __name__ == '__main__' context guard of your pyp file). That is absolutely not allowed.

The registration phase is for registering hooks only. Installing, querying web servers, opening fancy dialogs or doing other shenanigans is absolutely not allowed and can very well lead to malfunctions or crashes. For Python plugins this is less severe as for C++ plugins as Python plugins live in their own fake boot bubble and most systems should have been brought up at this point, but you are still poking the bear.

We had not too long ago a similar case but for license validation. Register your plugin hook(s) in the boot phase and nothing else. When you have some simple serial or other logic as shown in the serial example, you can run it also, everything else must be done later. Then once Cinema 4D has fully booted (c4d. C4DPL_STARTACTIVITY has been emitted) or when the user tries to use your plugin, you can do a complex license check using web servers or install dependencies. You can then force a restart with c4d.RestartMe.This could absolutely be the cause for the issues of the user and it working on most systems does not mean anything.

Fig. I: Doing GUI and file operations while Cinema 4D is loading: this is really bad!

Nested Plugin Package

Your download package creates a nested folder, which sort of sets a trap for less experienced users, as linking the outer folder will cause the plugin not to load (due to the limitation of how Python plugins are discovered compared to C++ plugins). I would recommend a flat structure.

TLDR: I would bet money on the user having linked the wrong folder.

Cheers,
Ferdinand

edit:

And just for completeness, here is your plugin loaded from {c4d}/plugins.

Thanks for the answer. That all makes sense in light of my current understanding.

You can download the trial to test it on your end.

Once prompted with the license dialog you can enter: trial but that would already tell us that he plugin is loaded properly. So looking forward to your feedback!

Thanks & Cheers,
Lasse

Thank you for reaching out to us. In general, we do not regulate users of EDU licenses being able to load plugins or not. The screenshot you sent us just tells the user you cannot manually mount the path {c4d}/plugins as it is an auto-mounted plugin search path. With 2025 we added some minor sanity checks for how plugin paths can be added, so that users cannot 'double dip' the same plugin path and with that cause conflicts.

So, when the user created a path {c4d}/plugins, the plugin should simply load from there, no adding as a plugin path required. You can send me your plugin, and I can see if I can load it in an EDU. It is hard to tell with this little information what is going on and where the fault lies.

In {c4d}/plugins you usually do not have write permissions, so when your plugin tries to write to its own root path, that could be an issue. Or the user did not check the console properly and your plugin actually writes something to the console or throws an error. It could of course also be that there is a bug in Cinema 4D.

I would ask the user:

1 - What is the content of the Plugin Manager (does your plugin show up)?
2 - Ask for a screenshot of a scrolled down Python console.
3 - Common mistake are also over-nested plugins. When you have your plugin as:

foo/
└── bar/
    └── my_plugin/
        ├── res/
        └── my_plugin.pyp

mounting /foo/bar/ as a plugin search path will load your Python plugin, mounting foo will not.

Cheers,
Ferdinand