I created a short series of getting started videos for anyone just starting out developing C++ plugins for Cinema 4D. I hope you find them useful.

https://www.youtube.com/playlist?list=PLEPTxkpDVvX0r292yn8xL39Cm3Wi3E69i

Hi everyone,

I have released a plugin I use to create documentation for my plugins.

The plugin is free. Currently available for R20 for Windows. I will add an OSX version if people ask for it.

https://www.plugins4d.com/docs

If you use it for anything let me know. Also if you have any features requests then send them my way.

Cheers,
Kent

Try using the absolute path to where your sdk is: /Users/YourName/Documents/C4D/sdk

https://developers.maxon.net/docs/Cinema4DCPPSDK/html/page_maxonapi_projecttool.html

g_updateproject: Defines the folder the tool should work on. Currently the tool only accepts absolute paths. This is typically the location of the SDK including frameworks and plugins. See SDK Overview.

You can use SetPluginPriority to tell your plugins to load in a specific order. IE tell some plugins to load after others have been loaded. Useful in cases where one of your plugins may register a library that your other plugins need to access as they start up.

@zipit I also want to say that the amount of time you contribute here to help out developers is very generous of you. You are doing an amazing job. I would hope that Maxon would actually pay you some retainer fee for your time or at least provide you with a free subscription for all the help you have given everyone here.

Yesterday I helped someone out with a question. Now they have marked it as deleted. The only reason I would help out on this forum is to help everyone and add to the knowledge pool here in this forum.

So please... do NOT delete your post if you received the answer you were looking for.

I just found that in S22 they have inverted the behaviour of a flag for GetAllAssets.

In R21 there existed a flag ASSETDATA_FLAG::MISSING.

From S22 onwards the functionality of this flag has been inverted and it is now called ASSETDATA_FLAG::NOMISSING.

The problem is that it sets the exact same bit.

So if you have a plugin that is compiled against R21 and your users use it in S22 then your code will not be getting the missing assets anymore, since this bit is set (if you use the MISSING flag) and it will now mean DO NOT get missing assets.

Compiling against the S22 SDK and removing the MISSING flag will fix your bugs if you have any.

Just something to watch out for if anyone is hearing of problems from your users relating to gather up assets. Mainly applies to people writing renderers and dealing with textures and materials.

Cheers,
Kent

I keep seeing comments from the sdk team telling people to please add tags to their posts.

Instead I would recommend you split the "Cinema 4D Development" category back into two like it was, C++ and Python.

Then if someone posts into C++ just add the C++ tag automatically. Likewise for Python.

I myself used to like coming in here and quickly see if there is any C++ questions I can help out on. This new combined approach makes that more difficult so I am no longer doing this. Yes I know I can click on a tag to see all posts, but thats just one more required hunt and click.

I used to really enjoy browsing through plugin cafe, just as much as I did cgtalk or c4dcafe. But this new look and the way it is organized it doesn't feel as nice. Super large fonts and text, images etc... means hardly any information on a single screen. So its hard to quickly see and browse through. But it looks like lots of sites are going this way, which is a shame. I am looking at all these forums less and less now because of this. Maybe I am just old, but I like my concise compact views with loads of info, rather than having to go through pages and pages (or worse this horrible endless scrolling mechanism sites have adopted) of oversized text and clunky cells. On top of that, actually creating this post is painful with this split view and only taking up a tiny part of my screen. But thats another issue.

This site used to feel like a community. But now it feels more like what I guess it was originally designed for... that being an SDK support site. So its almost like this site is a forum based version of a ticketing system like zendesk or freshdesk.

Anyway, this is my vote to move back to two categories. That at least would help.

I am not exactly sure how it works in Python but I will give you a run down of how Global Variables work in C++.

If you set a global variable in C++, and you are using it in a Generator Object, then that variable will be exactly the same in every object in every document that you have open. So if you change the value of it on any object (again in any document you have opened) it will be changed across everything. That is the definition of a global variable. It is global, it is the same everywhere.

Now it may not work exactly like this in python depending on how it is setup in C4D. But in general it is a bad idea to use this for ay variable in something like a generator object.

So even though it might be working for now in a basic test scene, it will come back to bite you once you use it for anything more complex, such as two or more objects.

It all comes down to what it is that you are trying to achieve and what this data is that you are using in a global variable.

In C++ you could use a SceneHook to hold scene wide data. But I don't think that is in Python yet, so the best option to use scene wide data is to use a PluginID as your way to access that data in the preferences for your scene.

For storing a matrix value to compare why don't you just use a local variable in the generator object itself?

Also I would avoid using the word "Save" when you discuss this data, since "saving" and "persistent" mean writing data to disk. And that is not what you are doing. But if you did want to save the value then just make the matrix a description in the resource files for your object generator and access it using the BaseContainer. Then it will be saved automatically.

Cheers,
Kent

Just came across a bug that took me about 2 hours to figure out.

1. Create a AutoAlloc<GeListHead> and add some child nodes. Store this in a GeDialog.
2. In your GeDialog create a TreeView. Set the TreeViewCustomGui->SetRoot( mygelisthead->GetFirst(), &treeviewfuncs, this));
3. In your TreeViewFunctions::GetFirst() { return root;}
4. When setting your treeview layouts, add a checkbox. layout.SetInt32(TREE_COLUMNS_CHECK, LV_CHECKBOX);
5. Implement the functions for IsChecked and SetCheck
6. Run your code and when you click on the checkbox it will enter an endless loop somewhere in the c4dplugins code.

The reason for this is (2). Instead of calling SetRoot(mygelisthead->GetFirst()...). I should have just passed in the GeListHead.

Then for (3) I should have returned the First element: GeListHead op = (GeListHead)root; return op->GetFirst();

With these changes it works, but that took a while to figure out.

I have a plugin that I sell to render farms that does this. You need to develop with C++ and use a scene hook to catch document messages.

My solution allows render farms to call their own Python script immediately after a document is loaded. This allows them to change the paths required by their rendering setup.

If you just want a copy of my plugin instead of developing something yourself then just let me know. You can then modify the Python script to make it do what it is you actually want to do.

https://plugins4d.gumroad.com/l/callpython

Just one last comment on this licensing issue.

I have a video that tells users how to install and license my own plugins for R21 upwards.

It has been viewed 33,882 times as of today. It is my most watched video every month.

https://youtu.be/WV3M8_I3Ovw

I don’t have that many customers or sales.

These views are from regular C4D users using Google to figure out what to do now since the old way is gone.

Don’t worry about the example. I am fine using the SDK methods. I won’t use the new MAXON API for this. So you can mark this as solved if you would like, since the initial question was answered. Thanks, Kent.

@r_gigante This is how the user experience for the previous system went.

1. Copy the last 11 digits of the serial number and paste that on the developers website.
2. They then receive a key which they can then paste into the Help->Personalize dialog of C4D. Done!

• Now there is no standard whatsoever for the user.
• Now there is no dialog where users would even paste in all their license keys.
• To get the information required you have to ask the user to actually start C4D and go to a menu, save out an json file, open that file and find something from it then paste that into the website, BUT there is absolutely no way to check that they have pasted the right thing since there is absolutely no convention to what the format of that data is or should look like. This also ignores the fact that a lot of the time it is not the end user that is purchasing.
• Now even if the user did send the right information, and they did manage to get back a license key, they now have to find the custom location that the developer has specified to actually enter this key. IE there is no longer a standard way.
• And the two points that Orestis mentioned are now longer possible either unless you implement your own custom solution.

Because of all this mess myself and other developers are instead moving to an online system of our own creation in order to avoid anything to do with touching C4D (pre-purchase) at all for this process. Hence the use of GumRoad APIs just to check if a user has a valid license. Or if you have the time and money you would create an online activation system instead against your own customer database (ie 10Duke or a custom solution). Neither of these are solutions for a beginner.

The reason you are not seeing many tickets is because it is now such a damn waste of time, why would anyone bother. So all the indie developers will either not use licensing at all, which is actually the easiest way to go, not release anything, or just leave for another platform like Blender. Looking at the number of tickets is an example of Survivorship Bias.

Maxon has the opportunity to build a world class plugin echo system but continues to ignore vital aspects of how a plugin developer would actually work with customers. You have this incredible SDK Team here doing an amazing job, yourself included, but there is no one out the back thinking about the UX for customers and 3rd Party developers. It is because of this that the plugin market for C4D has continued to shrink. There is no thriving market.

As a side note, it wasn't until I left Maxon and started selling my own plugins that I became aware of these issues. You do not see the issues unless you step outside the bubble and start looking at how a 3rdParty dev would actually sell in real life, and how you would create something with the least friction for the customer as well as create zero support tickets for yourself. You need to go through the pain before you see the problems. And R21 was a huge pain. Months of pain trying to figure out how to do licensing all over again with zero info available.

Right now it is incredibly hard and obfuscated. Where it could be a beautifully crafted experience for the end user and the developer. It would also be a great selling point for Maxon if they spent time actually making a proper solution.

@orestiskon said in Interfacing with Gumroad's API:

The reason I'm going with Gumroad is because it provides a system that I can automate as an indie developer. I can make useful C4D tools and plugins, but I'm not a web developer nor a fully-fledged programmer.

This is the exact same reason I chose GumRoad. It at least allows for a way for a customer to license their plugin without having to extract a Json file from C4D and send that, or parts of that, to the developer. Which the developer then needs to process somehow or handle by hand. It leads to too much confusion and support tickets.

The GumRoad check allows for a hands off licensing approach. I have virtually zero support tickets now.

@r_gigante This not about MAXON making an online store, marketplace or anything like that. It is purely about licensing. Something that MAXON should provide a solution for.

It can be solved with an C4D SDK solution and a simple backend API.

The problem is that no one at MAXON is an external plugin developer trying to sell plugins. So you have never hit these pain point. I have extensive experience with many different online sales platforms now, all in the search for something “simple” that would work with C4D due to the removal of the previous system.

Knowing how online sales systems work and how they can be connected is the knowledge required to be able to understand how an external developer would license the plugins in an automated way. A way to produce a license key that can then be checked by the plugin. This can all be automated. A solution from MAXON can 100% be made that would work for all online stores. I previously talked about this with Rick and Paul when R21 left all developers in the lurch and out on their own. But it seems like there is no interest in this and no budget. I even offered to provide a solution. But I can’t sell that to developers, it should really be done by MAXON.

You could also use your new system and allow developers the ability to lock licenses that way, ie with separate licenses or entitlements and control over seats and orgs etc… But I also have very in-depth knowledge of that system as well and understand how messy that could get. So I think an alternative licensing system built just for the use by external plugin developers would be a good solution.

@r_gigante said in Interfacing with Gumroad's API:

The current system, which is more flexible on checking what hardware/entitlement Cinema 4D is running on and on making the plugin protection mechanism to react accordingly, compared to the previous existing one, is only lacking the ability to have the Maxon Licenses Server serving plugin entitlements to Cinema 4D. While this was handy to offer a floating-license provisioning mechanism for plugins, it has, imho, little to do with the numbers of little guys doing plugin-development and it covers only a fraction of a whole licensing-managing system that goes from selling the licenses to check the license in the host application.

I have to completely disagree here. The previous system had a UI in Cinema 4D to allow users to enter in their License keys for plugins. This was one single place that could be used by a user to enter in the licenses for the plugins they purchased. Now every developer has to implement their own version of this dialog. This leads to a fragmented experience for the user since now every single plugin has its own different way of entering in licenses. And also every developer now has to implement their own version of a license check at startup.

The previous method worked very well for the causal developer who did not want to make an online system. I was pretty shocked when you removed it without any plan for a replacement.

Your current system does work well for you at MAXON. IE the entitlement and licensing system that C4D uses.But that is totally irrelevant to external plugin developers.

@orestiskon said in Interfacing with Gumroad's API:

@kbar Hey Kent, I have one more additional question:

You mentioned the issue with Gumroad keys is you cannot reset them, so you use the AWS database. But if you want to allow users to install it at another machine, couldn't you also allow generating the offline key beyond gumroad's first use? What is the difference?

That’s up to you to allow using it multiple times. But if you don’t limit it then they can post their key online and then everyone can use it, making your product free essentially.

Their license key system is perfect for subscriptions. But for single install software you have to create a system that works for you.

I just use my AWS system as a way to let me reset a license so a user can use the key again.

Or if you write out an offline key to disk then that user could copy it to their second computer manually. I did this for a while but it caused too many support tickets. So instead I limited it and if anyone wants a reset they just contact me.

@orestiskon said in Interfacing with Gumroad's API:

Edit: Nevermind, I think I got how you meant it. The gumroad confirmation allows the creation of the key.

Yes that is what I meant.

But it's so much effort to get there, no wonder there aren't many people developing. It's kind of a feedback loop.

So many developers have left already. Especially on the C++ side. It has been made so difficult now that it is simply not worth it for many. C++ devs that sell plugins are a dying breed. I don't imagine there will be any soon except for the big boys and a couple of us old timers. For small, or indie developers, plugin development does not pay for itself. You have to do it just for the fun of it or for the desire to help people out.

@orestiskon I use the GumRoad API and their License Key System for all my plugins. Here is a quick overview of how you would implement it.

• Enable the license key generation for your product in your gumroad store. This sends the user a key when they purchase
• You then need to implement a way for your users to input that key into their plugins. I have a plugin manager that gives users one location to do this for all of my plugins I sell.
• In your plugin you then call the GumRoad API license endpoint and pass in the Key that the user received.
• The API then returns if the key is valid and how many times it has been used. Each time the endpoint is called you can choose to increase this "used" counter.
• If it has never been used then you then need to generate an offline key that you will store on the users machine somewhere, or in their preferences. This Key would be something like an MD5 Hash of their Cinema 4D User ID, Email Address or System ID combined with some secret key and an identifier for your plugin. UserID+SecretKey+PluginModuleID
• When the user restarts C4D your plugin then looks for this offline key and if found your plugin would run.

The biggest problem with this solution is when users changes machine or move to a new version of C4D. If they haven't backed up their offline key, or if it is not even accessible to them then your GumRoad API key is no longer userful to them.

To remedy this I also have an AWS API that gets called by GumRoad when the purchase. You can add a Callback in your GumRoad account for this. I then call my own AWS API to handle allowing users to re-install the plugins if the GumRoad key has already been used by checking my own API database. Having my own database allows me to reset they keys on my side (something GumRoad doesn't let you do, but I have requested this already from them, ie the ability to reset the Used counter back to zero would do the same thing). But having my own API future proofs me in the event that I wish to move away from GumRoad as well, since I have now essentially built my own licensing system on AWS and may in future remove my dependence on the GumRoad license key generation completely.

I have contemplated providing a monthly service to developers to give them a proper licensing solution for C4D development. But there is really no market for it. There are not enough developers and we are all just wanting to do our own thing for the fun of it mostly anyway.

MAXON really need to sort this out and have an internal system for us developers. It is absolutely insane that they removed the existing system without implementing a replacement. Forcing every developer to roll their own licensing system is a complete waste of time and does away with what the developer wants to do in the first place, which is make a C4D plugin, not spend months investigating and writing their online licensing system.

Actually upon further investigation it doesn't look like OpenEncrypted is able to create an encrypted zip file at all. It just creates a regular zip file that can be extracted using any tool. IE no encryption.

Any insights into how this method should work are appreciated.