[crossfire] Moving server towards a modularized system?
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
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
Re: [crossfire] Moving server towards a modularized system?
>Hello. Hi :) > 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). > I agree - that's exactly for such purposes that I created the plugin system in the first place. It would allow to make a very clear separation between the "important", core code, and the fluff-n-fuzz glued around it. In the long run, I think it would contribute to make the code easier to maintain and to expand, as it would be divided in smaller chunks for a lot of tasks. > Actually, shouldn't the server be just a "core" with basic rules, and > everything else moved to plugins? *I* think it should, even if it is not a trivial task for everything. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Wouldn't what would happen is that the 'plugin' stuff is ignored and gets broken and only things that are used on MF worked on? That sounds like what this is for, to slowly jettison that which MF does not use. --- Yann Chachkoff <[EMAIL PROTECTED]> wrote: > >Hello. > > Hi :) > > > 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). > > > > I agree - that's exactly for such purposes that I > created the plugin system in the first place. It > would allow to make a very clear separation between > the "important", core code, and the fluff-n-fuzz > glued around it. In the long run, I think it would > contribute to make the code easier to maintain and > to expand, as it would be divided in smaller chunks > for a lot of tasks. > > > Actually, shouldn't the server be just a "core" > with basic rules, and everything else moved to > plugins? > > *I* think it should, even if it is not a trivial > task for everything. > > > ___ > 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?
Nicolas Weeger 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? The harder part is to define what are the core/basic rules and what are options. Taken to an extreme, you could say just write the entire thing in python/perl/whatever. There isn't much a reason to do that (you're basically re-writing anything, so only point would be to try to remain some compatibility). 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. All that said, could probably make some general rules for a plugin/built in test: 1) Speed - I'm sure the plugin is slower to some extent - ignoring the actual plugin language, the fact that access of a lot of data is done through callback functions vs direct access has to hurt a bit. This isn't an issue if a plugin isn't used very often, but probably would become an issue if the plugin is used multiple times every tick. 2) Complexity - I'd make the case that debugging very complex pieces is done if all is in native C - don't have to debug accross languages, etc. Nicolas ___ 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?
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
Re: [crossfire] Moving server towards a modularized system?
> 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
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
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?
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 pgpKbPz4Cn8VF.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?
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: [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: [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: [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/. 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?
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. > "Finding something" is not really that difficult. However, adding new things often is, because it is not uncommon to have to modify the code at several different places. I see this as inherently bad - if I want to implement a new object type for example, I'd prefer putting its whole code in a single place than having to edit several source files (some being in common/, others being in server/). Of course, a skilled coder that has got a good knowledge of the Crossfire code generally has little difficulty to find its way through the code - but not every contributor can/wants to afford the time required to get that in-depth knowledge of the code; besides that, having to play with grep to find the relevant piece of code is already a failure in itself, IMHO: if even somebody used to the source has to rely on a search engine to find its way through it, can we consider there is no problem ? > 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, > 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. As for the code located in the module itself, there would be little to change; at most, the function names being called (to call the wrappers instead), and the initialization/termination code (which will quite probably be the same in most cases). > 2) How effective the modularization API is designed (i.e. > currently the existing plugin API is vastly insufficient for server > modularization) > I think it is unsufficient for two reasons: (a) The API provided to plugins is not complete enough; (b) There are no ways for a plugin to interact with the server outside of the local/global events. I think (a) can be completed as modularization advances - if I tried to make a plugin out of alchemy, I'd check all the "external dependencies", then move them into the plugin API if required. It however means that the API will be an evolving target as long as modularization is in its early stages, though. As for (b), as I said earlier, I think it can be solved by offering to plugins the possibility to hook themselves to some often used functions in the code. In such a case, I think the plugin code should get hooked by callbacks contained in objects whenever possible (so, instead of calling apply(op) and make a switch(op->type) in apply, the specific behavior of op would be directly bound into the object as a callback and called by op->apply(op)). In that scenario, there would be no overhead involved when compared to the current situation - it would basically replace a switch statement by a function call. > and 3) Where we draw the line of what to modularize. > I'm not sure a line has to be drawn to what/what not modularize. I think a more important question is: to what level should the modularization take place ? I don't think there are simple answer to those questions. I'm not even sure answering them in a definitive, strict way is really required. > 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. > > 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) > Note that "optional/necessary for some quests" should not be a critera for modularization IMHO, because it is one you can use to justify nearly every function implemented in the game. On the other hand, the "optional/necessary for the server to run" sounds much more relevant. Can the server work without random maps ? Of course - it simply means that the maps using that feature will not work, but the others will be completely unaffected. It has no impact on the gaming rules, and no influence on the characters. > 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. > Nothing currently prevents a plugin to modify the data it has acces
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: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
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/. 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 > > --
Re: [crossfire] Moving server towards a modularized system?
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
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?
You haven't worked on many complex projects then. The upset this will cause in crossfire development (and devs will wait untill it's done before committing again because they don't want their new code to be broken) will be very large. I would like to see plots etc in crossfire in my lifetime, your "AWSOME KAWABUNGA!" idea of ripping apart the server will stall development for no freaking reason except that you think that you are above using grep. --- David Delbecq <[EMAIL PROTECTED]> wrote: > 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 > __ 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?
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?
Le Mercredi 18 Janvier 2006 07:30, Mark Wedel a écrit :
>
> However, I think if you start grouping all that stuff together, you start
>loosing some of the advantages.
>
Depends once again on the size of things you regroup and how much they have in
common. if you start making 80 modules for what is current server i think you
also miss the point on managability :)
> 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.
>
>
You said it, it's the poor man version ;)
If we modularize things, it is a good thing to have a plugin part in it. Even
if some of things currently in core could be done as module not plugins (like
let's say, binding a libCrossfireRandomMap.a at link time) you will probably
get into the case when someone want to add new behaviours in plugins.
--
--
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
pgpmIXGTib5I6.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 Mercredi 18 Janvier 2006 15:42, Miguel Ghobangieno a écrit : >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. > >The C in CVS may mean concurrent but it doesn't mean >perfect. > >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? > First, it will be a step by step change. For the obvious reason, a patch changing 40% of server code would take weeks to create and during this change, developper of the patch would have to do a regular 'cvs update' to incorporate other developpers change and would have to adapt each of their change to new modular system. Second, indeed cvs isn't perfect. It's written in there doc, nothing can replace the coder in case of a conflict (eg we are moving away the whole parts of move_apply() somewhere else and at same time another developper is trying to add new object type). This is not a problem. After cvs update, the guys trying to add things to move_apply() will see a conflict in move_apply() and will see the other coder comment saying "this code has been mainly moved to xyz". Just also move your new add-on. Once again, there has been restructurations in the past. This of course lead to conflicts during cvs update process. Then what? Just fix the conflict. That's how teamworks goes. Team is adapting you code changes during their development process, when team has commited adapt your uncommited changes to what team commited. Unless you work on a 'checkout, work on my stuff for 2 months locally, try to commit', the conflicts shouldn't be a big deal as, once again, it is very difficult to commit big patches. If it is really needed, i suppose the change could be done in a branch. This would allow people who want to explore the idea of modularized system to work in team and try different paths without fearing the 'try not to break the existing'. This head should then be merged on this branch in a regular basis. This is lots of additionnal work. But it also has it's gains imho. And when modularized system is ok, move it to the head. But there, this mean when branch is finally moved to the head (if idea does not proves to be a dead end), people will indeed see a 40% of server code patch coming. -- -- 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 pgpx0zKdARpF5.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 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?
Le Mardi 17 Janvier 2006 22:40, Yann Chachkoff a écrit : >> 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. > >Idea != Decision. Thanks to specify Yann :) > >Besides that, I don't think anybody requires your permission to code. > Democracy, we require team approval, not not every individuals approval (or code would never evolved :p ). However, i listen to every suggestion and critics (as far as i am able to find time to read them all ;) ) >> Why should all work have to stop because YOU want to restructure the >> server.. because you can't figure out grep... > >I can assure you that tchize is skilled enough to use grep, by far. The > whole point was that a properly structured code should *never* require > using grep. Yes, even large-scale enterprise projects. > man grep | grep -E '^[ ]*-|^[ ]*grep \[' usefull help shortcut :p -- -- 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 pgpL8Y6Q3x3ew.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 17:46, Miguel Ghobangieno a écrit : >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). > Ho yes am experimented in big refactoring of team project. Once again there won't be something as a 40% server code change in a row (unless we work on a branch and then have to merge it in head) >This will hold up usefull game development for months >all because you and friends believe that you are above >grep. I use grep on a regular basis. But for scripts or unstructured text searching. Moreover, you are assuming all people wanting to contribute to crossfire: 1) know how to handle grep 2) have a grep tool at disposal crossfire is multiplatform, not every windows coder have djgnu or wygwin installed on their system, and not every coder is skilled like you in grep. Having to grep throught to code to guess where you have to add your new features is a symptom of upcoming code management problems. ___ 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 17:54, Miguel Ghobangieno a écrit : >. 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. > lot's of 'things' added did break things (weather code made the server simply uncompilable in the beginings, led to duplicate items. Town portal led to people able to acces other people's appartments and get stuck. polymorphing monsters lets to demons inside newbie house... For most of slight or more important breakages of game logic, there is a common factor. Side effects unexpected from the add-on coder. Regulating what add-on has access to does allow it a wider range of possible improvments (as it is easier to find where in core you have to interact) while giving coder more insurance on possible side effects of it's calls (documented list of callable methods). -- 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 pgp3ubtsQxPA7.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: [crossfire] Moving server towards a modularized system?
tchize wrote:
Le Mercredi 18 Janvier 2006 07:30, Mark Wedel a écrit :
However, I think if you start grouping all that stuff together, you start
loosing some of the advantages.
Depends once again on the size of things you regroup and how much they have in
common. if you start making 80 modules for what is current server i think you
also miss the point on managability :)
Right, but you have to keep this in mind.
For example, there are probably about 100 different object types out there.
So if we take the module example, you either get 100 different modules for all
those objects, or a fairly big/complex module that handles those 100 different
object types.
It is unclear to me right now which is the better case.
This gets especially messy if say 10 object types are complex enough that they
really should be in their own module. So now you have those 10 separate modules
+ common module for other 90 types. This then starts to get away from making
things easy to find (is it in the common module, or one of those other 10)
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.
You said it, it's the poor man version ;)
If we modularize things, it is a good thing to have a plugin part in it. Even
if some of things currently in core could be done as module not plugins (like
let's say, binding a libCrossfireRandomMap.a at link time) you will probably
get into the case when someone want to add new behaviours in plugins.
True. However, I'd think that to do this by true plugins, the
objects/archetypes have to get updated, eg, hooks added for describe item, apply
item, etc. My poor mans version avoids that.
Another question is whether a plugin can call another plugin - that in itself
could perhaps limit the ability of some things to be in plugins.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Le Jeudi 19 Janvier 2006 07:44, Mark Wedel a écrit : > For example, there are probably about 100 different object types out there. > So if we take the module example, you either get 100 different modules for all > those objects, or a fairly big/complex module that handles those 100 different > object types. I think there are more object types than this! > > It is unclear to me right now which is the better case. > none of both solutions :) > This gets especially messy if say 10 object types are complex enough that they > really should be in their own module. So now you have those 10 separate modules > + common module for other 90 types. This then starts to get away from making > things easy to find (is it in the common module, or one of those other 10) > Let's say i've got a problem with a buggy trap. This is how i see it: 1) i do a 'dump' in dm mode to get info on buggy archetype. Server says me type xyz (the trape type) and maybe also in the dump the is a list of plugins linked to this object. 2) i go in the code of this (or those) module and start trying to fix the bug :) (please note, currently to fix an object, the procedure is something like dm -> get type -> open define.h -> get the associated #TYPE for this type -> issue a grep on this type to find where there is specific code.) Also, having a simple document of which module does what would be interresting. It's easy to manage (a module X -> description chapter and a item type -> module chapter) > > True. However, I'd think that to do this by true plugins, the > objects/archetypes have to get updated, eg, hooks added for describe item, apply > item, etc. My poor mans version avoids that. Or we can have a plugin, in initialisation code do a 'plug those callbacks to type x, thosr to type y, and those to skill z'. Ideally, in this idea, if you omit the 'traps' plugin from server code, you can have a server which knows nothing about traps :p (an we could imagine the traps module handling trap objects and trap related skills :p). If you omit the all spells modules, you could have a server in which casting spells is impossible (only bash and crash) > > Another question is whether a plugin can call another plugin - that in itself > could perhaps limit the ability of some things to be in plugins. Very good point. Plugins put aside for a few seconds, in modular project, there is usually a notion of modules dependencies (module X depends on module Y and core, module Y depends on core). I think we need to handle this dependencies system or we lose a bit part of interest in modularization. Back to plugins, that means we need plugin X to be able to do calls on plugin X. This shouldn't be difficult to do. Simply a plugin would link a list of callback in initialization but would also provide core a list of 'public callback' (that is a list a named method). Core will the provide every plugin depending on X the possibility to access them. > > > ___ > 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?
David Delbecq wrote: This gets especially messy if say 10 object types are complex enough that they really should be in their own module. So now you have those 10 separate modules + common module for other 90 types. This then starts to get away from making things easy to find (is it in the common module, or one of those other 10) Let's say i've got a problem with a buggy trap. This is how i see it: 1) i do a 'dump' in dm mode to get info on buggy archetype. Server says me type xyz (the trape type) and maybe also in the dump the is a list of plugins linked to this object. 2) i go in the code of this (or those) module and start trying to fix the bug :) (please note, currently to fix an object, the procedure is something like dm -> get type -> open define.h -> get the associated #TYPE for this type -> issue a grep on this type to find where there is specific code.) 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. 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. Also, having a simple document of which module does what would be interresting. It's easy to manage (a module X -> description chapter and a item type -> module chapter) But that sort of sidesteps the point, doesn't it? Isn't one of the issues right now that code is hard to find? If we have to document the new code, that doesn't seem to be going in the right direction - for that matter, a document could be written right now of 'these are steps to do to make a new object'. 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. True. However, I'd think that to do this by true plugins, the objects/archetypes have to get updated, eg, hooks added for describe item, apply item, etc. My poor mans version avoids that. Or we can have a plugin, in initialisation code do a 'plug those callbacks to type x, thosr to type y, and those to skill z'. Ideally, in this idea, if you omit the 'traps' plugin from server code, you can have a server which knows nothing about traps :p (an we could imagine the traps module handling trap objects and trap related skills :p). If you omit the all spells modules, you could have a server in which casting spells is impossible (only bash and crash) 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. 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. 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). 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). Another question is whether a plugin can call another plugin - that in itself could perhaps limit the ability of some things to be in plugins. Very good point. Plugins put aside for a few seconds, in modular project, there is usually a notion of modules dependencies (module X depends on module Y and core, module Y depends on core). I think we need to handle this dependencies system or we lose a bit part of interest in modularization. Back to plugins, that means we need plugin X to be able to do calls on plugin X. This shouldn't be difficult to do. Simply a plugin would link a list of callback in initialization but would also provide core a list of 'public callback' (that is a list a named method). Core will the provide every plugin depending on X the possibility to access them. 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). 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. ___
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
Re: [crossfire] Moving server towards a modularized system?
Le Mardi 24 Janvier 2006 07:38, Mark Wedel a écrit : > > 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. > 'Using object' is a core feature imho, while the behaviour of a specific object or object type when applied should be left to appropriate plugin I agree but with following reserve: - you are assuming 1 module is managing the apply while it would probably be 1 module is managing a defined range of object type (eg: applying handles, applying readables, applying wearables) and it could be interresting at some point to remove module for a specific category of items, like removing magic items management (applying , recharge, other stuffs) if you dedice you don't want spells in your server. - A developper could be interrested in removing parts of the server for testing purpose. If i have a specific problem loading a given map and i don't know if it's because of objects inside map, or because of map loading code, I could easily disable lots of plugins to get only core + maploading code + protocol and check if the problem is still there. Sure you couldn't do much ingame, but it is interresting for developping purpose. This also help you isolate your code. If core+your module+maybe a tester module (which could, for example, fake a user connection and load a test map) isn't enough to have your module working in test environment, then you might need to consider your module has other dependencies. > 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. Additional reason not to group together spells, monsters, alchemy and random map! > > 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). > > 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. > Well removing a .so or .dll from a dir is also easy. > > Well, you can't have a single list of all the set_type_callbacks() unless > all > the functions are in the same module. > > 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. I suppose you are refering to the problem of storing callback informations in mapfile (because at runtime a pointer is just a pointer, you would just need to update it if module is reloaded, already the case in current plugin code). That could be done using pluginname+declared plugin callback name. It's implementation details. For item type it's even easier as it's not stored in file. It's the plugin which declares at load time it want to have given listeners on given types. > > I think the term plugin vs module probably needs to be clarified, as well > as > clarification what approach we are really taking. 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. > > 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. 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 You could do modules in .a (and even suggest current plugins be converted to .a and gathered at link time, you would only lose the runtime reloading facilities). But you must ensure each module has it's separate .h files. Also, you must ensure you don't have cyclic modules dependencies and ensure you use only modules you depend on (that is only include .h of modules you depend on) To me, be it link time modules (.a) or runtime modules (.so), the work to do
Re: [crossfire] Moving server towards a modularized system?
tchize wrote: 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: , 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 removed. Certainly, some clean up and seperation cou
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?
Le Mercredi 25 Janvier 2006 13:16, Miguel Ghobangieno a écrit : > We want to cross module boundries and there is no aka spaghetti code > reason for us to > want 3rd party "module" additions (unless one is > pro-proprietary). > no comment. ___ 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?
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?
> 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?
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?
> 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
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?
> 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: Re: [crossfire] Moving server towards a modularized system?
> Wouldn't what would happen is that the 'plugin' stuff is ignored and gets > broken and only things that are used on MF worked on? That sounds like what > this is for, to slowly jettison that which MF does not use. That's ridiculous. The distinction between what is part of the core and what is not would have to be defined at a technical level, not at a 'political' one. If the anser to "can the game work without functionality X still work ?" is yes, then X isn't core. We can start nit-picking endlessly on the details of the definition of the core, but it changes nothing to the base idea. So things like weather or python are not part of the core, because they "only" extend the game functionalities. Note that splitting the code into plugins never meant that the content of those plugins would suddenly leave the codebase or be "left in the cold". Now, if you think that a functionality you feel important is put aside, then start supporting it - everybody is free to contribute to the Crossfire code. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: [crossfire] Moving server towards a modularized system?
> The harder part is to define what are the core/basic rules and what are > options. Definitely. But I'm not sure such a definition is really needed. I think that if a functionality is clearly "optional" or isn't strongly tied with the rest of the code (as it appears to be the case for random maps or the weather system), then it should at some point be modularized. I'm not sure I'd like to see a "let's define what the core is" debate being open - it will lead to endless sterile discussions, because everybody has its own idea, and that there are multiple definition of what the core should include, depending on how you perceive the problem. > Taken to an extreme, you could say just write the entire thing in > python/perl/whatever. There isn't much a reason to do that (you're basically > re-writing anything, so only point would be to try to remain some > compatibility). The idea is not to "rewrite everything" - but to move existing code into plugins. Sure, the "accessors" will have to be rewritten - but there's no reason to rewrite the whole internal code logic to do such a move. > 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. Again, there is nothing like rewriting whole sections of the code - only the "glue"-related stuff would have to be. As for the other important things to be done first, I tend to think that making the code more resistant and easier to debug should be our top priority, above the addition of new functionalities. In this respect, I think that modularizing things is a way to improve code maintainability on the long run. > 1) Speed - I'm sure the plugin is slower to some extent - ignoring the actual > plugin language, the fact that access of a lot of data is done through > callback functions vs direct access has to hurt a bit. This isn't an issue > if a plugin isn't used very often, but probably would become an issue if the > plugin is used multiple times every tick. I'm doubtful it hurts "a bit" - most of the overhead comes (a) from the analysis of the parameters passed by plugins to the server through va_args and (b) from the call to registered local plugin events. (a) is hardly an issue, even when dealings with hundreds of calls per second (unless we still want to consider 1997 machines as a relevant target architecture...). (b) is indeed an issue, as the server currently has to browse a list of objects to be able to call a plugin function. At some point, I think that besides the events currently available, plugins should be able to directly register callbacks that would be stored in lists and called at specific places in the code - "code events", thus, that would get called when a given server function is called, to modify or change its result. > 2) Complexity - I'd make the case that debugging very complex pieces is done > if all is in native C - don't have to debug accross languages, etc. Who said that the intend was to write plugins in another language than C ? It would be *possible* of course, but it doesn't mean that it is what we *want*. I don't see why you'd need to debug "across languages" - the base idea of a modularized system is to allow separate debugging of the modules and the core. And finally, given that the whole codebase is currently written in C, its modularization would lead to modules written in C as well. The whole question comes down to: "is a monolithic code easier or harder to debug and maintain than a modularized one ?". My personal opinion on this is that the answer is "it is harder". ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: [crossfire] Moving server towards a modularized system?
Throwing in my two pennies: In general modularisiation of the code will improve maintainability, as the core will be smaller, and tidier. Modules can then be compiled in or left out as the person running the server wishes. This would make debugging easier if anything, as then as long as the core is stable (which should not be too hard if it is made small) it will be always possible to isolate the modules that are causing trouble and either fix them or not use them until they are made more stable. 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. 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
Re: Re: [crossfire] Moving server towards a modularized system?
On 1/16/06, Anton Oussik <[EMAIL PROTECTED]> wrote: > 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. 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. 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. If there is going to be breakages, how about breaking the things that are already obsolete? There is a lot of old code in crossfire that has long since become redundent, which nonetheless increases complexity, the most obvious of these (to my mind) are: the original 'map' command, which doesn't support big faces at all. code to convert spells into regular objects, which was a conversion that happened years ago. the gnome client, which doesn't work (ok, that's client side, but still) stats support for the old skill system polymorphism (most of it is #if 0'ed out, but I'd prefer removed completely) 32 bit exp support (surely no one still uses that?) cfsndserver (it doesn't work) ___ 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: 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: 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 then 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: 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: Re: [crossfire] Moving server towards a modularized system?
> 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. > That is true - I'm not myself in favor of a system in which several languages would get used. Introducing something else than C in the server code would definitely create a lot of issues, and isn't something I'd like to see without a prior discussion. Probably the best rules is: code in C, and if you *really* think another language is needed, then ask the mailing list first, so the case gets discussed. Just because it can technically be done doesn't mean it is a good idea. ___ 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: 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. Idea != Decision. Besides that, I don't think anybody requires your permission to code. > Why should all work have to stop because YOU want to restructure the server.. > because you can't figure out grep... I can assure you that tchize is skilled enough to use grep, by far. The whole point was that a properly structured code should *never* require using grep. Yes, even large-scale enterprise projects. --- 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 ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
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. I for one frown on the idea of making the server slower and blocking other development. --- Yann Chachkoff <[EMAIL PROTECTED]> wrote: > > 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. > > > That is true - I'm not myself in favor of a system > in which several languages would get used. > Introducing something else than C in the server code > would definitely create a lot of issues, and isn't > something I'd like to see without a prior > discussion. > > Probably the best rules is: code in C, and if you > *really* think another language is needed, then ask > the mailing list first, so the case gets discussed. > Just because it can technically be done doesn't mean > it is a good idea. > ___ > 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 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?
Oh if that's the case let me just commit all the mlab maps in their current uni-directory form over the objections of everyone else that prefers multi-directory. Know why I don't do that; because everyone else prefers multi-directory. Try mucking in the linux kernel without grep, tell me how that goes. --- Yann Chachkoff <[EMAIL PROTECTED]> wrote: > > 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. > > Idea != Decision. > > Besides that, I don't think anybody requires your > permission to code. > > > Why should all work have to stop because YOU want > to restructure the server.. because you can't figure > out grep... > > I can assure you that tchize is skilled enough to > use grep, by far. The whole point was that a > properly structured code should *never* require > using grep. Yes, even large-scale enterprise > projects. > > --- 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 > > > > > ___ > 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: Re: [crossfire] Moving server towards a modularized system?
> Oh if that's the case let me just commit all the mlab maps in their current > uni-directory form over the objections of everyone else that prefers > multi-directory. Know why I don't do that; because everyone else prefers > multi-directory. Did you need the permission of anybody to write those maps ? No. So I don't think we need your permission to explore new coding ideas, even if they finally appear to be dead-ends. Making proposals, coding a prototype, submitting a patch to the mailing list, all this doesn't mean the code will finally get into the CVS (actually, there are examples in Crossfire itself of proposals that were extensively discussed and with some code created that never got into the CVS). > Try mucking in the linux kernel without grep, tell me how that goes. Pretty well, actually - the Linux kernel source code is extensively documented and is highly structured. I've worked on the kernel in the past, and never needed grep to find my way through the code. Besides that, compare what can be compared: the Linux kernel is more than 6 million lines of code. The Crossfire code is way smaller than that. Your example suggests that using a map to go buying my newspaper every day is perfectly normal, since I'd need one to go into holidays in a faraway country. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
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: Re: Re: [crossfire] Moving server towards a modularized system?
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. The C in CVS may mean concurrent but it doesn't mean perfect. 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? --- Yann Chachkoff <[EMAIL PROTECTED]> wrote: > > 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 > __ 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: Re: Re: [crossfire] Moving server towards a modularized system?
> 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
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
