> 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. > I do agree with that. I think that fixing all the current bugs should be the first priority, so that a solid 1.9 release can be achieved. Note that after 1.9 could come 1.10, though :)
> (and maybe include some metaserver filter to stop servers older than this > being included too). If protocol compatibility is to get broken, it is probably better to change the metaserver URL, so that versions 1.x and 2.x don't overlap. > 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) Probably a good time to get the "map2" command idea back on track. > 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. > Yes, I agree with that completely. Not having to deal with old piece of code would make the work a little easier for sure. > (note also, I would suggest taking the same approach with the C clients, > which have a similar problem (though less acutely)) Probably, although I'd say that clients are lower-priority, as their code complexity is somewhat lower. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
