@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.

Hi Daniel, for the time being I see three options: run Cinema with its own menu bar; drag out the menù containing your CommandData in order to make the cogwheel appear use keyboard modifiers: Alt + LMB -> lunches CommandData::Execute() LMB -> lunches CommandData::ExecuteOptionID() Best, Riccardo

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

Hi Daniel, Thanks a lot, you are indeed right, SimpleMaterial.cpp has been fixed. Cheers, Maxime.

@a_block No need for apologies. I thought the bearded guy had something to do with it ... Hence the reason I posted the message again. Luckily, JIT before the easter bunny was to blame.

Thanks a lot Daniel for following up here. Glad to listen that the update actually fixed it, although even on 20.030 I had no better luck to reproduce. Best, Riccardo