I have built the sdk samples and copied the res folder and the created xdl64 file into
C:\Users\Daniel\AppData\Roaming\Maxon\Maxon Cinema 4D R21_64C2B3BD\plugins\sdk
Starting Cinema 4D without any paths in the preferences and plugins get loaded. No message in the console.
Then adding the path:
C:\Users\Daniel\AppData\Roaming\Maxon\Maxon Cinema 4D R21_64C2B3BD\plugins
to the preferences, restarting Cinema 4D ...
Plugins get loaded, no message in the console window. Thus no collision.
@r_gigante
Good to know to check with value zero, but that isn't exactly what I meant.
You see, when user has the default layout with "Extension" menu part of the macOS menu, at that point the user has no possibility to launch the plugin via the cog wheel.
What I thus meant: is MAXON looking to bring back a way to show and use the cog wheel when using the macOS menu. Or is there a way for the user to launch the plugin with or without option (assuming the macOS menu is used).
@r_gigante
I am not actually giving up, just mentioning that it doesn't seem to make sense pursuing with this topic. As it seems we're not experiencing the same behaviour, as if we're using a different version (although it seems to be the same version number) or we're performing different actions.
Now, I added a new plugin and could not reproduce my previous result with R20.059, as it now always seem to collide whatever I try.
However, with R21 -which was mentioned should always collide- ... well now I get no collisions. According to the printscreen I made you can notice the only path added to the preferences is the <user_prefs>\plugins, exactly the same as the "internal default", still the console shows no collisions.
According to both of you, this is not reproducible at your end. Still I am getting this result. I must then have done something differently than both of you?
Note, the screenshot is right after launching Cinema 4D, and opening the console window and the preference window. No changes performed, simply opening the windows.
@r_gigante
Thanks for confirming the issue.
Should I leave the topic open until a bugfix is provided, or need I close it since not much more can be done at this point in time?
A question on the side, for documentation purposes:
Is a solution being looked at, in order to provide a work around to the known limitation, or provide an alternative way of having the CommandData option available?
I have modified the subject line in order to better indicate there's an issue on macOS. Also added the "issue" tag.
As it has been 5 days without any feedback, I am starting to fear that this is yet another one that cannot be reproduced ...
Tested again, same results.
R20.059
case 2: <user_prefs>\plugins unchecked, D:\R20plugins checked
-> restart -> no collision
R21.026
case 3: <user_prefs>\plugins checked -> no collision.
I really don't get this as I remember having had collisions when I first tried this.
I have tried following:
Removed all paths from the preferences, restart Cinema 4D. Obviously, plugins are loaded due to the default folder, and no collisions since no other path is defined.
I then add the <user_prefs>\plugin folder again, checkbox enabled. Restart -> no collisions.
Went a step further:
I had the <user_prefs>\plugins folder added, then added the <user_prefs> folder (without the "plugins" subfolder) -> restart -> no collision
Went even crazier:
With above 2 paths available (and enabled), I added D:\R21plugins
-> restart -> collisions !!!
Final case:
removed the D:R21plugins, then copied the plugins in the <user_prefs>
resulting in
<user_prefs>\plugins
<user_prefs>\plugins - Copy
Added both paths to the preferences, both enabled -> restart -> collisions
Removed the copy path from the preferences keeping only <user_prefs>\plugins
-> restart -> no collision
Cannot explain the behavior.
I think I will stop the whole topic here, it seems to make no sense at all.
Further testing.
R20.059
Step 1.
Step 2
Step 3
Step 4
R21.026
Step 1
Step 2
Step 3
Step 4
Current results of R21 seem to fit your findings, I must have mixed up results of R21.026 with those of R20.059
Meaning that, indeed, R20.057 (on one machine) matches with the results of R20.059 (on the other machine), no collisions when duplicate paths.
However, I don't understand step 3 on R21.026 doesn't report colliding pluginIDs.
I just don't get it.
@r_gigante
Thanks for taking the time to perform all these tests.
From this I have at least learned that the plugin folder is created during the first launch of the application. It can thus be after the installation of the original R20.0xx (apparently R20.011) I had been looking for a plugins folder in order to already "install"plugins, prior to launching the application.
I am sorry that all this time spent doesn't provide for a conclusive answer, since both our findings are contradicting. I will spend some time rechecking my findings, just to make sure ...
However, the recommendations for plugin installation is quite a surprise, in particular the second bullet:
"do not install a plugin in the Cinema 4D user's preferences folder".
That is exactly the location where the plugin folder gets created at first launch of the application, so I am confused this location is not recommended.
Hi there,
I am finalizing the update of my plugins to R21, and am working on the documentation right now, especially the part about explaining how/where to "install" plugins.
However, my recent experiences have somewhat conflicting results, to the point I am starting to wonder if I am becoming delusional, or my eyes and mind are just playing tricks on me.
I remember from the early days of R20, when installing the application there was NO plugins folder being created, nor in the main application installation folder, nor in the user's location (where library, scripts, prefs, ... are stored by default).
If a user wanted a similar location as was default available in pre-R20 times, one had to create that folder manually and add it as an entry into the Plugins section of the Cinema4D Preferences.
And now comes the weird part ...
On my main development machine, which had the originally release R20.0xx installed, I had manually created this "plugins" folder in my user location, and added that path as an entry in the Plugins section of the preferences. Plugins are thus available in that folder, and when I start Cinema 4D, in the console I see each plugin printing its "welcome-message", indicating it's loaded and ready to perform.
In the meantime I had upgraded to R20.057 and behavior remains the same: plugins get loaded, with welcome-messages in console window.
For various reason R21 is installed on a different machine.
On that same machine, I now have installed R20.059 in order to compare behavior of my plugins between the two Cinema 4D releases.
Strange thing is that after the installation the plugins folder already exists in my user's location. No need to manually create one. Was this change added in recent updates?
More strangely: when I add the path to the plugins folder in the preferences, and restart Cinema 4D I get conflicts in the console windows telling me the plugin IDs are colliding. As if the plugins are loaded twice (twice from the same location, since only a single path was added to the preferences). When I remove the paths from the preferences and restart Cinema 4D, all is fine, no collisions ... and yet the plugins are loaded.
So R20.059 creates a plugins folder, and internally already knows about that path without the need to add it to the preferences?
R20.057 might create a plugins folder, no way to test this as I already had such folder before upgrading to R20.057, but it doesn't complain about colliding plugin IDs. as such it ignores duplicate paths. And when removing the path from the preferences it still does load the plugins. Nice!
Now R21.026 does also create a plugins folder in the user's location (again: Nice!), and when this path is added to the preferences it doesn't complain about colliding pluginIDs. When removing the path from preferences the plugins still get loaded. Just as with R20.057 it seems to internally know about this "default" path, and ignores the duplicate when it's added by the user.
Both R20.057 and R21.026 behave identical where they know about the default path and ignore duplicates. While R20.059 knows about the default path but cannot handle duplicates.
So, R20.0xx did not create the default plugins folder, and obviously didn't internally know about.
Then R20.057 (or earlier) introduced the default plugins folder creation and internally knew about this, ignoring duplicate paths in the preferences.
Then R20.059 came along, still creating the default plugins folder but breaks the "ignoring duplicate paths".
Finally R21.026 creates the default plugins folder and again ignores duplicates.
Could this be confirmed, please.
Just checked on Windows, the cogwheel is present using R21.022 and after upgrading to R21.026 cogwheel is still available on Windows.
So is this a macOS thing only ?
I am updating an R20 plugin to work with R21.
The CommandData has changed, and requires an additional argument in most of its methods. Fine!
Plugin is updated and is available in the "Extensions" menu of R21.
However, in R20 it was available as an entry with a cog wheel behind it, since I had registered the CommandData as:
RegisterCommandPlugin(PLUGINID, GeLoadString(IDS_PLUGINNAME), PLUGINFLAG_COMMAND_OPTION_DIALOG, AutoBitmap("plugin.png"_s), "pluginname"_s, NewObjClear(PluginCommand));
I first converted the R20 code to R21 on Windows, and ran Cinema4D in debug. I didn't notice the cogwheel missing on Windows, it still might be the case, I just have currently no possibility to check it. However, now on macOS it is obviously missing.
Worst is that I seem to be unable to access CommandData::Execute() as selecting the plugin entry in the "Extensions" always seems to bring up the option dialog window, thus actually performing CommandData::ExecuteOptionID().
When I assign a shortcut to the plugin without the "option" checked, then hitting the shortcut will perform the CommandData::Execute().
This is on High Sierra, with a freshly installed R21.026 (this exact morning).
Will need to cross check what happens on Windows 10 ...
Here's a dump from DxDiag:
------------------
System Information
------------------
Time of this report: 9/19/2019, 21:45:45
Machine name: NUC
Operating System: Windows 10 Pro 64-bit (10.0, Build 18362) (18362.19h1_release.190318-1202)
Language: English (Regional Setting: English)
System Manufacturer: Intel(R) Client Systems
System Model: NUC8i5BEH
BIOS: BECFL357.86A.0064.2019.0213.1122 (type: UEFI)
Processor: Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz (8 CPUs), ~2.3GHz
Memory: 32768MB RAM
Available OS Memory: 32636MB RAM
Page File: 2894MB used, 34606MB available
Windows Dir: C:\Windows
DirectX Version: DirectX 12
DX Setup Parameters: Not found
User DPI Setting: 96 DPI (100 percent)
System DPI Setting: 96 DPI (100 percent)
DWM DPI Scaling: Disabled
Miracast: Available, with HDCP
Microsoft Graphics Hybrid: Not Supported
DirectX Database Version: Unknown
DxDiag Version: 10.00.18362.0267 64bit Unicode
---------------
Display Devices
---------------
Card name: Intel(R) Iris(R) Plus Graphics 655
Manufacturer: Intel Corporation
Chip type: Intel(R) Iris(R) Plus Graphics Family
DAC type: Internal
Device Type: Full Device (POST)
Device Key: Enum\PCI\VEN_8086&DEV_3EA5&SUBSYS_20748086&REV_01
Device Status: 0180200A [DN_DRIVER_LOADED|DN_STARTED|DN_DISABLEABLE|DN_NT_ENUMERATOR|DN_NT_DRIVER]
Device Problem Code: No Problem
Driver Problem Code: Unknown
Display Memory: 16446 MB
Dedicated Memory: 128 MB
Shared Memory: 16318 MB
Current Mode: 1920 x 1200 (32 bit) (59Hz)
HDR Support: Not Supported
Display Topology: Internal
Display Color Space: DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709
Color Primaries: Red(0.673828,0.319336), Green(0.187500,0.706055), Blue(0.148438,0.064453), White Point(0.313477,0.329102)
Display Luminance: Min Luminance = 0.500000, Max Luminance = 270.000000, MaxFullFrameLuminance = 270.000000
Monitor Name: Generic PnP Monitor
Monitor Model: DELL 2408WFP
Monitor Id: DELA02C
Native Mode: 1920 x 1200(p) (59.950Hz)
Output Type: HDMI
Monitor Capabilities: HDR Not Supported
Display Pixel Format: DISPLAYCONFIG_PIXELFORMAT_32BPP
Advanced Color: Not Supported
Driver Name: C:\Windows\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_bf9afe57cbde0e11\igdumdim64.dll,C:\Windows\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_bf9afe57cbde0e11\igd10iumd64.dll,C:\Windows\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_bf9afe57cbde0e11\igd10iumd64.dll,C:\Windows\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_bf9afe57cbde0e11\igd12umd64.dll
Driver File Version: 26.20.0100.6912 (English)
Driver Version: 26.20.100.6912
DDI Version: 12
Feature Levels: 12_1,12_0,11_1,11_0,10_1,10_0,9_3,9_2,9_1
Driver Model: WDDM 2.6
Graphics Preemption: Triangle
Compute Preemption: Thread
Miracast: Supported
Detachable GPU: No
Hybrid Graphics GPU: Integrated
Power P-states: Not Supported
Virtualization: Paravirtualization
Block List: No Blocks
Catalog Attributes: Universal:False Declarative:True
Driver Attributes: Final Retail
Driver Date/Size: 28/05/2019 02:00:00, 1887728 bytes
WHQL Logo`d: n/a
WHQL Date Stamp: n/a
Device Identifier: {D7B78E66-7DE5-11CF-36F8-1000BAC2D735}
Vendor ID: 0x8086
Device ID: 0x3EA5
SubSys ID: 0x20748086
Revision ID: 0x0001
Driver Strong Name: oem4.inf:5f63e5341264f0f6:iCFL_w10_DS:26.20.100.6912:PCI\VEN_8086&DEV_3EA5
Extra note:
I now only have the included plugin projects in the solution, and use cinem4dsdk as startup project. No other plugins of mine are part of the solution.
This whole issue reminds me about this:
https://plugincafe.maxon.net/topic/11212/memory-leak-after-plugin-migration-r16-r20
Same situation, memory leaks not reproducible.
Hi Riccardo,
I had installed Visual Studio 2017 Desktop Express, and wasn't able to add the Windows 8.1 SDK during installation due to limited settings being available. So, I uninstalled that one, and instead downloaded the Visual Studio 2017 Community Edition.
Reinstalled all, making sure the Windows 8.1 SDK option was enabled.
Removed the whole SDK folder and extracted once more, completely afresh. Same for the project tool.
I then launched the project tool with the command as you listed (once). Double clicked the solution, and built everything. Now with the Windows 8.1 SDK present I didn't have to retarget every project ... nice!
However, when pressingn F5:
Without the "g_alloc=debug" in the debugging options all runs fine, and after quiting Cinema4D no issues are listed. But, when I add the debugging option I still get the same list of memory leaks and dangling references.
Unfortunately, no progress.
Spoke too soon !!!
The moment I add g_alloc=Debug as Command Arguments of the debugging properties to any of the plugins, I do get the same list of memory leaks and dangling references .
I remember that entry from the time working on R20 and previous releases ... is this not applicable for R21 anymore?
Additionally, every plugin I add to the solution requires me to retarget from Windows 8.1 SDK to the Windows 10 SDK, since the R8.1 isn't installed. Is this 8.1 SDK reference a default of the project tool?
Since Cinema only runs on Windows 10, and plugins thus should be using Windows 10 SDK, why this obsolete 8.1 ?
OK, so I went over it once more.
Step 1.
Deleted the whole SDK_R21 folder, and extracted the sdk.zip to
D:\Projects\Dev\SDK_R21
Step 2
Extracted the project tool
Step 3
created and executed a batch file to create the necessary project files for the frameworks
d:\Projects\dev\SDK_R21\cinema4d_r21_project_tool_20190903\kernel_app_64bit.exe g_updateproject=d:\Projects\dev\SDK_R21\frameworks
Step4
created and executed a batch file for the plugins
d:\Projects\dev\SDK_R21\cinema4d_r21_project_tool_20190903\kernel_app_64bit.exe g_updateproject=d:\Projects\dev\SDK_R21\plugins
Step 5
created and executed a batch file for the plugin solution
d:\Projects\dev\SDK_R21\cinema4d_r21_project_tool_20190903\kernel_app_64bit.exe g_updateproject=d:\Projects\dev\SDK_R21\plugins\project
(This batch file will be used when plugins are added, in order to update the plugins solution)
Step 6
Double click the created plugin.sln, which opens Visual Studio.
Step 7
Build the whole solution, which results in errors for every vcxproj, as it mentions that Windows SDK version 8.1 was not found. Since running on Windows 10 I retarget all the projects ... Visual Studio offers the available Windows SDK 10.0.17763.0
I do this for every framework and plugin in the solution.
Step 8
Rebuild whole solution -> no more build errors.
Step 9
I set the cinema4dsdk as startup project, add the Cinema4D executables as debugging property
Step 10
Launch debugger, wait for Cinema 4D to launch, open the console (Shift-F10), close Cinema 4D ...
Result: ALL GOOD, no memory leaks, no dangling references.
Pffewh! Now I am finally settled, ready to start.
I don't know what went wrong the first and second time, and I am not trying to figure out.
I am surprised as well to see these issue, as I figure I wouldn't be the only one if this were genuine memory leaks. I can only assume something went wrong during my setup of the SDK.
I have started afresh and have extracted the R21 SDK on my D drive at
D:\Projects\Dev\SDK_R21
There a subfolder named "frameworks" has been created with the content of the SDK.zip
Also inside D:\Projects\Dev\SDK_R21 I have a "plugins" folder, which only contains the extracted "cinema4dsdk" folder (I removed maxonsdk.module and microsdk), and a "project" folder, which contains the solution projectdefinition.txt as follows
Platform=Win64;OSX
Type=Solution
Solution=\
plugins/cinema4dsdk
I downloaded the projecttool (20190903) and extracted this into
D:\Projects\Dev\SDK_R21, which created a "cinema4d_r21_project_tool_20190903" folder.
In D:\Projects\Dev\SDK_R21 I created a bat file to execute the projecttool, as follows:
d:\Projects\dev\SDK_R21\cinema4d_r21_project_tool_20190903\kernel_app_64bit.exe g_updateproject=d:\Projects\dev\SDK_R21\plugins\project
I execute this batch file, which generates the plugins solution, which I double click, opening Visual Studio 2017.
I make cinema4dsdk the startup project, enter the Cinema4D executable into the project's debugging properties. Build all (debug, 64bit), start debugging, wait for Cinema 4D to launch, close cinema ... and get the list of memory leaks and dangling references.
As I didn't add a specific plugin folder to the build project, nor did I manually install any plugin, I can confirm there are no plugins available in the Extension menu of Cinema4D.
Windows 10, 64 bit, Professional Edition (build 18362)
4(8)x Intel Core i5-8259U CPU, CPU speed 2310.000
Visual Studio Express 2017 for Windows Desktop Version 15.9.15
Microsoft .NET Framework 4.8.03752
import c4d
def main():
c4d.gui.ActiveObjectManager_SetObject(c4d.ACTIVEOBJECTMODE_OBJECT, op, 0, c4d.ACTIVEOBJECTMANAGER_SETOBJECTS_OPEN)
if __name__=='__main__':
main()
Up to now I was developing my plugins on a Windows 8.1 machine, since R21 requires windows 10 I have now purchased a completely new machine, installed Windows 10 pro, Visual Studio Express 2017 and Cinema 4D R21. Next I have installed the SDK and the project tools.
I then went on writing my first R21 plugin. The only thing it does is display the word "Test" into the R21 console window ... we all need to start somewhere ;-)
// ========================
// Cinema 4D C++ plugin
//
// PluginName: Test
// Dummy "empty" plugin
// ========================
#include "c4d.h"
// ====================================
// Plugin Main
// ====================================
Bool PluginStart(void)
{
ApplicationOutput("Test"_s);
return TRUE;
}
void PluginEnd(void)
{
}
Bool PluginMessage(Int32 id, void * data)
{
switch (id) {
case C4DPL_INIT_SYS:
if (!g_resource.Init())
return FALSE;
return TRUE;
case C4DMSG_PRIORITY:
return TRUE;
case C4DPL_BUILDMENU:
break;
case C4DPL_ENDACTIVITY:
return TRUE;
}
return FALSE;
}
So, I build the plugin, which copies the necessary files to my user's plugins folder of Cinema 4D and start the debugger, which starts Cinema 4D.
The "Test" is displayed into the console, all fine!
Then I close Cinema 4D and Visual Studio then reports:
Memory Leaks Detected:
../../../frameworks/core.framework/source/maxon/basearray.h (140): 8 Memory leaks of 128 bytes (, first leak at 000001C437C6E2C0)
../../../frameworks/core.framework/source/maxon/basearray.h (223): 4 Memory leaks of 40 bytes (, first leak at 000001C43B8CDEC0)
../../../frameworks/core.framework/source/maxon/basearray.h (223): 8 Memory leaks of 128 bytes (, first leak at 000001C437C6CCC0)
../../../frameworks/core.framework/source/maxon/defaultallocator.h (404): Memory leak of 48 bytes () at 000001C43C7E6E00
../../../frameworks/core.framework/source/maxon/hashmap.h (1179): Memory leak of 200 bytes () at 000001C439A22EC0
../../../frameworks/core.framework/source/maxon/hashmap.h (2323): 2 Memory leaks of 1024 bytes (, first leak at 000001C43C7D8380)
../../../frameworks/core.framework/source/maxon/hashmap.h (2331): 2 Memory leaks of 512 bytes (, first leak at 000001C43B9DBA00)
../../../frameworks/image.framework/source/maxon/gfx_image_pixelformat.h (223): Memory leak of 80 bytes () at 000001C43C7EB9C0
../../core.framework/source/maxon/basearray.h (140): 17 Memory leaks of 640 bytes (, first leak at 000001C437B51000)
../../core.framework/source/maxon/basearray.h (223): 14 Memory leaks of 16 bytes (, first leak at 000001C437F190C0)
../../core.framework/source/maxon/basearray.h (223): 7 Memory leaks of 24 bytes (, first leak at 000001C437F1A540)
../../core.framework/source/maxon/basearray.h (223): 3 Memory leaks of 32 bytes (, first leak at 000001C437D92BC0)
../../core.framework/source/maxon/basearray.h (223): Memory leak of 64 bytes () at 000001C439992F00
../../core.framework/source/maxon/basearray.h (223): Memory leak of 80 bytes () at 000001C435E87780
../../core.framework/source/maxon/basearray.h (223): 2 Memory leaks of 112 bytes (, first leak at 000001C437C66EC0)
../../core.framework/source/maxon/basearray.h (223): 18 Memory leaks of 128 bytes (, first leak at 000001C4398FB8C0)
../../core.framework/source/maxon/basearray.h (223): Memory leak of 144 bytes () at 000001C4398FA7C0
../../core.framework/source/maxon/basearray.h (223): 4 Memory leaks of 160 bytes (, first leak at 000001C437C6ABC0)
../../core.framework/source/maxon/basearray.h (223): 4 Memory leaks of 192 bytes (, first leak at 000001C435B2EA80)
../../core.framework/source/maxon/basearray.h (223): Memory leak of 208 bytes () at 000001C43814E700
../../core.framework/source/maxon/basearray.h (223): 5 Memory leaks of 224 bytes (, first leak at 000001C435B2F980)
../../core.framework/source/maxon/basearray.h (223): 2 Memory leaks of 232 bytes (, first leak at 000001C435B2F840)
../../core.framework/source/maxon/basearray.h (223): 2 Memory leaks of 240 bytes (, first leak at 000001C437541440)
../../core.framework/source/maxon/basearray.h (223): 2 Memory leaks of 408 bytes (, first leak at 000001C4395396C0)
../../core.framework/source/maxon/basearray.h (223): Memory leak of 536 bytes () at 000001C439807100
../source/maxon/baseref.h (778): 17 Memory leaks of 24 bytes (, first leak at 000001C437F25DC0)
r:\c4d_perforce_work\release\21.0\frameworks\core.framework\source\maxon\utilities\apibaseid.cpp (19): Memory leak of 39 bytes () at 000001C437BAC640
r:\c4d_perforce_work\release\21.0\frameworks\core.framework\source\maxon\utilities\apibaseid.cpp (19): Memory leak of 40 bytes () at 000001C437BAC340
r:\c4d_perforce_work\release\21.0\frameworks\core.framework\source\maxon\utilities\apibaseid.cpp (19): Memory leak of 41 bytes () at 000001C437C36040
r:\c4d_perforce_work\release\21.0\frameworks\core.framework\source\maxon\utilities\apibaseid.cpp (19): Memory leak of 45 bytes () at 000001C437C35140
r:\c4d_perforce_work\release\21.0\frameworks\core.framework\source\maxon\utilities\apibaseid.cpp (19): Memory leak of 47 bytes () at 000001C437C36340
r:\c4d_perforce_work\release\21.0\frameworks\core.framework\source\maxon\utilities\apibaseid.cpp (19): 2 Memory leaks of 51 bytes (, first leak at 000001C4395D8C40)
r:\c4d_perforce_work\release\21.0\frameworks\core.framework\source\maxon\utilities\apibaseid.cpp (19): Memory leak of 60 bytes () at 000001C4395D9240
r:\c4d_perforce_work\release\21.0\frameworks\core.framework\source\maxon\utilities\apibaseid.cpp (19): Memory leak of 66 bytes () at 000001C435E86940
r:\c4d_perforce_work\release\21.0\frameworks\core.framework\source\maxon\utilities\apibaseid.cpp (19): Memory leak of 82 bytes () at 000001C4399980C0
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\datatypelib_impl.cpp (178): 7 Memory leaks of 40 bytes (, first leak at 000001C437BAC3C0)
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\datatypelib_impl.cpp (178): Memory leak of 48 bytes () at 000001C437C361C0
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\datatypelib_impl.cpp (178): 2 Memory leaks of 56 bytes (, first leak at 000001C439998240)
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\datatypelib_impl.cpp (221): 10 Memory leaks of 272 bytes (, first leak at 000001C435945700)
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (485): Memory leak of 8080 bytes () at 000001C435E46680
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (485): 12 Memory leaks of 12632 bytes (, first leak at 000001C437E6E600)
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (485): 4 Memory leaks of 31112 bytes (, first leak at 000001C4399D6000)
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1528): 21 Memory leaks of 80 bytes (SuperMTable, first leak at 000001C437F85340)
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1528): 3 Memory leaks of 96 bytes (SuperMTable, first leak at 000001C437F7B500)
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1528): 2 Memory leaks of 112 bytes (SuperMTable, first leak at 000001C437C70AC0)
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1528): 3 Memory leaks of 144 bytes (SuperMTable, first leak at 000001C437C69BC0)
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1528): 2 Memory leaks of 192 bytes (SuperMTable, first leak at 000001C43814E340)
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1528): Memory leak of 224 bytes (SuperMTable) at 000001C435B12EC0
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1528): Memory leak of 288 bytes (SuperMTable) at 000001C43949DBC0
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1528): Memory leak of 304 bytes (SuperMTable) at 000001C4374EFEC0
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1528): 9 Memory leaks of 400 bytes (SuperMTable, first leak at 000001C437B61FC0)
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1528): Memory leak of 416 bytes (SuperMTable) at 000001C437B5B1C0
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1528): Memory leak of 688 bytes (SuperMTable) at 000001C4359D9D80
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1867): 4 Memory leaks of 16 bytes (net.maxon.image.colorspace.rgb, first leak at 000001C437BAFDC0)
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1867): 11 Memory leaks of 24 bytes (net.maxon.image.class.imagechannelPix8u, first leak at 000001C4379D9980)
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1867): Memory leak of 56 bytes (net.maxon.drawport.class.openglwindowframebuffer) at 000001C457D91DC0
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1867): 3 Memory leaks of 72 bytes (net.maxon.class.observable, first leak at 000001C457D91D00)
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1867): Memory leak of 120 bytes (net.maxon.drawport.class.openglwindowframebuffertargetset) at 000001C458C79440
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1867): 2 Memory leaks of 224 bytes (net.maxon.image.class.pixelformat.RGB.F16, first leak at 000001C435B309C0)
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1867): 2 Memory leaks of 232 bytes (net.maxon.image.class.pixelformat.RGBA.F32, first leak at 000001C435B31A00)
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1867): 5 Memory leaks of 400 bytes (net.maxon.drawport.class.openglcommandlistemulated, first leak at 000001C44230B5C0)
r:\c4d_perforce_work\release\21.0\frameworks\kernel.framework\source\implementation\object_impl.cpp (1867): Memory leak of 528 bytes (net.maxon.drawport.object.opengl) at 000001C45857BC80
62 blocks not freed
Dangling References Detected:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformat.RGB.U8 at 000001C435B2FAC0 holds 5 references to the following objects:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformat.RGB.U8 at 000001C435B2FAC0 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.pixelformat.rgbgroup at 000001C437F1B8C0 (offset 0xa8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix8u at 000001C437D9BFC0 (offset 0xc8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix8u at 000001C437D0BFC0 (offset 0xd0)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix8u at 000001C437BB12C0 (offset 0xd8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformat.RGB.F16 at 000001C435B309C0 holds 5 references to the following objects:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformat.RGB.F16 at 000001C435B309C0 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.pixelformat.rgbgroup at 000001C437F1B8C0 (offset 0xa8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix16f at 000001C437D9EAC0 (offset 0xc8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix16f at 000001C437D19840 (offset 0xd0)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix16f at 000001C437BB53C0 (offset 0xd8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformat.RGBA.U8 at 000001C435B313C0 holds 6 references to the following objects:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformat.RGBA.U8 at 000001C435B313C0 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.pixelformat.rgbagroup at 000001C437B972C0 (offset 0xa8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix8u at 000001C437D9BFC0 (offset 0xc8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix8u at 000001C437D0BFC0 (offset 0xd0)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix8u at 000001C437BB12C0 (offset 0xd8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix8u at 000001C4379D9980 (offset 0xe0)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformat.RGBA.F32 at 000001C435B31A00 holds 6 references to the following objects:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformat.RGBA.F32 at 000001C435B31A00 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.pixelformat.rgbagroup at 000001C437B972C0 (offset 0xa8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix32f at 000001C437D9D2C0 (offset 0xc8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix32f at 000001C437D19A40 (offset 0xd0)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix32f at 000001C437BB4FC0 (offset 0xd8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix32f at 000001C4379E9B00 (offset 0xe0)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix8u at 000001C4379D9980 holds a reference to one object:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix8u at 000001C4379D9980 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix32f at 000001C4379E9B00 holds a reference to one object:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix32f at 000001C4379E9B00 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformatdynamic at 000001C437B5B5C0 holds 3 references to the following objects:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformatdynamic at 000001C437B5B5C0 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.pixelformat.dynamicgroup at 000001C437D9FF40 (offset 0xa8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.colorspace.rgb at 000001C437BAFDC0 (offset 0x138)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformatdynamic at 000001C437B5C3C0 holds 3 references to the following objects:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformatdynamic at 000001C437B5C3C0 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.pixelformat.dynamicgroup at 000001C437D9FF40 (offset 0xa8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.colorspace.rgb at 000001C437BAFDC0 (offset 0x138)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformatdynamic at 000001C437B5C5C0 holds 3 references to the following objects:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformatdynamic at 000001C437B5C5C0 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.pixelformat.dynamicgroup at 000001C437D9FF40 (offset 0xa8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.colorspace.rgb at 000001C437BAFDC0 (offset 0x138)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformatdynamic at 000001C437B5D3C0 holds 3 references to the following objects:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformatdynamic at 000001C437B5D3C0 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.pixelformat.dynamicgroup at 000001C437D9FF40 (offset 0xa8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.colorspace.rgb at 000001C437BAFDC0 (offset 0x138)
kernel.framework\source\implementation\object_impl.cpp (1867): image.pixelformat.rgbagroup at 000001C437B972C0 holds a reference to one object:
kernel.framework\source\implementation\object_impl.cpp (1867): image.pixelformat.rgbagroup at 000001C437B972C0 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.colorspace.rgb at 000001C437BAFDC0 holds a reference to one object:
kernel.framework\source\implementation\object_impl.cpp (1867): image.colorspace.rgb at 000001C437BAFDC0 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix8u at 000001C437BB12C0 holds a reference to one object:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix8u at 000001C437BB12C0 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix32f at 000001C437BB4FC0 holds a reference to one object:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix32f at 000001C437BB4FC0 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix16f at 000001C437BB53C0 holds a reference to one object:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix16f at 000001C437BB53C0 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix8u at 000001C437D0BFC0 holds a reference to one object:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix8u at 000001C437D0BFC0 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix16f at 000001C437D19840 holds a reference to one object:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix16f at 000001C437D19840 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix32f at 000001C437D19A40 holds a reference to one object:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix32f at 000001C437D19A40 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix8u at 000001C437D9BFC0 holds a reference to one object:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix8u at 000001C437D9BFC0 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix32f at 000001C437D9D2C0 holds a reference to one object:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix32f at 000001C437D9D2C0 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix16f at 000001C437D9EAC0 holds a reference to one object:
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.imagechannelPix16f at 000001C437D9EAC0 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.pixelformat.dynamicgroup at 000001C437D9FF40 holds a reference to one object:
kernel.framework\source\implementation\object_impl.cpp (1867): image.pixelformat.dynamicgroup at 000001C437D9FF40 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.pixelformat.rgbgroup at 000001C437F1B8C0 holds a reference to one object:
kernel.framework\source\implementation\object_impl.cpp (1867): image.pixelformat.rgbgroup at 000001C437F1B8C0 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): drawport.class.openglcommandlistemulated at 000001C44230B5C0 holds 3 references to the following objects:
kernel.framework\source\implementation\object_impl.cpp (1867): drawport.object.opengl at 000001C45857BC80 (offset 0x20)
kernel.framework\source\implementation\object_impl.cpp (1867): drawport.class.openglwindowframebuffertargetset at 000001C458C79440 (offset 0x30)
kernel.framework\source\implementation\object_impl.cpp (1867): drawport.class.openglcommandlistemulated at 000001C44230B5C0 (offset 0x180)
kernel.framework\source\implementation\object_impl.cpp (1867): class.observable at 000001C457D91B80 holds 2 references to the following objects:
kernel.framework\source\implementation\object_impl.cpp (1867): class.observable at 000001C457D91B80 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): drawport.object.opengl at 000001C45857BC80 (offset 0x10)
kernel.framework\source\implementation\object_impl.cpp (1867): class.observable at 000001C457D91C40 holds 2 references to the following objects:
kernel.framework\source\implementation\object_impl.cpp (1867): class.observable at 000001C457D91C40 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): drawport.object.opengl at 000001C45857BC80 (offset 0x10)
kernel.framework\source\implementation\object_impl.cpp (1867): class.observable at 000001C457D91D00 holds 2 references to the following objects:
kernel.framework\source\implementation\object_impl.cpp (1867): class.observable at 000001C457D91D00 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): drawport.object.opengl at 000001C45857BC80 (offset 0x10)
kernel.framework\source\implementation\object_impl.cpp (1867): drawport.class.openglwindowframebuffer at 000001C457D91DC0 holds 2 references to the following objects:
kernel.framework\source\implementation\object_impl.cpp (1867): drawport.class.openglwindowframebuffer at 000001C457D91DC0 (offset 0x20)
kernel.framework\source\implementation\object_impl.cpp (1867): drawport.class.openglwindowframebuffertargetset at 000001C458C79440 (offset 0x28)
kernel.framework\source\implementation\object_impl.cpp (1867): drawport.object.opengl at 000001C45857BC80 holds 15 references to the following objects:
kernel.framework\source\implementation\object_impl.cpp (1867): drawport.object.opengl at 000001C45857BC80 (offset 0x8)
kernel.framework\source\implementation\object_impl.cpp (1867): class.observable at 000001C457D91B80 (offset 0x60)
kernel.framework\source\implementation\object_impl.cpp (1867): class.observable at 000001C457D91C40 (offset 0x68)
kernel.framework\source\implementation\object_impl.cpp (1867): class.observable at 000001C457D91D00 (offset 0x70)
kernel.framework\source\implementation\object_impl.cpp (1867): drawport.class.openglcommandlistemulated at 000001C44230B5C0 (offset 0x150)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformatdynamic at 000001C437B5B5C0 (offset 0x170)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformatdynamic at 000001C437B5C5C0 (offset 0x178)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformat.RGB.U8 at 000001C435B2FAC0 (offset 0x180)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformat.RGBA.U8 at 000001C435B313C0 (offset 0x188)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformatdynamic at 000001C437B5C3C0 (offset 0x1b0)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformatdynamic at 000001C437B5D3C0 (offset 0x1b8)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformat.RGB.F16 at 000001C435B309C0 (offset 0x1c0)
kernel.framework\source\implementation\object_impl.cpp (1867): image.class.pixelformat.RGBA.F32 at 000001C435B31A00 (offset 0x1c8)
kernel.framework\source\implementation\object_impl.cpp (1867): drawport.class.openglwindowframebuffer at 000001C457D91DC0 (offset 0x1f0)
kernel.framework\source\implementation\object_impl.cpp (1867): drawport.class.openglwindowframebuffertargetset at 000001C458C79440 (offset 0x200)
kernel.framework\source\implementation\object_impl.cpp (1867): drawport.class.openglwindowframebuffertargetset at 000001C458C79440 holds 2 references to the following objects:
kernel.framework\source\implementation\object_impl.cpp (1867): drawport.class.openglwindowframebuffer at 000001C457D91DC0 (offset 0x60)
kernel.framework\source\implementation\object_impl.cpp (1867): drawport.class.openglwindowframebuffertargetset at 000001C458C79440 (offset 0x70)
This can't be right.
Hi again,
I am about to start porting my plugins to R21 and hence have been looking into the new plugin licensing manual of the R21 SDK documentation.
Most of the information is quite clear, except for a few details I am missing.
(I am sure most will understand the general concept of the information, but might also be interested in some of the details below. So, while this post is for my own benefit, I hope it can also provide information to others)
Example is the call GetGeneralLicensingInformation. It provides productId, systemId, userId, licenseId and userName.
Obviously, the productId is an identification of the product and would rather be useless for purpose of plugin registration, except in those cases where there's a need to know difference between cinema4D or teamrender, and commercial versus education, lite, nfr, etc ..
However, in most cases, plugin developers might skip this productId to generate plugin licenses.
The systemId, being hardware related might be useful to distinguish between different workstations, although hardware-upgrades performed by user overtime might result in a same workstation to be detected as a different one. (correct ?)
The userId seems to be the most potential piece of information to be used for flexible plugin licensing, in the way that a single user can have different workstations (work and home) for a single cinema4d license. Here the systemId will be different but the userId not. To be flexible and allow a same user to purchase a single plugin license (to be used on a home or office workstation) it seems the easiest would be to only use the userId for generating the plugin license.
But what about a single user / company having multiple licenses? Is the userId the same for all licenses?
Documentation also doesn't mention the licenseId. Is this something which changes each time a new rental contract is started? What about next Cinema4D releases? Do these affect any of the Ids?
Probably not the userId, nor the systemId. Maybe the productId? What about the licenseId?
So, while the Plugin Licensing Manual provides quite some information, it still leaves out specific details needed to know, as a 3rd party developer, what exactly to use.
@a_block said in Good Bye and Thanks for the Fish:
I'm not quite sure where you are heading and which plot recently unraveled
Hi Andreas,
Nice to hear from you.
Ah ... seems we're definitely not on the same page.
Sorry to talk in riddles.
What I was referring to, was related to what we discussed in December-January past.
I had some questions related to serial numbers, and as the topic was quite delicate we communicated via e-mail.
As you required more time to provide the needed answers you asked me to be patient. Time went on and on, and I finally wrote back. Triggering for an update, jokingly telling that like any good story one need to raise suspense before giving away the ending, and that you were quite good at it ... (building up the suspense in our "communication-novel", I mean).
Then, out of the blue, you mentioned leaving. Quite a different ending to our novel then I had expected.
And now, with the recent R21-announcement, all became clear. No more serial numbers in the future.
So yes, all questions got now answered ... what a twist in that novel ending.