Thank you for the detailed description, it's very useful, I have a good understanding now how this should work. Yes, the main goal here is installer optimization. Unfortunately, hosting online is not an option. I'll give it a thorough testing to see if we hit any limitations with this approach, and we might drop the idea if so.

Thanks,
Peter

Thank you for reaching out to us. Yes, you can ship assets as a zipped asset database. To do this, simply select the assets you want to export and run one of the Create > Export ... commands from the Asset Browser menu.

This will leave you then with a database for these assets in zip format, e.g., my_database.zip which you can also rename, e.g., to my_database.db as I did here:

Now we can mount that zip database and can see that the assets are now provided both by the Preferences user database where I created them and our new zip database.

I am not quite sure why you want to use a zip-database, I assume for installer/uninstaller optimization reasons? But I would generally not recommend using zip databases, at least when you plan to programmatically interact with them. When I wrote the Asset API examples, I also created the sdk_asset_database_s26.zip database but then found out bit by bit that zip databases have some limitations. They are not large and I quite frankly do not remember all of them anymore but in this code example I mentioned one of them. Maybe all this has been fixed by now, but I would be surprised as I do not know any users for zipped databases aside from SDK at Maxon.

Hosting your Databases Online

The alternative would be to host your database simply online. There is no magic involved, you just need an ftp, ftps, http, or https server and can then put there your database folder as is. Technically you can also use the full width of protocols supported by maxon::Url, so even fringe things like a Perforce server. For demonstration purposes I have uploaded a small database to developers.maxon.net/downloads/my_online_database. Our server is of course configured in a manner that people cannot snoop around in the file system (the link above will 403) but you can mount that database in Cinema 4D.

On the server this is literally just the dumped database folder:

Before shipping a database in any form, you should always make sure it is properly indexed via the context menu of the database. As you can see here, for example the Arnold user database is not indexed (the icon behind the eye). You can easily fix this via the context menu of the database. Zipped databases are always indexed by default.

Cheers,
Ferdinand