From mwedel at sonic.net Tue Feb 1 00:45:37 2011 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 31 Jan 2011 22:45:37 -0800 Subject: [crossfire] 1.60 release thoughts Message-ID: <4D47AC11.2000505@sonic.net> 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. From leaf at real-time.com Wed Feb 2 21:19:09 2011 From: leaf at real-time.com (Rick Tanner) Date: Wed, 02 Feb 2011 21:19:09 -0600 Subject: [crossfire] crossfire-mapper In-Reply-To: <201101292124.34182.kbulgrien@att.net> References: <201101292124.34182.kbulgrien@att.net> Message-ID: <4D4A1EAD.5000208@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/29/11 9:24 PM, Kevin R. Bulgrien wrote: > > If anyone can confirm results or get different ones, I'd be interested in > hearing about them. > > I'm thinking a readme file in the utils folder might be helpful. Make sure your archetypes are updated, as some of the Error messages you list were recently fixed. Then, run make collect in the server/lib directory. Compile the server once again. I did these two (well, three actually..) steps, and the error alerts you list were no longer a problem. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFNSh6thHyvgBp+vH4RArHxAKDSs1dTWIwMXURftEH49mMmrF9NYACgr1/V 7+zmVzEsTDG19U+sW7KTtFs= =7gD4 -----END PGP SIGNATURE----- From kbulgrien at att.net Thu Feb 3 00:01:28 2011 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Thu, 3 Feb 2011 00:01:28 -0600 Subject: [crossfire] crossfire-mapper In-Reply-To: <4D4A1EAD.5000208@real-time.com> References: <201101292124.34182.kbulgrien@att.net> <4D4A1EAD.5000208@real-time.com> Message-ID: <201102030001.28185.kbulgrien@att.net> > > If anyone can confirm results or get different ones, I'd be interested in > > hearing about them. > > > > I'm thinking a readme file in the utils folder might be helpful. > > Make sure your archetypes are updated, as some of the Error messages you > list were recently fixed. > > Then, run make collect in the server/lib directory. Compile the server > once again. > > I did these two (well, three actually..) steps, and the error alerts you > list were no longer a problem. Still mystified. arch is up-to-date showing mod dates in the last few days, and I did explicitly do make clean and make install in the lib folder as well as in the server area., and rebuild and reinstall server. If I look where the server is installed, the date/time of the crossfire.0 and .1 files is current. strace confirms the new file is in use at the location where the server is installed. I tried running crossfire-mapper from both the server/trunk/utils folder and from the server install location and from the templates folder under utils... all giving the same results. I suppose maybe it might help to see if there is an svn commit that seems to address those things and then try to correlate the change with the current generated content of the archetypes file in the server install. From nicolas.weeger at laposte.net Thu Feb 3 01:41:53 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 3 Feb 2011 08:41:53 +0100 Subject: [crossfire] crossfire-mapper In-Reply-To: <201102030001.28185.kbulgrien@att.net> References: <201101292124.34182.kbulgrien@att.net> <4D4A1EAD.5000208@real-time.com> <201102030001.28185.kbulgrien@att.net> Message-ID: <201102030841.57199.nicolas.weeger@laposte.net> Hello. > Still mystified. arch is up-to-date showing mod dates in the last few > days, and I did explicitly do make clean and make install in the lib > folder as well as in the server area., and rebuild and reinstall server. > If I look where the server is installed, the date/time of the crossfire.0 > and .1 files is current. strace confirms the new file is in use at the > location where the server is installed. Note the file you want to check is "archetypes", since the "crossfire.x" files only contain pics :) "make clean" does not remove the "lib/archetypes" file, and won't collect, I just confirmed. As far as I can figure, the various make commands (except an explicit collect) are just happy with having a "lib/archetypes" file without checking the date. So I'd suggest to explicitely do "( cd lib && make collect && make install )" and try again. > I tried running crossfire-mapper from both the server/trunk/utils folder > and from the server install location and from the templates folder under > utils... all giving the same results. > > I suppose maybe it might help to see if there is an svn commit that seems > to address those things and then try to correlate the change with the > current generated content of the archetypes file in the server install. Here's the revision that added that check: Revision: 14083 http://crossfire.svn.sourceforge.net/crossfire/?rev=14083&view=rev Author: ryo_saeba Date: 2010-11-13 23:00:23 +0000 (Sat, 13 Nov 2010) Log Message: ----------- Do not allow spells without a skill defined. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From kbulgrien at att.net Thu Feb 3 02:48:47 2011 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Thu, 3 Feb 2011 02:48:47 -0600 Subject: [crossfire] crossfire-mapper In-Reply-To: <201102030841.57199.nicolas.weeger@laposte.net> References: <201101292124.34182.kbulgrien@att.net> <201102030001.28185.kbulgrien@att.net> <201102030841.57199.nicolas.weeger@laposte.net> Message-ID: <201102030248.47912.kbulgrien@att.net> > Hello. > > > Still mystified. arch is up-to-date showing mod dates in the last few > > days, and I did explicitly do make clean and make install in the lib > > folder as well as in the server area., and rebuild and reinstall server. > > If I look where the server is installed, the date/time of the crossfire.0 > > and .1 files is current. strace confirms the new file is in use at the > > location where the server is installed. > > Note the file you want to check is "archetypes", since the "crossfire.x" > files only contain pics :) Well, yes... and my communication was poor and inadequate as I had indeed checked that file for freshness. > "make clean" does not remove the "lib/archetypes" file, and won't collect, > I just confirmed. > > As far as I can figure, the various make commands (except an explicit > collect) are just happy with having a "lib/archetypes" file without > checking the date. > > So I'd suggest to explicitely do "( cd lib && make collect && make install > )" and try again. I had done make collect at all the appropriate junctures as well. Somehow, the server/trunk/lib/arch was an actual folder rather than a symlink to arch/trunk. Perhaps I did that in some long forgotten dream. Sorry. It's working now that I repaired the link. Thanks for your patient help. I wonder though, if there is a better way to manage that link... From nicolas.weeger at laposte.net Sun Feb 6 03:57:13 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 6 Feb 2011 10:57:13 +0100 Subject: [crossfire] 1.60 release thoughts In-Reply-To: <4D47AC11.2000505@sonic.net> References: <4D47AC11.2000505@sonic.net> Message-ID: <201102061057.17679.nicolas.weeger@laposte.net> 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 " 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From mwedel at sonic.net Wed Feb 9 00:15:27 2011 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 08 Feb 2011 22:15:27 -0800 Subject: [crossfire] 1.60 release thoughts In-Reply-To: <201102061057.17679.nicolas.weeger@laposte.net> References: <4D47AC11.2000505@sonic.net> <201102061057.17679.nicolas.weeger@laposte.net> Message-ID: <4D5230FF.3050308@sonic.net> 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" > 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. From mwedel at sonic.net Thu Feb 10 00:54:34 2011 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 09 Feb 2011 22:54:34 -0800 Subject: [crossfire] Skill thoughts In-Reply-To: <4D43B2F1.1070100@sonic.net> References: <4D43B2F1.1070100@sonic.net> Message-ID: <4D538BAA.9090603@sonic.net> On 01/28/11 10:25 PM, Mark Wedel wrote: > > I finally got around to recording my thoughts on a revised skill system: > > http://wiki.metalforge.net/doku.php/user:mwedel:skills > > Take a look, let me know what you think - as the bottom of the article says, I > have no immediate plans to implement it - it is mostly thoughts that have been > bouncing around my head that I wanted to record someplace. Just a note, I've added an attribute section to that, since to balance any system, how the attributes (and their bonuses) has to be thought out/balanced also. IMO, current system is not balanced due to large bonuses some high attributes get and fact they are applied to first 10 levels. From tolga.dalman at googlemail.com Sun Feb 13 05:47:40 2011 From: tolga.dalman at googlemail.com (Tolga Dalman) Date: Sun, 13 Feb 2011 12:47:40 +0100 Subject: [crossfire] Player creation bug Message-ID: <4D57C4DC.2040401@project-psi.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, currently, the player creation in crossfire 1.60 is broken. You can reproduce it by doing the following with the crossfire-client 1.60: - - create new character: fire hatchling/monk - - maximize str, dex and con - - set remaining stats so that they are 1 in total - - distribute the remaining points to pow This will fail, because the stats are checked after applying the race (but not the class). The attached patch fixes this issue. Being on this topic, I have some suggestions for the crossfire-client. I think it is already pretty good, however for a normal user like me it is quite difficult to create a character in a sane way. So I suggest: 1. add descriptions for stats (e.g. tooltips). 2. make the stat number field read-only (this feature is actually not useful, but rather confusing and error-prone). 3. when selecting a race or class automatically update the stats to the required minimum values. Also, these values should become constraints, i.e. pushing the '-' should not yield in stats lower 1. 4. disallow negative unspent stat points. This should be a simple check in the '+' buttons. 5. "Choose starting map" should be replaced by the actual drop-down menu with "Scorn" as default value. I hope these suggestions are helpful :) Thanks and best regards Tolga Dalman -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNV8TcAAoJEATLYSm2cxP9t9QH/jVFZTnVNZJUOwLpjp7nNhQO j9oh9KJaH2Ur1bhgvUVsuUw0OicK0vsiAOfpT5v6WOer0ORsE7Sl+vH6M85u4fs5 mJZzAGcCI9/G7qbi/AjDdxuwuXV8PRxOP1SAOKLCbjVZW7H1PfJdszGW64Gv51+u Ah07nVGoNHC/w77I2rDzLiZ3jQBXOXybjY36OyOF3e2drJf8v9p/5/YMnCmBqi5l GCCyavUwFOMwwIlLMaxagdRCbK3brqRgLWgkOchI6w2NAsOrY+JdRb4PtR2OWOnl psjiHxuHIcc5vt/I3m27885pL9geSp0ysEAbeRmXur/9mXOgEtJvY5ROLnjXiEQ= =Rtb2 -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: player.c.diff URL: From nicolas.weeger at laposte.net Mon Feb 21 15:14:27 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 21 Feb 2011 22:14:27 +0100 Subject: [crossfire] Skill thoughts In-Reply-To: <4D43B2F1.1070100@sonic.net> References: <4D43B2F1.1070100@sonic.net> Message-ID: <201102212214.31961.nicolas.weeger@laposte.net> > I finally got around to recording my thoughts on a revised skill system: What is the planned implementation timeline? I'm wondering whether it's worth fixing (or at least trying to fix) existing monsters with the current system, or just waiting for the new one. Note that of course I'm ready to help implementing that, and others may be too. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Mon Feb 21 16:14:10 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 21 Feb 2011 23:14:10 +0100 Subject: [crossfire] Player creation bug In-Reply-To: <4D57C4DC.2040401@project-psi.org> References: <4D57C4DC.2040401@project-psi.org> Message-ID: <201102212314.14919.nicolas.weeger@laposte.net> Hello. > currently, the player creation in crossfire 1.60 is broken. > This will fail, because the stats are checked after applying the > race (but not the class). The attached patch fixes this issue. Thanks for the patch :) I'm no specialist of this part of the code, but my reading is that both the "basic" combo (race and modifiers) and the "full" combo (race, class and modifiers) should be valid for the character to be considered valid. Your patch removes the race+modifiers check. So I'm not sure it's totally correct, because shouldn't the character without its class be valid? Of course, the client interface may be bugged if it accepts such combos the server deems invalid :) > Being on this topic, I have some suggestions for the crossfire-client. > I think it is already pretty good, however for a normal user like > me it is quite difficult to create a character in a sane way. > So I suggest: > 1. add descriptions for stats (e.g. tooltips). > 2. make the stat number field read-only (this feature is actually not > useful, but rather confusing and error-prone). > 3. when selecting a race or class automatically update the stats to the > required minimum values. Also, these values should become constraints, > i.e. pushing the '-' should not yield in stats lower 1. > 4. disallow negative unspent stat points. This should be a simple check in > the '+' buttons. All those make sense, yes. > 5. "Choose starting map" should be replaced by the actual drop-down menu > with "Scorn" as default value. Well, it's nice to have a map description, which is why (I guess) there is a sub-dialog. Right now the description is basic, but if it is extended, a tooltip may prove to not be enough. Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From leaf at real-time.com Mon Feb 21 17:48:42 2011 From: leaf at real-time.com (Rick Tanner) Date: Mon, 21 Feb 2011 17:48:42 -0600 Subject: [crossfire] Player creation bug In-Reply-To: <4D57C4DC.2040401@project-psi.org> References: <4D57C4DC.2040401@project-psi.org> Message-ID: <4D62F9DA.5010208@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/13/11 5:47 AM, Tolga Dalman wrote: > > Being on this topic, I have some suggestions for the crossfire-client. > I think it is already pretty good, however for a normal user like > me it is quite difficult to create a character in a sane way. > So I suggest: > 1. add descriptions for stats (e.g. tooltips). I tested this under Ubuntu Lucid with the standard Gnome desktop, and tool tip summaries appeared for all the stats (Str, Dex, Con, et al.) I have not tested this under any other OS/Distro and desktop environment. Perhaps other list subscribers can and report their findings? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFNYvnahHyvgBp+vH4RAu1aAKDLjQTQ0nuARkagpz22QSxI3IkyhQCfaUHc 2RnpU51XbJhqyAESMuUiqvc= =y1rN -----END PGP SIGNATURE----- From mwedel at sonic.net Tue Feb 22 00:55:01 2011 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 21 Feb 2011 22:55:01 -0800 Subject: [crossfire] Player creation bug In-Reply-To: <4D57C4DC.2040401@project-psi.org> References: <4D57C4DC.2040401@project-psi.org> Message-ID: <4D635DC5.60701@sonic.net> On 02/13/11 03:47 AM, Tolga Dalman wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > currently, the player creation in crossfire 1.60 is broken. > You can reproduce it by doing the following with the > crossfire-client 1.60: > - - create new character: fire hatchling/monk > - - maximize str, dex and con > - - set remaining stats so that they are 1 in total > - - distribute the remaining points to pow > > This will fail, because the stats are checked after applying the > race (but not the class). The attached patch fixes this issue. I'm not quite sure if I understand the problem or not. I tried to do that, and got a message saying stat to low. That is correct behavior IMO. The old rolled method would allow for class combos where the minimum stats were not meant - that is no longer allowed, and that was an intentional change - since the player can distribute points, they can more easily make sure they meet the minimum values. I also think this is needed for balance - if a class has a big stat penalty, you need to spend some points to offset that penalty. If one does not need to spend any points to offset penalties, then the penalties become a lot less meaningful (don't put any points, and the fact there is a -8 penalty doesn't mean anything) > > Being on this topic, I have some suggestions for the crossfire-client. > I think it is already pretty good, however for a normal user like > me it is quite difficult to create a character in a sane way. > So I suggest: > 1. add descriptions for stats (e.g. tooltips). Already there - at least they work for me. > 2. make the stat number field read-only (this feature is actually not useful, > but rather confusing and error-prone). Entering stat numbers by hand works (I presume you mean the base attribute value). Maybe it was just my testing, but I often would just enter the numbers directly vs using the spin wheels. > 3. when selecting a race or class automatically update the stats to the required > minimum values. Also, these values should become constraints, i.e. pushing > the '-' should not yield in stats lower 1. > 4. disallow negative unspent stat points. This should be a simple check in the > '+' buttons. #3 is perhaps reasonable - I'll defer that to the community. My initial thought was that if one wanted to look through the different races and classes, one might want to be able to see those different choices without it messing with the values one set. For example, one might be making up a barbarian, and current has human. Given this is a barbarian, str, dex, con are maxed, remaining points in cha, and int,wis,pow are minimum. I might then decide I want to see what things would look like if I did a troll instead. If select troll increases the base stat values, it means I just can not go back and select human (after deciding I don't like troll) and get those same values back. And conversely, on point #4, that compounds the issue. Eg, I select troll, it updates the stats to minimum values - now I have negative stat points. So now it goes and decreases the high stats to make things legal. If I go back to human, then those stat values are really nothing close to what I had put in before. I'm not 100% sure what is the best way here - each one has its pros and cons. My initial implementation of that was to make it very easy to experiment with different combos, which means it does allow illegal values when playing around. > 5. "Choose starting map" should be replaced by the actual drop-down menu with > "Scorn" as default value. I had issues fitting the description in. I had also thought that maybe at some point, that even gets extended with an image of some sort representing the map choice. From mwedel at sonic.net Tue Feb 22 01:13:21 2011 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 21 Feb 2011 23:13:21 -0800 Subject: [crossfire] Skill thoughts In-Reply-To: <201102212214.31961.nicolas.weeger@laposte.net> References: <4D43B2F1.1070100@sonic.net> <201102212214.31961.nicolas.weeger@laposte.net> Message-ID: <4D636211.5000002@sonic.net> On 02/21/11 01:14 PM, Nicolas Weeger wrote: >> I finally got around to recording my thoughts on a revised skill system: > > > What is the planned implementation timeline? I'm always bad at estimating how long things will take. What I really want to do next is write up brief descriptions of the skills, possible special abilities, etc, they give, and probably combine some skills while I'm at it. For example, I'm think that detect magic and detect curse, as too different skills, would really never be worth spending points on (above getting it initially), but if those are combined as perhaps a general identification skill, it might be. But in that model, it would be not as good as the specific item ones. For example, with smithery, you might identify weapons/armor of level less than your skill. With general identification, it might be items less than 1/3 or 1/2 your skill. Likewise, combining singing and oratory would make sense to me - it is easier to calm monsters than make them friendly, so same skill could have different effects. > > > I'm wondering whether it's worth fixing (or at least trying to fix) existing > monsters with the current system, or just waiting for the new one. It probably depends what is wrong with them. While ideally monsters will follow the same rules for players (and thus have same skill with special abilities, etc), I don't necessarily know if that would be something I'd do in the first pass - I'd much rather get the new skill system really sorted out for players and then tackle adapting monsters to use it. I'll note that many games don't actually make any attempt for the monsters to follow all the same rules for players. But once the player stuff seems fairly well balanced, then apply/converting monsters to use that would start (I'm not 100% sure if it would make sense for all monsters to use that system, but that could get sorted out at that time) So things like hit points, damage, resistances would all be things that would still get used under the new skill system. Level would still get used as a starting point for any conversion. But in any case, I do want to write up some more details - its much easier to spend an evening or 2 writing up some ideas and getting a better idea if they work than to code them up. > > > Note that of course I'm ready to help implementing that, and others may be > too. Thanks for the offer - the problem I keep facing is feature creep - if skills are going to get redone, and attributes redone, should resistances be tackled at the same time? What about spells? At some point, it ends up being a big task, but maybe that is also needed to really get balance/playability back - a lot of things currently in the game were added one by one (new skill here, new spell there, new artifact over here) without any real central idea of how everything should work together. From tolga.dalman at googlemail.com Tue Feb 22 03:10:59 2011 From: tolga.dalman at googlemail.com (Tolga Dalman) Date: Tue, 22 Feb 2011 10:10:59 +0100 Subject: [crossfire] Player creation bug In-Reply-To: <4D635DC5.60701@sonic.net> References: <4D57C4DC.2040401@project-psi.org> <4D635DC5.60701@sonic.net> Message-ID: <4D637DA3.8020505@googlemail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (resending to the list) On 22.02.2011 07:55, Mark Wedel wrote: > > On 02/13/11 03:47 AM, Tolga Dalman wrote: >> >> - - create new character: fire hatchling/monk >> >> - - maximize str, dex and con >> >> - - set remaining stats so that they are 1 in total >> >> - - distribute the remaining points to pow >> >> >> >> This will fail, because the stats are checked after applying the >> >> race (but not the class). The attached patch fixes this issue. > > > > I'm not quite sure if I understand the problem or not. > > > > I tried to do that, and got a message saying stat to low. That is > > correct behavior IMO. Why is that correct ? Having total stats with at least 1 point should not yield an error! The attached patch removes the first (and thus redundant) stat check. > > I also think this is needed for balance - if a class has a big stat > > penalty, you need to spend some points to offset that penalty. If one > > does not need to spend any points to offset penalties, then the > > penalties become a lot less meaningful (don't put any points, and the > > fact there is a -8 penalty doesn't mean anything) Agreed. However, this could be automated. >> >> Being on this topic, I have some suggestions for the crossfire-client. >> >> I think it is already pretty good, however for a normal user like >> >> me it is quite difficult to create a character in a sane way. >> >> So I suggest: >> >> 1. add descriptions for stats (e.g. tooltips). > > > > Already there - at least they work for me. Strange. Then this is considered a bug in the client :) >> >> 4. disallow negative unspent stat points. This should be a simple >> >> check in the >> >> '+' buttons. > > > > And conversely, on point #4, that compounds the issue. Eg, I select > > troll, it updates the stats to minimum values - now I have negative stat > > points. So now it goes and decreases the high stats to make things > > legal. If I go back to human, then those stat values are really nothing > > close to what I had put in before. > > > > I'm not 100% sure what is the best way here - each one has its pros and > > cons. My initial implementation of that was to make it very easy to > > experiment with different combos, which means it does allow illegal > > values when playing around. While it is great for a developer not to have automatic attribute adjustments, for a user it does not make any sense. >> >> 5. "Choose starting map" should be replaced by the actual drop-down >> >> menu with >> >> "Scorn" as default value. > > > > I had issues fitting the description in. I had also thought that maybe > > at some point, that even gets extended with an image of some sort > > representing the map choice. I understand. Why not add another button for detail information on the particular choice ? Thanke & best regards Tolga Dalman -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNY32jAAoJEI0vwg8AaIlUnLQH/RjGibZhwgCALAxhFufa4q3x N7z719Hr05Z6lCCWIS74mfETEMjFV3ml0Xe4hHwU9n+87SibRB3vVG/IgzPGBsEz vMn0FxETCmrZKCMvvvAC0tWg9f+x7z+WwuXb6AM8VCjIvSqKUe4CIGErzIRA4a1M lnxMH2mbEIdyXO4nWH35BfwG8/TgGpdMRjTRUzwYnTouR2hNtH3k5SXOnzRVdeHX tqBXbz5KEMKKZ3OP+ESs0WfLbjLDu9PG2IA0jMjr084GcR0KRQhfp/Zl45EosF6l 8LZcM9lf3kQENO41v+/7rhpch0KHndhkbYfsE++baroD/+/w6L5/xC0OAoMSJO4= =CqkP -----END PGP SIGNATURE----- From mwedel at sonic.net Wed Feb 23 00:38:05 2011 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 22 Feb 2011 22:38:05 -0800 Subject: [crossfire] Player creation bug In-Reply-To: <4D637DA3.8020505@googlemail.com> References: <4D57C4DC.2040401@project-psi.org> <4D635DC5.60701@sonic.net> <4D637DA3.8020505@googlemail.com> Message-ID: <4D64AB4D.2000104@sonic.net> On 02/22/11 01:10 AM, Tolga Dalman wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > (resending to the list) > > On 22.02.2011 07:55, Mark Wedel wrote: >>> On 02/13/11 03:47 AM, Tolga Dalman wrote: >>>>> - - create new character: fire hatchling/monk >>>>> - - maximize str, dex and con >>>>> - - set remaining stats so that they are 1 in total >>>>> - - distribute the remaining points to pow >>>>> >>>>> This will fail, because the stats are checked after applying the >>>>> race (but not the class). The attached patch fixes this issue. >>> >>> I'm not quite sure if I understand the problem or not. >>> >>> I tried to do that, and got a message saying stat to low. That is >>> correct behavior IMO. > > Why is that correct ? Having total stats with at least 1 point should > not yield an error! The attached patch removes the first (and thus > redundant) stat check. Ok - I understand the problem better now - I thought you were keeping the stat values (the values the player sets) to minimum, but you are talking final result. So the way it currently works is broken - you are correct in that as long as the end result is valid, it should let you create the character. However, looking at this more, it appears that the checking of stat bounds for the class is completely broken right now. The plus side is that most class bonuses/penalties are minor, so a character does not get away with much. But with the change you have, since the check is only done after applying the class, it completely breaks it for the race also. I think the fix for that later problem is that allowed_class() should check op->contr->orig_stats values - fix_object() will never put a stat value (below min) in op->stats, and fix_object() is called as part of giving initial items. But I need to look at the more - allowed_class() is also used by legacy character creation, and I'm not sure if changing that would have some other unintended consequence. > >>>>> 4. disallow negative unspent stat points. This should be a simple >>>>> check in the >>>>> '+' buttons. >>> >>> And conversely, on point #4, that compounds the issue. Eg, I select >>> troll, it updates the stats to minimum values - now I have negative stat >>> points. So now it goes and decreases the high stats to make things >>> legal. If I go back to human, then those stat values are really nothing >>> close to what I had put in before. >>> >>> I'm not 100% sure what is the best way here - each one has its pros and >>> cons. My initial implementation of that was to make it very easy to >>> experiment with different combos, which means it does allow illegal >>> values when playing around. > While it is great for a developer not to have automatic attribute > adjustments, for a user it does not make any sense. But even new users, they might want to play around with different races and classes. But as said, I'm not of any strong opinion on that - maybe a compromise might be a button like 'fix attributes' which does put them in valid range. > > >>>>> 5. "Choose starting map" should be replaced by the actual drop-down >>>>> menu with >>>>> "Scorn" as default value. >>> >>> I had issues fitting the description in. I had also thought that maybe >>> at some point, that even gets extended with an image of some sort >>> representing the map choice. > I understand. Why not add another button for detail information on the > particular choice ? I'm not sure how many people would actually read it. But I also do expect that as time passes, there will be more than 1 window for character creation - if/when the new skill system is done, will likely need to have some way to let characters set up their skills, etc. From mwedel at sonic.net Sat Feb 26 01:54:00 2011 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 25 Feb 2011 23:54:00 -0800 Subject: [crossfire] Skill thoughts In-Reply-To: <4D636211.5000002@sonic.net> References: <4D43B2F1.1070100@sonic.net> <201102212214.31961.nicolas.weeger@laposte.net> <4D636211.5000002@sonic.net> Message-ID: <4D68B198.3080105@sonic.net> I've updated: http://wiki.metalforge.net/doku.php/user:mwedel:skills I've added a more detailed skill section, going through the skills and combining some and adding notes about the others. I've also added a section on resistances - I'm not sure how I feel about that - it add more work, but the counter is it reduces the number of attacktypes/resistances from 26 to 11, which in theory means it should be easier to balance these (fewer variables).