Resource Description ID bug?

[Helper]

On 18/03/2014 at 04:16, xxxxxxxx wrote:

I have successfully got a working deformer-type plugin working in C4D (R14), created using Python.

However ive been hitting a couple of issues with the resource description IDs..

First issue was - i have four object properties described in my .res file, a bit like the following:

CONTAINER Omydeformer
{
	NAME Omydeformer;
	INCLUDE Obase;
	
	GROUP ID_OBJECTPROPERTIES
	{	
		REAL MYDEFORMER_STARTRADIUS	{ UNIT METER; MIN 0.0; }
		REAL MYDEFORMER_ENDRADIUS	{ UNIT METER; MIN 0.0; }
		REAL MYDEFORMER_AMT			{ UNIT METER; MIN 0.0; }
	}
}

With the ID numbers assigned in the .h file like this:

#ifndef _Omydeformer_H_
#define _Omydeformer_H_
  
enum
{
	MYDEFORMER_STARTRADIUS		= 1000,
	MYDEFORMER_ENDRADIUS		= 1001,
	MYDEFORMER_AMT				= 1002,
};
  
#endif

What has been happening is that all of those appeared successfully in my plugin within C4D, however it was only recognising the first two IDs within the code ( throwing moduleobject has no attributeMYDEFORMER_AMT` for example ).

Now, i actually managed to fix this issue, by doing nothing specific, it fixed itself.  I was in the process of creating a duplicate copy of the plugin and starting afresh, after having tried everything i possibly could ( i know how anal Python can be about indentation etc ), when the original copy just started working and recognising the ID`s as it should..

SO - the new problem im having is - it is now recognising everything fine, but has decided to mix up the IDs.  So for example when i assign an initial value to those inside the Init() function, it mixes up the IDs and applies the wrong values to the wrong IDs..

This is really strange and giving me some headaches.  Just wondering at this point - is this a known bug?  Something to do with C4D not re-parsing changes to the resource files or something along those lines?  Pretty stumped here but if theres a workaround im happy to know it..

[Helper]

On 18/03/2014 at 15:01, xxxxxxxx wrote:

The thing that solved this issue for me was using the explicit ID numbers rather than the text identifiers.

So what i had in my .py class was for example:

def Init(self, op) :
		
		self.InitAttr(op, float, [c4d.MYDEFORMER_STARTRADIUS])
		self.InitAttr(op, float, [c4d.MYDEFORMER_ENDRADIUS])
		self.InitAttr(op, float, [c4d.MYDEFORMER_AMT])
		
		op[c4d.MYDEFORMER_STARTRADIUS]= 200
		op[c4d.MYDEFORMER_ENDRADIUS] = 2000
		op[c4d.MYDEFORMER_AMT]= 3
		
		return True

But it was mixing up the values, and applying the AMT value to the STARTRADIUS etc..  When i changed things around to the ID numbers it worked fine, as shown here:

  
def Init(self, op) :
		
		self.InitAttr(op, float, [1000])
		self.InitAttr(op, float, [1001])
		self.InitAttr(op, float, [1002])
		
		op[1000]= 200
		op[1001] = 2000
		op[1003]= 3
		
		return True

As i said the issue seems to be fairly random..  I`m 99% there are no errors on my part, so would still like to know if it is a known issue, maybe a bug that was fixed in later revisions of C4D, or what..

[Helper]

On 22/03/2014 at 03:17, xxxxxxxx wrote:

It is the famous problem with the symbolcache. You have the following options:

1. delete the symbolcache everytime you modified the description resource header

This is not recommended since you will run into problems with your users when you
deliver an updated version of your plugin. You would need to tell them to delete the
symbolcache.

2. use hard-coded IDs or write them as global variables

Much work. Sucks.

3. use a tool to automate #2

Check out my c4ddev module. It won't be a dependency for your plugin, but just a
little helper for your work. I always have a Makefile in my Python projects like this:

symbols:
    python -m c4ddev symbols --format json --description > res/symbols.json

and in my Python plugin

with open(os.path.join(os.path.dirname(__file__), 'res', 'symbols.json')) as fp:  
    res = json.load(fp)
res = type('', (), res)

So instead of c4d.MYDEFORMER_STARTRADIUS you use res.MYDEFORMER_STARTRADIUS.

Best,
Niklas

[Helper]

On 22/03/2014 at 08:12, xxxxxxxx wrote:

Thanks for responding Niklas.

Yeah i ended up just using the hardcoded numbers, bit of a pain but it works.  Caused quite a bit of confusion that little problem, especially for a noob!

Will def check out your module etc.