[crossfire] Archetypes collection changes proposal

Nicolas Weeger nicolas.weeger at laposte.net
Wed Sep 16 04:38:50 CDT 2020


Hello.


I'd like to revamp the archetypes / faces / treasures / etc. "collect" 
mechanism.

This proposal is opened to discussion & suggestions & criticism of course :)

To simplify, I'll call "assets" everything that is in the "arch" repository: 
archetypes, pictures, faces, animations, treasures, artifacts, and what ever 
else I'm missing ;)



The goal: make it easier to add or replace existing assets for contributors, 
simplify assets distribution, and make it easy for server admins to add/remove 
extra or "official" assets.




My proposal:
- have the server recursively browse "data" directory to find all assets
- browse in a deterministic manner (sorted case-sensitive, depth first)
- allow override of defined assets (thus the need to have a deterministic 
browsing pattern)
- remove the requirement for "collect"
- keep the "collect" mechanism to consolidate assets in big files easy for 
distribution - have it work for non official assets too


This way, one could:
- use collected asset files in the "data" directory => have "official" Crossfire 
assets
- use collected asset files, add a directory "my-assets" with additional or 
replacement assets => extend the game
- have an empty "data" directory and a symlink to "arch" repository => use 
trunk assets
- add as many directories as wanted to alter assets as needed
- use "official" collected asset files, and add custom collected asset files
- and so on


I think that for asset contributors it'll be easier to test changes (no need 
to "make do-collect && make install"); it'll allow contributors to distribute 
"asset packs" which can simply be put into data/subdir by server admins; it'll 
make it easy for people wanting to maintain extra/non official stuff without 
messing with the "arch" repository (avoiding conflicts with changes and such).



One big drawback is that the server startup will probably be slower, and the 
code more complex (to handle overriding).

I think that's an acceptable drawback, but that's subject to discussion ;)


Nicolas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.metalforge.org/pipermail/crossfire/attachments/20200916/8569367e/attachment.sig>


More information about the crossfire mailing list