I guess a Python script would do it fine, but I don't use Python. I can write you a quick plugin if that's any use? A plugin would give a few more options than a script I think.
Steve
I guess a Python script would do it fine, but I don't use Python. I can write you a quick plugin if that's any use? A plugin would give a few more options than a script I think.
Steve
Hi rui,
Yes, it's a pain in the neck doing macOS development. I almost gave up on it at one point it's such a hassle. But once you figure out all the hoops to jump through, it's not too bad. You might want to take a look at my guide to notarizing a mac plugin on my site at https://microbion.co.uk/html/createplugins_r23_3_notarize.htm. This explains the steps needed; the first step is the Apple developer account, which is what I think the tutorial you read must have been referring to. Unfortunately, unlike an Apple ID, getting a dev account is not free.
Steve
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
@m_adam Thanks very much for your comments. You asked which parts of the manual page weren't clear. It's more that it's incomplete, in that it doesn't tell you how to get a bundle ID, app password or provider ID. Also, I don't think the statement that adding a timestamp is optional if you enable the hardended runtime is correct - from what I can see, you must provide a timestamp even though you enable the hardended runtime.
The other thing is that invariably at some point the process is going to fail and there's no mention of what to do when it does. It's extremely frustrating when the notarization fails and you have to figure out why. Apart from that, the page is actually very good - just needs a bit more detail (IMO).
Steve
No problem, give me a couple of days to get an initial test version working. Are you on PC or Mac?
Steve
Take a look at the command line arguments passed to the project tool in your screen shot. The project tool is looking in the wrong place.
Steve
Hi Bjorn,
I have a working version of this now which you can download from my site at https://microbion.co.uk/files/rounditr2024.zip
It's PC-only at the moment and requires C4D R2024. Try this and see if it does what you need. There's some basic documentation included which I'll tidy up for the final version.
There doesn't seem to be a DM facility here so we'd better take any further discussion to email. You can get hold of through the contact page on my site (link is in the PDF in the zip file). Do let me know what you think.
Cheers,
Steve
In C++ - I expect it's the same in Python - I would call GeGetPluginPath() to find the absolute path to the plugin, then append the filename to that path. This should work no matter where the user has installed your plugin.
Steve
@kmhfygg I must admit it isn't entirely clear what you are asking for. Since you have developed your plugin already, you are not asking for a licence for C4D itself. And since it's a free plugin, you don't need to licence it to other users.
I'm guessing that you need a plugin ID number, which makes your plugin unique and distinguished from all other plugins. To get that, go to the 'Support' menu at the top of the page, choose 'Plugin IDs' and follow the procedure to receive a new and unique ID number. You need to do that for every plugin you develop and intend to release.
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
Thanks again for your help,
Cheers,
Steve
Excellent. Glad you got it working okay.
Steve
What I meant was, if your resource files are now named curvaturetools.res/h/str then RegisterTagPlugin() must contain the ‘description’ parameter to be “curvaturetools” not “Tpylookatcamera”.
Steve
@mogh If you are using the same code but just different resource files, did you remember to change the resource name in the RegisterTagPlugin() function?
Steve
@mogh Ah, this is the old symbol cache bug/feature. I'd forgotten about that. With Cinema not running, go into the prefs folder - you can get the location by running Cinema, opening the Preferences dialog, and click 'Open Preferences Folder...'.
In that folder you'll see a file called 'symbolcache', probably with today's date. Delete that file, then run/restart Cinema and all should now work with your revised resource files.
AFAIK this was only a problem with Python plugins, not C++. I've tested this in R19, not R20, but my guess is that it's the same in R20.
(Edit - yes, same in R20.)
Steve
@mogh I think it's unlikely to be anything VS Code does. Millions of people use it and I've never heard of a problem caused by whatever line endings it adds.
Much more likely is an error in the resource files. Earlier versions of Cinema were incredibly sensitive to mistakes in the resource and the stock response is to show that message. Misleadingly, it says the error is in the .res file but it could actually be in the matching .h. or .str files.
The most common errors I find are:
There are probably other causes but these are the commonest ones (IMO). If you altered the name of an element .res file of your plugin did you change the .h and .str files to match? And if you did, did you alter the Python source code to use the new name?
Steve
Unfortunately not (in my case) because my MacBook is too old to run Ventura. This means I can only build macOS plugins for R2024 or earlier, because I can’t run R2025 on my Mac (requires Ventura to run). Therefore, I’ve made the decision not to build my plugins for R2025 on macOS until/unless I can afford to buy a newer Mac. It just isn’t worth it for free plugins. If I had a newer Mac I would almost certainly do as you suggest; I’ve done it before with older macOS versions.
Why not just use a BaseArray of the data structures you want to use? Re-initialise this every time InitRender is called then you can iterate through it when needed (presumably in the Output function?).
You’ll also need to implement CopyTo() to make sure the data is available when rendering to the picture viewer.
Steve
Just to note for info, the SDK docs for 2025 have a page for notarizing a Mac plugin. However, it still refers to using 'xcrun altool ...' but as I have just discovered, the use of altool has been discontinued and you must use 'xcrun notarytool ...' instead. The command line is almost the same but slightly different if you don't use a keychain profile but enter your Apple ID, app-specific password, and team ID separately.
Thought I'd mention it so the page can be corrected (in all that wonderful free time I'm sure you have!).
Steve
That’s a very useful site, thank you. I already have Xcode 13.4 installed but I don’t know if it will still be available after upgrading the OS to Ventura. If not, I can get it from there and reinstall.
Hi @ferdinand,
Yes, I've seen those hacks needed to run Xcode 13 on Ventura. TBH, I think while Macs are lovely machines, Xcode as a dev tool is a pig, even more so if you can't match Xcode versions with the OS version, as here.
I'll try installing Ventura then seeing what happens when running Xcode 13 in the way you suggest, but it's getting to the point where supporting macOS for freebie plugins just isn't worth the time and effort required. I'd be interested to hear what the techs say about this. There's an interesting page on Stack Overflow about it.
Cheers,
Steve