Re: [crossfire] Moving server towards a modularized system?
Yann Chachkoff wrote: Of course, you may object that this is pure conjecture, that would get only results on the long-term, if they ever get any. Sure - this is an important change. I think that it all comes down to asking the question: do we want to polish the current infrastructure, keeping adding details to it, or do we want it to evolve into something more ambitious ? I think that we should, at some point, clearly put on the table the future direction we want Crossfire to go to, goals we want it to achieve not today or the next month, but on a long-term perspective. That is a fair point - what is the long term goals of crossfire, and perhaps just as much to the point, how do we get there. One problem is that I think lots of different things are being discussed without any real concrete/clear examples. Broad strokes are being drawn, and this results in each person having a different interpretation of what the final picture may look like and whether or not they will like it. In terms of making crossfire completely modular so it can be a game framework, once again a nice idea. I'm not sure however if it wouldn't be easier/better to start from a clean slate - probably a lot of crossfire code could be re-used, but there is lots of code in crossfire right now to handle case X so maps that use that feature don't break, etc. A clean slate could get rid of those hacks and then have a clean well understood interface. The problem there is this becomes more an exercise of a good design with it not immediately applicable to anything - that cleanup is likely to make it work too oddly with lots of crossfire maps and/or objects. One could say that right now, a good cleanup effort in the code could be made to get rid of those hacks - I think in many cases, a programmatic fix has been done because it was deemed easier/faster than fixing/modifying say 20 maps. I've also seen some past discussion about cleaning up function calls within function calls, dependencies, etc. That also sounds great to clean up, but I'm also wondering how that can be done. I doubt people writing the code are just calling functions they don't need to call, so I am not sure right now how that gets fixed up without other more broad changes. But I think in total, there is some level of agreement that a code clean up/modularization is a good idea. What is less clear is what is the best way to do it, and what form it will take. So as I said in a previous message, it may be a good idea for those that are wanting/willing to do this to post some more specific examples of what they are talking about doing. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
I don't think it would be wise to remove the hacks, the hacks make things work as they should. If someone want's to create a RPG engine crossfire, in my opinion, is not the place to do it. Crossfire is a game in it's own right, we should be concerned with our game, not some theoretical developers who might want to make their own game. We have media, we are beyond framework. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
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
[crossfire] renaming binaries (was: Moving server towards a modularized system?)
On 1/28/06, Brendan Lally [EMAIL PROTECTED] wrote: I'd be inclined to say that the quickest way to do that would be to have a deliberate compatibility break, oh, one other thing which is vaguely related to that, a 2.0 release would also seem to be a good time to rename some binaries. Currently the server binary is called crossfire, and the gtkclient is gcfclient, every few weeks someone appears on either #crossfire or the cfmb who can't find the name of the binary to run, the naming system isn't as straightforward as it might be I would suggest the following mappings (for both binaries and package names) crossedit - crossedit crossfire - crossfire-server gcfclient - crossfire-client gcfclient2 - crossfire-client2 (or crossfire-client-gtk2) cfclient - crossfire-client-x CFJavaEditor - jcrossedit The slight annoyance this might cause with script breakages can be justified by a major version number change. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
