On 06/09/2013 at 07:30, xxxxxxxx wrote:
Hi guys. Please advise:)
R15 requires "pype" files to be re-enclipted to "pypv".
R14 and lower does not read "pypv" files.
So what should I do? Distribute both files "plugin.pype" and "plugin.pypv" with a plugin? Or is there a more logical way?
P.S. If I keep both "pype" and "pypv" files, all C4D versions seem to work and don't complain.
On 06/09/2013 at 08:02, xxxxxxxx wrote:
The reason why the suffix was changed is that you can keep both files in the same distribution.
http://niklasrosenstein.de/2013/08/cinema-4d-r15-important-python-info/
Best,
-Niklas
On 10/09/2013 at 02:25, xxxxxxxx wrote:
I really wonder what the reasoning behind this is. In my opinion one of the main benefits of Python plugins (and COFFEE plugins as well) was that they were usually downward compatible. I still use a super old COFFEE plugin called chestnuts and I think that's been around since R9.
I heard there were some security issues with the pypes where people got to decrypt the original source code, but AFAIK this was done right in memory with some debugging software, after the pype was decrypted by C4D for execution.
Wouldn't it have been best to simply compile the pyp to byte code and than run that directly instead of implementing some proprietary encryption?
On another note, if Maxon is all that concerned about protecting our sourcecode, why didn't we get a protect button for Python objects, Python xpresso nodes and Python effectors?
This and the slower startup times make the R15 a real letdown for all C4D developers.
On 10/09/2013 at 05:51, xxxxxxxx wrote:
i have not tested r15 yet, how long does it take to load compared to r14 ? twice as long ?
On 10/09/2013 at 06:05, xxxxxxxx wrote:
Well, I haven't stopped the time yet, but it feels like it's about 3x slower. I can't be sure if it is not something with my machine, but I have a Crucial SSD so if it's really an issue, it should be even more noticeable if installed on a disc based HD.
This is especially peculiar, because the added features in R15 are all seem somewhat top-level and shouldn't affect startup times. Maybe Maxon is tweaking the core behind the scenes, and we get a 100% multi threaded release in R16. Who knows.... :dizzy_face:
On 10/09/2013 at 06:19, xxxxxxxx wrote:
Okay, I did a very unscientific comparison (Stoping the time on my smart phone, while simultaneously launching C4D). The result is:
R14 -> 9.7 sec
R15 -> 14.9 sec
So it's not even 2x longer, but still considerably delayed and definitely noticeable, especially if you're restarting for a couple hundred times during development.
On 10/09/2013 at 07:01, xxxxxxxx wrote:
hi,
lol, that is okish for me, I just thought they did something like Adobe - 'Adobe product is
loading - you might want to go and grab a cup of coffee now'. FYI r14 is loading in under 3
seconds for me here. I am talking about the second and ongoing startups, as these are all
considerably faster than the first initial startup after the system has been (re)booted. Might be
a plugin thing, many plugins will of course increase the loading time, but I did not thought, that
they have such an impact.
On 10/09/2013 at 10:49, xxxxxxxx wrote:
You are absolutely right about the plugins. I did some further testing and found out that R15 starts in about 4-5 sec when I rid the user prefs folder of all plugins. At first I thought it was one of the obsolete pype plugins, but it must be one of the good ole C++ ones. Guess I'll have to go one by one. :joy:
In any case I'm happy, that it was simply a problem on my side and not something general with C4D. Why they felt the need to change the Python encryption and not include some legacy support (like they do with about anything else in C4D) is still beyond me. :frowning2:
On 11/09/2013 at 09:41, xxxxxxxx wrote:
I was the first Betatester to report this issue during the development of R15. The developer assigned to this
topic told me it was not possible to support the old encryption in R15 due to the change of the internal
encryption engine. That is all I know.
Best regards,
-Niklas
On 11/09/2013 at 11:20, xxxxxxxx wrote:
Interesting! As far as I know the pypes (now pypvs) get decrypted to plain sourcecode and are then compiled and run by the python interpreter. I don't see why it wouldn't be possible to include two decryption methods, but I guess we just have to take the developers word for it.
Still I wonder, why changing the encryption was necessary at all. As I stated earlier I have some ideas, but so far I get the feeling that this questionable decision brings more bad than good. An official statement by Maxon concerning this matter would have been great.