I have to do the same thing when I am adding things to my perl rpg (which is not smaller in lines of code then crossfire). It's not a big hassle, and how else will the code know what's going on? Use grep.
--- tchize <[EMAIL PROTECTED]> wrote: > Le Lundi 16 Janvier 2006 13:07, Anton Oussik a écrit > : > > Throwing in my two pennies: > > > > In general modularisiation of the code will > improve maintainability, > > That's also my opinion. > > > On the other hand modularising the code will > result in many changes, > > may introduce new bugs into the code, and is in > general a lot of work > > whilst the benefits are questionable (this will > only be useful if core > > is really small and most things are out in modules > which can be > > configured at configure stage). If someone has a > desire to do all that > > they are welcome to (it is an open source project > :-) ), but in my > > opinion implementing new features would be more > beneficial to the > > project. > > Speaking of my experience with crossfire code. I > have developped > a few add-ons to crossfire in the past (don't > remember the list). > From my point of view, adding new features in the > code is currently > a pain in the ass. I have dropped features add-ons > which took > me lots of time simply because it has become nearly > impossible to find > something in the code. > If you add a new arch type, you have to register it > in a define list, register > it in the movement function if it is active, > register it in the attack code > if it can attack player, maybe register it with > weather system if it can > interact with it, register it to spell casting > system if, for example, it > represents a spell modifier. Can you imagine today > creating an item which has > as characteristic 'owner can walk over water' > without modifying piece of code > everywhere? > > In a modularized system, you could have something > like that (it's just an > idea, it still has obvious flaws in aglorithms) > > when trying to move object from squareX to squareY, > you trigger a move_request > event on squareX listeners, on squareY listeners and > on object listeners. > Each listener can respond with NEUTRAL(0), ALLOW(1), > REJECT(-1) > if there is an allow, then allow movement > else if there are no reject then allow movement > else refuse movement > water would be REJECT non swimming obj, your item, > registered in player when > applied) would allow on every square with water. > The exact same idea can be used to create complex > check_inv, confusion spells, > director, no_movement traps . You just 'plugs' in > the movement code. > > Also this system can improve server performances. > Currently, one of the main > 'lag' problem of server is meteor swarm in the open > areas. thousands of fire > elements are checking the object list on a given > square (that is other fire > elements) at a given tick, and this until fire dies > a few seconds later. > Now imagine this. > create a 'fire' arch at square X. > When inserted, arch code register a move_event for > the square and also analyse > immediatly content of square. > when new things are added to the square, the fire > can check immediatly if this > item can burn. Most of the time, there is nothing to > burn. > when the fire element gets activated avery X ticks, > it does not have to > explore a list of 100 other fire object to know > there is nothing burnable > where it belongs. > > Saying it's more important to add new features than > modularize the code is > simply a short term view. Since am part of this > projects, i saw new features > coming on a regular basis. Today the code, imho, is > far less maintanable > then it was 5 years ago. And if we continue to focus > on features without > architecture the code will be a blotted piece of > unmaintanable code in a few > years. > > If i remember well, Mark Wedel already had in the > past to request from > developper they spend more time on fixing the server > code then add new > features. There are tons of features in code map > maker simply don't know > about. > > Moreover there are tons of security issues in the > code. They could be isolated > and identified far more easily during a > reorganisation process. > > I hope we will ge to an agreement on this subject. > > > > > If you are going to go ahead with it, before you > do anything to the > > code you will need to define what goes out to what > modules, and what > > depends on what. Since CF was not designed to be > modular you may also > > find recursive dependancies which will need > resolving first. But I > > suspect you knew this already... > > > > _______________________________________________ > > crossfire mailing list > > crossfire@metalforge.org > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire