Re: Re: Re: [crossfire] Moving server towards a modularized system?
Indeed. Just because the server can be modularized thus blocking any other new development whilst that takes place doesn't mean it's a good idea. There is no reason to block any other development. I suppose you know that the C in CVS means Concurrent ? I for one frown on the idea of making the server slower There is no reason that it would be slower than it is now. There are no reason for a modularized system to be slower than the current version. The only overhead would be when connecting callbacks to objects - and that's hardly something you'd notice, unless if you're running Crossfire on a [EMAIL PROTECTED] and blocking other development. I think I already said it, but there is no reason to block other developments. Everybody who has already worked in large-scale software projects knows that parallel development on different parts of the code is a rather common practice. That you believe that only a single task can be performed at once on something like the Crossfire code shows that you urgently need to get better informed on software development/engineering techniques and more generally on modern teamwork methods. For what is worth, I could already be working on a code prototype on my personal workstation - would you ever notice it before I submit a patch ? Would it prevent somebody else to add something in the code in the meantime ? The answer to both of those questions would appear obvious, I think, to every reasonable person. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gcfclient options deathlist
On 1/18/06, Mark Wedel [EMAIL PROTECTED] wrote: Miguel Ghobangieno wrote: Yes, it would be best to remove that option from the menu IMHO. 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. Regardless of that, I would suggest that it is something that is something that is so infrequently the intended course of action, that making the player issue the command themselves would be desirable. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: Polymorph etc
On 1/18/06, Anton Oussik [EMAIL PROTECTED] wrote: Adding fighting levels to weapons would also make sense, and in my opinion would be more consistent for things like swords and bows than item power is. Having a minimum level for every object that can be applied wouldn't be that difficult, I'd be inclined to say it could work well with item power as well. (to wield sword of foo you must be level n at one_handed_weapons and have x spare item power) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Re: Moving server towards a modularized system?
On 18/01/06, Yann Chachkoff [EMAIL PROTECTED] wrote: 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] Actually, this will depend on how modular the code will be. Going back to Hurd analogy for a second, one of the reasons has not become widely used yet is not because it is modular, but because being so modular makes IPC (Inter-Process Communication) slow (using the GNUMach microkernel), as processes are forced to make frequent calls to the kernel, and therefore the whole thing runs about 66% slower [than Linux]. There is a theoretical design with will make it only 15% slower or so (Hurd on L4), but it seems to have other problems, so the project is no longer sure what kernel it will run on when the Hurd gets released. Effectively, most of the development is spent looking for an architecture that is both modular and fast, and therefore it may look like real development is not happening. The same thing can be done to Crossfire, making one core module, which will be tasked with starting up, parsing command line arguments, and starting up all other things as modules, provide a way of synchronising them and provide Inter-Module communication. If a message is sent to a module that is not currently there the core would then try to load that module before failing, so the random map generator only gets loaded after someone decides to enter a random map. This feature will also make handling errors easier, so if a person enters a random map, and random map generator is not avaliable, it will be possible to display an error to the player, like The total chaos inside prevents you from entering. The player could then decide to build and install just the random map generator, and the server would not need to be restarted to apply the changes. Likewise for all other components, so applying a security update will not mean restarting the server. Also if some module segfaults, it will not need a restart of the whole server, but simply of that module. This should aid the server stability, as something wrong when casting meteor swarm resulting in the spell not working will not disturb someone else killing dragons in a dungeon. Having the code highly modular also will mean each module can be started as a seperate process (or thread, but that is slightly less portable, if somewhat faster), making it possible to run the server usefully on SMP systems (or even clusters), and therefore potentially much faster than the speed at which the current server runs. I don't know if this is what is wanted, but the advantages seem tempting to me. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: Moving server towards a modularized system?
Le Mercredi 18 Janvier 2006 18:25, Anton Oussik a écrit : Also if some module segfaults, it will not need a restart of the whole server, but simply of that module. This should aid the server stability, as something wrong when casting meteor swarm resulting in the spell not working will not disturb someone else killing dragons in a dungeon. Well ,technically, as a plugin is loaded in the process memory area and share the process pid, a segfault in module mean a segfault in whole server (we are not in java where you cant do a catch (Throwable t) Having the code highly modular also will mean each module can be started as a seperate process (or thread, but that is slightly less portable, if somewhat faster), making it possible to run the server usefully on SMP systems (or even clusters), and therefore potentially much faster than the speed at which the current server runs. Of course when code is modular at this point you can think about multiprocesses interaction and all sort of stuff ;) but that's not, i think an immediate aim :) (and yes, in this case a segfault in a module is not a segfault in core processe :p) I don't know if this is what is wanted, but the advantages seem tempting to me. to me too, but for having already explored possibilities of multithreading cf, you have to fix before lots of potential concurrency issues :) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- 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 pgpEJ32eqG7Ak.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?
On 1/18/06, tchize [EMAIL PROTECTED] wrote: Having to grep throught to code to guess where you have to add your new features is a symptom of upcoming code management problems. I agree on this point, however I suspect that much of this could be avoided by simply shifting a few functions and #define's around, much of what exists currently has been grandfathered into various parts of the code (look at include/define.h for a good example of this) moving these into more logical locations (or maybe even just documented locations) would help in finding various parts of the source code. Likewise moving things around could probably reduce the number of functions which are called from different files, improving the usefulness of text-editor based find tools. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: Re: Re: [crossfire] Moving server towards a modularized system?
Well enjoy raping the server. I'm retiring from CF untill a certain unnamed feature I was promised 1/2 a year ago (no not plots) is in. See you soon or never. --- Yann Chachkoff [EMAIL PROTECTED] wrote: Except that you are not working on one section of the code, you are restructuring the whole server into diffrent modules. This means that if you develop in cvs there will be breakage with any and everyone else as you sweeping edits touch every facet of the glory that is crossfire. Well, the required editing is, for the most part, moving existing code rather than change it. Algorithms will stay the same, execution paths as well, etc. What will change is the way various functions are called - so for example, calling apply(this_object) would become this_object-manual_apply(this_object) (This is only an illustration :)). Only in a few cases will new code be needed - mostly to bind the modules content to the code. So basically, you'd expect problems in: - The module loading/unloading (a clearly separate, specific piece of code); - Improperly converted calls (which can be avoided if we're careful enough). So no heavy breakage is expected. The C in CVS may mean concurrent but it doesn't mean perfect. I never said the contrary. It just means that no, even a refactoring of that scale wouldn't block the whole project for months, that's all. If you want to make the sweeping changes on your own system; enjoy. But please, before committing to cvs do extensive bugtesting so that it 1) doesn't make the code any slower, 2) doesn't break anything, and 3) maybe makes MS less of a hog? I think all Crossfire coders perform quite some tests before committing to CVS - nobody would want to be responsible of severely damaging the server. Simply understand that coders are not perfect, and that they cannot think about all possible cases. To take a recent example, there was a library-related bug in the new plugin code that I didn't spot on time; was that because I didn't test that bit of code ? Of course not - but on the architecture I was trying it on, it simply didn't exist. Also, let's not forget that the CVS codebase wasn't meant to be used on production servers: the CVS is (theorically) the repository in which the work in progress server code is stored. Stable versions are distributed in the various packages available on the SF website. Now, it is true that if some big changes are to be done, it would probably be a good idea to release a new stable version first, so that server administrators like you can get all the recent features without having to struggle through the possibly stability-threatening changes. Regarding possible performance issues, I think that there are ways to ensure that nothing noticeable happens. Most of the time lost would probably get when the plugin/module gets initialized and loaded - and that's unimportant for the running speed of the server. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: gcfclient options deathlist
Anton Oussik wrote: Yes, it asks you something like Are you sure you want want to quit the character?, not WARNING: You are about to delete the character! Are you sure you want to completely delete the character and entirely and irreversably remove all evidence that the character ever existed for ever and ever?. I think what Mikee was referring to is that the comfirmation message does not look threatening enough. I agree, it is how I lost my first ever two characters. :-) Mark, would it be possible to make the -split option work on gtk-v2 client? It effectively allows the client to run on any screen resolution, and allows users to position controls the way they like it. I think the main reason so many people are still using gtk-v1 client is because it is able to better fit their needs. Anything is possible. It'd be a bit of work if you want to load/save window size and position. I'm also not 100% sure how well suited it is to do that - the layout is all done by glade, and I don't know if there is any reasonable way to do split windows and keep the glade interface design. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
