[crossfire] Moving server towards a modularized system?

[Miguel Ghobangieno]

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 <tchize at myrealbox.com> 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 at metalforge.org
> >
>
http://mailman.metalforge.org/mailman/listinfo/crossfire
> > 
> > 
> 
> _______________________________________________
> crossfire mailing list
> crossfire at 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