Problem Adding description parameter by clicking button and access this

ferdinand

I would not reuse the identifiers of previously removed parameters (when avoidable) as this does violate the Cinema 4D design pattern that parameter identifiers express a purpose. I.e., a parameter Foo with the ID 1000 should not be relabeled as the parameter Bar (with also the ID 1000) . Which is effectively what you are doing here.

As you have discovered yourself, you will then run into value history problems. Other things that can cause problems are undo states that are inexplicable for the user and the preset system.

C4DAtom parameter identifiers below the value 1,000 are reserved for Cinema 4D. Plugin identifiers start at the value 1,000,000, we should not go above this value because there could be other plugins which write data under such plugin ID into the data container of our node. Static parameter identifiers for a plugin, i.e., what you define in a header file, usually do not exceed the value 20,000. Which means that we have 980,000 identifier slots left. There is no need for any house keeping with our identifiers, even when we reserve them in blocks.

A good pattern to setup header files for dynamic descriptions is this:

// Header for Oexample object hook description.

#ifndef _OEXAMPLE_H__
#define _OEXAMPLE_H__

enum
{
  // The identifiers for static parameters.
  ID_GRP_EXAMPLE_MAIN = 1000,
  ID_VAL_EXAMPLE_MAIN_DIAMETER,
  // ...
  ID_GRP_EXAMPLE_OPTIONS = 2000,
  ID_VAL_EXAMPLE_OPTIONS_BLAH,

  // This just a normal enum, we can define here whatever we want, including values that are not 
  // referenced in the res or str files.

  // These values express the range in which dynamic IDs can be found, i.e., the lowest ID can
  // be 10,000 and the highest 20,000. Your plugin has still to conform to that, but it is a good
  // idea to express such information in the header file of the resource.
  ID_EXAMPLE_DYNAMIC_IDS_START = 10000,
  ID_EXAMPLE_DYNAMIC_IDS_END = 20000,

  // The stride with which "logical parameter blocks" are placed. By just reading the header file
  // we now know that there are 10,000 dynamic IDs going from 10,000 to 20,000, placed with a stride
  // of 100, resulting in up to 100 dynamic parameter groups. When this is not enough, you can easily
  // also set #ID_EXAMPLE_DYNAMIC_IDS_END to 200,000 to have 1000 item groups. Or also make your 
  // stride smaller. A value of 100 is probably a bit wasteful for a use case of only a handful of
  // parameters.
  ID_EXAMPLE_DYNAMIC_IDS_STRIDE = 100

}

#endif // _OEXAMPLE_H__

You should also remember to initialize your dynamically added parameters. Which you do not do at the moment in GetDDescription. Doing this will get rid of the problem of 'lingering' values with your current design, but the other problems would remain.

Cheers,
Ferdinand

ThomasB

@ferdinand said in Problem Adding description parameter by clicking button and access this:

Plugin identifiers start at the value 1,000,000,

you probably meant end or?

ok this was my first idea, but my ids starting from 10000
Manuel just said above that you have to empty the BaseContainer, so thought not a bad idea at all

can you still tell me how to empty the container?
if not also ok
I mean I certainly need that in other situations too.

The user deletes the ID, all parameters in the group must be reset.

Have a nice day.

ferdinand

Hi @ThomasB,

you probably meant end or?

No, I meant start. The upper limit of plugin IDs, i.e., "end", is simply +2147483648, the maximum value a signed 32 bit integer can take. The largest plugin ID assigned at the time of writing is 1061082:

Internally, there are exceptions and Cinema 4D ships with some plugins with an ID below 1,000,000 but we can ignore them. The reason why we must respect plugin IDs is that they can also be used as a globally unique address for data containers. I.e., someone could register ID_MY_DATA: int = 1061083 to write his or her data into the data container of a node implemented by you. The plugin ID is then meant to ensure that your plugin does not accidently overwrite that data. From which follows that parameter identifiers should not exceed the value 999,999.

can you still tell me how to empty the container?

You are not really meant to delete a value of a node, you are only meant to modify the data model, i.e., add, remove, or modify parameters. You can call BaseContainer.RemoveData on the data container of a node to remove an entry. But that is not really deleting the value (history).

As stated before, setting a default value once a "new" parameter has been created will fix your problem, even with your current design. No need for deletion. I am not quite sure why Manuel did recommend this pattern, only he can explain that.

Cheers,
Ferdinand

ThomasB

@ferdinand

Ah plugin ID. Sorry, I thought you meant the IDs for the description parameters. Yes, PluginID. Yes, I didn't take that into account when writing the example code

Ok, yes, that would be the best solution to add new unused ids for dynamic ids. I will definitely do that.
But if the user would press a dynamically created reset button, could I use BaseContainer.FlushAll() to only reset the values in that ID group?
Or do I have to use the SetParameter() Method for all parameters.

So if the user has made some settings that don't quite fit and he wants to reset all dynamic parameters in the dynamic group... So they have to be set to the default value.

Best Regards
Thomas

Manuel

@ThomasB said in Problem Adding description parameter by clicking button and access this:

You told me something about cleaning the BaseContainer?
2023-05-11 01-11-45.mp4

hi, that is exactly why i was talking about cleaning the BaseContainer, or to initialise correctly the values. It is even worse if you mix datatype.

I was thinking of the morph tag and the way he does add or remove morph target using the same IDs.

And of course, removing data that you are not using anymore is a good idea.

Cheers,
Manuel

ThomasB

@Manuel
and how do I initialise the parameter if the user presses for instance reset.
With Atom.SetParameter(), right?

Manuel

You can use SetParameter or change the value directly in the BaseContainer. Using SetParameter is a better option if you want to move the data anywhere else outside the BaseContainer. If you do so, you will have to override the NodeData.SetDParameter function to handle your data properly. (note the difference, there is a D in that function name)
Calling SetParameter will work on both cases, storing your data in a BaseContainer or in your own way.
It is always a clever idea to initialise your data.

I would rather clean the BaseContainer when you press the "delete" button. That will avoid having a BaseContainer getting bigger and bigger, especially if you copy paste your generator from document to document.

Cheers,
Manuel

ThomasB

This post is deleted!

ThomasB

This post is deleted!

ThomasB

@ferdinand
I hope it's ok to delete old posts to which I found the answer myself.

So after I have removed now the Data from the Container.
I also keeped track of the already used ID´s in a member variable, to follow your intructions related the Cinema 4D Design pattern.

But is it now also necessary to overwright Read, Write and CopyTo Methods
Or is this negligible, when loading the scene again.

For Instance 10000 and 10100 will be created,
then 10200 will be created and deleted.
An new ID will be created again and gets the ID 10300. (10200 already was used)
Then this 10300 will be deleted again.
The document will be saved.
After loading the document and creating a new ID , next ID will get 10200.

Does this matter. Or is this also important to keep track of the already used ID´s when loading a new doc, or copying the node instance.
Or does it not matter in this case.

Initializing Dynamic parameters:
I still do not now how to Initialize a dynamically created parameter.
I used the DESC_DEFAULT but this seems not to be the right thing.
I look into the plugin example in the sdk for dynamically created parameters.
But this is not really clear for me where he initializes the ID's. He just appends them to a member variable.

I thought this maybe also works with BaseContainter.SetFloat(c4d.DESC_DEFAULT, 50.0) but yes, puff cake

ferdinand

Hello @ThomasB,

first of all, when you store your data in the data container of the node, you do not have to overwrite NodeData.Read, .Write, and .CopyTo as the data container is automatically serialized and deserialized. These methods are only necessary when you want to serialize things which technically cannot, perform badly, or are otherwise undesirable to be expressed in a BaseContainer format.

The automatic serialization of things in the data container of a node applies to all data, i.e., including your dynamic parameters. This is also why I mentioned the rule that your parameter IDs should not exceed 999,999 because other plugins sometimes store data under their plugin ID in your node.

Regarding the ID order. When a new document has been loaded, all the value history data is newly initialized and reusing IDs would therefore not have the same effect anymore. So, things should not be that bad anymore. In the end, there is no absolute right or wrong here, and it depends and what you do. You could also just add a parameter (without an UI, i.e., just an enum value in the header file) to your node which always holds the last used ID slot.

When you play this game long enough, you will of course run at some point out of IDs. But for a stride of 100 and a possible dynamic ID range of [10,000:999,999] you have 9.899 bins, so users would REALLY have to work for reaching that limit.

I personally would for sure build a fail-safe into my plugin that prevents it from going over the ID-limit. I personally would also ensure that parameters that are visually consecutive in the GUI are also consecutive in the data container, i.e., not reuse IDs. If you wanted to, you could also implement a parameter compacting routine which upon a node being allocated, i.e., when there is no value history, compacts parameters from somthing like [10001, 10004, 10006] to [10001, 10002, 10003] so that you can never run out of IDs. I personally would probably not do that given how unlikely such overflow is, I would simply live with the fact that the plugin would stop the user from adding new parameter groups after 10,000 items.

But you can also just reuse IDs, it all depends on how you implement things.

Cheers,
Ferdinand

m_adam

Hello @ThomasB ,

without further questions or postings, we will consider this topic as solved by Friday 02/06/2023 and flag it accordingly.

Thank you for your understanding,
Maxime.