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] Polymorph etc
Le Lundi 16 Janvier 2006 23:06, Nicolas Weeger a écrit : > > Sure, i'll do it - lemme just confirm the money has correctly been > transferred from your account to mine :) > OMG, i think it ended in my account. Well better luck next time ryo. /me going out to buy a new ipod with that money ___ 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] gcfclient options deathlist
Ok, to try and summarise from this. (this is how I'm reading the existing responses, yell if you think this isn't a fair summary). Not a target for removal: Split Information Window (Takes effect next run) Automatically re-applies a container when you use apply to close it. Still targeted for removal: (on) Colored Inventory Lists (on) Colored Information Text - maybe to be replaced by some future feature (off) Print Grid Overlay (on) Cache Images (on) splash window (gros' suggestion) Options on how to display resistances: - keeping the two options involving scroll bars, but still haven't heard from an advocate of the no-scrollbar option (if this were removed, it could go from 3 buttons to 1) the options in the list above need someone to claim the use of them sometime within the next fortnight. ___ 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] gcfclient options deathlist
Yes, it would be best to remove that option from the menu IMHO. Could we also make quit ask the person if they really want to delete their character (and then ask again for confirmation)? (server side). --- Brendan Lally <[EMAIL PROTECTED]> wrote: > On 1/17/06, Rick Tanner <[EMAIL PROTECTED]> wrote: > > Would it be OT or out of scope to ask for the > "File -> Quit Character" > > option in the menu to be renamed to "File -> > Delete Character" ? > > Well, it wouldn't be if you instead suggested that > the menu entry be > removed altogether. > > I'm inclined to think that the better option, it > isn't as though the > quit command should be used particularly often. > > ___ > 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
[crossfire] On moving the Lone Town apartment
Greetings all, It was pointed out to me on IRC that the Lone Town apartment does not fit the Lone Town story line. Specifically the apartment is too big and ostentatious for Lone Town. So, I propose moving that set of maps to a "country villa" setting somewhere. I still want an apartment in, or near, Lone Town and intend to make a single map to fit in with the original Lone Town idea (as far as I understand it). I will also leave the build shop in Lone Town but scale it down a touch. If moved I want the country villa to be near somewhere that does not currently have a permanent apartment. It does not matter if the town nearby is small since a country villa is intended to be rural. Feed me some suggestions please. I was thinking perhaps in the world maps to the near East of Lake Country? Or even in the pup land maps near Lone Town would be ok I think. I could then just remove the apartment in Lone Town. IMO the Regular Army people would be living in big country villa's (or town apartments ;-) and the Freedom folk would be the poor and downtrodden types. So perhaps access to the country villa (or apartment if it stays in Lone Town) should depend on owning a Regular Army Passport. "Feed me Seymour!" As I already stated I do not want to put this somewhere near a city that already has a permanent apartment. I also do not want to place it so far out in the wilderness that it is impractical to own. I want to make this change (if everyone agrees I need to move that thing) before too many players buy them. I do not want to create more of an administration headache than necessary. TIA Gene -- Mandriva Linux release 2006.0 (Official) for i586 15:30:37 up 3 days, 22:23, 10 users, load average: 0.06, 0.05, 0.06 ERA Computer Consulting - http://www.eracc.com/ eComStation, Linux, FreeBSD, OpenServer & UnixWare resellers ___ 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: [crossfire] On moving the Lone Town apartment [bigworldized pupland]
lalo is bigworldizing pupland, the villas could be placed somewhere on said bigworldized pupland (note: how long untill it's done?). --- ERACC <[EMAIL PROTECTED]> wrote: > Greetings all, > > It was pointed out to me on IRC that the Lone Town > apartment does not > fit the Lone Town story line. Specifically the > apartment is too big > and ostentatious for Lone Town. So, I propose moving > that set of maps > to a "country villa" setting somewhere. I still want > an apartment in, > or near, Lone Town and intend to make a single map > to fit in with the > original Lone Town idea (as far as I understand it). > I will also > leave the build shop in Lone Town but scale it down > a touch. > > If moved I want the country villa to be near > somewhere that does not > currently have a permanent apartment. It does not > matter if the town > nearby is small since a country villa is intended to > be rural. Feed > me some suggestions please. I was thinking perhaps > in the world maps > to the near East of Lake Country? Or even in the pup > land maps near > Lone Town would be ok I think. I could then just > remove the apartment > in Lone Town. > > IMO the Regular Army people would be living in big > country villa's > (or town apartments ;-) and the Freedom folk would > be the poor and > downtrodden types. So perhaps access to the country > villa (or > apartment if it stays in Lone Town) should depend on > owning a Regular > Army Passport. "Feed me Seymour!" > > As I already stated I do not want to put this > somewhere near a city > that already has a permanent apartment. I also do > not want to place > it so far out in the wilderness that it is > impractical to own. I want > to make this change (if everyone agrees I need to > move that thing) > before too many players buy them. I do not want to > create more of an > administration headache than necessary. > > TIA > Gene > -- > Mandriva Linux release 2006.0 (Official) for i586 > 15:30:37 up 3 days, 22:23, 10 users, load average: > 0.06, 0.05, 0.06 > ERA Computer Consulting - http://www.eracc.com/ > eComStation, Linux, FreeBSD, OpenServer & UnixWare > resellers > > ___ > 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] gcfclient options deathlist
Miguel Ghobangieno wrote: Yes, it would be best to remove that option from the menu IMHO. Could we also make quit ask the person if they really want to delete their character (and then ask again for confirmation)? (server side). I just tried this out. If I select the 'Quit Character' option from the file list, it does ask if I want to quit or not. ___ 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
