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

Tue May 1 08:46:50 CDT 2001

Le Mardi  1 Mai 2001 01:10, vous avez écrit :
>

      DAVID DELBECQ wrote:

     >

      > Ok, you say it requires a lot of changes because it is a problem of lots

     >

      > of spells. If this is the case, this means you changed a lot of stuff

     >

      > from 0.97 version cause this version didn't lag and i don't think you

     >

      > made so heavily changes.

     >

     >

       I looked, and don't see any changes between then and now which would

     >

      immediately change this behavioiur.  Note the lots of spell causing

     >

      lag/high cpu consumption is infinitely old (or at least as old as

     >

      crossfire).   But generally, it starts to require a fair number of spells

     >

      before you hit the threshold (although, to be honest, I don't know where

     >

      the exact threshold is).

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. 
Crossfire-0.98.0 consumed nearly 80% CPU power for the same map. This is not 
an impression, it is a fact. It is also a fact that I was unable to play the 
map locally on a K62/450 with only one player - Will Crossfire 1.0 require a 
PIII/Athlon to run fine ?

>

     >

      > Moreover, you speak about lots of spell on the same square. I have

     >

      > checked, there are no more than 5 objects on a square (6 if i include my

     >

      > self, 7 with the floor). The map, as i said, contain only 10 spellcaster,

     >

      > disposed so that 8 of them are hurting the player the same time, reducing

     >

      > number of spellcaster is simply stupid.

     >

     >

       I would guess that the number of spells per square would need to be at

     >

      least 20-30 before serious performance problems would get observed.

Again, it depends on the machine where you are running Crossfire on.

>

     >

      > 3rd point, even if map could be smaller, with lesser spellcaster, don't

     >

      > forget that level 80 players can cast more than 10 spells nearly at the

     >

      > same time, linked on the same key in the client (e.g. cast 5 icestorm, 5

     >

      > burnig hands, 5 holy word, 1 counterwall in the same key to do lots

     >

      > damages in a short time in the arena.....). This cannot be prevented.

     >

     >

       Correct, and in fact that can cause performance issues.  comet/large

     >

      fireball are actually the worst examples, as they create a lot more objects

     >

      for the one cast.  But yes, the problem happens no matter who is casting

     >

      the spells.

     >

     >

       However, generally players are more restained than most monsters are, who

     >

      cast things as fast as possible.  Players are probably more likely to try

     >

      and limit the number of spells to not be more than it really takes -

     >

      otherrwise you burn up mana and also increase the likelihood of

     >

      incinerating the treasure you may want.

     You forget that Crossfire is designed to be a 'Multiplayer Adventure Game'. 
This means that there could be many players on a server at the same time. And 
if two or three level 110 players in a team join their forces to finish a 
map, it means lots of spells at the same time - theirs and those of the 
opposing monsters... And high-level players can cast spells _very_ fast...

>

      > You say you are fixing bugs in crossfire for version 1.0 THIS clearly is

     >

      > a bug, i recommend you to check closely at the cast cone code, it

     >

      > contains a lot of useless assignements in a loop. (System does not seem

     >

      > laggy when casting things other than cone!!). If you make some checks,

     >

      > you could also see the the time consuming is done when spell casting, not

     >

      > when the spell spreads.

     *snip*
>

       Is this a bad bug?  Sure.  Should it be fixed for 1.0?  Would be nice, but

     >

      doing so would mean delaying 1.0 a long time - as said, the change to

     >

      improve that processing is non trivial, and is fairly integral - it really

     >

      needs to be pretty thoroughly tested.

     >

     >

       I will note that there are several public servers where this does noot

     >

      generally seem to be a problem.  And I have no illusions - there will be

     >

      some bugs in 1.0.  But a little while ago, it was decided that getting 1.0

     >

      out as quick as reasonably possible was what was important, and not fixing

     >

      everything on the TODO list.

What is said here above looks quite strange and makes me somewhat anxious 
about the way things are going. This means that:

- Bugs difficult to correct will not be resolved because it is too 
time-consuming;

- 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').

- 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').

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 
are fixed, etc. I know it is not programming - it is managment. And I also 
know saying such things will not be on the taste of many people, but is is 
sad too see that an OpenSource project goes more and more 'closed' because of 
bad managment and communication techniques.

Again, I know that many people will not like what I say, but it is how I (and 
others too) see things.

Commander Gros