Posts made by spedler

When rebuilding my plugins for R2024, I had to notarize the Mac version again for the new builds. The process worked fine, but I noticed that there was a message from Apple stating that the use of 'altool' to notarize was not going to be supported by the end of 2023.

In fact, they now say "The Apple notary service no longer supports altool from November 1, 2023. You use notarytool instead." See https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution

So I looked into using 'notarytool' and surprisingly (for Apple and XCode) it's significantly simpler and faster than the previous method. I've written some notes on how to use it for anyone interested, which are on my site at https://microbion.co.uk/html/r2024macosnotarize.htm

Steve

Thanks Ferdinand. That's very helpful. TBH, for me the best option is probably to support only R2023/4/5 if that just needs the one development environment. It would be different for commercial plugins but for mine I think the most I want to do is support the 2-3 latest versions of Cinema. It just gets too confusing for earlier releases. But it's very useful to know that Monterey/XCode 13 is good for the current two latest releases and maybe the next one too.

Cheers,
Steve

Hi Ferdinand,

Ah, sorry, my mistake. It's just that I find having to work out which version of C4D requires which version of macOS and which version of Xcode very confusing. For example, the requirements for R2023 were initially for Xcode 12.2, now it's given as Xcode 13. Which in turn requires macOS Monterey, not Big Sur which 12.2 needed. Perhaps 12.2 would still work under Monterey if needed, or perhaps not - who knows?

For any new plugin I write, I'll only be building for the latest C4D release, as long as my MacBook can install whatever macOS/Xcode versions are needed. Once it can't, chances are I won't build for macOS at all - since I'm not selling my plugins, there's no point for me in buying an expensive new Mac.

And yes, I know this isn't Maxon's fault. Apple just seem to make it harder and harder to produce anything for their platform, what with incompatible OS and development versions.

Steve

@ferdinand,

Just to add to this, there is some confusion here. See this page from the R2024 SDK docs, https://developers.maxon.net/docs/cpp/2024_0_0/page_maxonapi_plugin_dev.html

The page clearly states Xcode 13.x for R2023 builds:

This is presumably an error?

Steve

Hi Ferdinand,

Thank you very much, that's really helpful. All I'm actually doing is implementing a dynamic description and storing some needed data in the base container. There may be another way to do that rather than using the container, if so I can avoid all this problem by changing the code. The other methods you give will all work but as you say, if I don't really need to do it, best not to in the first place.

Cheers,

Steve

Hi Ferdinand,

Thanks for this. I've read the casting guide but now I'm completely puzzled over what to do if I want to remove C-style casts from my code. In this case, GetDDescription() is passed a const GeListNode*. I want to get the BaseContainer of the BaseObject so I can change a parameter. Surely this is a common practice, but are you saying it can no longer be done?

In such a case, how do you go about it without using a C-style cast? I accept that using const_cast is dangerous...but what is the alternative?

Steve

Thanks, that does indeed work. I thought I had tried that, but clearly not. However, although it compiles it leads to further issues. If you do this, for example:

const BaseObject* op = static_cast<const BaseObject*>(node);
	BaseContainer* data = op->GetDataInstance();

It won't compile, because now you need to do this:

const BaseContainer* data = op->GetDataInstance();

And if you do that, trying to change any parameter using the (now const) BaseContainer also results in errors. So to get this to work you need to do this:

const BaseObject* op = static_cast<const BaseObject*>(node);
BaseContainer* data = const_cast<BaseContainer*>(op->GetDataInstance());

Which finally will compile. The annoying thing is that you might think this would work:

BaseObject* op = const_cast<BaseObject*>(node);

But it gives the same cannot convert error. However, you can do this and it will compile:

GeListNode* dnode = const_cast<GeListNode*>(node);
BaseObject* op = static_cast<BaseObject*>(dnode);

And then you don't need to const_cast the BaseContainer*.

No wonder the SDK examples just stick with C-style casts!

Steve

That's what I thought, so I tried a const_cast like so:

BaseObject* op = const_cast<BaseObject*>(node);

And it still give the same error. Even tried:

const BaseObject* op = const_cast<BaseObject*>(node);

Same error. Only the C-style cast seems to work. It's noticeable that the C-style cast is also used in the SDK examples, and it's worth mentioning that the static_cast worked correctly (i.e. no error) in R2023.

Steve

I'm rebuilding my plugins for R2024 and found an odd problem. It's more a C++ issue than the SDK, so hopefully this is the right place to post.

What happened is this. In my code there are these lines:

Bool MyPlugin::GetDDescription(const GeListNode* node, Description* description, DESCFLAGS_DESC& flags) const
{
	BaseObject* op = static_cast<BaseObject*>(node);	// fails: cannot convert from const GeListNode* to BaseObject*

This fails, the compiler can't do the conversion. But changing it to this line:

BaseObject* op = (BaseObject*)node;

Works fine! I can't see why the C-style cast works but the static_cast doesn't (and I've tried all the other casts such as dynamic_cast and they fail too). Anyone know why this happens?

Steve

Hi @ferdinand,

No problem, I got there in the end and it's actually not too tricky once you know how it's supposed to work. I'll have a go now at a material node, there are more examples of those so hopefully it'll be straightforward. I'll be sure to be back if it isn't!

In the meantime I've uploaded a detailed explanation of all the steps needed to build this kind of node to my site at https://www.microbion.co.uk/html/create_nodes_corenode1.htm so if anyone wants to see how it was done, it's all there. Hopefully it's fairly accurate; all I can say is that this is what I did and it worked for me :relaxed:

Thanks again for your help,

Cheers,
Steve

Okay, so I still don't know why I got duplicate ports but I'm pretty sure it was due to my repeated tinkering with the description and not really knowing what I was doing.

I've now coded a new code from scratch and have got it working correctly with no duplicate ports :grin:

I'm writing a tutorial on how do this if anyone's interested. It'll be on my site in a couple of days. In the meantime this thread can be marked closed because the problem was beyond the keyboard, not in the SDK.

Thanks again to @ferdinand for all the help in getting to this point!

Steve

Hi @ferdinand,

Sure, no problem. Attached is a zip with the compiled binary, the database files and the source.

The source is shamelessly lifted from that in the SDK docs. One thing to be aware of - which might be relevant - is that I had to edit the description include file by hand. This is because I can't get the resource editor to generate the include file. Either it can't find the file to write to (if a relative path is given to the header, it's relative to the location of the C4D executable, and of course the header isn't there) or if an absolute path is provided the resource editor fails with this error on trying to write it:

Don't know what that means! This isn't only the case with my node, if I modify the SDK's example simple core node the same thing happens on trying to generate the include file.

Cheers,

Steve
NodeTest.zip

Okay, I've made some progress with this but I've run into a problem. My node appears in the 'Uncategorized' section in the asset browser, as expected. The layout in the resource editor looks like this:

The preview in the resource editor is this:

Which is all good. But when I add it to the node editor, what appears is this:

Instead of the strings I expected ('Input A' etc.) I just get what look like default strings. However, in the attribute manager I can see my attributes and these default ones:

The node does work, all it does is add two integers, and if I put values into the two input ports the results appears in the output port. But why don't I get my input and output ports instead of these apparently default ones?

Hi @ferdinand,

Firstly, thank you very much for this, which is incredibly helpful. I didn't know you had to turn on the ID switch in the editor prefs but more than that, was how to get the resource editor running as you showed in earlier screen shots.

The resource editor manual says that you can right-click in the node editor window and open the resource editor by clicking 'Edit Resource...'. This either does not work at all (if in material mode) or in scene nodes mode opens the resource editor for what looks like the node editor window itself, which isn't very useful. Anyway, there is no menu entry for the resource editor anywhere in the Cinema menu system as far as I can see, or in the node editor menus, so your method of using the commander to open it is the only way to get to it. That is what was confusing me! Now I can open the resource editor and get most of what the screencast shows, although I didn't get the 'Mode' menu so couldn't switch to developer mode. However, adding the 'g_descriptionEditorDeveloperMode=true' flag does work and I can finally see what you show in the screencast - all the menus and switches (Data/UI/String switches) - so that flag is in fact essential ATM with this build of Cinema.

Now I can actually get to the resource editor I can look at the manual for it and see where it goes. I am sorry if I've been so dense in getting this working. It would be nice though if the dev team could look at the issues of how to open the resource editor because it doesn't match the documentation and might well confuse others as well as me.

So for the moment I can now try adding a simple core node of my own based on the example. If I can, I'll try to write some kind of tutorial for this because it's a tricky process as things stand to even get started.

Thanks once again for being so helpful, it is greatly appreciated.

Cheers, Steve

Hi @ferdinand,

I'm sorry but I'm completely stuck here. I'm starting Cinema with the required flag to enable node description editing. I can drag the example core node into the node editor in either scene or material nodes and it works fine.

If I right-click the editor window when in material nodes mode and choose 'Edit Resource...' nothing happens - that is, the resource editor does not open at all. In scene nodes mode, the resource editor does open but I don't see what is shown in your screenshot, what I get is this:

I've been reading the resource editor manual and what I am doing should work, but doesn't, and the screenshots there are different from what I see. I don't get a Mode or Description menu unlike in your screenshot, and I don't see the language drop-down, or the find text button, etc.

I just can't get it to work. Is it possible that your latest build has corrected problems that currently exist in the latest release, or is it just that I am doing something completely wrong? The only thing I can think of is that I am not passing the parameter to Cinema correctly. I'm using a Windows shortcut to start Cinema with this as the target:

"C:\Program Files\Maxon Cinema 4D 2023\Cinema 4D.exe" g_applicationRepositoryWritable=true

Does this look right?

Steve

Hi @ferdinand,

Thank you for sparing the time you can, I know you must be very busy with other things.

Perhaps I'm going about it the wrong way here. In the node editor, I can drag the Example Core Node from the 'uncategorized' section of the node list into the editor window. To edit the resource for that node, I assumed I would right-click on the example node and somewhere in the context menu, there would be an 'Edit Resource...' entry. That is what happens if I group some nodes together and right-click the group node.

But with the example core node there is no such entry so I can't open the resource editor so can't see or edit the resource. Am I going about this the wrong way? Is there another way to invoke the resource editor?

Steve

Hm, well as I said I have the example core node running but I can't see its resource because when right-clicking on the node the 'Edit Resource...' entry is not in the context menu. I ran Cinema with this command line:

"C:\Program Files\Maxon Cinema 4D 2023\Cinema 4D.exe" g_applicationRepositoryWritable=true

But it doesn't seem to do anything. I'd expected it to enable editing of the example node, but it doesn't. I can use the resource editor on node groups I've created but not this one. What am I missing?

Hi @ferdinand,

This is great stuff, thanks very much! I'm glad I wasn't too far out in my guesstimate of how it all hung together. I got the example core node built and running but found I couldn't edit the decription. I see now that I have to use the mandatory flag to do that, so I'll give that a try.

Thanks again for your help. I may be back if (when) I run into more issues :-)

Cheers,

Steve

Hi @ferdinand,

Many thanks for all the useful info here. I had seen most of it already but it was difficult to pick out which examples were best to start with, so this is very helpful.

I've been experimenting with interfaces and the resource editor using node groups, and I'm gradually getting an idea of how it works. But the process of how to create a new node and its resource is still a bit unclear.

Please correct me if I'm wrong, but as I understand it, the UI for a node is held in a .json file (which Maxon also calls a 'database' from what I can see). Once you have a database you can edit it to define the interface in a new node and the .json file is written out by the resource editor. Am I right so far?

Now the problem is that the nodes API handbook implies that to create the new database (.json file) you need to start Cinema with three command-line parameters as described here. Is this still correct? It seems a bit user-unfriendly if so :-) but I can't find any other way to start the resource editor and create a new database.

Further, the handbook seems to say that you cannot create the node interface in this way until you have a node compiled first, at least a node which registers the (at that point, non-existent) database file. Is this all correct? If so then I've at least begun to understand the process and can start to try to implement something.

Cheers,

Steve

@ferdinand

Thanks, I'll look forward to seeing more detail later. I do feel that the scene nodes are very powerful, but as with many things in Cinema their usefulness will be greater if you have some third-party devs expanding what is available. I think the current system will need a lot more high-level nodes added before the majority of artists (as opposed to coders) use them. That's what I'd like to be doing.

Steve