[crossfire] Changing connection texts

[Mark Wedel]

Nicolas Weeger wrote:

>>   But I'm also not sure if your ingame comment refers to selecting a
>> character to play or creating a new one.  For creating a new one, we could
>> perhaps leave the existing mechanism there since redoing is more work.  But
>> making in game (map based) character selection I think would be more work
>> than just doing the appropriate dialogs.
> 
> Current creation mechanism sucks. Yes. It's bad. It's evil.
> 
> If only because first you choose stats then class - which then uses some stats 
> more than others.
> 
> 
> So let's take the opportunity to rewrite the character generation mechanism.

  Maybe I'll finally get around to do that in the next few weeks, given X-mas 
break and fact I've finished up all my home improvements.


> 
> 
> 
> 
>> Question on accounts:  Where do we store this information?  May be a flat
>> file or dbm file or something?  After all, the only information associated
>> with an account is the name, password, and characters for that account -
>> not a lot of information here.  But flat files don't work good if you have
>> thousands of entries.
> 
> Flat file seems ok for me.
> Obviously, I could suggest an abstraction layer with a pluggable storage 
> mechanism being DB/file/..., but in C that'd be a PITA to write :)

  Its a different topic than this, but having such a pluggable interface would 
be nice.  The biggest pain would be having to emulate it if a real database is 
not available (emulation would probably mean a flat file with fields separated 
by something or another)

  I can think of all sorts of stuff to record.  And if it was stored in an SQL 
database, one could then do analysis.  What are people really buying from the 
stores?  What spells are characters using?  Where are people killing monsters, etc.

  For crossfire, I was thinking something like dbm (or other native file based 
method) could be used, but I don't know how portable such methods are on non 
unix systems.  But looking at that, other than fast fetching of the keys, the 
data for that key is all stored in one field, so the server would still need to 
parse that out.  So doesn't gain as much as one would like.  I also suspect that 
for most servers, the size of this file wouldn't be very large, so even parsing 
a flat file wouldn't be that costly.