Some various musings I wanted to write up before I forget about them :) They don't directly relate to this conversation, but were brushed upon in certain messages.
Backward compatibility and rewrite: Given the number of maps and archetypes, it is certainly desirable that those still work - we don't want to have to go through and update every map just so it loads. However, there could certainly be some maps using behavior that is undocumented, or there could even be code to handle certain things so they don't break. But for some things, having clean code may be more desirable than maintaining some behavior that 2 maps use (and those 2 maps could get updated/fixed). Shared strings: While perhaps no reason to get rid of them, I also wonder how necessary they are now days. They do simplify comparisons. And with C++ and proper class descriptions, they can be made to be safe (have to use class functions to modify the name, and it knows to do the right thing). But shared strings date back a long time in crossfire, to when systems had much less memory and this was more a concern. They certainly do still save space, but the amount of space saved may not be worth the extra handling. It should certainly be reviewed - many design decisions date back to when computers where much less capable than they are now, and may not make much sense. Quick thought on features you mention: Dynamic arch loading: This makes sense, especially if/when images want to include new archetypes/images/animations/whatever else. Handling changing archetypes on a running server gets weird - need to have a fairly clear understanding what should happen there (if I'm fighting a monster and an arch reload happens and monster now changes, that would be odd) Distributed server archetype: Need more details - having redundancy (client rerouting with minimal data loss) might not be worth the effort - have to make sure you don't have two servers trying to control the same area, recovery when one comes back on-line, etc. But being distributed (this server is responsible for scorn region, this one for navar city, etc) to reduce load may make sense, with there being smarts to transfer character detail between those, etc. In terms of server failure/crash, the client could improve that experience - most servers restart when they crash, so it is really to the client to pop up a window with something like 'connection lost - trying to reconnect (with spinning disk or something)'. Multithread server: I think this is a must - computers are moving more and more towards multiple cores, and less towards raw speed, and for crossfire to make use of those really requires multithreading. I always thought that multithreading at the map level would make the most sense - this potentially lets one use many threads (and thus cores) and is probably the simplest way to go. _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
