Hello.
> Do maps have a place here, as well? Didn't think about them, good question. They could probably, but I don't plan to have them handled right now like other assets. > 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. Having a .zip is indeed a possibility, but that's not something I plan at start. For the 'collect', I like the idea of having consolidated files that were "validated" for consistency (like all referenced archetypes are defined, things like that). Also, what I like with the current system is that most files are plain text files that are easy to adjust if needed. So .zip/.tar support could be added, but imo shouldn't be mandatory, to keep it easy to tweak. > `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. Yes, performance isn't that high on my topic list right now. Also since I plan on adding the collect mechanism back later, we will be able to use single files like right now, so I don't expect any performance issue. > 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. Current strategy: - have the server recursively find files in "arch" directory - remove the current collect mechanism - maybe rename some files (add extensions and such) - add new collect mechanism to consolidate archetypes, treasures, and such - format for pictures to be defined - optionally add tar/zip/... support (which could solve the picture format question) Best regards Nicolas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
