c4dpy -g_encryptPypFile fails: cannot find pyp file - plugin registration failed

ferdinand

Thank you for reaching out to us. I can reproduce this, and what is even more odd, I can reproduce this back to R25, where it for sure once worked on my machine.

I am quite frankly a bit perplexed by what is going wrong here. This is the code which is failing here:

//Check if a pyp file is currently loaded. Used to check if a user registers a plugin from the pluginmanager. Requires GIL, sets the exception text.
static Bool CheckIfLoadedFromPypFile()
{
	if (!current_plugin)
	{
		CPyErr_Format(PyExc_EnvironmentError, "cannot find pyp file - plugin registration failed");
		return false;
	}
	return true;
}

Since this is failing so far back for me, there are two options:

We overlook something. That seems a bit unlikely, I run my shell as admin and I tried this with multiple plugin files to encrypt. And there is the screen in my old posting where it for sure worked. I also wrote the command line arguments part in the c4dpy manual and I tested there each command I documented.
Something in Windows changed so that now the plugin loading is failing (but only in this context), i.e., current_plugin is null. This sounds even more unlikely.

At the end of the day, this is more @m_adam's domain, as he owns c4dpy. Let me sleep a night over this and also try the same on macOS (or have a look with a debugger when I find the time). When I then cannot find a solution, I will flag this thread as a bug, and Maxime will have to take a look.

I am pretty sure we are overlooking something here ...

Cheers,
Ferdinand

edit: There could be a bug in recent versions of Cinema 4D which does not unload binaries correctly. Try rebooting, I currently cannot do this as I am compiling, will try on Monday.

ezeuz

@ferdinand Good to know it's not just myself. I tried restarting just now and the problem still persists. Looking forward for an update, thanks!

ezeuz

@ferdinand I guess still no luck on this, and it's officially a bug? Would be interested too if you managed to find a temporary workaround.

ferdinand

Hey, I have not had yet time to tackle this, but I will latest by the Monday next week. Cannot tell you much else in the mean time. What certainly does not work is using older versions, I tried multiple versions up to R25 with no luck.

Cheers,
Ferdinand

ferdinand

Hello @ezeuz,

so, I could not reproduce this on macOS, and I also still do not see what we are doing wrong. But I have currently absolutely no time to debug this and instead will just flag this as a bug. @m_adam will have a look when he is back, I have flagged this as critical. In the mean time I must ask you to use the in-Cinema feature of the same name.

Submitted as: 'ITEM#529934 [Python] Encrypting PYP files with c4dpy seemingly broken on Windows'.

Cheers,
Ferdinand

baca

Hi @ezeuz, @ferdinand,

Back in a days, it was run with python file as a second argument, like so:
c4dpy.exe dummy.py -g_encryptPypFile py-commanddata_dialog_r13.pyp
where dummy.py just a blank file.

ezeuz

@baca Nope, not working. It's worse now coz the error doesn't show up, but it's also not encrypted. So silent error.

ferdinand

Yeah, I tested that too. It is correct that you need the dummy scrip for c4dpy, I did that in the old thread and also on MacOS but somehow forgot it here. This of course explains the error message. But the output is still broken, which is why I did not revert this thread.

ferdinand

Hey everyone,

so, I did indeed overlook something here (which I apparently did correctly on MacOS without noticing). Our command line arguments are a bit non standard in that they expect an equal sign between the argument label and value instead of the commonly used whitespace. So, it is -g_encryptPypFile=myfile.pyp and not -g_encryptPypFile myfile.pyp. I have also fixed this in the docs, as this was also incorrect there.

So the full correct syntax would be:

> c4dpy d:\scripts\myscript.py -g_encryptPypFile=d:\plugins\py-commanddata_dialog_r13.pyp

My apologies for the inconvenience,
Ferdinand

ezeuz

@ferdinand Wow, thanks a ton for that! Our workflow was working just fine without c4dpy, so I didn't get to check the forum again, but this is very nice.

Happy new year!