[Re: [[CF-Devel] CPU and memory?]]

Peter Mardahl peterm at tonks.EECS.Berkeley.EDU
Tue May 1 06:14:38 CDT 2001


>
     
     
     >
     
      You may have looked at the wrong place. It is definitely true that my 
     
     >
     
      Crossfire-0.97.0 consumed about 40% CPU power when loading the map of David. 
     
     
What "map of david"?  What map is this?

>
     
      - Bugs difficult to correct will not be resolved because it is too 
     
     >
     
      time-consuming;
     
     
Ever heard of milestones?  We defer the major fixes we foresee to
get something servicable and stable out soon.  We'll
leave the hard project which involves ripping out the innards
and restructuring for 2.0.

The hope is that with a reasonable 1.0 out, we'll generate
more developer and player interest in contribution to crossfire.

This was a consensus decision by the developers:  the current
code freeze--which Mark has the unpleasant task of
enforcing--is directly serving that purpose.

We do not have enough people NOR time to fix everything, and
getting a 1.0 out is, we hope, a way to get MORE people AND
programmer/designer/artist time to help with this game.

We should NOT wait until 1.0 is completely perfect before
releasing it.

>
     
      - Getting a '1.0' version number is more important than having a 'clean' 
     
     >
     
      program (note that in the TODO file, 1.0 is 'First true public release - 
     
     >
     
      fully stable, and very well balanced.' I see 'fully stable', not 'to be 
     
     >
     
      released as quick as reasonably possible').
     
     
Have you missed all the bugfixes that have gone in recently?
This crash fixed, that crash fixed, another crash fixed, this
weird thing removed, that bug killed.... and on and on and on.

Where have you BEEN?  Mean time to server crash has tripled in the
last several weeks, mostly due to Mark's efforts, with some help
from the rest of us.  TREMENDOUS progress has been made.

>
     
      - Getting a '1.0' version number is more important than wishes of players and
     
     >
     
      mapmakers (If Mr. Delbecq encountered the bug, it is certainly a problem for 
     
     >
     
      him and potentially for others, even if 'this is generally not a problem for 
     
     >
     
      public servers').
     
     
Yeah, we all wish for a totally fast and totally bugfree server.
Who, however, is going to do the work?  If Mark strangles the developers
from doing creative new stuff (the main attraction of working with
crossfire) for too long, they'll leave.

*that* is an excellent reason to push 1.0 out and lift the code
freeze as soon as possible, while also serving the need for
stability and game balance.  

It'd be REALLY nice if we could also eliminate the performance problem,
but Mark (and I, and others) think the problem is due to poor algorithms
in certain sections of the code, which would be a MAJOR rip-and-rework
job, best undertaken past the current milestone goal, which is
release of a version called 1.0, which has stability and balance as
its primary goals.

We'd all be thrilled if you could demonstrate otherwise and provide
a simple patch, one we could be sure wouldn't hurt the PRIMARY goal
of stability for the 1.0 release.

>
     
      I think the only feature needed by Crossfire before 1.0 release is a complete
     
     >
     
     
     >
     
      rethinking on how the code is managed, how players/mapmakers can make their 
     
     >
     
      wishes known, how the work must be distributed between contributors, how bugs
     
     
What's wrong with people sending email to crossfire devel, discussing
things there, which is how we've done it for a very long time?  Or
getting on the IRC channel and chatting with the developers and players
who happen to be around?
And as to distributing work, everyone works on what they want to work on,
and have time for, same as ANY open source project. 

And as to the 'command and control' structure for crossfire development,
there aren't that many of us.  Mark's doing the bulk of the work,
*and* has shouldered the job of lead maintainer, a job NO ONE else
wanted.  It's only fair that he have a good bit of control over
development.

And your charge of this being a 'closed' open source project are
completely off-base.  Most people who've really wanted access have GOT it:
I know of no one who hasn't.  In fact, we've pushed access onto
people who were reluctant to have it so that they'd quit bugging us
to incorporate their patches!



PeterM

    
    


More information about the crossfire mailing list