From leaf at real-time.com Thu Apr 1 14:13:47 2010 From: leaf at real-time.com (Rick Tanner) Date: Thu, 01 Apr 2010 14:13:47 -0500 Subject: [crossfire] Flash based Crossfire Client Message-ID: <4BB4F06B.9010000@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, Great news! I've been making substantial progress with building a Flash based Crossfire client based of the GTK-v2 client. Most of the work was handled by this product, http://labs.adobe.com/technologies/alchemy/ The test platforms of Windows XP Home/Pro, Windows 7 Pro, Mac OS X 10.6.3 have shown great promise. I hope to have a beta available soon! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLtPBrhHyvgBp+vH4RAm7SAJ4pe4ebZ+DOu4/AKqkvUsQDNzR7AwCg+AKB OjPUu+jbHGagAQ0vtgrz1rM= =G86Y -----END PGP SIGNATURE----- From nicolas.weeger at laposte.net Thu Apr 1 14:47:29 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 1 Apr 2010 21:47:29 +0200 Subject: [crossfire] Flash based Crossfire Client In-Reply-To: <4BB4F06B.9010000@real-time.com> References: <4BB4F06B.9010000@real-time.com> Message-ID: <201004012147.35439.nicolas.weeger@laposte.net> Hello. > I've been making substantial progress with building a Flash based > Crossfire client based of the GTK-v2 client. > > Most of the work was handled by this product, > http://labs.adobe.com/technologies/alchemy/ That's nice! On my side I've been hacking the C code to make a library that can be called using C# and the .NET platform, so far it works nicely too (spending three years in a .NET shop does influence one, after all). So I could probably easily expose webservices (easy enough to do in C#), which could be used for client-server communication. Unless I'm mistaking, Flex makes it easy to call such services, so hopefully that could simplify a lot the protocol, by using full typed structures defined via a WSDL. An addict friend is busy writing a Silverlight client, I should have more information on his progress in a few days. Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100401/e5cd9224/attachment.pgp From brenlally at gmail.com Fri Apr 2 08:35:12 2010 From: brenlally at gmail.com (Brendan Lally) Date: Fri, 2 Apr 2010 14:35:12 +0100 Subject: [crossfire] [CF-maps] Sprite Recolouring In-Reply-To: <4BB579E9.3040303@sonic.net> References: <20100402014626.3d50f06d@angmar> <4BB579E9.3040303@sonic.net> Message-ID: <20100402143512.6ffe5f6e@angmar> On Thu, 01 Apr 2010 22:00:25 -0700 Mark Wedel wrote: > On 04/ 1/10 05:46 PM, Brendan Lally wrote: > > > > > 1) Are recolours worth adding as a way to increase variety of NPCs? > > For NPC's, I'm not quite sure about. However, for PC's, this could > certainly be interesting (provided we have a way for players to > choose this). But I'd also say that more diversity is seldom a bad > thing. I started off with NPCs for two reasons: 1) there are a lot more of them than there are players 2) they can be changing them in the map files requires nothing more than using sed appropriately. I was also looking at creating the png file directly in the arch/ folder, so that none of the server-client interaction was affected. I'll carry on with writing some C code to handle palette extraction and substitution, since if it isn't used, it may form the basis of a client patch if it is decided the client should redraw PNGs. What you are describing now is potentially much more powerful, although also more complex. I've copied in the main CF dev list because that is more a server-client discussion. > > 2) does the answer to question 1 vary depending on how they are > > implemented? (lots of different PNG files, or a script to rewrite > > the palette entries of a single png file, maybe as part of the > > collect step) > > Would it/how hard would it be for the client to do this coloring? > Yes, some mechanism to convey this extra information would be needed, > but on the plus side it means that the client doesn't have to > download a bunch of images that are the same except for a different > color palette. Also, depending on how this is done, it actually > provides for a lot more potential images (realistically, there is > probably some upper limit of number of different colored versions of > the same image you want, but if in the client you convey a 256 color > base (3/3/2 bit rgb values let say), and have some way to specify > that in the arch, you now provide a huge number of possibilities. > And if you want to let the full 24 bit values in (figuring extra few > bytes of bandwidth is not an issue), you now have endless colors. I think there are several possible approaches here: 1) a different face number for each image. => This involves very little change to the server/client interaction, since they are just more face numbers. However it is inefficient, because the image data is sent each time, and the number of faces potentially spirals out of control. 2) a palette number associated with each face, so that the palettes are sent separately => this is more efficient than 1, and less so than 3. You also would need to extend the map2 command to send the palette varient. => the least distruptive way to do this would probably be to have a 5 byte variation on the image information, so that the options then become: 2 bytes: This is only the face number. 3 bytes: [|] 4 bytes: 5 bytes: there would also need to be some either some extension to image2/creation of image3 in order to send the palette variations ahead of time, or a separate palette command Client side, the clients would need to hold the alternate PLTE sections of the png files and substitute them in depending on the palette variation they are sent. This could be quite quick if the variations are stored in an array associated with the face but it would mean a fair bit of custom PNG mangling. For the C client, this shouldn't be too bad, I don't know what that would be like for 3) Try to send the individual colour substitutions. While this would be potentially more efficient, it also causes a question of how to store them sensibly, I can't think of a coherent design for this at the moment. > This clearly changes the logic for the client - it would need to > color them real-time in that case (for 24 bit values). Conceivably, > for 8 bit values, it could just set up an array and fill that in as > it actually needs, and even in worse case, on modern systems, > probably not a high burden on memory (and if done on the client, the > client could perhaps choose not to even do that coloring to save > memory or reduce the palette to 16 colors or something). > > But I have no idea how hard it would be to do this on the client - > I would suspect that some form of standard for the images would be > needed. Yes, I'd suspect at a minimum, the existing images would need to be re-indexed less efficiently (so that for example colours 1-10 are hair colours, with 1 being the highlight colour through to 10 being the darkest shadow in the hair. 11-20 skin tones 20-25 facial features (nose, eyes, mouth) 26-35 torso 36-45 lower body 46-50 feet/shoes 51-60 weaponry (if held) 61-70 headwear and so on. Not many images can conform to something like that currently, and it would bloat the PNG files to include what would be in many cases duplicate colours (eg, the blue of a cloak may be the blue of the eyes, they would need to be different colours in the PNG file in order to recolour one without getting purple eyes because a cloak changed colour). The PNG spec does permit duplicate colours so that isn't a problem, but it probably does need someone with artistic talent (rather than an ability to play with some sliders in the gimp) to handle it. Also there would probably need to be a policy regarding RGB png files (different to colourmapped ones, which have a defined palette) somewhere around 95% of the existing images are colourmapped, but there are also over 100 RGB images (and a number of greyscale images, which are still hanging around). > > 3) If they are added, should there be some guidelines about > > where they will tend to be used? (eg, light blues are > > considered fashionable in navar, greens in darcap, etc) > > I don't know. At some level, it could be handy to remember that I > talked to the red courier in navar for quest information, and he is > the one I should return to - so having a rainbow in each city makes > it visually easier to identify the one you need to talk to. I was thinking also in terms of world design here, so saying that the colour of the imperial post office is yellow (say), therefore all their employees will be wearing yellow uniforms (rather than looking like everyone else on the street). Brendan. From leaf at real-time.com Fri Apr 2 13:01:47 2010 From: leaf at real-time.com (Rick Tanner) Date: Fri, 02 Apr 2010 13:01:47 -0500 Subject: [crossfire] Flash based Crossfire Client In-Reply-To: <4BB4F06B.9010000@real-time.com> References: <4BB4F06B.9010000@real-time.com> Message-ID: <4BB6310B.1030601@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I've been making substantial progress with building a Flash based > Crossfire client based of the GTK-v2 client. Just to clarify.. yes; this was 100% April Fools "joke" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLtjELhHyvgBp+vH4RAqTJAJ4xH+lxqD+GJ+eNCQel6i/ocCyCNwCg1JLr bHE2odEvAqFK62Gh/e4Zy9c= =eTwX -----END PGP SIGNATURE----- From 2c93e8f1 at gmail.com Sun Apr 4 23:13:04 2010 From: 2c93e8f1 at gmail.com (David McIlwraith) Date: Mon, 5 Apr 2010 14:13:04 +1000 Subject: [crossfire] Flash based Crossfire Client In-Reply-To: <4BB6310B.1030601@real-time.com> References: <4BB4F06B.9010000@real-time.com> <4BB6310B.1030601@real-time.com> Message-ID: Re Nicolas: Silverlight? You've got to be kidding me. Ouch. Quite possibly the worst development platform ever envisioned (one may as well use Java, at least it's mature and sane), save for exposing native-code executables directly to the web (what was that? "ActiveX"? OLE v2? COM? Oh, they're all the same thing? Never mind...) On Sat, Apr 3, 2010 at 4:01 AM, Rick Tanner wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >> I've been making substantial progress with building a Flash based >> Crossfire client based of the GTK-v2 client. > > Just to clarify.. yes; this was 100% April Fools "joke" > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iD8DBQFLtjELhHyvgBp+vH4RAqTJAJ4xH+lxqD+GJ+eNCQel6i/ocCyCNwCg1JLr > bHE2odEvAqFK62Gh/e4Zy9c= > =eTwX > -----END PGP SIGNATURE----- > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From nicolas.weeger at laposte.net Wed Apr 7 13:51:50 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 7 Apr 2010 20:51:50 +0200 Subject: [crossfire] Flash based Crossfire Client In-Reply-To: References: <4BB4F06B.9010000@real-time.com> <4BB6310B.1030601@real-time.com> Message-ID: <201004072051.55750.nicolas.weeger@laposte.net> > Silverlight? You've got to be kidding me. Ouch. Quite possibly the > worst development platform ever envisioned (one may as well use Java, > at least it's mature and sane), save for exposing native-code > executables directly to the web (what was that? "ActiveX"? OLE v2? > COM? Oh, they're all the same thing? Never mind...) *whoooooooooooooooosh* :) Nicolas (for those who don't get the Slashdot reference: yes, this whole mail was an april's fool joke, there is no Silverlight client :)) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100407/ff688e2e/attachment.pgp From brenlally at gmail.com Wed Apr 14 14:10:57 2010 From: brenlally at gmail.com (Brendan Lally) Date: Wed, 14 Apr 2010 20:10:57 +0100 Subject: [crossfire] skill window Message-ID: <20100414201057.2f0a6376@angmar> Hi All, As part of an overall aim to make the cf client a little more user-friendly, I have created a patch to add a skill window to the client. This may be found here: https://sourceforge.net/tracker/?func=detail&aid=2987308&group_id=13833&atid=313833 The aim is to enable access to all of the skills that a player has without needing to type anything. (I would expect that sooner or later, a player will want to bind use_skill praying to trigger a dozen times per press of a hotkey rather than clicking repeatedly, but if that is something that the player only needs to think about after playing the game for a couple of weeks rather than on the first day, then I'd consider that a win) There are a few things I'd like to add at some future point* but for now this is complete. Questions: 1) Can the skills and experience pane now disappear? 2) If it goes, should character, protections and core statistics move into the same pane? (so one pane with 3 tabs rather than 2 with 2 each) 3) Is there time for either or both of 1 and 2 to occur before the release of 1.50? (and when is that taking place?) *The following are things I would like to add probably during the next release cycle or the one after: Columns showing the keyboard shortcuts for the skills (ie looking for shortcuts for use_skill or ready_skill) - not sure whether those should be settable there, since that treads on the task of the Keybindings window a little icons for all of the skills (implemented by sending a face number along with the reply_info skill_info response) The 'character' pane on the client to show the icon for the skill rather than the name, and clicking on the icon to trigger the callback for the skill window in the same way that the menu entry does. Brendan From leaf at real-time.com Wed Apr 14 14:29:59 2010 From: leaf at real-time.com (Rick Tanner) Date: Wed, 14 Apr 2010 14:29:59 -0500 Subject: [crossfire] Release? In-Reply-To: <4BB2F360.4070507@sonic.net> References: <201002282150.55437.nicolas.weeger@laposte.net> <4BB2F360.4070507@sonic.net> Message-ID: <4BC617B7.9060703@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/31/10 2:01 AM, Mark Wedel wrote: > > Just a heads up - I'm targeting weekend of April 10-11 to make a release, > since I should have time then (certainly won't this weekend).. To recap or confirm.. This will or would be called 1.5 and based on what is currently in trunk? Or is this the final "branch" roll out of maps & server and client and called 1.12? (client based on SVN R12303 - the confirmed working checkin to work with Branch content) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLxhe1hHyvgBp+vH4RAlAsAKCtPeu//VVGR6no6cfYBGk3RYev/gCgyYqS TO4c8LlI+qRVYZ4jiVBrEQ8= =npgk -----END PGP SIGNATURE----- From nicolas.weeger at laposte.net Wed Apr 14 17:13:15 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 15 Apr 2010 00:13:15 +0200 Subject: [crossfire] Call for suggestions: CRE Message-ID: <201004150013.20230.nicolas.weeger@laposte.net> Hello. I've been lately toying with and improving the CRE tool (in server/utils/cre), and I'm wondering what features people would be interested in. Current features: - displays all archetypes, formulae, maps, animations, faces, treasure lists, artifacts - for each archetype, displays full details, and use in maps, treasure lists - for formulae, almost all details - for maps, exits to and from the map - for animations, which archetype(s) use them - for faces, use by animation and archetype - for treasure lists, details of a list, and what archetype(s) or treasure list use them - for artifacts, some details - report generation - for now not that powerful, and needs documentation, but you can generate a list of monsters by level for instance ;) - map information cache, so no need to rescan all >2500 maps each time Basically, I have two large improvement areas: - report generation, in various formats, for various things ; ultimately, it could be possible to totally customize a report (both contents and output) - edition, of archetypes, artifacts, anything (except maps - Gridarta does that nicely :)) ; this would make it easier to customize the game or contribute content Both those areas are interesting, and I may tackle them anyway, but I was wondering if people had nice ideas I didn't think of :) Note that the tool will probably not work under Windows (or Mac?) for now. I'm using Qt (C++ toolkit) which is itself cross-platform, but I still link to the common Crossfire library (in C), which needs to be built beforehand - and I'm not sure how Windows would handle the libraries formats and such. Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100415/da9c98e6/attachment.pgp From mwedel at sonic.net Thu Apr 15 00:59:43 2010 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 14 Apr 2010 22:59:43 -0700 Subject: [crossfire] skill window In-Reply-To: <20100414201057.2f0a6376@angmar> References: <20100414201057.2f0a6376@angmar> Message-ID: <4BC6AB4F.1050405@sonic.net> On 04/14/10 12:10 PM, Brendan Lally wrote: > Hi All, > > As part of an overall aim to make the cf client a little more > user-friendly, I have created a patch to add a skill window to the > client. > > This may be found here: > > https://sourceforge.net/tracker/?func=detail&aid=2987308&group_id=13833&atid=313833 Looks good. > > The aim is to enable access to all of the skills that a player has > without needing to type anything. (I would expect that sooner or later, > a player will want to bind use_skill praying to trigger a dozen times > per press of a hotkey rather than clicking repeatedly, but if that is > something that the player only needs to think about after playing the > game for a couple of weeks rather than on the first day, then I'd > consider that a win) One could make a compelling case that it shouldn't be necessary for the player to hit the same skill 50 times, but that is a more significant change (although one way could do it is some setting which basically has character doing the same activity under another command is entered, eg, character keeps playing until player hits some other command like north). > > There are a few things I'd like to add at some future point* but for > now this is complete. > > Questions: > > 1) Can the skills and experience pane now disappear? Yes, I think so. > 2) If it goes, should character, protections and core statistics move > into the same pane? (so one pane with 3 tabs rather than 2 with 2 each) This seems to be a layout specific issue - so there isn't a simple answer. For example, right now the gtk-v2 layout has a stat area (where the hp, sp, etc, bars are) and another area which right now has 3 panes - core stats, skills & exp, protections. I don't think there is any clear/best answer here. If you have a large/wide window, have 2 pane areas half the width may be more useful than one pane that is the entire width but of of which most is just blank. > 3) Is there time for either or both of 1 and 2 to occur before the > release of 1.50? (and when is that taking place?) I don't have a firm date on when the release for 1.50 will take place, but I'm thinking sometime soon. Given this is purely a client change, the change is pretty low risk. However, one thing that makes it a little harder is that all the layouts (of which I guess there are about a dozen now) should get updated. > > > *The following are things I would like to add probably during the > next release cycle or the one after: > > Columns showing the keyboard shortcuts for the skills (ie looking for > shortcuts for use_skill or ready_skill) - not sure whether those should > be settable there, since that treads on the task of the Keybindings > window a little IMO, settable there would be good. Likewise, letting the player do spell binding in the spell window might be handy. My thought on this is that right now, the keybinding window is a bit archaic - you basically need to know the syntax of the command you are going to bind - hardly a simple/beginner thing. But for skills and spells, the client knows what the command is, so can provide a nicer interface, something like the player selects the skill, then hits a 'bind key to skill button', and it pops up a window or something and says 'press key you want to use to have this skill used when you activate it', and all the player has to do is hit a key and maybe something like a confirm button (or maybe a bind to ready or a bind to use type thing). That's much better than having players have to know that they need to do a 'user_skill praying' syntax in the bind window. > > icons for all of the skills (implemented by sending a face number along > with the reply_info skill_info response) Yes - that would be nice. I'm not 100% sure if there are currently suitable faces for all of the skills however. > > The 'character' pane on the client to show the icon for the skill > rather than the name, and clicking on the icon to trigger the callback > for the skill window in the same way that the menu entry does. I'm not sure if I'd want the window to pop up, or just clicking it causes it to do the skill - I think the later may be more useful in most cases. From mwedel at sonic.net Thu Apr 15 01:03:04 2010 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 14 Apr 2010 23:03:04 -0700 Subject: [crossfire] Release? In-Reply-To: <4BC617B7.9060703@real-time.com> References: <201002282150.55437.nicolas.weeger@laposte.net> <4BB2F360.4070507@sonic.net> <4BC617B7.9060703@real-time.com> Message-ID: <4BC6AC18.3020106@sonic.net> On 04/14/10 12:29 PM, Rick Tanner wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 3/31/10 2:01 AM, Mark Wedel wrote: >> >> Just a heads up - I'm targeting weekend of April 10-11 to make a release, >> since I should have time then (certainly won't this weekend).. > > To recap or confirm.. > > This will or would be called 1.5 and based on what is currently in trunk? Called 1.50, and be based what is in trunk. > > Or is this the final "branch" roll out of maps& server and client and > called 1.12? No, I think the 1.x branch is basically dead - it hasn't had any significant updates, and I don't see much point in making a release knowing 1) it has out of date content 2) there are no plans to fix it 3) trunk is all that is worked on going forward. its basically releasing a product that we already know is EOL. > > (client based on SVN R12303 - the confirmed working checkin to work with > Branch content) I think the main thing that breaks the client right now is the lack of newmap setup command - that could easily be added simply for backward compatibility reasons (and might not be a bad idea until the next release, on the idea that by then, all servers should have gotten updated, and if they are not going to update, the client is going to break sooner or later, so may as well do it sooner) From brenlally at gmail.com Thu Apr 15 09:47:40 2010 From: brenlally at gmail.com (Brendan Lally) Date: Thu, 15 Apr 2010 15:47:40 +0100 Subject: [crossfire] skill window In-Reply-To: <4BC6AB4F.1050405@sonic.net> References: <20100414201057.2f0a6376@angmar> <4BC6AB4F.1050405@sonic.net> Message-ID: <20100415154740.0d21fbf5@angmar> On Wed, 14 Apr 2010 22:59:43 -0700 Mark Wedel wrote: > On 04/14/10 12:10 PM, Brendan Lally wrote: > > The aim is to enable access to all of the skills that a player has > > without needing to type anything. (I would expect that sooner or > > later, a player will want to bind use_skill praying to trigger a > > dozen times per press of a hotkey rather than clicking repeatedly, > > but if that is something that the player only needs to think about > > after playing the game for a couple of weeks rather than on the > > first day, then I'd consider that a win) > > One could make a compelling case that it shouldn't be necessary for > the player to hit the same skill 50 times, but that is a more > significant change (although one way could do it is some setting > which basically has character doing the same activity under another > command is entered, eg, character keeps playing until player hits > some other command like north). That could probably be implemented reasonably easily with a server-side command, so you would have a syntax like 'repeat [command you would normally issue]' Then if the server stored a 'repeat command' then when the server comes to process the command stream from the client, if it is empty, it would use the 'repeat command' stored against the player. if it is not empty (a new command has been given) then it would clear the 'repeat command' string and process the new commands instead. Client side, there would probably want to be a stat that is sent to say 'I am current doing your repeated command' so that the player knows when they are no longer praying/searching for traps/etc Might be necessary to mark a few commands as unrepeatable, since they don't really make sense to run multiple times (quit would be an obvious one) > > Questions: > > > > 1) Can the skills and experience pane now disappear? > > Yes, I think so. > > > 2) If it goes, should character, protections and core statistics > > move into the same pane? (so one pane with 3 tabs rather than 2 > > with 2 each) > > This seems to be a layout specific issue - so there isn't a simple > answer. For example, right now the gtk-v2 layout has a stat area > (where the hp, sp, etc, bars are) and another area which right now > has 3 panes - core stats, skills & exp, protections. > > I don't think there is any clear/best answer here. If you have a > large/wide window, have 2 pane areas half the width may be more > useful than one pane that is the entire width but of of which most is > just blank. ok, so it probably comes down to being a question for the creator/maintainer of each of the layouts. I've left them as they are for now (other than adding the menu entry) it does mean that the information is duplicated, but that's not a huge problem. > > *The following are things I would like to add probably during the > > next release cycle or the one after: > > > > Columns showing the keyboard shortcuts for the skills (ie looking > > for shortcuts for use_skill or ready_skill) - not sure whether > > those should be settable there, since that treads on the task of > > the Keybindings window a little > > IMO, settable there would be good. Likewise, letting the player > do spell binding in the spell window might be handy. Yeah, although with spells it is probably a bit more complex because they have options that can be passed to them > My thought on this is that right now, the keybinding window is a > bit archaic - you basically need to know the syntax of the command > you are going to bind - hardly a simple/beginner thing. But for > skills and spells, the client knows what the command is, so can > provide a nicer interface, something like the player selects the > skill, then hits a 'bind key to skill button', and it pops up a > window or something and says 'press key you want to use to have this > skill used when you activate it', and all the player has to do is hit > a key and maybe something like a confirm button (or maybe a bind to > ready or a bind to use type thing). That's more like a 'hot-key' setup > That's much better than having players have to know that they need > to do a 'user_skill praying' syntax in the bind window. Yeah, my inclination would be to say that the more advanced bindings should still be possible, but that simple bindings should be simple to set up > > icons for all of the skills (implemented by sending a face number > > along with the reply_info skill_info response) > > Yes - that would be nice. I'm not 100% sure if there are currently > suitable faces for all of the skills however. Most of them don't have any faces at all currently, I'm hoping there's someone who'd be prepared to draw them. > > The 'character' pane on the client to show the icon for the skill > > rather than the name, and clicking on the icon to trigger the > > callback for the skill window in the same way that the menu entry > > does. > > I'm not sure if I'd want the window to pop up, or just clicking it > causes it to do the skill - I think the later may be more useful in > most cases. I can see that, maybe the best approach there is do both, use on left click, select different skill on right click? Brendan From kbulgrien at att.net Thu Apr 15 22:17:24 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Thu, 15 Apr 2010 22:17:24 -0500 Subject: [crossfire] skill window In-Reply-To: <20100414201057.2f0a6376@angmar> References: <20100414201057.2f0a6376@angmar> Message-ID: <20100415221724.1f288b18@a850srvr.kbulgrien.att.net> > Questions: > > 1) Can the skills and experience pane now disappear? Probably, but the answer may not be as simple as you are thinking. Not only that, but I think that even though there are a lot of people that like to hide detail, there are some that like everything visible on the HUD, and that people should not make sweeping changes that hide information into separate windows for all layouts. I for one, generally want a lot of info on the screen all the time. I don't consciously read it all, but its being there lets me feel what's going on better because I rely on subconscious feedback a lot. The gtk-v1 series layouts (gtk-v1, v1-redux, and un-deux) are deliberately based on the gtk-v1 UI format. I should think it would be kind of odd to remove the look of the client the layout was to emulate. But, the gtk-v2 emulation of the gtk-v1 only went so far as gtk-v1 fonts were much different than gtk-v2, so the look/feel is not 100%. To preserve the intent behind these layouts the underlying code would have to remain to support them. I think libglade is not offended when a .glade file doesn't have all the items the code tries to connect. It think it does the right thing at run-time. Now, the original skills layout was pretty ugly and the underlying code did not manage the panel very well. There are apparently issues with some of the code - going an old bug list on SF - buffer overruns or some such, so that lends some credibility to removing the code support, but I won't be doing that because I really liked the gtk-v1. I did the libglade conversion because people kept threatening to shutdown the gtk-v1 and I was not about to play the original gtk-v2 layout as it just did not work on my small monitors. I did intend not to, and continue to avoid messing with the gtk-v2 original layout. It was the author's design and I did not want to presume to muck it up for him since he probably designed it that way because he liked it that way. What happens to gtk-v2 is not really not something I particular feel concerned about except that I'd like to see people respect the author's preferences. I definitely support pulling it out of sixforty.glade and oroboros.glade because the point of those layouts was to crunch screen space. Note that sixforty has some really good ideas, but its not that successful at making 640x480 work yet. Maybe removing skills from it would help break that loose. From there it starts to get a bit more personal. All the designs except gtk-v2, are "mine". A few I don't care a lot about as there is a bit too much similarity on some of them, so I would invite some diversity added, or the field thinned if removal makes too many of them even more similar than they already are, but I'd pose the reminder that the point of the libglade rewrite was to give people the freedom to hack the UI to their tastes and not have to be locked into someone else's choice. Design your own glade even if you base it on one of the existing designs. These are in SVN and are community property on an open license, but still I think some consideration to the original author is warranted - at least if they are still around. It would seem kind of rude to up an mod the author's favorite out from under him. That's kind of why the AUTHORS file in the glade directory ties layouts to authors. There's an awful lot of hours been put into them. meflin.glade is Meflin's design. It should not be messed with unless he goes for it. I did it up custom for him to his specifications, down to the bit sizing of some of the defaults. Other layouts might be other player's favorites, so making sweeping changes seems to take some extra thought about who it affects. Ok, so I've gone off a bit here here... I'll stop. Overall, I am probably fine with removal from the glades that are not gtk-v1 strains, but I would like some say in changes to my favorites... chthonic very definitely, and sixforty because it is WIP with a lot of new ideas, and to some extent caelestis as it was my first glade (though I see it as needing some rethinking especially after addition of the message control system). > 2) If it goes, should character, protections and core statistics move > into the same pane? (so one pane with 3 tabs rather than 2 with 2 each) > 3) Is there time for either or both of 1 and 2 to occur before the > release of 1.50? (and when is that taking place?) There's not a single answer. Various layouts have various design goals, though there is an element of experimentation in all of them. > *The following are things I would like to add probably during the > next release cycle or the one after: > > Columns showing the keyboard shortcuts for the skills (ie looking for > shortcuts for use_skill or ready_skill) - not sure whether those should > be settable there, since that treads on the task of the Keybindings > window a little No problem with setup being able to be done there as long as it doesn't preclude use of the keybinding dialog - at least until something better comes along for other keybinds. > icons for all of the skills (implemented by sending a face number along > with the reply_info skill_info response) Its fine, but I'd note that graphics blows out the vertical space requirements, so some consideration might be given to allowing them to be turned off or made quite small so as not to expand every line. The thing I like about your dialog now is that it is pretty tight and readable. I'm not really sure that I see a lot of value in skill graphics myself except as eye candy - which tends to aggravate things if you happen to have a really small monitor, but can be nice if you have screen real estate to throw away. > The 'character' pane on the client to show the icon for the skill > rather than the name, and clicking on the icon to trigger the callback > for the skill window in the same way that the menu entry does. Not sure I know what you mean by the 'character' pane. If you mean the core stats, I'm not in favor of the text version of the readied skill going away on all the layouts... but maybe I'm not groking what you want to do. Whereas some people like pictures, I tend to like text for that. I think graphics are ok for fairly static things like button bars, but I would find the readied skill shown only graphically to be frustrating. From kbulgrien at att.net Thu Apr 15 22:47:11 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Thu, 15 Apr 2010 22:47:11 -0500 Subject: [crossfire] Release? In-Reply-To: <4BC6AC18.3020106@sonic.net> References: <201002282150.55437.nicolas.weeger@laposte.net> <4BB2F360.4070507@sonic.net> <4BC617B7.9060703@real-time.com> <4BC6AC18.3020106@sonic.net> Message-ID: <20100415224711.0a282e79@a850srvr.kbulgrien.att.net> On Wed, 14 Apr 2010 23:03:04 -0700 Mark Wedel wrote: > On 04/14/10 12:29 PM, Rick Tanner wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 3/31/10 2:01 AM, Mark Wedel wrote: > >> > >> Just a heads up - I'm targeting weekend of April 10-11 to make a release, > >> since I should have time then (certainly won't this weekend).. > > > > To recap or confirm.. > > > > This will or would be called 1.5 and based on what is currently in trunk? > > Called 1.50, and be based what is in trunk. > > > > > Or is this the final "branch" roll out of maps& server and client and > > called 1.12? > > No, I think the 1.x branch is basically dead - it hasn't had any significant > updates, and I don't see much point in making a release knowing 1) it has out of > date content 2) there are no plans to fix it 3) trunk is all that is worked on > going forward. > > its basically releasing a product that we already know is EOL. > > > > (client based on SVN R12303 - the confirmed working checkin to work with > > Branch content) > > I think the main thing that breaks the client right now is the lack of newmap > setup command - that could easily be added simply for backward compatibility > reasons (and might not be a bad idea until the next release, on the idea that by > then, all servers should have gotten updated, and if they are not going to > update, the client is going to break sooner or later, so may as well do it sooner) Without countering Mark, I have build scripts that go all the way down to making RPMs... I'll support you in making a client release compatible with branch if you really want that. I can see part of the point of having branch for stability, but at some point it seems to detract from CF progress since people are banging on current development and pointing out issues, making suggestions, etc. I am, however, in full agreement with Mark regarding server, etc. and I'm not interested in putting time in on branch for server. The scripts automatically do assemble maps, etc as was done for prior releases, so its not like I'd have to spend a lot of time trying to help out on the client, but I don't have the server builds scripted. Kevin From mwedel at sonic.net Thu Apr 15 23:18:03 2010 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 15 Apr 2010 21:18:03 -0700 Subject: [crossfire] Release? In-Reply-To: <20100415224711.0a282e79@a850srvr.kbulgrien.att.net> References: <201002282150.55437.nicolas.weeger@laposte.net> <4BB2F360.4070507@sonic.net> <4BC617B7.9060703@real-time.com> <4BC6AC18.3020106@sonic.net> <20100415224711.0a282e79@a850srvr.kbulgrien.att.net> Message-ID: <4BC7E4FB.4050506@sonic.net> On 04/15/10 08:47 PM, Kevin Bulgrien wrote: > Without countering Mark, I have build scripts that go all the way down to making > RPMs... I'll support you in making a client release compatible with branch if you > really want that. I can see part of the point of having branch for stability, but > at some point it seems to detract from CF progress since people are banging on > current development and pointing out issues, making suggestions, etc. > > I am, however, in full agreement with Mark regarding server, etc. and I'm not > interested in putting time in on branch for server. The scripts automatically do > assemble maps, etc as was done for prior releases, so its not like I'd have to > spend a lot of time trying to help out on the client, but I don't have the > server builds scripted. Quick thoughts: On the client side, a few trivial changes would let the 1.50 (proposed) client work on 1.12 servers. I'd rather do that than have both a 1.50 and 1.12 client release. I believe the main thing that the 1.50 client did was remove some of the set up options, on the basis these are now defaults. Now certainly there is some new logic in the 1.50 client which one would not use on a 1.12 server (account based, I think the improved spell monitoring, etc). Likewise, the 1.12 client should be able to run on latest server without any real issues, but also wouldn't be able to use the new features the server offers. If the concern here is for servers that will spend some time migrating but players would be using the latest client, then my preferred solution would be to make sure latest client works on 1.x branch servers. From brenlally at gmail.com Fri Apr 16 08:35:09 2010 From: brenlally at gmail.com (Brendan Lally) Date: Fri, 16 Apr 2010 14:35:09 +0100 Subject: [crossfire] skill window In-Reply-To: <20100415221724.1f288b18@a850srvr.kbulgrien.att.net> References: <20100414201057.2f0a6376@angmar> <20100415221724.1f288b18@a850srvr.kbulgrien.att.net> Message-ID: <20100416143509.35233c29@angmar> On Thu, 15 Apr 2010 22:17:24 -0500 Kevin Bulgrien wrote: > > Questions: > > > > 1) Can the skills and experience pane now disappear? > > Other layouts might be other player's favorites, so making sweeping > changes seems to take some extra thought about who it affects. Ok, so taking all of that, then it is even less clarity over who can 'bless' a change to a layout, particularly if the author of a layout isn't the same thing as a user. Because there are multiple respondents, giving different verdicts, the mailing list probably isn't the ideal place to try and collate those, so I have created a wiki page: http://wiki.metalforge.net/doku.php/gtk-v2_ui_updates Where these responses can be collected. The other advantage of this approach is that if no verdict or comments are given after a month or two, then it is probably safe to consider that layout unused and unloved, and then to consider it for exclusion from future releases and ultimately removal from the SVN repository. Obviously if there are vastly differing and strongly held sentiments in terms of what should be done for any given layout, then that makes the case for creating another new layout. > > icons for all of the skills (implemented by sending a face number > > along with the reply_info skill_info response) > > Its fine, but I'd note that graphics blows out the vertical space > requirements, so some consideration might be given to allowing them to > be turned off or made quite small so as not to expand every line. The > thing I like about your dialog now is that it is pretty tight and > readable. I'm not really sure that I see a lot of value in skill > graphics myself except as eye candy - which tends to aggravate things > if you happen to have a really small monitor, but can be nice if you > have screen real estate to throw away. Ok, I can certainly see that point, OTOH there are 44 skills and it is a scrolled window which is sortable, a few of these are mutually exclusive anyway, and a couple are switched off, so you are probably looking at not more than 40x32 pixels = 1280 pixels For many players on modern systems, that entire list probably fits on screen or very close to it, for the rest, then sorting by level is probably going to show them the skills they care about anyway (after all, when was the last time you gained jumping experience?) > > The 'character' pane on the client to show the icon for the skill > > rather than the name, and clicking on the icon to trigger the > > callback for the skill window in the same way that the menu entry > > does. > > Not sure I know what you mean by the 'character' pane. If you mean > the core stats, I'm not in favor of the text version of the readied > skill going away on all the layouts... but maybe I'm not groking what > you want to do. Whereas some people like pictures, I tend to like > text for that. I think graphics are ok for fairly static things like > button bars, but I would find the readied skill shown only > graphically to be frustrating. That is what I meant, I can see why you might not like that, so maybe it is something that should be altered on a per-layout basis. Brendan From nicolas.weeger at laposte.net Fri Apr 16 11:48:28 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 16 Apr 2010 18:48:28 +0200 Subject: [crossfire] Material Message-ID: <201004161848.34786.nicolas.weeger@laposte.net> Hello. I'm not sure many people actually use the NEW_MATERIAL_CODE macro defined in config.h... I don't even know who knows what it is supposed to do or if it was tested :) So I'm proposing 2 alternatives: 1) remove this code, and forget about it 2) activate it and debug it. For option 2), here is a proposal for a defined behaviour. An object will have 2 properties, "real material" and "readable material". The first will be used in the code, for various save throws and such. The second (current "materialname") will be the name displayed to the player. The "real material" will be a comma-separated list of either material name (as defined in the "lib/materials" file or material type (as defined in include/material.h). If it is a name, this material is used ; if it is a type, a random one is chosen from the materials of this type. For computing purposes, the average of a value will be computed - if you have 2 materials, the eg fire saving throw will be the average of both values. It is only possible to use one material from the same type (one skin only). The readable name will be either defined by the archetype creator or map maker, or made from the real material(s). This is to let map makers have fun with names and still keep a real material underneath. A flag will indicate if the material bonuses (to damage, to weight, ...) were already applied to the object or not. Material will not be processed for archetypes or artifacts, to enable diversity. Examples: - "material 8" will select a random skin, from wolfhide, dragonhide, and so on - "material 24" will select a random skin and a random wood - "material "bamboo,64" will make a material from bamboo and a random stone. Opinions? Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100416/8d921d6b/attachment.pgp From leaf at real-time.com Fri Apr 16 13:04:53 2010 From: leaf at real-time.com (Rick Tanner) Date: Fri, 16 Apr 2010 13:04:53 -0500 Subject: [crossfire] Material In-Reply-To: <201004161848.34786.nicolas.weeger@laposte.net> References: <201004161848.34786.nicolas.weeger@laposte.net> Message-ID: <4BC8A6C5.8030101@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I'm not sure many people actually use the NEW_MATERIAL_CODE macro defined in > config.h... > I don't even know who knows what it is supposed to do or if it was tested :) Quite some time ago, it was enabled on Metalforge but removed due to player complaints. What people didn't like about it was merging issues in their inventory window. They would (for instance) have 8 different Boots of Speed all because they would not merge together to be Boots of Speed x8; the material types (different hides; dragon, wolf, serpent, etc.) was determined to have caused this. The goal or hope of the original developer for this feature was to implement task quests in the game like find a NPC a stone amulet, a gold sword, serpent skin leather armour, etc. and then collect a reward. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLyKbFhHyvgBp+vH4RAg/TAJ9KynSdIDJ3vfBZoT9QIY39DHYBBACcDRYQ uJXIfPp25t8wdfX9bIqLar8= =dJzv -----END PGP SIGNATURE----- From brenlally at gmail.com Fri Apr 16 15:47:20 2010 From: brenlally at gmail.com (Brendan Lally) Date: Fri, 16 Apr 2010 21:47:20 +0100 Subject: [crossfire] Auto ID on examine Message-ID: <20100416214720.79b62ca8@angmar> Hello all, Just wanted to get some opinions on the following patch: https://sourceforge.net/tracker/?func=detail&aid=2988536&group_id=13833&atid=313833 This changes the way the examine command (triggered by left clicking on an object) works so that if the object is unidentified, and the player has the appropriate skill, then an attempt to identify the object is automatically made. The intention is that this should make the ID process much smoother for new players, and less likely to be discovered after wasting money on ID tables or selling items that were useful. Brendan From kbulgrien at att.net Fri Apr 16 18:30:56 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Fri, 16 Apr 2010 18:30:56 -0500 Subject: [crossfire] skill window In-Reply-To: <20100416143509.35233c29@angmar> References: <20100414201057.2f0a6376@angmar> <20100415221724.1f288b18@a850srvr.kbulgrien.att.net> <20100416143509.35233c29@angmar> Message-ID: <20100416183056.4fdb6dd2@a850srvr.kbulgrien.att.net> > Ok, so taking all of that, then it is even less clarity over who can > 'bless' a change to a layout, particularly if the author of a layout > isn't the same thing as a user. Because there are multiple respondents, > giving different verdicts, the mailing list probably isn't the ideal > place to try and collate those, so I have created a wiki page: > > http://wiki.metalforge.net/doku.php/gtk-v2_ui_updates > > Where these responses can be collected. > > The other advantage of this approach is that if no verdict or comments > are given after a month or two, then it is probably safe to consider > that layout unused and unloved, and then to consider it for > exclusion from future releases and ultimately removal from the SVN > repository. Surely you jest. Just how often is the quantity of wiki edits / month or two an accurate sampling of the entire crossfire player population's views on anything? > Obviously if there are vastly differing and strongly held sentiments in > terms of what should be done for any given layout, then that makes the > case for creating another new layout. From nicolas.weeger at laposte.net Sat Apr 17 02:05:01 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 17 Apr 2010 09:05:01 +0200 Subject: [crossfire] Material In-Reply-To: <4BC8A6C5.8030101@real-time.com> References: <201004161848.34786.nicolas.weeger@laposte.net> <4BC8A6C5.8030101@real-time.com> Message-ID: <201004170905.06512.nicolas.weeger@laposte.net> Hello. > Quite some time ago, it was enabled on Metalforge but removed due to > player complaints. > > What people didn't like about it was merging issues in their inventory > window. They would (for instance) have 8 different Boots of Speed all > because they would not merge together to be Boots of Speed x8; the > material types (different hides; dragon, wolf, serpent, etc.) was > determined to have caused this. My opinion is that almost all archetypes should have a fixed precise material, eg fixed wood, or metal, or other material. Using random ones should be limited to specific cases, including maybe quests items... > The goal or hope of the original developer for this feature was to > implement task quests in the game like find a NPC a stone amulet, a gold > sword, serpent skin leather armour, etc. and then collect a reward. Indeed, this could be done. This can already be done, though, through the 'materialname' and 'material' things. Currently, right now, the material is used for two things: - when animate weapon is used, to give resistances to the golem - for throw saves to know if an item is destroyed or not by an attack Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100417/313268f2/attachment.pgp From brenlally at gmail.com Sat Apr 17 03:41:44 2010 From: brenlally at gmail.com (Brendan Lally) Date: Sat, 17 Apr 2010 09:41:44 +0100 Subject: [crossfire] skill window In-Reply-To: <20100416183056.4fdb6dd2@a850srvr.kbulgrien.att.net> References: <20100414201057.2f0a6376@angmar> <20100415221724.1f288b18@a850srvr.kbulgrien.att.net> <20100416143509.35233c29@angmar> <20100416183056.4fdb6dd2@a850srvr.kbulgrien.att.net> Message-ID: <20100417094144.3a8fe21e@angmar> On Fri, 16 Apr 2010 18:30:56 -0500 Kevin Bulgrien wrote: > > > > http://wiki.metalforge.net/doku.php/gtk-v2_ui_updates > > > > Where these responses can be collected. > > > > The other advantage of this approach is that if no verdict or > > comments are given after a month or two, then it is probably safe > > to consider that layout unused and unloved, and then to consider it > > for exclusion from future releases and ultimately removal from the > > SVN repository. > > Surely you jest. Just how often is the quantity of wiki edits / > month or two an accurate sampling of the entire crossfire player > population's views on anything? I'm hoping the answer to that is, 'when there are a number of mailing list, IRC and forum posts inviting, with ever escalating persistence, an expression of such views. That probably means up to 4 mailing list posts & forum posts + at least that quantity of IRC discussions which follow the following form: 1) There is a proposal to change layouts, can all layout owners/maintainers give their verdicts and interested users give comments. [2-4 weeks later] 2) Please give all comments and verdicts to the layout change proposals in the next 2 weeks, the following layouts are lacking any response: .... the following layouts have comments but no owner verdict. ... [2-4 weeks thereafter] 3) The following layouts have not received a response from the owner/maintainer regarding the change n. ... Please can any commentators who wish to take over maintenance of these layouts contact the mailing list. [2-4 weeks thereafter] 4) The following layouts received no response at all to the proposed layout change n, ... and are now considered abandoned, they will be removed prior to the next release. There may also be a case for a crossfire-announce posting to be made in the lead-up to a release, probably a couple of weeks beforehand so that there is time for anyone who doesn't read the main mailing list to yell. (Although then you might question how much such a person really cares about the ongoing development of CF, and if they would really notice). The overall aims here are: 1) That the number of layouts remains fewer than the number of players, preferably substantially fewer. 2) That the majority of players using the majority of layouts should benefit from work being done on client changes, unless they are deliberately choosing layouts which are designed not to. My view would tend to be that if: * There is a layout currently that is intended never to be updated, * It is for the use of a single individual, who has decided that it is perfect as it is Then that shouldn't be in SVN, and shouldn't be a choice in the client as it is distributed by default. By all means keep a backup somewhere globally accessible, along with instructions for using it with a client, but for someone new to CF, who discovers the layout selection widget for the first time, they should expect that the selections they choose from correspond vaguely with the documentation that they will read, and not have something which is hugely different (other than in the ways that are a design feature of the layout) The case of an underused layout where there is a desire to see it actively maintained is a different matter, I'd hope that all the current layouts fall into this category, and the only question is over how to implement such maintenance (if at all). > > Obviously if there are vastly differing and strongly held > > sentiments in terms of what should be done for any given layout, > > then that makes the case for creating another new layout. If no one cares to express such views over the course of several months, the conclusion must be that they are not strongly held. Brendan. From om at iki.fi Sat Apr 17 05:00:24 2010 From: om at iki.fi (Otto J. Makela) Date: Sat, 17 Apr 2010 13:00:24 +0300 Subject: [crossfire] Auto ID on examine In-Reply-To: <20100416214720.79b62ca8@angmar> References: <20100416214720.79b62ca8@angmar> Message-ID: <4BC986B8.9090909@iki.fi> Brendan Lally wrote: > This changes the way the examine command (triggered by left > clicking on an object) works so that if the object is unidentified, > and the player has the appropriate skill, then an attempt to identify > the object is automatically made. > > The intention is that this should make the ID process much smoother for > new players, and less likely to be discovered after wasting money on ID > tables or selling items that were useful. This does change the overall game balance a bit (making it easier to use skills automatically), but all-in-all I think it is a good change. What I would like to also see is having a class "identified" (similar in function to "cursed" and "magic") in the inventory, so that you could more easily manipulate items which you have identified. -- /* * * Otto J. Makela * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * */ From kbulgrien at att.net Sat Apr 17 13:53:45 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Sat, 17 Apr 2010 13:53:45 -0500 Subject: [crossfire] skill window In-Reply-To: <20100417094144.3a8fe21e@angmar> References: <20100414201057.2f0a6376@angmar> <20100415221724.1f288b18@a850srvr.kbulgrien.att.net> <20100416143509.35233c29@angmar> <20100416183056.4fdb6dd2@a850srvr.kbulgrien.att.net> <20100417094144.3a8fe21e@angmar> Message-ID: <20100417135345.47cd897f@a850srvr.kbulgrien.att.net> Until other responses are made to this, there is really little point in continuing the discussion. It is evident that an agenda is being pushed when there are many other alternative paths and cooperative viewpoints that are less isolating and much more constructive. Policy is being proposed that is not applied to other areas of SVN. It gives the appearance that control is much more important than cooperation. There seems little point to argue when the agenda is so destructive. Freedom at the expense of relationship is not something that is going to help Crossfire. Copy a design you want to change, and modify it. Commit it, and expect that people will be respectful of the work that went into it, and will not attempt to wrest control of your efforts away from you, nor attempt to invalidate your tastes of how a client should look and feel while you are still active in the project. > > > http://wiki.metalforge.net/doku.php/gtk-v2_ui_updates > > > > > > Where these responses can be collected. > > > > > > The other advantage of this approach is that if no verdict or > > > comments are given after a month or two, then it is probably safe > > > to consider that layout unused and unloved, and then to consider it > > > for exclusion from future releases and ultimately removal from the > > > SVN repository. > > > > Surely you jest. Just how often is the quantity of wiki edits / > > month or two an accurate sampling of the entire crossfire player > > population's views on anything? > > I'm hoping the answer to that is, 'when there are a number of mailing > list, IRC and forum posts inviting, with ever escalating persistence, an > expression of such views. > > That probably means up to 4 mailing list posts & forum posts + > at least that quantity of IRC discussions which follow the following > form: > > 1) There is a proposal to change layouts, can all layout > owners/maintainers give their verdicts and interested users give > comments. > > [2-4 weeks later] > > 2) Please give all comments and verdicts to the layout change proposals > in the next 2 weeks, the following layouts are lacking any response: > .... > the following layouts have comments but no owner verdict. > ... > [2-4 weeks thereafter] > > 3) The following layouts have not received a response from the > owner/maintainer regarding the change n. > ... > Please can any commentators > who wish to take over maintenance of these layouts contact the mailing > list. > > [2-4 weeks thereafter] > > 4) The following layouts received no response at all to the proposed > layout change n, > ... > and are now considered abandoned, they will be removed > prior to the next release. > > There may also be a case for a crossfire-announce posting to be made in > the lead-up to a release, probably a couple of weeks beforehand so that > there is time for anyone who doesn't read the main mailing list to > yell. (Although then you might question how much such a person really > cares about the ongoing development of CF, and if they would really > notice). > > The overall aims here are: > 1) That the number of layouts remains fewer than the number of players, > preferably substantially fewer. > 2) That the majority of players using the majority of layouts should > benefit from work being done on client changes, unless they are > deliberately choosing layouts which are designed not to. > > My view would tend to be that if: > * There is a layout currently that is intended never to be updated, > * It is for the use of a single individual, who has decided that it is > perfect as it is > > Then that shouldn't be in SVN, and shouldn't be a choice in the > client as it is distributed by default. By all means keep a backup > somewhere globally accessible, along with instructions for using it > with a client, but for someone new to CF, who discovers the layout > selection widget for the first time, they should expect that the > selections they choose from correspond vaguely with the documentation > that they will read, and not have something which is hugely different > (other than in the ways that are a design feature of the layout) > > The case of an underused layout where there is a desire to see it > actively maintained is a different matter, I'd hope that all the > current layouts fall into this category, and the only question is over > how to implement such maintenance (if at all). > > > > Obviously if there are vastly differing and strongly held > > > sentiments in terms of what should be done for any given layout, > > > then that makes the case for creating another new layout. > > If no one cares to express such views over the course of several > months, the conclusion must be that they are not strongly held. > > Brendan. From nicolas.weeger at laposte.net Sun Apr 18 13:08:43 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 18 Apr 2010 20:08:43 +0200 Subject: [crossfire] Gnome tweaking Message-ID: <201004182008.54471.nicolas.weeger@laposte.net> Hello. The "gnome", and "gnome2" monsters have an attacktype of paralyze, for a level of 6. IMO that is too hard for new players, so I've changed the attacktype to physical and magic. "gardengnome" on the other hand, level 25, keeps his paralyze attacktype :) Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100418/ef10b7a9/attachment.pgp From om at iki.fi Sun Apr 18 17:46:04 2010 From: om at iki.fi (Otto J. Makela) Date: Mon, 19 Apr 2010 01:46:04 +0300 Subject: [crossfire] skill window In-Reply-To: <20100417135345.47cd897f@a850srvr.kbulgrien.att.net> References: <20100414201057.2f0a6376@angmar> <20100415221724.1f288b18@a850srvr.kbulgrien.att.net> <20100416143509.35233c29@angmar> <20100416183056.4fdb6dd2@a850srvr.kbulgrien.att.net> <20100417094144.3a8fe21e@angmar> <20100417135345.47cd897f@a850srvr.kbulgrien.att.net> Message-ID: <4BCB8BAC.10609@iki.fi> Kevin Bulgrien wrote: > There seems little point to argue when the agenda is so destructive. ...misunderstandings and neglect create more confusion in this world than trickery and malice. At any rate, the last two are certainly much less frequent. -- Johann Wolfgang von Goethe (1749-1832): The Sorrows of Young Werther, 1774 -- /* * * Otto J. Makela * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * */ From om at iki.fi Sun Apr 18 17:47:11 2010 From: om at iki.fi (Otto J. Makela) Date: Mon, 19 Apr 2010 01:47:11 +0300 Subject: [crossfire] Gnome tweaking In-Reply-To: <201004182008.54471.nicolas.weeger@laposte.net> References: <201004182008.54471.nicolas.weeger@laposte.net> Message-ID: <4BCB8BEF.1010503@iki.fi> The subject sounds like something you could end up in jail for in many states. -- /* * * Otto J. Makela * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * */ From mwedel at sonic.net Sun Apr 18 23:49:15 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 18 Apr 2010 21:49:15 -0700 Subject: [crossfire] Material In-Reply-To: <201004170905.06512.nicolas.weeger@laposte.net> References: <201004161848.34786.nicolas.weeger@laposte.net> <4BC8A6C5.8030101@real-time.com> <201004170905.06512.nicolas.weeger@laposte.net> Message-ID: <4BCBE0CB.7000404@sonic.net> On 04/17/10 12:05 AM, Nicolas Weeger wrote: > Hello. > >> Quite some time ago, it was enabled on Metalforge but removed due to >> player complaints. >> >> What people didn't like about it was merging issues in their inventory >> window. They would (for instance) have 8 different Boots of Speed all >> because they would not merge together to be Boots of Speed x8; the >> material types (different hides; dragon, wolf, serpent, etc.) was >> determined to have caused this. > > My opinion is that almost all archetypes should have a fixed precise material, > eg fixed wood, or metal, or other material. > Using random ones should be limited to specific cases, including maybe quests > items... I agree. But if random ones were really desired, it could be done via treasurelists. for example, if you wanted gold swords, silver swords, bronze, etc, as a random treasure for a quest, this could be done as a treasurelist which lists those different archetypes. One of the other problems/issues with the material code is that you would fine stuff in all different materials, but from a player perspective, it had no value. The item attributes for the different materials was pretty much always trivial, so the fact you had a pine bow vs an oak bow had no real value (there wasn't any compelling reason to want one of those vs the other - more likely what is more important is which ever one was more magical). If alchemy/crafting skills were heavily used and made use of that, this might of had more relevance. But few players use the smithing skills, and I'm not even sure if in most cases there was any recipes that used the various specific materials. > > > >> The goal or hope of the original developer for this feature was to >> implement task quests in the game like find a NPC a stone amulet, a gold >> sword, serpent skin leather armour, etc. and then collect a reward. > > Indeed, this could be done. > This can already be done, though, through the 'materialname' and 'material' > things. > > > > Currently, right now, the material is used for two things: > - when animate weapon is used, to give resistances to the golem > - for throw saves to know if an item is destroyed or not by an attack IMO, a lot more could be done with material, but that would really get tied into the alchemy/crafting area, and is a different conversation. But just brainstorming on that (not suggesting that anyone hop on doing this, but just recording while fresh in my mind): All mundane (non magical/normal objects) are going to be made up of some number of base materials. All the base material (wood, iron, stone, etc) would come from someplace - in the forest, you could harvest wood. One could add some type of mining to harvest stone/iron from dungeons. With that, you could then make the basic items - an axe for example. The materials in the finished items would also be what items you would get if you recycled the materials - for that axe, you might be a piece of wood and hunk of iron when you salvage it. Players should be able to make all these basic items - now for the most part, they probably would not want to. Now from the game design point of view, you would look at the different possible materials and determine if that material is significant enough to be its own object. For example, one might determine that an oak bow and ash bow are close enough there is no reason to differentiate them, so you just have generic bows made from wood. But one might say that yew is special enough that it gives wc+1, so that is given its own archetype. In this way, maybe bows show up in 2 materials, vs half a dozen with the old material code, but the 2 varieties are different enough that there is value in that yew bow What this does give is also base crafting needed for these items - for that bow, you would need wood and maybe a strip of leather. If you had a piece of yew wood, you would make a good bow. A lot of these recipes would also be intrinsic - in that the player/character would know the recipe without having found it - if I'm building a bookcase, I don't automatically fail if I don't have enough wood - I'd realize pretty quickly I need more wood and get some more - same would be true for a lot of these basic crafting. With the basics done, you can now start to work on items using magical materials. For example, you may say that mithril is 50% lighter than steel. So if chainmail normally takes 10 chunks of iron, you would need 10 chunks of mithril to make mithril chainmail, which would be like that iron chainmail except for 50% lighter (which would adjust some other things like spell encumbrance also). Using dragon hides instead of cow leather hide gives you better leather armor - maybe some resistances, better AC, etc. The problem with all this is that it is a lot of work. But the crafting arena needs a lot of work (or did last I looked), and needs an overall good design - these basic formula give some way for characters to build up exp in those skills to make better items, and by starting with the the basic materials, characters would have no problem finding enough wood, iron, etc, from the hordes of monsters to craft to their hearts content. From mwedel at sonic.net Mon Apr 19 00:36:29 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 18 Apr 2010 22:36:29 -0700 Subject: [crossfire] skill window In-Reply-To: <4BCB8BAC.10609@iki.fi> References: <20100414201057.2f0a6376@angmar> <20100415221724.1f288b18@a850srvr.kbulgrien.att.net> <20100416143509.35233c29@angmar> <20100416183056.4fdb6dd2@a850srvr.kbulgrien.att.net> <20100417094144.3a8fe21e@angmar> <20100417135345.47cd897f@a850srvr.kbulgrien.att.net> <4BCB8BAC.10609@iki.fi> Message-ID: <4BCBEBDD.9080008@sonic.net> My fairly random thoughts on all of this: - The space used up for the tab for skills & exp is minimal, so for most layouts, the cost of keeping it in place isn't very high. - Changes where someone else disagrees with that change are always a problem - this can also happen in maps. In general, if it is the person that originally did the work that disagrees with it, decisions on changes is left to them - however, opinions can be swayed also by what other people say. - In the ideal world, this would be something each user could decide on via setting or the like. I'm not sure how realistic this is, but I can certainly see why there may be different opinions. For myself, I have a lot of screen real-estate, so if I want to see that skills and exp, keeping that window up all the time isn't an issue. But for others, I could see the crossfire game window using up all the screen space they have, so keeping up another window would just hide something else, and having that tab there is handy. At one time, GNOME had the idea of dockable widgets (don't know if it still does), so you could move widgets around, dock them here, there, etc. If that is still possible, it would basically let users customize the interface however they want (don't want the skills tab? Just dump it in the trash). A concern I have is that if one has too many options (checkboxes for what stuff to show in the client vs windows), you potentially have a dozen checkboxes down the road of what to show or not show - that isn't great. - The number of glade files probably needs to be controlled in some way - otherwise, I could forsee a mass increase here, and the question then becomes who supports them all. One thought is to take 3-4 core glade files and call them the standard/supported ones, and the rest fall into a contrib area. What that means is that if bugs are filed against the core ones, they should get fixed - if filed against contrib ones, they don't, but whoever contributed that layout file may feel compelled to fix it (or may not) - if a contributed layout gets so out of date it isn't usable, it gets removed. - It would be nice to have a better way of switch layout files, or at least seeing what they are. Having a .png file of each layout that that is perhaps displayed would be one way. I would imagine it isn't impossible to have it reconfigure the layout in real-time, but it may require destroying all the widgets and re-creating them (this becomes an issue for images). My only thought here is that I do wonder how many of those layouts really are used, given that the mechanism for switching does require a restart (I don't know if I'd want to restart my client 12 times to see all the different layouts) Probably got a bit off topic on some of these. From mwedel at sonic.net Mon Apr 19 00:43:38 2010 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 18 Apr 2010 22:43:38 -0700 Subject: [crossfire] Gnome tweaking In-Reply-To: <201004182008.54471.nicolas.weeger@laposte.net> References: <201004182008.54471.nicolas.weeger@laposte.net> Message-ID: <4BCBED8A.3090703@sonic.net> On 04/18/10 11:08 AM, Nicolas Weeger wrote: > Hello. > > The "gnome", and "gnome2" monsters have an attacktype of paralyze, for a level > of 6. > > IMO that is too hard for new players, so I've changed the attacktype to > physical and magic. > > "gardengnome" on the other hand, level 25, keeps his paralyze attacktype :) this is mostly off topic, but in some way or another, paralyzation needs to get changed or removed IMO. As a player, at any level, it is annoying to just get frozen in place an not able to do anything about it. At least with confusion, you may be able to wonder out of the area, use a scroll to remove confusion (or get you out of there), etc. The current solution to this is that most people end up getting a ring or amulet that gives +100 resistance to paralyzation, so they don't have to worry about it any more. But that then raises the question of what is the point of having an attacktype if most people just get immune to it (on a related basis, draining probably needs a fix for the same reason). I don't have any good fix - one way might be not allowing the character to move, but still do other actions (attack, cast spells, etc) - in a sense, act like the characters feet are stuck to the floor. This in itself could be pretty annoying - that fighter gets frozen in place as he charges the dragon, likewise, hard to retreat. But it also allows characters other actions, like use a remove paralyze scroll (such would have to get added) and at least feel like their fate is in their hands. Right now, if you get paralyzed, really nothing you can do except hope you survive. (on such a change, the resist paralyze +100 items should probably become +75 items instead). But now, with the character being able to do other actions, they may say that another item is better use. From kbulgrien at att.net Mon Apr 19 19:08:02 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Mon, 19 Apr 2010 19:08:02 -0500 Subject: [crossfire] skill window In-Reply-To: <4BCBEBDD.9080008@sonic.net> References: <20100414201057.2f0a6376@angmar> <20100415221724.1f288b18@a850srvr.kbulgrien.att.net> <20100416143509.35233c29@angmar> <20100416183056.4fdb6dd2@a850srvr.kbulgrien.att.net> <20100417094144.3a8fe21e@angmar> <20100417135345.47cd897f@a850srvr.kbulgrien.att.net> <4BCB8BAC.10609@iki.fi> <4BCBEBDD.9080008@sonic.net> Message-ID: <20100419190802.722c591a@a850srvr.kbulgrien.att.net> > My fairly random thoughts on all of this: > > - The space used up for the tab for skills & exp is minimal, so for most > layouts, the cost of keeping it in place isn't very high. As for removal, I don't have a problem taking it out of most layouts, and will likely remove it from most, except for the gtk-v1 layout. What is less obvious is how the rest of the layout changes to preserve the intent behind the original design. > - Changes where someone else disagrees with that change are always a problem - > this can also happen in maps. In general, if it is the person that originally > did the work that disagrees with it, decisions on changes is left to them - > however, opinions can be swayed also by what other people say. Precisely. And it should be quite clear that input is accepted, and that .glade tweaks are done for people by request. meflin.glade and sixforty.glade are explicitly done to support specific user requests. To some extent, others are less obviously designed to a particular user's preference - even the dialogs.glade has changes inspired by users. The designer may be the only one who really understands all of why the layout was made the way it was in some cases. It only makes sense for the designer to have more input weight than a user poll. Whatever the recent flap may seem to imply, getting feedback and making changes based on them is a high priority goal. I do not, however, feel it is appropriate for design changes to go to a "democratic" vote, and it is clear you feel that way too. What is not obvious to a third party is that some of the layouts have very specific reasons for their implementation that may only be noticed under the conditions the layout was optimized for. A casual vote on what to change will likely not appropriately consider the design rationale and preserve it. It is not always easy to document this rationale, and even less easy to put it out in a way that would let a voter appropriately decide how to deal with it. I am not willing to sacrifice some design goals for a user who does not know why the design is done the way it is. In cases such as this, however, I do feel it is appropriate to allow/support rename and modify to support requests. In other words, as far as I am concerned there is no flat out "no I won't do that", but there might very easily be a "you may have what you want, but perhaps not the way you stated it". I may want to preserve certain aspects of certain named designs under that name, but I have no problem copying the design and naming it something else. > - In the ideal world, this would be something each user could decide on via > setting or the like. I'm not sure how realistic this is, but I can certainly > see why there may be different opinions. For myself, I have a lot of screen > real-estate, so if I want to see that skills and exp, keeping that window up all > the time isn't an issue. But for others, I could see the crossfire game window > using up all the screen space they have, so keeping up another window would just > hide something else, and having that tab there is handy. > > At one time, GNOME had the idea of dockable widgets (don't know if it still > does), so you could move widgets around, dock them here, there, etc. If that is > still possible, it would basically let users customize the interface however > they want (don't want the skills tab? Just dump it in the trash). > > A concern I have is that if one has too many options (checkboxes for what > stuff to show in the client vs windows), you potentially have a dozen checkboxes > down the road of what to show or not show - that isn't great. For the present, I think the current situation is acceptable. Those that care enough about layout can either figure out how to make their own, or ask for help getting a layout that supports their needs. While in concept the idea of giving greater flexibility is nice, the level of work it will take is probably not something worth doing at this point when so many other things can be done to improve the game. I do not at all like the idea of having to switch items on and off. What I think would be more practical would be to switch to an MDI interface and allow layout of the MDI to be saved and restored... either that, or figure out how hard it would be to implement what the gtk-v1 client did where you could glue windows together and save that state. Neither of those options probably require a bunch of configuration controls. Either way, I think that it is still important to offer options to people that have 15" or 17", or smaller, monitors... This was a huge factor in why it was so hard for me to move to the gtk-v2 layout and is why I did the libglade rewrite. I see requests for even smaller displays actively occurring. Whatever might be done in the future should not make it difficult for desktop-challenged users to play. > - The number of glade files probably needs to be controlled in some way - > otherwise, I could forsee a mass increase here, and the question then becomes > who supports them all. > > One thought is to take 3-4 core glade files and call them the > standard/supported ones, and the rest fall into a contrib area. What that means > is that if bugs are filed against the core ones, they should get fixed - if > filed against contrib ones, they don't, but whoever contributed that layout file > may feel compelled to fix it (or may not) - if a contributed layout gets so out > of date it isn't usable, it gets removed. I think 3-4 is too restrictive, but I agree that the number of officially distributed files needs to be controlled. There are currently 12 in the distribution, and I think that is too many. Otherwise, in general, I agree with these statements. I do think it is important, however to make it clear I do not agree that the number of .glade files in SVN should be suppressed unnecessarily. Obviously we do not want to go crazy with having files that are different only in minor details, so no argument there about restricting that sort of thing, but, it is advantageous to allow some designs that have proof-of-concept work in them for easy access. I think it should be possible for designers to have a favorite design in SVN without anyone fussing about it - even if it is not widely used. Controlling what is officially supported/distributed is as simple as controlling XML_FILES in gtk-v2/glade/Makefile.am. > - It would be nice to have a better way of switch layout files, or at least > seeing what they are. Having a .png file of each layout that that is perhaps > displayed would be one way. I would imagine it isn't impossible to have it > reconfigure the layout in real-time, but it may require destroying all the > widgets and re-creating them (this becomes an issue for images). My only > thought here is that I do wonder how many of those layouts really are used, > given that the mechanism for switching does require a restart (I don't know if > I'd want to restart my client 12 times to see all the different layouts) Yes. libglade can dynamically manage the XML at run-time. Ideally, it would be nice. Practically, I think the UI code needs some work to realize this. I am not sure it would not be better to start an effort like that from the ground up rather than to try to tweak this code base... Maybe as a move to GTK Builder... That said, I'm not looking to start an effort like that anytime soon. I think determining client usage might not be that hard. I think that it would be pretty easy for the client to register its layout usage with a server. We could then use servers like MetalForge or Invidious to get the data without having to rely on a human poll. > Probably got a bit off topic on some of these. If so, the change is good. Kevin From kbulgrien at att.net Mon Apr 19 19:54:18 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Mon, 19 Apr 2010 19:54:18 -0500 Subject: [crossfire] skill window In-Reply-To: <4BCBEBDD.9080008@sonic.net> References: <20100414201057.2f0a6376@angmar> <20100415221724.1f288b18@a850srvr.kbulgrien.att.net> <20100416143509.35233c29@angmar> <20100416183056.4fdb6dd2@a850srvr.kbulgrien.att.net> <20100417094144.3a8fe21e@angmar> <20100417135345.47cd897f@a850srvr.kbulgrien.att.net> <4BCB8BAC.10609@iki.fi> <4BCBEBDD.9080008@sonic.net> Message-ID: <20100419195418.0aa64b6b@a850srvr.kbulgrien.att.net> > - It would be nice to have a better way of switch layout files, or at least > seeing what they are. Having a .png file of each layout that that is perhaps > displayed would be one way. There are screen shots of the layouts on-line. Some of them need an update, and I think sixforty is not represented at all. A cheap way to do this would be to have the client configuration page have a link to this page. http://crossfire.real-time.com/clients/gtkv2_client.html Even so, a static .png can introduce you to a layout, but it doesn't really do a lot to help you figure out how the layout works dynamically. Still, I agree, something is better than nothing. The name doesn't do very much to help and having to restart the client is not very user-friendly. I certainly agree there is room for improvement. Kevin From kbulgrien at att.net Mon Apr 19 20:26:15 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Mon, 19 Apr 2010 20:26:15 -0500 Subject: [crossfire] skill window In-Reply-To: <4BCB8BAC.10609@iki.fi> References: <20100414201057.2f0a6376@angmar> <20100415221724.1f288b18@a850srvr.kbulgrien.att.net> <20100416143509.35233c29@angmar> <20100416183056.4fdb6dd2@a850srvr.kbulgrien.att.net> <20100417094144.3a8fe21e@angmar> <20100417135345.47cd897f@a850srvr.kbulgrien.att.net> <4BCB8BAC.10609@iki.fi> Message-ID: <20100419202615.3c0c634e@a850srvr.kbulgrien.att.net> > Kevin Bulgrien wrote: > > There seems little point to argue when the agenda is so destructive. > > ...misunderstandings and neglect create more confusion in this > world than trickery and malice. At any rate, the last two are > certainly much less frequent. > -- Johann Wolfgang von Goethe (1749-1832): > The Sorrows of Young Werther, 1774 > -- > /* * * Otto J. Makela * * * * * * * * * * * * * * * */ I appreciate the comment, and I agree with the quote. I do feel that likely the motive was not evil. I do, however, believe the agenda is and was destructive. One does not have to have malicious and trickery to have a destructive agenda. Whether or not a great deal of the issue was misunderstanding, the methods chosen where very, very poorly chosen. Even though my initial response was conciliatory, he chose to manipulate and escalate the situation, and clearly was striving to take control of the .glade file situation - gathering public opinion to override what he did not like or agree with. This taking over might not have been malicious at heart, but I know few people that would not interpret as such. For someone to dance in after years of development and try to grab control with so little dialog is destructive and thoughtless. If indeed he was pure in motive, surely he could have chosen to cooperate on deciding what was best - and I still don't see a .glade file in SVN that he has decided to maintain. It would be nice for that side of things to be recognized as well. I doubt that any developer would take tactics like this well, especially after I had redesigned something specifically for him. Even after the fact, I have made changes that he proposed. I'll be glad to move on. I hope he can do the same, and try to take a point about what kind of things tick people off. Kevin From kbulgrien at att.net Mon Apr 19 21:25:44 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Mon, 19 Apr 2010 21:25:44 -0500 Subject: [crossfire] Un Deux layout ok to remove vs V1-Redux? Message-ID: <20100419212544.09a9d054@a850srvr.kbulgrien.att.net> I think the skills panel addition is a very valuable addition, and appreciate the effort that went into making it. It's advent seems to have broken loose some more opportunities in UI design, including for thinning the field of .glade offerings. As a start, it is my opinion that either Un Deux or V1-Redux should be deprecated. http://crossfire.real-time.com/clients/gtkv2images/un-deux_748x600.png http://crossfire.real-time.com/clients/gtkv2images/v1-redux_773x600.png If I were to pick one to delete, it would be Un Deux because I find the swapped messages and inventory panels not to be something I care for. I would like to keep one of them, or one that combines some elements from each. I think there are too many .glade layouts in the distribution at present - without enough variety. This could be a start at thinning the field. Keeping Un Deux would help the "other" GTK-V1 look-alike to be more unique, but I have no idea if the swapped layout has any appeal at all. Before Un Deux goes away, please feel free to comment on whether this would bother anyone - though if there is an outcry after removal, it's not like a remove cannot be undone, or a swap redone. Does anyone particularly appreciate the message panels being on the left vs. on the right? On another note, I do plan to remove the skills/exp tab on which ever one is left active in SVN (whether or not it remains in an active distribution list). I suspect before its all over, most glade files will have the skills/exp pane removed. It is the most problematic of all the panels - in various respects. Feel free to comment on this as well. Kevin From kbulgrien at att.net Mon Apr 19 21:36:20 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Mon, 19 Apr 2010 21:36:20 -0500 Subject: [crossfire] Deprecation of eureka.glade? Message-ID: <20100419213620.7a7d09cb@a850srvr.kbulgrien.att.net> The eureka.glade layout was heavily influenced by the skills & experience tab, and, I believe that the addition of the skills window obsoletes this layout. http://crossfire.real-time.com/clients/gtkv2images/eureka_747x600.png I feel that the the shortened inventory/floor and message views are detrimental when the width is no longer needed for the width of the skills & experience panel. A lot of space is wasted by this layout when it is no longer needed to render the skills and experience data. Though I like the name because it has an in-game reference, I think it does not really add enough value to the .glade layout offerings to warrant keeping it alive. Feel free to register opinions pro or con to the deprecation of eureka.glade. Kevin From kbulgrien at att.net Mon Apr 19 22:43:06 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Mon, 19 Apr 2010 22:43:06 -0500 Subject: [crossfire] caelestis.glade up for modification Message-ID: <20100419224306.508eeaf5@a850srvr.kbulgrien.att.net> A key design point for caelestis.glade was that the GTK-V2 client used to make little use of the so-called Critical Messages pane. This made it seem reasonable to add it to a tab notebook since it added little value to the client. With the advent of the message control features in the GTK-V2 client, this design choice now seems to be a detriment to the layout. Furthermore, with the advent of the detached skills window, an opportunity has arisen to incorporate some user feedback into rework of this or another layout. A suggestion was put forward for the chthonic.glade to remove the skills and experience panel, and to place the character, core statistics, and protections information on a three-tab notebook. While I do not wish to change chthonic.glade to increase the use of notebook tabs for various reasons, it does seem reasonable to attempt an improvement on caelestis by both moving critical messages off of a notebook, and by moving the core stats and protections data to the character notebook after removing the skills and experience panel. The changes are in the works, as I believe the logic behind reworking the Critical Messages panel visibility is likely strong enough to anticipate which way response, if any, would fall, but feedback is welcome. Taking the original chthonic request to heart, a key difference between caelestis and chthonic is that the information is at the top of the screen on one layout and at the bottom of the other. I am amenable to changing caelestis to place the new three-tab notebook at the bottom of the display if one position is preferred over another. With no feedback, I will leave the notebook at the top. I had originally made a counter-proposal to rename chthonic.glade to eureka.glade and make the requested changes there, but, it does seem reasonable to remove eureka, and I am more reluctant to retire the caelestis name. While eureka has an in-game reference, the reason it was picked as a glade layout name was rather lame. From kbulgrien at att.net Mon Apr 19 22:51:21 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Mon, 19 Apr 2010 22:51:21 -0500 Subject: [crossfire] caelestis.glade up for modification In-Reply-To: <20100419224306.508eeaf5@a850srvr.kbulgrien.att.net> References: <20100419224306.508eeaf5@a850srvr.kbulgrien.att.net> Message-ID: <20100419225121.12bcaa37@a850srvr.kbulgrien.att.net> Discussed in this thread: http://crossfire.real-time.com/clients/gtkv2images/caelestis_790x600.png http://crossfire.real-time.com/clients/gtkv2images/chthonic_790x600.png > A key design point for caelestis.glade was that the GTK-V2 client used to > make little use of the so-called Critical Messages pane. This made it seem > reasonable to add it to a tab notebook since it added little value to the > client. > > With the advent of the message control features in the GTK-V2 client, this > design choice now seems to be a detriment to the layout. > > Furthermore, with the advent of the detached skills window, an opportunity > has arisen to incorporate some user feedback into rework of this or another > layout. > > A suggestion was put forward for the chthonic.glade to remove the skills and > experience panel, and to place the character, core statistics, and protections > information on a three-tab notebook. > > While I do not wish to change chthonic.glade to increase the use of notebook > tabs for various reasons, it does seem reasonable to attempt an improvement > on caelestis by both moving critical messages off of a notebook, and by > moving the core stats and protections data to the character notebook after > removing the skills and experience panel. > > The changes are in the works, as I believe the logic behind reworking the > Critical Messages panel visibility is likely strong enough to anticipate > which way response, if any, would fall, but feedback is welcome. > > Taking the original chthonic request to heart, a key difference between > caelestis and chthonic is that the information is at the top of the screen > on one layout and at the bottom of the other. I am amenable to changing > caelestis to place the new three-tab notebook at the bottom of the display > if one position is preferred over another. With no feedback, I will leave > the notebook at the top. > > I had originally made a counter-proposal to rename chthonic.glade to > eureka.glade and make the requested changes there, but, it does seem > reasonable to remove eureka, and I am more reluctant to retire the > caelestis name. While eureka has an in-game reference, the reason it > was picked as a glade layout name was rather lame. From kbulgrien at att.net Tue Apr 20 00:18:27 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Tue, 20 Apr 2010 00:18:27 -0500 Subject: [crossfire] skill window In-Reply-To: <4BCB8BAC.10609@iki.fi> References: <20100414201057.2f0a6376@angmar> <20100415221724.1f288b18@a850srvr.kbulgrien.att.net> <20100416143509.35233c29@angmar> <20100416183056.4fdb6dd2@a850srvr.kbulgrien.att.net> <20100417094144.3a8fe21e@angmar> <20100417135345.47cd897f@a850srvr.kbulgrien.att.net> <4BCB8BAC.10609@iki.fi> Message-ID: <20100420001827.165fce2b@a850srvr.kbulgrien.att.net> > > There seems little point to argue when the agenda is so destructive. > > ...misunderstandings and neglect create more confusion in this > world than trickery and malice. At any rate, the last two are > certainly much less frequent. > -- Johann Wolfgang von Goethe (1749-1832): > The Sorrows of Young Werther, 1774 Brendan, I did react too strongly, and I apologize for that. I imagine that the intent was to set up some kind of feedback mechanism to help client development. I should have been quicker to consider and acknowledge that, whether or not there remained issues with the implementation or other concerns. I also needed to be less quick to assume I understood and make more of an attempt to try to find more out about the upsetting elements. I am grateful for your many recent contributions to Crossfire, especially the skills dialog, as it changes the landscape for user interface challenge that have had me stuck for a while. In all fairness, that should be weighed in (a lot) more than it was. I do hope to move along and be over with this, though I recognize I have made it hard to do so. I ask for your forgiveness in this matter as my response was not respectful and was in itself hurtful. I will be more than happy to rework a .glade to your specifications, and plan to do so based on what I saw on the wiki. Sorry for the mess. Otto, Thank-you for inserting a bit of sanity into the thread and affording me the opportunity to review my reaction. Others, Apologies also for the splash-over... Kevin From kbulgrien at att.net Tue Apr 20 00:29:14 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Tue, 20 Apr 2010 00:29:14 -0500 Subject: [crossfire] skill window In-Reply-To: <20100419202615.3c0c634e@a850srvr.kbulgrien.att.net> References: <20100414201057.2f0a6376@angmar> <20100415221724.1f288b18@a850srvr.kbulgrien.att.net> <20100416143509.35233c29@angmar> <20100416183056.4fdb6dd2@a850srvr.kbulgrien.att.net> <20100417094144.3a8fe21e@angmar> <20100417135345.47cd897f@a850srvr.kbulgrien.att.net> <4BCB8BAC.10609@iki.fi> <20100419202615.3c0c634e@a850srvr.kbulgrien.att.net> Message-ID: <20100420002914.401bba32@a850srvr.kbulgrien.att.net> > I appreciate the comment, and I agree with the quote. Yeah... should not have hit send... but maybe that's what made me think. It was not supposed to go to the list, but if that was true, then it should not have been sent in the first place... so we're having a bad streak here. Sorry folks. /:-/ From mwedel at sonic.net Tue Apr 20 01:19:03 2010 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 19 Apr 2010 23:19:03 -0700 Subject: [crossfire] skill window In-Reply-To: <20100419190802.722c591a@a850srvr.kbulgrien.att.net> References: <20100414201057.2f0a6376@angmar> <20100415221724.1f288b18@a850srvr.kbulgrien.att.net> <20100416143509.35233c29@angmar> <20100416183056.4fdb6dd2@a850srvr.kbulgrien.att.net> <20100417094144.3a8fe21e@angmar> <20100417135345.47cd897f@a850srvr.kbulgrien.att.net> <4BCB8BAC.10609@iki.fi> <4BCBEBDD.9080008@sonic.net> <20100419190802.722c591a@a850srvr.kbulgrien.att.net> Message-ID: <4BCD4757.2080604@sonic.net> On 04/19/10 05:08 PM, Kevin Bulgrien wrote: > I do not at all like the idea of having to switch items on and off. What I > think would be more practical would be to switch to an MDI interface and > allow layout of the MDI to be saved and restored... either that, or figure > out how hard it would be to implement what the gtk-v1 client did where you > could glue windows together and save that state. Neither of those options > probably require a bunch of configuration controls. For the gtk-v1 client, there was an option for it to create a bunch of top level windows, which the player could move about and save their positions, but they never really got glued together beyond the player putting them next to each other. That wouldn't be that hard to do - one could make a half dozen top level windows in the glade layout file, and put the different widgets in there instead (eg, the map stuff goes into one of those instead of the top level window, the info stuff goes in the top level window instead of a container) - I believe some extra code would be need to realize them all, as well as load/save positions, but that in itself wouldn't be impossible. That said, I then do wonder if that is the best way... > > Either way, I think that it is still important to offer options to people > that have 15" or 17", or smaller, monitors... This was a huge factor in why > it was so hard for me to move to the gtk-v2 layout and is why I did the libglade > rewrite. I see requests for even smaller displays actively occurring. Whatever > might be done in the future should not make it difficult for desktop-challenged > users to play. Certainly there is need for several different options - never meant to imply there wasn't. > >> - The number of glade files probably needs to be controlled in some way - >> otherwise, I could forsee a mass increase here, and the question then becomes >> who supports them all. >> >> One thought is to take 3-4 core glade files and call them the >> standard/supported ones, and the rest fall into a contrib area. What that means >> is that if bugs are filed against the core ones, they should get fixed - if >> filed against contrib ones, they don't, but whoever contributed that layout file >> may feel compelled to fix it (or may not) - if a contributed layout gets so out >> of date it isn't usable, it gets removed. > > I think 3-4 is too restrictive, but I agree that the number of officially > distributed files needs to be controlled. There are currently 12 in the > distribution, and I think that is too many. Otherwise, in general, I agree > with these statements. > > I do think it is important, however to make it clear I do not agree that the > number of .glade files in SVN should be suppressed unnecessarily. Obviously > we do not want to go crazy with having files that are different only in minor > details, so no argument there about restricting that sort of thing, but, it is > advantageous to allow some designs that have proof-of-concept work in them for > easy access. I think it should be possible for designers to have a favorite > design in SVN without anyone fussing about it - even if it is not widely used. > > Controlling what is officially supported/distributed is as simple as controlling > XML_FILES in gtk-v2/glade/Makefile.am. > I'm not really sure what the correct number is, but looking at some of your other e-mails, some of the layouts are really the same but for something being swapped from one side to another, and that really becomes a preference issue (I like my info on left side instead of right) vs a functionality issue (I have a small screen and need a layout that works on it.) I don't even have much an issue with there being a bunch of layout files available and even in SVN (and rpm/packages for that matter). What I'm more concerned about is a clearer indication of what are the 'officially supported' (for lack of better term) layouts vs ones that have been contributed and people may find useful - it would clearly be good in the client to someone not which ones are contrib layouts. My main concern would be if something changed requiring an update to all layout files, I don't want to have to be updating 20 different layout files. Or for that matter, if a bug is filed against a layout - IIRC, there were/are bugs filed regarding formatting in some of the windows, and that will show up based on layout decisions in the layout itself. >> - It would be nice to have a better way of switch layout files, or at least >> seeing what they are. Having a .png file of each layout that that is perhaps >> displayed would be one way. I would imagine it isn't impossible to have it >> reconfigure the layout in real-time, but it may require destroying all the >> widgets and re-creating them (this becomes an issue for images). My only >> thought here is that I do wonder how many of those layouts really are used, >> given that the mechanism for switching does require a restart (I don't know if >> I'd want to restart my client 12 times to see all the different layouts) > > Yes. libglade can dynamically manage the XML at run-time. Ideally, it would be > nice. Practically, I think the UI code needs some work to realize this. I am > not sure it would not be better to start an effort like that from the ground up > rather than to try to tweak this code base... Maybe as a move to GTK Builder... > That said, I'm not looking to start an effort like that anytime soon. it seems like going to gtkbuilder would eventually happen. But I'm not particularly fond of doing a major rewrite either. One thing that might be easier (but still amount of work) is a further decoupling of the elements in the window and the window itself. For example, right now, there is the dialog.glade file which deals with all the pop up windows, so all the layouts don't reproduce that. Imagine same thing for most of the other widgets - there is a common file which has the declarations for the info widgets, map widgets, etc. The the current layout files really just become that - layout files - the notebooks, dividers, etc, would be there, and there would be some form of placeholder widget to note which widget goes where. At run time, the client process that layout file and walks the widget tree, finding those placeholder widgets. When it finds one, it uses information in that place holder to know what which widget in common file should get reparented to this location. In this way, the layout files themselves become very lightweight, and changes to any of the main elements just have to get done in that main/common file. And since you are already reparenting, it does allow the potential to allow user overrides (but how the user would set that up would be much trickier) > > I think determining client usage might not be that hard. I think that it would > be pretty easy for the client to register its layout usage with a server. We > could then use servers like MetalForge or Invidious to get the data without > having to rely on a human poll. Yes, that wouldn't be that hard - the client string that is sent is already free form, so putting in the name of the layout file wouldn't harm anything. It would require a little work to pull those strings out and tally them up. From brenlally at gmail.com Tue Apr 20 12:45:53 2010 From: brenlally at gmail.com (Brendan Lally) Date: Tue, 20 Apr 2010 18:45:53 +0100 Subject: [crossfire] skill window In-Reply-To: <20100420001827.165fce2b@a850srvr.kbulgrien.att.net> References: <20100414201057.2f0a6376@angmar> <20100415221724.1f288b18@a850srvr.kbulgrien.att.net> <20100416143509.35233c29@angmar> <20100416183056.4fdb6dd2@a850srvr.kbulgrien.att.net> <20100417094144.3a8fe21e@angmar> <20100417135345.47cd897f@a850srvr.kbulgrien.att.net> <4BCB8BAC.10609@iki.fi> <20100420001827.165fce2b@a850srvr.kbulgrien.att.net> Message-ID: <20100420184553.26ba9777@angmar> On Tue, 20 Apr 2010 00:18:27 -0500 Kevin Bulgrien wrote: > I imagine that > the intent was to set up some kind of feedback mechanism to help > client development. Pretty much, and also allow a way to determine if there is a desire for new layouts to be created (the point of making the wiki comment that I did was that if there was anyone who thought along similar lines, then that would give me sufficient reason to create it). > I do hope to move along and be over with > this, Absolutely. I'm sorry that a lot of this discussion has generated more heat than light, and I wish to apologise for the role I have played in that. In retrospect I should have asked the 'how are client layouts being updated now' question and then left the 'how can client layouts evolve and be maintained over time' issue for another thread at a later date. I am also now of the view that my earlier proposal was over-engineered. > I will be more than happy to rework a .glade > to your specifications, and plan to do so based on what I saw on the > wiki. I appreciate the offer, but please don't feel like there is a need to do so for my sake. There are lots of UI changes that ought to take place over the next few months in order to make it easier to use some of the existing game features, and these may well require additional thought in terms of how an interface layout should represent them. As such, it is likely that my local copies of the glade files will end up being a bit of a mess as I test things. To give you some idea of what I am thinking of: Medium term (ie, after the next release) I am looking at: * A 'knowledge browser' that doesn't involve typing in numbers to recall knowledge (preferably one that is ordered into categories, and somewhat crosslinked - ie, clicking an ingredient in a recipe should show you a recipe to make that ingredient if you know one). * A 'quest log' that will show information about current and completed quests. As I'm thinking currently, these might go into the 'player' menu, Longer-Term I am also thinking in terms of: * A nicer interface to the 'who' command, so that it brings up a list of players and allows 'tell' commands to be sent more easily (without typing in an (often difficult to spell) player's name) Possibly there could also be additional controls exposed for dms, things like muzzle and kick. * And then additional things like toggle buttons the 'obscure but useful commands' such as brace, bowmode, peaceful, afk, etc. I still don't really have a clear idea of where any of those could fit interface-wise, so that's something I'll be looking to discuss in more detail. Ultimately I want to be able to reach a point where: * it is possible to play crossfire without needing to type anything other than to chat with other players/NPCs. * None of the command-based functionality is lost since that gives a lot of power to keybindings (I just don't want to *need* to use them just to play the game). * The interface doesn't become cluttered. There would be times where these three aims would be in conflict, so I would welcome any discussion/thoughts on the most effective approach. There is a separate discussion to be had around creating more default keybindings for the client. The current approach is to explain right at the start of the game how to bind commands to keys, my view is that this is an intermediate/advanced topic, and shouldn't be something that a new player should want or need to care about until they are a few hours into the game. Brendan From brenlally at gmail.com Tue Apr 20 20:20:23 2010 From: brenlally at gmail.com (Brendan Lally) Date: Wed, 21 Apr 2010 02:20:23 +0100 Subject: [crossfire] 'Identified' tab in the inventory display (was: Auto ID on examine) In-Reply-To: <4BC986B8.9090909@iki.fi> References: <20100416214720.79b62ca8@angmar> <4BC986B8.9090909@iki.fi> Message-ID: <20100421022023.66a1c7d8@angmar> On Sat, 17 Apr 2010 13:00:24 +0300 "Otto J. Makela" wrote: > > What I would like to also see is having a class "identified" (similar > in function to "cursed" and "magic") in the inventory, so that you > could more easily manipulate items which you have identified. NB: In order to do this, a new flag would need to be defined for the item2 command, there is space for it, and clients should handle new flags gracefully, but I'd still want a bit of testing to take place. I can see how this might be useful, and I think there are four possible ways to approach it: 1) with another 'style' in the inventory display in the way that cursed and magic items are currently highlighted in red and blue respectively (possibly including (2) as well). 2) with a change to the item name in the inventory (maybe adding a ? after the name of unIDed items?) 3) Using a new notebook tab. (possibly in combination with (2) and/or (1)) 4) Rethinking the way that inventory filtering is done. Option 1) Creates an interesting question of precedence, since the same items that are unidentified are also often the ones that are known to be cursed or magical, it isn't clear which bit of information is the most important there. Option 2) Should pretty much work cleanly, but it may not be obvious enough on its own. Option 3) Is the one that is most consistent with the way other classes of objects are defined. The following is a screenshot I have taken of how the inventory pane on my client appears like with an additional tab added (the question mark) http://imagebin.ca/view/R6ofXm.html This illustrates a potential issue with adding additional tabs, I don't normally tend to have my inventory display any wider than this, and tend to lose the icon display (which I never use) anyway. Losing the 'unlocked items' tab would matter a bit more, since that's often my 'I have loot I need to dump' tab. This is using a 'full-size' layout, so I would imagine the situation would be worse for someone using one of the small-scale layouts (such as sixforty) Maybe Kevin can weigh in here, since he will be able to judge the impact on layouts more accurately than I can. For Option 4) I'd love to hear suggestions, I was half thinking of push buttons for toggling the display of different groups of items (ie, a button which is clicked once to show magic items only, again to show mundane items only and a third time to show all items again) - but I don't think tri-state buttons are a good move interface-wise Brendan. From brenlally at gmail.com Tue Apr 20 20:19:58 2010 From: brenlally at gmail.com (Brendan Lally) Date: Wed, 21 Apr 2010 02:19:58 +0100 Subject: [crossfire] Auto ID on examine In-Reply-To: <4BC986B8.9090909@iki.fi> References: <20100416214720.79b62ca8@angmar> <4BC986B8.9090909@iki.fi> Message-ID: <20100421021958.6bcc734c@angmar> On Sat, 17 Apr 2010 13:00:24 +0300 "Otto J. Makela" wrote: > Brendan Lally wrote: > > > This changes the way the examine command (triggered by left > > clicking on an object) works so that if the object is unidentified, > > and the player has the appropriate skill, then an attempt to > > identify the object is automatically made. > > > > The intention is that this should make the ID process much smoother > > for new players, and less likely to be discovered after wasting > > money on ID tables or selling items that were useful. > > This does change the overall game balance a bit (making it easier to > use skills automatically), but all-in-all I think it is a good change. I'd like to think that the change to game balance is only for the first few levels and only because with the current behaviour new players may lose money because they sell items before identifying them, or pay to identify items which they could have IDed for free because they had the appropriate skill to identify them. I'd consider such behaviour to be a challenge posed by the interface rather than the game itself. The flipside is that a player who would want to 'scum' exp by identifying a huge stack of arrows individually using a keybinding or script might accidentally click on the stack and 'lose' the exp they would've gained. I'm not sure that sort of behaviour that should be encouraged or rewarded though - even if I have done it myself in the (distant) past... Brendan. From agschult at ucalgary.ca Tue Apr 20 20:33:24 2010 From: agschult at ucalgary.ca (Alex Schultz) Date: Tue, 20 Apr 2010 19:33:24 -0600 Subject: [crossfire] Auto ID on examine In-Reply-To: <20100421021958.6bcc734c@angmar> References: <20100416214720.79b62ca8@angmar> <4BC986B8.9090909@iki.fi> <20100421021958.6bcc734c@angmar> Message-ID: <20100420193324.50b7ec53@ucalgary.ca> Just my 2 cents: > I'd consider such behaviour to be a challenge posed by the interface > rather than the game itself. Exactly why I like this change. The interface poses too many issues and this helps one such issue (out of very many...). From meflin at meflin.net Tue Apr 20 20:39:38 2010 From: meflin at meflin.net (James Lopeman) Date: Tue, 20 Apr 2010 19:39:38 -0600 Subject: [crossfire] Auto ID on examine In-Reply-To: <20100421021958.6bcc734c@angmar> References: <20100416214720.79b62ca8@angmar> <4BC986B8.9090909@iki.fi> <20100421021958.6bcc734c@angmar> Message-ID: <201004201939.39280.meflin@meflin.net> On Tuesday 20 April 2010 7:19:58 pm Brendan Lally wrote: > On Sat, 17 Apr 2010 13:00:24 +0300 > > "Otto J. Makela" wrote: > > Brendan Lally wrote: > > > This changes the way the examine command (triggered by left > > > clicking on an object) works so that if the object is unidentified, > > > and the player has the appropriate skill, then an attempt to > > > identify the object is automatically made. > > > > > > The intention is that this should make the ID process much smoother > > > for new players, and less likely to be discovered after wasting > > > money on ID tables or selling items that were useful. > > > > This does change the overall game balance a bit (making it easier to > > use skills automatically), but all-in-all I think it is a good change. > > I'd lik > few levels and only because with the e to think that the change to game balance is only for the firstcurrent behaviour new players may > lose money because they sell items before identifying them, or pay to > identify items which they could have IDed for free because they had the > appropriate skill to identify them. > > I'd consider such behaviour to be a challenge posed by the interface > rather than the game itself. > > The flipside is that a player who would want to 'scum' exp by > identifying a huge stack of arrows individually using a keybinding or > script might accidentally click on the stack and 'lose' the exp they > would've gained. > > I'm not sure that sort of behaviour that should be encouraged or > rewarded though - even if I have done it myself in the (distant) past... > > Brendan. There is no change to game balance for experienced players. At most it is a change in your available choices. Make a key-bind if you know how or spend a long time typing commands. Xp scumming takes experience and planning. After this change you can just pickup and run a script anyway. There is no reason to hose new players in the way it works now. I was thinking that it might be slightly better to create a new command "identify" that is pre-bound to i or some such. _BUT_ examine isn't a command most players know now. Left click is easy for new players to figure out and also easy for experienced players to avoid if they are xp farming. Sooner committed the better. Meflin Hater Of email lists From kbulgrien at att.net Wed Apr 21 00:02:37 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Wed, 21 Apr 2010 00:02:37 -0500 Subject: [crossfire] GTK-v2 Client Theme Extension Message-ID: <20100421000237.45c188c5@a850srvr.kbulgrien.att.net> I plan to extend the theme support in the GTK-V2 client slightly - to make it easier to customize the UI appearance without having to have access to the client theme directory, and to allow pin-point customization. The GTK-V2 client uses standard GTK rc files to implement the client themes. If the player did not configure a theme (None), the client uses GTK default style/theme setup from conventional places like /gtk-2.0/gtkrc and ${HOME}/.gtkrc-2.0. If the player has configured a custom client theme like "Standard" or "Black", the client adds the pathname of the selected theme file to the list of RC files that GTK will use for the client session. My extension will add to this in the following way. Whether the player has picked a theme or not, the client will add the following pathnames to the default RC file list: ${HOME}/.crossfire/gtkrc ${HOME}/.crossfire/.gtkrc This means that a player can now setup their own theme in the gtkrc file without having to have access to the client themes folder. The gtkrc file is universally applied, so it can either enhance a client theme like Black or Standard, but it will also be used when the theme is None. What does this mean: For example, if ${HOME}/.crossfire/gtkrc contains: style "default" { font_name = "Sans 8" } widget_class "*" style "default" All fonts in the client are set to Sans 8. Properties like italics, and bolding still get set normally. This may not be an ideal example, but it gets the point across. The second thing the extension does is allow for a glade-layout-specific theme file. For example, if, at run-time, the client is using sixforty.glade, after looking for ${HOME}/.crossfire/gtkrc, it will next look for a ${HOME}/.crossfire/sixforty.gtkrc file and use it if it exists. The point of this is to allow particular layouts to be tweaked by the player without impacting other layouts. The idea is that if one wanted to use a particular layout on a laptop when not connected to a really big monitor, you could even go so far as to customize the theme, not just the layout. When you get back home to the really big monitor, instead of fiddling with all your settings, you just switch layouts and can still have custom settings that only apply to it. Now, I realize this is a pretty geeky feature that is probably not going to get a lot of use as-is, but I think the options it adds are good because it puts the power in the player's hands without them having to have access to the "official" theme folder. But more than that, what it opens up is a possibility that at some point in the future, the client itself could put stuff in one or the other of these files, though I do not have a short-term plan to implement that at this time. Why am I doing this. There are a few basic reasons. 1) I liked that the GTK-V1 client rendered its widgets using a smaller font than GTK-V2 did. 2) Until yesterday, I never really figured out how to change GTK-V2 to use smaller fonts. Though I can wiki what I learned, it seems better to be able to wiki something that is client-specific that will not affect all other GTK applications the user might run. 3) I am still working on a player request for a working 640x480 layout, and I have one, but the giant font sizes are a real pain because they soak up so much space. I envision having some kind of sixforty.gtkrc file up somewhere and then referencing on a FAQ. You might ask why not just distribute a new SixForty theme file... Well, I thought of that, but then when I saw how simple it was to force a smaller font, I thought it was kind of silly to copy/paste/tweak Standard just to get a font size change, and, as is not presently the case with .glade files, this allows a very-special purpose file to be left out of the distribution, but very easy to install (copy to the .crossfire folder). Note that it doesn't matter in the least whether the ${HOME}/.crossfire gtkrc or .rc files are present or not. GTK happily goes along doing what it always did before if it does not find the files. This means that nobody will notice any difference in the client behavior. The original themes will continue to work as they always have. Kevin Bulgrien From mwedel at sonic.net Wed Apr 21 01:23:25 2010 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 20 Apr 2010 23:23:25 -0700 Subject: [crossfire] 'Identified' tab in the inventory display In-Reply-To: <20100421022023.66a1c7d8@angmar> References: <20100416214720.79b62ca8@angmar> <4BC986B8.9090909@iki.fi> <20100421022023.66a1c7d8@angmar> Message-ID: <4BCE99DD.3080309@sonic.net> On 04/20/10 06:20 PM, Brendan Lally wrote: > On Sat, 17 Apr 2010 13:00:24 +0300 > "Otto J. Makela" wrote: >> >> What I would like to also see is having a class "identified" (similar >> in function to "cursed" and "magic") in the inventory, so that you >> could more easily manipulate items which you have identified. > > NB: In order to do this, a new flag would need to be defined for the > item2 command, there is space for it, and clients should handle new > flags gracefully, but I'd still want a bit of testing to take place. > > > I can see how this might be useful, and I think there are four > possible ways to approach it: > > 1) with another 'style' in the inventory display in the way that > cursed and magic items are currently highlighted in red and > blue respectively (possibly including (2) as well). Note this can be overridden with theme also, so a special font or font color could be defined. > > 2) with a change to the item name in the inventory (maybe adding > a ? after the name of unIDed items?) Maybe a ? before so it is more visible - otherwise, for long names, it is just lost. For the players inventory, I had thought of the idea of adding an inventory management window, just like there is now a skills window, spell window, etc. My thought here is that when I'm out adventuring/killing things, I don't care much about an item the instant I pick it up. I may care if I reach my weight limit, and I probably care when I get back to town to sell the stuff I accumulated. But while adventuring, what I care about in my inventory is some set of important items - scrolls, potions, maybe even weapons or a few other items to switch back and forth. Since the times I care about all the junk I pick up is in town or other calm time periods (figuring out what to drop for weight/alchemy), I don't really need an expedited interface such that I can click on it right away - bringing up a window to manage it is fine. The advantage of a window is several - it allows more space to view the items, allows much better options for filtering (one could add filters for just weapons in addition to the currently cursed/magic/etc), it allows for some operations like 'sell all items', which in this context would sell all items currently displayed based on current filter. It also allows for customization for the different tabs. Right now, other than the locked item tab, there really isn't much of a way to control what item is in what tab during normal gameplay. But with a window, you could now set up item sets and/or choose which tab those items display in - thus, as a player I could have a cold item tab and a hot item tab (so I go to whichever one based on creature), or could have something like a healing tab (shows all healing related items) and an offensive tab. Point being that it would be possible to let the player choose this information. Item sets would basically be sets of items for fast apply, eg, one could define what item is in each set, and something like an 'apply set1' applies everything in first set, etc (more likely, player would set up keybindings for different sets) For that matter, such an interface could also easily allow players to set up keybindings to apply different items, so once again, easy to set up the 'apply scroll of remove confusion' keybinding. In such a window, I could see a layout something like: Image Name Weight Cursed Magical ID Equiped Value Keybinding ... sword 5 N N Y N 55 ... chainmail 60 N Y N Y 210 F3 ... at bottom, may have options like: [Drop All] [Identify All] [Drop Selected] [Identify Selected] ... As said, off topic, but I think long term, this is probably a better way to go as it adds a lot more options. I'd also like to utilize basically that same layout as a way to buy items from shops - it would show all the items in teh shop, with values, and have an option like 'buy selected' or the like. In this way, the shop menus are not needed anymore, and a player doesn't have to wander the shop trying to find the items they want From nicolas.weeger at laposte.net Fri Apr 23 13:51:25 2010 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 23 Apr 2010 20:51:25 +0200 Subject: [crossfire] Player file migration from branch to trunk Message-ID: <201004232051.28165.nicolas.weeger@laposte.net> Hello. The release of trunk being soon, I tested my player from Metalforge (thanks Leaf :)) on a trunk server. No anomaly detected, all skills are apparently ok, spells seem to work too. Apartments (unique maps) seem ok too - tried the lonetown one, underground and upper, were fine. Server with -d didn't report anything unusual. Did anyone else try? My first conclusion is that branch player files can just be used as it. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20100423/4e4aea9c/attachment.pgp From kbulgrien at att.net Fri Apr 23 18:40:36 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Fri, 23 Apr 2010 18:40:36 -0500 Subject: [crossfire] GTK-V2 and the gtk-v2.glade problem Message-ID: <20100423184036.21b90722@a850srvr.kbulgrien.att.net> The GTK-V2 client gets a bad rap because the default sizing has been removed from the layout. People who start up the client think it is not working because it is all jumbled, etc. I think either the change should be reverted, or a different, more first-timer friendly layout made the default. I understand that the defaults were removed to prevent issues with making the layout smaller than default, but IMO this is the wrong way to fix it. People are trying to play on gtk-v1 which doesn't work anymore on new servers. This is not going to go well for getting new players. It puts people off right at the start when they can't make heads or tails of what to do. It should not be a first-time players job to have to unjumble a display. It should come up right, and the complexity of adjusting display hassle should be deferred until after they see they love the game. With the release coming up, I think that this is a non-trivial issue, and suggest that gtk-v2.glade be fixed to be more friendly, or replaced as the default. Kevin Bulgrien From mwedel at sonic.net Sat Apr 24 00:07:13 2010 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 23 Apr 2010 22:07:13 -0700 Subject: [crossfire] GTK-V2 and the gtk-v2.glade problem In-Reply-To: <20100423184036.21b90722@a850srvr.kbulgrien.att.net> References: <20100423184036.21b90722@a850srvr.kbulgrien.att.net> Message-ID: <4BD27C81.6060406@sonic.net> On 04/23/10 04:40 PM, Kevin Bulgrien wrote: > The GTK-V2 client gets a bad rap because the default sizing has been removed > from the layout. People who start up the client think it is not working > because it is all jumbled, etc. I think either the change should be reverted, > or a different, more first-timer friendly layout made the default. > > I understand that the defaults were removed to prevent issues with making > the layout smaller than default, but IMO this is the wrong way to fix it. > People are trying to play on gtk-v1 which doesn't work anymore on new > servers. This is not going to go well for getting new players. It puts > people off right at the start when they can't make heads or tails of what > to do. It should not be a first-time players job to have to unjumble a > display. It should come up right, and the complexity of adjusting display > hassle should be deferred until after they see they love the game. > > With the release coming up, I think that this is a non-trivial issue, and > suggest that gtk-v2.glade be fixed to be more friendly, or replaced as > the default. As noted, the issue was that if the layout sizes were set, this ended up restricting the how small different things could be resized. As such, folks on lowish resolution systems found they couldn't resize things small enough. The size values could be put in place again, but unless things have changed in glade/gtk, I suspect the same issue will arise. I don't know how the other layouts get around this - maybe the default positioning/sizes that gtk chooses is more reasonable on different layout, or maybe some of the other layouts don't have the same minimum size restrictions (eg, won't allow resize below some size). I have no issue making a different layout the default if it works better. I don't know if the gtk2 layout can get fixed purely in the glade file. A non glade method would basically be to have a predefined set of position files for the layout that the client uses if there is no per user layout. An even more clever approach would be to have different positions get used based on size - gtk-v2.1024x768.pos, gtk-v2.1600x1200.pos, etc. But I suspect the even more clever approach is to choose different layouts by default based on the resolution of the system - if user has 640x480 resolution, probably the sixforty layout should be used, if 1028x768 another one may be a better fit, etc. From kbulgrien at att.net Sat Apr 24 00:29:53 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Sat, 24 Apr 2010 00:29:53 -0500 Subject: [crossfire] GTK-V2 and the gtk-v2.glade problem In-Reply-To: <20100423184036.21b90722@a850srvr.kbulgrien.att.net> References: <20100423184036.21b90722@a850srvr.kbulgrien.att.net> Message-ID: <20100424002953.00791597@a850srvr.kbulgrien.att.net> > The GTK-V2 client gets a bad rap because the default sizing has been removed > from the layout. People who start up the client think it is not working > because it is all jumbled, etc. I think either the change should be reverted, > or a different, more first-timer friendly layout made the default. > > I understand that the defaults were removed to prevent issues with making > the layout smaller than default, but IMO this is the wrong way to fix it. > People are trying to play on gtk-v1 which doesn't work anymore on new > servers. This is not going to go well for getting new players. It puts > people off right at the start when they can't make heads or tails of what > to do. It should not be a first-time players job to have to unjumble a > display. It should come up right, and the complexity of adjusting display > hassle should be deferred until after they see they love the game. > > With the release coming up, I think that this is a non-trivial issue, and > suggest that gtk-v2.glade be fixed to be more friendly, or replaced as > the default. > > Kevin Bulgrien Well, I played around with it a long time tonight to try to fix without putting the sizes back in and didn't get anywhere... Not sure there is a quick fix unless we find some GTK/glade geniuses somewhere. That said, I think there are issues that aggravate it. I think homogenous on some of those widgets is contributing to the mess. On another note, I can trigger the lockup MasseR was seeing by fiddling with shrink settings on widgets in an hpane or vpane. The freeze up appears to be related to desktop size and client size. I might get a freeze at one desktop resolution, change it, and it won't freeze up. I can fix it at one res by adding a viewport in a key location, but then it freezes at another desktop resolution. When it freezes, you are stuck with a blank client and metaserver page. Running under GDB shows you stuck in a metaserver loop. Shrink allows you to shrink a widget below its requisition. Seems something in gtk/libglade gets annoyed at times when you do that under certain conditions. From kbulgrien at att.net Sat Apr 24 15:44:58 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Sat, 24 Apr 2010 15:44:58 -0500 Subject: [crossfire] GTK-V2 and the gtk-v2.glade problem In-Reply-To: <20100424002953.00791597@a850srvr.kbulgrien.att.net> References: <20100423184036.21b90722@a850srvr.kbulgrien.att.net> <20100424002953.00791597@a850srvr.kbulgrien.att.net> Message-ID: <20100424154458.2b38a528@a850srvr.kbulgrien.att.net> With top of SVN, I set my screen to 640x480 and tried it. I was able to make it play without a restart. The messages/inventory panel are not visible, but one can see the hpane handle and move it into view. The map fits too small a space, and is very buggy at the default size. Map tiles often do not change off of black, but, one can put the stats down and the map starts to work ok. I guess with that, it is probably good enough, though the inventory data is scrambled unless you make the pane quite wide (due to use of homogenous), and, the skills/exp are hard to fit. I think Mark was amenable to removing that pane with the skills window in existence. I think that would help a lot, as I think that is the one that people often have trouble with. It also uses homogenous, which allows things to overlap horribly. sixforty.glade found a way around that, by putting that panel in a scrolled window and getting rid of homogenous - so it did not have to mess up when there was not enough room, and the player could grab the scroll bar to see the rest of the stuff. From kbulgrien at att.net Wed Apr 28 02:20:12 2010 From: kbulgrien at att.net (Kevin Bulgrien) Date: Wed, 28 Apr 2010 02:20:12 -0500 Subject: [crossfire] GTK-V2 init_connection() change. Message-ID: <20100428022012.40b74f8e@a850srvr.kbulgrien.att.net> This took me way out of my comfort zone, but in trying to fix another bug in the client, I experienced several really hard lockups that traced down to the connect() call inside init_connection() found in common/client.c. The lockup lasted 3 minutes before the client came back. During this time the client UI was completely unresponsive (white screen). I have also gotten into this situation a number of times when the metaserver went down, and I find it really annoying. When I commented about this on IRC, the suggestion was made to consider multi-threading the client as a solution. I know I'm not up to that yet, but, what I found out was that the connection attempts are made in blocking mode. After some research, I found out how to implement a timeout by temporarily configuring the socket in non-blocking mode during the connection. I made a change to the existing code to block no longer than 30 seconds. It was tempting to put in a shorter timeout, but then I remembered that a DNS lookup failure can take about 30 seconds, so at least for now I went with 30 seconds as it is significantly better than 3 minutes. I made no attempt to modify code that did not run on my system, so the case where !HAVE_GETADDRINFO || WIN32 has not been modified. It seems that it might be possible to refactor the code a tiny bit to make it possible to implement in that case without having to copy/paste the changes. The code changes could bear some testing on other systems, though I suspect the changes are not problematic for different platforms. I did not skimp on the error reporting, and implemented various checks that I saw while researching how to implement non-blocking connection attempts. It's probably kind of in-depth for a game client, but... The commit is 13015. If this change causes to much trouble, that is the only change made in the commit, so it should be easy to revert if need be. Kevin Bulgrien From brenlally at gmail.com Thu Apr 29 09:48:31 2010 From: brenlally at gmail.com (Brendan Lally) Date: Thu, 29 Apr 2010 15:48:31 +0100 Subject: [crossfire] Pickup Drop Event expansion Message-ID: <20100429154831.02f1a45f@angmar> Hi All, Quite a minor patch this, but one that has an impact on script/map compatibility, so I figure it should probably go here. https://sourceforge.net/tracker/?group_id=13833&atid=313833 This patch changes the meaning of the return types from event_pickup and event_drop. The initial motivation for this was in developing an implementation of draughts (something which is still at quite an early stage) and needing to be able to prevent an item from being picked up under certain conditions (ie by the player playing the other colour). The current behaviour of event pickup isn't helpful for this because the item disappears if the pickup fails. So what I have done is altered the meaning of the return values, rather than 0 meaning 'item may be picked up' and non-zero meaning 'item may not be picked up' I have 0 meaning 'item may be picked up' negative meaning 'item will disappear rather than being picked up' and positive meaning 'item will stay where it is' Because picking up and dropping items are opposing actions, it follows that they should have the same relative meaning for their return types, hence event_drop is altered too. The only immediate effects of this will be to give a cleaner way for QuestEssentialUntil.py to handle item dropping (returning negative and writing a custom message rather than setting start equip and showing the default 'the gods who lent it to you' message) Although I think navar_midane_pickup.py might need amended also, and possibly also cf_darcap. Brendan.