Problem Adding description parameter by clicking button and access this

[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.