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
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
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
Re: [crossfire] Moving server towards a modularized system?
On 1/25/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: Some CF programmers, such as Cave, would like to beable to reuse their code without having to recopy and paste what they have allready done (which would create bloated code if it was required). The idea of separating the code into fairly well defined areas is something I would support wholeheartedly, I don't think the current tangle of functions is a desirable thing and would much rather some functions were rearranged between files, to better reflect what they do. In this I do not disagree with Tchize and Gros, however I am still unconvinced by the case for a complex API to enforce such separation, a well constructed layout of functions within files, created according to how they are called in various places, would, I feel, help almost as much without adding yet another thing to support that will quickly become outdated. Modules would disallow this (bad) as they are not loaded untill they are called. In an organisational change that would achieve the same effect, these same functions would be marked static anyway, so this is a non-point. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Le Jeudi 26 Janvier 2006 00:17, Miguel Ghobangieno a écrit : Yes, spagetti code, if that's what you wish to call it. Some CF programmers, such as Cave, would like to beable to reuse their code without having to recopy and paste what they have allready done (which would create bloated code if it was required). Modules would disallow this (bad) as they are not loaded untill they are called. Call it what you will but this is why subroutienes were invented (subroutines, in assembly, are basically gotos... :) ) so you didn't have to paste the same code everywhere. That goes in modules dependencies, helper methods gets on a common root. Spaghetti code happens when this occurs without limits (eg a method in loader call a method in socket which itself calls a methods in player which itself calls back the socket!) Code reuse happens in modularized code too! ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
In this I do not disagree with Tchize and Gros, however I am still unconvinced by the case for a complex API to enforce such separation, I never suggested to make a complex API to enforce such separation. Quite the contrary, I think that the API should be kept simple, organized and rather straightforward. If the resulting API is complex (either in structure or to maintain), then it is indeed a failure, as one of the goal is to make the code easier to interface, not harder. a well constructed layout of functions within files, created according to how they are called in various places, would, I feel, help almost as much without adding yet another thing to support that will quickly become outdated. Such a layout is indeed one of the points to achieve, and is the first step to do (one cannot expect to define a solid API without a clear and global view over the existing code). On the other hand, let's not forget that cleaner code is *one* point a modularized system with a generic API for objects is meant to address. A modular system would allow easier interfacing with other libraries, languages or software, would make possible integration of new classes of objects alongside the maps themselves; if properly done, it could allow upgrades and fixes in the modules code to be integrated in a running server without having to stop it; on-demand loading/unloading of code, with the possibility of creating auto-downloadable chunks, etc. It would basically make Crossfire a game framework that could effectively be used as a workbasis for all kinds of square-based multiplayer RPGs, something a monolithic code will *never* be able to achieve. 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. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
tchize wrote: much about removing code removed I agree that removing/disabling code is a valuable feature. I'm just not sure that any of the methods either of us have talked about is really a good method. From my point of view, making it really easy/convenient for developers to disable code is less important than a method where it can be done on the server. And when I say 'on the server', I mean literally through a running crossfire server, and not by shell login. I'd see the most likely scenariou that a DM on a server that does not have shell access seeing that applying an item (or some other action) is causing the server to crash, and thus wants to disable that. IMO, having the server unlink .so files probably isn't a great solution (and in fact, may not always work, as the .so files may be installed with a uid different than what the server runs under). Also, disabling at an entire module level may not be desirable. In my example above, you may want to disable the applying of items, but still want ot be able to get descriptions of items, identify them, etc. Likewise, any disabling of functions should be persistent accross runs until re-enable. Disabling that apply function doesn't do much good if something else crashes the server and it is enable again. So what I started thinking was you could have a module control, with things like: operation type operation name operation value, eg: function scroll:apply disable (operation name would be module:function name, with potential wildcards, so you could do something like) function scroll: disable to disable all scroll code. This then allows other things like: variable scroll:max_level 25 To set module values to various things. this requires support of the module initialization code (checking to see if it shouldn't set the callback, change global variable, etc). If callbacks aren't used, the first line of various functions could be things like: if (!module.apply) return; That is marginally more complex than other methods we have talked about, but probably more flexible (I do especially like the clearer documentation of setting variables and how they effect things). I'd also think that once this glue code was written for one module, it could pretty easily be re-used for everything else. IMO, compiling/not compiling something isn't an issue - if something is so broken that it doesn't even compile, it should be fixed ASAP or be removed. Yes, assuming it's easily fixable (does not take 3 days of work). Well, if it takes 3 days of work to fix, then perhaps it should be removed, or disabled from the make system. After all, right now at least, the current built environment isn't especially graceful about continuing when it fails to compile a file (you can always do make -k) And I'd personally be concerned anytime I see something failing to compile. But as modules, it should at least be able to disable compilation of that one problematic file without affecting anything else. If you don't put the modules in plugins (at least what we could modularize from current server code) you would have two things - 1) code to manage hard linked modules (eg arrays of module callbacks to explores and so on) - 2) code to manage additionnal behaviour which could be requested by plugins (be it python, animator or another one) That mean during modularization process, at each place we consider splitting appart code in modules we have to handle separetly - main server module - plugin managment code This is twice the effort during the modularization process. I disagree it would be twice the effort. It _may_ be more work - it certainly wouldn't be quite as consistent. But if you pluginize a lot of code, I'd say there is more code that would need to be rewitten/changed than if it was modularized. This isn't enough for modules. Of course modules can be gathered .a and gathered a link time. But you also need to clearly separate them. Currently it has nothing of modularized. A piece of code in random map can call functions present in the socket, a piece of code in weather can call functions in maploader. Same for piece of code in protocol which makes call to maploader.c I don't see how you can avoid that. At the most basic level, almost any module of code is going need to talk to the socket (draw_info commands at most basic, but I can also see need for lots of update object commands). Now you can perhaps wrap some of those functions or use callbacks, but that really isn't changing anything. If we are talking about apply code again, the module will need to know about the NDI_ values as well as perhaps the UPD_ values. Now the plugin could have its own private file, but then somewhere in that plugin logic, it has to convert those values (PG_BLUE to NDI_BLUE or whatever). And unfortunately, I'm not really sure how many of the current top level include files have dependencies
Re: [crossfire] Moving server towards a modularized system?
We want to cross module boundries and there is no reason for us to want 3rd party module additions (unless one is pro-proprietary). Modules would do 2 things: disallow use of code across module boundries (as they aren't loaded yet), let proproprietary addons be created and work over more then 1 release cycle. Both are bad. __ 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?
Yes, spagetti code, if that's what you wish to call it. Some CF programmers, such as Cave, would like to beable to reuse their code without having to recopy and paste what they have allready done (which would create bloated code if it was required). Modules would disallow this (bad) as they are not loaded untill they are called. Call it what you will but this is why subroutienes were invented (subroutines, in assembly, are basically gotos... :) ) so you didn't have to paste the same code everywhere. Oh and I just got a yamaha midi guitar (EZ-AG) :) (I now have a midi keyboard and a midi guitar :D, the keyboard is recognised by linux through USB and rosebud4, I still have yet to get a midi-cable-usb adapter which the geeetar needs). __ 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?
Le Lundi 23 Janvier 2006 07:18, Mark Wedel a écrit : Well, one could change that behavior without resulting to plugins - to give meaningful names to object types just requires an array that has the names. I was just showing with plugins it would be easier then currently. Of course there are plenty of other possiblitie to solve that particular problem of identifying code related to a type. But plugins provides also other advantages: - third party add-ons - easy deactivation of parts of code - ensure there are no modules boundaries crossing (go thru a single access point) - even if a non plug-in modularization is used, we would have to map it to a plugin system to be able to upgrade current existing plugins to it. And for everyone out there currently using grep - download cscope and use that - it is a vastly superior solution (even going to plugins or whatever else, cscope is a very handy tool - just run 'cscope -R' in the top level directory. Am not sure it's a good idea to have de developper dependency on cscope or grep. While current code isn't particularly well organized, at the same time, it is only in a few files, so it is not like you have to visit 30 files. It's a few file but it's spaghetti code! Not to mention the length of some files or even the length of some methods :) True, but that goes more back to my 'poor mans version' of plugins. At some level, I think a poor mans version with callback registration is actually more flexible. You'd have to issue a 'patch' if you want to add third party specific features (like a server having it's own crossfire - html stats system). You'd have to 'patch' the code if you want to disable compilation of a problematic piece of code. One could have a registration function like: set_type_callback(object_type, event_type, callback()) The advantage of registration of that form (instead of true event plugs in the object) is that adding new event type callbacks doesn't require any change to the objects. What's the difference with set_type_callback(object_type, event_type, somePluginMethod()) ? the fact of adding plugin event to object instead of type, is just a generalization of what is currently done for existing script and is needed to keep backward compatibility (not to mention it also allow plugin to have some methods triggered only on demand). Moreover before thinking of the specific ways to modularize things, questions to be answered must be - Do we want a modularized system? - If yes, who would lead this process, how will he lead this, and who would team with him. Another advantage is that registration above sort of provides a self documentation of what function is going to be used just in that callback function (and presumably, proper function naming, can be pretty clear where function is located, eg apply_.. would be in apply.c, describe_.. in describe.c, etc). I don't see how it documents itself. Lastly, it could be very easy (even within the game) to disable certain plugins, eg, just a call like: set_type_callback(.., .., NULL) Where with true plugins, I don't think there would be any easy way, as you'd need to update all the objects with event_.. hooks (or keep a table someplace saying to ignore hooks, but that would seem to get pretty messy). See my previous comment. That is one consideration. Another is whether the any of the plugin logic itself would prevent proper re-entry (eg, static values in wrapper functions, in case of python plugin, is there anything to prevent two python scripts from running properly at the same time, etc). That's tipically a problem associated with multithreading. I don't think it's a good idea to mix the ideas of multithreaded core and the ideas of modularized system. One big change at a time :) Of course, ideally, in all cases, the answer should be no - if/when crossfire becomes multithreaded, those things would likely need to be fixed anyways. We are still far from multhreading. However, a modularized system would help a lot in future such changes. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
tchize wrote: And for everyone out there currently using grep - download cscope and use that - it is a vastly superior solution (even going to plugins or whatever else, cscope is a very handy tool - just run 'cscope -R' in the top level directory. Am not sure it's a good idea to have de developper dependency on cscope or grep. But at some level, you will always have some dependencies on other tools - compiler, linker, editor, etc. I was mostly pointing out that if people are currently using grep, there are much better tools available. True, but that goes more back to my 'poor mans version' of plugins. At some level, I think a poor mans version with callback registration is actually more flexible. You'd have to issue a 'patch' if you want to add third party specific features (like a server having it's own crossfire - html stats system). You'd have to 'patch' the code if you want to disable compilation of a problematic piece of code. True, but a plugin for object actions would be a pretty critical piece of code - you just can't disable the players from applying all items (or not compile that bit) and have a working system. Now the counter is that you'd just disable it for the specific bad object type, but then, if one plugin is covering 30 object types, that still isn't much an option. IMO, compiling/not compiling something isn't an issue - if something is so broken that it doesn't even compile, it should be fixed ASAP or be removed. the issue would more likely be disabling them once problems start, which would be same regardless of method used, but registered callbacks are probably easier. One could have a registration function like: set_type_callback(object_type, event_type, callback()) The advantage of registration of that form (instead of true event plugs in the object) is that adding new event type callbacks doesn't require any change to the objects. What's the difference with set_type_callback(object_type, event_type, somePluginMethod()) ? the fact of adding plugin event to object instead of type, is just a generalization of what is currently done for existing script and is needed to keep backward compatibility (not to mention it also allow plugin to have some methods triggered only on demand). Well, you can't have a single list of all the set_type_callbacks() unless all the functions are in the same module. For example, you can't have any such callbacks in the server code if they reference functions in plugins that are called later. Likewise, for the plugin itself, it will only know about the functions in the plugin itself. This isn't directly a problem except that these callbacks would be spread across several plugins, which makes finding the actual details more difficult (have to do a grep to see which file is registering that callback). For most plugins, that probably isn't a problem - if one were to think of the random map code, it really only needs to register one callback, so big deal. OTOH, the random map code is already pretty well modularized, so I don't see much point to convert that to plugin logic. Moreover before thinking of the specific ways to modularize things, questions to be answered must be - Do we want a modularized system? - If yes, who would lead this process, how will he lead this, and who would team with him. I think the term plugin vs module probably needs to be clarified, as well as clarification what approach we are really taking. To me, module is like the .a files currently used (random maps, socket, etc) - code is logically grouped in one place, but linked in at compile time. plugin is code that isn't loaded until run time by explicit calls to load shared libraries. In this case, the server (or other code) doesn't know about anything in the plugin until the plugin is loaded. Now a separate question may be which method should be used - modules are certainly simpler to do, but harder to control usage of that code. I guess for the object code handling, I'm more inclined to do a module type approach - that code is already compiled in, and I don't see much in the way of compelling advantage to making it an actual plugin - the code can be made a lot easier to maintain and find stuff without making it an actual plugin. That said, I can certainly see the need for plugins. It just becomes harder to figure out what approach works best for what. That is one consideration. Another is whether the any of the plugin logic itself would prevent proper re-entry (eg, static values in wrapper functions, in case of python plugin, is there anything to prevent two python scripts from running properly at the same time, etc). That's tipically a problem associated with multithreading. I don't think it's a good idea to mix the ideas of multithreaded core and the ideas of modularized system. One big change at a time
Re: Re: Re: [crossfire] Moving server towards a modularized system?
Indeed. Just because the server can be modularized thus blocking any other new development whilst that takes place doesn't mean it's a good idea. There is no reason to block any other development. I suppose you know that the C in CVS means Concurrent ? I for one frown on the idea of making the server slower There is no reason that it would be slower than it is now. There are no reason for a modularized system to be slower than the current version. The only overhead would be when connecting callbacks to objects - and that's hardly something you'd notice, unless if you're running Crossfire on a [EMAIL PROTECTED] and blocking other development. I think I already said it, but there is no reason to block other developments. Everybody who has already worked in large-scale software projects knows that parallel development on different parts of the code is a rather common practice. That you believe that only a single task can be performed at once on something like the Crossfire code shows that you urgently need to get better informed on software development/engineering techniques and more generally on modern teamwork methods. For what is worth, I could already be working on a code prototype on my personal workstation - would you ever notice it before I submit a patch ? Would it prevent somebody else to add something in the code in the meantime ? The answer to both of those questions would appear obvious, I think, to every reasonable person. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Le Mercredi 18 Janvier 2006 01:04, Miguel Ghobangieno a écrit : Try mucking in the linux kernel without grep, tell me how that goes. I did, for school. And at that time the block device part of kernel was considered a mess by most developpers. However i used grep far less then i had to do with cf. (sometimes i did as it was faster to know where an error message came from :p) Considering line number ratio, kernel is far more structured than cf :) -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgp5gioEfKWjn.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
On 1/18/06, tchize [EMAIL PROTECTED] wrote: Having to grep throught to code to guess where you have to add your new features is a symptom of upcoming code management problems. I agree on this point, however I suspect that much of this could be avoided by simply shifting a few functions and #define's around, much of what exists currently has been grandfathered into various parts of the code (look at include/define.h for a good example of this) moving these into more logical locations (or maybe even just documented locations) would help in finding various parts of the source code. Likewise moving things around could probably reduce the number of functions which are called from different files, improving the usefulness of text-editor based find tools. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: Re: Re: [crossfire] Moving server towards a modularized system?
Well enjoy raping the server. I'm retiring from CF untill a certain unnamed feature I was promised 1/2 a year ago (no not plots) is in. See you soon or never. --- Yann Chachkoff [EMAIL PROTECTED] wrote: Except that you are not working on one section of the code, you are restructuring the whole server into diffrent modules. This means that if you develop in cvs there will be breakage with any and everyone else as you sweeping edits touch every facet of the glory that is crossfire. Well, the required editing is, for the most part, moving existing code rather than change it. Algorithms will stay the same, execution paths as well, etc. What will change is the way various functions are called - so for example, calling apply(this_object) would become this_object-manual_apply(this_object) (This is only an illustration :)). Only in a few cases will new code be needed - mostly to bind the modules content to the code. So basically, you'd expect problems in: - The module loading/unloading (a clearly separate, specific piece of code); - Improperly converted calls (which can be avoided if we're careful enough). So no heavy breakage is expected. The C in CVS may mean concurrent but it doesn't mean perfect. I never said the contrary. It just means that no, even a refactoring of that scale wouldn't block the whole project for months, that's all. If you want to make the sweeping changes on your own system; enjoy. But please, before committing to cvs do extensive bugtesting so that it 1) doesn't make the code any slower, 2) doesn't break anything, and 3) maybe makes MS less of a hog? I think all Crossfire coders perform quite some tests before committing to CVS - nobody would want to be responsible of severely damaging the server. Simply understand that coders are not perfect, and that they cannot think about all possible cases. To take a recent example, there was a library-related bug in the new plugin code that I didn't spot on time; was that because I didn't test that bit of code ? Of course not - but on the architecture I was trying it on, it simply didn't exist. Also, let's not forget that the CVS codebase wasn't meant to be used on production servers: the CVS is (theorically) the repository in which the work in progress server code is stored. Stable versions are distributed in the various packages available on the SF website. Now, it is true that if some big changes are to be done, it would probably be a good idea to release a new stable version first, so that server administrators like you can get all the recent features without having to struggle through the possibly stability-threatening changes. Regarding possible performance issues, I think that there are ways to ensure that nothing noticeable happens. Most of the time lost would probably get when the plugin/module gets initialized and loaded - and that's unimportant for the running speed of the server. ___ 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
Re: [crossfire] Moving server towards a modularized system?
Le Mardi 17 Janvier 2006 02:56, Miguel Ghobangieno a écrit : It is not half broken as far as I can tell. Yes it's not running on MF, that doesn't mean it's broken. So having trees growing on sea squares isn't broken ? It gives few problems on Cat2. This whole thing is about slowly dumping whatever MF doesn't use. It is not about moving code out of Crossfire, but about re-organizing it so it is easier to manage. Which, as a side note, should help debugging chunks like the weather system and provide fixes without even having to rebuild and restart the whole server. If you read what I typed earlier, you'd note that I think random maps should get modularized as well - and AFAIK, it is used extensively on MF. Let's repeat it again: modularizing code is *not* about removing functionalities; it is *not* about scrapping code out of the main CVS tree. It is mostly a structural change to make an easier maintenance for those wanting to work on such pieces of code - so it is in fact a way to make them *better* supported. Open your eyes, the 2nd biggest server runs weather code at it's most extreme, in terms of players that's not a few. That there are many players on Cat2 doesn't make the weather system less broken. I suggest you not implement a huge worthless code change that is nothing but busy work. That's indeed an opinion based on emotion rather than facts, unfortunately. I reject your assertion that cave's analogy is flawed as it is not. Tell me how it isn't, then, or stop the nah, nah, nah song. If you want to code code something new useful rather then breaking the server as is what will happen if you go forward with this plan. Breaking the server always occur when a new functionality that is larger than a few lines of code is implemented (everybody makes mistakes, even skilled coders). And given that I see it as useful, I would have no problem breaking it. You also will be holding off any new large codechanges for months as they wait for you to be done with this not-needed reshuffling. I don't see why. Moving existing parts of the code into modules doesn't mean development on other parts of the code would suddenly be halted for months. And I could return you the argument: the completely optional get drunk when drinking functionality you suggested would block the more important restructuration of the code, probably for a couple of weeks - where's the difference ? You could of course object that players want to get drunk, but don't give a damn about an obscure change in the code. Presented like that, sure. But wouldn't a server that is easier to maintain, debug, and extend have a more in-depth impact on the players in particular, and the game interest in general ? I think it does, even if it means that the priority is set on changes that are not immediately visible to players. -- Yann Chachkoff --- Garden Dwarf's Best Friend --- GPG Key: http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 pgpEc5eUt2t9I.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Le Mardi 17 Janvier 2006 06:03, Alex Schultz a écrit : Frankly, I have to agree with mikee to some degree on this point. I generally have little trouble finding something after a combination of getting a feel for the code, which I have gotten pretty good for a while now, as well as skilled grepping. Crossfire is the only project i have worked with either on my spare time, either at work, which needs grepping in the code to understand it! This just proves how much a mess it is. However aside from some things like this, I do find modularization can have merits, it just depends on 1) How much effort it takes to modularize, 2) How effective the modularization API is designed (i.e. currently the existing plugin API is vastly insufficient for server modularization) and 3) Where we draw the line of what to modularize. Personally, I don't think we should modularize very much, but if the API is good enough (which I would likely be picky about myself), then it might be worth doing for a limited number of things. 1) It would be, in my opinion, a progressive effort. Modularize one piece, then another one then another one. This woudln't prevent current commiter to do their add-ons too. 2) modularization api should simply progress along with modules. If you need core to export something new, then simply have it export it. Please not i don't consider plugin based modules as the only solution. It would be good in the sense it force code to have clean way to access datas. To get back to provided example, what if modules whant to change object-dam? Well i would say then it must register a dam modifier methode to object :) Simply because you can't be sure another module don't want also to interfer with dam imagine this rule with this item weared, player does twice dam when standing on fire and this one this weapon does half damage when player is wearing a helmet It's up to core to gather rules exception registered for object and do a calculation chain based on it. mdifying object-dam directly would then be dangerous :) 3) the line will be found in a progressive way. Depending on needs. Alex Schultz Miguel Ghobangieno wrote: I have to do the same thing when I am adding things to my perl rpg (which is not smaller in lines of code then crossfire). It's not a big hassle, and how else will the code know what's going on? Use grep. --- tchize [EMAIL PROTECTED] wrote: Speaking of my experience with crossfire code. I have developped a few add-ons to crossfire in the past (don't remember the list). From my point of view, adding new features in the code is currently a pain in the ass. I have dropped features add-ons which took me lots of time simply because it has become nearly impossible to find something in the code. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire -- David Delbecq Royal Meteorological Institute of Belgium - Pingouins dans les champs, hiver méchant ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Le Mardi 17 Janvier 2006 08:00, Mark Wedel a écrit : Yann Chachkoff wrote: Well, it really depends on what the C code requires as dependencies - the Python plugin has one with the python libs for example. But stuff that was initially in the server code would have no such external dependencies indeed. True. I imagine dependencies to be fairly standard C dependencies. But I could imagine someone writing a plugin in C++ with appropriate wrappers. On the other hand, I think splitting the code in logical entities, more or less independent of the others, would be a path of thinking to try. As such, random maps would appear as a good target for modularization, since it doesn't really depend on anything else, apart from very basical operations, and is called only at a few places. Alchemy would be another good candidate - both are very important in the game, yet are working very much like black boxes - complex code with relatively limited interactions with the rest of the code. Agree. And in fact, any object that does something 'interesting' when applied could be a plugin, since most such objects are also very well self contained. However, I'd counter that if it is just 20 lines of C code to do that 'whatever', it could be more convenient to just add that 20 lines to apply.c I say this because I imagine plugins would probably be organized by plugin/C/plugin_name. Maybe have one directory for basic plugins (one in which the entier plugin is in one file). But if plugin grows to the extent that there are 50 'trivial' plugins, one could say finding the code there isn't any more convenient than having it sit in apply.c Nothing would prevent all those 'basic plugins' to be gathered together. eg all kind of current exit in a module along with walls, grounds, name this module 'basicLayout' anotherone for movment stuffs another module regrouping monster stuffs anotherone for all kind of traps ... Common lifecycle is 'add new feature in existing code, when it becomes lots of line, move it to it's own module', unless of course you know from the start it will contain lots of code ;) I'd think that if there is a C plugin, aside from the different passing in of the values, and using appropriate callbacks for functions instead of calling them directly, it could access the function data directly? Eg, it should need to do a plugin callback to set the dam of an object, it could just set ob-dam? Theorically, yes: there's nothing preventing such a thing. Wrapping such access behind functions was basically to allow checking that the values passed were in the correct range, and to provide encapsulation of the data (so that a plugin wouldn't get tempted to directly change fields it wasn't supposed to change without a high risk) I'd imagine it is more important for the plugin wrapper to provide a consistent interface to the various functions, so that if a function handling changes in the C code (say a function now takes another argument), that all the plugins don't have to be rewritten - they can keep using the existing code, with the wrapper just passing in some default value. principles of methods polymorphism in object oriented programming ;) Sure ! But I think such changes would be easier to make if the code was, in a way or another, split into smaller entities, so that they affect only a limited part of it. And indeed, a lot of functions would benefit from some in-depth rebuilding. Also, part of the problems of code debugging/maintenance come to how things are distributed all around the code - finding where to add/change things is a rather complex task. Making small changes to make the code more readable and editable would thus be another important point to achieve, IMHO. True - some functions have grown a bit in complexity and could certainly use a rewrite. And I could envision doing some things as plugins would make some things easier/more modular (Going back to what someone said, objects that the player uses are complicated - need to update the apply code, but depending on the object, may also need to update the code that actually describes the item - I could see with appropriate plugin support, all that could be done in the plugin, so all code related to that object is in one place) Well you put the finger on it. Adding a new object is generally adding a 2 lines code to apply which calls myObjectType_apply(). and same to describe, sometimes, also for some same to move_object(). Damn this looks to me like the pattern of registering listeners to some events :D ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire -- David Delbecq Royal Meteorological Institute of Belgium - Pingouins dans les champs, hiver méchant
Re: [crossfire] Moving server towards a modularized system?
On 1/17/06, Mark Wedel [EMAIL PROTECTED] wrote: True. I imagine dependencies to be fairly standard C dependencies. But I could imagine someone writing a plugin in C++ with appropriate wrappers. This point (more than any other) is potentially alarming. Currently crossfire is written in C and python, with some perl scripts doing some minor things. If this range of languages is increased, there is a danger that it would include languages outside the range of competence of the existing developers, or outside the range of languages which are well supported on some of crossfire's target platforms. Whilst it might be that $NEW_WHIZZY_FEATURE would be very easy to write in D, for example (or some other $OBSCURE_LANGUAGE) it is unlikely that most systems running servers have a suitable compiler installed or that most existing developers would be able to adequately maintain code written in it. Whilst C++ on its own isn't greatly objectionable, there must be some guidelines as to which languages would be permissible so that we don't end up with 20 different modules in a dozen different languages half of which were known only to their original author who has since disappeared. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Le Mardi 17 Janvier 2006 18:15, Brendan Lally a écrit : On 1/17/06, Mark Wedel [EMAIL PROTECTED] wrote: True. I imagine dependencies to be fairly standard C dependencies. But I could imagine someone writing a plugin in C++ with appropriate wrappers. Things written in other languages then C should always be considered as optionnal. This is the case of python scripts. They are usefull but not all platform do support them very well. In all cases, things like writting a plugin in C++ or Fortran or ADA or anything else should require prior discussion on ML. It's too early for a discussion about languages in which plugins are written. I understood the current idea is to move C code to plugin still in C (just structural reorganisation). -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgpQXBLgd48iT.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
How about not modularizing and thus not having to make a trade off. How about not screwing up the server for months just because you are itchting for busy work. --- Yann Chachkoff [EMAIL PROTECTED] wrote: Nothing currently prevents a plugin to modify the data it has access to directly - but of course, that's unsafe access, so if the plugin makes a bad modification to the data, or forgets to notify the server of it if necessary, then it will probably crash the server. Accessing data directly or through wrappers is basically a tradeoff between performances and security. In the case of modularization of the existing code, I'd say that direct access wherever possible should be kept - accessors for such data modifications would probably be used only for debugging purposes (as a wrapper can check if the data modification is legal or not, and thus can help detecting a whole range of errors). -- Yann Chachkoff --- Garden Dwarf's Best Friend --- GPG Key: http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 ___ 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
Re: [crossfire] Moving server towards a modularized system?
Did you not read my post. If you are screwing around with the code structure of the server then other programmers do have to wait untill you are done as they do not want their code to suddenly break when it intersects with your massive changes. You must not be at all experianced in these matters (as you indicated before in fingering crossfire for the sin of you having to grep through it). This will hold up usefull game development for months all because you and friends believe that you are above grep. --- David Delbecq [EMAIL PROTECTED] wrote: Le Mardi 17 Janvier 2006 02:51, Miguel Ghobangieno a écrit : I suggest you not implement a huge worthless code change that is nothing but busy work. I reject your assertion that cave's analogy is flawed as it is not. If you want to code code something new useful rather then breaking the server as is what will happen if you go forward with this plan. You also will be holding off any new large codechanges for months as they wait for you to be done with this not-needed reshuffling. Why would other coders have to wait? Nobody did mention freezing the CVS at anytime. If you don't want to work on modularization, nobody forces you to do so, work on implementing new features. It's the sole responsability of the one modularizing a feature to ensure there is no conflict when he commits. When the commit is done, it's the responsability of other code to take into account this change. That's how CVS based development work. Crossfire had deep changes in code in the past (object based skills is one of the most recent). This has never prevented other people to do their change. That's the magic of teamworking. -- David Delbecq Royal Meteorological Institute of Belgium ___ 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
Re: [crossfire] Moving server towards a modularized system?
Why oh why do you want to do this useless crap? We have a real game, we don't have to make an engine. How about adding some new features rather then ripping the things apart. This is why I hate CF devel, rather then improving the game most suggestions are oh let's fuck shit up or delete this or drop that. How about adding things? It's fun, people don't get angry at you as you aren't breaking or throwing out what they've made aswell. tchize can you modulize the server? no? so how about not suggesting screwing it up for every other developer? Ryo? no aswell? This is busy work, it is useless, and it slows down game improvements. --- tchize [EMAIL PROTECTED] wrote: Le Mardi 17 Janvier 2006 06:12, Alex Schultz a écrit : Indeed. On this example, IMHO random maps are not optional, as they are essential to some quests, and also soon would be used by land plots (though land plots would in my opinion be a relatively good thing to implement as an optional-but-defaultly-on C plugin) IMHO they are optional, they are mandatory to use the current map set, that is true, but that just mean a random maps module is a requirement for using bigworld maps. I my opinion, those are optional, even if they may appear mandatory to run current maps. Imho it should even be possible to pickup the crossfire core and create a brand new world out of it. - communication protocol (should be interchangeable, it can be driven by object modification events in server, this also would help dissociate rules from socket events, it would make also easy to put several protocol modules, eg, one for bots or another one for a scorn webcam) - weather system (it's main architecture is, on a regular time do calculations and update world maps) - python scripting (is a requirement to run big world, but not to run server) - random maps, in a more general point, map loading / saving, this would give the possibility to have other means of generating maps and saving maps. We could think of separate modules for random maps, user specific permanent maps, underworld? (it has been suggested the underworld could be based on what exist on upper world) The fact is, a server would be able to start without map loading, without scripts, without communication protocol. It would just have a bunch of rules and nothing to do. But that also mean we could start it with only communication protocol plugged in and a dummy map loading module, this only in the purpose of testing protocol behaviour, maybe in an automated way. ___ 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
Re: [crossfire] Moving server towards a modularized system?
Current idea? I must have missed something, I didn't know you decided, above all the objections, to go ahead and rip apart the server anyway. I will be waiting for my 3 thousand dollar cheque in the mail (along with everyone else who would like to add new stuff to CF but will have to wait untill you tire of ripping apart the server and revert the CVS tree). Why should all work have to stop because YOU want to restructure the server.. because you can't figure out grep... --- tchize [EMAIL PROTECTED] wrote: Le Mardi 17 Janvier 2006 18:15, Brendan Lally a écrit : On 1/17/06, Mark Wedel [EMAIL PROTECTED] wrote: True. I imagine dependencies to be fairly standard C dependencies. But I could imagine someone writing a plugin in C++ with appropriate wrappers. Things written in other languages then C should always be considered as optionnal. This is the case of python scripts. They are usefull but not all platform do support them very well. In all cases, things like writting a plugin in C++ or Fortran or ADA or anything else should require prior discussion on ML. It's too early for a discussion about languages in which plugins are written. I understood the current idea is to move C code to plugin still in C (just structural reorganisation). -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html ___ 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
Re: [crossfire] Moving server towards a modularized system?
Gros wrote:
It actually depends on the level of control you want to grant to the plugins.
The most extreme case would be to export all the functions currently in the
code - to do that, you'll have to provide a wrapper for each function you
want to export. That's a lot of functions, but let's not forget that a
significant part of those are only used by specific pieces of the code, so
the actual useful number is definitely lower than that by a significant
margin.
One danger of providing wrappers to too many functions is danger of infinite
recursive loops. There is already that potential - the apply code always has
such a check.
But the danger could be that if module writers see a list of functions they
can use, they may think it is safe to call it back at any time. Not that is
really any different than current code, but just a thought.
David Delbecq wrote:
Nothing would prevent all those 'basic plugins' to be gathered together.
eg all kind of current exit in a module along with walls, grounds, name this
module 'basicLayout'
anotherone for movment stuffs
another module regrouping monster stuffs
anotherone for all kind of traps
...
Common lifecycle is 'add new feature in existing code, when it becomes lots of
line, move it to it's own module', unless of course you know from the start
it will contain lots of code ;)
However, I think if you start grouping all that stuff together, you start
loosing some of the advantages.
I think there are also some limitations regarding the actual use of the shared
libraries (modules) - for example, each one can only have one initialization
function I believe, so if you have say 20 object types in one module, you'd have
to mix all the code they need for initialization in one function (or have a list
of the 20 function calls it makes).
Well you put the finger on it. Adding a new object is generally adding a 2
lines code to apply which calls myObjectType_apply(). and same to describe,
sometimes, also for some same to move_object(). Damn this looks to me like
the pattern of registering listeners to some events :D
But one could do that to some extent without plugins.
You could for example set up something like:
struct object_type_description {
functypeapply_func;
functypedescribe_func;
functype
} object_actions[MAX_OBJECT_TYPE
Then in the code, you could do things like:
if (object_actions[op-type].apply_func)
object_actions[op-type].apply_func(...)
In a sense, a poor mans/specialized plugin. You then just need one
initialization function, but all the specialized code related to object type
itself could be in one place.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
I have to do the same thing when I am adding things to my perl rpg (which is not smaller in lines of code then crossfire). It's not a big hassle, and how else will the code know what's going on? Use grep. --- tchize [EMAIL PROTECTED] wrote: Le Lundi 16 Janvier 2006 13:07, Anton Oussik a écrit : Throwing in my two pennies: In general modularisiation of the code will improve maintainability, That's also my opinion. On the other hand modularising the code will result in many changes, may introduce new bugs into the code, and is in general a lot of work whilst the benefits are questionable (this will only be useful if core is really small and most things are out in modules which can be configured at configure stage). If someone has a desire to do all that they are welcome to (it is an open source project :-) ), but in my opinion implementing new features would be more beneficial to the project. Speaking of my experience with crossfire code. I have developped a few add-ons to crossfire in the past (don't remember the list). From my point of view, adding new features in the code is currently a pain in the ass. I have dropped features add-ons which took me lots of time simply because it has become nearly impossible to find something in the code. If you add a new arch type, you have to register it in a define list, register it in the movement function if it is active, register it in the attack code if it can attack player, maybe register it with weather system if it can interact with it, register it to spell casting system if, for example, it represents a spell modifier. Can you imagine today creating an item which has as characteristic 'owner can walk over water' without modifying piece of code everywhere? In a modularized system, you could have something like that (it's just an idea, it still has obvious flaws in aglorithms) when trying to move object from squareX to squareY, you trigger a move_request event on squareX listeners, on squareY listeners and on object listeners. Each listener can respond with NEUTRAL(0), ALLOW(1), REJECT(-1) if there is an allow, then allow movement else if there are no reject then allow movement else refuse movement water would be REJECT non swimming obj, your item, registered in player when applied) would allow on every square with water. The exact same idea can be used to create complex check_inv, confusion spells, director, no_movement traps . You just 'plugs' in the movement code. Also this system can improve server performances. Currently, one of the main 'lag' problem of server is meteor swarm in the open areas. thousands of fire elements are checking the object list on a given square (that is other fire elements) at a given tick, and this until fire dies a few seconds later. Now imagine this. create a 'fire' arch at square X. When inserted, arch code register a move_event for the square and also analyse immediatly content of square. when new things are added to the square, the fire can check immediatly if this item can burn. Most of the time, there is nothing to burn. when the fire element gets activated avery X ticks, it does not have to explore a list of 100 other fire object to know there is nothing burnable where it belongs. Saying it's more important to add new features than modularize the code is simply a short term view. Since am part of this projects, i saw new features coming on a regular basis. Today the code, imho, is far less maintanable then it was 5 years ago. And if we continue to focus on features without architecture the code will be a blotted piece of unmaintanable code in a few years. If i remember well, Mark Wedel already had in the past to request from developper they spend more time on fixing the server code then add new features. There are tons of features in code map maker simply don't know about. Moreover there are tons of security issues in the code. They could be isolated and identified far more easily during a reorganisation process. I hope we will ge to an agreement on this subject. If you are going to go ahead with it, before you do anything to the code you will need to define what goes out to what modules, and what depends on what. Since CF was not designed to be modular you may also find recursive dependancies which will need resolving first. But I suspect you knew this already... ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ 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
Re: [crossfire] Moving server towards a modularized system?
That is what the hurd project thought at the begining, the reality is diffrent. --- tchize [EMAIL PROTECTED] wrote: You forgot the other important point, modularity reduces speed of development, sometimes catastroptically, you only need to look at GNU Hurd for an example of that. i see the exact opposite of behaviour at work. Project initiated in a modular way, or migrated to a modular approach are easier to manage for the following reasons 1) You don't need to have knowledge of how the whole code works to be able to work on parts of it 2) You can isolate changes in only a part of the code It strikes me that crossfire is (still) not yet mature enough to have a fixed interface to all the modules that would be used, only a couple of months ago all the python scripts were broken by a plugin change, and I know I for one wouldn't want to attempt to fix the weather 'module' the next time the interface to it was broken. Architecture must be handled from the very beginning and currently there is no architecture design on crossfire project. A way to structure things here is suggested. This may not be the best approach, but it's far better then what we currently have. And nobody in the last year did propose anything to fix architecture problems in crossfire. And in modularized projects, the interfaces between modules are not always clear, they are not fixed and would probably never been. Some code migrate from one module to another after experience show it is needed nearer to the core, or on the opposite, it get further from the core because it is not as multipurpose as we may have thought in the begin. Some modules sometimes get gathered as a unique module. Some other gets splitted in sub modules. That's the lifecycle of a project. It works, and well. Yes sometimes there are clash, sometimes a very big change in a module is a pain in the ass for all people using the modules. But considering the gain, in development speed, in code learning curve and bugs hunting, it is clearly worth it. You argue a change in 'core' could interfer with 'weather' and you don't want to fix weather if it gets broken by that change in core? Well i claim, with current organisation of code, a change *anywhere* in code (not only what we could define as core) can break the weather. (Or potentially break anything else). That is something a modularized approach tends to prevent as much as possible. And am not speaking of compilation here. Compilation problems are easy to solve. You could argue, currently, you can't make a change in core that would make weather uncompilable, which with a plugin system could be possible. But, this is not a difficult fix, the most difficult bugs to fix are those which let the code compilable but with subtle invalid logic. And the last one happends a lot in crossfire. regards ___ 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
Re: [crossfire] Moving server towards a modularized system?
Try not to dismiss things solely because they disagree with your opinion. Modularizing the server would create a ton of problems, breakage, and solve nothing and add even less: it is busy work. If you must be busy be busy on some new feature rather then scrapping the last 10 years of work (and that is what would happen if we seriously went on the modularizing war path). Things you can help add: plots (with red). drunkeness. work on regional fiat currencies. pilotable boats (new arch in addition to the exit boats we have), horses, etc. perl plugin? --- Yann Chachkoff [EMAIL PROTECTED] wrote: Le Lundi 16 Janvier 2006 18:47, Miguel Ghobangieno a écrit : That is what the hurd project thought at the begining, the reality is diffrent. The Hurd project thought a microkernel architecture was interesting for reasons other than maintainability. It is also a stalling project for reasons unrelated to the concept of modularization itself. If you're to use examples to illustrate your thoughts, try to use one you really know and have an in-depth understanding of. -- Yann Chachkoff --- Garden Dwarf's Best Friend --- GPG Key: http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 ___ 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
Re: Re: [crossfire] Moving server towards a modularized system?
Try not to dismiss things solely because they disagree with your opinion. I dismissed a flawed analogy, based on wrong technical assumptions. It is not an opinion point, but rather the rebuttal of an out-of-topic flambait. Modularizing the server would create a ton of problems, Tons ? Name them, then, and we'll have something to debate. breakage, Just as there is with *each* code change. Are you suggesting that we stop changing the code ? and solve nothing As I (and others) argumented, it eases a couple of development issues. It could be a flawed view - but then, demonstrate it, and suggest other solutions. Note that those points weren't based on air, but on significant experience in other projects, not on taste or other egocentric or sentimental feelings. and add even less: it is busy work. If you must be busy be busy on some new feature Given that you are not a coder, you have no right to decide for me what I should work on (Note that I usually don't follow such a philosophy - but since you expressed the exact same reasoning not so long ago, I find it appropriate to provide the same kind of answer now). rather then scrapping the last 10 years of work (and that is what would happen if we seriously went on the modularizing war path). Why ? I see a rant based on a pure sentimental feeling from somebody who has little knowledge of the Crossfire code, or of C coding in general. Provide technical arguments, and we'll have a serious discussion. If you cannot, then stop spamming the list. Just as a side note, scrapping the whole code has never been the intend. Next time, try to understand the emails you read before flaming their content. Things you can help add: Out-of-topic - we're discussing the pros/cons of modularization, not about your personal wishes about the code. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Sorry, in the initial post I presumed it would be python, but a C plugin seems like a reasonable idea. For one thing, I can't imagine a C plugin ever not being able to be installed (unlike python where people could be lacking the libraries) That said, trying to figure out what is optional or not is difficult. I'd venture to say a lot of people would say the random maps really are not optional (or if those are optional, what else is optional, like shops, monsters, etc) I'd think that if there is a C plugin, aside from the different passing in of the values, and using appropriate callbacks for functions instead of calling them directly, it could access the function data directly? Eg, it should need to do a plugin callback to set the dam of an object, it could just set ob-dam? That said, the plugin itself won't fix all the ills. To do that, more radical changes are needed in the basic functions as is, and that will break things. For example, it was brought up the idea of meteor swarms and/or swimming. Doing those in plugins don't really fix anything. The basic problem here is that insert_ob_in_map() does a lot more than just puts the object on the map and links it up. It checks for move_on/move_off flags. It checks for merging. It checks if the object glows, and thus updates lighting, checks to see if it blocks movement/line of sight. It is those things which make a consistent behavior difficult (and also what causes meteor swarm to slow down the server). To be redesigned, insert_ob_in_map should just do only that. The functions that call it should make the other checks (can we merge with something on this space? should we check move_on status, etc). But making those type of changes is likely to result in breakage in various places (insert_ob_in_map is called in 146 places for example). Although, perhaps at a first pass, a new flag like INS_OBJ_ONLY_AND_DONT_DO_ANYTHING_ELSE could be added (ok, maybe a littler shorter, but you get the point). all that said, I do think it is fair to discuss other work to be done - if you have limited resources, it makes sense to discuss where those resources go. Yet at the same time, given this is a volunteer project, one can't really force anyone to do anything. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
I personally don't see much reason to rewrite existing code that is working fine as a plugin. There are just enough things that could be/should be done than rewriting working code doesn't make sense. As Yann said, i was not really mentioning rewriting stuff - apologies for the confusion. Weather system, for instance, could be put in a plugin, and still retain its functionnality - talking about it because it's currently half broken, and not always enabled, depending on servers. Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: [crossfire] Moving server towards a modularized system?
Sorry, in the initial post I presumed it would be python, but a C plugin seems like a reasonable idea. Yep, I easily understand the confusion, given that for the most part, the Python plugin was the only one widely used (Actually, it is the Crossfire-Python bridge itself that is the plugin, not the scripts it allows to run). For one thing, I can't imagine a C plugin ever not being able to be installed (unlike python where people could be lacking the libraries) Well, it really depends on what the C code requires as dependencies - the Python plugin has one with the python libs for example. But stuff that was initially in the server code would have no such external dependencies indeed. That said, trying to figure out what is optional or not is difficult. I'd venture to say a lot of people would say the random maps really are not optional (or if those are optional, what else is optional, like shops, monsters, etc) Well, I don't think we should actually draw a line between what is optional or not in gaming terms, because basically nearly everything actually in the server code could be considered as core in that respect. On the other hand, I think splitting the code in logical entities, more or less independent of the others, would be a path of thinking to try. As such, random maps would appear as a good target for modularization, since it doesn't really depend on anything else, apart from very basical operations, and is called only at a few places. Alchemy would be another good candidate - both are very important in the game, yet are working very much like black boxes - complex code with relatively limited interactions with the rest of the code. I'd think that if there is a C plugin, aside from the different passing in of the values, and using appropriate callbacks for functions instead of calling them directly, it could access the function data directly? Eg, it should need to do a plugin callback to set the dam of an object, it could just set ob-dam? Theorically, yes: there's nothing preventing such a thing. Wrapping such access behind functions was basically to allow checking that the values passed were in the correct range, and to provide encapsulation of the data (so that a plugin wouldn't get tempted to directly change fields it wasn't supposed to change without a high risk) That said, the plugin itself won't fix all the ills. That's true. It is a way to make some things easier, but it is definitely not a magical answer to all problems. My opinion is that it would make the code cleaning/maintenance easier, but it will certainly not do that maintenance by itself. To do that, more radical changes are needed in the basic functions as is, and that will break things. Sure ! But I think such changes would be easier to make if the code was, in a way or another, split into smaller entities, so that they affect only a limited part of it. And indeed, a lot of functions would benefit from some in-depth rebuilding. Also, part of the problems of code debugging/maintenance come to how things are distributed all around the code - finding where to add/change things is a rather complex task. Making small changes to make the code more readable and editable would thus be another important point to achieve, IMHO. all that said, I do think it is fair to discuss other work to be done - if you have limited resources, it makes sense to discuss where those resources go. Indeed, it does - as long as it stays a reasoned discussion attempting to find the best solution, and not a collection of ignorant rants and ridiculous analogies. I'm tired of having to read such useless things, which (un)surprizingly always come from the same person. Yet at the same time, given this is a volunteer project, one can't really force anyone to do anything. Yes, although I understand the urge that many people have to see some funny/interesting ideas implemented. Simply, there is a civilized way to ask for those, a way that unfortunately not everybody seems to have understood. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
It is not half broken as far as I can tell. Yes it's not running on MF, that doesn't mean it's broken. It gives few problems on Cat2. This whole thing is about slowly dumping whatever MF doesn't use. Open your eyes, the 2nd biggest server runs weather code at it's most extreme, in terms of players that's not a few. (Sure most servers don't run weather, but most servers are at 0 players also). --- Nicolas Weeger [EMAIL PROTECTED] wrote: I personally don't see much reason to rewrite existing code that is working fine as a plugin. There are just enough things that could be/should be done than rewriting working code doesn't make sense. As Yann said, i was not really mentioning rewriting stuff - apologies for the confusion. Weather system, for instance, could be put in a plugin, and still retain its functionnality - talking about it because it's currently half broken, and not always enabled, depending on servers. Nicolas ___ 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
Re: Re: [crossfire] Moving server towards a modularized system?
I suggest you not implement a huge worthless code change that is nothing but busy work. I reject your assertion that cave's analogy is flawed as it is not. If you want to code code something new useful rather then breaking the server as is what will happen if you go forward with this plan. You also will be holding off any new large codechanges for months as they wait for you to be done with this not-needed reshuffling. --- Yann Chachkoff [EMAIL PROTECTED] wrote: Try not to dismiss things solely because they disagree with your opinion. I dismissed a flawed analogy, based on wrong technical assumptions. It is not an opinion point, but rather the rebuttal of an out-of-topic flambait. Modularizing the server would create a ton of problems, Tons ? Name them, then, and we'll have something to debate. breakage, Just as there is with *each* code change. Are you suggesting that we stop changing the code ? and solve nothing As I (and others) argumented, it eases a couple of development issues. It could be a flawed view - but then, demonstrate it, and suggest other solutions. Note that those points weren't based on air, but on significant experience in other projects, not on taste or other egocentric or sentimental feelings. and add even less: it is busy work. If you must be busy be busy on some new feature Given that you are not a coder, you have no right to decide for me what I should work on (Note that I usually don't follow such a philosophy - but since you expressed the exact same reasoning not so long ago, I find it appropriate to provide the same kind of answer now). rather then scrapping the last 10 years of work (and that is what would happen if we seriously went on the modularizing war path). Why ? I see a rant based on a pure sentimental feeling from somebody who has little knowledge of the Crossfire code, or of C coding in general. Provide technical arguments, and we'll have a serious discussion. If you cannot, then stop spamming the list. Just as a side note, scrapping the whole code has never been the intend. Next time, try to understand the emails you read before flaming their content. Things you can help add: Out-of-topic - we're discussing the pros/cons of modularization, not about your personal wishes about the code. ___ 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
Re: [crossfire] Moving server towards a modularized system?
Frankly, I have to agree with mikee to some degree on this point. I generally have little trouble finding something after a combination of getting a feel for the code, which I have gotten pretty good for a while now, as well as skilled grepping. However aside from some things like this, I do find modularization can have merits, it just depends on 1) How much effort it takes to modularize, 2) How effective the modularization API is designed (i.e. currently the existing plugin API is vastly insufficient for server modularization) and 3) Where we draw the line of what to modularize. Personally, I don't think we should modularize very much, but if the API is good enough (which I would likely be picky about myself), then it might be worth doing for a limited number of things. Alex Schultz Miguel Ghobangieno wrote: I have to do the same thing when I am adding things to my perl rpg (which is not smaller in lines of code then crossfire). It's not a big hassle, and how else will the code know what's going on? Use grep. --- tchize [EMAIL PROTECTED] wrote: Speaking of my experience with crossfire code. I have developped a few add-ons to crossfire in the past (don't remember the list). From my point of view, adding new features in the code is currently a pain in the ass. I have dropped features add-ons which took me lots of time simply because it has become nearly impossible to find something in the code. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Mark Wedel wrote: That said, trying to figure out what is optional or not is difficult. I'd venture to say a lot of people would say the random maps really are not optional (or if those are optional, what else is optional, like shops, monsters, etc) Indeed. On this example, IMHO random maps are not optional, as they are essential to some quests, and also soon would be used by land plots (though land plots would in my opinion be a relatively good thing to implement as an optional-but-defaultly-on C plugin) I'd think that if there is a C plugin, aside from the different passing in of the values, and using appropriate callbacks for functions instead of calling them directly, it could access the function data directly? Eg, it should need to do a plugin callback to set the dam of an object, it could just set ob-dam? Personally, I think that a C plugin interface for modularization, it should provide full direct access to the data, though recommend use of wrappers functions unless you know it's safe. That said, the plugin itself won't fix all the ills. To do that, more radical changes are needed in the basic functions as is, and that will break things. For example, it was brought up the idea of meteor swarms and/or swimming. Doing those in plugins don't really fix anything. Indeed. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Yann Chachkoff wrote: Well, it really depends on what the C code requires as dependencies - the Python plugin has one with the python libs for example. But stuff that was initially in the server code would have no such external dependencies indeed. True. I imagine dependencies to be fairly standard C dependencies. But I could imagine someone writing a plugin in C++ with appropriate wrappers. On the other hand, I think splitting the code in logical entities, more or less independent of the others, would be a path of thinking to try. As such, random maps would appear as a good target for modularization, since it doesn't really depend on anything else, apart from very basical operations, and is called only at a few places. Alchemy would be another good candidate - both are very important in the game, yet are working very much like black boxes - complex code with relatively limited interactions with the rest of the code. Agree. And in fact, any object that does something 'interesting' when applied could be a plugin, since most such objects are also very well self contained. However, I'd counter that if it is just 20 lines of C code to do that 'whatever', it could be more convenient to just add that 20 lines to apply.c I say this because I imagine plugins would probably be organized by plugin/C/plugin_name. Maybe have one directory for basic plugins (one in which the entier plugin is in one file). But if plugin grows to the extent that there are 50 'trivial' plugins, one could say finding the code there isn't any more convenient than having it sit in apply.c I'd think that if there is a C plugin, aside from the different passing in of the values, and using appropriate callbacks for functions instead of calling them directly, it could access the function data directly? Eg, it should need to do a plugin callback to set the dam of an object, it could just set ob-dam? Theorically, yes: there's nothing preventing such a thing. Wrapping such access behind functions was basically to allow checking that the values passed were in the correct range, and to provide encapsulation of the data (so that a plugin wouldn't get tempted to directly change fields it wasn't supposed to change without a high risk) I'd imagine it is more important for the plugin wrapper to provide a consistent interface to the various functions, so that if a function handling changes in the C code (say a function now takes another argument), that all the plugins don't have to be rewritten - they can keep using the existing code, with the wrapper just passing in some default value. Sure ! But I think such changes would be easier to make if the code was, in a way or another, split into smaller entities, so that they affect only a limited part of it. And indeed, a lot of functions would benefit from some in-depth rebuilding. Also, part of the problems of code debugging/maintenance come to how things are distributed all around the code - finding where to add/change things is a rather complex task. Making small changes to make the code more readable and editable would thus be another important point to achieve, IMHO. True - some functions have grown a bit in complexity and could certainly use a rewrite. And I could envision doing some things as plugins would make some things easier/more modular (Going back to what someone said, objects that the player uses are complicated - need to update the apply code, but depending on the object, may also need to update the code that actually describes the item - I could see with appropriate plugin support, all that could be done in the plugin, so all code related to that object is in one place) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Why? That's just extra useless busy work. You could code in drunkenness (see previous post) if you're itching for something to do. --- Nicolas Weeger [EMAIL PROTECTED] wrote: Hello. I'm wondering about moving some parts of the code to plugins. IMO things like weather system (excluding darkness-related things) could be moved to a plugin, and just hook to server core. Random maps generation too could imo be moved. (particularly weather, as it's really optional, setting for that). Actually, shouldn't the server be just a core with basic rules, and everything else moved to plugins? Nicolas ___ 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
