From kbulgrien at worldnet.att.net Fri Aug 3 00:12:48 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Fri, 3 Aug 2007 00:12:48 -0500 Subject: [crossfire] GTK2-v2 Client new layout defined (gtk-v1) In-Reply-To: <200707261810.34130.kbulgrien@worldnet.att.net> References: <200707261810.34130.kbulgrien@worldnet.att.net> Message-ID: <200708030012.48234.kbulgrien@worldnet.att.net> After suffering a SATA controller on motherboard death, I finally got back to looking at the gtk-v2 client again. Here's a layout that is pretty close to the gtk-v1 client. The screenshot was taken on a 1280x1024 screen. The main difference from the GTK1 client is the font size... so it is not really the same. The map shown is 19x19. It fits pretty well. http://krayvin.home.att.net/gtk2_gtk-v1_layout.png Kevin R. Bulgrien From mwedel at sonic.net Fri Aug 3 00:41:18 2007 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 02 Aug 2007 22:41:18 -0700 Subject: [crossfire] Redo wc/ac/armor (+dodge) Message-ID: <46B2BFFE.8030400@sonic.net> Some discussions recently have discussed that we should think fresh about different ideas/balancing the game. And the current wc/ac/armor got me thinking about this. Right now, AC and wc basically follow the original AD&D model - low AC is good, armor gives an AC bonus, and low wc is also good. But perhaps from the start, crossfire also had the armor (resist_physical) field which denotes armor/damage absorption (but in a percentage term). In pretty much all games that have some armor absorption rule, your equipment typically gives you absorption, but makes you _easier_ to hit - less likely to dance around wearing plate armor. So thinking about that, and thinking about how AD&Dv3 actually made things a bit simpler by characters always wanting higher values (ac goes up, not down, as it gets better), these are my thoughts: rename ac to dodge, and make it start at ten. Remove this bonus from pretty much all armor currently in the game, and/or perhaps add penalty for most of the armors. I mulled over the idea of making dodge a skill, but handling exp on that is tricky - instead, I think base dodge should be based on dexterity, certianly races/classes may get a dodge bonus, and certain skills may give increasing dodge bonus for higher levels (like karate - high level person in karate should have an excellent dodge) make wc start at zero and go up - thus, always clear that higher wc is better. Also explain to explain things like d20 + wc > opponent dodge means you hit armor (resist_physical) remains as same - if you are hit/hit something else, this works as now, reducing the amount of damage. The one change I would make is that enchanting armor would increase the resist_physical value, and not the armor. Right now, boots +1 give you 1 ac point and perhaps 3 resist physical - under the revised system, those boots would still not give you an AC, but 4 resist physical instead. I think this has some nice effects - it adds some additional tuning/balance factors to armor - that best armor may not be say if it has a big dodge penalty. And it sort of opens up two playing strategy - the character that tries to avoid being hit, but when hit, takes a bit of damage, and the character that will get hit a lot, but not take much damage when it does happen. And it also makes some skills more interesting - characters/classes that can't wear armor may not be so bad to play if they have the karate skill to get a high dodge. The tricky part on this is balancing it out - since the to hit rolls is d20 based, it doesn't take too much a difference for something to be deadly or not deadly enough. For example, suppose a monster is supposed to hit on a 15+ (25% of the time). If you are off +5, such that it needs a 20, it now only hits 5% of the time. And if you are off -5, it now needs a 10, and hits 50% of the time (meaning twice as many hits as expected). These are bit differences - much bigger than a character having ?10% expected resist_physical values. Now one thought I have here might be to sort of say what are reasonable/expected values of those different attributes, eg: level wc dodge resist value 1 1 10 20 10 5 15 30 20 13 22 45 ... 100 90 106 95 (numbers made up) - the point is they may not really be linear - at certain points, characters may get different items that give them certain boosts, etc. I think the values derived from skills should be fairly linear. The point of such a table is that it gives some idea of what values should be in a given monster - according to that table, a typical level 20 character as a 22 dodge. So if you want that monster to hit 25% of the time, you give it a wc of 17. And you know how much damage will be absorbed, so can tune its damage to some extent. such things also help in determine balance of items. An item that a level 20 character can get that gives them a resist value of 50 is probably too powerful from that table (because when stacked with other items they have, that means their resist value would be something like 60-70, well above the curve). In any case, just some random thoughts. From yann.chachkoff at myrealbox.com Fri Aug 3 07:41:07 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Fri, 3 Aug 2007 14:41:07 +0200 Subject: [crossfire] GTK2-v2 Client new layout defined (gtk-v1) In-Reply-To: <200708030012.48234.kbulgrien@worldnet.att.net> References: <200707261810.34130.kbulgrien@worldnet.att.net> <200708030012.48234.kbulgrien@worldnet.att.net> Message-ID: <200708031441.13923.yann.chachkoff@myrealbox.com> Le vendredi 3 ao?t 2007, Kevin R. Bulgrien a ?crit : > > Here's a layout that is pretty close to the gtk-v1 client. > > http://krayvin.home.att.net/gtk2_gtk-v1_layout.png > Am I the only one finding this interface rather scary and cluttered by tons of stuff ? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070803/a0796fd6/attachment.pgp From nicolas.weeger at laposte.net Fri Aug 3 11:37:58 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 3 Aug 2007 18:37:58 +0200 Subject: [crossfire] GTK2-v2 Client new layout defined (gtk-v1) In-Reply-To: <200708031441.13923.yann.chachkoff@myrealbox.com> References: <200707261810.34130.kbulgrien@worldnet.att.net> <200708030012.48234.kbulgrien@worldnet.att.net> <200708031441.13923.yann.chachkoff@myrealbox.com> Message-ID: <200708031838.01474.nicolas.weeger@laposte.net> > > http://krayvin.home.att.net/gtk2_gtk-v1_layout.png > > Am I the only one finding this interface rather scary and cluttered by tons > of stuff ? Nope :) IMO both the GTK clients are too geeky... jxclient seems much better, from my point of view. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070803/ee148ac2/attachment.pgp From crossfire at kahnert.de Fri Aug 3 14:42:47 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Fri, 3 Aug 2007 21:42:47 +0200 Subject: [crossfire] Redo wc/ac/armor (+dodge) In-Reply-To: <46B2BFFE.8030400@sonic.net> Message-ID: <20070803194247.GA5279@cthulhu.desy.de> On Thu, Aug 02, 2007 at 10:41:18PM -0700, Mark Wedel wrote: > rename ac to dodge, and make it start at ten. If working with d20 this sound reasonable. > Remove this bonus from pretty much all armor currently in the game, > and/or perhaps add penalty for most of the armors. Keep ac of armour. But this value will reduce dodge. So a plate mail with ac 5 will reduce the dodge value by 5. We still need to check all the armour to verify the ac value. > I mulled over the idea of making dodge a skill, but handling exp on > that is tricky Let us discuss a little bit more about a dodge skill. It would have some advantages having dodge as a skill. This way you're able to keep up with wc and also mages will be able to dodge without the need to train physical combat... > I think base dodge should be based on dexterity, But wc will increase with a skill which may reach level 100, dexterity will stay around 30. You won't be able to dodge anything on higher levels. > certianly races/classes may get a dodge bonus, This will make it easier on lower levels. But at high level the problem will still exists. > and certain skills may give increasing dodge bonus for higher levels > (like karate - high level person in karate should have an excellent > dodge) That forces mages to learn physical combat to avoid being killed on higher levels. > The one change I would make is that enchanting armor would increase > the resist_physical value, and not the armor. Right now, boots +1 > give you 1 ac point and perhaps 3 resist physical - under the revised > system, those boots would still not give you an AC, but 4 resist > physical instead. Sounds reasonable. But than we need to increase the enchanting level. A maximum armour enchanting up to +4 won't have such a big impact than ac +4. One ac point is worth a 5% chance (due to the d20). And will it take effect on all resistances or just physical? > The tricky part on this is balancing it out - since the to hit rolls > is d20 based, it doesn't take too much a difference for something to > be deadly or not deadly enough. Do we want to stay with the d20 based system? It allows us just 5% steps. We don't need to implement pen & paper systems. We should develop something more suitable; d20 is good for pen & paper based systems, but we don't need to care about an easy dice system. The computer will do the calculation part. > Now one thought I have here might be to sort of say what are > reasonable/expected values of those different attributes, eg: > > level wc dodge resist value > 1 1 10 20 > 10 5 15 30 > 20 13 22 45 > ... > 100 90 106 95 Such a table is neat and will help making better maps. > the point is they may not really be linear - at certain points, > characters may get different items that give them certain boosts, etc. That heavily depends on map making. A linear progress is favoured. J??rgen From juhaj at iki.fi Fri Aug 3 15:51:13 2007 From: juhaj at iki.fi (Juha =?UTF-8?B?SsOkeWtrw6Q=?=) Date: Fri, 03 Aug 2007 23:51:13 +0300 Subject: [crossfire] Redo wc/ac/armor (+dodge) In-Reply-To: <20070803194247.GA5279@cthulhu.desy.de> References: <46B2BFFE.8030400@sonic.net> <20070803194247.GA5279@cthulhu.desy.de> Message-ID: <20070803235113.69a774b6@alnitak.stiff.utu.fi> > > Remove this bonus from pretty much all armor currently in the game, > > and/or perhaps add penalty for most of the armors. > Keep ac of armour. But this value will reduce dodge. So a plate mail > with ac 5 will reduce the dodge value by 5. So we'd have AC, armour (resist_physical) and dodge? Three things? Not good, imo. > Let us discuss a little bit more about a dodge skill. It would have > some advantages having dodge as a skill. This way you're able to keep > up with wc and also mages will be able to dodge without the need to > train physical combat... Agreed. Some incarnation of D&D has a skill "tumbling" which in essence is the same as "dodge" here. It can be improved by the skill point system. Perhaps we need that 10% XP pool, after all, but make it allocatable ONLY to those skills which cannot advance in any other way, perhaps? Or even make the 10% player-selectable? Or simply let dodge gain XP from missing attacks? Like 1 XP per missed damage? This needs a major change in the server: currently (I think) the player will not even know whether the monster has tried to hit and missed or not tried at all. And I think damage is computed only after hit is scored, that would need to change as well. One more thing: would dodge help evade things like magic missile? I think not, since they are spells and supposedly "guided" (missile). It might be ok to help evade comets, asteroids and other non-guided stuff (firebolt comes to mind), though (not lightnings, they are supposed to be too fast). > But wc will increase with a skill which may reach level 100, dexterity > will stay around 30. > You won't be able to dodge anything on higher levels. True, unless we ramp up the maximum stats to 100 - not likely (I'd up them to at least 40-50 range, because fireborns, for example, can easily get Pow > 30 with very little equipment - their maximum Pow with all equip should be more than that of other races.). Dodge needs to rise with levels. > > certianly races/classes may get a dodge bonus, > This will make it easier on lower levels. But at high level the problem > will still exists. This is the old problem with racial/class bonuses all again! We should decide here and now that all racial/class bonuses need to either a) not exist or b) improve with level, as fireborn ac and dragon resist_physical do at the moment. (This does no apply to such things as fireborns' resist_fire +100 or undeads' disease immunity or even fireborns' extra "fingers" - just numerical bonuses (except those that are already maximal).) > That forces mages to learn physical combat to avoid being killed on > higher levels. Or avoid melee and missiles - like in many pen&paper rpgs. Though it is sometimes pretty difficult in CF. > Sounds reasonable. But than we need to increase the enchanting level. > A maximum armour enchanting up to +4 won't have such a big impact than > ac +4. One ac point is worth a 5% chance (due to the d20). True. > And will it take effect on all resistances or just physical? Why would it? Just AC is being altered and it never affected any other resistances anyway. BUT I'd alter the alchemy/jewellery/etc as per one of my earlier posts and that would enable you to alter the other resistances of items as well. Perhaps it might also be nice to limit the total sum of bonuses an item can give by something else than jeweller/etc level as well: iron rings might be able to give less bonuses than mithril rings? > Do we want to stay with the d20 based system? It allows us just 5% > steps. We don't need to implement pen & paper systems. I can only see one problem with 5% steps: it means 5% of the attacks hit no matter what. This might be considered unrealisticly high. But since beings with AC 100 are pretty tough anyway, they'd probably have so good resist_physical as well that those who should not realistically be able to hit them will not do any damage even when they hit. -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070803/c38a5b0f/attachment.pgp From mwedel at sonic.net Fri Aug 3 20:47:40 2007 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 03 Aug 2007 18:47:40 -0700 Subject: [crossfire] Redo wc/ac/armor (+dodge) In-Reply-To: <20070803235113.69a774b6@alnitak.stiff.utu.fi> References: <46B2BFFE.8030400@sonic.net> <20070803194247.GA5279@cthulhu.desy.de> <20070803235113.69a774b6@alnitak.stiff.utu.fi> Message-ID: <46B3DABC.4030108@sonic.net> Quick followups: AC: if this change is adopted, one really can't just say 'make what is currently AC a dodge penalty' - that will result in lots of broken items (certain items that currently give high AC and shouldn't give that as dodge penalty). Plus, it becomes confusing - if I've learned one thing, having these legacy values is a bad idea. Instead, a dodge (or dodge_adj) field should be added. It may be that AC is a good starting point for that, and anything that has AC set is converted into -dodge_adjustment. Another reason a new field is good is that it then makes it very easy to see if the item has been updated - if you see that the item has a dodge_adj set, you know it is up to date/current. If you don't change the field name, impossible to know if you have some legacy object that needs to be updated, or if it has been rebalanced. Dodge skill: I thought about the idea of dodge skill getting exp each time you dodge. Several problems - exp has to go up as character advances, otherwise dodge skill effectively maxes out at pretty low level. I think such a simple is open to easily exploited abuses - I park myself by a monster I know can't damage me (say high regen + high resistance to its attack type). I let it sit overnight, and next morning, I've got bunch of dodge exp. Now with the experience pool idea, dodge may be a bit more usable, but I'm still not sure if one would be able to funnel enough exp into it to be useful - if the creatures WC is 50, having a dodge of 30 vs 20 makes no difference - the creature is going to hit you all the time. For spellcasters, may be reasonable to have various spells (of different power) that give dodge bonuses. So you have a 40th level spell that gives you a 30 dodge bonus - good enough to avoid being damaged most of the time. An advantage of this is that this is also quite easy to tune - if a character is a pure spell caster, his spellcasting skill is effectively his overall level in some sense, so what level spell he casts really determines what creatures he can kill, and thus, what level of protection he can get from those spells is of direct relevance. Enchanting armor: Exactly how much improvement each scroll gives is an implementation detail. However, one has to be careful - if one is able to enchant all pieces of armor to resist_armor 50, that character will have an overall resist_armor 99. So you need some mechanism to say something like 'max enchantment on boots is 10, max on gloves is 5, max on armor (suits) is 60', just to keep things in balance. I would say enchant armor would only improve resist_physical. That said, adding other spells to increase other resistances is I think reasonable (enchant armor - protection from fire, etc). But still in this case, the max total enchantments of all the different types of attacks can not exceed the max enchantment values. And those max enchantment values are really only for player controlled enchantments. Artifact/special armor may go above that, but those max values should be used as baselines. d20 vs dother: That could be changed - has to be thought on how to do it. Percentage system would be fairly consistent with rest of game (percentages for resist values, etc). A problem however is steps of increase - if you increase say dodge and wc 1% per level, then actual level doesn't make a huge different - wc + d100 > dodge + 50 makes the dodge and wc skills not especially important - that d100 is what will primarily make a difference - in that above example, suppose creature has dodge 30, so wc + d100 > 80 to hit. If character has wc of 0, hits 20% of time. Wc if 20 means 40% of time - twice as much. This system may be reasonable, but really does de-emphasize wc and dodge. Other issue is that currently a weapons bonus (sword +1) affects wc. If switched to a percentage system, that +1 sword means diddly squat. One could change it so that each plus of a weapon is 5%, but now you're looking more like a d20 system again, just everything multiplied by 5. Dodge for spells: It should perhaps for certain spells. One could follow that AD&Dv3 systems of 3 saving throughs - reflex, fortitude, and willpower, and dodge will really equate to reflex - sort of goes beyond original start of this discussiong, but discussing saving throws perhaps makes sense. From kbulgrien at worldnet.att.net Sat Aug 4 01:25:18 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 4 Aug 2007 01:25:18 -0500 Subject: [crossfire] GTK2-v2 Client new layout defined (gtk-v1) In-Reply-To: <200708031838.01474.nicolas.weeger@laposte.net> References: <200707261810.34130.kbulgrien@worldnet.att.net> <200708031441.13923.yann.chachkoff@myrealbox.com> <200708031838.01474.nicolas.weeger@laposte.net> Message-ID: <200708040125.18622.kbulgrien@worldnet.att.net> > > > http://krayvin.home.att.net/gtk2_gtk-v1_layout.png > > > > Am I the only one finding this interface rather scary and cluttered by tons > > of stuff ? > > Nope :) > > IMO both the GTK clients are too geeky... jxclient seems much better, from my > point of view. > > Nicolas Yeah... whatever... at least GTK clients are easily built. I'd try this so-called super awesome, non-geekified jxclient if I had a clue where to get a jar or how to build it, but maybe it is too good for the playing masses and we couldn't handle it? And for crying out loud, it doesn't even get honorable mention on the Crossfire web site. I pulled down ant (87 MB with deps), and still didn't have a clue where to go from there. For now, I'll stick with using a geeky client rather than none at all. What's with java projects anyway? Gridarta doesn't release jars, I don't see one for jxclient. You have to get them off-project. I guess if you're not in, you're out. From nicolas.weeger at laposte.net Sat Aug 4 01:47:16 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 4 Aug 2007 08:47:16 +0200 Subject: [crossfire] GTK2-v2 Client new layout defined (gtk-v1) In-Reply-To: <200708040125.18622.kbulgrien@worldnet.att.net> References: <200707261810.34130.kbulgrien@worldnet.att.net> <200708031838.01474.nicolas.weeger@laposte.net> <200708040125.18622.kbulgrien@worldnet.att.net> Message-ID: <200708040847.19817.nicolas.weeger@laposte.net> > Yeah... whatever... at least GTK clients are easily built. I'd try this > so-called super awesome, non-geekified jxclient if I had a clue where to > get a jar or how to build it, but maybe it is too good for the playing > masses and we couldn't handle it? And for crying out loud, it doesn't even > get honorable mention on the Crossfire web site. jxclient was (is probably still) considered experimental (no map2 support, I think) since not so long ago (a few days/weeks), so yes it isn't mentioned. But even in its current state I much prefer the interface :) (your mileage may vary, of course) And I suggest you do a small experiment: find a Windows computer, and try to build the GTK1 client there :) You'll see it isn't that easy ^_- (and I'm not even sure it does work on Macs...) > I pulled down ant (87 MB with deps), and still didn't have a clue where to > go from there. For now, I'll stick with using a geeky client rather than > none at all. cd to jxclient directory, then 'ant' to build it. Then 'java -jar jxclient.jar' to run it (full screen mode by default, add -N to make it windowed). > What's with java projects anyway? Gridarta doesn't release jars, I don't > see one for jxclient. You have to get them off-project. I guess if you're > not in, you're out. See first point, experimental. But I do hope it'll soon be in good shape, thanks to Ragnor's work, and usable :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070804/032f360f/attachment-0001.pgp From kirschbaum at myrealbox.com Sat Aug 4 02:44:00 2007 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sat, 4 Aug 2007 09:44:00 +0200 Subject: [crossfire] GTK2-v2 Client new layout defined (gtk-v1) In-Reply-To: <200708040125.18622.kbulgrien@worldnet.att.net> References: <200707261810.34130.kbulgrien@worldnet.att.net> <200708031441.13923.yann.chachkoff@myrealbox.com> <200708031838.01474.nicolas.weeger@laposte.net> <200708040125.18622.kbulgrien@worldnet.att.net> Message-ID: <20070804074400.GA21861@kirschbaum.myrealbox.com> Kevin R. Bulgrien wrote: > Yeah... whatever... at least GTK clients are easily built. I'd try > this so-called super awesome, non-geekified jxclient if I had a clue > where to get a jar or how to build it, but maybe it is too good for > the playing masses and we couldn't handle it? And for crying out loud, > it doesn't even get honorable mention on the Crossfire web site. There is a simple reason it is not advertised on the web site: the client is still in development. You are able to connect to a server and actually play the game, but some gui elements do not yet work (click on an element and nothing happens), and error handling is almost absent (failure to connect to server, or have the connection break ==> client just exits). Also, it still runs quite slowly on machines without hardware accelerated graphics operations -- in fact, currently you basically cannot play on such machines... That said, I do not yet consider jxclient to be in a state to be released as a pre-compiled client intended to be run by "normal" players. Therefore I currently do neither advertise it nor provide pre-compiled binaries. > I pulled down ant (87 MB with deps), and still didn't have a clue > where to go from there. Thanks for pointing out this issue. I've now added a few lines to the README file about how to compile the client. Basically: run "ant" in the jxclient directory. This creates the file jxclient.jar. Run this file as "java -jar jxclient.jar". > For now, I'll stick with using a geeky client rather than none at all. Better yet: figure out how to make it work, then fix the documentation;) Or at least file a bug report so somebody else can fix it. Just declining and not telling anything does not enable us to fix issues... > What's with java projects anyway? Gridarta doesn't release jars, I > don't see one for jxclient. You have to get them off-project. I guess > if you're not in, you're out. For Gridarta it is for the same reason: the project has started from the sources of both the Crossfire and the Daimonin Java map editors. They did share a common code base but have been developed separately for quite a while. Gridarta's goal was to merge both code bases to bundle the development resources of both projects, effectively helping both projects. We decided not to officially release binaries for Gridarta because we thought the editors might be (very) unstable during the merging process. Until today, the merging is still in progress (see http://gridarta.sourceforge.net/dev/mergeStats). To the off-site download place: It was introduced because some people couldn't compile the editor. (In fact, I did compile Gridarta for eracc. He then figured that it could be helpful for other to get at the pre-compiled editor as well, so he hade it available on his site.) As far as I know, currently all people who are (semi-)actively using the editor can compile it from the sources. Now, creating a new release takes me at least 30 minutes. Therefore I prefer spending this time into code improvements. That means I update the pre-compiled binary only very infrequently (less than once per month, almost always only when somebody complains that it is way outdated...) That said, even though we do not yet provide pre-compiled binaries for jxclient or Gridarta, feedback is always highly welcome. Both feedback about what needs to be improved/changed/implemented to make the application actually useful, and feedback about bugs/crashes/etc. Even feedback that you just use it without problems is useful (since it might accelerate further development ;)). From kbulgrien at worldnet.att.net Sat Aug 4 02:47:46 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 4 Aug 2007 02:47:46 -0500 Subject: [crossfire] GTK2-v2 Client new layout defined (gtk-v1) In-Reply-To: <200708040847.19817.nicolas.weeger@laposte.net> References: <200707261810.34130.kbulgrien@worldnet.att.net> <200708040125.18622.kbulgrien@worldnet.att.net> <200708040847.19817.nicolas.weeger@laposte.net> Message-ID: <200708040247.46736.kbulgrien@worldnet.att.net> > And I suggest you do a small experiment: find a Windows computer, and try to > build the GTK1 client there :) You'll see it isn't that easy ^_- > (and I'm not even sure it does work on Macs...) What is windows? Is it something i can afford to care about? ;-/ > > I pulled down ant (87 MB with deps), and still didn't have a clue where to > > go from there. For now, I'll stick with using a geeky client rather than > > none at all. > > cd to jxclient directory, then 'ant' to build it. Then 'java -jar > jxclient.jar' to run it (full screen mode by default, add -N to make it > windowed). $ pwd /home/data/svn/crossfire/jxclient [krb at kraymd64 jxclient]$ ant Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher [krb at kraymd64 jxclient]$ cd trunk/com/realtime/crossfire/jxclient/ [krb at kraymd64 jxclient]$ ant Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher [krb at kraymd64 jxclient]$ cd ../../../../../trunk/src/test/com/realtime/crossfire/jxclient/ [krb at kraymd64 jxclient]$ ant Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher Not that easy... Tried that already. > > What's with java projects anyway? Gridarta doesn't release jars, I don't > > see one for jxclient. You have to get them off-project. I guess if you're > > not in, you're out. > > See first point, experimental. But I do hope it'll soon be in good shape, > thanks to Ragnor's work, and usable :) > > Nicolas From kbulgrien at worldnet.att.net Sat Aug 4 03:50:20 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 4 Aug 2007 03:50:20 -0500 Subject: [crossfire] GTK2-v1-wtabs In-Reply-To: <200708030012.48234.kbulgrien@worldnet.att.net> References: <200707261810.34130.kbulgrien@worldnet.att.net> <200708030012.48234.kbulgrien@worldnet.att.net> Message-ID: <200708040350.20908.kbulgrien@worldnet.att.net> http://krayvin.home.att.net/gtk2_gtk-v1_layout.png Obviously, not that anyone cares, but throwing this out just in case... Still fiddling, getting comfortable with glade. I didn't like the first gtk-v1-ish layout for the gtk2 client. So I tweaked on it a bit. Core stats is laid out better IMO, and now is on a tab sheet with the skills/experience data. http://krayvin.home.att.net/gtk2_gtk-v1-wtabs_layout.png As easy as it is to make new layouts, I'm tempted to look at libglade. Kevin R. Bulgrien From kbulgrien at worldnet.att.net Sat Aug 4 04:19:45 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 4 Aug 2007 04:19:45 -0500 Subject: [crossfire] GTK2-v2 Client new layout defined (gtk-v1) In-Reply-To: <20070804074400.GA21861@kirschbaum.myrealbox.com> References: <200707261810.34130.kbulgrien@worldnet.att.net> <200708040125.18622.kbulgrien@worldnet.att.net> <20070804074400.GA21861@kirschbaum.myrealbox.com> Message-ID: <200708040419.46245.kbulgrien@worldnet.att.net> > There is a simple reason it is not advertised on the web site: the > client is still in development. You are able to connect to a server and > actually play the game, but some gui elements do not yet work (click on > an element and nothing happens), and error handling is almost absent > (failure to connect to server, or have the connection break ==> client > just exits). Also, it still runs quite slowly on machines without > hardware accelerated graphics operations -- in fact, currently you > basically cannot play on such machines... Hmm... So then the mumbler was really just detracting from my feeble attempts to work on fixing what I felt like moaning about. Ok... I get it. > > I pulled down ant (87 MB with deps), and still didn't have a clue > > where to go from there. > > Thanks for pointing out this issue. I've now added a few lines to the > README file about how to compile the client. Basically: run "ant" in the > jxclient directory. This creates the file jxclient.jar. Run this file as > "java -jar jxclient.jar". Nope, that make huge assumptions. All I get is an exception when I do that. On the other client, it has ./configure that has a chance of showing me maybe I don't have all the requirements installed, which I suppose has something to do with ant croaking when I try to start it. > > For now, I'll stick with using a geeky client rather than none at all. > > Better yet: figure out how to make it work, then fix the documentation;) > Or at least file a bug report so somebody else can fix it. Just > declining and not telling anything does not enable us to fix issues... Why do you suppose I'm even trying it? And that is what I'm doing about the GTK2 client. If you read the top of the thread, I wasn't the groaner, and in fact am doing something about what I did groan about. > > What's with java projects anyway? Gridarta doesn't release jars, I > > don't see one for jxclient. You have to get them off-project. I guess > > if you're not in, you're out. > > For Gridarta it is for the same reason: the project has started from the > sources of both the Crossfire and the Daimonin Java map editors. They > did share a common code base but have been developed separately for > quite a while. Gridarta's goal was to merge both code bases to bundle > the development resources of both projects, effectively helping both > projects. > > We decided not to officially release binaries for Gridarta because we > thought the editors might be (very) unstable during the merging process. > Until today, the merging is still in progress (see > http://gridarta.sourceforge.net/dev/mergeStats). > > To the off-site download place: It was introduced because some people > couldn't compile the editor. (In fact, I did compile Gridarta for eracc. > He then figured that it could be helpful for other to get at the > pre-compiled editor as well, so he hade it available on his site.) > > As far as I know, currently all people who are (semi-)actively using the > editor can compile it from the sources. Now, creating a new release > takes me at least 30 minutes. Therefore I prefer spending this time into > code improvements. That means I update the pre-compiled binary only very > infrequently (less than once per month, almost always only when somebody > complains that it is way outdated...) Don't know what semi-actively is, but I sure have a lot of commits in svn... and don't know how to compile it. I can learn anything, but if I can't even get it compiled, and can compile something else... my time is better spent on the one that builds. $ pwd /home/data/svn/gridarta $ ant Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher Ok, so Googling on that turns up a suggestion to try: $ ant --execdebug exec "/usr/java/jdk1.5.0_08/bin/java" -classpath "/usr/bin/build-classpath: error: JVM_LIBDIR /usr/lib/jvm-exports/java-gcj does not exist or is not a directory" -Dant.home="/usr/share/ant" -Dant.library.dir="/usr/share/ant/lib" org.apache.tools.ant.launch.Launcher -cp "" Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher I'd add that to the README, BTW. I suppose I could dig around to see why said directory is not on my system. Maybe I picked the wrong options when I pulled down ant. > That said, even though we do not yet provide pre-compiled binaries for > jxclient or Gridarta, feedback is always highly welcome. Both feedback > about what needs to be improved/changed/implemented to make the > application actually useful, and feedback about bugs/crashes/etc. Even > feedback that you just use it without problems is useful (since it might > accelerate further development ;)). Been there done that. It is a very cool tool, and I've posted several things to sourceforge, except probably didn't say how nice it was to use compared to what I used to use to edit maps. From lalo.martins at gmail.com Sat Aug 4 07:09:17 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Sat, 4 Aug 2007 12:09:17 +0000 (UTC) Subject: [crossfire] Client proposal: redo inventory/look widgets Message-ID: On the quest to "ungeekify" the client... ;-) Based on recent discussions and a comment from Mwedel, I'd like to propose a revision of the inventory and "look" areas, and the introduction of three new things. (Of course I'm volunteering to write the code for this.) The question being: do people really *USE* all those 10 tabs? Very occasionally I use "unlocked" to sell stuff, but most of the time I use "icons" and the first one. And really, neither is the ideal UI for what I actually want to do. So here's the proposal: Currently we have an inventory notebook and a "look" table. I propose to replace them with two other widgets: what I call the "stuff notebook", and the "shortcut area". The "shortcut area" is really Mwedel's idea. It would be a 10x2 or 10x3 (or even 10x4) table, and you drag either equippable items or spells to that area. Each "slot" essentially manages one keybinding; so if I put my axe on 1,1 and small fireball in 2,1, then pressing "1" does "apply axe" (well not really, but you get the point), and "shift 1" does "cast small fireball". The rows correspond to no mod, shift, ctrl, and alt. Then the "stuff notebook"; I imagine it has a control (checkbox or toggle button) that chooses between "details" and "icons" mode, regardless of tab (I think the choice applies to all tabs). First tab is "look"; the objects on the floor near you. Second is the plain, unfiltered inventory. Yes, the filters are occasionally useful, but IMO, not often enough to justify polluting the UI. Fourth tab is the spell list; this is an awesome addition to the game, IMO it's about time it gets a more permanent space in the UI (and it's somewhat necessary in order for the shortcut area to be useful for mages). The third tab deserves its own paragraph :-) what I'm proposing here is a "body diagram" similar to what many computer adventure games have. Yes, it would require some tinkering, since we have IIRC 3 or 4 different combinations of body parts... but I have an idea how to do it and I'm willing to write the code. Here, you'd have a rough outline of a body, and for each "body slot" your character has, there would be a space where an icon can be drawn; if you equip an item on that slot, the corresponding icon appears there. Clicking a slot (with or without an equipped item) would bring up a menu with the items that can be equipped there. Since it's a notebook widget, it would be hard to drag items from the inventory to the body diagram; but then again, I have no idea why you'd want to do that, since you can double-click it on the inventory :-) I think hovering an icon on any of those widgets, if you are on "icon" view, would display the rest of the information (what you would have on "detail" view) on a tooltip. Thoughts? best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From yann.chachkoff at myrealbox.com Sat Aug 4 12:11:52 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sat, 4 Aug 2007 19:11:52 +0200 Subject: [crossfire] GTK2-v2 Client new layout defined (gtk-v1) In-Reply-To: <200708040419.46245.kbulgrien@worldnet.att.net> References: <200707261810.34130.kbulgrien@worldnet.att.net> <20070804074400.GA21861@kirschbaum.myrealbox.com> <200708040419.46245.kbulgrien@worldnet.att.net> Message-ID: <200708041911.57933.yann.chachkoff@myrealbox.com> Le samedi 4 ao?t 2007, Kevin R. Bulgrien a ?crit : > Hmm... So then the mumbler was really just detracting from my feeble > attempts to work on fixing what I felt like moaning about. Ok... I get it. > Just as a side note, my original comment was about underlining the (IMO) terrible layout of the GTK1 client, one that the GTK2 adaptation didn't make any better. Or, to speak using other terms: - no, it wasn't a free ad for jxclient; - yes, it meant that regardless of the toolkit used, I found the UI cluttered and unfriendly. Does that mean it shouldn't be fixed ? Of course not. It simply meant that IMHO mimicking the GTK1 client UI didn't fix anything. > Nope, that make huge assumptions. All I get is an exception when I do > that. On the other client, it has ./configure that has a chance of > showing me maybe I don't have all the requirements installed, which I > suppose has something to do with ant croaking when I try to start it. > If you had spent two minutes googling about it, you'd have found that this message was caused by a badly installed/configured ant, and not by a problem in jxfire's building process. Reference (amongst several others): http://ant.apache.org/faq.html#NoClassDefFoundError With a badly installed/configured C toolchain, you'd just get the same kind of failure with ./configure. Don't blame the SVN content for a problem in your own building chain. Just my two ?-cents. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070804/b995d234/attachment.pgp From huet.o at free.fr Sat Aug 4 14:06:25 2007 From: huet.o at free.fr (Olivier Huet) Date: Sat, 4 Aug 2007 21:06:25 +0200 Subject: [crossfire] jxclient (was RE: GTK2-v2 Client new layout defined (gtk-v1)) In-Reply-To: <200708040247.46736.kbulgrien@worldnet.att.net> References: <200707261810.34130.kbulgrien@worldnet.att.net> <200708040125.18622.kbulgrien@worldnet.att.net> <200708040847.19817.nicolas.weeger@laposte.net> <200708040247.46736.kbulgrien@worldnet.att.net> Message-ID: <001e01c7d6ca$8e576ae0$ab0640a0$@o@free.fr> Hello, I was quite curious to see if that jxclient would works, and you know what ? It does runs well on Windows :) (to be precise, on Windows Vista) See a screenshot with default resolution : http://huet.o.free.fr/cftest/testjxclient.png and I did modify a little parameters and skins and with 25 x 16 map : (I did only changed map size, so other stuffs do go in front of map) http://huet.o.free.fr/cftest/testjxclient_bigger.png well it's does not have all functionalities and did crash a little, but mainly when leaving the client, in java runtime (hey java is not very stable, I already did know that :-) ) and due to out of memory exception when I did not use any -Xmx flag to run java (it's strange, java don?t use all available memory by default, it's quite stupid...) - when I click on "menu", it doesn't do anything. - the opengl rendering was buggy for me : "old images" do appear when I move : when moving, I randomly see an image of 1 or 2 second before, and then, it come back to current image --> but when disabling OpenGL, it did works well. - In addition, to have it works properly in full screen and with a non 0 number displayed for "Accelerated memory available" (so probably with some hardware DirectX acceleration), I did use that command line (some flags are perhaps already on by default) : java -Xmx1024M -cp jxclient.jar -Dsun.java2d.opengl=false -Dsun.java2d.translaccel=true -Dsun.java2d.noddraw=false -Dsun.java2d.d3d=true -Dsun.java2d.ddscale=true com.realtime.crossfire.jxclient.jxclient -B 32 -W 1680 -H 1050 But except that, it works well and is, surprisingly, very fast. (well, at least on a very recent laptop, I did not try it on a slower computer) Best regards, Olivier Huet (findufin & findragon on metalforge) -----Message d'origine----- De?: crossfire-bounces at metalforge.org [mailto:crossfire-bounces at metalforge.org] De la part de Kevin R. Bulgrien Envoy??: samedi 4 ao?t 2007 09:48 ??: Crossfire Discussion Mailing List Objet?: Re: [crossfire] GTK2-v2 Client new layout defined (gtk-v1) > And I suggest you do a small experiment: find a Windows computer, and try to > build the GTK1 client there :) You'll see it isn't that easy ^_- > (and I'm not even sure it does work on Macs...) What is windows? Is it something i can afford to care about? ;-/ > > I pulled down ant (87 MB with deps), and still didn't have a clue where to > > go from there. For now, I'll stick with using a geeky client rather than > > none at all. > > cd to jxclient directory, then 'ant' to build it. Then 'java -jar > jxclient.jar' to run it (full screen mode by default, add -N to make it > windowed). $ pwd /home/data/svn/crossfire/jxclient [krb at kraymd64 jxclient]$ ant Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher [krb at kraymd64 jxclient]$ cd trunk/com/realtime/crossfire/jxclient/ [krb at kraymd64 jxclient]$ ant Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher [krb at kraymd64 jxclient]$ cd ../../../../../trunk/src/test/com/realtime/crossfire/jxclient/ [krb at kraymd64 jxclient]$ ant Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher Not that easy... Tried that already. > > What's with java projects anyway? Gridarta doesn't release jars, I don't > > see one for jxclient. You have to get them off-project. I guess if you're > > not in, you're out. > > See first point, experimental. But I do hope it'll soon be in good shape, > thanks to Ragnor's work, and usable :) > > Nicolas _______________________________________________ crossfire mailing list crossfire at metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire From kbulgrien at worldnet.att.net Sat Aug 4 14:31:44 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 4 Aug 2007 14:31:44 -0500 Subject: [crossfire] jxclient (was RE: GTK2-v2 Client new layout defined (gtk-v1)) In-Reply-To: <001e01c7d6ca$8e576ae0$ab0640a0$@o@free.fr> References: <200707261810.34130.kbulgrien@worldnet.att.net> <200708040247.46736.kbulgrien@worldnet.att.net> <001e01c7d6ca$8e576ae0$ab0640a0$@o@free.fr> Message-ID: <200708041431.44643.kbulgrien@worldnet.att.net> > I was quite curious to see if that jxclient would works, and you know what ? > > It does runs well on Windows :) > > (to be precise, on Windows Vista) > > See a screenshot with default resolution : > http://huet.o.free.fr/cftest/testjxclient.png > > and I did modify a little parameters and skins and with 25 x 16 map : > (I did only changed map size, so other stuffs do go in front of map) > http://huet.o.free.fr/cftest/testjxclient_bigger.png Thanks for the screenshot... it does look cool... but even after a couple of hours of digging, I still can't seem to get the toolchain so I can compile it on my end. It has something to do with ant not finding Sun's jdk on my system. I got so far as to get it to start building to the point where it croaks on java 1.4.2 being less than the required 1.5. It seems to be finding the java-1.4.2.gcj-compat stuff that the distribution installs by default, instead of the latest Sun JDK that I do have installed. I need to figure out how to tell ant to use it instead. Yes, I can see now why having a fast graphics card would matter... Wonder how fast it needs to be to be usable. Some of my systems are pretty old, and some are pretty lean on RAM. From kbulgrien at worldnet.att.net Sat Aug 4 17:19:56 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 4 Aug 2007 17:19:56 -0500 Subject: [crossfire] Compiling jxclient with ant Message-ID: <200708041719.56543.kbulgrien@worldnet.att.net> Using Mandriva 2007.0 x86_86 $ rpm -q jdk jdk-1.6.0_02-fcs I see 1.5 is minimum on Sun's stuff, but I don't know what the significance of ant's depends are on this distribution. My first attempt at getting ant installed didn't work. In the past I've had trouble with the gcj-compat stuff, so I took a wrong turn at the outset. $ sudo urpmi ant One of the following packages is needed: 1- java-1.4.2-gcj-compat-devel-1.4.2.0-40.103.1mdv2007.0.x86_64 : JPackage development scripts for GCJ (to install) 2- kaffe-devel-1.1.7-1mdk.x86_64 : Development package with static libs and headers for kaffe (to install) What is your choice? (1-2) 2 To satisfy dependencies, the following packages are going to be installed ant-1.6.5-21mdv2007.0.x86_64 antlr-2.7.6-4.1mdv2007.0.x86_64 bouncycastle-1.33-3mdv2007.0.x86_64 bouncycastle-jdk1.4-1.33-3mdv2007.0.x86_64 classpath-0.92-3mdv2007.0.x86_64 classpathx-jaf-1.1.1-1mdv2007.0.x86_64 classpathx-mail-1.1.1-3mdv2007.0.x86_64 classpathx-mail-monolithic-1.1.1-3mdv2007.0.x86_64 eclipse-ecj-3.2.0-12.3mdv2007.0.x86_64 gcj-tools-4.1.1-3mdk.x86_64 gjdoc-0.7.7-9mdv2007.0.x86_64 jamvm-1.4.3-3.1mdv2007.0.x86_64 java-1.4.2-gcj-compat-1.4.2.0-40.103.1mdv2007.0.x86_64 jikes-1.23-0.20050308.1mdk.x86_64 jpackage-utils-1.7.0-1.4mdv2007.0.noarch kaffe-1.1.7-1mdk.x86_64 kaffe-devel-1.1.7-1mdk.x86_64 lib64gcj7-devel-4.1.1-3mdk.x86_64 Proceed with the installation of the 18 packages? (84 MB) (Y/n) Y This gave me: $ pwd /home/data/svn/crossfire/jxclient $ ant Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher $ cd trunk/com/realtime/crossfire/jxclient/ $ ant Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher $ cd ../../../../../trunk/src/test/com/realtime/crossfire/jxclient/ $ ant Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher Googling the above message resulted in a suggestion for troubleshooting. $ ant --execdebug exec "/usr/java/jdk1.5.0_08/bin/java" -classpath "/usr/bin/build-classpath: error: JVM_LIBDIR /usr/lib/jvm-exports/java-gcj does not exist or is not a directory" -Dant.home="/usr/share/ant" -Dant.library.dir="/usr/share/ant/lib" org.apache.tools.ant.launch.Launcher -cp "" Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher Ok, so problem is in the tool chain probably, since it is missing stuff in /usr/lib. On a hunch, I pull out kaffe and kaffe-devel and start over. $ sudo urpme kaffe kaffe-devel To satisfy dependencies, the following 3 packages will be removed (19 MB): ant-1.6.5-21mdv2007.0.x86_64 (due to missing java-devel) kaffe-1.1.7-1mdk.x86_64 kaffe-devel-1.1.7-1mdk.x86_64 (due to unsatisfied java-1.4.2-kaffe == 0:1.4.2.00-1mdk, due to unsatisfied kaffe == 0:1.1.7-1mdk) Remove 3 packages? (y/N) y removing ant-1.6.5-21mdv2007.0.x86_64 kaffe-1.1.7-1mdk.x86_64 kaffe-devel-1.1.7-1mdk.x86_64 And re-install ant using the other choice. $ sudo urpmi ant One of the following packages is needed: 1- java-1.4.2-gcj-compat-devel-1.4.2.0-40.103.1mdv2007.0.x86_64 : JPackage development scripts for GCJ (to install) 2- kaffe-devel-1.1.7-1mdk.x86_64 : Development package with static libs and headers for kaffe (to install) What is your choice? (1-2) 1 One of the following packages is needed: 1- xml-commons-resolver10-1.3.03-5.1mdv2007.0.x86_64 : XmlResolver 1.0 utility from xml-commons (to install) 2- xml-commons-resolver11-1.3.03-5.1mdv2007.0.x86_64 : XmlResolver 1.1 utility from xml-commons (to install) 3- xml-commons-resolver12-1.3.03-5.1mdv2007.0.x86_64 : XmlResolver 1.2 from xml-commons (to install) What is your choice? (1-3) 3 To satisfy dependencies, the following packages are going to be installed: ant-1.6.5-21mdv2007.0.x86_64 gcc-java-4.1.1-3mdk.x86_64 java-1.4.2-gcj-compat-devel-1.4.2.0-40.103.1mdv2007.0.x86_64 xalan-j2-2.7.0-2.2mdv2007.0.x86_64 xerces-j2-2.8.0-1mdv2007.0.x86_64 xml-commons-1.3.03-5.1mdv2007.0.x86_64 xml-commons-resolver12-1.3.03-5.1mdv2007.0.x86_64 Proceed with the installation of the 7 packages? (26 MB) (Y/n) y Progress... but still no cigar... $ ant /usr/bin/build-classpath: error: Could not find xml-commons-apis Java extension for this JVM /usr/bin/build-classpath: error: Some specified jars were not found Buildfile: build.xml init: compile: [delete] Deleting directory /home/data/svn/crossfire/jxclient/trunk/build/jxclient [mkdir] Created dir: /home/data/svn/crossfire/jxclient/trunk/build/jxclient [javac] Compiling 115 source files to /home/data/svn/crossfire/jxclient/trunk/build/jxclient [javac] Compliance level '1.4' is incompatible with target level '1.5'. A compliance level '1.5' or better is required BUILD FAILED /home/data/svn/crossfire/jxclient/trunk/build.xml:12: Compile failed; see the compiler error output for details. Total time: 1 second Ok, something else is missing... $ sudo urpmi xml-commons-apis One of the following packages is needed: 1- xml-commons-jaxp-1.1-apis-1.3.03-5.1mdv2007.0.x86_64 : JAXP 1.1, DOM2, SAX2, SAX2-ext 1.0 apis (to install) 2- xml-commons-jaxp-1.2-apis-1.3.03-5.1mdv2007.0.x86_64 : JAXP 1.2, DOM 2, SAX 2.0.1, SAX2-ext 1.0 apis (to install) 3- xml-commons-jaxp-1.3-apis-1.3.03-5.1mdv2007.0.x86_64 : JAXP 1.3, DOM 2, SAX 2.0.1, SAX2-ext 1.0 apis (to install) What is your choice? (1-3) 3 $ ant Buildfile: build.xml init: compile: [delete] Deleting directory /home/data/svn/crossfire/jxclient/trunk/build/jxclient [mkdir] Created dir: /home/data/svn/crossfire/jxclient/trunk/build/jxclient [javac] Compiling 115 source files to /home/data/svn/crossfire/jxclient/trunk/build/jxclient [javac] Compliance level '1.4' is incompatible with target level '1.5'. A compliance level '1.5' or better is required BUILD FAILED /home/data/svn/crossfire/jxclient/trunk/build.xml:12: Compile failed; see the compiler error output for details. Total time: 1 second I don't quite understand the compliance level complaint... $ javac -version javac 1.5.0_08 Hmm... The following might have something to do with it... bouncycastle-jdk1.4-1.33-3mdv2007.0 jpackage-utils-1.7.0-1.4mdv2007.0 jamvm-1.4.3-3.1mdv2007.0 java-1.4.2-gcj-compat-1.4.2.0-40.103.1mdv2007.0 java-1.4.2-gcj-compat-devel-1.4.2.0-40.103.1mdv2007.0 This is getting complicated. the java-1.4.2-gcj-compat stuff is required by the distribution because it doesn't supply Sun's java. Hours later... This did the trick... $ export JAVA_HOME=/usr/java/latest $ ant --execdebug $ ant --execdebug exec "/usr/java/latest/jre/bin/java" -classpath "/usr/bin/build-classpath: error: JAVAVER_JNIDIR /usr/lib/java-1.6.0 does not exist or is not a directory:/usr/bin/build-classpath: error: JAVAVER_JNIDIR /usr/lib/java-1.6.0 does not exist or is not a directory:/usr/java/latest/lib/tools.jar" -Dant.home="/usr/share/ant" -Dant.library.dir="/usr/share/ant/lib" org.apache.tools.ant.launch.Launcher -cp "" Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher $ sudo mkdir /usr/lib/java-1.6.0 Who knows why the above was needed... No clue, but it was looking for the directory and could not find it. Simply making it gets the build to actually start and fail due to unfound resources.. $ ant --execdebug exec "/usr/java/latest/jre/bin/java" -classpath "/usr/bin/build-classpath: error: JAVAVER_JNIDIR /usr/lib/java-1.6.0 does not exist or is not a directory:/usr/bin/build-classpath: error: JAVAVER_JNIDIR /usr/lib/java-1.6.0 does not exist or is not a directory:/usr/java/latest/lib/tools.jar" -Dant.home="/usr/share/ant" -Dant.library.dir="/usr/share/ant/lib" org.apache.tools.ant.launch.Launcher -cp "" Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher [krb at kraymd64 trunk]$ ant --execdebug exec "/usr/java/latest/jre/bin/java" -classpath "/usr/bin/build-classpath: error: JAVAVER_JNIDIR /usr/lib/java-1.6.0 does not exist or is not a directory:/usr/java/latest/lib/tools.jar" -Dant.home="/usr/share/ant" -Dant.library.dir="/usr/share/ant/lib" org.apache.tools.ant.launch.Launcher -cp "" Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher [krb at kraymd64 trunk]$ ant --execdebug exec "/usr/java/latest/jre/bin/java" -classpath "/usr/share/java/ant.jar:/usr/share/java/ant-launcher.jar:/usr/share/java/jaxp_parser_impl.jar:/usr/share/java/xml-commons-apis.jar:/usr/java/latest/lib/tools.jar" -Dant.home="/usr/share/ant" -Dant.library.dir="/usr/share/ant/lib" org.apache.tools.ant.launch.Launcher -cp "" Buildfile: build.xml init: compile: [delete] Deleting directory /home/data/svn/crossfire/jxclient/trunk/build/jxclient [mkdir] Created dir: /home/data/svn/crossfire/jxclient/trunk/build/jxclient [javac] Compiling 115 source files to /home/data/svn/crossfire/jxclient/trunk/build/jxclient [javac] /home/data/svn/crossfire/jxclient/trunk/src/test/com/realtime/crossfire/jxclient/gui/log/ParserTest.java:23: package junit.framework does not exist [javac] import junit.framework.Test; [javac] ^ [javac] /home/data/svn/crossfire/jxclient/trunk/src/test/com/realtime/crossfire/jxclient/gui/log/ParserTest.java:24: package junit.framework does not exist [javac] import junit.framework.TestCase; [javac] ^ [javac] /home/data/svn/crossfire/jxclient/trunk/src/test/com/realtime/crossfire/jxclient/gui/log/ParserTest.java:25: package junit.framework does not exist [javac] import junit.framework.TestSuite; [javac] ^ [javac] /home/data/svn/crossfire/jxclient/trunk/src/test/com/realtime/crossfire/jxclient/gui/log/ParserTest.java:26: package junit.textui does not exist [javac] import junit.textui.TestRunner; [javac] ^ [javac] /home/data/svn/crossfire/jxclient/trunk/src/test/com/realtime/crossfire/jxclient/gui/log/ParserTest.java:33: cannot find symbol [javac] symbol: class TestCase [javac] public class ParserTest extends TestCase [javac] ^ [javac] /home/data/svn/crossfire/jxclient/trunk/src/test/com/realtime/crossfire/jxclient/gui/log/ParserTest.java:55: cannot find symbol [javac] symbol : class Test [javac] location: class com.realtime.crossfire.jxclient.gui.log.ParserTest [javac] public static Test suite() [javac] ^ [javac] /home/data/svn/crossfire/jxclient/trunk/src/test/com/realtime/crossfire/jxclient/gui/log/ParserTest.java:57: cannot find symbol [javac] symbol : class TestSuite [javac] location: class com.realtime.crossfire.jxclient.gui.log.ParserTest [javac] return new TestSuite(ParserTest.class); [javac] ^ [javac] /home/data/svn/crossfire/jxclient/trunk/src/test/com/realtime/crossfire/jxclient/gui/log/ParserTest.java:67: cannot find symbol [javac] symbol : variable TestRunner [javac] location: class com.realtime.crossfire.jxclient.gui.log.ParserTest [javac] TestRunner.run(suite()); [javac] ^ [javac] /home/data/svn/crossfire/jxclient/trunk/src/test/com/realtime/crossfire/jxclient/gui/log/ParserTest.java:294: cannot find symbol [javac] symbol : method assertEquals(java.lang.String,java.lang.String) [javac] location: class com.realtime.crossfire.jxclient.gui.log.ParserTest [javac] assertEquals(expected, dumpBuffer()); [javac] ^ [javac] 9 errors BUILD FAILED /home/data/svn/crossfire/jxclient/trunk/build.xml:12: Compile failed; see the compiler error output for details. Total time: 4 seconds $ urpmq --fuzzy junit ant-junit junit junit-demo junit-javadoc junit-manual $ sudo urpmi ant-junit To satisfy dependencies, the following packages are going to be installed: ant-junit-1.6.5-21mdv2007.0.x86_64 junit-3.8.2-1.1mdv2007.0.x86_64 Proceed with the installation of the 2 packages? (2 MB) (Y/n) y $ cd /home/data/svn/crossfire/jxclient/trunk $ ant Buildfile: build.xml init: compile: [delete] Deleting directory /home/data/svn/crossfire/jxclient/trunk/build/jxclient [mkdir] Created dir: /home/data/svn/crossfire/jxclient/trunk/build/jxclient [javac] Compiling 115 source files to /home/data/svn/crossfire/jxclient/trunk/build/jxclient skin.prelude: [copy] Copying 188 files to /home/data/svn/crossfire/jxclient/trunk/build/skin.prelude/com/realtime/crossfire/jxclient/skins/default [jar] Building jar: /home/data/svn/crossfire/jxclient/trunk/jxcskin_prelude.jar jar: [jar] Building jar: /home/data/svn/crossfire/jxclient/trunk/jxclient.jar all: BUILD SUCCESSFUL Total time: 7 seconds Bingo! $ bash run.sh The GPU cooler comes on... Ah... yes... there it is... Yup, crossfire.metalforge.com Hmm... So... JAVA_HOME and xml-commons-api, junit, ant-junit packages and the inexplicable mkdir are key for Mandriva. Does anyone care if I markup the readme a bit? Especially with the part about --execdebug? From kbulgrien at worldnet.att.net Sat Aug 4 19:44:25 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 4 Aug 2007 19:44:25 -0500 Subject: [crossfire] Compiling gridarta with ant In-Reply-To: <200708041719.56543.kbulgrien@worldnet.att.net> References: <200708041719.56543.kbulgrien@worldnet.att.net> Message-ID: <200708041944.25937.kbulgrien@worldnet.att.net> Now that I have jxclient building... gridarta still doesn't work... Will have to dig to find out what these indicate as far as missing dependencies... In the mean time, hints/clues welcome. $ rpm -q ant ant-1.6.5-21mdv2007.0 $ cd /home/data/svn/gridarta $ svn switch --relocate https://svn.sourceforge.net/svnroot/gridarta https://gridarta.svn.sourceforge.net/svnroot/gridarta $ svn update ... $ cd crossfire $ ant --execdebug exec "/usr/java/latest/jre/bin/java" -classpath "/usr/share/java/ant.jar:/usr/share/java/ant-launcher.jar:/usr/share/java/jaxp_parser_impl.jar:/usr/share/java/xml-commons-apis.jar:/usr/java/latest/lib/tools.jar" -Dant.home="/usr/share/ant" -Dant.library.dir="/usr/share/ant/lib" org.apache.tools.ant.launch.Launcher -cp "" Buildfile: build.xml init: BUILD FAILED /home/data/svn/gridarta/crossfire/build.xml:66: Could not create task or type of type: echoproperties. Ant could not find the task or a class this task relies upon. This is common and has a number of causes; the usual solutions are to read the manual pages then download and install needed JAR files, or fix the build file: - You have misspelt 'echoproperties'. Fix: check your spelling. - The task needs an external JAR file to execute and this is not found at the right place in the classpath. Fix: check the documentation for dependencies. Fix: declare the task. - The task is an Ant optional task and the JAR file and/or libraries implementing the functionality were not found at the time you yourself built your installation of Ant from the Ant sources. Fix: Look in the ANT_HOME/lib for the 'ant-' JAR corresponding to the task and make sure it contains more than merely a META-INF/MANIFEST.MF. If all it contains is the manifest, then rebuild Ant with the needed libraries present in ${ant.home}/lib/optional/ , or alternatively, download a pre-built release version from apache.org - The build file was written for a later version of Ant Fix: upgrade to at least the latest release version of Ant - The task is not an Ant core or optional task and needs to be declared using . - You are attempting to use a task defined using or but have spelt wrong or not defined it at the point of use Remember that for JAR files to be visible to Ant tasks implemented in ANT_HOME/lib, the files must be in the same directory or on the classpath Please neither file bug reports on this problem, nor email the Ant mailing lists, until all of these causes have been explored, as this is not an Ant bug. Total time: 0 seconds From kbulgrien at worldnet.att.net Sat Aug 4 22:11:01 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 4 Aug 2007 22:11:01 -0500 Subject: [crossfire] Compiling gridarta with ant In-Reply-To: <200708041944.25937.kbulgrien@worldnet.att.net> References: <200708041719.56543.kbulgrien@worldnet.att.net> <200708041944.25937.kbulgrien@worldnet.att.net> Message-ID: <200708042211.02085.kbulgrien@worldnet.att.net> On Saturday 04 August 2007 19:44, Kevin R. Bulgrien wrote: > Now that I have jxclient building... gridarta still doesn't work... Will have to dig to > find out what these indicate as far as missing dependencies... In the mean time, > hints/clues welcome. > > $ rpm -q ant > ant-1.6.5-21mdv2007.0 > $ cd /home/data/svn/gridarta > $ svn switch --relocate https://svn.sourceforge.net/svnroot/gridarta https://gridarta.svn.sourceforge.net/svnroot/gridarta > $ svn update > ... > $ cd crossfire > $ ant --execdebug > exec "/usr/java/latest/jre/bin/java" -classpath "/usr/share/java/ant.jar:/usr/share/java/ant-launcher.jar:/usr/share/java/jaxp_parser_impl.jar:/usr/share/java/xml-commons-apis.jar:/usr/java/latest/lib/tools.jar" -Dant.home="/usr/share/ant" -Dant.library.dir="/usr/share/ant/lib" org.apache.tools.ant.launch.Launcher -cp "" > Buildfile: build.xml > > init: > > BUILD FAILED > /home/data/svn/gridarta/crossfire/build.xml:66: Could not create task or type of type: echoproperties. > > Ant could not find the task or a class this task relies upon. > > This is common and has a number of causes; the usual > solutions are to read the manual pages then download and > install needed JAR files, or fix the build file: > - You have misspelt 'echoproperties'. > Fix: check your spelling. > - The task needs an external JAR file to execute > and this is not found at the right place in the classpath. > Fix: check the documentation for dependencies. > Fix: declare the task. > - The task is an Ant optional task and the JAR file and/or libraries > implementing the functionality were not found at the time you > yourself built your installation of Ant from the Ant sources. > Fix: Look in the ANT_HOME/lib for the 'ant-' JAR corresponding to the > task and make sure it contains more than merely a META-INF/MANIFEST.MF. > If all it contains is the manifest, then rebuild Ant with the needed > libraries present in ${ant.home}/lib/optional/ , or alternatively, > download a pre-built release version from apache.org > - The build file was written for a later version of Ant > Fix: upgrade to at least the latest release version of Ant > - The task is not an Ant core or optional task > and needs to be declared using . > - You are attempting to use a task defined using > or but have spelt wrong or not > defined it at the point of use > > Remember that for JAR files to be visible to Ant tasks implemented > in ANT_HOME/lib, the files must be in the same directory or on the > classpath > > Please neither file bug reports on this problem, nor email the > Ant mailing lists, until all of these causes have been explored, > as this is not an Ant bug. > > Total time: 0 seconds Resolved by adding another package, though I did not know how to figure out which "optional task" package to get, so I just kept trying different ones... There must be a better way. $ urpmi ant-nodeps $ ant ... [javac] 25 warnings jar: [jar] Building jar: /home/data/svn/gridarta/crossfire/CrossfireEditor.jar [delete] Deleting directory /home/data/svn/gridarta/crossfire/class/production BUILD SUCCESSFUL $ java -jar CrossfireEditor.jar Bingo. From kbulgrien at worldnet.att.net Sun Aug 5 00:12:06 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 5 Aug 2007 00:12:06 -0500 Subject: [crossfire] jxclient In-Reply-To: <200708041431.44643.kbulgrien@worldnet.att.net> References: <200707261810.34130.kbulgrien@worldnet.att.net> <001e01c7d6ca$8e576ae0$ab0640a0$@o@free.fr> <200708041431.44643.kbulgrien@worldnet.att.net> Message-ID: <200708050012.06214.kbulgrien@worldnet.att.net> $ java -version java version "1.6.0_02" Java(TM) SE Runtime Environment (build 1.6.0_02-b05) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_02-b05, mixed mode) Using run.sh, I get... disappointingly... Warning ! True full-screen support is not available. The system is a dual core pentium d (3.6 GHz) x86_64 with 3 Gb RAM. The graphics card is a NVIDIA 7600 GT running a true nvidia driver compiled on this machine. 01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600 GT] (rev a1) I don't know if running dual-monitors messes with performance, and do not know much about graphics acceleration as I'm no power gamer since my hardware is pretty old (except for this box which is a sort of loaner), but I believe it is possible since TuxRacer rocks even with only 17" monitor, you get a wierd feeling like you are really going down the slope. The jxclient is very slow. It feels like the character is heavily burdened, so is very hard to control. Compared to both GTK clients, it is not very playable, so I suppose it is not taking advantage of hardware acceleration :-(. So far I have not had it crash. I've played a bit with it, though at 1280x1024 it is only using about 1024x800 or so for the display, so I need a magnifying glass to see in game text and inventory and the little buttons. It's odd because the map graphics are in your face big compared to how I run the GTK clients. Unfortunately I only have 17" monitors on this machine. The graphics work is beautiful, but I must be a geek... it kind of gets in the way, though to be fair, I'd have to see it using the full 1280x1024 to give it a reasonable evaluation, but I find it really hard to monitor HP, Grace, and Mana. The small veins in the icons seem to take a lot of concentration to be able to monitor. To me the fast pace of crossfire means you can't spend a lot of time looking to see how bad you're hurting or what you have left for mana/grace. Don't know if that stuff is skinnable and so might be able to be done differently to taste. That dragon thing can about freak you out with a low-level character when you walk around a corner the right way ;-). It will be interesting to see it mature... I, and other people played the dxclient years ago because it had a bit of ambiance to it, and I've often been sorry it disappeared, so I can see jxclient going over well if performance improves, but the lag now would kill my character... literally... and I'd hate to think I had to buy better hardware to get it. Long and short of it is, I'm glad I took the time to figure out how to build it. It'll be interesting to watch. Oh, the speed thing reminds me... Daimonin sort of caught my eye some time back, and I played it a while, though quit. It was too slow. There's some talk about slowing Crossfire down, and I'm all about not dying before you can even press the word of recall hotkey, but here's my vote to not go that slow... though I haven't tried it in ages to be sure my impressions were up to date. Wish list: Scroll wheel support. From mwedel at sonic.net Sun Aug 5 01:04:24 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 04 Aug 2007 23:04:24 -0700 Subject: [crossfire] GTK2-v2 Client new layout defined (gtk-v1) In-Reply-To: <200708041911.57933.yann.chachkoff@myrealbox.com> References: <200707261810.34130.kbulgrien@worldnet.att.net> <20070804074400.GA21861@kirschbaum.myrealbox.com> <200708040419.46245.kbulgrien@worldnet.att.net> <200708041911.57933.yann.chachkoff@myrealbox.com> Message-ID: <46B56868.8010405@sonic.net> Yann Chachkoff wrote: > Le samedi 4 ao?t 2007, Kevin R. Bulgrien a ?crit : >> Hmm... So then the mumbler was really just detracting from my feeble >> attempts to work on fixing what I felt like moaning about. Ok... I get it. >> > Just as a side note, my original comment was about underlining the (IMO) > terrible layout of the GTK1 client, one that the GTK2 adaptation didn't make > any better. > > Or, to speak using other terms: > - no, it wasn't a free ad for jxclient; > - yes, it meant that regardless of the toolkit used, I found the UI cluttered > and unfriendly. > > Does that mean it shouldn't be fixed ? Of course not. It simply meant that > IMHO mimicking the GTK1 client UI didn't fix anything. But for whatever reason, it seems a lot of people like the gtk1 client layout, which is why that client still exists and hasn't been completely replaced by the gtk2 client. So since a gtk1 layout for the gtk2 client does now exist, it would seem that once that all gets formalized and set up, there really isn't any reason that the gtk1 client couldn't get removed - people would no longer be able to say "I don't like that layout", if in fact the layout is the same. And removing that client is one less thing to support, so I think that is all good. Now maybe we just need an old X11 layout for gtk2, and then we can get rid of that client also :) From mwedel at sonic.net Sun Aug 5 01:42:46 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 04 Aug 2007 23:42:46 -0700 Subject: [crossfire] Client proposal: redo inventory/look widgets In-Reply-To: References: Message-ID: <46B57166.5090905@sonic.net> Lalo Martins wrote: > On the quest to "ungeekify" the client... ;-) Just a note - I doubt there will be any single answer that everyone will like. So the idea of using libglade so multiple layouts can easily be defined I think will be a very good idea. There are just too many variations - a client that works on a 800x600 resolution display (which some people seem to want) is not likely to be all the interesting/useful for someone like me with a 1920x1200 display (I actually don't play the client full screen, but one reason is that making it full screen doesn't get me much at some point - wider inventory and text areas isn't useful). > > Based on recent discussions and a comment from Mwedel, I'd like to > propose a revision of the inventory and "look" areas, and the > introduction of three new things. (Of course I'm volunteering to write > the code for this.) > > The question being: do people really *USE* all those 10 tabs? Very > occasionally I use "unlocked" to sell stuff, but most of the time I use > "icons" and the first one. And really, neither is the ideal UI for what > I actually want to do. Probably not. I do often use the unlocked to see what stuff I've picked up that I need to sell. Sometimes I'll use the unpaid item tag if I accidentally pick something up in the store - makes it find that item. > > So here's the proposal: Currently we have an inventory notebook and a > "look" table. I propose to replace them with two other widgets: what I > call the "stuff notebook", and the "shortcut area". Are you combind what is currently the two separate look & inventory areas into 1 widge, that you are then subdividing into these 2 new widgets? I'm just having troubles visualizing the layout here. > > The "shortcut area" is really Mwedel's idea. It would be a 10x2 or 10x3 > (or even 10x4) table, and you drag either equippable items or spells to > that area. Each "slot" essentially manages one keybinding; so if I put > my axe on 1,1 and small fireball in 2,1, then pressing "1" does "apply > axe" (well not really, but you get the point), and "shift 1" does "cast > small fireball". The rows correspond to no mod, shift, ctrl, and alt. That seems reasonable. Note that dealing with numbers requires a little bit of extra work - currently, whenever you enter a number into the client, it presumes that is the count of how many items you want to drop or pick up. Realistically, that probably isn't used very often, and even for cases when it is, require characters at that point to specify the number is reasonable (I do notice that right now, the count is a spinwheel, which makes it annoying if you want to drop 1000 of something, as spinning up that far would take a while). But it could be changed to a text box. I also wonder if there is some practical limit to number of useful quick item keys - at some level, you'd get so many, that it could be a pain to remember what is there. I'd think that because of space constraints, those quick items would have to be just icon views, and not names (unless you hover the mouse) - but if you have to hover the mouse, that sort of looses the ability for it to be a quick view. If it is icon view, then it doesn't take much space - one thing to look at would be width - I think you would want it 4 rows and 10 columns - in this way, the columns effectively line up nicely with the numbers at the top of the keyboard (1 at left, then 2, etc), making it visually easier to see associations. But there may not be space for all 10, but if the number was lower (like 8), that would still be an improvement. > > Then the "stuff notebook"; I imagine it has a control (checkbox or toggle > button) that chooses between "details" and "icons" mode, regardless of > tab (I think the choice applies to all tabs). Reasonable. > > First tab is "look"; the objects on the floor near you. Second is the > plain, unfiltered inventory. Yes, the filters are occasionally useful, > but IMO, not often enough to justify polluting the UI. Fourth tab is the > spell list; this is an awesome addition to the game, IMO it's about time > it gets a more permanent space in the UI (and it's somewhat necessary in > order for the shortcut area to be useful for mages). I'd have to play around a bit to see if having to switch back and forth between ground view and inventory view would be OK, or if it would be annoying. The GTK2 client contains different support for containers (displayed inside normal inventory, not look area), so that may not be quite so bad. I'd probably suggest another tab there, which is filtered inventory, but let the character define the filter how they want - probably simple checkboxes (like the newpickup) - unpaid, magical, etc. This is probably better than current system, as it is more flexible, and matches my current method of play better - go to dungeon, get loads of crap, come back, do detect curse, drop that, do detect magic, drop non magical, then do identify, drop unlocked stuff I don't want. If I can filter on unlocked/non magical, makes it easier to filter out. And adding in client side dropall based on currently selected tab and filter view would also be nice. > > The third tab deserves its own paragraph :-) what I'm proposing here is a > "body diagram" similar to what many computer adventure games have. Yes, > it would require some tinkering, since we have IIRC 3 or 4 different > combinations of body parts... but I have an idea how to do it and I'm > willing to write the code. Here, you'd have a rough outline of a body, > and for each "body slot" your character has, there would be a space where > an icon can be drawn; if you equip an item on that slot, the > corresponding icon appears there. Clicking a slot (with or without an > equipped item) would bring up a menu with the items that can be equipped > there. > > Since it's a notebook widget, it would be hard to drag items from the > inventory to the body diagram; but then again, I have no idea why you'd > want to do that, since you can double-click it on the inventory :-) > > I think hovering an icon on any of those widgets, if you are on "icon" > view, would display the rest of the information (what you would have on > "detail" view) on a tooltip. It would seem to me that the only purpose of such a body view if you can't really interact with it (or at least equip items directly on it) is somewhat limited. Its informative to tell you where you have open spots, and another way to see what stuff you have equipped (but the show equipped items filter would probably give a more detailed information). It always seems to me the value of such body diagrams is 'ah, I have nothing on my feet - let me drag some boots there' type of thing, and/or as an easy way to equip/unequip items and see overall effect. It is graphically nicer than having to use the body command to see what stuff I could equip, but would still seem to be of limited usefulness. So I think it would be useful if it could be displayed while also displaying inventory - just not sure if there is space to do that on low res setups. If the look (ground) area remained its own widget, it could be done as a tab there, but that might also be odd. It could perhaps also be done/overdrawn in the map area, but that gets messy since different drawing logic is used there. I don't have a really good solution - the body view is good, I'm just trying to think how to make it more useful. One thing quickly off the top of my head, is if you click on an empty spot (say your finger where a ring goes), it could be nice to have an option for it to make a filter so that it only displays objects that go there. Thus, you see an empty spot and you could quickly see if/what you have to put there. This does require more information that client currently has (client currently doesn't get body info data for objects). Other unrelated imrpovements I never got around to: - Use drag and drop for containers - if I drag something (either from inventory to ground) on top of a container, it should go into that container if at all possible. Likewise, this could be used as a way to move stuff directly from container to ground. Also, drag & drop should be used for complex items task (remove need to mark items) - eg, drag a torch to flint and steel, and it does the correct thing (some for weapons and weapon improvement scrolls, etc) - the use of mark items is a bit of a hack, but that fixes a hack before that. - Change meaning of mouse buttons - left is currently examine, middle is apply (must be annoying to play crossfire if you have 2 button mouse), and right is pickup/drop. My suggestions: Left remains examine- nice about this is that it is 'safe' - nothing bad can happen if you left click on the time. Double click left is apply (double click logic can be handled by GTK IIRC). left + drag & drop works as desribed above middle is pickup/drop, but could be bound to other things Right brings up context menu, with things like lock item, mark (but that should go away), examine, not sure whatever item actions there are, but what there is, it would be here It would also be nice to make mouse buttons bindable/redefinable just like keys are. So I could rebind middle button to something different, or right button, whatever. I choose the meaning of mouse buttons above as I think it matches what is GTK/gnome standard - right normally brings up a menu of things to do, left is normally select, but doing examine isn't bad. Double click normally activates something, hence apply here. Note that if you have spells listed as a tab with objects, you do have to think about what different mouse buttons do there - one would be something like 'cast', one would be something like invoke, etc. From kbulgrien at worldnet.att.net Sun Aug 5 02:08:09 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 5 Aug 2007 02:08:09 -0500 Subject: [crossfire] GTK2-v2 Client new layout defined (gtk-v1) In-Reply-To: <46B56868.8010405@sonic.net> References: <200707261810.34130.kbulgrien@worldnet.att.net> <200708041911.57933.yann.chachkoff@myrealbox.com> <46B56868.8010405@sonic.net> Message-ID: <200708050208.09912.kbulgrien@worldnet.att.net> > But for whatever reason, it seems a lot of people like the gtk1 client layout, > which is why that client still exists and hasn't been completely replaced by the > gtk2 client. > > So since a gtk1 layout for the gtk2 client does now exist, it would seem that > once that all gets formalized and set up, there really isn't any reason that the > gtk1 client couldn't get removed - people would no longer be able to say "I > don't like that layout", if in fact the layout is the same. And removing that > client is one less thing to support, so I think that is all good. > > Now maybe we just need an old X11 layout for gtk2, and then we can get rid of > that client also :) > > But for whatever reason, it seems a lot of people like the gtk1 client layout, > which is why that client still exists and hasn't been completely replaced by the > gtk2 client. > > So since a gtk1 layout for the gtk2 client does now exist, it would seem that > once that all gets formalized and set up, there really isn't any reason that the > gtk1 client couldn't get removed - people would no longer be able to say "I > don't like that layout", if in fact the layout is the same. And removing that > client is one less thing to support, so I think that is all good. I don't know the build tools enough to know how to integrate what I have yet. I'd like to look at libglade so it wasn't a matter of building multiple binaries, but that will take time if I can keep up the interest. In the mean time, do I check in what I have even though it is awkward to build? I think it should be available if only to generate interest or feedback. Right now I have my projects in gtk-v2/glade. In there I have a script called cp2src.sh that puts the built files in gtk-v2/src so that make; make install will build one, but that doesn't make the binary a different name or anything. I can make a Makefile do a make in the gtk-v2/glade directory that did a make in gtk-v2 and renamed the binary, but it seems clunky and I haven't done anything with automake and friends so don't really know what to do to set it up to build all the various binaries automagically. Do you care if I check in something like that in a gtk-v2/glade subdirectory, or should it be alongside gtk-v2 instead of subordinate to it? > Now maybe we just need an old X11 layout for gtk2, and then we can get rid of > that client also :) That almost makes me want to fire it up for sake of the memories... Wasn't it kind of greenish or something? Hey, when it comes down to it, it is the game... not the client that holds people... isn't it? Though the client helps get more people on board I guess. I still miss the dxclient at times, but I also remember the screen was cramped... and I played GTK1 in favor of it with the guy next to me playing the dxclient with mood music so I could get the best of both worlds. From kbulgrien at worldnet.att.net Sun Aug 5 02:24:05 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 5 Aug 2007 02:24:05 -0500 Subject: [crossfire] Client proposal: redo inventory/look widgets (spinwheel) In-Reply-To: <46B57166.5090905@sonic.net> References: <46B57166.5090905@sonic.net> Message-ID: <200708050224.05634.kbulgrien@worldnet.att.net> Mark Wedel wrote: > Realistically, that probably isn't used very often, and even for cases > when it > is, require characters at that point to specify the number is reasonable > (I do notice that right now, the count is a spinwheel, which makes it > annoying if you want to drop 1000 of something, as spinning up that far > would take a while). But it could be changed to a text box. It is most useful for dropping a certain number of objects on an altar, or pulling one item out of a container of holding to give to someone else, say a potion of life... or whatever. It is also used to grab a couple of something there is a huge pile of on the ground. It is a spin wheel. The most annoying thing is is goes backwards from 0 to 10000 and that kind of messes with your mind a bit, but, it is also already a text box. You can type in a number directly. I do both, and don't think it needs to change. From crossfire at kahnert.de Sun Aug 5 13:23:25 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Sun, 5 Aug 2007 20:23:25 +0200 Subject: [crossfire] Redo wc/ac/armor (+dodge) In-Reply-To: <46B3DABC.4030108@sonic.net> Message-ID: <20070805182325.GA17005@cthulhu.desy.de> On Fri, Aug 03, 2007 at 11:51:13PM +0300, Juha J?ykk? wrote: > So we'd have AC, armour (resist_physical) and dodge? Three things? Not > good, imo. This just reflects the fact that a heavy armour will reduce your mobility. But as Mark said, keeping legacy values will cause problems. A new value called "dodge" or whatever will work better. Maybe we should do a body part table and think about protection values. After the Wallace rule of nines, we have (for humans): head 1 x 9% arm 2 x 9% leg 2 x 18% torso 1 x 36% For our body protection armour system we may use: body_head 1 x 9% body_arm 2 x 6% (12%) body_wrist 2 x 2% ( 4%) body_hand 2 x 1% ( 2%) body_leg 2 x 15% (30%) body_foot 2 x 3% ( 6%) body_torso 1 x 36% The body_shoulder part is special. A cloak covers body, legs, arms and also the head with a hood. So I would say a cloak is able to increase the armour value by 11 (arms 2%, legs 4%, torso 4% and head 1%). But no armour should increase the maximum percentage for the body part. This leads into some calculations with the overlapping cloak. For example a helmet is unable to increase your armour by more than 9%. The same for other resistances. Having a helmet which protects me by 100% against fire wouldn't burn my torso? No, just the head is protected against fire, which means 9% of the body. The armour parts shouldn't offer more protection than the body cover percentage. This also makes the armour system more clear for the players. Now combining for example a +20% leg armour with a +30% torso armour will result into +50%. Maybe we could allow a cloak for other resistances than armour to offer up to 87% protection (head 9%, arms 12%, legs 30% and torso 36%). For example a cloak of fire protection with 87% resist_fire combined with fire protection bracers, gauntlets and boots will allow an overall maximum resist_fire of 99%. But combining a 87% resist_fire cloak with a 36% resist_fire torso armour won't increase the overall resist_fire protection, because the torso is already fully protected by the torso armour, the cloak can't add anything else. Having a 30% resist_fire torso armour with 87% resist_fire cloak adds the missing 6% resist_fire for the torso part. Because there are only 99% in the body table above, you can't ever reach a protection of 100%. This can be reached by magic for a period of time or rings / amulets, but not permanent with armour. Enchanting armour will work up to the maximum value out of the table above. So you won't be able to enchant boots over 6% (2 x 3%). Adding an option to add other resistances than physical, either by scrolls or by smithery, will have the same limit. What about rings adding resistances? Well, they could either "fill up" the missing points of armours. Or there is an extra "slot" for magic which always adds the resistance, no matter of the armour resistances. The extra magic "slot" will allow resistances up to 100%, filling up armour points just up to 99%. I prefer the extra magic slot with the chance of 100% resistances. And this will be new, but easier to understand. Adding resistances will work linear. Combining two rings of fire +30% will sum up to +60%. > > Let us discuss a little bit more about a dodge skill. > > Perhaps we need that 10% XP pool, after all, I still don't like this xp pool idea. CF is not a pen & paper RPG. > but make it allocatable ONLY to those skills which cannot advance in > any other way, perhaps? Or even make the 10% player-selectable? Make skills in a way that it's possible to gain xp in. > Or simply let dodge gain XP from missing attacks? That's better. > Like 1 XP per missed damage? Uh, how do you reach level 100? Did you tried to level up hiding? This 1 xp steps are a pain. > One more thing: would dodge help evade things like magic missile? No, just those you won't be able to run away from with normal movement. You see arrows, bolts, magic missiles, ... coming and you're able to run away from them. No need to dodge them. It's just for the melee combat. On Fri, Aug 03, 2007 at 06:47:40PM -0700, Mark Wedel wrote: > Dodge skill: I thought about the idea of dodge skill getting exp each > time you dodge. Same do I. > Several problems - exp has to go up as character advances, otherwise > dodge skill effectively maxes out at pretty low level. Correct. Same problem as with lockpicking, find / disarm traps, ... > I think such a simple is open to easily exploited abuses - I park > myself by a monster I know can't damage me (say high regen + high > resistance to its attack type). I let it sit overnight, and next > morning, I've got bunch of dodge exp. Than we have to make it not exploitable. If a monster can't hurt you, you can't gain xp from it. Again, we need a system which decreases the xp gained from lower level monsters. What about something like that. You're unable to increase your dodge skill level over the monsters level. So you have to find a monster with a higher level which should be able to hurt you to gain xp from dodging. The lower the level difference is, the lower the xp gain is for dodging. So you get more xp successfully dodging with a skill level 5 against a level 10 monsters. But you won't be able to gain xp with a level 10 monster after you reached level 11 in dodging. So parking against a low level monster which is unable to hurt you won't let you gain any xp. Doing the same with a high level monster won't let you survive if you're doing nothing else than sleeping. > Now with the experience pool idea, dodge may be a bit more usable, This xp pool just don't fit into a computer based RPG. We should think more about how to gain xp with the skills instead of a pool handling. > For spellcasters, may be reasonable to have various spells (of > different power) that give dodge bonuses. I can't see why different spells should change the dodge ability. How do you explain this? Getting xp out of a successful dodge will solve this problem. > d20 vs dother: That could be changed - has to be thought on how to do > it. Percentage system would be fairly consistent with rest of game > (percentages for resist values, etc). Yes, I also think so. > A problem however is steps of increase - if you increase say dodge and > wc 1% per level, then actual level doesn't make a huge different - wc > + d100 > dodge + 50 makes the dodge and wc skills not especially > important We have to change the system, not just the values. ;) Wc is used as a percentage value. Same for dodge. For example wc 60% against 35% dodge. If you roll 1-60 on d100 you get the chance for a hit. Now the monster rolls on d100 and with 1-35 it evades. If you like a single "dice roll" you calculate 0.6 * (1 - 0.35) = 39% chance to hit the monster. But because it's a computer RPG we don't need to reduce the dice rolls... ;) We could think about if it's wise to let Wc > 100 reduce the dodge skill of the monster by Wc - 100. For example wc 135% against dodge 95% will make an effective hit value of 60%. This will allow higher level monsters low level character can't hurt. J?rgen From nicolas.weeger at laposte.net Sun Aug 5 14:57:17 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 5 Aug 2007 21:57:17 +0200 Subject: [crossfire] Compiling gridarta with ant In-Reply-To: <200708042211.02085.kbulgrien@worldnet.att.net> References: <200708041719.56543.kbulgrien@worldnet.att.net> <200708041944.25937.kbulgrien@worldnet.att.net> <200708042211.02085.kbulgrien@worldnet.att.net> Message-ID: <200708052157.20922.nicolas.weeger@laposte.net> > Resolved by adding another package, though I did not know how to figure out > which "optional task" package to get, so I just kept trying different > ones... There must be a better way. I had some issues under Gentoo, too, related to optional packages. I think I needed to add "ant-tasks" to make it compile. Thanks for the tests, and of course feel free to update documentation(s) when needed :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070805/0924daa4/attachment.pgp From lalo.martins at gmail.com Sun Aug 5 15:01:55 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Sun, 5 Aug 2007 20:01:55 +0000 (UTC) Subject: [crossfire] Client proposal: redo inventory/look widgets References: <46B57166.5090905@sonic.net> Message-ID: Also spracht Mark Wedel (Sat, 04 Aug 2007 23:42:46 -0700): > Lalo Martins wrote: > >> So here's the proposal: Currently we have an inventory notebook and a >> "look" table. I propose to replace them with two other widgets: what I >> call the "stuff notebook", and the "shortcut area". > > Are you combind what is currently the two separate look & inventory > areas into > 1 widge, that you are then subdividing into these 2 new widgets? I'm > just having troubles visualizing the layout here. Yes. Or to describe it differently -- I'm combining the separate areas into 1 widget, and introducing another widget based on your "shortcut area" idea. >> The "shortcut area"... > > That seems reasonable. Note that dealing with numbers requires a > little bit > of extra work - currently, whenever you enter a number into the client, > it presumes that is the count of how many items you want to drop or pick > up. Oh... I forgot about that. I use it all the time, for dropping money and for alchemy. Then again, those are two things that have no urgency; I suppose it would be OK if on 2.0 you were required to click on a textbox first, before typing the number. > I also wonder if there is some practical limit to number of useful > quick item > keys - at some level, you'd get so many, that it could be a pain to > remember what is there. I'd think that because of space constraints, > those quick items would have to be just icon views, and not names > (unless you hover the mouse) - but if you have to hover the mouse, that > sort of looses the ability for it to be a quick view. I was imagining an icon view, yes. I don't really care for it to be a quick view; its purpose is really binding keys. > I'd have to play around a bit to see if having to switch back and > forth > between ground view and inventory view would be OK, or if it would be > annoying. > The GTK2 client contains different support for containers (displayed > inside > normal inventory, not look area), so that may not be quite so bad. Of course, the answer will be different from person to person; but the glade layout I did for my laptop did have look and inventory as tabs, and it didn't bother me too much, except when I needed to equip or eat or drink something very fast. Which I solved by using bindings, which leads to the shortcut area :-) > I'd probably suggest another tab there, which is filtered inventory, > but let > the character define the filter how they want - probably simple > checkboxes (like the newpickup) - unpaid, magical, etc. This is > probably better than current system, as it is more flexible, and matches > my current method of play better - go to dungeon, get loads of crap, > come back, do detect curse, drop that, do detect magic, drop non > magical, then do identify, drop unlocked stuff I don't want. I did think of something like that, but it sounds like a lot of work, and I'm already biting a rather large chunk with my ideas. >> The third tab deserves its own paragraph :-) what I'm proposing here is >> a "body diagram" similar to what many computer adventure games have... > It would seem to me that the only purpose of such a body view if you > can't > really interact with it (or at least equip items directly on it) is > somewhat limited. Its informative to tell you where you have open > spots, and another way to see what stuff you have equipped (but the show > equipped items filter would probably give a more detailed information). > > It always seems to me the value of such body diagrams is 'ah, I have > nothing > on my feet - let me drag some boots there' type of thing, and/or as an > easy way to equip/unequip items and see overall effect. It is > graphically nicer than having to use the body command to see what stuff > I could equip, but would still seem to be of limited usefulness. You seem to have missed these two parts: >> Clicking a slot (with or without >> an equipped item) would bring up a menu with the items that can be >> equipped there. >> >> Since it's a notebook widget, it would be hard to drag items from the >> inventory to the body diagram; but then again, I have no idea why you'd >> want to do that, since you can double-click it on the inventory :-) Notably, yes, I think it could be possible to enable drag-and-drop; I just don't see that it would be worth it, since really, you can double- click already. > One thing quickly off the top of my head, is if you click on an empty > spot > (say your finger where a ring goes), it could be nice to have an option > for it to make a filter so that it only displays objects that go there. > Thus, you see an empty spot and you could quickly see if/what you have > to put there. This does require more information that client currently > has (client currently doesn't get body info data for objects). This was on my description :-) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From kbulgrien at worldnet.att.net Sun Aug 5 17:23:36 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 5 Aug 2007 17:23:36 -0500 Subject: [crossfire] Compiling gridarta with ant In-Reply-To: <200708052157.20922.nicolas.weeger@laposte.net> References: <200708041719.56543.kbulgrien@worldnet.att.net> <200708042211.02085.kbulgrien@worldnet.att.net> <200708052157.20922.nicolas.weeger@laposte.net> Message-ID: <200708051723.36537.kbulgrien@worldnet.att.net> > > Resolved by adding another package, though I did not know how to figure out > > which "optional task" package to get, so I just kept trying different > > ones... There must be a better way. > > I had some issues under Gentoo, too, related to optional packages. I think I > needed to add "ant-tasks" to make it compile. > > Thanks for the tests, and of course feel free to update documentation(s) when > needed :) > > Nicolas I'm not on the gridarta developer list, so I posted the information here so that someone could add what they wanted to add. I already put a document in the crossfire project... From kbulgrien at worldnet.att.net Wed Aug 8 02:35:56 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Wed, 8 Aug 2007 02:35:56 -0500 Subject: [crossfire] GTK2-v2 Client - Big Inv, All Msgs, 4 Stat Tabs In-Reply-To: <200707261810.34130.kbulgrien@worldnet.att.net> References: <200707261810.34130.kbulgrien@worldnet.att.net> Message-ID: <200708080235.56332.kbulgrien@worldnet.att.net> The quest for a better layout continues... It's funny... I like this one conceptually, but I must say, if the GTK1 is terrible and both GTKs are geeky, then I must be a geek with bad taste... I still feel like I'm missing something not having the skills/exp onscreen all the time. Fortunately, we aren't required to like the same things... but I have a feeling this one would go over reasonably well in a poll. The battle relevant data and character development data are on notebooks so that some information overload can be alleviated. Basically, if you consider the core stats and skills/experience data to be irrelevant most of the time, this one might work. The layout is 1280x1000 in the screenshot. http://krayvin.home.att.net/gtk-v2-biginv-4tabstats.png I did a libglade tutorial... Not ready to try on the crossfire client yet, but am tempting myself. One of these days I'll decide how to check all this in... Kevin R. Bulgrien From lalo.martins at gmail.com Wed Aug 8 04:53:36 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Wed, 8 Aug 2007 09:53:36 +0000 (UTC) Subject: [crossfire] GTK2-v2 Client - Big Inv, All Msgs, 4 Stat Tabs References: <200707261810.34130.kbulgrien@worldnet.att.net> <200708080235.56332.kbulgrien@worldnet.att.net> Message-ID: Also spracht Kevin R. Bulgrien (Wed, 08 Aug 2007 02:35:56 -0500): > I did a libglade tutorial... Not ready to try on the crossfire client > yet, but am tempting myself. Here's a thought: when you feel comfortable enough to start, create a branch (/client/branches/libglade) and hack on. If you stumble, ask here or on irc, and I'll lend a hand. (I suspect others will too.) This is IMHO a very worthwhile project. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From yann.chachkoff at myrealbox.com Wed Aug 8 11:21:01 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Wed, 8 Aug 2007 18:21:01 +0200 Subject: [crossfire] Client proposal: redo inventory/look widgets In-Reply-To: References: Message-ID: <200708081821.07962.yann.chachkoff@myrealbox.com> Le samedi 4 ao?t 2007, Lalo Martins a ?crit : > On the quest to "ungeekify" the client... ;-) > > Based on recent discussions and a comment from Mwedel, I'd like to > propose a revision of the inventory and "look" areas, and the > introduction of three new things. (Of course I'm volunteering to write > the code for this.) > See also http://wiki.metalforge.net/doku.php/ui_proposals , whose purpose was to serve as a central point to UI design-related discussions. > The "shortcut area" is really Mwedel's idea. It would be a 10x2 or 10x3 > (or even 10x4) table, and you drag either equippable items or spells to > that area. Each "slot" essentially manages one keybinding; so if I put > my axe on 1,1 and small fireball in 2,1, then pressing "1" does "apply > axe" (well not really, but you get the point), and "shift 1" does "cast > small fireball". The rows correspond to no mod, shift, ctrl, and alt. > *hrem* Just as a side note, that's a design idea that has already been suggested and discussed several times (The JXClient "fastbelt", the technolous's "quickbar" proposal, or the "fastbelt" in the UI Proposal #1 on the link above). You may want to ask IRC log archives for discussions about UI proposals (and also to give proper ideas credit were due :P). See in particular http://www.ailesse.be/irclog_client_ui_1.txt , which contains a couple of interesting comments over one of such proposals. > Then the "stuff notebook"; I imagine it has a control (checkbox or toggle > button) that chooses between "details" and "icons" mode, regardless of > tab (I think the choice applies to all tabs). > > First tab is "look"; the objects on the floor near you. Second is the > plain, unfiltered inventory. Yes, the filters are occasionally useful, > but IMO, not often enough to justify polluting the UI. Fourth tab is the > spell list; this is an awesome addition to the game, IMO it's about time > it gets a more permanent space in the UI (and it's somewhat necessary in > order for the shortcut area to be useful for mages). > The problem with tabs is that you cannot have the content of two different tabs on screen at the same time. This was the reason why the original JXClient design didn't use them - having both spells *and* equipment items directly accessible is quite important, IMHO. > The third tab deserves its own paragraph :-) what I'm proposing here is a > "body diagram" similar to what many computer adventure games have. Yes, > it would require some tinkering, since we have IIRC 3 or 4 different > combinations of body parts... but I have an idea how to do it and I'm > willing to write the code. Here, you'd have a rough outline of a body, > and for each "body slot" your character has, there would be a space where > an icon can be drawn; if you equip an item on that slot, the > corresponding icon appears there. Clicking a slot (with or without an > equipped item) would bring up a menu with the items that can be equipped > there. > > Since it's a notebook widget, it would be hard to drag items from the > inventory to the body diagram; but then again, I have no idea why you'd > want to do that, since you can double-click it on the inventory :-) > Because drag-n-dropping an item from one location to another to equip/unequip them is somewhat more intuitive than double-clicking. > I think hovering an icon on any of those widgets, if you are on "icon" > view, would display the rest of the information (what you would have on > "detail" view) on a tooltip. > > Thoughts? > I think you should add your proposal to the wiki page mentioned above. I'm also not sure revising the inventory part separately from the reste is the way to go. I tend to believe that rethinking the UI should be done in a more global way, as every element relates in a way or another to the others. Just my 2 ?-cents. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070808/03c3254c/attachment.pgp From yann.chachkoff at myrealbox.com Thu Aug 9 10:59:15 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Thu, 9 Aug 2007 17:59:15 +0200 Subject: [crossfire] jxclient In-Reply-To: <200708050012.06214.kbulgrien@worldnet.att.net> References: <200707261810.34130.kbulgrien@worldnet.att.net> <200708041431.44643.kbulgrien@worldnet.att.net> <200708050012.06214.kbulgrien@worldnet.att.net> Message-ID: <200708091759.19884.yann.chachkoff@myrealbox.com> Le dimanche 5 ao?t 2007, Kevin R. Bulgrien a ?crit : > $ java -version > java version "1.6.0_02" > Java(TM) SE Runtime Environment (build 1.6.0_02-b05) > Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_02-b05, mixed mode) > > Using run.sh, I get... disappointingly... > > Warning ! True full-screen support is not available. > > The system is a dual core pentium d (3.6 GHz) x86_64 with 3 Gb RAM. > The graphics card is a NVIDIA 7600 GT running a true nvidia driver > compiled on this machine. > True full-screen support and hardware acceleration should indeed be available on a platform similar to yours. The client basically relies on the JDK to detect if fullscreen is available or not for the given screen resolution. Dual-screen *may* be the cause for that. It could also be that the required screen resolution (1024x768) is not available for a reason or another. Maybe try with various values for the -W (width), -H (height) parameters. Indeed, if the Java2D software renderer is used instead of the hardware-accelerated one, the client will be rather slow. This is because it has to redraw its whole GUI, which is a costly operation. I'm not sure this can really be improved. > So far I have not had it crash. I've played a bit with it, though at > 1280x1024 it is only using about 1024x800 or so for the display, so I > need a magnifying glass to see in game text and inventory and the > little buttons. It's odd because the map graphics are in your face > big compared to how I run the GTK clients. Unfortunately I only have > 17" monitors on this machine. > Yep - This is because the skin supplied for JXClient was made for 1024x768 resolution. If that screen mode is not available, Java will emulate it by using the next closest one, but it means you'll get (1) a tiny GUI and (2) some glitches outside the 1024x768 area. > The graphics work is beautiful, but I must be a geek... it kind of > gets in the way, though to be fair, I'd have to see it using the full > 1280x1024 to give it a reasonable evaluation, but I find it really > hard to monitor HP, Grace, and Mana. The small veins in the icons > seem to take a lot of concentration to be able to monitor. To me > the fast pace of crossfire means you can't spend a lot of time looking > to see how bad you're hurting or what you have left for mana/grace. > Don't know if that stuff is skinnable and so might be able to be done > differently to taste. That dragon thing can about freak you out with > a low-level character when you walk around a corner the right way ;-). > I agree. My tests showed that, although the interface was rather nice, it was not very successfull at being usable. There were too many elements visible by default, and many of those were not clear enough in the information provided. That's based on those findings that I suggested the design which is now in the wiki. Good news is that, to some extend, jxclient is skinnable, so a lot of elements can be displayed in a different, and hopefully better, way. Gauges are indeed skinnable - the resistance ones and the HP/SP/Food/Mana ones are all using the same code, So making them clearer to see would probably be mostly a matter of changing the pictures used. Note that I believe that this interface would require more work than just changing a couple pictures, though. > It will be interesting to see it mature... I, and other people played > the dxclient years ago because it had a bit of ambiance to it, and I've > often been sorry it disappeared, so I can see jxclient going over well > if performance improves, but the lag now would kill my character... > literally... and I'd hate to think I had to buy better hardware to get > it. > You won't need to (it works well on my Athlon64/3500+ with a 6600GT) :). It is hard to guess what may be causing your lack of acceleration support, though. > Oh, the speed thing reminds me... Daimonin sort of caught my eye some > time back, and I played it a while, though quit. It was too slow. > There's some talk about slowing Crossfire down, and I'm all about not > dying before you can even press the word of recall hotkey, but here's > my vote to not go that slow... though I haven't tried it in ages to > be sure my impressions were up to date. > Notice that the talks to "slow down Crossfire" are about slowing the pace at which things happen, not the reaction time - it definitely wouldn't be fun to have a huge lag for each key pressed or action attempted. The slow-down talk was (if I'm correct) about reducing the speed of combats, for example (so fighting a big wizard would take, say, one minute, when it currently only takes ten seconds for you to smoke him - or him to smoke you, if you aren't fast enough :)). > > Wish list: Scroll wheel support. > Indeed :) Not very hard to add for sure :). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070809/2c4c2d21/attachment.pgp From kirschbaum at myrealbox.com Thu Aug 9 13:50:25 2007 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Thu, 9 Aug 2007 20:50:25 +0200 Subject: [crossfire] jxclient In-Reply-To: <200708091759.19884.yann.chachkoff@myrealbox.com> References: <200707261810.34130.kbulgrien@worldnet.att.net> <200708041431.44643.kbulgrien@worldnet.att.net> <200708050012.06214.kbulgrien@worldnet.att.net> <200708091759.19884.yann.chachkoff@myrealbox.com> Message-ID: <20070809185025.GB30410@kirschbaum.myrealbox.com> Yann Chachkoff wrote: > Le dimanche 5 ao?t 2007, Kevin R. Bulgrien a ?crit : > > Using run.sh, I get... disappointingly... > > > > Warning ! True full-screen support is not available. > > > > The system is a dual core pentium d (3.6 GHz) x86_64 with 3 Gb RAM. > > The graphics card is a NVIDIA 7600 GT running a true nvidia driver > > compiled on this machine. > > > True full-screen support and hardware acceleration should indeed be > available on a platform similar to yours. The client basically relies > on the JDK to detect if fullscreen is available or not for the given > screen resolution. I have get same problem now: at one time I got full-screen mode, but currently I cannot get it working anymore. I'm not aware that I did change anything of my X11 setup. It might be a software bug, but reading the source I get no idea what might be incorrect. > Indeed, if the Java2D software renderer is used instead of the > hardware-accelerated one, the client will be rather slow. This is > because it has to redraw its whole GUI, which is a costly operation. > I'm not sure this can really be improved. I think the client is slow without hardware acceleration because it uses transparent images for most GUI elements: if I make the client pretend that all images are opaque, the client runs very fast. That said, my plans to improve the speed are a) to minimize the number and sizes of transparent images in the GUI, and b) to redraw only the screen parts that actually have changed. I have an idea how to make it work with double buffering. > > So far I have not had it crash. I've played a bit with it, though at > > 1280x1024 it is only using about 1024x800 or so for the display, so > > I need a magnifying glass to see in game text and inventory and the > > little buttons. It's odd because the map graphics are in your face > > big compared to how I run the GTK clients. Unfortunately I only have > > 17" monitors on this machine. > > Yep - This is because the skin supplied for JXClient was made for > 1024x768 resolution. If that screen mode is not available, Java will > emulate it by using the next closest one, but it means you'll get (1) > a tiny GUI and (2) some glitches outside the 1024x768 area. Hmmm... I did increase the font size to make it readable but not wasting too much screen space for text output. > Good news is that, to some extend, jxclient is skinnable, so a lot of > elements can be displayed in a different, and hopefully better, way. > Gauges are indeed skinnable - the resistance ones and the > HP/SP/Food/Mana ones are all using the same code, So making them > clearer to see would probably be mostly a matter of changing the > pictures used. Note that I believe that this interface would require > more work than just changing a couple pictures, though. The screen layout now is defined by text files. To create a new skin copy the directory default.theme to (say) testskin. Modify the testskin directory contents to your taste: each *.skin file defines one screen; the files in fonts/ and pictures/ are the fonts/pictures referenced from the commands in the *.skin files. Then start the client with jxclient -jar jxclient.jar -S /path/to/testskin or jxclient -jar -jxclient.jar -S /path/to/testskin --server localhost The latter example skips the metaserver screen. To return to the default layout, start jxclient with "-S default". (Currently no documentation exists yet. Also, the available commands probably will change a bit from time to time.) > > Wish list: Scroll wheel support. > > Indeed :) Not very hard to add for sure :). Noted. From kbulgrien at worldnet.att.net Fri Aug 10 01:01:27 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Fri, 10 Aug 2007 01:01:27 -0500 Subject: [crossfire] libglade... Message-ID: <200708100101.27443.kbulgrien@worldnet.att.net> It's not that hard to get the client to load a .glade file with libglade... I have it doing that, but the spew is terrible. There are tons of Widget not found warnings, then it blows up, but if I am running it under gdb, I can see it is drawing the root window found in the .glade file. If I swap out the glade file, it is also obvious that window_root is rendered differently according to the new .glade file. . . . (crossfire-client-gtk2:1780): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion `GTK_IS_WIDGET (widget)' failed ** (crossfire-client-gtk2:1780): WARNING **: Widget not found: map_notebook Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47046947261936 (LWP 1780)] 0x00000000004180dd in map_init (window_root=0x9920c0) at map.c:100 100 mapgc = gdk_gc_new(map_drawing_area->window); (gdb) bt #0 0x00000000004180dd in map_init (window_root=0x9920c0) at map.c:100 #1 0x0000000000417eae in main (argc=1, argv=0x7fffb7d82098) at main.c:695 I only changed code in main.c for the window_root, so perhaps it has something to do with needing other things initializing from the .glade file too. I can see this will be interesting. It's a far cry from hello world. Well, it's late and I've been losing too much sleep the past couple of days, so its going to have to wait. BTW, I have no clue how to get the auto* stuff fixed to get ./configure to find libglade and fix up the Makefiles, etc? I edited the Makefile by hand. Anyone have any pointers to at least get me going in the right direction. What files have to be fixed by a human? Kevin R. Bulgrien From mwedel at sonic.net Fri Aug 10 02:07:53 2007 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 10 Aug 2007 00:07:53 -0700 Subject: [crossfire] Summary: Next major CF project Message-ID: <46BC0EC9.5070202@sonic.net> Discussions started a month ago about what the next major thing to work on in crossfire should be. The purpose of this e-mail is to make sure I haven't missed anything major - if this is a complete list, I'll then send it out for voting. Like before, these are very general guidelines - the goal isn't to find the solution, but rather figure out what to work on. Once we know what we are working on, then at that time, figuring out how to do it makes sense. One reason is because discussing something that is number 4 on the list may not make sense - when numbers 1-3 are done, that may change things enough that new options are available for solving #4, and previous options may no longer apply. The other reason is that by the time #4 is started, any discussions would not be as fresh in our minds. So in very broad terms, these are high priority major projects I saw discussed. Note that this is just forming a list that people will vote on, so discussions like 'that is a stupid idea' or 'that is a great idea' are also misplaced at this time - when the voting happens, that will determine what actually gets worked on - if an idea really is great, then in theory it should come up near the top of the vote total, and reverse for bad ideas. Note also that the numbering here isn't meant to show preference - it is just used as a way to more easily refer to different points from other points ---- 1) Redo classes & races so their is more difference in them - stat bonuses, skills, special per race or per class items. As part of this, I think different versions of the same skill is needed (apprentice/journeyman/master level skills for example) - I say that should be part of this because the different versions of a skill would be a major way to redo the classes & races. Maybe also change the max stat cap also. 2) Re-organize the world so there are different areas for different levels (level 1-10 area, level 11-20 area, etc). Add a main quest(s) that would lead a character through these areas up to high level 3) New beginner area - perhaps start them off on their own island, and one way exit once you leave. Have this beginner map be full of tutorial maps, easy to use places, etc. If the above point is done (reorganize the world), this may then fall into a subproject of that, or be a precursor if done first. 4) Slow down combat, so there is time to use strategy, coordinate, etc. Part of this is to reduce/eliminate monster vs player hp disparity. this may also help party play. 5) Balance magic and combat skills, so at most all levels, they are of equal power/killing potential (this is not to say that some tactics may be more/less effective at some monsters). Point being a level 50 evoker should have same ability to kill creatures as a level 50 melee weapon user. Other skills should be balanced/fixed so it is reasonably possible to get to a decent level in all of them, and having a decent level is important (a level 60 chest may demand level 60 search, disarm trap, and lockpicking) 6) Rebalance spells - highest level spell is under 30 - spells should cover the entire range of level 1-100 (not necessarily 100 different spells, but there should be a level 100 spell for each skill out there). This point may be related to #5 above, as if combat is redone, spell potency would also have to get tuned. 7) Add class guilds - basically, your best skill determines what guild(s) you can belong to - get certain benefits from those guilds not otherwise available. 8) Redo/clean up alchemy and related item creation skills - in a sense, every item in the game should be creatable by characters (I'd exclude true artifacts/map special items - those should be of legendary nature and created in a bygone time, and details and elements of their creation long lost). But characters should be able to create all the potions, most rings, armor, weapons, etc. 9) Improve party support - ideas talked about are more party quests, more party spells, having more detailed information about current health status of other party members, perhaps other 10) Move AC into a dodge attribute, with most armor giving dodge penalty, and some skills giving dodge bonus - this may tie in with point #4 (slow down combat). Doing this requires adjusting all the in-game armor, and likely adjustments to combat rolls. Also, dodge and wc should go up in value to denote they are better, not down like ac & wc currently do. That is all the points - I was looking for 5-10, and got 10. It is possible I missed something, as there were lots of e-mail messages, and I largely skimmed through them. Also, some things that were discussed I did not include here, as they are not what I'd call big projects, but more issues of policy - if decided to do that, it would be quite easy to do - issue is more if there is consensus on doing it. And as said before, this message is to make sure I have covered all the points - if we figure each project would take ~1 month (which may be way off), and we decide to do all 10 projects, that means it is almost a year of work. Hopefully it isn't that long, but discussing something 6 projects (and 6 months) down the road right now probably isn't the best use of time (it certainly isn't of mine) From crossfire at kahnert.de Fri Aug 10 07:10:00 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Fri, 10 Aug 2007 14:10:00 +0200 Subject: [crossfire] Summary: Next major CF project In-Reply-To: <46BC0EC9.5070202@sonic.net> Message-ID: <20070810121000.GB9028@cthulhu.desy.de> We should create a CF2 roadmap page in the wiki and link for each of the points to an extra page with detailed informations about it. I think all of the points are worth to become realized, so it's just the order (which project first). But in general, they're all important and depends on each other (more or less). A natural order would be (point 3-5 is better made as one project): 1. races, stats, skills 2. classes, guilds 3. change combat system (including ac -> dodge, armour, dice rolls) 4. slow down combat (alter monsters, ...) 5. balance magic and combat skills (including spreading spells up to level 100) 6. improve party support 7. reorganize the world, starting with beginner area + guilds 8. alchemy redo / clean up For example, you can't create a beginner area and than alter the combat system. The maps in this area may become unplayable. Not only there. After changing the combat system, every map / monster needs a review. Or if you rebalance magic and combat and than slowing down combat may mess up all the work done before. Same for alchemy. Finding good formulas heavily depends on the maps and what you can find there. Creating low level formulas with ingredients which are after all the changes only found on high level maps won't help either. Because of that, voting is suboptimal. We should make votes about implementation details of the points, but not the order. $0.02 J?rgen From kbulgrien at worldnet.att.net Fri Aug 10 23:33:52 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Fri, 10 Aug 2007 23:33:52 -0500 Subject: [crossfire] libglade... In-Reply-To: <200708100101.27443.kbulgrien@worldnet.att.net> References: <200708100101.27443.kbulgrien@worldnet.att.net> Message-ID: <200708102333.53077.kbulgrien@worldnet.att.net> Ok, a branch gtk-v2-libglade has been created. I'm making progress on the conversion now. It's mostly a bunch of rock breaking. > (crossfire-client-gtk2:1780): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion `GTK_IS_WIDGET (widget)' failed > > ** (crossfire-client-gtk2:1780): WARNING **: Widget not found: map_notebook > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 47046947261936 (LWP 1780)] > 0x00000000004180dd in map_init (window_root=0x9920c0) at map.c:100 > 100 mapgc = gdk_gc_new(map_drawing_area->window); > (gdb) bt > #0 0x00000000004180dd in map_init (window_root=0x9920c0) at map.c:100 > #1 0x0000000000417eae in main (argc=1, argv=0x7fffb7d82098) at main.c:695 > > I only changed code in main.c for the window_root, so perhaps it has > something to do with needing other things initializing from the .glade > file too. The other windows are converted to load from the xml file now, but the segfault was caused because lookup_widget() calls were returning null pointers. lookup_widget() is not working with libglade. The problem is addressed in a libglade FAQ... | 4.5 How do I get a pointer to a widget from within a signal handler? | | If you have a pointer to any widget in a window, you can get a pointer to | any other widget in the window using the lookup_widget() function that Glade | provides (in support.c). | | You pass it a pointer to any widget in a window, and the name of the widget | that you want to get. Usually in signal handlers you can use the first argument | to the signal handler as the first parameter to lookup_widget(), e.g. | | void | on_button1_clicked (GtkButton *button, gpointer user_data) | { | GtkWidget *entry1; | | entry1 = lookup_widget (GTK_WIDGET (button), "entry1"); | ... | } | | Note that this does not work if you are using libglade. The corresponding | code for libglade would be: | | void on_button1_clicked (GtkButton *button, gpointer user_data) | { | GladeXML* xml; | GtkWidget* entry1; | | xml = glade_get_widget_tree (GTK_WIDGET (button1)); | entry1 = glade_xml_get_widget (xml, "entry1"); | ... | } And there are a lot of lookup_widget() calls to replace in that client code. But, after only doing a couple of files, it is obvious that the problem is fixing. The windows render more completely with each lookup_widget that is converted. Kevin R. Bulgrien From kbulgrien at worldnet.att.net Sat Aug 11 01:13:50 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 11 Aug 2007 01:13:50 -0500 Subject: [crossfire] libglade... In-Reply-To: <200708102333.53077.kbulgrien@worldnet.att.net> References: <200708100101.27443.kbulgrien@worldnet.att.net> <200708102333.53077.kbulgrien@worldnet.att.net> Message-ID: <200708110113.50164.kbulgrien@worldnet.att.net> > And there are a lot of lookup_widget() calls to replace in that client code. > But, after only doing a couple of files, it is obvious that the problem is > fixing. The windows render more completely with each lookup_widget > that is converted. All lookup_widget() calls fixed. The client no longer crashes. Presently it simply sits and stares at you when you are on the metaserver dialog. It does not connect to the server, but the windows look good. NOTE: gtk-v2/src/Makefile is currently manually edited to compile. Just appended libglade-2.0 stuff. GTK2_LIBS = -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lmi -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -llibglade-2.0 INCLUDES = \ -DPACKAGE_DATA_DIR=\""$(datadir)"\" \ -DPACKAGE_LOCALE_DIR=\""$(prefix)/$(DATADIRNAME)/locale"\" \ -I$(top_srcdir)/common -I$(top_srcdir)/help \ -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libglade-2.0 \ -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT configure.in is going to need a change. Anyone who knows how to do that, feel free to pitch in and help. I've never done that before. Kevin R. Bulgrien From nicolas.weeger at laposte.net Sat Aug 11 03:30:08 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 11 Aug 2007 10:30:08 +0200 Subject: [crossfire] Summary: Next major CF project In-Reply-To: <46BC0EC9.5070202@sonic.net> References: <46BC0EC9.5070202@sonic.net> Message-ID: <200708111030.11261.nicolas.weeger@laposte.net> > So in very broad terms, these are high priority major projects I saw > discussed. Note that this is just forming a list that people will vote on, > so discussions like 'that is a stupid idea' or 'that is a great idea' are > also misplaced at this time - when the voting happens, that will determine > what actually gets worked on - if an idea really is great, then in theory > it should come up near the top of the vote total, and reverse for bad > ideas. You're missing point 2b, which is: write quests - not "quest 1 that enables to do quest 2 that enables to do quest 3", but "quest that we can do for the fun", or "outspin / details on something" :) As a personal note, point 2 isn't something I'd want to be too strict - no, I don't want a world where every beginner quests are together, every high level quets are together somewhere else. I'd rather have quests mixed in the world, provided enough (subtle) warning is given so players don't stumble onto too hard quests and die. Just my 2 cents of ? :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070811/ee33d58d/attachment.pgp From kbulgrien at worldnet.att.net Sat Aug 11 09:17:17 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 11 Aug 2007 09:17:17 -0500 Subject: [crossfire] Announce: SVN branch client/branches/gtk-v2-libglade created. In-Reply-To: <200708110113.50164.kbulgrien@worldnet.att.net> References: <200708100101.27443.kbulgrien@worldnet.att.net> <200708102333.53077.kbulgrien@worldnet.att.net> <200708110113.50164.kbulgrien@worldnet.att.net> Message-ID: <200708110917.18015.kbulgrien@worldnet.att.net> > configure.in is going to need a change. Anyone who knows how to do that, > feel free to pitch in and help. I've never done that before. Forgot to mention it... I created a branch to support the libglade conversion. What I have so far is checked in. Kevin R. Bulgrien From nicolas.weeger at laposte.net Sat Aug 11 15:41:44 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 11 Aug 2007 22:41:44 +0200 Subject: [crossfire] Announce: SVN branch client/branches/gtk-v2-libglade created. In-Reply-To: <200708110917.18015.kbulgrien@worldnet.att.net> References: <200708100101.27443.kbulgrien@worldnet.att.net> <200708110113.50164.kbulgrien@worldnet.att.net> <200708110917.18015.kbulgrien@worldnet.att.net> Message-ID: <200708112241.47675.nicolas.weeger@laposte.net> > Forgot to mention it... I created a branch to support the libglade > conversion. What I have so far is checked in. Thanks for the work on the client :) Sorry, can't really help for automess stuff, my black magic level isn't high enough :( Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070811/070041bb/attachment.pgp From kbulgrien at worldnet.att.net Sat Aug 11 16:04:59 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 11 Aug 2007 16:04:59 -0500 Subject: [crossfire] Announce: SVN branch client/branches/gtk-v2-libglade created. In-Reply-To: <200708112241.47675.nicolas.weeger@laposte.net> References: <200708100101.27443.kbulgrien@worldnet.att.net> <200708110917.18015.kbulgrien@worldnet.att.net> <200708112241.47675.nicolas.weeger@laposte.net> Message-ID: <200708111605.00074.kbulgrien@worldnet.att.net> > > Forgot to mention it... I created a branch to support the libglade > > conversion. What I have so far is checked in. > > Thanks for the work on the client :) > > Sorry, can't really help for automess stuff, my black magic level isn't high > enough :( > > Nicolas Gwa ha ha ha ha... No problem... It has been done... Gwa ha ha ha ha... Ok, I scare myself. Now... About connecting all those signals... I have a bunch of dead ones... Figures glade_xml_signal_autoconnect() doesn't automagically work (the way I tried using it). Kevin R. Bulgrien From kbulgrien at worldnet.att.net Sat Aug 11 22:46:01 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 11 Aug 2007 22:46:01 -0500 Subject: [crossfire] Announce: SVN branch client/branches/gtk-v2-libglade created. In-Reply-To: <200708110917.18015.kbulgrien@worldnet.att.net> References: <200708100101.27443.kbulgrien@worldnet.att.net> <200708110113.50164.kbulgrien@worldnet.att.net> <200708110917.18015.kbulgrien@worldnet.att.net> Message-ID: <200708112246.02095.kbulgrien@worldnet.att.net> > Forgot to mention it... I created a branch to support the libglade conversion. > What I have so far is checked in. The branch is actually playable... Woohoo... Ahem... as long as the only thing you need the keyboard to do is chat and enter commands. ;-) It is quite broken though. Most keyboard function does not work, and various signals do not seem to be connected properly. My initial thought is to check out how to use g_signal_connect() instead of glade_xml_signal_connect(), but so far no luck. I think it will come down to looking at what all is in interface.c and finding out the libglade equivalent stuff and where to put it. Other problems: All windows are open at app start and can't be raised if closed since the menu bar is non-functional. You can quit, but the app won't fully shutdown... maybe because the metaserver window will not re-raise to expose the quit button. But... I can drop a new .glade file and change the UI without recompiling (at present, the file must be named gtk-v2.glade and it must be in ${prefix}/usr/share/crossfire-client. make install does not put one there to begin with. Kevin R. Bulgrien From kbulgrien at worldnet.att.net Sat Aug 11 23:02:19 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 11 Aug 2007 23:02:19 -0500 Subject: [crossfire] Announce: SVN branch client/branches/gtk-v2-libglade created. In-Reply-To: <200708112246.02095.kbulgrien@worldnet.att.net> References: <200708100101.27443.kbulgrien@worldnet.att.net> <200708110917.18015.kbulgrien@worldnet.att.net> <200708112246.02095.kbulgrien@worldnet.att.net> Message-ID: <200708112302.19386.kbulgrien@worldnet.att.net> > My initial thought is to check > out how to use g_signal_connect() instead of glade_xml_signal_connect(), but > so far no luck. I think it will come down to looking at what all is in interface.c > and finding out the libglade equivalent stuff and where to put it. Ah, yes... even libglade people say glade_xml_signal_connect() is evil... and to use g_signal_connect() instead. http://www.gnome.org/~newren/tutorials/developing-with-gnome/html/re07.html And g_signal_connect() is what was in the interface.c file already, so a fix may be as simple as moving those calls to right after the xml file is first loaded. That still doesn't address the window/keyboard issues probably, but a good look over interface.c is in order. Kevin R. Bulgrien From kbulgrien at worldnet.att.net Sat Aug 11 23:12:43 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 11 Aug 2007 23:12:43 -0500 Subject: [crossfire] branches/gtk-v2-libglade created (and already obsolete?) In-Reply-To: <200708110917.18015.kbulgrien@worldnet.att.net> References: <200708100101.27443.kbulgrien@worldnet.att.net> <200708110113.50164.kbulgrien@worldnet.att.net> <200708110917.18015.kbulgrien@worldnet.att.net> Message-ID: <200708112312.43414.kbulgrien@worldnet.att.net> http://blogs.gnome.org/johan/2007/06/15/gtkbuilder-has-landed/ Interesting... though GtkBuilder is apparently not for Glade-2. From lalo.martins at gmail.com Sun Aug 12 06:48:47 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Sun, 12 Aug 2007 11:48:47 +0000 (UTC) Subject: [crossfire] branches/gtk-v2-libglade created (and already obsolete?) References: <200708100101.27443.kbulgrien@worldnet.att.net> <200708110113.50164.kbulgrien@worldnet.att.net> <200708110917.18015.kbulgrien@worldnet.att.net> <200708112312.43414.kbulgrien@worldnet.att.net> Message-ID: Also spracht Kevin R. Bulgrien (Sat, 11 Aug 2007 23:12:43 -0500): > http://blogs.gnome.org/johan/2007/06/15/gtkbuilder-has-landed/ > > Interesting... though GtkBuilder is apparently not for Glade-2. Well... here are a number of reasons why your work is still useful: * the v2 client's UI was *already* done with glade * I believe there aren't any GUI tools yet that fully support the GtkBuilder format * and while we're on that, I believe the library doesn't yet have all the functionality offered by libglade, although I'm not sure we're using any of the missing features * we have been promised migration tools in the future to convert Glade files into GtkBuild ones; there is some prototype stuff, but not, I believe, yet production quality. Which means, when GtkBuilder does mature, we can convert our files * and conversely, we've been told migration from libglade to GtkBuilder won't be very hard; in particular, it will be easier than migrating a "normal" gtk+ app which uses glade best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Sun Aug 12 23:23:47 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 12 Aug 2007 21:23:47 -0700 Subject: [crossfire] Summary: Next major CF project In-Reply-To: <200708111030.11261.nicolas.weeger@laposte.net> References: <46BC0EC9.5070202@sonic.net> <200708111030.11261.nicolas.weeger@laposte.net> Message-ID: <46BFDCD3.7080107@sonic.net> Nicolas Weeger wrote: >> So in very broad terms, these are high priority major projects I saw >> discussed. Note that this is just forming a list that people will vote on, >> so discussions like 'that is a stupid idea' or 'that is a great idea' are >> also misplaced at this time - when the voting happens, that will determine >> what actually gets worked on - if an idea really is great, then in theory >> it should come up near the top of the vote total, and reverse for bad >> ideas. > > You're missing point 2b, which is: write quests - not "quest 1 that enables to > do quest 2 that enables to do quest 3", but "quest that we can do for the > fun", or "outspin / details on something" :) > > > As a personal note, point 2 isn't something I'd want to be too strict - no, I > don't want a world where every beginner quests are together, every high level > quets are together somewhere else. I'd rather have quests mixed in the world, > provided enough (subtle) warning is given so players don't stumble onto too > hard quests and die. I wonder if there are really two points, as going back to my orignal message for context: 2a) Re-organize the world so there are different areas for different levels (level 1-10 area, level 11-20 area, etc). Add a main quest(s) that would lead a character through these areas up to high level with 2b being: 2b) Add many more maps and quests. Mid to high level quests are probably needed in greater number than low level quests I'd probably consider these as separate as many other items on the list (so 2b should perhaps be point 11). Re-organizing the maps doesn't require new content (but new content is always nice), and likewise, new maps/quests don't require a re-organization of the entire world. And keeping them as separate points may make them more manageable in scope (each on its own is a big project I think). And without getting into too big a discussiong on point 2b, I'd like to try to narrow it down for a better definition. For all the other points in the summary, I have a pretty some idea mentally on what changes are needed, and at what point one would call that completed. For 2b above, it is a bit vague. Is 100 quests enough? 50? 200? An exact number may not be realistic or something easily stuck to, but having some idea would be nice. Should it be driven instead by perhaps more broad terms, eg, there should be 3 story lines/quest threads that could take a character from level 1 to 100. I don't want to get into specifics (right now) about what those might be - the point being there is now some replay if a character diligently stuck to one story, they could play again and get something different. Or is what you were really saying is that in order to complete what is point 2a, some number of new maps is needed in addition to re-organization of what is there? I suppose some question above applies - should that be 1 point or 2, but in that case, I would see that if it was 1 project, the scope at that point is small enough to be reasonable. From kbulgrien at worldnet.att.net Sun Aug 12 23:35:10 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 12 Aug 2007 23:35:10 -0500 Subject: [crossfire] Gtk2 Libglade client is argely playable now. In-Reply-To: <200708112246.02095.kbulgrien@worldnet.att.net> References: <200708100101.27443.kbulgrien@worldnet.att.net> <200708110917.18015.kbulgrien@worldnet.att.net> <200708112246.02095.kbulgrien@worldnet.att.net> Message-ID: <200708122335.10286.kbulgrien@worldnet.att.net> > The branch is actually playable... Woohoo... > > Ahem... as long as the only thing you need the keyboard to do is chat and > enter commands. ;-) > > It is quite broken though. Most keyboard function does not work, and various > signals do not seem to be connected properly. My initial thought is to check > out how to use g_signal_connect() instead of glade_xml_signal_connect(), but > so far no luck. I think it will come down to looking at what all is in interface.c > and finding out the libglade equivalent stuff and where to put it. > > Other problems: All windows are open at app start and can't be raised if > closed since the menu bar is non-functional. You can quit, but the app won't > fully shutdown... maybe because the metaserver window will not re-raise to > expose the quit button. Use of g_signal_connect() is much more useful. interface.c uses it all over the place, so it makes it easy to verify the signals that need to be connected, and the resulting connections look much more like what you would expect to see based on the .glade file. By making sure all g_signal_connect() that were in the interface.c were put in the libglade version of gtk-v2 client, most of the breakage reported above is now fixed. Still persistent, though, are the window issues. The metaserver dialog will not reappear on quit, so shutting down the client is hosed, as is Client | Disconnect. But, all the windows are popped up on app start, which is not right. Presumably this means there are more interface.c guts to transfer into the application. The client, however, is very playable, and, as mentioned before, you can set in new .glade files. The conversion is largely done, it appears, except for the window stuff. Oh, but, some mods really need to be made that are a bit more than strict conversion to libglade. To support saving window position on alternate glade files, it is anticipated that some of the sizeable widgets probably need to be renamed to generic names so that they are applicable no matter what glade file is in use... like resize1, resize2, etc. They are named specific to function now, so it could make the widget names kind of silly in some layouts. The .glade file name should be programmatically selectable as another configuration parameter, so some changes are due there. Further, the make process needs to be updated to install the available glade files. It might even be wise to have a script that verifies that a .glade file is "compatible" with the source code, but checking for key widget names that must be present to avoid crashing the client. Kevin R. Bulgrien. From nicolas.weeger at laposte.net Mon Aug 13 15:15:35 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 13 Aug 2007 22:15:35 +0200 Subject: [crossfire] Map saving updates Message-ID: <200708132215.39617.nicolas.weeger@laposte.net> Hello. I committed yesterday changes to the map saving functions. Hopefully they will make the server more robust towards corruption, ensuring maps are not partially written to disk. I do advise people running servers to backup their data before updating to SVN, though :) I do think there is no breakage, but there is always some corner case I may have forgotten ^_- Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070813/d9326378/attachment.pgp From kbulgrien at worldnet.att.net Mon Aug 13 23:20:00 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Mon, 13 Aug 2007 23:20:00 -0500 Subject: [crossfire] gtk-v2/src/metaserver.c revision 6801 (metaserver2 mods) Message-ID: <200708132320.00553.kbulgrien@worldnet.att.net> It seems trunk is broken with metaserver2 code. The client hard locks on exit. It seems to be hanging at the mutex lock because the metaserver2 isn't up, but I'm not 172 while (metaserver2_check_status()) { 173 usleep(100); 174 gtk_main_iteration_do(FALSE); 175 } 176 177 178 pthread_mutex_lock(&ms2_info_mutex); It kind of concerns me that the client would hard lock if the metaserver was down. I put the whole block in #if 0 / #endif, and the libglade client works great. Do I file a bug report, or is this in process code and that would just irritate someone? It also means I guess I need to merge the libglade stuff down to branch 1.x to get non-broken code. I am pretty sure the libglade port is done and all that is left is to add new code to support choosing a .glade file to play with and tweaking on the window position saving. Comments? Kevin R. Bulgrien From mwedel at sonic.net Mon Aug 13 23:57:02 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 13 Aug 2007 21:57:02 -0700 Subject: [crossfire] gtk-v2/src/metaserver.c revision 6801 (metaserver2 mods) In-Reply-To: <200708132320.00553.kbulgrien@worldnet.att.net> References: <200708132320.00553.kbulgrien@worldnet.att.net> Message-ID: <46C1361E.3070900@sonic.net> Kevin R. Bulgrien wrote: > It seems trunk is broken with metaserver2 code. The client hard locks on exit. > It seems to be hanging at the mutex lock because the metaserver2 isn't up, > but I'm not > > 172 while (metaserver2_check_status()) { > 173 usleep(100); > 174 gtk_main_iteration_do(FALSE); > 175 } > 176 > 177 > 178 pthread_mutex_lock(&ms2_info_mutex); > > It kind of concerns me that the client would hard lock if the metaserver was > down. > > I put the whole block in #if 0 / #endif, and the libglade client works great. > Do I file a bug report, or is this in process code and that would just > irritate someone? File a bug report. I'll look at it no matter what, but bug reports are always good. I think I have some idea as to the problem, but please post bug report with best steps to reproduce it. > > It also means I guess I need to merge the libglade stuff down to branch 1.x > to get non-broken code. I am pretty sure the libglade port is done and all > that is left is to add new code to support choosing a .glade file to play with > and tweaking on the window position saving. I probably wouldn't worry about that much right now - 1.x and trunk are kept pretty closely in sync - at some point, that metaserver2 code is going to get merged down into the 1.x branch, so that bug in the trunk needs to get fixed, but I think all new/active development should be done on the trunk and not 1.x (otherwise you may find yourself in the reverse situation down the road - some new feature unique to 2.0 (trunk) is added, and you now need to rebase/merge up to that) From nicolas.weeger at laposte.net Tue Aug 14 13:24:28 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 14 Aug 2007 20:24:28 +0200 Subject: [crossfire] Pen and inscription Message-ID: <200708142024.31753.nicolas.weeger@laposte.net> Hello. There are currently some bugs on tracker related to the ease one has in leveling in inscription. I propose to fix this issue by having pen use food when used. One food per character for standard writing, some computed value for spell scrolls. This would enable to limit the max scrolls one could write. Maybe we could enable charging to work on pen, too ;) Opinions? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070814/2a001ea4/attachment.pgp From nicolas.weeger at laposte.net Tue Aug 14 12:09:49 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 14 Aug 2007 19:09:49 +0200 Subject: [crossfire] Summary: Next major CF project In-Reply-To: <46BFDCD3.7080107@sonic.net> References: <46BC0EC9.5070202@sonic.net> <200708111030.11261.nicolas.weeger@laposte.net> <46BFDCD3.7080107@sonic.net> Message-ID: <200708141909.52899.nicolas.weeger@laposte.net> > 2a) Re-organize the world so there are different areas for different levels > (level 1-10 area, level 11-20 area, etc). Add a main quest(s) that would > lead a character through these areas up to high level Well, we could do some quests to have the player visit the world, that sure could be fun if well done :) As I said, I don't like that much the idea of having "main quest" to guide you - part of the game imo is to find quests and places to level up. > For 2b above, it is a bit vague. Is 100 quests enough? 50? 200? An Quests are enough, as long as we actually write some. There hasn't been any change in maps in months, I think... and no real "quest" (by quest I mean something more than raffle [enter map, kill everything, take loot], I'm more thinking of necromancer / ancient pupland, pupland, scorn royalty quest) > Or is what you were really saying is that in order to complete what is > point 2a, some number of new maps is needed in addition to re-organization > of what is there? I suppose some question above applies - should that be 1 > point or 2, but in that case, I would see that if it was 1 project, the > scope at that point is small enough to be reasonable. No, didn't mean that, sorry if that wasn't clear :) I meant "non main quests are important too, to help players discover the world, find backstories, whatever" - all the more important as I don't like this idea of main quest, there are only "side quests" ;) Just my 2 cents of ? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070814/850fbded/attachment.pgp From crossfire at kahnert.de Tue Aug 14 14:32:44 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Tue, 14 Aug 2007 21:32:44 +0200 Subject: [crossfire] Pen and inscription In-Reply-To: <200708142024.31753.nicolas.weeger@laposte.net> Message-ID: <20070814193244.GF14483@cthulhu.desy.de> On Tue, Aug 14, 2007 at 08:24:28PM +0200, Nicolas Weeger wrote: > There are currently some bugs on tracker related to the ease one has > in leveling in inscription. > > I propose to fix this issue by having pen use food when used. One food > per character for standard writing, some computed value for spell > scrolls. > > This would enable to limit the max scrolls one could write. Are people unable to eat or why should this limit anything? > Maybe we could enable charging to work on pen, too ;) That will fix the problem. Have you ever seen a pen which is able to write forever? Let the pen consume charges; make the pen rechargeable via charging scrolls. It's ok to have a high amount of charges, in a range of 200 up to 500; maybe even more, depending on the xp gain. Pens aren't found that often, so having a low charge will prevent people getting a decent inscription level. Oh, and don't let the skill scroll level be higher than the casting skill level. Writing a scroll with inscription level 30 and a spell casting level of 5 (for the selected spell) should result into a level 5 scroll (not 30). And vice versa, having level 25 casting skill and level 7 inscription skill will produce level 7 scrolls. Whatever is lower should be the resulting level. And reduce the amount of xp someone gets for inscribing a scroll. Slaying orcs and zombies to reach level 10 in melee will take a long time, but using inscription level 10 is a matter of seconds. That's ridiculous. J?rgen From kbulgrien at worldnet.att.net Tue Aug 14 18:53:36 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Tue, 14 Aug 2007 18:53:36 -0500 Subject: [crossfire] Summary: Next major CF project In-Reply-To: <200708141909.52899.nicolas.weeger@laposte.net> References: <46BC0EC9.5070202@sonic.net> <46BFDCD3.7080107@sonic.net> <200708141909.52899.nicolas.weeger@laposte.net> Message-ID: <200708141853.36775.kbulgrien@worldnet.att.net> > Well, we could do some quests to have the player visit the world, that sure > could be fun if well done :) > As I said, I don't like that much the idea of having "main quest" to guide > you - part of the game imo is to find quests and places to level up. I may be "off topic" here, but with the discussion of quests, I wonder why current, pre-existing quests shouldn't receive some attention to make them compatible with the "quest system". I filed a sourceforge issue once and in it commented about the quest system, and anonymous said that nobody wrote any quests so having the system was kind of immaterial. Why? Are the pre-existing quests not able to be rolled into the quest system? To me getting quests logged somehow would be an excellent way to start out improving crossfire. Kevin R. Bulgrien From mwedel at sonic.net Tue Aug 14 23:20:02 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 14 Aug 2007 21:20:02 -0700 Subject: [crossfire] Summary: Next major CF project In-Reply-To: <200708141909.52899.nicolas.weeger@laposte.net> References: <46BC0EC9.5070202@sonic.net> <200708111030.11261.nicolas.weeger@laposte.net> <46BFDCD3.7080107@sonic.net> <200708141909.52899.nicolas.weeger@laposte.net> Message-ID: <46C27EF2.40408@sonic.net> Nicolas Weeger wrote: >> 2a) Re-organize the world so there are different areas for different levels >> (level 1-10 area, level 11-20 area, etc). Add a main quest(s) that would >> lead a character through these areas up to high level > > Well, we could do some quests to have the player visit the world, that sure > could be fun if well done :) > As I said, I don't like that much the idea of having "main quest" to guide > you - part of the game imo is to find quests and places to level up. This, like many of these discussions, is probably a matter of preference. I'm sure there are some folks that would prefer to have a major quest storyline that characters could follow. Not every quest should be part of a main quest storyline - some quests you would only find by talking to certain NPCs. Other quests may perhaps need some cleaning up or additions - if one takes the nobility quest in scorn, I seem to recall that if one was to only do that (and managed to never die), there are still some gaps where you wouldn't be high enough level for the next task - I'm not sure that is a bad thing, but it might be nice to handle that better somehow - I'm not sure filling in all the gaps is right, but something more of 'this quest shouldn't be attempted by people less than level 30' - that may sound a little too guided, but some of those quests require a bit of searching to find the right place, and to go there only to find out it is way too deadly can be annoying. > >> For 2b above, it is a bit vague. Is 100 quests enough? 50? 200? An > > Quests are enough, as long as we actually write some. There hasn't been any > change in maps in months, I think... and no real "quest" (by quest I mean > something more than raffle [enter map, kill everything, take loot], I'm more > thinking of necromancer / ancient pupland, pupland, scorn royalty quest) But I think it would help to having something a bit more definitive. If we added just 1 more quest, do we call it done? I'd think not. So it'd probably be good to have some idea of the scope. > >> Or is what you were really saying is that in order to complete what is >> point 2a, some number of new maps is needed in addition to re-organization >> of what is there? I suppose some question above applies - should that be 1 >> point or 2, but in that case, I would see that if it was 1 project, the >> scope at that point is small enough to be reasonable. > > No, didn't mean that, sorry if that wasn't clear :) > I meant "non main quests are important too, to help players discover the > world, find backstories, whatever" - all the more important as I don't like > this idea of main quest, there are only "side quests" ;) Ok - so it really sounds like you the reorganization of the world isn't related to adding new quests, so that these are then separate points - a) world should get reorganized and b) new quests/maps are needed From mwedel at sonic.net Tue Aug 14 23:21:15 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 14 Aug 2007 21:21:15 -0700 Subject: [crossfire] Summary: Next major CF project In-Reply-To: <200708141853.36775.kbulgrien@worldnet.att.net> References: <46BC0EC9.5070202@sonic.net> <46BFDCD3.7080107@sonic.net> <200708141909.52899.nicolas.weeger@laposte.net> <200708141853.36775.kbulgrien@worldnet.att.net> Message-ID: <46C27F3B.8030203@sonic.net> Kevin R. Bulgrien wrote: >> Well, we could do some quests to have the player visit the world, that sure >> could be fun if well done :) >> As I said, I don't like that much the idea of having "main quest" to guide >> you - part of the game imo is to find quests and places to level up. > > I may be "off topic" here, but with the discussion of quests, I wonder why > current, pre-existing quests shouldn't receive some attention to make them > compatible with the "quest system". I filed a sourceforge issue once and in > it commented about the quest system, and anonymous said that nobody > wrote any quests so having the system was kind of immaterial. > > Why? > > Are the pre-existing quests not able to be rolled into the quest system? To > me getting quests logged somehow would be an excellent way to start out > improving crossfire. Last I recall, the previous quest management system was removed to come up with some new/better system. I think once that new system is in place, anything that is a quest should be included in it, not just new quests. From mwedel at sonic.net Wed Aug 15 01:09:15 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 14 Aug 2007 23:09:15 -0700 Subject: [crossfire] Pen and inscription In-Reply-To: <200708142024.31753.nicolas.weeger@laposte.net> References: <200708142024.31753.nicolas.weeger@laposte.net> Message-ID: <46C2988B.5030106@sonic.net> Nicolas Weeger wrote: > Hello. > > There are currently some bugs on tracker related to the ease one has in > leveling in inscription. > > I propose to fix this issue by having pen use food when used. One food per > character for standard writing, some computed value for spell scrolls. > > This would enable to limit the max scrolls one could write. > > Maybe we could enable charging to work on pen, too ;) I see no reason for the pens not to have some limited number of uses, just like the flint & steel. It sounds like some adjusting to the exp rewards are also needed. But if a character has an infinite number of pens and a sufficiently large enough amount of time, I don't see that as being an issue related to getting lots of exp - that is no different than lots of other parts of the game. Another adjustment could be to put in some time penalty (set pl->speed_left to some value) on the basis it should take some real time to right scrolls. The time penalty should be based somewhat on the players actual speed, as otherwise a fast player may not get penalized enough, where as a slow player would get penalized for too long. From mwedel at sonic.net Wed Aug 15 01:33:39 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 14 Aug 2007 23:33:39 -0700 Subject: [crossfire] Gtk2 Libglade client is argely playable now. In-Reply-To: <200708122335.10286.kbulgrien@worldnet.att.net> References: <200708100101.27443.kbulgrien@worldnet.att.net> <200708110917.18015.kbulgrien@worldnet.att.net> <200708112246.02095.kbulgrien@worldnet.att.net> <200708122335.10286.kbulgrien@worldnet.att.net> Message-ID: <46C29E43.8070806@sonic.net> To fix the metaserver2 hanging bug, I used the libglade version. Quick notes/thoughts: configure.in, line 470 - think you mean 'test' not 'text'. Not sure why that was added for the glade version Client itself: If unable to load the glade file, it should probably just print the error and exit - with it trying to run, it doesn't get very far before it crashes anyway, but it spews lots of messages before it does so, so one can't easily see what one did wrong. As a note, make install doesn't seem to install the glade file, so extra steps are needed to get something that works here. It might also be nice to be able to specify the glade file on the command line, since it would seem that with the client, being able to point to different glade files easily/quickly would be desirable. These are all just minor quibbles. all in all, great job that you have done so far on this. From nicolas.weeger at laposte.net Wed Aug 15 02:52:21 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 15 Aug 2007 09:52:21 +0200 Subject: [crossfire] Summary: Next major CF project In-Reply-To: <200708141853.36775.kbulgrien@worldnet.att.net> References: <46BC0EC9.5070202@sonic.net> <200708141909.52899.nicolas.weeger@laposte.net> <200708141853.36775.kbulgrien@worldnet.att.net> Message-ID: <200708150952.25508.nicolas.weeger@laposte.net> > I may be "off topic" here, but with the discussion of quests, I wonder why > current, pre-existing quests shouldn't receive some attention to make them > compatible with the "quest system". I filed a sourceforge issue once and > in it commented about the quest system, and anonymous said that nobody > wrote any quests so having the system was kind of immaterial. > > Why? > > Are the pre-existing quests not able to be rolled into the quest system? > To me getting quests logged somehow would be an excellent way to start out > improving crossfire. As Mark said, the quest system was removed - it wasn't really that great anyway (I'm the author, so I don't mind saying that ;p) As I see it, having a quest system from the start is useless. The way for me to have quests is: * someone thinks of a nice idea, starts to implement * wants to do something she doesn't know how to do, asks for help * someone else does some scripting to implement the nice idea * quest is nice and fun * when some more scripting is needed, existing scripts can be adapted Doing scripts beforehand is useless, no one uses them anyway (just see the experience rewarder I made, or even the "old" quest system - it wasn't used at all). So let's first have people *design* quests, then we'll do the infrastructure around it :) (else we *again* fall in the "let's code something! how will it be used? who knows, I don't care, I wanna code!" trap) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070815/e4363f46/attachment.pgp From crossfire at kahnert.de Wed Aug 15 04:18:25 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Wed, 15 Aug 2007 11:18:25 +0200 Subject: [crossfire] Summary: Next major CF project In-Reply-To: <46C27EF2.40408@sonic.net> Message-ID: <20070815091825.GA8307@cthulhu.desy.de> On Tue, Aug 14, 2007 at 09:20:02PM -0700, Mark Wedel wrote: > Nicolas Weeger wrote: > > No, didn't mean that, sorry if that wasn't clear :) > > I meant "non main quests are important too, to help players discover > > the world, find backstories, whatever" - all the more important as I > > don't like this idea of main quest, there are only "side quests" ;) > > Ok - so it really sounds like you the reorganization of the world > isn't related to adding new quests, so that these are then separate > points - a) world should get reorganized and b) new quests/maps are > needed New quests / maps are always needed. This point won't become less important if not listed or more important if collected lots of votes. And the idea of having a region with a "main quest" leading through it is just to help players find their way without spoilers and without becoming bored / frustrated because they can't find suited maps to play. There is no need to make it a "guided tour". It should be more a way to find interesting maps / quests to play. It's really annoying to run around and discover new maps which are boring because your level is far to high for it (and you didn't found it before where it would be fun). And on the ohter hand, it's annoying to enter a new map and to find out that this is far to hard to beat for your level and you die. The solution is a quest system which gives out quests best suited for your character level. This is done far easier by having regions for a level range than mixing it all together. Besides that, it's much more consistent to have monsters of the same strength together; or what prevents a dragon to eat all the small critters near the dragon cave? For the gameplay it's also much better to place monsters of the same strength together. I don't want to face low level monsters on higher levels. There's no fun running through a hord of goblins as a level 20 character, not talking about higher levels... So the quest system should offer the player maps of the region where they'll have fun playing. It should be avoided that the king of scorn sends out a level 30 character to find the goblin chief, just because the player discovered this quest far to late. Same for the titan quest, which isn't solvable for low level players. Someone could argue that you can come back later. Sure, but you won't remember all the maps, and again, you will visit them later with a far to high level. At the moment it's far to easy to gain levels and far to hard to find suited maps. That's a bad combination and I would say the main reason why there are so few players around the world. J?rgen From nicolas.weeger at laposte.net Wed Aug 15 09:33:20 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 15 Aug 2007 16:33:20 +0200 Subject: [crossfire] gtk-v2/src/metaserver.c revision 6801 (metaserver2 mods) In-Reply-To: <46C1361E.3070900@sonic.net> References: <200708132320.00553.kbulgrien@worldnet.att.net> <46C1361E.3070900@sonic.net> Message-ID: <200708151633.23828.nicolas.weeger@laposte.net> > I probably wouldn't worry about that much right now - 1.x and trunk are > kept pretty closely in sync - at some point, that metaserver2 code is going > to get merged down into the 1.x branch, so that bug in the trunk needs to > get fixed, but I think all new/active development should be done on the > trunk and not 1.x (otherwise you may find yourself in the reverse situation > down the road - some new feature unique to 2.0 (trunk) is added, and you > now need to rebase/merge up to that) For client, couldn't we just forget branch? AFAIK both trunk and branch are almost the same, and trunk client works fine, so I see no reason really to keep both. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070815/aa3383ea/attachment.pgp From subs at eracc.com Wed Aug 15 11:45:26 2007 From: subs at eracc.com (ERACC Subscriptions) Date: Wed, 15 Aug 2007 11:45:26 -0500 Subject: [crossfire] Pen and inscription In-Reply-To: <200708142024.31753.nicolas.weeger@laposte.net> References: <200708142024.31753.nicolas.weeger@laposte.net> Message-ID: <200708151145.28169.subs@eracc.com> On Tuesday 14 August 2007 Nicolas Weeger wrote: > Hello. > > There are currently some bugs on tracker related to the ease one has in > leveling in inscription. > > I propose to fix this issue by having pen use food when used. One food per > character for standard writing, some computed value for spell scrolls. > > This would enable to limit the max scrolls one could write. > > Maybe we could enable charging to work on pen, too ;) > > Opinions? > > Nicolas Nerf! Nerf! Nerf! Nerf! Nerf! Nerf! Nerf! Nerf! Nerf! Nerf! Nerf! Nerf! :) Oh well, looks like experience for inscription is going the way of hiding experience. IOW it won't be useful to work on it after this and can be mostly ignored. :p Gene Alexander -- ERA Computers & Consulting We can provide you with VoIP phone service for your home and/or business. Our VoIP phone service has FREE long distance in the USA and Canada! Contact us! Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From kbulgrien at worldnet.att.net Wed Aug 15 20:04:48 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Wed, 15 Aug 2007 20:04:48 -0500 Subject: [crossfire] Gtk2 Libglade client is argely playable now. In-Reply-To: <46C29E43.8070806@sonic.net> References: <200708100101.27443.kbulgrien@worldnet.att.net> <200708122335.10286.kbulgrien@worldnet.att.net> <46C29E43.8070806@sonic.net> Message-ID: <200708152004.48387.kbulgrien@worldnet.att.net> > To fix the metaserver2 hanging bug, I used the libglade version. Thanks. > Quick notes/thoughts: > > configure.in, line 470 - think you mean 'test' not 'text'. Not sure why that > was added for the glade version That was an unintentional commit, however, the reason it is there is because while struggling to learn autoconf, I found out about autoscan, and autoscan reports that configure.in is missing many checks. In fact, it has been well over a year since I have been able to build locally with working sound, yet the Mandriva compiled 1.9.1 client works with sound -- so configure.in or some thing is just not helping someone like me build with all features successfully, and I have not taken the time yet to try to figure out more than examining the config.log and trying to add packages to get rid of the "no" entries. I thought to add in to configure.in autoscan's recommendations, but rethought it might be a bit presumptuous to assume I should do that, and only added the sound stuff for myself. It was bad that I didn't catch that in the diff analysis I did before the commit. I'll back it out, but thanks for pointing out the typo. > Client itself: If unable to load the glade file, it should probably just print > the error and exit - with it trying to run, it doesn't get very far before it > crashes anyway, but it spews lots of messages before it does so, so one can't > easily see what one did wrong. Good thought. I hadn't gotten that far. > As a note, make install doesn't seem to install > the glade file, so extra steps are needed to get something that works here. Yes, I already had that on my agenda as stated earlier in the thread. > It might also be nice to be able to specify the glade file on the command line, > since it would seem that with the client, being able to point to different glade > files easily/quickly would be desirable. Great idea. It hadn't occurred to me, but would be faster to implement than reworking config.c, so could get the libglade client more presentable faster while the more complicated changes are being worked on. > These are all just minor quibbles. all in all, great job that you have done > so far on this. From mwedel at sonic.net Wed Aug 15 23:46:05 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 15 Aug 2007 21:46:05 -0700 Subject: [crossfire] gtk-v2/src/metaserver.c revision 6801 (metaserver2 mods) In-Reply-To: <200708151633.23828.nicolas.weeger@laposte.net> References: <200708132320.00553.kbulgrien@worldnet.att.net> <46C1361E.3070900@sonic.net> <200708151633.23828.nicolas.weeger@laposte.net> Message-ID: <46C3D68D.7020607@sonic.net> Nicolas Weeger wrote: >> I probably wouldn't worry about that much right now - 1.x and trunk are >> kept pretty closely in sync - at some point, that metaserver2 code is going >> to get merged down into the 1.x branch, so that bug in the trunk needs to >> get fixed, but I think all new/active development should be done on the >> trunk and not 1.x (otherwise you may find yourself in the reverse situation >> down the road - some new feature unique to 2.0 (trunk) is added, and you >> now need to rebase/merge up to that) > > For client, couldn't we just forget branch? > > AFAIK both trunk and branch are almost the same, and trunk client works fine, > so I see no reason really to keep both. That is the case right now, but may not be. What I forsee at some point is various update to the protocol level in the trunk server and client - those changes may not be really stable (alteration needed whatever) and thus are not really good to be in one area. And I can also see some changes made to the server/client/protocol that would only exist in the 2.0 branch. It was also decided at the same of setting this up, that two versions for all the areas should be done. One could probably make a stronger case that trunk vs branch of maps doesn't make a lot of sense, but maintaining two versions really isn't that difficult, especially if at some point (which sounds likely) those two versions drift apart. From kbulgrien at worldnet.att.net Thu Aug 16 02:30:38 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu, 16 Aug 2007 02:30:38 -0500 Subject: [crossfire] gtk-v2-libglade branch stable; ready for review/merge. Message-ID: <200708160230.38911.kbulgrien@worldnet.att.net> FYI, The libglade conversion of the gtk-v2 client is in a stable state and is basically at release-candidate stage with respect to the libglade functionality. Feel free to try it on for size. I haven't checked on all the glade configurations I have make up, but there are two different ones in SVN presently. Feel free to scope it out and give feedback... I believe it is stable to the point where it can be merged back onto trunk and branch/1.x. Consider the following example: $ ./configure --prefix=${HOME} $ make $ make install The libglade client changes include: 1) autoconf/automake stuff has been done so that `make install` copies the gtk-v2.glade and gtk-v1.glade file into the package data directory aka ~/share/crossfire-client in this example. 2) crossfire-client-gtk2 sources main.h and main.c consider the the package data directory to be the default location for .glade files. This directory is already the default location for bmaps.client. 3) By default crossfire-client-gtk2 will attempt to load gtk-v2.glade. 4) It is possible to specify and alternate .glade file from the command-line using -xml_file. IE. crossfire-client-gtk2 -xml_file ~/share/crossfire-client/gtk-v1.glade 5) If the glade xml file cannot be read, the client will abort immediately and display an error message on stderr that identifies the file it wants to load. 6) The new libglade gtk-v2 client has been modified to be able to programatically determine the names of all hpaned and vpaned widgets in the .glade file. This means that Client | Save Window Position will work for any .glade file as long as all of the resizeable hpaned and vpaned widget names are prefixed with either hpaned_ or vpaned_. This is the default naming convention used by the Glade Designer. The client no longer used hard-coded names, and is not restricted to a fixed number of resize points. It is not possible to specify the .glade file from within the Client | Configure window. I looked at that code a bit, but have not really digested how it works if you want to save string data (path/filename) instead of a simple numeric value. I guess the sound_server setting is one possible example to follow, but so far I haven't quite figured it out. Features to be considered, but not yet implemented are likely: 1) Choose a .glade file from the Client | Configure window. 2) Possibly create a mechanism so that Client | Save Window Position could work for multiple .glade files without blowing away the saved settings for other layouts. Presently, if you run the client with a new layout, the Window sizing may be broken because it will use the values set up for the previously used layout. I guess I'm not sure how big a deal that is since I see people latching on to a favorite and playing with it. 3) I wonder if the .glade files should be named to make it obvious they are designed only for the gtk-v2 client. Perhaps so that the file name always appears in the form gtk-v2-.glade. Ideas entertained. I do plan to upload a few more .glade layouts, but I haven't given much thought yet on how to name them or describe their appearance yet. Kevin R. Bulgrien From crossfire at kahnert.de Thu Aug 16 15:16:22 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Thu, 16 Aug 2007 22:16:22 +0200 Subject: [crossfire] Summary: Next major CF project In-Reply-To: <20070810121000.GB9028@cthulhu.desy.de> Message-ID: <20070816201622.GC1246@cthulhu.desy.de> On Fri, Aug 10, 2007 at 02:10:00PM +0200, Juergen Kahnert wrote: > We should create a CF2 roadmap page in the wiki and link for each of > the points to an extra page with detailed informations about it. I started to fill up some points into such a page: http://wiki.metalforge.net/doku.php/dev_todo:cf2.0:roadmap I tried to make a summary of the discussion. I took the points which was talked about without any protest. Or if there was any contradiction I tried to merge and fix it or added some new ideas. Leaf already found the sites and added things. Feel free to do the same. :) J?rgen From nicolas.weeger at laposte.net Sat Aug 18 07:38:36 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 18 Aug 2007 14:38:36 +0200 Subject: [crossfire] Summary: Next major CF project In-Reply-To: <46BC0EC9.5070202@sonic.net> References: <46BC0EC9.5070202@sonic.net> Message-ID: <200708181438.40840.nicolas.weeger@laposte.net> After some thought, the list is missing: - add lore, background stories, and so on. This makes the world funnier, imo - improve monster behaviour / moving algos. Do I need to say more? ;) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070818/b0c885de/attachment.pgp From crossfire at kahnert.de Sat Aug 18 08:10:51 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Sat, 18 Aug 2007 15:10:51 +0200 Subject: [crossfire] Summary: Next major CF project In-Reply-To: <200708181438.40840.nicolas.weeger@laposte.net> Message-ID: <20070818131051.GA19694@cthulhu.desy.de> On Sat, Aug 18, 2007 at 02:38:36PM +0200, Nicolas Weeger wrote: > - add lore, background stories, and so on. This makes the world funnier, imo Yes, I see this as a natural part of reorganizing the world. Touching each map offers lot of chances to add such information. Also the quests leading through the new regions should provide lots of background informations. > - improve monster behaviour / moving algos. Do I need to say more? ;) Same as NPC chat improvements; this is even more important. But both are missing in the list. J?rgen From kbulgrien at worldnet.att.net Sun Aug 19 23:01:29 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 19 Aug 2007 23:01:29 -0500 Subject: [crossfire] libglade GTK2 client update & questions Message-ID: <200708192301.29665.kbulgrien@worldnet.att.net> A couple of FYIs and questions: First, the gtk-v2-libglade branch has been reworked to split out the common dialogs for the metaserver, keybinding, configuration, spells, and about box into a separate dialogs.glade file. This was done to remove redundant definitions for them in the various main client window .glade files. The client now depends on having access to two separate .glade files. The command-line argument for the branch crossfire-client-gtk2 executable has changed from a single -xml_file argument to -window_xml and -dialog_xml. One or both may be modified from the command-line as in: crossfire-client-gtk2 -window_xml chthonic.glade -dialog_xml dialogs.glade Second, I have committed a new layout called chthonic.glade that is similar to the screen shot I called "big_inv" earlier on the list. Question one is this. Mark's original gtk-v2.glade sets up a screen size of 1201x1010 which for some reason shows up as taller than my screen in Glade Designer on a 1280x1024 graphic mode. I would like to alter the _default_ window size to 1275x945 for maximal horizontal space at 1280x1024 (but to allowing window frames to be grabbed), and to allow a "start bar" below the game window. KDE's "Normal" panel setting was used to pick the vertical dimension. Is there any objection to my altering the gtk-v2 layout only as pertains to default window size as it is already problematic in the horizontal dimension on 1280x1024? Question two: I do not like the "centered/justified/homogenous" look of the stat pane on the original layout. I far prefer the stats to appear in a left- justified form, more like the ...gasp... GTK1 client, or more recent chthonic.glade layout. I am curious if I stand alone on this. Question three: I propose we change the default layout for the new client to be one that is more compatible with smaller screen sizes. I do not know what format a new default should take, but I think chthonic.glade might be worth using as a seed for discussion and suggestions. I would be glad(e) to provide the effort to realize a number of suggestions if people sketch out the window layout. Lastly, I have some idea that the client could be made to support features like button bars. Glade seems to offer functionality that could let the client easily adjust to layouts that did/didn't have certain elements. I don't know how far I would go in the short term, but specific thoughts on how the GTK2 client may be improved practically may be entertained since working this is proving to be rather fun. Kevin Bulgrien From mwedel at sonic.net Sun Aug 19 23:42:03 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 19 Aug 2007 21:42:03 -0700 Subject: [crossfire] libglade GTK2 client update & questions In-Reply-To: <200708192301.29665.kbulgrien@worldnet.att.net> References: <200708192301.29665.kbulgrien@worldnet.att.net> Message-ID: <46C91B9B.8020803@sonic.net> Kevin R. Bulgrien wrote: > Question one is this. Mark's original gtk-v2.glade sets up a screen size of > 1201x1010 which for some reason shows up as taller than my screen in Glade > Designer on a 1280x1024 graphic mode. I would like to alter the _default_ > window size to 1275x945 for maximal horizontal space at 1280x1024 (but to > allowing window frames to be grabbed), and to allow a "start bar" below the > game window. KDE's "Normal" panel setting was used to pick the vertical > dimension. Is there any objection to my altering the gtk-v2 layout only as > pertains to default window size as it is already problematic in the > horizontal dimension on 1280x1024 I have no real issues with that. I can't remember exactly why I chose that resolutions as a default. I will make the comment that it is hard to really know what a persons particular layout will be (for example, I have my gnome setup so that the toolbar/panel is vertical along the left edge of the screen instead of horizontal at the bottom. Now I run at a much higher resolution, so that isn't an issue for this particular change, but if I was running at 1280x1024, then that could be annoying. But so long as the client can be reconfigured to be smaller, not a big deal there. > > Question two: I do not like the "centered/justified/homogenous" look of the > stat pane on the original layout. I far prefer the stats to appear in a left- > justified form, more like the ...gasp... GTK1 client, or more recent > chthonic.glade layout. I am curious if I stand alone on this. Doesn't make that much difference to me. I suppose it depends on the width of that actual window. But taking a quick look, I'd almost say I'd want a hybrid method. For example, on my client, I see something that is like Speed 1.05 Weapon Speed 2.40 I think I'd like the speed/weapon speed each on their half of the screen, instead of being all jumbled together, but the values that go with them close together. That is to say, something like: Speed 1.05 Weapon Speed 2.40 Instead of Speed 1.05 Weapon Speed 2.40 but that is just a preference based on size of the stats tab and visual appearance. > > Question three: I propose we change the default layout for the new client to > be one that is more compatible with smaller screen sizes. I do not know what > format a new default should take, but I think chthonic.glade might be worth > using as a seed for discussion and suggestions. I would be glad(e) to provide > the effort to realize a number of suggestions if people sketch out the window > layout. Smaller screen size has always been messy. One of the real changes needed to support smaller screen sizes is better handling in the client of reducing map size as its window gets smaller (eg, if the map window gets resized to be 600x600, then it should automatically change map size to 17x17 (600/32 is actually 18.75, but I think odd map sizes work better, as that way the player is centered). But aside from that, I'd suggest that if a default layout is chosen, then there should be dialogs/config within the client to change the layout, and of course have that stored in the gdefaults2 file (don't know if a gdefaults2-glade is needed to seperate from normal gdefaults2). In short, I should have to need to mess with command line options each time I run the client to get the layout I want. > > Lastly, I have some idea that the client could be made to support features like > button bars. Glade seems to offer functionality that could let the client > easily adjust to layouts that did/didn't have certain elements. I don't know > how far I would go in the short term, but specific thoughts on how the GTK2 > client may be improved practically may be entertained since working this is > proving to be rather fun. Not sure what a button bar is. From mwedel at sonic.net Sun Aug 19 23:51:15 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 19 Aug 2007 21:51:15 -0700 Subject: [crossfire] gtk-v2-libglade branch stable; ready for review/merge. In-Reply-To: <200708160230.38911.kbulgrien@worldnet.att.net> References: <200708160230.38911.kbulgrien@worldnet.att.net> Message-ID: <46C91DC3.7060702@sonic.net> Kevin R. Bulgrien wrote: > > It is not possible to specify the .glade file from within the Client | Configure window. > I looked at that code a bit, but have not really digested how it works if you want to > save string data (path/filename) instead of a simple numeric value. I guess the > sound_server setting is one possible example to follow, but so far I haven't quite > figured it out. The best thing to look at is probably the theme support, as that does a lot of what you probably want - scans a directory for usable entries, makes up a selection box of the different choices, etc. > 2) Possibly create a mechanism so that Client | Save Window Position could work > for multiple .glade files without blowing away the saved settings for other > layouts. Presently, if you run the client with a new layout, the Window sizing > may be broken because it will use the values set up for the previously used > layout. I guess I'm not sure how big a deal that is since I see people latching > on to a favorite and playing with it. Maybe not that big a deal. It might be nice however to store away what layout was used when the window positions were saved (maybe a line in the gwinpos), so that if I run with a different theme, it can figure that out and then use default window positions then. Otherwise, a user could find that a layout seems unusable, because wrong placement of widgets, etc, has been done (some portion resized too small to be seen, whatever). Or, and I don't know if this can be done, have something like a 'reset window positions' menu item which reset things to default, so if I do run with some new glade file and things are all out of whack, I can easily get things back to a normal state. > > 3) I wonder if the .glade files should be named to make it obvious they are > designed only for the gtk-v2 client. Perhaps so that the file name always > appears in the form gtk-v2-.glade. Ideas entertained. I'd probably instead put them all in a subdirectory that is so named, eg, glade-gtk2 or something. Also, if the only thing in that directory is glade config files, it makes things easier with the logic for the config window. IIRC, the themes for gtk2 are put in their own directory. > From mwedel at sonic.net Mon Aug 20 02:10:18 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 20 Aug 2007 00:10:18 -0700 Subject: [crossfire] improved monster AI Message-ID: <46C93E5A.2070002@sonic.net> It was brought up in another thread that monster AI needs to be improved. I think for purpose of this discussion, monster AI pertains to the monster killing/stealing/otherwise harrassing the player, not about NPC & scripting. I'd like to discuss a bit more about improvements people would like to see. I'm not 100% sure it is a major project - it may be more a minor project, but that depends on what people are doing. I say that because it could turn out to be improvements to the logic, and doing that is fairly localized. Smarter monsters may mean some maps are tougher than before, but one would not have to go through every map to have the monsters use this new intelligence - in fact, they all would use it by default which is why some would be tougher. Quick thoughts off the top of my head: - For monsters that use equipment (rings, swords, armor), they probably need to be smarter in what they pick up and use - in many cases, they may use the best based on straight values, but not look at how it affects movement, etc. They should also drop equipment they seem worthless. - Spell selection should be better - monsters are still dealt whatever spells they get, but what they decide to cast could be improved. - Monsters should better tailor their attacks to their opponents. If the player is vulnerable to cold, monster should hit it with cold more often than not if possible, and shouldn't hit fire immune characters with fire. This applies to both spells and melee/weapon attacks (but for weapon attacks, monsters don't have lots of choices). - There is already different logic in for monsters to use hit and run or circle player tactics - more monsters should be modified to use these less direct tactics, especially if they have missile weapons. Lots of maps are not designed for this however (wall to wall monsters, so until a bunch are killed, no room to move about0 - Monsters should be more careful about single row/column attacks, like arrows or bolts - there is little point casting the bolt spell if the monster can not line it up so it hits the player. For example, if in a 2 wide hallway (going north/south) with the monster along the east wall and player to the south along the west wall, there is little point for the monster to cast a bolt spell south, as unless the player moves, he won't get hit by it. - Related to point above, monsters should coordinate and/or have memory/planning. In the above example, if that monster cast the bolt spell south, then moved west and cast another bolt south, the player is now caught with no place to go. Or if there are two monsters at the top of the hall, after the first one casts the bolt spell, the second one sees it and does the same. Likewise, some form of planning for monsters like 'hit player with weakness to fire. Then hit them with fireball' type of thing. Right now, for every action the monster goes, it newly figures out what to do, which is largely random - do I hit them with a spell or bow (random chance of each). What spell do I hit them with (random chance of each), etc. If monsters had 5 or 6 tick plans what to do, could be much more deadly. - Path to player logic to better find players/not get stuck would be good. This seems to me at least less and issue, because there is usually few ways for the player to hit the monster if the monster can't hit the player, but having monsters be smart enough to circle around players, etc, would be really nice From kbulgrien at worldnet.att.net Mon Aug 20 07:43:24 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Mon, 20 Aug 2007 07:43:24 -0500 Subject: [crossfire] libglade GTK2 client update & questions In-Reply-To: <46C91B9B.8020803@sonic.net> References: <200708192301.29665.kbulgrien@worldnet.att.net> <46C91B9B.8020803@sonic.net> Message-ID: <200708200743.24447.kbulgrien@worldnet.att.net> > > Not sure what a button bar is. > Not 100% sure what it "should" be, but dxclient had iconified buttons that could be used to cast spells, and I see that jxclient has them too. jxclient seems to prefer such buttons for inventory management also, though I probably wouldn't suggest that as it seems much more difficult to pull off as a simple face-lift. I suppose what I mostly had in mind was along the lines of a graphical "keybinding" interface for the folk that use a mouse more. The thing is, I'm not sure I like what dxclient/jxclient do in that they provide buttons for all spells whether or not you know them. Generic button bars could be setup by spell path to give pre-defined layouts now that I think about it. Personally, I would likely not use buttons for spell casting in general, but I would probably like them to give quick visual access to ready or use functions that are done infrequently and where a visual icon would help me locate the function. On the other hand, my son would use that since he isn't a keyboard adept yet. I can tell him keybindings I set up for him, and he learns, but I see him not using spells a lot because at 4, the letters on the keyboard are still a bit opaque to him - not that 4 is our target audience, but, it may still be an indicator of how different people might want to play. I'm not sure about this. I like keyboard-based macros, but I think it might be an area that people generally have difficulty: considering so much these days is done with graphical interfaces. In the end, though, I would want to be sure the client code would be able to effectively ignore panels that aren't present... not something that seems difficult to do using libglade. Kevin From mwedel at sonic.net Mon Aug 20 12:53:46 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 20 Aug 2007 10:53:46 -0700 Subject: [crossfire] Vote: Next major project Message-ID: <46C9D52A.10906@sonic.net> We've pretty much figured out the choice of major projects, now to decide which one to vote on. Like source control vote, we will do a ranked choice vote. Brief list of choices below: A) Redo races & classes B) Re-organize the world into different difficulty areas C) Make a new beginner area/town D) Slow down combat so one can use tactics E) Balance magic & combat skills so they are more equal F) Rebalance spells, so meaningful from level 1 to 100 G) Add class guild halls H) Re-do/fix/improve alchemy I) Improve party support J) Make AC into dodge, with most armor giving AC penalty K) Add/improve lore L) Improve NPC chat To make processing easy, please follow this sample ballot: --- Start Here --- Developer: yes/no - if yes, please include sourceforge name A 6 B 3 C 9 D 4 E 2 (and so on for rest of choices). --- End Here --- This is open to voting by everyone that plays crossfire, so please redistribute this message. Please send votes to me, mwedel at sonic.net, with same subject. Not positive when voting will finish, but probably a week or two (I realize some people may be on vacation, etc, during that time period, but that is probably a small enough number not to be too significant. And other question then becomes how long does one keep a vote open to cover everyone. The information below is only first working draft. There is also information at http://wiki.metalforge.net/doku.php/dev_todo:cf2.0:roadmap but I'm not 100% sure that the proposals will follow the detail stuff written there. ---- A) Redo classes & races so their is more difference in them - stat bonuses, skills, special per race or per class items. As part of this, I think different versions of the same skill is needed (apprentice/journeyman/master level skills for example) - I say that should be part of this because the different versions of a skill would be a major way to redo the classes & races. Maybe also change the max stat cap also. B) Re-organize the world so there are different areas for different levels (level 1-10 area, level 11-20 area, etc). Add a main quest(s) that would lead a character through these areas up to high level C) New beginner area - perhaps start them off on their own island, and one way exit once you leave. Have this beginner map be full of tutorial maps, easy to use places, etc. If the above point is done (reorganize the world), this may then fall into a subproject of that, or be a precursor if done first. D) Slow down combat, so there is time to use strategy, coordinate, etc. Part of this is to reduce/eliminate monster vs player hp disparity. this may also help party play. E) Balance magic and combat skills, so at most all levels, they are of equal power/killing potential (this is not to say that some tactics may be more/less effective at some monsters). Point being a level 50 evoker should have same ability to kill creatures as a level 50 melee weapon user. Other skills should be balanced/fixed so it is reasonably possible to get to a decent level in all of them, and having a decent level is important (a level 60 chest may demand level 60 search, disarm trap, and lockpicking) F) Rebalance spells - highest level spell is under 30 - spells should cover the entire range of level 1-100 (not necessarily 100 different spells, but there should be a level 100 spell for each skill out there). This point may be related to #5 above, as if combat is redone, spell potency would also have to get tuned. G) Add class guilds - basically, your best skill determines what guild(s) you can belong to - get certain benefits from those guilds not otherwise available. H) Redo/clean up alchemy and related item creation skills - in a sense, every item in the game should be creatable by characters (I'd exclude true artifacts/map special items - those should be of legendary nature and created in a bygone time, and details and elements of their creation long lost). But characters should be able to create all the potions, most rings, armor, weapons, etc. I) Improve party support - ideas talked about are more party quests, more party spells, having more detailed information about current health status of other party members, perhaps other J) Move AC into a dodge attribute, with most armor giving dodge penalty, and some skills giving dodge bonus - this may tie in with point #4 (slow down combat). Doing this requires adjusting all the in-game armor, and likely adjustments to combat rolls. Also, dodge and wc should go up in value to denote they are better, not down like ac & wc currently do. K) With crossfire, there is a lore field that can be used to hold information about creatures, objects, etc, but this is infrequently used. As such, most readable materials found within the game are pretty useless. If lore was used, then this readable information would be useful, and could also provide a way to have hooks for quests or dungeons. L) NPC chat right now really isn't very good. The main reason is that there is no way to know how a conversation should/will progress - the NPC itself has no state to where it is in the conversation, and no clue is given to what keywords might yield more conversation. Would suggest that all NPC msg stuff should be updated with the tags that the clients now support - maybe even add a new 'special' tag that denotes conversation point. In this way, the client could display them in some way to make it easier (perhaps even clicking on the word). Secondarily, it would be nice if NPC conversation had some state - right now, for any given world, there will be a set response, and if you know the right word, you can get deep into the conversation - being able to chain same word to different responses based on state would also improve conversation logic. From nicolas.weeger at laposte.net Mon Aug 20 17:16:44 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 21 Aug 2007 00:16:44 +0200 Subject: [crossfire] Vote: Next major project In-Reply-To: <46C9D52A.10906@sonic.net> References: <46C9D52A.10906@sonic.net> Message-ID: <200708210016.44390.nicolas.weeger@laposte.net> > easier (perhaps even clicking on the word). Secondarily, it would be nice > if NPC conversation had some state - right now, for any given world, there > will be a set response, and if you know the right word, you can get deep > into the conversation - being able to chain same word to different > responses based on state would also improve conversation logic. I guess you missed the notice :) NPCs *CAN* have dialog state, thanks to Yann's Python script. Check the /maps/python/CFDialog.py class, or the wiki at http://wiki.metalforge.net/doku.php/cfdialog Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] From yann.chachkoff at myrealbox.com Tue Aug 21 02:15:41 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Tue, 21 Aug 2007 09:15:41 +0200 Subject: [crossfire] Vote: Next major project In-Reply-To: <46C9D52A.10906@sonic.net> References: <46C9D52A.10906@sonic.net> Message-ID: <200708210915.42116.yann.chachkoff@myrealbox.com> Le lundi 20 ao?t 2007, Mark Wedel a ?crit : > We've pretty much figured out the choice of major projects, now to decide > which one to vote on. Like source control vote, we will do a ranked choice > vote. Brief list of choices below: I find rather strange that monster AI didn't get included in that list... > K) With crossfire, there is a lore field that can be used to hold > information about creatures, objects, etc, but this is infrequently used. > As such, most readable materials found within the game are pretty useless. > If lore was used, then this readable information would be useful, and could > also provide a way to have hooks for quests or dungeons. > More generally, add more background information to the game, not only stuff in the "lore" tags. > L) NPC chat right now really isn't very good. *sigh* From the header of maps/python/CFDialog.py: # What is this about ? #======================= # This is a small set of utility classes, to help you creating # complex dialogs. It is made for those who do not want to # bother about complex programming, but just want to make a few # dialogs that are better than the @match system used in the # server. # # How to use this. #======================= # First, you need to import DialogRule and Dialog classes. Add the # following line at the beginning of your script: # from CFDialog import DialogRule, Dialog # Then, you can go to the dialogs themselves. A dialog is made of # several rules. Each rule is made of keywords, preconditions, # postconditions, and answers. # - Keywords are what the rule will be an answer to. For example, if # you want a rule to be triggered when the player will say "hi", # then "hi" is the keyword to use. You can associate more than a # keyword to a rule by concatenating them with the "|" character. # Finally, "*" is a special keyword that means: "match everything". # "*" is useful to provide generic answers. # - Answers are what will be said when the rule is triggered. This is # what the NPC replies to the player. Answers are stored in a list. # When there is more than one answer in that list, one will be # selected at random. # - Preconditions are flags that must match for the rule to be triggered. # Each precondition has a name and a value. The default value of a # precondition is "0". The flags are stored into each player, and will # survive between gaming sessions. They are useful to set the point in # a dialog reached by a player - you can see those as an "NPC memory". # All conditions must have a name and a value. The ":" and ";" characters # are forbidden. For a rule to be triggered, all the player's flags should # match the preconditions. If you give "*" as the value for a precondition, # it means that there is no need to match it. # A precondition is a list in the form: [key, value]. All preconditions # are stored in a list. # - Postconditions are the status changes to apply to the player's # conditions after the rule has been triggered. Their format is similar to # preconditions. A value of "*" means that the condition will not be touched. # # Once you have defined your rules, you have to assemble them into a dialog. # Each dialog involves somebody who triggers it, somebody who answers, and # has a unique name so it cannot be confused with other dialogs. # Typically, the "one who triggers" will be the player, and the "one who # answers" is an NPC the player was taking to. You are free to chose whatever # you want for the dialog name, as long as it contains no space or special # characters, and is not used by another dialog. # You can then add the rules you created to the dialog. Rules are parsed in # a given order, so you must add the most generic answer last. # # A simple example #================= # I want to create a dialog for an old man. If I say "hello" or "hi" for the # first time, grandpa will greet me. If I say it for the second time, he'll # grumble (because he's like that, you know :)). I also need a generic answer # if I say whatever else. # In this example, the player is stored in 'player', and the old man in 'grandpa'. # What the player said is in 'message'. # ## Dialog creation: # speech = Dialog(player, grandpa, "test_grandpa_01") # ## The first rule is the "hello" answer, so we place it at index 0 of the ## rules list. The precondition is that we never said hello before. ## The postcondition is to mark "hello" as "1", to remember we already ## greeted grandpa. # prer = [["hello","0"]] # postr = [["hello", "1"]] # rmsg = ["Hello, lad!","Hi, young fellow!","Howdy!"] # speech.addRule(DialogRule("hello|hi", prer, rmsg, postr),0) # ## The second rule is the answer to an hello if we already said it before. ## Notice that we used "*" for the postcondition value, meaning that we ## are leaving it as it is. # prer = [["hello","1"]] # postr = [["hello", "*"]] # rmsg = ["I've heard, you know, I'm not deaf *grmbl*"] # speech.addRule(DialogRule("hello|hi", prer, rmsg, postr),1) # ## And finally, the generic answer. This is the last rule of the list. ## We don't need to match any condition, and we don't need to change them, ## so we use "*" in both cases this time. # prer = [["hello","*"]] # postr = [["hello", "*"]] # rmsg = ["What ?", "Huh ?", "What do you want ?"] # speech.addRule(DialogRule("*", prer, rmsg, postr),2) # See also http://wiki.metalforge.net/doku.php/cfdialog It is always refreshing to see how one's work is appreciated :). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070821/593a6af0/attachment.pgp From kbulgrien at worldnet.att.net Tue Aug 21 03:42:03 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Tue, 21 Aug 2007 03:42:03 -0500 Subject: [crossfire] Vote: Next major project In-Reply-To: <200708210915.42116.yann.chachkoff@myrealbox.com> References: <46C9D52A.10906@sonic.net> <200708210915.42116.yann.chachkoff@myrealbox.com> Message-ID: <200708210342.03474.kbulgrien@worldnet.att.net> > > L) NPC chat right now really isn't very good. > *sigh* > > From the header of maps/python/CFDialog.py: > > See also http://wiki.metalforge.net/doku.php/cfdialog > > It is always refreshing to see how one's work is appreciated :). From the documentation indicated, I would not easily know how to make a map that uses this since I do not know squat about using python scripts in maps. The code documentation and wiki documentation is too light, and could show an example of an NPC definition that uses the script example. It would be nice not to have to go digging through other documents to find out how to do python scripting in general just to get started. If that were the case, I'd probably make use of what I did know (even if that is only a lazy slob's excuse). It would be better to show a complete example, and reference the docs that discuss python scripting as it relates to map editing as a way of encouraging the reader to broaden their understanding of the available tool set. The feature should also get mention in the server documents where NPC conversations are discussed. Some ideas: server/*/doc/Developers: - Section 'I. NPC's Speak out' in file "objects". - Item #5 in the suggestion section of the "mapguide" - Mention in "map.dox" and/or "map-technical". I am not suggesting shotgun style documentation, but I am suggesting an appropriate amount of cross-linking of information so that map writing will actually realize the benefits of these features. Presently I think it is difficult for a map developer to know how to use the facility. With some mention, cross-linking, and a better example, more than likely the author's work _will_ be far better appreciated, and maybe even used. Kevin Bulgrien From yann.chachkoff at myrealbox.com Tue Aug 21 16:48:35 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Tue, 21 Aug 2007 23:48:35 +0200 Subject: [crossfire] CFDialog Documentation (was Re: Vote: Next major project) In-Reply-To: <200708210342.03474.kbulgrien@worldnet.att.net> References: <46C9D52A.10906@sonic.net> <200708210915.42116.yann.chachkoff@myrealbox.com> <200708210342.03474.kbulgrien@worldnet.att.net> Message-ID: <200708212348.35478.yann.chachkoff@myrealbox.com> Le Tuesday 21 August 2007 10:42:03 Kevin R. Bulgrien, vous avez ?crit?: > > > L) NPC chat right now really isn't very good. > > > > *sigh* > > > > From the header of maps/python/CFDialog.py: > > > > > See also http://wiki.metalforge.net/doku.php/cfdialog > > > > It is always refreshing to see how one's work is appreciated :). > > From the documentation indicated, I would not easily know how to make > a map that uses this since I do not know squat about using python > scripts in maps. > Documentation reference: - "How do I hook a script to an object", from server/doc/Developers/python - Same title, from http://wiki.metalforge.net/doku.php/cfpython Of course the CFDialog does not explain how to write Python scripts, since this is already documented elsewhere. And no, the CFDialog document doesn't explain what an NPC is, or why they are answering using speech; for what matters, all this is supposed known from the rest of the documentation. > The code documentation and wiki documentation is too > light, and could show an example of an NPC definition that uses the > script example. > See above. For practical examples of NPCs using scripts to manage "say" events, see for example maps/scorn/shops/IPO_scorn. Various scripted map examples have been in existence since 2001 in the maps. > It would be nice not to have to go digging through > other documents to find out how to do python scripting in general > just to get started. > There is no "digging" needed. If you had done your homework, you'd have found that it is clearly explained in a single document, which can hardly get a more explicit name ("doc/Developers/python" and "cfpython" on the Wiki; it is also the first entry found when searching for "python" on the Wiki search engine.). Now, if typing "python" in the Wiki search textbox is "digging through documents", then maybe we should just trash the whole content of the doc/ directory and from the wiki, since it is probably too difficult to find anything useful in it. > If that were the case, I'd probably make use of > what I did know (even if that is only a lazy slob's excuse). It would > be better to show a complete example, and reference the docs that > discuss python scripting as it relates to map editing as a way > of encouraging the reader to broaden their understanding of the > available tool set. > The example given in the wiki is a *complete* script. It is expected that the reader will be clever enough to read the related Python page (which is *also* linked from the CFDialog wiki page) if he/she has trouble for hooking scripts. There is a complete example, there are several scripted NPCs in the maps, and there is a rather detailed description of what CFDialog does. What the heck was I supposed to add ? A youtube video of clay characters visually explaining how to type "P.Y.T.H.O.N" using the keyboard ? > Presently I think it is difficult for a map developer to know how to use the facility. > For a map-maker that doesn't even bother to read the provided docs, yes, it is. > With some mention, cross-linking, and a better example, more than likely > the author's work _will_ be far better appreciated, and maybe even used. > A *better* example ? Fido Damn It(tm), the example is a two-level-deep "hello world" style dialog ! What by the gods am I supposed to find as a "better" example for a class used to provide scripted *dialogs* ? For reference, the example provided in the Wiki contains 20 lines of code (the rest of the content being comments). 6 of those are either required imports or variable definitions. This leaves 14 lines that are specific to the use of CFDialog. Should I conclude that 14 lines is already too complex for a two-level dialog with three different answer branches ? Was I expected to make one-liner examples only ? Cross-linking ? More mention ? Do you realize that a search on "dialog" on the Wiki returns the CFDialog documentation as the *first* result ? Same for "speech" ? That it is the 5th result on "npc script" ? The only one on "npc answer" ? The first one on "npc answer" ? Or maybe "CFDialog" is not an explicit enough name ? Maybe I should have named "doc/Developers/python" "this-is-the-doc-related-to-scripting-stuff-using-python-use-a-text-editor-to-open" ? I'm sorry if I'm feeling my temper on this, but that's really BS. Any 2-minutes search on the Wiki would have told you what you needed to know about the extension alongside with an example script (heck, I didn't even know which keywords would have worked to find the cfdialog page - I just tried the first words coming into my mind on that topic !). Now, if even a search in the Wiki is asking too much to a map-maker, then maybe we should plainly ask the question of the pertinence of maintaining a documentation wiki in the first place. From kbulgrien at worldnet.att.net Tue Aug 21 18:20:46 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Tue, 21 Aug 2007 18:20:46 -0500 Subject: [crossfire] CFDialog Documentation (was Re: Vote: Next major project) In-Reply-To: <200708212348.35478.yann.chachkoff@myrealbox.com> References: <46C9D52A.10906@sonic.net> <200708210342.03474.kbulgrien@worldnet.att.net> <200708212348.35478.yann.chachkoff@myrealbox.com> Message-ID: <200708211820.47041.kbulgrien@worldnet.att.net> > I'm sorry if I'm feeling my temper on this, but that's really BS. Any > 2-minutes search on the Wiki would have told you what you needed to know > about the extension alongside with an example script (heck, I didn't even > know which keywords would have worked to find the cfdialog page - I just > tried the first words coming into my mind on that topic !). Now, if even a > search in the Wiki is asking too much to a map-maker, then maybe we should > plainly ask the question of the pertinence of maintaining a documentation > wiki in the first place. The full-auto, .50 cal. reply does nothing for the project. I am sorry to have offended you. Whether you see it or not, there _is_ a wall that people face when they are not the author's of a feature. Your complaint that people didn't know about the feature proves something, and I do know exactly what I am up against when I try to do new things in crossfire. I did, you know, just figure out autoconf/automake when other developers are too lazy to do it, so I could do the libglade conversion, so this is not at about being willing or not willing to dig, but it is about facilitating people at overcoming barriers with discriminate redundancy, which is a known quality of good training. Two minutes is sufficient to drive most people away from something if they know an easier way. match is easier. All your points about resources are good. They will help if I feel like taking on what I firmly believe will help people use the feature. Whether I did it correctly or not might be in question, but the motive behind what and why I wrote is for the good of the project, and not to knock a skilled and valued individual. Please take some time to try to believe that. Kevin From kbulgrien at worldnet.att.net Wed Aug 22 01:48:44 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Wed, 22 Aug 2007 01:48:44 -0500 Subject: [crossfire] CFDialog Documentation (was Re: Vote: Next major project) In-Reply-To: <200708211820.47041.kbulgrien@worldnet.att.net> References: <46C9D52A.10906@sonic.net> <200708212348.35478.yann.chachkoff@myrealbox.com> <200708211820.47041.kbulgrien@worldnet.att.net> Message-ID: <200708220148.44532.kbulgrien@worldnet.att.net> On Tuesday 21 August 2007 18:20, Kevin R. Bulgrien wrote: > > I'm sorry if I'm feeling my temper on this, but that's really BS. Any > > 2-minutes search on the Wiki would have told you what you needed to know > > about the extension alongside with an example script (heck, I didn't even > > know which keywords would have worked to find the cfdialog page - I just > > tried the first words coming into my mind on that topic !). Now, if even a > > search in the Wiki is asking too much to a map-maker, then maybe we should > > plainly ask the question of the pertinence of maintaining a documentation > > wiki in the first place. > > The full-auto, .50 cal. reply does nothing for the project. I am sorry > to have offended you. Whether you see it or not, there _is_ a wall that > people face when they are not the author's of a feature. Your complaint > that people didn't know about the feature proves something, and I do know > exactly what I am up against when I try to do new things in crossfire. I > did, you know, just figure out autoconf/automake when other developers are > too lazy to do it, so I could do the libglade conversion, so this is not > at about being willing or not willing to dig, but it is about facilitating > people at overcoming barriers with discriminate redundancy, which is a > known quality of good training. Two minutes is sufficient to drive most > people away from something if they know an easier way. match is easier. > All your points about resources are good. They will help if I feel like > taking on what I firmly believe will help people use the feature. Whether > I did it correctly or not might be in question, but the motive behind what > and why I wrote is for the good of the project, and not to knock a skilled > and valued individual. Please take some time to try to believe that. > > Kevin And after about 3.5 hours of digging... though honestly about an hour was lost to getting a server compiled, all I have to add is this: http://wiki.metalforge.net/doku.php/cfdialog It will _not_ take the next guy 2-3 hours. Kevin From kbulgrien at worldnet.att.net Wed Aug 22 02:01:16 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Wed, 22 Aug 2007 02:01:16 -0500 Subject: [crossfire] CFDialog Documentation (was Re: Vote: Next major project) In-Reply-To: <200708220148.44532.kbulgrien@worldnet.att.net> References: <46C9D52A.10906@sonic.net> <200708211820.47041.kbulgrien@worldnet.att.net> <200708220148.44532.kbulgrien@worldnet.att.net> Message-ID: <200708220201.17040.kbulgrien@worldnet.att.net> Yann, One more belated add-on to this painful thread... Thank-you most graciously for your efforts. Once again, if the original reply was rude, ungracious, or otherwise offensive, I most certainly ask for your forgiveness and thank you for motivating to learn how to use Crossfire python scripts for the first time ever. Sincerely, Kevin From kbulgrien at worldnet.att.net Wed Aug 22 06:53:16 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Wed, 22 Aug 2007 06:53:16 -0500 Subject: [crossfire] Vote: Next major project In-Reply-To: <200708210016.44390.nicolas.weeger@laposte.net> References: <46C9D52A.10906@sonic.net> <200708210016.44390.nicolas.weeger@laposte.net> Message-ID: <200708220653.16465.kbulgrien@worldnet.att.net> On Monday 20 August 2007 17:16, Nicolas Weeger wrote: > > easier (perhaps even clicking on the word). Secondarily, it would be nice > > if NPC conversation had some state - right now, for any given world, there > > will be a set response, and if you know the right word, you can get deep > > into the conversation - being able to chain same word to different > > responses based on state would also improve conversation logic. > > I guess you missed the notice :) > NPCs *CAN* have dialog state, thanks to Yann's Python script. Check > the /maps/python/CFDialog.py class, or the wiki at > http://wiki.metalforge.net/doku.php/cfdialog > > Nicolas The wiki is out of date, so if Mark was looking at the wiki, it is quite understandable that it was on the vote list IMO. It still contains TODO entries that appear to be addressed by CFDialog: http://wiki.metalforge.net/doku.php/dev_todo I'd delete them, but I don't know if all three points are completed. I can tell that probably two of them are now that I've gotten a CFDialog example to work. The only part of item: Technical Better NPCs - Make NPCs smarter (memory, track conversation instead of just matching a phrase) not implemented might be "track conversation instead of just matching a phrase". Player says: why do I always have to say hello anyway? grandpa says: What ? Player says: hello grandpa says: I've heard, you know, I'm not deaf *grmbl* And that statement is based on: http://wiki.metalforge.net/doku.php/dev_todo:better_npcs Which is also out of date and includes: The in game Non Player Characters could be smarter. * Reconize if you are responding to a question that they just asked (yes/no) * Dynamicly match wording of the phrases said by players * Remember details about a player?s prior conversations CFDialog definitely supports the third point because the conversation state is stored in the player's file. The first point is probably programmatically achievable with CFDialog if I understand it right, and I'm not 100% sure that the second point means. Kevin Bulgrien From nicolas.weeger at laposte.net Wed Aug 22 15:45:55 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 22 Aug 2007 22:45:55 +0200 Subject: [crossfire] Vote: Next major project In-Reply-To: <46C9D52A.10906@sonic.net> References: <46C9D52A.10906@sonic.net> Message-ID: <200708222245.58504.nicolas.weeger@laposte.net> > A) Redo races & classes > B) Re-organize the world into different difficulty areas > C) Make a new beginner area/town > D) Slow down combat so one can use tactics > E) Balance magic & combat skills so they are more equal > F) Rebalance spells, so meaningful from level 1 to 100 > G) Add class guild halls > H) Re-do/fix/improve alchemy > I) Improve party support > J) Make AC into dodge, with most armor giving AC penalty > K) Add/improve lore > L) Improve NPC chat I'll also note that IMO K) should take place when doing B), and DEFJL should probably be done before B too - B means basically "rework all maps", so we should do "rework all maps, add lore, adjust to new combat system" instead of multiple map reworking. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070822/25633a76/attachment.pgp From nicolas.weeger at laposte.net Wed Aug 22 15:56:29 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 22 Aug 2007 22:56:29 +0200 Subject: [crossfire] Vote: Next major project In-Reply-To: <200708210342.03474.kbulgrien@worldnet.att.net> References: <46C9D52A.10906@sonic.net> <200708210915.42116.yann.chachkoff@myrealbox.com> <200708210342.03474.kbulgrien@worldnet.att.net> Message-ID: <200708222256.32263.nicolas.weeger@laposte.net> > The feature should also get mention in the server documents where NPC > conversations are discussed. > > Some ideas: > > server/*/doc/Developers: > > - Section 'I. NPC's Speak out' in file "objects". > - Item #5 in the suggestion section of the "mapguide" > - Mention in "map.dox" and/or "map-technical". Fix it, then? > I am not suggesting shotgun style documentation, but I am suggesting an > appropriate amount of cross-linking of information so that map writing will > actually realize the benefits of these features. Presently I think it is > difficult for a map developer to know how to use the facility. Your ideas to improve the documentation are welcome. > With some mention, cross-linking, and a better example, more than likely > the author's work _will_ be far better appreciated, and maybe even used. Feel free to expand the wiki, that's what it is for. Do you have any idea how frustrating it is to write doc (that no one actually reads most of the time)? How long it takes to correctly cross-link between documents? And just have people say "I can't find" when they obviously didn't even bother to search? Feedback on the result is appreciated, but people are expected to actually try to look first, to dig slightly (and searching is digging slightly, IMO). People wanting to write maps can also ask on the list, on the forum, on the wiki, on irc, ingame. I'll also restate what I said some time ago: I volunteer to write Python scripts for people provided they specify exactly what they really want and they *ACTUALLY* *NEED* it *NOW* (I'd fed up with writing stuff no one ever uses just because "I'd be nice to have xxx"). Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070822/b4efebb3/attachment.pgp From kbulgrien at worldnet.att.net Wed Aug 22 19:52:30 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Wed, 22 Aug 2007 19:52:30 -0500 Subject: [crossfire] Vote: Next major project In-Reply-To: <200708222256.32263.nicolas.weeger@laposte.net> References: <46C9D52A.10906@sonic.net> <200708210342.03474.kbulgrien@worldnet.att.net> <200708222256.32263.nicolas.weeger@laposte.net> Message-ID: <200708221952.30176.kbulgrien@worldnet.att.net> > Feedback on the result is appreciated, but people are expected to actually try > to look first, to dig slightly (and searching is digging slightly, IMO). > People wanting to write maps can also ask on the list, on the forum, on the > wiki, on irc, ingame. I did. That's why I wrote, and I stand by my assertion, though perhaps a smiley on the last sentence or two might have helped show I was not griping. > I'll also restate what I said some time ago: I volunteer to write Python > scripts for people provided they specify exactly what they really want and > they *ACTUALLY* *NEED* it *NOW* (I'd fed up with writing stuff no one ever > uses just because "I'd be nice to have xxx"). If you think this issue is because I wanted someone to do my work for me, it isn't. I think both of you have got a wrong idea about this. I didn't need or want CFDialog, but it was interesting when I read about it because I had no clue it existed, and I'd been working on an NPC issue off and on, banging my head (and documenting) on the broken match code. I had trouble with having a clue where to begin with CFDialog, and did, by the way, see the stuff on the wiki, and still had trouble, so, even though I didn't need it for myself, figured if the work was to be appreciated, the non-CF Python people out there might need a bit more help in the map side of the example. Did you look at how little was needed to get what was suggested? I made the change, but it took hours, just as I figured it would. I volunteered to figure it out for the project last night and document how easy it is to use once you have been given a complete example, and to prove to myself that I hadn't slipped a cog when the suggestion was made. It would have taken someone else less than half an hour probably. The suggestion was legitimate and the reply was completely out of control. Though negatively motivated to do it, I am glad to have introduced myself to the scripting side of the system, because I like scripting myself, but in fact, it is unlikely I'll be doing maps at the moment as I've been quite consumed by other things. Kevin