Re: [crossfire] 1.60 release thoughts
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 partyname 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. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 1.60 release thoughts
Hello. - Within the file release on sourceforge, I think it makes more sense to just have the version directories at the top (eg, 1.60.0, 1.50.0), and then under each one, put all the associated files - server, maps, client, different clines (linux, windows, java, etc). Agreed, makes sense. - 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. - 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. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] 1.60 release thoughts
1.60.0 is close to being out the door, it might be by the time you read this message - after doing it, I've had various thoughts: - With SVN tree, all computer generated files get removed - I think the only thing really left is some of the macro files - since developers out of SVN are going to need autoconf/automake, pretty likely they will have aclocal/libtoolize, etc (in fact, I think those later ones are in autoconf or automake packages anyways) - Within the file release on sourceforge, I think it makes more sense to just have the version directories at the top (eg, 1.60.0, 1.50.0), and then under each one, put all the associated files - server, maps, client, different clines (linux, windows, java, etc). That would certainly be easier to navigate - very clear what the latest one is and no hunting for files. If we do get the case of some files not released (lets say we do an interim 1.61.0 for clients but not server), the readme there could note to use the 1.60.0 server. Thoughts? This becomes perhaps more relevant when jxclient and gridarta are added, as then there are lots of top level items. - At some point, the legacy character creation code should get removed, and related, basically all the ST_ values/player_set_state(). Anything that should have confirmation should be handled on the client, eg, if creating a party, should be an interface on the client to do that, which confirms the party password (and throws up an error if a mismatch), and it just sends the command to the server - maybe a protocol command for that, but there really isn't any reason password confirmations should be handled on the server. This just makes a much cleaner design - if a character is logged in, they are always playing. - 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. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
