Re: [crossfire] Moving server towards a modularized system?
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
Re: [crossfire] Moving server towards a modularized system?
Yann Chachkoff wrote: If someone want's to create a RPG engine crossfire, in my opinion, is not the place to do it. It is the exact place where to discuss about what we want to do with Crossfire, being maintaining it in its current state, expanding it or making it more generic. See the description of the list: This list is used for general discussion and questions, answers, and latest changes and updates. This is general discussion around the game, so that discussion is perfectly in sync with that definition. If you don't like it, don't answer to it - simple as that. I agree that the code structure could be improved, and some level of modularization/separation of parts would be good if done with care. However, personally I do not see any real value in expanding it to a generic game engine. That said, I don't see any harm in that either, so long as it is done carefully. IMHO, creating a generic game engine is not a good goal for the project, however isn't necessarily a harmful as a side affect of increased modularization. I feel that modularization should be done (gradually and with care), to improve maintainability, *not* to create a generic game engine, though that would not be harmful to come as a side affect. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Brendan Lally wrote: 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. Note that removing the old protocol commands is probably a good thing. I don't necessarily know we need to wait for a major version number (2.0) to do it. It could be done sooner - the server would need some code to detect minimum version the client can have (based on the cs/sc version as well as setup commands), and if the client doesn't meet it, it could print a message to the client like: Your client is too old to play on this server. Download the latest client from if you want to play on this server I don't think that would be too terrible. That said, I don't think much of that code is causing too much confusion/cruft - I think in the most part, the functions are pretty well defined. The stuff I'm more concerned about is code you look at and scratch your head and say 'what the heck is that for'. Yet if you remove it, you then find out that some maps break or whatever. That is the stuff that should be cleaned up - the problem is that the process is basically: Remove the odd code Run on somewhat well used server and see what problems are reported (if you know what stuff it will break, you could fix it yourself) Update the maps/objects, repeat The issue here is that this means that for some time period, there is a server with likely issues, just not known exactly what those would be. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Yann Chachkoff wrote: (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. When there was the metaserver downtime/issues, there was talk at that time about a new more distributed metaserver implementation. Now the problem with the metaserver got resolved, and that sort of lowered in priority. But we still have the case of a single metaserver. If we know the server/protocol is going to change, coming up/using a new metaserver protocol at the same time would make a lot of sense. Thus, only new servers would have the code to talk to this metaserver. Only new clients would have the code to talk to this metaserver. It sorts its self out quite nicely in that regard. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Crossfire 2.0+ features/priorities
With the current discussion regarding modularization, the topic of new features also came up. For 2.0, it was mentioned do a general code cleanup to removed old crufty code that is only there for compatibility reasons. Fair enough. but relatively to players and developers, what do people see as the top feature(s) that should be added (or things fixed) to make crossfire a better game. I'm somewhat curious to see what the thoughts are. I think this info may indirectly help drive the modularization discussion - it may be that some of these features require significant rewrites or cleanups of the code that make sense with modularization. It may also be that some are relatively easy to do and don't require such changes. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] renaming binaries (was: Moving server towards a modularized system?)
I am not opposed to porting crossedit to gtk however. But if my favorite editor is removed outright... java is not an option. However crossedit works great (IMHO) now, so there really is no reason to change it. All this constant talk of removing things is displeasurable, thus my retirement for a time. If the things I like are not removed I'll come back, if the things I like are removed I won't come back. I am also waiting on some new features aswell. I trust all notice the drop in cvs commits? That is because I am uninspired as I watch the CF dev team discuss the most effective way of canning the whole project. How about not removing things from the game, a novel idea, no? __ 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] renaming binaries (was: Moving server towards a modularized system?)
If crossedit dissappears then I dissapear. I guess that is what you all want though. Should CF fork? --- Mark Wedel [EMAIL PROTECTED] wrote: Arguably, crossedit should just disappear. This, however, may become more or less an issue depending on other changes (if a code restructuring means significant rewrites needed for crossedit, I could see more reason to get rid of it. OTOH, if that major rewrite makes it cleaner, then maybe more compelling reason to keep crossedit, or make a gtk replacement). __ 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] Negative Luck for pk
Hi, I've asked for just that configuration option before. I'll forward this mail to the mailing list so the other devs may see that this is a wanted feature. --- Logan Tygart [EMAIL PROTECTED] wrote: Hey Man, I enjoy the hell out of your server. I have a couple of characters there. (Funyuns and Cugel) but when ever you pk your luck goes down. Since the server has no rules, is there anyway to turn off that feature? The last couple of days, we have been having a pk fest on a character named killah. Logan -- Nam et ipsa scientia potestas est -- Sir Francis Bacon Registered Linux User: 277727 __ 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?
MWedel just talked about a complete redesign in his latest post. Things that are redesigned tend to be broken for 1 or 2 years. I could be dead in 1 or 2 years, so could any of us. I'd rather not wait around. --- Yann Chachkoff [EMAIL PROTECTED] wrote: I don't think it would be wise to remove the hacks, the hacks make things work as they should. Hacks are what the name imply: dirty fixes. By removing hacks, it simply means replacing them by something cleaner that does the same job. Which benefits from code clarity, ease of debugging, and probably performances as well. We already removed some in the past, so that's simply a restatement that the efforts in that should continue. If someone want's to create a RPG engine crossfire, in my opinion, is not the place to do it. It is the exact place where to discuss about what we want to do with Crossfire, being maintaining it in its current state, expanding it or making it more generic. See the description of the list: This list is used for general discussion and questions, answers, and latest changes and updates. This is general discussion around the game, so that discussion is perfectly in sync with that definition. If you don't like it, don't answer to it - simple as that. Crossfire is a game in it's own right, I never said the contrary. we should be concerned with our game, not some theoretical developers who might want to make their own game. 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. No, I don't suggest working towards a cleaner and more generic code just for the sake of a handful of theoretical developers. I'm suggesting it to make *our* own developments easier and faster, to have a workbasis that we can expand further than what can be achieved now. We have wonderful game mechanisms in most cases, that can rival or even outclass those of a lot of commercial (successful games). I think that adding a new spell or a new object type to Crossfire should be as simple as writing a new map, so that new gaming mechanisms can get quickly implemented and tested - I don't see this as the benefit of a few coders, but a benefit for all players, who wouldn't have to wait for ages to get bugs solved or new, interesting ideas implemented. Maybe you're satisfied with the rythm at which your proposals are tested and implemented. I am not, and I believe a good structure would speed the process up a bit. We have media, we are beyond framework. Nonsense. Just because we have code doesn't mean that its structure is of good quality, or that staying forever with it is satisfying. Given that you never had to add stuff in the Crossfire code, I suggest that you first try to do so, and *then* speak about your experience, as I really don't think you have any knowledge of the difficulties involved with the current codebase. Finally, I'd suggest not to introduce notions you obviously don't understand. By framework in this case, I was speaking about a structure supporting a style of game; or, if you prefer that term, a generic, structured core of functions. The Media/Framework model has *nothing* to do with that. I don't think there can be any sane debate if you don't even understand the terms used. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ 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
