Ok, success. Copying the plugin folder from pc to mac was the issue!

I have been looking at my plugins and my biggest question so far is how to handle urllib2 in a way that will work with both Python 2.7 and 3.7.7. Everything else just seems to be adding parentheses to print functions. I found this Cheat Sheet: Writing Python 2-3 compatible code that suggests: # Python 2 and 3: easiest option from future.standard_library import install_aliases install_aliases() from urllib.parse import urlparse, urlencode from urllib.request import urlopen, Request from urllib.error import HTTPError However, trying that in Cinema 4D threw this error: ImportError: No module named future.standard_library Fortunately, there are some alternatives to try, like # Python 2 and 3: alternative 4 try: from urllib.parse import urlparse, urlencode from urllib.request import urlopen, Request from urllib.error import HTTPError except ImportError: from urlparse import urlparse from urllib import urlencode from urllib2 import urlopen, Request, HTTPError From that article: "urllib is the hardest module to use from Python 2/3 compatible code."

@r_gigante Well ... this is embarrassing. I came up with the R21 code using notes I had collected over the years, and was rather confused seeing this didn't port over to R20. Actually the correct code should look like following: Bool MyUserArea::InputEvent(const BaseContainer& msg) { const Int32 dev = msg.GetInt32(BFM_INPUT_DEVICE); const Int32 chn = msg.GetInt32(BFM_INPUT_CHANNEL); if (dev == BFM_INPUT_MOUSE) { if (chn == BFM_INPUT_MOUSEWHEEL) { const Float wheel = msg.GetFloat(BFM_INPUT_VSCROLL) / 120.0; Int32 mx = msg.GetInt32(BFM_INPUT_X); Int32 my = msg.GetInt32(BFM_INPUT_Y); Global2Local(&mx, &my); ApplicationOutput("Mousewheel value @ at x=@, y=@", wheel, mx, my); return true; } } return false; } No need at all to perform a GetInputState to obtain the the x and y coordinates from, as the BaseContainer to get it from is already provided as "msg". And this works both for R21 and R20. Man ... sometimes you think you know what you're doing, and then it seems you just know squad. Embarrassing! Riccardo, terribly sorry for wasting your time!

@m_magalhaes Thanks for bringing this up, as it seems I had overlooked it on multiple occasions. Which also points me to the fact that the R19 SDK did have a String::operator == () Also overlooked that all those years. I need better glasses.

Ok, made it work now. Thank you so much.

hello @rui_mac without futher information i'll change this thread as resolved tomorrow.

Ok, thanks @r_gigante... I'll keeping going with the workaround.

That's ok, I have meanwhile refactored everything* into a MessageData plugin anyway so the plugin will work** even if the dialog is closed. *Everything except for timer stuff, which for some reason works differently for a dialog than for a message plugin. **There are some strange effects like hanging or crashing application on Close, when the dialog is in certain states. I will need to investigate whether this is an effect of the missing CoreMessage calls or something that happens now due to refactoring.

Hello, as far as I know the licenseID is a temporary session ID that is only used internally. It has no use for third party developers. The hardware ID is based on the corresponding OS functions. So the hardware ID is the same as long the OS thinks the system is the same. Please also notice that, for internal reasons, the format of any of these IDs may change in future releases. Is it up to the studios to decide how they want to license their software. A typical use case could be that a studio creates a single account that is shared in the company. So there would be one user ID for the whole studio. It is up to you to decide if you want to bind your plugin to that user ID or a system ID. best wishes, Sebastian

hello, this thread will be considered as Solved tomorrow is you have nothing to add. Cheers Manuel

@s_bach Aha! That helps! I will see how this works this weekend. :)

Thanks Sebastian, I will try that! /Filip

thanks solved: self.data = {'sphere_size': 15, 'extension_ratio': 1, 'extend_vector': False} kind regards

Thanks Riccardo, It all (well, some of it) starts to make sense after your explanation. A big step forward in starting to understand how to proceed with the MAXON API.

Hi, GeAllocTypeNC() was already removed from the API with version R15 (see API Change List in R15 and maybe more interesting for you Transition to Cinema 4D R15 API). You are already on the right track using NewMem(), now in R20, there's an additional change, which bites you here: The error handling. This indeed is quite an important topic and (of course no bragging involved at all) a really nice feature in the new MAXON API. But it's also the one thing that causes most needed changes for R20. The point is, here at MAXON we do not take error checking lightly. Actually quite the opposite, we enforce error handling where ever we can and our internal developers have no chance to get away without. So, before I provide the solution, here the recommendation to take the time to read the manuals about the Error System. Additionally I recommend the manuals about classic API Entity Creation and Destruction and its MAXON API sibling about Memory Allocation. The additional means you get provided with in the new MAXON API can really make your life easier. I apologize for writing so much before coming to your actual issue. In the end NewMemClear() now returns an Error Result, which basically encapsulates the actual return value and needs to be evaluated in order to get the actual return value. No worries, this is done in a highly optimized form, so it should not impede your code's performance in any way. If you take a look at our SDK examples, you will find quite a few places, where error handling in conjunction with NewMem is demonstrated in various ways. Cheers, Andreas

Good news. And... more good news. The best news are that, after creating a Debug version and running Cinema 4D R20 from XCode, all of a sudden, the plugin started working!!! I then created a simple build (not a Debug one) and it is still working fine :-) The other good news is that I now know how to create a Debug version :-)

This is really weird but after getting this error (and everything all being Ok), the way that I found to get rid of this error is to delete the xcodeproj, the props, the vcxproj and the vcxproj.filters files from the project folder, leaving just the projectdefinition.txt file there, and running the Project Tool again. Then, opening the newly created xcodeproj file, I no longer get this error and it compiles fine.

I found the culprit. My cmyk.cpp file was inside of a folder. When I got it out and placed it alongside the main.cpp file, the project file created by the Project Tool finally opened in XCode. Now I'm getting other errors, but at least the problem reported in this post is solved.

Hello, the Source Processor only checks for coding style violations and creates auxiliary code. It cannot check for valid C++ syntax (because C++ is quite an complex language). Coming back to the issue of return values, only the compiler can check that at compile time. And, yes, unfortunately Visual Studio and Xcode behave differently. best wishes, Sebastian