[crossfire] 1.60 release thoughts

Mark Wedel mwedel at sonic.net
Wed Feb 9 00:15:27 CST 2011

On 02/ 6/11 01:57 AM, Nicolas Weeger wrote:

>> - At some point, the legacy character creation code should get removed, and
>> related, basically all the ST_ values/player_set_state().
> Makes sense too. Many commands (join party, form party) should be first handled
> by client to get player's input.
> Note that there'd be some return value for commands, eg "join party<name>"
> with a return value of "-1 wrong password" so the client can display the
> password prompy.

  Right - in the account management code, I added the ability for the server to 
send back failure responses, and that same logic could get used here.

  In fact, many commands that take such input may have failure scenarios - 
create party could still fail if that party name already exists.

>> - For ChangeLog/CHANGES file:  I suggest the ChangeLog file get generated
>> by svn2cl - this is already done for maps.  But each area also has a
>> CHANGES file, which updated by hand but is used to note
>> improvements/things of more general interest - hard to say where to really
>> draw the line, but reformatting, minor bug fixes would not go in the
>> CHANGES file - big features would.  Maybe the determination is anything
>> that actually affects gameplay?  Thus, bug fixes wouldn't typically get
>> put in (they may change gameplay because someone is exploiting a bug).
>> One reason I bring this up is that with the maps ChangeLog file from SVN,
>> really no way to get any real useful content from that - I pretty much
>> used the crossfire traffic - it is that type of stuff that could perhaps
>> get put in the CHANGES file.
> I think the manually made file should only list significant (and maybe only
> player-related?) changes, not all the minutia we have now.
> So crossfire-traffic would just be a copy of that file.

  Yes, that is what I was thinking - it is just never clear how significant 
something should be.  But that can be left up to the developer

  I'd argue that there could be significant changes that are made (and worth 
noting) but that don't really directly impact the player.  EG, if someone fixed 
some serious crash bug or made major performance improvements, that is probably 
worth nothing in the CHANGES file, even though as players see it, that impact 
may not be so great.

More information about the crossfire mailing list