Problem Adding description parameter by clicking button and access this

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.