C4D way for storing options.



  • On 03/10/2017 at 04:13, xxxxxxxx wrote:

    I would like to ask what is the best c4d way for storing options for a command plugin that have a Gedialog for set options.
    I do not ask about saving serial which are often few byte but some options file that can be few mb.

    Using external file (json / XML)

    • Save in the plugin folder.
    • Save in a custom folder inside the temp folder.
    • Save somewhere in pref c4d folder.
    • Save in a custom folder inside the c4d temp folder.

    Using c4d storage.

    • Save under a hyperfile and write in WritePluginInfo.
    • Save as WorldPref.
    • Save as BaseContainer of my c4d.BasePlugin.

    Thanks in advance.



  • On 04/10/2017 at 02:00, xxxxxxxx wrote:

    Hi gr4ph0s, thanks for writing us.

    With reference to your question, there's no single one-way answer representing the "best" way for storing options. The way you design it, heavily depends on how these information should be accessed in a production pipeline or what is the actual expected workflow.

    A few questions popping up in my mind are:

    • should these options be available at the plugin installation time?
    • should these options be copied across different machines?
    • should these options be accessed in a network environment?
    • should these options be accessed/saved concurrently?
    • should these options be different across different Cinema revisions?

    Beside these few additional consideration, the easiest way for storing plugin options is saving them in the plugin's resource folder by using any type of file you'd like to (XML, JSON, or binaries like HyperFile) to grant an higher degree of portability.

    Last but not least, with regard to the point above, consider this documentation page to access Cinema 4D paths out of the box.

    Looking forward to hear your further considerations.

    Best, Riccardo



  • On 04/10/2017 at 04:02, xxxxxxxx wrote:

    Thanks for replying.
    Didn't thought about actually writting HyperFile, I always thought they are memory only and can't be a real file. But I was wrong. Then Thanks a lot for this informations ! Moreover since with HyperFile we can easily control c4d revision it's a very nice FileType.

    For the actual plugin it's only in local, so nothing fancy. And I guess I will go to the HF + Custom folder inside temp c4d folder (GeGetStartupWritePath)

    But I get another plugin idea that would ideally work in a network environment + concurrently. As I know (and I may be wrong) concurrency writting is not possible (wich is quite obvious and I don't want to implement it) but concurrenty reading is only possible in NTFS drive or linux. Isn't it? If yes my solutions are make a queue system or copying file in local then perfom reading?

    A bit off topic and it's can be pretty easily done but is there any functions in the C++ sdk like os.path.join in python? (In order to avoid as much as possible to make change in the source for WIN/MAC compilation)



  • On 05/10/2017 at 02:05, xxxxxxxx wrote:

    Hi gr4ph0s,

    with reference to the os.path.join function delivered by Python I think you can easily replace it the Filename operators as pointed out in the Filename Manual combine section.

    Best, Riccardo



  • On 05/10/2017 at 02:18, xxxxxxxx wrote:

    Thanks a lot ! Now it's seem pretty obvious that would be in Filename.


Log in to reply