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