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>