Re: [crossfire] Archetypes collection changes proposal
This idea seems reasonable. The original collection dates back to a time when hard drives were much slower (and amount of memory in systems was less, so likelihood of that data being cached was low) Like Kevin, I'm not sure if there is still need for collected archetypes - the tar file could just be distributed as is now, and have it unpacked as part of the install. At least for the .arc files, in theory, I think a 'cat */*.arc > everything.arc' would more or less work - archetype files can currently have more than one archetype. The issue is the png files - those can not be simply combined - some form of container would be needed, whether that is zip, tar, or custom format currently used. One advantage in the past was that having large files was more efficient if you wanted to compress them, but that isn't an issue now days. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Archetypes collection changes proposal
On 9/16/20 2:38 AM, Nicolas Weeger wrote: > 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 ;) Do maps have a place here, as well? > 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. These sound like good goals to me. > 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 To keep things simple, why keep the collect mechanism? Couldn't we put the "official" assets into a big ZIP file, and teach the server how to open ZIP files like ordinary directories? Scan the index, create sorted case-sensitive depth-first order, etc. > 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 ;) `make do-collect` on a cold cache on my dated computer, with an SSD, takes 6.3 sec. I imagine it could be a bit slower for those with spinning magnetic media. This seems acceptable for a video game, and particularly for a server that's supposed to be long-running. But, we should still profile, see what's slow, and try to make this faster. What would your strategy be for a change like this? One interim strategy, just to keep everything working, could be to invoke the current collect process at server start via fork/exec, read in output via loader, then start. Then merge the steps until they become one. Regards, Kevin ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] seg. fault with latest commit
On 9/13/20 8:39 PM, Preston Crow wrote: > There's a reproducible seg fault in is_identifiable_type() in item.c in > cases where get_typedata(op->type) return NULL. This has been fixed. Revision: 21430 http://sourceforge.net/p/crossfire/code/21430 Author: toxicfrog Date: 2020-09-14 13:43:33 + (Mon, 14 Sep 2020) Log Message: --- Fix segfault when calling is_identifiable_type() on something with no typedata Thanks to Preston Crow on crossfire-devel for the bug report. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Archetypes collection changes proposal
So the simple version of the proposed change is to have the arch directory work like the maps do now instead of like source code that is complied in. (And other details like allowing overrides.) I like the idea. The current system is broken in that I can make arch changes and the Makefiles don't detect any changes, so I have to manually do the collect to pull in the changes. Fixing that would be a pain. As to the start-up time, how much longer will it really take? Running 'make do-collect' just took 1.166s on my laptop. Even 5s wouldn't be a big problem for recovering from a server crash. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Archetypes collection changes proposal
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 signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
