On 1/28/06, Yann Chachkoff <[EMAIL PROTECTED]> wrote: > I'm not speaking about "theoretical developers" - I'm speaking about those > who (hopefully) will still play with crossfire and its code long after we > don't. I'm thinking about all the ideas that could get implemented much more > easily on a cleaner base than on a patchwork of code. >
I'd be inclined to say that the quickest way to do that would be to have a deliberate compatibility break, not completely, but at least back to what is actually used. Debian Stable is probably the single most obsolete GNU/Linux distro in widespread use, but even this ships crossfire 1.7.0 Given that crossfire 1.9 should be close to release (maybe?) the second digit would wrap round, and the next release after that would logically be 2.0. A major version number shift would be a reasonable time to deliberately break compatibility with all versions below 1.7 (and maybe include some metaserver filter to stop servers older than this being included too). If this were to occur there would be an awful lot on the server side that could be dispensed with the map command and map1 commands (map1a could be used exclusively) the item1 command (the C clients have long since used item2) spell conversion from the old spell system support for the old skill system. support for oldsocket mode (pippijn recently made a textmode parser using the modern packet structure, oldsocketmode is a hack that could be retired completely) doubtless there are more that I haven't thought of. Remove all that compatibility cruft first, and then, when the server is made leaner as a result, look at what, if anything needs simplifying. (note also, I would suggest taking the same approach with the C clients, which have a similar problem (though less acutely)) _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire