[CF-Devel] Adding New Stuff (again) - Requests and suggestions

[crossfire-devel-admin at archives.real-time.com]

  You make a lot of good points.

  Documentation is sorely lacking.

  IMO, one good design method is to write the doc for what you want to do before 
you do it.  Post it out - this not only describes what you are doing, but can 
then act as the doc when done, with perhaps some updates as things move along. 
Giving some thought to what you right will probably make the code better also.

  That what to contribute is a tough one.  It it hard to turn down code that 
will do something new and cool.  However, at the same time, it is interesting to 
note how many new maps there are relative to new features.  And arguably, maps 
requires less technical knowhow than coding something new into the game. 
However, I think trying to force people to do something may not be good. Eg, I'm 
required to make some maps before I can add some new feature, and it is the 
later that I'm more interested in doing.  How good do you think the maps I 
create will really be?

  that said, there are certainly some issues.  People seem much more inclined to 
work on new features than fix bugs, yet arguably this second point is more 
important.

  As far as date files at load time:

There is already a lot more stuff that can be set at load time than in the past 
- settings, exp, etc.  However, at the same time I look at some of the files 
that are there (spell_params, skill_params) and really wonder how often people 
actually touch them, and if they had to re-compile the server to make the 
change, would that be a show stopper?

  Arguable, the spell_params and skill_params are the worst examples - compiled 
in defaults + files that get loaded at run time.  It seems to me the right thing 
is basically one or the other - compile in or load at run time.

  There is also the 'races' file, which IMO is probably even worse - it jsut 
takes archetype information and changes it at load time.  Better solution would 
be to just update the archs with the right information than using that file.

  Perhaps to me the bigger issue of making everything setable in load time files 
is where does it end?  There is a lot of data that could generated at load time, 
but there is an issue of return on investment, so to speak.  Computer speed has 
incrreased a lot faster than code growth in crossfire, to the extent that a full 
compile of crossfire probably takes just a minute or two on a fast computer.

That said, I could certainly see pulling some data into more central include 
files.  In the example of order of skills being searched for, having that in the 
skills.h file probably makes more sense than embedding it in some .c file.  And 
.h files tend to change less, so any patches that may be necessary ahve better 
odds of applying.




_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel