ah okay. Well that is true. I assume you want some kind of batch operation here, right? Using c4dpy in the manner I did demonstrate will not bring you any further in this case, as it will replace just one window with another one. But you could pass in a dummy script, e.g., something like this:

Which won't cause the call in a shell script to c4dpy the shell script to halt, as calling c4dpy without a script will launch the live interpreter, while calling it with a script will only execute the script (i.e., the same as the Python binary of vanilla CPython behaves). The content of dummyScript.py is irrelevant, it could be the empty file. With that you could chain multiple calls to c4dpy in a shell script together and execute them in one go, without you having to close the windows.

Cheers,
Ferdinand

@ferdinand said in Python Source Protector: Can it be called via CLI?:

I am not sure how you mean that, g_encryptPypFile will not open any dialogs. What is a "file requester"? Sorry when I am overlooking here the obvious ...

No need to feel sorry. But in this case the obvious is, I would need to close C4D and start it with this command line option only for this specific purpose. And since there is no more -parallel option, I assume that I can't do this in parallel to a running instance. And within the running instance my only option seems to be the command, which opens a file requester.

Since the command line option got added, do we also have an option to call the command in a way, that it does not open a file requester? So that we could script our own source protection mechanisms?

I am not sure how you mean that, g_encryptPypFile will not open any dialogs. What is a "file requester"? Sorry when I am overlooking here the obvious ...

Or could we achieve the same in Python shell ...

Yes.

Is it anything else than creating byte code?

It is fundamentally different. A Python code execution chain is something like this:

[Python Code] --- Python Compiler ---> [Python Byte Code] --- Python Interpreter (VM) ---> [Machine Code]

The source protection does not do anything about this chain (opposed to .pyc files for example, which indeed cut out the step of compiling human readable instructions into byte-code). It instead just puts a step in front of this chain:

[Protected Code] --- Cinema 4D ---> [Python Code] --- Python Compiler ---> [Python Byte Code] --- ...

The files are protected with AES, so cracking the files itself will be (almost) impossible. But since decomplication from byte code is easy in Python, and stuff must reside in memory at some point, "source protection" should be treated more as "source obfuscation". It will not be a hurdle for anyone dedicated to finding out what your code is.

Cheers,
Ferdinand

This feature was added in R23 and can be used like so g_encryptPypFile="PathToPypFile"
You can pass one or multiple pyp file, they should be separated with ;.

Cheers,
Maxime.

In any case, I can't give you an estimate about when it will be implemented.
Cheers,
Maxime.

If this was added to S22 ( or S23 ) then would the resulting pypv files also load in R20 and R21?

Cheers,
Maxime.

I am going to bump this also.This function should be able to be called by command line. I would like to do this via my build system. By calling the cinema4d.exe, or c4dpy, with the python plugin path.

Any updates on this? Would love to see this in conjunction with c4dpy!

Thanks & Cheers,
Lasse

Please use Q&A Functionality for your topics.

It's currently not possible. I've forward the idea.
Cheers,
Maxime.