From nicolas.weeger at laposte.net Sun Oct 1 05:06:31 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 1 Oct 2006 12:06:31 +0200 Subject: [crossfire] Pupland Monunent Service In-Reply-To: <451DCF5A.2050406@telus.net> References: <451DCF5A.2050406@telus.net> Message-ID: <200610011206.31483.nicolas.weeger@laposte.net> Le Samedi 30 Septembre 2006 03:58, Alex Schultz a ?crit?: > Currently, the hall of fame in pupland just sits there static, so I'm > thinking that perhaps I should make a python script replacement for the > monument service, to inscribe the names of those who have beat the evil > masters if they want it inscribed. Anyone have any objections to > replacing the monument with a 'magical' python based one? good idea to me too :) Nicolas From alex_sch at telus.net Sun Oct 1 18:26:54 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 01 Oct 2006 17:26:54 -0600 Subject: [crossfire] useful macros in crossfire Message-ID: <45204EBE.7080002@telus.net> Often when looking through code, I notice that that many code snippets are repeated in many places, often with variations on how to do the same task. The best example is iterating through stacks of objects, because loops for that are implemented in many different places, with quite a few needless variations. Another example is "if ob->head ob=ob->head;" while not complex, might be more readable as something like "ob = GET_HEAD(ob);". I propose that we add the following macros or similar to the crossfire code to make things cleaner: #define TRANSVERSE_STACK_DOWN(ob, tmp) for((tmp)=(ob); (tmp), (tmp)=(tmp)->below) #define TRANSVERSE_STACK_UP(ob, tmp) for((tmp)=(ob); (tmp), (tmp)=(tmp)->above) #define TRANSVERSE_INV(ob, tmp) TRANSVERSE_STACK_DOWN((ob)->inv, (tmp)) #define TRANSVERSE_FLOOR(m, x, y, tmp) TRANSVERSE_STACK_UP(GET_MAP_OB((m), (x), (y)), (tmp)) #define GET_HEAD(ob) ((ob)->head ? (ob)->head : (ob)) #define TRANSVERSE_MULTITILE(ob, tmp) for((tmp) = GET_HEAD(ob)->arch; (tmp); (tmp) = (tmp)->more) #define TRANSVERSE_ARCHETYPES(tmp) for((tmp)=first_archetype; (tmp); (tmp)=(tmp)->next) #define TRANSVERSE_OBJECTS(tmp) for((tmp)=objects; (tmp); (tmp)=(tmp)->next) #define GET_NROF(ob) ((ob)->nrof ? (ob)->nrof : 1) I'm not sure how useful the last four are, however I know they're used in some places and would be good for convenience. Anyone have any objections to making macros for these? Also, does anyone have any other ideas for good macros? Alex Schultz From mwedel at sonic.net Sun Oct 1 19:48:30 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 01 Oct 2006 17:48:30 -0700 Subject: [crossfire] useful macros in crossfire In-Reply-To: <45204EBE.7080002@telus.net> References: <45204EBE.7080002@telus.net> Message-ID: <452061DE.1050407@sonic.net> Alex Schultz wrote: > Often when looking through code, I notice that that many code snippets > are repeated in many places, often with variations on how to do the same > task. The best example is iterating through stacks of objects, because > loops for that are implemented in many different places, with quite a > few needless variations. Another example is "if ob->head ob=ob->head;" > while not complex, might be more readable as something like "ob = > GET_HEAD(ob);". I propose that we add the following macros or similar to > the crossfire code to make things cleaner: Generally speaking, just because the code is repeated, it isn't necessarily bad if the the expanded code isn't very long, is clear to understand, and is unlikely to need global replacement because of some other change in the the code. OTOH, I'm pretty use to the code, so when I see most of those operations, it is pretty clear to me what it is doing. I'm more inclined to accept the GET_.. ones than the TRANSVERSE ones. They seem cleaner - maybe it is just me, but having something like: TRANSVERSE_INV() { } seem a bit more confusing to me, as it is actually hiding the operation from you, which may be relevant depending on what you do in that inner loop. That could perhaps be improved by calling them something like FOREACH, which better describes what it is doing. But also, I think that several of the TRANSVERSE macros as is will have problems, as I know there is code like: for (tmp=ob->inv; tmp && next; tmp=next ) { next = tmp->below } Because depending on operations, you can't rely on tmp->below to be accurate after doing remove_ob or insert_ob calls. This is true for both inventory and map loops. So that now needs another set of macros to take that third object pointer. To me, going through the code and updating all those code snippets would be near the bottom of the list of things to do, given the fairly long TODO list that there currently is (and given that the this doesn't effectively change the operation of any of the code, it just changes how it looks). But making the macros available and used in new code may not be a bad thing. From alex_sch at telus.net Sun Oct 1 20:39:40 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 01 Oct 2006 19:39:40 -0600 Subject: [crossfire] useful macros in crossfire In-Reply-To: <452061DE.1050407@sonic.net> References: <45204EBE.7080002@telus.net> <452061DE.1050407@sonic.net> Message-ID: <45206DDC.7030206@telus.net> Mark Wedel wrote: > Generally speaking, just because the code is repeated, it isn't > necessarily > bad if the the expanded code isn't very long, is clear to understand, and is > unlikely to need global replacement because of some other change in the the code. > However, IMHO it is a problem when functionally identical pieces of code are written many different ways and can be confusing to people who are new to the code. > OTOH, I'm pretty use to the code, so when I see most of those operations, it > is pretty clear to me what it is doing. > I'm also pretty used to the code, however the thing about the same operation being written 50 different ways does bother me a bit, plus I recall that back when I first was looking at the codebase about a year and a half ago, those things sometimes took me a little while to figure out. Also, one potentially confusing thing sometimes, is that with inventories one has to go up through the stack of objects, however with objects on the ground one must search down, which while being something I'm quite used to now, is not something that is not necessarily clear to less familiar programmers. > I'm more inclined to accept the GET_.. ones than the TRANSVERSE ones. They > seem cleaner - maybe it is just me, but having something like: > > TRANSVERSE_INV() { > } > > seem a bit more confusing to me, as it is actually hiding the operation from > you, which may be relevant depending on what you do in that inner loop. That > could perhaps be improved by calling them something like FOREACH, which better > describes what it is doing. > Hmm, FOREACH would probably be better. I was just using transverse because that's an accurate term that I usually describe these operations as, however FOREACH is probably better for this, partially because it's more familiar to programmers in certain languages. Well, though it hides some operation anyone who can understand the loops as now, easily could easily find out how the macros work, especially so if they're also documented. Also it leaves less room for mistakes; It can be rather frustrating to accidentally make a off by one error in the loop, or transverse the wrong direction. > But also, I think that several of the TRANSVERSE macros as is will have > problems, as I know there is code like: > > for (tmp=ob->inv; tmp && next; tmp=next ) { > next = tmp->below > } > > Because depending on operations, you can't rely on tmp->below to be accurate > after doing remove_ob or insert_ob calls. This is true for both inventory and > map loops. So that now needs another set of macros to take that third object > pointer. > That is indeed an issue, though one could always make "SAFE_TRANSVERSE_*" versions which use an extra tmp variable to store the next one. Also, here we have a perfect demonstration the above mentioned issue off by one errors, it just so happens that your example here will stop one short of the end of the inventory, because next will be NULL when one away from the bottom of the inventory which will stop the loop ;) > To me, going through the code and updating all those code snippets would be > near the bottom of the list of things to do, given the fairly long TODO list > that there currently is (and given that the this doesn't effectively change the > operation of any of the code, it just changes how it looks). But making the > macros available and used in new code may not be a bad thing. Agreed. Alex Schultz From kbulgrien at worldnet.att.net Wed Oct 4 21:38:57 2006 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Wed, 4 Oct 2006 21:38:57 -0500 Subject: [crossfire] Newly modified spring_trap() passes uninitialized ptr and crashes server. Message-ID: <200610042138.57951.kbulgrien@worldnet.att.net> Here is a backtrace for a crash on x86_64 but not on metalforge http://rafb.net/paste/results/nwRjEf71.html Uninitialized ptr... env in spring_trap is passed to get_rangevector and is used without checking it first. http://rafb.net/paste/results/nHaX0I34.html Revision 4979 modified spring_trap() 8 days, 20 hours ago get_rangevector() call was moved up before env was initialized and get_rangevector() assumes the pointer is good and uses it. http://svn.sourceforge.net/viewvc/crossfire/server/branches/1.x/server/rune.c?view=diff&r1=4978&r2=4979 From alex_sch at telus.net Wed Oct 4 23:33:19 2006 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 04 Oct 2006 22:33:19 -0600 Subject: [crossfire] Newly modified spring_trap() passes uninitialized ptr and crashes server. In-Reply-To: <200610042138.57951.kbulgrien@worldnet.att.net> References: <200610042138.57951.kbulgrien@worldnet.att.net> Message-ID: <45248B0F.4000201@telus.net> Kevin R. Bulgrien wrote: > Uninitialized ptr... env in spring_trap is passed to get_rangevector and is > used without checking it first. > > http://rafb.net/paste/results/nHaX0I34.html > > Revision 4979 modified spring_trap() 8 days, 20 hours ago > > get_rangevector() call was moved up before env was initialized and > get_rangevector() assumes the pointer is good and uses it. > > http://svn.sourceforge.net/viewvc/crossfire/server/branches/1.x/server/rune.c?view=diff&r1=4978&r2=4979 Ack, sorry about that. My mistake. Fixing that now. Alex Schultz From mwedel at sonic.net Sat Oct 7 13:44:20 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 07 Oct 2006 11:44:20 -0700 Subject: [crossfire] Removal of output-count/output-sync from server Message-ID: <4527F584.7070804@sonic.net> I've been working on updating the server to use draw_ext_info() calls and remove all draw_info_calls() - I mentioned this in another e-mail. One area that could use cleanup IMO is the output buffer handling in the server. For background, this is the code that combines messages so instead of getting: You hit orc You hit orc You hit orc You get 3 times You hit orc Now originally, that code was put in when the display logic was still part of the server, and the display options were not as good (specifically, lack of long scrollback buffers and only single pane displaying the messages). So I'd like to remove that code. The only real argument I can think against it is that by having it in the server, there is some bandwidth savings (server combines messages before being sent). However, I find it hard to believe that the savings are going to be very significant compared to the rest of the bandwidth consumed. If I don't hear any complaints, I'll remove that code. One question is whether it makes sense to put that code into the client. Given that both GTK clients have multiple panes for messages, and the only thing that really benefits from this combinining messages is the attack messages, the amount of benefit isn't as great. Plus, since the attack messages where changed to be more variable in terms of what they print, those often can not be combined. IT seems the main area of benefit is spells. Now one minor issue here is that within the server, there is the NDI_UNIQUE to say if it should be collapsed or not, and that isn't passed on to the client. However, with the draw_ext_info, type/subtype of the message is passed to the client, and with that, the client could make pretty intelligent choices on if it may be a message that it could try to buffer (basically, if it isn't an attack of spell message, probably not worth it). Thoughts? From alex_sch at telus.net Sat Oct 7 14:58:40 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 07 Oct 2006 13:58:40 -0600 Subject: [crossfire] HallOfSelection in crossfire 2.0 Message-ID: <452806F0.9030608@telus.net> It's not a big thing, just a little detail, but it's a fun thing. I'm thinking that the top section of the HallOfSelection that's displayed when players are logging in, should have some cosmetic changes in the trunk (2.0 branch). It would be nice if to make it so what was displayed there would be something that would make players think something like "Ooh, this looks shiny" when they first see it, and when seeing in the future, can at the slightest glance be like "Neat, a 2.0 server". I'm thinking that it would be neat to use either movers or the cfanim plugin to make an interesting animation for it. Anyone have any comments on this simple but fun idea? :) Alex Schultz From brenlally at gmail.com Sat Oct 7 19:44:47 2006 From: brenlally at gmail.com (Brendan Lally) Date: Sun, 8 Oct 2006 01:44:47 +0100 Subject: [crossfire] Removal of output-count/output-sync from server In-Reply-To: <4527F584.7070804@sonic.net> References: <4527F584.7070804@sonic.net> Message-ID: <7903f03c0610071744v2fa01ce1m924ddf6dfef68989@mail.gmail.com> On 10/7/06, Mark Wedel wrote: > One area that could use cleanup IMO is the output buffer handling in the server. > > ... > > One question is whether it makes sense to put that code into the client. > Given that both GTK clients have multiple panes for messages, and the only thing > that really benefits from this combinining messages is the attack messages, the > amount of benefit isn't as great. Plus, since the attack messages where changed > to be more variable in terms of what they print, those often can not be > combined. IT seems the main area of benefit is spells. The other useful one is searching for traps, especially at low levels, I find that a small number of searches isn't sufficiant, and will hold down the 's' key for a while, using the output count to bundle the messages into groups of 10. That way I can search 50-100 times (depending on how bored/paranoid I am feeling) without having the searching messages spam the message list hopelessly. Potentially client side support for this could be much better than existing server-side support (if it were to say redraw the last message on the same line it was on but with 'n times:' prepended to it), but no existing clients do that. From subs at eracc.com Sun Oct 8 11:07:46 2006 From: subs at eracc.com (ERACC Subscriptions) Date: Sun, 8 Oct 2006 11:07:46 -0500 Subject: [crossfire] Removal of output-count/output-sync from server In-Reply-To: <7903f03c0610071744v2fa01ce1m924ddf6dfef68989@mail.gmail.com> References: <4527F584.7070804@sonic.net> <7903f03c0610071744v2fa01ce1m924ddf6dfef68989@mail.gmail.com> Message-ID: <200610081107.47099.subs@eracc.com> On Saturday 07 October 2006 07:44 pm Brendan Lally wrote: > On 10/7/06, Mark Wedel wrote: > > One area that could use cleanup IMO is the output buffer handling in > > the server. > > > > ... > > > > One question is whether it makes sense to put that code into the > > client. Given that both GTK clients have multiple panes for messages, and > > the only thing that really benefits from this combinining messages is the > > attack messages, the amount of benefit isn't as great. Plus, since the > > attack messages where changed to be more variable in terms of what they > > print, those often can not be combined. IT seems the main area of > > benefit is spells. > > The other useful one is searching for traps, especially at low levels, > I find that a small number of searches isn't sufficiant, and will hold > down the 's' key for a while, using the output count to bundle the > messages into groups of 10. That way I can search 50-100 times > (depending on how bored/paranoid I am feeling) without having the > searching messages spam the message list hopelessly. > > Potentially client side support for this could be much better than > existing server-side support (if it were to say redraw the last > message on the same line it was on but with 'n times:' prepended to > it), but no existing clients do that. Yes, I use it too to control how much garbage scrolls by in my client. Please don't remove that until there is a replacement in the client. Gene Alexander -- Mandriva Linux release 2006.0 (Official) for i586 11:06:13 up 3:19, 7 users, load average: 0.05, 0.27, 0.19 ERA Computers & Consulting - http://www.eracc.com/ <- get VOIP here! eComStation, Linux, FreeBSD, OpenServer & UnixWare preloads & sales From kbulgrien at att.net Sun Oct 8 19:42:28 2006 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Sun, 08 Oct 2006 19:42:28 -0500 Subject: [crossfire] msg/endmsg in maps/objects References: <45163C53.8010501@sonic.net> <451785BB.3050500@sonic.net> Message-ID: Mark Wedel wrote: > Kevin R. Bulgrien wrote: >> Mark Wedel wrote: >>> Ideally, I think most of the newlines from the msg/endmsg structures >>> should be >>> removed - the client is plenty smart enough to do proper wrapping. >>> There are also a few messages which should have the '[fixed]' tag added, >>> since they are maps or diagrams, and just don't look right when printed >>> with the proportional font. BTW, not sure what "proper wrapping" means. In gcfclient, it mercilessly chops the text to fit the window. Word boundaries are not honored. >> How about blank lines? Is this discouraged in order to consume less >> vertical space, or is it seen to be acceptable for improving readability >> for longer multi-paragraph output? > > I'd say they should be there for readability. Without a blank line, it > can be very difficult to really see where the paragraph breaks are. > > In addition, this really only comes up with NPC messages - generally, > I'd say those are a relatively small portion of the total text output > (things like attack messages being much more prevalant), and I can't > imagine a couple extra newlines being that big a deal. It turns out, blank lines are stripped. I don't know how to add blank lines. This is can be problematic when you use split windows because, for example, if you walk down the main drag in scorn reading all the signs, all the output is just strung in sequence with no separation between signs or headings. It is pretty hard to scroll back and see what happened, and, it is hard for any given message to be well formatted so that paragraphs are separated nicely. Does anyone know how to output a blank line in message text? I tried \n, but it does not seem to work. Kevin From kbulgrien at worldnet.att.net Sun Oct 8 20:11:05 2006 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 8 Oct 2006 20:11:05 -0500 Subject: [crossfire] msg/endmsg in maps/objects Message-ID: <200610082011.05203.kbulgrien@worldnet.att.net> Mark Wedel wrote: > Kevin R. Bulgrien wrote: >> Mark Wedel wrote: >>> Ideally, I think most of the newlines from the msg/endmsg structures >>> should be >>> removed - the client is plenty smart enough to do proper wrapping. >>> There are also a few messages which should have the '[fixed]' tag added, >>> since they are maps or diagrams, and just don't look right when printed >>> with the proportional font. BTW, not sure what "proper wrapping" means. In gcfclient, it mercilessly chops the text to fit the window. Word boundaries are not honored. >> How about blank lines? Is this discouraged in order to consume less >> vertical space, or is it seen to be acceptable for improving readability >> for longer multi-paragraph output? > > I'd say they should be there for readability. Without a blank line, it > can be very difficult to really see where the paragraph breaks are. > > In addition, this really only comes up with NPC messages - generally, > I'd say those are a relatively small portion of the total text output > (things like attack messages being much more prevalant), and I can't > imagine a couple extra newlines being that big a deal. It turns out, blank lines are stripped. I don't know how to add blank lines. This is can be problematic when you use split windows because, for example, if you walk down the main drag in scorn reading all the signs, all the output is just strung in sequence with no separation between signs or headings. It is pretty hard to scroll back and see what happened, and, it is hard for any given message to be well formatted so that paragraphs are separated nicely. Does anyone know how to output a blank line in message text? I tried \n, but it does not seem to work. >> Is there an advantage to using leading whitespace acceptable to inset >> example >> text? I think so, but wonder what others might think. > > Depends on what you mean by example text. > > Also, look at the server/doc/mediaTags file - it supports a limited > number of > HTML like tags. What this really means is that within a message itself, > you can change various attributes (like make the text italic, or change > the color, use > fixed width fonts, etc). Using those tags is probably better than using > indentation. mediaTags seem to be of limited usefulness, or are broken. The following DOES NOT work... The tags are output as text, at least in the GTK 1 client. The tags appear to be applicable only for cases where server code writes to the client, but not when that text is extracted from an arch msg block. arch crone name Servant of Gaea msg @match Gaea|gaea|Mother|mother We are the children of Gaea. Kneel down and pray your mother. Feel [color=#00FF00]Her[/color] [b]force[/b] under your feet. @match * I am celebrating Gaea, our Mother. endmsg x 13 y 6 end Kevin From kbulgrien at att.net Sun Oct 8 21:27:52 2006 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Sun, 8 Oct 2006 21:27:52 -0500 Subject: [crossfire] HallOfSelection in crossfire 2.0 In-Reply-To: <452806F0.9030608@telus.net> References: <452806F0.9030608@telus.net> Message-ID: <200610082127.52288.kbulgrien@att.net> On Saturday 07 October 2006 02:58 pm, Alex Schultz wrote: > It's not a big thing, just a little detail, but it's a fun thing. I'm > thinking that the top section of the HallOfSelection that's displayed > when players are logging in, should have some cosmetic changes in the > trunk (2.0 branch). It would be nice if to make it so what was displayed > there would be something that would make players think something like > "Ooh, this looks shiny" when they first see it, and when seeing in the > future, can at the slightest glance be like "Neat, a 2.0 server". I'm > thinking that it would be neat to use either movers or the cfanim plugin > to make an interesting animation for it. > Anyone have any comments on this simple but fun idea? :) The HallOfSelection is pretty bland, and a bit of rework could be something cool. ?I always thought the opening background was rather crude even though the earth/wind/fire/water theme is appropriate. If ?one isn't careful though, I'd think gameplay would be a let-down to newbies if the opening screen was amazing and the rest of the game remains the same. ?It would seem a bit like false advertising to me. Also, not meaning to be Debby Downer, but, if I wanted to play something shiny, I wouldn't play Crossfire. ?As it is, the smoothing looks like crap, so I turn it off. ?I'd rather see some real improvement in things like smoothing than adding window dressing. ?On the flip side, I am also not into having to have a liquid-cooled graphics processor and a 10m/b up/downlink from the net just to play around. Kevin From mwedel at sonic.net Mon Oct 9 02:03:52 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 09 Oct 2006 00:03:52 -0700 Subject: [crossfire] msg/endmsg in maps/objects In-Reply-To: <200610082011.05203.kbulgrien@worldnet.att.net> References: <200610082011.05203.kbulgrien@worldnet.att.net> Message-ID: <4529F458.8020007@sonic.net> Kevin R. Bulgrien wrote: > Mark Wedel wrote: > >> Kevin R. Bulgrien wrote: >>> Mark Wedel wrote: >>>> Ideally, I think most of the newlines from the msg/endmsg structures >>>> should be >>>> removed - the client is plenty smart enough to do proper wrapping. >>>> There are also a few messages which should have the '[fixed]' tag added, >>>> since they are maps or diagrams, and just don't look right when printed >>>> with the proportional font. > > BTW, not sure what "proper wrapping" means. In gcfclient, it mercilessly > chops the text to fit the window. Word boundaries are not honored. The gtk2 client handles word wrapping properly. > It turns out, blank lines are stripped. I don't know how to add blank > lines. This is can be problematic when you use split windows because, for > example, if you walk down the main drag in scorn reading all the signs, all > the output is just strung in sequence with no separation between signs or > headings. It is pretty hard to scroll back and see what happened, and, > it is hard for any given message to be well formatted so that paragraphs > are separated nicely. > > Does anyone know how to output a blank line in message text? I tried > \n, but it does not seem to work. The gtk2 client seems to also handle this just fine. I'm not positive where the issue is in the gtk client. I know for the word wrapping, it is left to the widget to do the wrapping, and it instead just chops the lines - I'd think that there is probably an option there someplace to have it wrap, but it is also using a deprecated (relative to gtk 2.0) widget. > > mediaTags seem to be of limited usefulness, or are broken. The following > DOES NOT work... The tags are output as text, at least in the GTK 1 client. > The tags appear to be applicable only for cases where server code writes > to the client, but not when that text is extracted from an arch msg block. I'm in the process of updating all the code in the server to do the right thing in this regard. From mwedel at sonic.net Mon Oct 9 02:11:52 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 09 Oct 2006 00:11:52 -0700 Subject: [crossfire] HallOfSelection in crossfire 2.0 In-Reply-To: <452806F0.9030608@telus.net> References: <452806F0.9030608@telus.net> Message-ID: <4529F638.6080906@sonic.net> Alex Schultz wrote: > It's not a big thing, just a little detail, but it's a fun thing. I'm > thinking that the top section of the HallOfSelection that's displayed > when players are logging in, should have some cosmetic changes in the > trunk (2.0 branch). It would be nice if to make it so what was displayed > there would be something that would make players think something like > "Ooh, this looks shiny" when they first see it, and when seeing in the > future, can at the slightest glance be like "Neat, a 2.0 server". I'm > thinking that it would be neat to use either movers or the cfanim plugin > to make an interesting animation for it. > Anyone have any comments on this simple but fun idea? :) The way I see/envision things, the hall of selection map will just go away. This is because there will be another method of character creation that does not involve moving a character around a map to choose race, etc. So the question then becomes what should be displayed. There is the current issue now that when you first run the client, nothing at all (or just the generic crossfire icon) is displayed - and this is displayed at the metaserver selection window, etc. It'd just be nice to have something better to display then, vs just some big black empty area. The easiest thing, IMO, is to have some static image of good size (png or the like) that is displayed in that window. Given this doesn't have to be a map, it could really be anything, but probably easiest to have some map like form (that represents what the game looks like to some extent), maybe with lettering and the like overdrawn (Crossfire 2.0 or something). The follow up question is then: Should the server provide an updated/different image while receiving the player name/password, or just use that one in the client? From a practical matter, I don't think there is anything prevent arbitrary images from being in the arch directory, and thus served to the client. so a large image could exist in the arch tree, and through some basic negotiation at startup, the client could figure out what the image is, download it, and display it. OTOH, I'm not sure the likelihood of different servers going to the work of customizing that image, and most players will log in relatively quickly so probably wouldn't notice any difference, but who knows. From mwedel at sonic.net Mon Oct 9 02:16:27 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 09 Oct 2006 00:16:27 -0700 Subject: [crossfire] Removal of output-count/output-sync from server In-Reply-To: <200610081107.47099.subs@eracc.com> References: <4527F584.7070804@sonic.net> <7903f03c0610071744v2fa01ce1m924ddf6dfef68989@mail.gmail.com> <200610081107.47099.subs@eracc.com> Message-ID: <4529F74B.8030009@sonic.net> > Yes, I use it too to control how much garbage scrolls by in my client. Please > don't remove that until there is a replacement in the client. > > Gene Alexander Ok - followup question this: the current implementation in the server has several buffers that it uses to store/track different messages. What this means is if you have messages like: you hit orc you hit orc hard you hit orc hard you hit orc you hit orc ... They get compressed into something like: 3 times you hit orc 2 times you hit orc hard and so on. Is that extra logic still needed, or is it sufficient to just track the last message an print repeat counts? I'm thinking that if this is most often just used for things like search locks or other repeated checks, just buffering/repeating the last message would be sufficient, and is certainly a bit simpler to do. The disadvantage is that if there is a bunch of other messages being generated as you search for traps (say your suffering from poisoning), that would cause the search messages to get broken up, etc. Thoughts? From mwedel at sonic.net Mon Oct 9 02:37:39 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 09 Oct 2006 00:37:39 -0700 Subject: [crossfire] Crossfire protocol cleanup Message-ID: <4529FC43.70909@sonic.net> Please note that everything discussed in this message only pertains to the targetted 2.0 release of crossfire, which is in the trunk. Changes won't be made to the 1.x branch. It has been noted that within both the client and server, there is a fair amount of old code around to support older versions of the servers and older versions of the client. The setup command has also gotten a lot of options with methods to negotiate what protocol commands it supports, and directly related to that, there is a lot of code in the server that does/does not do something based on what has been negotiated. The idea here is to clean all that up for 2.0. Specifically: - Change the SC_VERSION and CS_VERSION to 2000, to represent 2.0 release. - server and client must have some version to work correctly - mismatched versions may or may not work (client may get data it doesn't understand, server may get client commands it is unable to process) - Version 2.0 compliance means that the client supports the latest implementation of the protocol. Support for superceded protocol commands is removed from both server and client. - Version 2.0 compliance also means that the client supports all the relevant items within the setup command, so that doesn't need to be negotiated (spell info, 64 bit exp values, whatever, so those are not needed in the setup command. Note that there will still be some things done via setup, like faceset, map size, etc - things that are actual preferences, and not protocol selection info. - While 2.0 is in development, any updates/changes to the protocol will result in updating the SC/CS version numbers, and not done via setup. This may mean people need to update their client to play on their test server, but since this is while doing development, I don't think that is unreasonable. - Once 2.0 does release, then any changes to protocol would go back to being enabled via setup commands like done now. - If/when alphas/betas for 2.0 are done, both a client and server release snapshot is done, so no issue with version commands. Pros for doing this: - Helps in code cleanup (get rid of old code) - Enables more rapid code development (easier to make protocol changes, and can remove obsolete code at time new code is added). Note: This doesn't remove the need for discussion on protocol changes - Simplifies protocol, make it clearer what new developers should program to. Cons: - Need 2.0 client to play on 2.0 server (would probably be a requirement at some point anyways) - May not be able to use a 2.0 client to play on an older server (depends on how old, and what protocol commands to use). Could still use the 1.x clients of course. - Developers would need to keep their client and server in sync to play, given requirement of equal protocol versions (may not be that big a deal - I'm not sure how often the protocol will change, and doing svn updates shouldn't be that hard) thoughts? From mwedel at sonic.net Mon Oct 9 03:10:52 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 09 Oct 2006 01:10:52 -0700 Subject: [crossfire] Improved/redone client. Message-ID: <452A040C.20105@sonic.net> One of those perennial items on the TODO is an improved client interface. Unfortunately, seldom are good details provided. I had a discussion with a few people on irc a little while back on this, and some ideas where exchanged. Note that this is likely far from a complete list: == Standardize on 19x19 map size. This size was chosen as that the map could still fully fit on lower resolution systems. Standard size so that map makers know what to design to, and so players don't have an unfair advantage (if I have a 25x25 map and you only have 19x19, I have more info). To me, the idea seems reasonable. Having a single map size to supports certainly makes programming easier. As a user of high resolution displays, that would seem to leave the map a bit small to me (it has been suggested to make a 'large sized' image set with 64x64 tiles, but that is probably a separate discussion). It maybe that resizing the images on hi-res systems to be larger is the way to go, or the client displays fog info in the extra space it has. == Make client fullscreen. Reasoning here is that most games run in fullscreen mode, so it becomes more like most games. It can also ensure that other applications are not grabbing keystrokes/button presses (eg, window manager, etc), so if we tell the player to press a key, we can know for sure that if the player presses that key, the client gets it. For lots of reasons, would still need to support a windowed mode of operation. My thoughts: I personally find fullscreen applications annoying, so would also use the window mode (I think most people using unix don't expect full screen apps). While we can run fullscreen, I don't think we can or should attempt to switch resolution. This does then mean that client could be asked to run at odd dimensions. I think this issue needs to be investigated further - it may be possible to make the pointer captive in a non full screen window. I also think that if we do full screen window, it needs to be pretty clear how to get out of it (nothing more annoying than an app taking over your system) == Standardize on one client Doesn't make sense to be supporting 3 clients in the current client distribution alone, plus a few others hanging around out there. This is just more work when a bug/issue shows up (may need to be fixed in all 3, or maybe only shows up in one client, requiring digging in there, etc). So in the trunk, should just use the gtk2 client, and get rid of the x11 and gtk1 client (note, they would still exist in the 1.x branch). Related to this, SDL mode in gtk2 client should probably just go away (opengl will give us the features we need long term) My thoughts: As the writer and user of the gtk2 client, I'm biased, but keeping the gtk2 clients seems fine to me. I know there are complaints about it, as well as bugs, but having 3 supported clients I don't think really helps things much (it becomes too easy to just not make improvements or fix bugs and keep using the gtk1 client). It may also be that a completely new client should be written (see point below) so that the gtk2 client goes away. But whatever is done, I think going forward, it certainly makes the most sense to only officially support one client (people could unofficially continue to support the x11 client, but in that case, the developers making changes to the protocol or official client wouldn't have to update it, just like the unofficial clients out there now) Better UI interface == Improve client UI This is often discussed, but I hear few concrete suggestions. I'll be the first to admit I'm not wholly satisfied with the gtk2 client. Yet at the same time, I'm not exactly sure what I'd change to make it better. Here are various thoughts and some suggestions I think people presented: - Pop up window for inventory handling (one gets so many items in crossfire, that the normal scrolled area really isn't sufficient) - Maybe use themes to make the appearance more that of a game and less that of an application (font size, background colors, etc) - Figure out what information is important to display, and what isn't. In particular, I'm thinking of the stats pane here - most often I use the exp pane to see where I am at relative to leveling, less so the resistances, and seldom use the overall stats one, since stats don't change very often. Could we maybe use icons instead of string names, and scrollbars instead of numbers to represent progress? Add popup hints so if you hover over the value, you get the full info? - Improved help - I don't think the help in the client has much useful content - I think a lot of the information currently in various places could make it to the client so it has a real help system. === Thoughts/comments? From kbulgrien at worldnet.att.net Mon Oct 9 06:28:31 2006 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Mon, 9 Oct 2006 06:28:31 -0500 Subject: [crossfire] Improved/redone client. In-Reply-To: <452A040C.20105@sonic.net> References: <452A040C.20105@sonic.net> Message-ID: <200610090628.31333.kbulgrien@worldnet.att.net> On Monday 09 October 2006 03:10 am, Mark Wedel wrote: > == > Standardize on 19x19 map size. > > This size was chosen as that the map could still fully fit on lower resolution > systems. Standard size so that map makers know what to design to, and so > players don't have an unfair advantage (if I have a 25x25 map and you only have > 19x19, I have more info). > > To me, the idea seems reasonable. Having a single map size to supports > certainly makes programming easier. As a user of high resolution displays, that > would seem to leave the map a bit small to me (it has been suggested to make a > 'large sized' image set with 64x64 tiles, but that is probably a separate > discussion). It maybe that resizing the images on hi-res systems to be larger > is the way to go, or the client displays fog info in the extra space it has. Does this mean each layer of every map is 19x19? That every client has a max display grid of 19x19 that cannot be set higher? I guess I'd see the priority of this as being quite low. The main advantage of a larger display is that you have a "better memory" of where you have been before. I don't see that as critical, but I may not understand the issue. > == > Make client fullscreen. > > Reasoning here is that most games run in fullscreen mode, so it becomes more > like most games. It can also ensure that other applications are not grabbing > keystrokes/button presses (eg, window manager, etc), so if we tell the player to > press a key, we can know for sure that if the player presses that key, the > client gets it. For lots of reasons, would still need to support a windowed > mode of operation. > > My thoughts: I personally find fullscreen applications annoying, so would also > use the window mode (I think most people using unix don't expect full screen > apps). While we can run fullscreen, I don't think we can or should attempt to > switch resolution. This does then mean that client could be asked to run at odd > dimensions. I think this issue needs to be investigated further - it may be > possible to make the pointer captive in a non full screen window. I also think > that if we do full screen window, it needs to be pretty clear how to get out of > it (nothing more annoying than an app taking over your system) Ugh. Full-screen is awful IMO, and not worth any development time vs. getting other things improved/fixed. > == > Standardize on one client > > Doesn't make sense to be supporting 3 clients in the current client distribution > alone, plus a few others hanging around out there. This is just more work when > a bug/issue shows up (may need to be fixed in all 3, or maybe only shows up in > one client, requiring digging in there, etc). So in the trunk, should just use > the gtk2 client, and get rid of the x11 and gtk1 client (note, they would still > exist in the 1.x branch). Related to this, SDL mode in gtk2 client should > probably just go away (opengl will give us the features we need long term) > > My thoughts: As the writer and user of the gtk2 client, I'm biased, but keeping > the gtk2 clients seems fine to me. I know there are complaints about it, as > well as bugs, but having 3 supported clients I don't think really helps things > much (it becomes too easy to just not make improvements or fix bugs and keep > using the gtk1 client). > > It may also be that a completely new client should be written (see point > below) so that the gtk2 client goes away. But whatever is done, I think going > forward, it certainly makes the most sense to only officially support one > client (people could unofficially continue to support the x11 client, but in > that case, the developers making changes to the protocol or official client > wouldn't have to update it, just like the unofficial clients out there now) > Better UI interface > > == > Improve client UI > > This is often discussed, but I hear few concrete suggestions. > > I'll be the first to admit I'm not wholly satisfied with the gtk2 client. Yet > at the same time, I'm not exactly sure what I'd change to make it better. First off, there are very attractive features in the GTK2 client. I was glad to see it when I first tried it. The presentation / UI design had polish that was obvious at first glance. But, the GTK2 Client is highly biased towards users with large high-resolution displays and high experience with Crossfire gaming. I am blind when I play with it. I feel _very_ strongly about this and that this is way more of a problem than map size. Specifically, I run with a large inventory pane and a large pane for output like store signs. The client is also quite buggy. It crashed my server this morning when I tried it again to answer this message... (http://rafb.net/paste/results/X0AAlv84.html) before I even got logged in. Resizing different from default for my lower-res systems seems problematic, keyboard lockups during game play make death inevitable. I get incredible spews of errors that bog the client to the point of being unusable. Configure options/screen layout settings do not seem to save properly. I would hope these would be fixed, but one cannot really count on that when one is not that familiar with GUI programming. The layout constraints would be hard to get around until I found a treasure hoard in the real world so that I could get one of those displays that is very, very tall. Messages/critical messages on different panes seemed cool in the beginning, but the longer I used it the more I disliked it. On the GTK1 client, I depend a lot on having split panes because the critical messages persist without having to specifically flip back and forth even though the critical pane is relatively small. Long and short, I would hate to see v2 go to one client if it is the GTK2 client without any changes. As for any other clients, as I only use GTK1, I personally don't care if they go. > Here are various thoughts and some suggestions I think people presented: > - Pop up window for inventory handling (one gets so many items in crossfire, > that the normal scrolled area really isn't sufficient) Vote no unless somehow this can be done only for containers. I have never gotten to the point where everything ever done is bound to keys, and even then, some of the bindings break sometimes so in an emergency you have to "reset" a multi-step binding by hand. This happens, for instance when using emergency bindings that apply a rod of heal, and unapply it. I would die more if I had to pop a window up to fix the state of such a binding with a mouse. In dangerous situations, I can have my inventory pane already positioned in case I need to use the mouse to fix something. Can see that this could be an option, but GTK1 client is _ideal_ for me in this regard, and is one of the main reasons why I use it and not GTK2 client. On second thought, maybe exploring the a "body slot" motif might be a way to overcome this. Selecting a body slot might automatically give you only items that could be configured for that slot and might actually speed up the ability to manually juggle what is equipped, not equipped, etc. The point being perhaps that simply dropping the existing panel on a separate window won't cut it, but totally rethinking it might be a more worthwhile pursuit. Can't remember what I thought about the way Daimonin did it, but I seem to think maybe they had a good idea. > - Maybe use themes to make the appearance more that of a game and less that of > an application (font size, background colors, etc) Unimportant to me, but have no objection as long as display density is not reduced. > - Figure out what information is important to display, and what isn't. In > particular, I'm thinking of the stats pane here - most often I use the exp pane > to see where I am at relative to leveling, less so the resistances, and seldom > use the overall stats one, since stats don't change very often. Could we maybe > use icons instead of string names, and scrollbars instead of numbers to > represent progress? Add popup hints so if you hover over the value, you get the > full info? The one improvement in the GTK2 client that I do like concerns the stats displays. Having a tabbed pane works well for me. Popup hints are not something I'd want to see, but maybe I am missing something. I feel the GTK2 current implementation is excellent as-is, except perhaps for the rubber-banding on the vertical layout (that is just wierd, and garbles the pane if too small). > - Improved help - I don't think the help in the client has much useful content - > I think a lot of the information currently in various places could make it to > the client so it has a real help system. Would be great, especially in the area of keybinding. Gameplay help could be improved by in client improvement for spells pane content. Pickup could use some coverage too. > === > > Thoughts/comments? Strong suggestion to add "background music" like the Windows DX client had. In my opinion, this adds far more to the ambiance of game play than anything else one might do. The Daimonin client seems to have done a good job with sound improvement, and it has background music. Sound setup is a royal pain... I have done without sound for ages. Somehow on my x86_64 system it all of a sudden started working... I still don't know why. I'd rank sound improvements high if I were setting priorities. Kevin From kbulgrien at worldnet.att.net Mon Oct 9 07:02:38 2006 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Mon, 9 Oct 2006 07:02:38 -0500 Subject: [crossfire] Improved/redone client. In-Reply-To: <200610090628.31333.kbulgrien@worldnet.att.net> References: <452A040C.20105@sonic.net> <200610090628.31333.kbulgrien@worldnet.att.net> Message-ID: <200610090702.38188.kbulgrien@worldnet.att.net> On Monday 09 October 2006 06:28 am, Kevin R. Bulgrien wrote: > > - Improved help - I don't think the help in the client has much useful content - > > I think a lot of the information currently in various places could make it to > > the client so it has a real help system. > > Would be great, especially in the area of keybinding. Gameplay help could be > improved by in client improvement for spells pane content. Pickup could use > some coverage too. Add to that magic map interpretation/use. I never have figured out how to use them. > > === > > > > Thoughts/comments? > > Strong suggestion to add "background music" like the Windows DX client had. In > my opinion, this adds far more to the ambiance of game play than anything else > one might do. The Daimonin client seems to have done a good job with sound > improvement, and it has background music. > > Sound setup is a royal pain... I have done without sound for ages. Somehow on > my x86_64 system it all of a sudden started working... I still don't know why. I'd > rank sound improvements high if I were setting priorities. > > Kevin Also, strongly suggest key-binding "profiles", possibly for keyboard regions. When playing multiple characters with unique skill-sets, it is difficult to create one single key-binding profile that fits all of them. I can see that a profile for the function keys would add value. I could slide in a new function key set while keeping the alpha keys common since they are often bound in ways that help you memorize what they do better. I tend to keep the numeric/punctuation key binding constant too, but that might be another area that would benefit from being able to be profiled depending on the tastes of various players. The reason for profiling regions would be to reduce rework of bindings that a player keeps constant across various characters played. Additionally, without knowing the underlying infrastructure, it is hard to know if the following is practical or not. I think all clients suffer from buffer flooding. I think it would be exceptionally profitable to have an ability to flush the command buffer or to escalate the priority of certain "emergency" bindings. I don't know how many times I have helplessly watched as my character died because the buffer was flooded and there was nothing to be done except stop and hope you don't die before it emptied. Kevin From alex_sch at telus.net Mon Oct 9 09:16:20 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 09 Oct 2006 08:16:20 -0600 Subject: [crossfire] Buffer flooding (was: Improved/redone client.) In-Reply-To: <200610090702.38188.kbulgrien@worldnet.att.net> References: <452A040C.20105@sonic.net> <200610090628.31333.kbulgrien@worldnet.att.net> <200610090702.38188.kbulgrien@worldnet.att.net> Message-ID: <452A59B4.7060400@telus.net> Kevin R. Bulgrien wrote: > Additionally, without knowing the underlying infrastructure, it is hard to know if the > following is practical or not. I think all clients suffer from buffer flooding. I think it > would be exceptionally profitable to have an ability to flush the command buffer > or to escalate the priority of certain "emergency" bindings. I don't know how many > times I have helplessly watched as my character died because the buffer was > flooded and there was nothing to be done except stop and hope you don't die > before it emptied. To my understanding, buffer flooding occurs on the server side, not the client side. One simple fix could be done client side however; One could make the client ignore key-repeats, getting rid of the command buffer issues caused by holding the key down. When using crossfire, I can't think of a time I actually make use of key repeating (using running for example doesn't rely on key repeating, just on holding the run key down) Also, IMHO the command buffer needs some redoing anyways: Paralysis is currently implemented simply as not processing the command buffer, with which I believe there are a few issues. For one, I believe it would make sense for some types of commands such as communication commands, possibly other than say, to ignore paralysis. Also, it might be a good idea to instead of buffer actions while paralyzed, to just ignore them. Alex Schultz From alex_sch at telus.net Mon Oct 9 09:46:15 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 09 Oct 2006 08:46:15 -0600 Subject: [crossfire] Improved/redone client. In-Reply-To: <200610090628.31333.kbulgrien@worldnet.att.net> References: <452A040C.20105@sonic.net> <200610090628.31333.kbulgrien@worldnet.att.net> Message-ID: <452A60B7.8010802@telus.net> Kevin R. Bulgrien wrote: > On Monday 09 October 2006 03:10 am, Mark Wedel wrote: > >> == >> Standardize on 19x19 map size. >> >> >> > Does this mean each layer of every map is 19x19? That every client has a max > display grid of 19x19 that cannot be set higher? I guess I'd see the priority of > this as being quite low. The main advantage of a larger display is that you have > a "better memory" of where you have been before. I don't see that as critical, > but I may not understand the issue. > I'm pretty sure what Mark means isn't making each lever of every map 19x19, what he means is making that the amount of displayed map on the client all of the time (not counting darkness etc. limits). And what he meant by "Standard size so that map makers know what to design to" is meaning in terms of map makers assuming a player can see a certain distance ahead of them. Alex Schultz From alex_sch at telus.net Mon Oct 9 10:37:29 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 09 Oct 2006 09:37:29 -0600 Subject: [crossfire] Improved/redone client. In-Reply-To: <452A040C.20105@sonic.net> References: <452A040C.20105@sonic.net> Message-ID: <452A6CB9.5050106@telus.net> Mark Wedel wrote: > One of those perennial items on the TODO is an improved client interface. > Unfortunately, seldom are good details provided. I had a discussion with a few > people on irc a little while back on this, and some ideas where exchanged. Note > that this is likely far from a complete list: > > == > Standardize on 19x19 map size. > > This size was chosen as that the map could still fully fit on lower resolution > systems. Standard size so that map makers know what to design to, and so > players don't have an unfair advantage (if I have a 25x25 map and you only have > 19x19, I have more info). > I wouldn't consider this a high priority, but seems like a reasonable reasonable thing to do. > To me, the idea seems reasonable. Having a single map size to supports > certainly makes programming easier. As a user of high resolution displays, that > would seem to leave the map a bit small to me (it has been suggested to make a > 'large sized' image set with 64x64 tiles, but that is probably a separate > discussion). It maybe that resizing the images on hi-res systems to be larger > is the way to go, or the client displays fog info in the extra space it has. > Well relating to what is said below in the fullscreen section, this issue could be considered a strong reason to make a fullscreen client change resolution. I'm not personally sure if it would be worth switching resolution, but this issue makes switching resolution make some sense. > == > Make client fullscreen. > > Reasoning here is that most games run in fullscreen mode, so it becomes more > like most games. It can also ensure that other applications are not grabbing > keystrokes/button presses (eg, window manager, etc), so if we tell the player to > press a key, we can know for sure that if the player presses that key, the > client gets it. For lots of reasons, would still need to support a windowed > mode of operation. > Agreed here. Some other reasons for making it 'fullscreen-style', is that it allows 'popups' or 'heads up display' like interface elements somewhat nicer than a traditional widget system like gtk. It also frees up interface design, possibly allowing better inventory controls than is possible with traditional widgets. > My thoughts: I personally find fullscreen applications annoying, so would also > use the window mode (I think most people using unix don't expect full screen > apps). While we can run fullscreen, I don't think we can or should attempt to > switch resolution. This does then mean that client could be asked to run at odd > dimensions. I think this issue needs to be investigated further - it may be > possible to make the pointer captive in a non full screen window. I also think > that if we do full screen window, it needs to be pretty clear how to get out of > it (nothing more annoying than an app taking over your system) > Personally, I would also be one using it in windowed mode usually, however I still would most likely prefer a 'fullscreen' UI design. In terms of switching resolution, why shouldn't it switch resolution defaultly? It would help with the first note. Of course there is the option of simulating a resolution switch by scaling the graphics up in size (IMHO though, that would look ugly if the UI didn't scale in the same way with no smoothing). Also, I don't think it would be a good idea to make the pointer captive in a windowed mode, I find applications which do that to be really annoying. Also, yes, we need a clear UI for display settings such as being full screen or not, actually I'm tempted that we should make windowed mode default to be safe. > == > Standardize on one client > > Doesn't make sense to be supporting 3 clients in the current client distribution > alone, plus a few others hanging around out there. This is just more work when > a bug/issue shows up (may need to be fixed in all 3, or maybe only shows up in > one client, requiring digging in there, etc). So in the trunk, should just use > the gtk2 client, and get rid of the x11 and gtk1 client (note, they would still > exist in the 1.x branch). Related to this, SDL mode in gtk2 client should > probably just go away (opengl will give us the features we need long term) > IMHO this would be a good idea, however, only once whatever client we decide to keep seems to have the approval of the masses and has no major UI problems. > == > Improve client UI > > > - Pop up window for inventory handling (one gets so many items in crossfire, > that the normal scrolled area really isn't sufficient) > This seems like it would be a good idea to me, in certain conditions, if handled very carefully. For one, I don't believe popups would work in an environment where the popups are controlled by the window manager. Also, it would need to be carefully set up as to not obstruct anything, and it would be best if it could be keyboard controlled, while still allowing keyboard control of the game. > - Maybe use themes to make the appearance more that of a game and less that of > an application (font size, background colors, etc) > This in my opinion is something that should be done, but again needs to be done very carefully to do right. Badly chosen fonts and colors and such could be much worse than things are now, however if chosen very carefully and tastefully it could be a nice improvement and give the game more depth. > - Figure out what information is important to display, and what isn't. In > particular, I'm thinking of the stats pane here - most often I use the exp pane > to see where I am at relative to leveling, less so the resistances, and seldom > use the overall stats one, since stats don't change very often. Could we maybe > use icons instead of string names, and scrollbars instead of numbers to > represent progress? Add popup hints so if you hover over the value, you get the > full info? > Scrollbars with 'popup hints' seems like a good idea to me. On the other issues though, I'm not sure how it should be handled, and personally the way the gtk2 client handles it annoys me alot. I also use the exp one most, resistances next, and overall stats next, however I use even the overall stats one frequently enough that them being hidden annoys me. On the other hand, what I use least, is some of the exp display, as most of the skills are not ones I use. Because of that I'd be inclined to think about ways of making useful exp/level info visible to the user while not showing the full list. I think that perhaps some sort of thing that displayed the skill one was most recently gaining experience in might be a good thing to persistently show. > - Improved help - I don't think the help in the client has much useful content - > I think a lot of the information currently in various places could make it to > the client so it has a real help system. > Strongly agreed. Also, we need to decide how much to store client side and how much to store server side. Alex Schultz From subs at eracc.com Mon Oct 9 12:10:05 2006 From: subs at eracc.com (ERACC Subscriptions) Date: Mon, 9 Oct 2006 12:10:05 -0500 Subject: [crossfire] HallOfSelection in crossfire 2.0 In-Reply-To: <200610082127.52288.kbulgrien@att.net> References: <452806F0.9030608@telus.net> <200610082127.52288.kbulgrien@att.net> Message-ID: <200610091210.06407.subs@eracc.com> On Sunday 08 October 2006 09:27 pm Kevin R. Bulgrien wrote: > ..................................................... ?On the flip side, > I am also not into having to have a liquid-cooled graphics processor > and a 10m/b up/downlink from the net just to play around. Thus one of the reasons I like crossfire. It is low resource GUI capable and I can even play it on my old PII lappy. The game-play alone is enough to make the game fun without "awesome 3D graphics dude!" or even real purty 2D. :-) Gene Alexander -- Mandriva Linux release 2006.0 (Official) for i586 12:07:14 up 1 day, 4:20, 9 users, load average: 0.03, 0.08, 0.11 ERA Computers & Consulting - http://www.eracc.com/ <- get VOIP here! eComStation, Linux, FreeBSD, OpenServer & UnixWare preloads & sales From subs at eracc.com Mon Oct 9 12:24:53 2006 From: subs at eracc.com (ERACC Subscriptions) Date: Mon, 9 Oct 2006 12:24:53 -0500 Subject: [crossfire] Removal of output-count/output-sync from server In-Reply-To: <4529F74B.8030009@sonic.net> References: <4527F584.7070804@sonic.net> <200610081107.47099.subs@eracc.com> <4529F74B.8030009@sonic.net> Message-ID: <200610091224.54170.subs@eracc.com> On Monday 09 October 2006 02:16 am Mark Wedel wrote: > ............. Is that extra logic still needed, or is it sufficient to just > track the last message an print repeat counts? > > ? I'm thinking that if this is most often just used for things like search > locks or other repeated checks, just buffering/repeating the last message > would be sufficient, and is certainly a bit simpler to do. > > ? The disadvantage is that if there is a bunch of other messages being > generated as you search for traps (say your suffering from poisoning), that > would cause the search messages to get broken up, etc. > > ? Thoughts? As long as one can control, to some extent, how much garbage scrolls by in the client I for one don't really care how it is handled. I do use the split message window feature in the GTKv1 client to keep the hit, etcetera messages separate from conversations so that helps some. Gene Alexander -- Mandriva Linux release 2006.0 (Official) for i586 12:13:32 up 1 day, 4:26, 9 users, load average: 0.02, 0.06, 0.08 ERA Computers & Consulting - http://www.eracc.com/ <- get VOIP here! eComStation, Linux, FreeBSD, OpenServer & UnixWare preloads & sales From kbulgrien at worldnet.att.net Mon Oct 9 13:01:39 2006 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Mon, 9 Oct 2006 13:01:39 -0500 Subject: [crossfire] Food consumption Message-ID: <200610091301.39250.kbulgrien@worldnet.att.net> I am running an x86_64 test server with an Opteron processor. Food consumption seems unreal. Does anyone know what factors determine the rate of food loss? Speed is 0.90 (3.03). The character is a halfling. Food seems to click down a notch every second. On metalforge, food ticks down about 1 notch per 3 seconds with speed being up like 3.0+ (?) - not wearing any sustenance items. It wouldn't happen to be based on some platform dependent thingamabobber would it? Kevin From leaf at real-time.com Mon Oct 9 13:12:48 2006 From: leaf at real-time.com (Rick Tanner) Date: Mon, 09 Oct 2006 13:12:48 -0500 Subject: [crossfire] Food consumption In-Reply-To: <200610091301.39250.kbulgrien@worldnet.att.net> References: <200610091301.39250.kbulgrien@worldnet.att.net> Message-ID: <452A9120.1070907@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin R. Bulgrien wrote: > I am running an x86_64 test server with an Opteron processor. Food consumption > seems unreal. Does anyone know what factors determine the rate of food loss? > Speed is 0.90 (3.03). The character is a halfling. Food seems to click down a notch > every second. On metalforge, food ticks down about 1 notch per 3 seconds with > speed being up like 3.0+ (?) - not wearing any sustenance items. It wouldn't happen > to be based on some platform dependent thingamabobber would it? What is your server speed set at? By default, AFAIK, it should 120000 One way you can set this is while in DM mode, use this command: 'speed 120000 Also, any item that is +regeneration will cause you to consume food faster as well. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFKpEghHyvgBp+vH4RAtaOAKDdl0PoEn6X3ufpzi1aqfXZKyRVLQCeOncA CEdtKQxlik3suzkEmGkvX4M= =YySo -----END PGP SIGNATURE----- From raphael at gimp.org Mon Oct 9 13:57:40 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Mon, 9 Oct 2006 20:57:40 +0200 Subject: [crossfire] Improved/redone client. In-Reply-To: <452A040C.20105@sonic.net> References: <452A040C.20105@sonic.net> Message-ID: <20061009205740.46e55414.raphael@gimp.org> On Mon, 09 Oct 2006 01:10:52 -0700, Mark Wedel wrote: > Standardize on 19x19 map size. > > This size was chosen as that the map could still fully fit on lower resolution > systems. Standard size so that map makers know what to design to, and so > players don't have an unfair advantage (if I have a 25x25 map and you only have > 19x19, I have more info). Well, I disagree with a fixed size of 19x19 because it would be difficult to use it on a 1024x768 screen (sorry, I cannot easily switch to a bigger screen on my laptop). I have currently set my gtk2 client to use 20x15 for the map size and this works quite well. Here is a screenshot of my gcfclient2, with some comments about where some space optimizations could be implemented: http://wilber.gimp.org/~raphael/crossfire/gcfclient-ui.png > Make client fullscreen. > [...] Like you, I also find fullscreen applications annoying. Although this is good for many games such as action games that are played without interruption, I often like to switch from crossfire to a text editor or web browser in order to take some notes or read some docs. Maybe it is just a sign that the client does not provide enough features on its own (such as allowing the player to take notes or having a better online help system). But even if some of these features could be added later, I still think that I would prefer to use the crossfire client in windowed mode. > Standardize on one client [...] > My thoughts: As the writer and user of the gtk2 client, I'm biased, but keeping > the gtk2 clients seems fine to me. I know there are complaints about it, as > well as bugs, but having 3 supported clients I don't think really helps things > much (it becomes too easy to just not make improvements or fix bugs and keep > using the gtk1 client). I would also like to support the gtk2 client as the main client. The main problem with that client is that it is designed for a screen that is at least 1000 pixels high and this causes most of the widgets to be created out of the screen when the client in used on a 1024x768 screen. It is even difficult to resize the user interface so that most pieces fit on the screen, because even the resize handles for the hpanes and vpanes are off the screen initially. I had to resort to hand-editing of the ~/.crossfire/gwinpos2 file in order to make it fit on my screen because changing the map size or resizing the top-level application window was not sufficient to make all widgets appear in the visible area of the screen. It is much easier for the user to start with a smaller window and make it larger than to start with a window that is too large and try to make is smaller. I would like gcfclient2 to start with a smaller size by default so that it fits on a 1024x768 screen. Those (like you) who have a larger screen will be able to enlarge the window in order to make use of the available space and those who have a small/normal screen will be able to make minor adjustments if necessary. I was a bit disapointed to read in the docs of the client that you were not interested in accepting patches for improving the client on small screens. I hope that you have changed your mind about this and that you would still accept patches that change the initial dimensions of the gcfclient2 widgets. > Improve client UI > > This is often discussed, but I hear few concrete suggestions. > > I'll be the first to admit I'm not wholly satisfied with the gtk2 client. Yet > at the same time, I'm not exactly sure what I'd change to make it better. > > Here are various thoughts and some suggestions I think people presented: > - Pop up window for inventory handling (one gets so many items in crossfire, > that the normal scrolled area really isn't sufficient) I agree that the inventory handling should be improved. One of the drawbacks of the current solution (using a nested list in the inventory) is that it is sometimes hard to quickly close a container during combat because you have to scroll up exactly to the right place and this is tricky if you have many items in your inventory and in the container. I'm not sure that I would like a pop-up window, though. Pop-ups should generally be avoided because they get in the way and have to be dismissed explictely. It may be better to get back to the solution that was used in the old gtk1 client: replace the view of the stack/floor by the items in the container and have a "close" button in a place that can be found easily. Maybe something similar could be used in the gtk2 client. > - Maybe use themes to make the appearance more that of a game and less that of > an application (font size, background colors, etc) Hmmm... Themes can be nice. On the other hand, consistency with other applications running on the desktop is also nice. > - Figure out what information is important to display, and what isn't. In > particular, I'm thinking of the stats pane here - most often I use the exp pane > to see where I am at relative to leveling, less so the resistances, and seldom > use the overall stats one, since stats don't change very often. Could we maybe > use icons instead of string names, and scrollbars instead of numbers to > represent progress? Add popup hints so if you hover over the value, you get the > full info? I put some comments on the screenshot: http://wilber.gimp.org/~raphael/crossfire/gcfclient-ui.png The most important information (from my point of wiew) would be: - The current range/attack: spell, weapon, bow, rod, ... - The total exp: it is very useful to be able to see if that number changes while you are doing something, and by how much. If I want to see the details I can go to the "Skills & Experience" tab, but usually it is enough for me to see if the total is increasing. - The current armor and other protections. I am usually playing characters that have temporary resistances from spell or potions and I do not always see the messages telling me that some of them have expired (especially in the middle of some combat that generates lots of messages). So keeping an eye on the protections is rather useful. These values are the ones that I like to see when I am engaged in combat. When I am exploring, shopping or thinking between battles, I may be more interested in the "Core stats" or the details of my skills (which I can also get via the 'skills command anyway). It would be nice if some of the unused areas (marked in red on the screenshot) could be used to display some of these important values. It may be sufficient to display the range and total exp somewhere so that they are always visible, and then I could have the "Protections" tab visible most of the time, while you would probably choose to have the "Skills & Experience" tab visible. > - Improved help - I don't think the help in the client has much useful content - > I think a lot of the information currently in various places could make it to > the client so it has a real help system. Yes. See also the previous discussion that we had in August in the thread ``Proposal for better in-game information: client-side "player books"''. -Rapha?l From raphael at gimp.org Mon Oct 9 14:32:44 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Mon, 9 Oct 2006 21:32:44 +0200 Subject: [crossfire] displaying protections changes with colors (was: Improved/redone client) In-Reply-To: <20061009205740.46e55414.raphael@gimp.org> References: <452A040C.20105@sonic.net> <20061009205740.46e55414.raphael@gimp.org> Message-ID: <20061009213244.244a11ea.raphael@gimp.org> On Mon, 9 Oct 2006 20:57:40 +0200, Rapha?l Quinet wrote: > The most important information (from my point of wiew) would be: > - The current range/attack: spell, weapon, bow, rod, ... > - The total exp: it is very useful to be able to see if that number > changes while you are doing something, and by how much. If I want > to see the details I can go to the "Skills & Experience" tab, but > usually it is enough for me to see if the total is increasing. > - The current armor and other protections. I am usually playing > characters that have temporary resistances from spell or potions and > I do not always see the messages telling me that some of them have > expired (especially in the middle of some combat that generates lots > of messages). So keeping an eye on the protections is rather > useful. I just thought about a way to improve how protections are displayed in the client: temporarily change the color of the protection name and value (percentage) in the "Protections" tab so that the player can see quickly what has changed and in what direction (increase or decrease) without having to read all the messages in the normal message window. So for example, if you cast "protection from poison", you would see the "poison" protection and its percentage displayed in green for 1 or 2 seconds, after which it switches back to black (or slowly fades to black if we want to be fancy and waste CPU cycles). When the spell effect runs out, the percentage would be displayed in red for 1 or 2 seconds. The same would happen if you drink a potion that protects you from fire or cold, etc. The colors would change briefly whenever your protections are changing, so this would also happen if you wear or remove armor, rings and other items that change your protections. This would be a complement to the usual messages and it would be easier to see quickly what has changed without having to read all messages. We could even use this brief change of colors for all values that can change during the game: primary and secondary stats, skills and experience, etc. But maybe it would be too distracting for things that change frequently, such as the total experience. Anyway, it shouldn't be too hard to implement this in a generic way in the client (timer + callback for changing the color of the labels). A further extension (even nicer) would be possible if the client could know the difference between temporary and permanent changes to the protections. Temporary changes are the ones granted by spells or potions; permanent changes come from equipment or player stats. If the client could know that some protections are temporary, they could be displayed in some other color such as blue instead of black. So for example, if you cast "protection from attack" and then "protection from cold", you would see the following changes in the protections: - armor % is displayed in green for 1-2 seconds (increase) - cold % is displayed in green for 1-2 seconds (increase) - armor % is displayed in blue (temporary protection, will expire) - cold % is displayed in blue (temporary protection, will expire) - after a while, armor % drops back to its normal value and is displayed in red (decrease) for 1-2 seconds, then back to black - same for cold %: red for 1-2 seconds, then the usual black. -Rapha?l From raphael at gimp.org Mon Oct 9 15:09:20 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Mon, 9 Oct 2006 22:09:20 +0200 Subject: [crossfire] Improved/redone client. In-Reply-To: <452A6CB9.5050106@telus.net> References: <452A040C.20105@sonic.net> <452A6CB9.5050106@telus.net> Message-ID: <20061009220920.6f67f156.raphael@gimp.org> On Mon, 09 Oct 2006 09:37:29 -0600, Alex Schultz wrote: > Mark Wedel wrote: > > == > > Make client fullscreen. > > > > Reasoning here is that most games run in fullscreen mode, so it becomes more > > like most games. It can also ensure that other applications are not grabbing > > keystrokes/button presses (eg, window manager, etc), so if we tell the player to > > press a key, we can know for sure that if the player presses that key, the > > client gets it. For lots of reasons, would still need to support a windowed > > mode of operation. > > > Agreed here. Some other reasons for making it 'fullscreen-style', is > that it allows 'popups' or 'heads up display' like interface elements > somewhat nicer than a traditional widget system like gtk. It also frees > up interface design, possibly allowing better inventory controls than is > possible with traditional widgets. Well, sorry to disagree but I actually prefer to have the crossfire client using "traditional widgets". Even if games can be considered as a special kind of application, I like to have all applications on my desktop using the same widgets and behaving in the same way. For me, consistency is as important or even more important than the looks of an application. I usually dislike the applications that try to design their own widgets because they do not obey the global options that the user has set for all applications. If I have a large display and bad eyesight and I want to use larger fonts or high contrast colors for all applications, I don't want the crossfire client to behave differently because it uses its own widgets or because it installs its own private theme. Custom widgets can also cause problems because they do not behave like the other ones: they may not support copy & paste operations (I use that a lot for copying interesting messages from crossfire to a text editor) or they may have menus that pop up in a different way or text entry fields that do not support the usual shortcuts, etc. Another issue is cross-platform integration: there are themes for gtk2 that allow all applications (including the crossfire client) to look a bit more like Qt applications while running in KDE, like Windows applications while running in Windows, like Mac applications while running in MaxOS X, etc. Using custom widgets or private themes would imply that the crossfire client would look "foreign" on all desktops and would not respect the global settings such as the default colors, etc. In summary, I am happy with the crossfire client using "traditional widgets" and I would not like to change that. A separate client could be designed for full screen mode (a bit like the one developped for CFPlus: http://cf.schmorp.de/screenshots.shtml) but I would probably keep on using whatever client looks and behaves more like other applications on my desktop. -Rapha?l From alex_sch at telus.net Mon Oct 9 16:34:30 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 09 Oct 2006 15:34:30 -0600 Subject: [crossfire] Improved/redone client. In-Reply-To: <20061009220920.6f67f156.raphael@gimp.org> References: <452A040C.20105@sonic.net> <452A6CB9.5050106@telus.net> <20061009220920.6f67f156.raphael@gimp.org> Message-ID: <452AC066.7000306@telus.net> Rapha?l Quinet wrote: > On Mon, 09 Oct 2006 09:37:29 -0600, Alex Schultz wrote: > >> Mark Wedel wrote: >> >>> == >>> Make client fullscreen. >>> >>> Reasoning here is that most games run in fullscreen mode, so it becomes more >>> like most games. It can also ensure that other applications are not grabbing >>> keystrokes/button presses (eg, window manager, etc), so if we tell the player to >>> press a key, we can know for sure that if the player presses that key, the >>> client gets it. For lots of reasons, would still need to support a windowed >>> mode of operation. >>> >>> >> Agreed here. Some other reasons for making it 'fullscreen-style', is >> that it allows 'popups' or 'heads up display' like interface elements >> somewhat nicer than a traditional widget system like gtk. It also frees >> up interface design, possibly allowing better inventory controls than is >> possible with traditional widgets. >> > > Well, sorry to disagree but I actually prefer to have the crossfire > client using "traditional widgets". Even if games can be considered > as a special kind of application, I like to have all applications on > my desktop using the same widgets and behaving in the same way. For > me, consistency is as important or even more important than the looks > of an application. > > Hmm, I consider those points for using "traditional widgets" to be valid points, however using them creates a bit of a dilemma from my point of view. One thing that I think would be highly beneficial would be making the inventory easily controllable by keyboard controls. Sure one could use traditional widget focus on it and do things that way, however even if those were efficient controls (which they aren't IMHO), it would *not* be consistent with the feel of the rest of the keyboard controls in the game. To me, consistency within an application is much more important than consistency with the rest of the desktop. So, one is forced to either: 1. Make it inconsistent with the rest of the game's controls 2. Modify the widget behavior and be inconsistent with widgets that look exactly the same 3. Or one could make new widgets that though arn't consistent with the desktop, but wouldn't be confused with desktop widgets and would have keyboard controls fitting in with the rest of the game. 4. Leave out keyboard controls for such things So #4 is the current behavior. Personally I would prefer behavior #3, followed by #1, followed by #4, with the strongest dislike from #2. I don't believe it is just a matter of inventory keyboard control, I believe various aspects of the UI suffer from lack proper keyboard control, and that use of "traditional widgets" and their notion of focus eliminates the best solution in my opinion, the third one I listed. At that, I believe this is a problem with having complex interfaces that are primarily keyboard controlled implemented in any sort of "traditional widget" system. Of course if you have any ideas on a way to make something such as efficient keyboard controls that fit other game controls, to work in such an environment, that might be interesting :) Alex Schultz From alex_sch at telus.net Mon Oct 9 17:32:40 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 09 Oct 2006 16:32:40 -0600 Subject: [crossfire] displaying protections changes with colors In-Reply-To: <20061009213244.244a11ea.raphael@gimp.org> References: <452A040C.20105@sonic.net> <20061009205740.46e55414.raphael@gimp.org> <20061009213244.244a11ea.raphael@gimp.org> Message-ID: <452ACE08.4090100@telus.net> Rapha?l Quinet wrote: > temporarily change the color of the protection name and > value (percentage) in the "Protections" tab so that the player can see > quickly what has changed and in what direction (increase or decrease) > without having to read all the messages in the normal message window. > > > A further extension (even nicer) would be possible if the client could > know the difference between temporary and permanent changes to the > protections. Temporary changes are the ones granted by spells or > potions; permanent changes come from equipment or player stats. If > the client could know that some protections are temporary, they could > be displayed in some other color such as blue instead of black. This seems like a really good idea to me, can't think of any problems with it :) Alex Schultz From fuchs.andy at gmail.com Mon Oct 9 17:44:55 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon, 9 Oct 2006 18:44:55 -0400 Subject: [crossfire] Improved/redone client. In-Reply-To: <452AC066.7000306@telus.net> References: <452A040C.20105@sonic.net> <452A6CB9.5050106@telus.net> <20061009220920.6f67f156.raphael@gimp.org> <452AC066.7000306@telus.net> Message-ID: I posted some brainstorms ive had onto the wiki: http://wiki.metalforge.net/doku.php/dev_todo:better_client_ui -- Andrew Fuchs From cher at riedquat.de Mon Oct 9 16:56:18 2006 From: cher at riedquat.de (Christian Hujer) Date: Mon, 9 Oct 2006 23:56:18 +0200 Subject: [crossfire] Gridarta CFJavaEditor Jar? In-Reply-To: References: Message-ID: <200610092356.23865.cher@riedquat.de> Hi Kevin, sorry to respond so late, I didn't notice this post earlier. On Monday 25 September 2006 06:45 Kevin R. Bulgrien wrote: > Could someone make a jar file from the CFJavaEditor sources on the > Gridarta project? I have so far been unable to get a working > build environment. I get errors when I try the command-line build > instructions in INSTALL.txt, and I am having great difficultly > getting ant installed. > > $ javac -d class -classpath > lib/png.jar:lib/visualtek.jar:lib/jdom.jar:lib/crimson.jar > src/cfeditor/*.java src/cfeditor/textedit/textarea/*.java > src/cfeditor/textedit/scripteditor/*.java > src/cfeditor/JFontChooser.java:355: unclosed character literal > new_msg = new_msg.replace('??', '\n'); > ^ > src/cfeditor/JFontChooser.java:355: illegal character: \167 > new_msg = new_msg.replace('??', '\n'); > ^ > src/cfeditor/JFontChooser.java:355: unclosed character literal > new_msg = new_msg.replace('??', '\n'); > ^ > src/cfeditor/JFontChooser.java:355: ')' expected > new_msg = new_msg.replace('??', '\n'); > ^ > error: cannot read: src/cfeditor/textedit/textarea/*.java > 5 errors The Gridarta sources are encoded in UTF-8. javac uses the vm's underlying operating system's default encoding. When building on a system that does not use UTF-8 as default encoding (e.g. utf-16, archaic iso-8859-something or worse windows-cp-something) it is required to tell javac about the actual encoding: javac -encoding utf-8 The sources are spread accross two directories: crossfire/src/**/*.java and src/**/*.java, in the second directory the Java editors of Crossfire and Daimonin share their constantly growing merged and unified common code. Also, it is not guaranteed that building the above mentioned Crossfire sources will really compile all required sources, I'd actually explicitely specify them all. javac -sourcepath src:../src $(find src ../src -name "*.java") There are two lib directories, the crossfire/lib directory which contains libs only used by the Crossfire editor and the lib directory which contains libs used by both plus some libs which are used by the build process: javac -classpath ...:../lib/annotations.jar:../lib/japi.jar Because of that building by invoking javac yourself is no fun. Though it of course is possible I wouldn't even bother trying it. Building with Ant is highly recommended and the only way "officially" supported. If there's anything else regarding Gridarta that I can do for you, please let me know. Cher :) -- Christian Hujer Free software developer mailto:cher at riedquat.de http://www.riedquat.de/ PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20061009/b8ad08de/attachment-0001.pgp From cher at riedquat.de Mon Oct 9 17:29:02 2006 From: cher at riedquat.de (Christian Hujer) Date: Tue, 10 Oct 2006 00:29:02 +0200 Subject: [crossfire] SVN notes/thoughts In-Reply-To: <200609252309.30281.nicolas.weeger@laposte.net> References: <4514BD57.8050202@sonic.net> <200609252309.30281.nicolas.weeger@laposte.net> Message-ID: <200610100029.10116.cher@riedquat.de> Hi, On Monday 25 September 2006 23:09 Nicolas Weeger (Laposte) wrote: > > I think similar logic could also be used to embed the version number > > into the client and server binaries. That way, when someone reports a > > bug, it is very clear what version they are running. By using a state > > file, it means we don't need to recompile and relink everytime (if we > > just used svnversion to blindly write a .c/.h file, then everytime it > > would recompile and relink that component). > > Agreed, having the exact revision number would be really nice to see the > exact issue. I agree and highly recommend this (using revision number). I use it in Gridarta for a long time already. You actually can get the last change revision number instead of the latest update revision number out of the subversion client: svn info --xml doc | xql /info/entry/commit/@revision -cv XML is such a wonderful thing (read: Life can be so easy ;-) $ rpm -qf $(which xql) perl-XML-XQL-0.68-150 > > In both of these cases, we also need to handle the case for the > > official releases, where there will not be any SVN information in the > > downloaded source code, and the user may not even have svn tools > > installed. > > Well, that's what tags/branches are for, i guess :) Yes. If used correctly, a release tag semantically is nothing else but a symbolic name assigned to a specific repository revision. (The symbolic name is assigned using svn cp, and please use svn cp with remote URLs for that, creating a symbolic name locally neither makes sense nor is it a lot of fun) Cher :) -- Christian Hujer Free software developer mailto:cher at riedquat.de http://www.riedquat.de/ PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20061010/6317fbd3/attachment-0001.pgp From lordyoukai at gmail.com Mon Oct 9 19:07:30 2006 From: lordyoukai at gmail.com (Ben Jolitz) Date: Mon, 09 Oct 2006 17:07:30 -0700 Subject: [crossfire] Improved/redone client. In-Reply-To: References: <452A040C.20105@sonic.net> <452A6CB9.5050106@telus.net> <20061009220920.6f67f156.raphael@gimp.org> <452AC066.7000306@telus.net> Message-ID: <452AE442.8090403@gmail.com> Yo. I am one of the players of Metalforge, and I have been monitoring this. Of most of the proposed elements, I have agreement. However, SDL should _not_ be removed because on some computers OpenGL and DRI are not implemented right. That or add in an option to disable OpenGL and rely on old drawing mode. SDL is really nice because of legacy and support issues. On the plus side, I do not think CF should be optimized for the uber-supported computers if it is an open source project. Consider all the people, not just the few with the perfect setups. Thanks, Ben "Bort" >I posted some brainstorms ive had onto the wiki: > >http://wiki.metalforge.net/doku.php/dev_todo:better_client_ui > > > From leaf at real-time.com Mon Oct 9 21:18:31 2006 From: leaf at real-time.com (Rick Tanner) Date: Mon, 09 Oct 2006 21:18:31 -0500 Subject: [crossfire] User error with SVN, unintended checkin of files Message-ID: <452B02F7.7040609@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just made a rather embarrassing error with SVN a few moments ago. Following the instructions at HowtoForge for setting up a local websvn, I committed some junk files when I thought "import" was going to check *out* files. Apologies for the inconvenience. Now, could someone please remove/correct my blunder? Much appreciated and thanks! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFKwL3hHyvgBp+vH4RAlLSAKCH6s7ZCDHY5bHgDZNXVAZJVt848gCfY/tV +1/nUVLrpjv0Oi/gjQbcBm4= =3x6G -----END PGP SIGNATURE----- From alex_sch at telus.net Mon Oct 9 21:41:30 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 09 Oct 2006 20:41:30 -0600 Subject: [crossfire] User error with SVN, unintended checkin of files In-Reply-To: <452B02F7.7040609@real-time.com> References: <452B02F7.7040609@real-time.com> Message-ID: <452B085A.7040905@telus.net> Rick Tanner wrote: > I just made a rather embarrassing error with SVN a few moments ago. > > Following the instructions at HowtoForge for setting up a local websvn, > I committed some junk files when I thought "import" was going to check > *out* files. > > Apologies for the inconvenience. > > Now, could someone please remove/correct my blunder? > > Much appreciated and thanks! Attempted to but blundered myself and made a mistake commiting a hall of selection I was fooling with. Trying to correct both of our mistakes... Alex Schultz From alex_sch at telus.net Mon Oct 9 22:04:18 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 09 Oct 2006 21:04:18 -0600 Subject: [crossfire] User error with SVN, unintended checkin of files In-Reply-To: <452B085A.7040905@telus.net> References: <452B02F7.7040609@real-time.com> <452B085A.7040905@telus.net> Message-ID: <452B0DB2.4020905@telus.net> Alex Schultz wrote: > Rick Tanner wrote: > >> I just made a rather embarrassing error with SVN a few moments ago. >> >> Following the instructions at HowtoForge for setting up a local websvn, >> I committed some junk files when I thought "import" was going to check >> *out* files. >> >> Apologies for the inconvenience. >> >> Now, could someone please remove/correct my blunder? >> >> Much appreciated and thanks! >> > Attempted to but blundered myself and made a mistake commiting a hall of > selection I was fooling with. Trying to correct both of our mistakes... Ok, fixed both of our blunders :) For future reference: http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.branchmerge.commonuses.undo Alex Schultz From kbulgrien at worldnet.att.net Mon Oct 9 22:30:48 2006 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Mon, 9 Oct 2006 22:30:48 -0500 Subject: [crossfire] Food consumption In-Reply-To: <200610091301.39250.kbulgrien@worldnet.att.net> References: <200610091301.39250.kbulgrien@worldnet.att.net> Message-ID: <200610092230.48883.kbulgrien@worldnet.att.net> > I am running an x86_64 test server with an Opteron processor. Food consumption > seems unreal. Does anyone know what factors determine the rate of food loss? > Speed is 0.90 (3.03). The character is a halfling. Food seems to click down a notch > every second. On metalforge, food ticks down about 1 notch per 3 seconds with > speed being up like 3.0+ (?) - not wearing any sustenance items. It wouldn't happen > to be based on some platform dependent thingamabobber would it? > > Kevin I never played Gaea before... That's what's doing it. Regeneration +2... Man, I need to carry a refrigerator around with me... :-) Kevin From mwedel at sonic.net Tue Oct 10 00:12:58 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 09 Oct 2006 22:12:58 -0700 Subject: [crossfire] Food consumption In-Reply-To: <200610092230.48883.kbulgrien@worldnet.att.net> References: <200610091301.39250.kbulgrien@worldnet.att.net> <200610092230.48883.kbulgrien@worldnet.att.net> Message-ID: <452B2BDA.9010406@sonic.net> Kevin R. Bulgrien wrote: >> I am running an x86_64 test server with an Opteron processor. Food consumption >> seems unreal. Does anyone know what factors determine the rate of food loss? >> Speed is 0.90 (3.03). The character is a halfling. Food seems to click down a notch >> every second. On metalforge, food ticks down about 1 notch per 3 seconds with >> speed being up like 3.0+ (?) - not wearing any sustenance items. It wouldn't happen >> to be based on some platform dependent thingamabobber would it? >> >> Kevin > > I never played Gaea before... That's what's doing it. Regeneration +2... Man, I need to > carry a refrigerator around with me... :-) A separate discussion could perhaps be change food consumption rate. High food consumption just means you carry around lots of food - not much other affect. The food consumption probably dates all the way to back when crossfire was more of a gauntlet clone (old arcane game). Most adventure games tend to have fairly low food needs (some games don't even have good). Another thing that affects food consumption - each time you regenerate an HP or SP, you lose a food point. Thus, if you are decent level and have high regen, you're food can go down really fast. If you are fully healed, a high regen rate doesn't affect food consumption that much I think. From mwedel at sonic.net Tue Oct 10 00:21:54 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 09 Oct 2006 22:21:54 -0700 Subject: [crossfire] Buffer flooding In-Reply-To: <452A59B4.7060400@telus.net> References: <452A040C.20105@sonic.net> <200610090628.31333.kbulgrien@worldnet.att.net> <200610090702.38188.kbulgrien@worldnet.att.net> <452A59B4.7060400@telus.net> Message-ID: <452B2DF2.8000404@sonic.net> Alex Schultz wrote: > To my understanding, buffer flooding occurs on the server side, not the > client side. > One simple fix could be done client side however; One could make the > client ignore key-repeats, getting rid of the command buffer issues > caused by holding the key down. When using crossfire, I can't think of a > time I actually make use of key repeating (using running for example > doesn't rely on key repeating, just on holding the run key down) That could be reasonable. OTOH, I'm not sure if new players, before they realize about the run feature, may hold down direction keys. > > Also, IMHO the command buffer needs some redoing anyways: Paralysis is > currently implemented simply as not processing the command buffer, with > which I believe there are a few issues. For one, I believe it would make > sense for some types of commands such as communication commands, > possibly other than say, to ignore paralysis. Also, it might be a good > idea to instead of buffer actions while paralyzed, to just ignore them. Yes, the command handling on the server could be redone. In the ideal case, it works something like this: 1) Read all pending commands from the client. Commands that are considered free can be executed (free commands could be administrative stuff, like maps, player communication commands, so forth). One such free command could be 'cancel all commands before this' type of thing. 2) The commands read are stored into a pending command buffer (maybe a linked list). If the player does not have time to execute non free commands, nothing more is done. 3) If the player does have time to execute commands, run the first command on the list, remove it, and repeat 4) Possible enhancement: Add some form of priority tagging to commands (number? Just a single flag?) In this way, that 'drink healing potion' command could be a priority command, which is run before the other pending commands, no matter where it shows up. From mwedel at sonic.net Tue Oct 10 02:36:18 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 10 Oct 2006 00:36:18 -0700 Subject: [crossfire] Improved/redone client. In-Reply-To: <452A040C.20105@sonic.net> References: <452A040C.20105@sonic.net> Message-ID: <452B4D72.2010009@sonic.net> Quick note - the client reorganization/cleanup/entire discussion is aimed at the 2.0 branch. I don't really forsee many of things things going into the 1.x client. Will try to quickly catch up with all the issues at once : Keybind profiles: I think that is doable, and makes sense (keybinding for a spellcaster vs non spellcaster is quite a bit different). From what was described, it sounds like there would be two keybinding profiles in use at any time - the common set, and then the specialized one for the given character type. That gets more complicated, because if you add a new binding, have to record where it goes (specialized binding or general one). It certainly wouldn't be hard to have an option on what keybinding profile to use. OTOH, presumably players would want this somewhat intelligent (if I play character X, use this binding, if I player character Y, use that binding), but probably don't want one binding selection per character. And even keying on character names may not be good, as different types of characters with the same name could be played on different server. Keybinding interface: I don't think anyone mentioned this, but I know people have said they don't like the current interface in the gtk2 client (which is really the same as the one in the gtk client). Not positive how to improve it - it seems with the number of spells, etc, we're always going to have a lot of keybindings in crossfire, but would be interested in hearing ideas. GTK2 client resolution: Yes, it is/was aimed at higher resolution screens. One reason was there is lots of buggy/complicated code in the gtk1 client to try and adjust based on window size, etc, and I want to avoid that complication in the gtk2 client. And at some level, I think that making changes to layout based on screen resolution has other disadvantages (it's hard to optimize for both low and high resolutions, which is one problem I had with the gtk1 client - fine on moderate resolution systems, but not very good on high res). I'm not sure the perfect solution here, but perhaps designing a layout for 1024x768 and seeing how it works might be a good start. The doc that says I won't take patches for lower resolution is not accurate. Containers: How to handle them can always be a bit of pain. I never thought it opening on the ground beneath the player was very intuitive (and would then create odd issues like you can't get to objects on the ground with an open container, etc). A quick fix for closing containers in the inventory is a 'close all containers' button could be added to the top of the inventory area. Quick item handling: In the ideal world, the client should be able to support some better form of filtering, perhaps even having like a 'favorites' tab which only shows items marked as your favorite (in this way, you could put all your items that you frequently apply there). Some games have the 'paper doll' type interface - I think that could still be a good idea for equipping, but I'm not sure if it is good during general purpose play (I can't think where that would fit in the client) Map size: The 19x19 was to make that the only supported map dimension as far as protocol/setup is concerned for viewable player map. The game map files won't change. And the client could of course have a larger visible map, but just wouldn't get data from the server for it, so its only use would be to use that for fog of war. I tend to think that letting the player select map size doesn't have much in the way of downside (yes, some players may get more information, but that hasn't seemed to have been a big problem in the past) Fullscreen client: The reason I don't think changing resolutions should be a method is because I don't think that will be very well supported. There is no guarantee what resolutions the system may support. I can certainly see people with LCD only having 1 valid resolution defined (native resolution of the screen). And you get the complication of widescreen (its not 1280x1024, but 1280x800). So you're now in a case where you may still need to support several resolutions. The other problem is that the client has to be more bulletproof to change the resolution back to the original when done. But the interesting point about fullscreen client, is that while several people say it may be useful, I don't think I've seen anyone actually say that is what they would use (they would use windowed mode). Which to me sort of suggests that this isn't something really worth pursuing - we're trying to guess what other people want. Pop up inventory window: I'm perhaps seeing this more as a secondary interface to the inventory, not the only way. So the existing scrollbar exists, but when dealing with lots of store, or perhaps more advanced operations, a pop up window could provide a better interface. OTOH, having two different interfaces would seem confusing. Icons & tooltips: My idea here is to try and convey the same data, but in smaller space. For example, for skills, we could probably use a quarter of the space by having an icon for the different skills, and then a small progress bar that shows progress towards next level. The tooltip would come into player if your mouse hovers over the icon/progress bar - it would pop up the tooltip with the skill name, level, and precise exp values. Themes: Initial thought is to make sure the client is fully themable, and then write some theme files that the player can select in the config window (with a default/inherit from system as an option). This matches what a lot of other programs do - have the ability to change appearance on themes. I don't think there is any downside on this, other than the work to add the theme support. Inventory control via keyboard: I'd be interested in how people think that should work - I really can't envision much any reasonable way to control the inventory only by keyboard, whether we use gtk2 widget or write our own. I'd personally consider this to be a pretty low thing to do. SDL removal: The old built in draw mode of gtk will always remain. I just don't think it makes sense to have 3 different drawing modes (gtk, opengl, sdl). I'm prooposing just gtk and opengl. Protection display changing colors: That works, but is only useful if you have the protection tab displayed (but that is like most things I suppose). Knowing if a change is temporary or permanent is much harder. By the time the server gets to sending that resistance values to the client, it only knows what the current values are and what the old values are. It has no idea what caused the change. I suppose code could be added to change_abil(), I'm not sure how reliable that will be. But related to this is the changing to draw_ext_info - the start and stop of protection related messages will have their own types, so the client will also be able to more prominently display such messages. Extra space in gtk2 client: I'm thinking the extra space in the stats display (sp/hp/grace/good) could perhaps be used for an experience bar. In terms of smaller icons for inventory, that should already be supported by using the -iconscale option (I think that is also in the config options) - scale them down to a smaller size. Perhaps the correct thing is the default should have them scaled down and not use the default. Also, I think some of that extra area in the stats display is to denote caps/shift keys being depressed (you can sometimes get odd behaviour by having one of those keys pressed, leaving the window, and client doesn't catch that, which is why they are noted). But all that info could fit in just one line. From alex_sch at telus.net Tue Oct 10 07:12:37 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 10 Oct 2006 06:12:37 -0600 Subject: [crossfire] Buffer flooding In-Reply-To: <452B2DF2.8000404@sonic.net> References: <452A040C.20105@sonic.net> <200610090628.31333.kbulgrien@worldnet.att.net> <200610090702.38188.kbulgrien@worldnet.att.net> <452A59B4.7060400@telus.net> <452B2DF2.8000404@sonic.net> Message-ID: <452B8E35.1010800@telus.net> Mark Wedel wrote: > OTOH, I'm not sure if new players, before they > realize about the run feature, may hold down direction keys. I recall that I did at very first ;) Alex Schultz From alex_sch at telus.net Tue Oct 10 08:35:58 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 10 Oct 2006 07:35:58 -0600 Subject: [crossfire] Improved/redone client. In-Reply-To: <452B4D72.2010009@sonic.net> References: <452A040C.20105@sonic.net> <452B4D72.2010009@sonic.net> Message-ID: <452BA1BE.4080009@telus.net> Mark Wedel wrote: > Keybinding interface: I don't think anyone mentioned this, but I know people > have said they don't like the current interface in the gtk2 client (which is > really the same as the one in the gtk client). Not positive how to improve it - > it seems with the number of spells, etc, we're always going to have a lot of > keybindings in crossfire, but would be interested in hearing ideas. > Well, a few things about keybindings: -In the gtk2 gui, the selections 'run', 'fire', 'alt meta', and 'stay in edit mode' are not very intuitive to new players -If you try to make a keybinding over a key that is already bound something, it shouldn't just append to the list, it should warn you and if you choose to continue, remove the old binding first. -One idea that might be good, is while it is waiting for you to press a key to bind to, it should come up with a graphical display of the keys on the keyboard, and with color coding showing which keys are already bound. Tooltips when hovering over a key show what is bound there and clicking a key counts as if you pressed that key. > Pop up inventory window: I'm perhaps seeing this more as a secondary interface > to the inventory, not the only way. So the existing scrollbar exists, but when > dealing with lots of store, or perhaps more advanced operations, a pop up window > could provide a better interface. OTOH, having two different interfaces would > seem confusing. > IMHO there are two main problems with popups: -window managers doing strange things -interferes with realtime gameplay And though I like popups for saving interface space, the only ways I see to deal with both of those issues would be to work around the window manager, and that doesn't seem reasonable to do unless one is also abandoning gtk and making an interface more akin to, for the sake of example, the battle for wesnoth. > Inventory control via keyboard: I'd be interested in how people think that > should work - I really can't envision much any reasonable way to control the > inventory only by keyboard, whether we use gtk2 widget or write our own. I'd > personally consider this to be a pretty low thing to do. Personally I think this would make a big improvement if it could be pulled off in a reasonable manner. The best I've seen for keyboard inventory control in large inventories, would be how nethack does it even in it's gtk interface. That keyboard interface might work well if we used popups, however see the popup issues above. One could do something though with giving focus the inventory list and allowing keyboard scrolling of it and pressing keys to apply from it or drop etc. however one would need to make it VERY obvious to the player when they have focus on that, and also would have to make it very difficult to accidentally trigger while easy to trigger manually (and for fairly obvious reason I don't think focus on click would work well for it...) Alex Schultz From brenlally at gmail.com Tue Oct 10 14:33:04 2006 From: brenlally at gmail.com (Brendan Lally) Date: Tue, 10 Oct 2006 20:33:04 +0100 Subject: [crossfire] Crossfire protocol cleanup In-Reply-To: <4529FC43.70909@sonic.net> References: <4529FC43.70909@sonic.net> Message-ID: <7903f03c0610101233ja549a0cq4b54eb4b46447df4@mail.gmail.com> On 10/9/06, Mark Wedel wrote: > - May not be able to use a 2.0 client to play on an older server (depends on how > old, and what protocol commands to use). Could still use the 1.x clients of course. Might I suggest then, that when the 2.0 protocol changes are (vaguey) finalised, a version of the 1.x server be released which understands a 2.x version number and acts as though all of the appropriate setup flags were set (without adding any of the new features), and also is aware of any new commands that can be sent to it, but merely ignores them (with suitable draw_info-ed error messages). That way it should be possible to have a compatibility upgrade to the server allowing both sets of clients to work for however long it would be until most distros have upgraded the versions they ship. From nicolas.weeger at laposte.net Tue Oct 10 16:22:38 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 10 Oct 2006 23:22:38 +0200 Subject: [crossfire] Crossfire protocol cleanup In-Reply-To: <4529FC43.70909@sonic.net> References: <4529FC43.70909@sonic.net> Message-ID: <200610102322.39008.nicolas.weeger@laposte.net> > It has been noted that within both the client and server, there is a fair > amount of old code around to support older versions of the servers and > older versions of the client. The setup command has also gotten a lot of > options with methods to negotiate what protocol commands it supports, and > directly related to that, there is a lot of code in the server that > does/does not do something based on what has been negotiated. > > The idea here is to clean all that up for 2.0. Specifically: I agree code cleanup could and should be done, including removal of old and deprecated things. I also support Brendan's idea to have an intermediate release with still the setup command for 2.0 stuff, so there could be an intermediate release. We could simply remove the arguments of the setup command, and keep it for new (post 2.0) things. Nicolas From nicolas.weeger at laposte.net Tue Oct 10 16:29:09 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 10 Oct 2006 23:29:09 +0200 Subject: [crossfire] Improved/redone client. In-Reply-To: <452A040C.20105@sonic.net> References: <452A040C.20105@sonic.net> Message-ID: <200610102329.09390.nicolas.weeger@laposte.net> > Standardize on 19x19 map size. It makes sense to have a common client size. Of course, whatever size we use, some people will find it too small, some will find it too big :) > Make client fullscreen. As long as it's an option, no issue here. Note that I agree about the point concerning toolkits - it's nice to have coherence between applications. > Standardize on one client Agreed, with the following conditions: * be available on as many platforms as we can, so people don't feel like writing another one * have as many options as possible - so people can customize it to their taste, and don't feel like writing another one :) > Improve client UI > Here are various thoughts and some suggestions I think people presented: > - Pop up window for inventory handling (one gets so many items in > crossfire, that the normal scrolled area really isn't sufficient) Optional :) > - Maybe use themes to make the appearance more that of a game and less that > of an application (font size, background colors, etc) The best thing would be to have "game mode", either full screen or not, with a specialized toolkit, and "integrated mode", integrated in the desktop (using style and such). > - Figure out what information is important to display, and what isn't. In > particular, I'm thinking of the stats pane here - most often I use the exp > pane to see where I am at relative to leveling, less so the resistances, > and seldom use the overall stats one, since stats don't change very often. > Could we maybe use icons instead of string names, and scrollbars instead of > numbers to represent progress? Add popup hints so if you hover over the > value, you get the full info? Again, let's enable the user to customize the interface as much as possible. > - Improved help - I don't think the help in the client has much useful > content - I think a lot of the information currently in various places > could make it to the client so it has a real help system. Agreed. A nice thing would be to have a generic client, with an interface layer. This way we could apply different interfaces while retaining a common layer. Think something like Firefox's XUL, maybe? (as a concept, i certainly don't suggest to use that language for the interface). Maybe with a "widget" system? Let users write (in Python? LUA?) their own displaying widget to display game information? Nicolas From alex_sch at telus.net Tue Oct 10 17:48:08 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 10 Oct 2006 16:48:08 -0600 Subject: [crossfire] Improved/redone client. In-Reply-To: <200610102329.09390.nicolas.weeger@laposte.net> References: <452A040C.20105@sonic.net> <200610102329.09390.nicolas.weeger@laposte.net> Message-ID: <452C2328.6050705@telus.net> Nicolas Weeger (Laposte) wrote: > The best thing would be to have "game mode", either full screen or not, with a > specialized toolkit, and "integrated mode", integrated in the desktop (using > style and such). > In my opinion this would be a great feature to have, however might be difficult to implement. The two ways I see to implement it would be: -Do something along the lines of what you say below, a much higher level common layer. -Less flexibly, as a gtk2 theme with small changes in logic and hacks to make popups have custom title bars and stay within the game view (might involve interesting platform specific code). The second would probably be less work, however IMHO more hackish and more likely to have odd quirks. I'm not sure which I would deem better overall though. > > A nice thing would be to have a generic client, with an interface layer. This > way we could apply different interfaces while retaining a common layer. Think > something like Firefox's XUL, maybe? (as a concept, i certainly don't suggest > to use that language for the interface). > Maybe with a "widget" system? Let users write (in Python? LUA?) their own > displaying widget to display game information? Well, we already have a common layer of sorts with the common code, however what you suggest of making something much higher level would be a very interesting idea. How much work it is to implement may be another matter though. Alex Schultz From kbulgrien at att.net Tue Oct 10 19:33:40 2006 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Tue, 10 Oct 2006 19:33:40 -0500 Subject: [crossfire] Food consumption References: <200610091301.39250.kbulgrien@worldnet.att.net> <200610092230.48883.kbulgrien@worldnet.att.net> <452B2BDA.9010406@sonic.net> Message-ID: Mark Wedel wrote: > Kevin R. Bulgrien wrote: >>> I am running an x86_64 test server with an Opteron processor. Food >>> consumption seems unreal... >> I never played Gaea before... That's what's doing it. Regeneration +2... >> Man, I need to carry a refrigerator around with me... :-) > > A separate discussion could perhaps be change food consumption rate. > > High food consumption just means you carry around lots of food - not > much other affect. Hmmm... Well, food beep seems to not be working again... Lately I have been working on maps with my client up and running, and have died quite a few times due to starvation because the warning seems to not work anymore. It has been patched ages ago, but I guess something has broken it again. Also, the poor halfling cannot carry very much weight, so has to resort o eating carcasses... blech... in a dungeon crawl. He is not nearly high enough level to have create food, town portal, and the like. Not complaining here so much as saying its not quite as simple as carrying lots of food. > The food consumption probably dates all the way to back when crossfire > was more of a gauntlet clone (old arcane game). Most adventure games > tend to have fairly low food needs (some games don't even have good). Food is cool... the thing is with this character, it is in your face. Now, on the flip side, it is way cool to have the regen rate because it makes me concentrate on playing stealthy. I would not change the food rate as it relates to regeneration of stats. > Another thing that affects food consumption - each time you regenerate > an HP or SP, you lose a food point. > > Thus, if you are decent level and have high regen, you're food can go > down really fast. Yes... a resounding yes, but that is not what seems problematic. It's pretty cool to have the regen rate so the food loss there is more than reasonable. > If you are fully healed, a high regen rate doesn't affect food > consumption that much I think. I don't think that is true. The 3-1 rates mentioned in the original post were standing around doing nothing. That's what limits you. Now, is it more "real"? Probably, but it isn't scaled well with the other characters. In all, I am enjoying the differences of playing a Gaean Halfling... but it does seem that the food rate during inactivity is a bit high. Kevin From mwedel at sonic.net Wed Oct 11 01:35:32 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 10 Oct 2006 23:35:32 -0700 Subject: [crossfire] Food consumption In-Reply-To: References: <200610091301.39250.kbulgrien@worldnet.att.net> <200610092230.48883.kbulgrien@worldnet.att.net> <452B2BDA.9010406@sonic.net> Message-ID: <452C90B4.2020302@sonic.net> Kevin R. Bulgrien wrote: > Mark Wedel wrote: > >> Kevin R. Bulgrien wrote: >>>> I am running an x86_64 test server with an Opteron processor. Food >>>> consumption seems unreal... > >>> I never played Gaea before... That's what's doing it. Regeneration +2... >>> Man, I need to carry a refrigerator around with me... :-) >> A separate discussion could perhaps be change food consumption rate. >> >> High food consumption just means you carry around lots of food - not >> much other affect. > > Hmmm... Well, food beep seems to not be working again... Lately I have > been working on maps with my client up and running, and have died quite > a few times due to starvation because the warning seems to not work > anymore. It has been patched ages ago, but I guess something has broken > it again. Looking at the code, I don't see anything odd with the foodbeep code. > > Also, the poor halfling cannot carry very much weight, so has to resort > o eating carcasses... blech... in a dungeon crawl. He is not nearly > high enough level to have create food, town portal, and the like. Not > complaining here so much as saying its not quite as simple as carrying > lots of food. IIRC, carrying capacity is directly related to strength. Of course, halflings have a strength penalty, so that doesn't help. > I don't think that is true. The 3-1 rates mentioned in the original post > were standing around doing nothing. That's what limits you. Now, is it > more "real"? Probably, but it isn't scaled well with the other characters. Which is maybe a decent question - the regen rate for Gaea is seen as an advantage. I don't know if the high food consumption rate was factored in as a disadvantage, or is an unintended side effect. And in some sense, having it as a granted ability from Gaea is a disadvantage, in that you can't turn it off. For other character, you can just take off the ring of regeneration and be back to normal food consumption. From mwedel at sonic.net Wed Oct 11 01:49:10 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 10 Oct 2006 23:49:10 -0700 Subject: [crossfire] Improved/redone client. In-Reply-To: <452BA1BE.4080009@telus.net> References: <452A040C.20105@sonic.net> <452B4D72.2010009@sonic.net> <452BA1BE.4080009@telus.net> Message-ID: <452C93E6.7040606@sonic.net> Alex Schultz wrote: > -If you try to make a keybinding over a key that is already bound > something, it shouldn't just append to the list, it should warn you and > if you choose to continue, remove the old binding first. Yes - that is a valid point - overbinding a key doesn't make sense. But it gets a little odd with modifiers. > -One idea that might be good, is while it is waiting for you to press a > key to bind to, it should come up with a graphical display of the keys > on the keyboard, and with color coding showing which keys are already > bound. Tooltips when hovering over a key show what is bound there and > clicking a key counts as if you pressed that key. I don't know if there is a widget for that or not. That is not something I'd want to have to write ourselves. We just can have a universal looking keyboard - after all, laptops, different keyboards, etc, can have different layouts. >> Inventory control via keyboard: I'd be interested in how people think that >> should work - I really can't envision much any reasonable way to control the >> inventory only by keyboard, whether we use gtk2 widget or write our own. I'd >> personally consider this to be a pretty low thing to do. > Personally I think this would make a big improvement if it could be > pulled off in a reasonable manner. The best I've seen for keyboard > inventory control in large inventories, would be how nethack does it > even in it's gtk interface. That keyboard interface might work well if > we used popups, however see the popup issues above. One could do > something though with giving focus the inventory list and allowing > keyboard scrolling of it and pressing keys to apply from it or drop etc. > however one would need to make it VERY obvious to the player when they > have focus on that, and also would have to make it very difficult to > accidentally trigger while easy to trigger manually (and for fairly > obvious reason I don't think focus on click would work well for it...) A valid question may be whether the inventory interface should be completely redone. The mouse buttons I believe kept what was used in the old X11 client. I don't think the current button presses conform to what people would expect from a GTK application. I'd say that a single button press being the expected behavior is not standard. What comes to mind could be something like this: Left click selects an item. A double click applies the item (most common operation). Double middle click drops item (second most common operation?) Right clicking on a selected item brings up a little pop up menu on additional item actions (drop, lock, apply, examine, mark, etc). I think that is better than having these odd shift and control combos. From mwedel at sonic.net Wed Oct 11 02:05:04 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 11 Oct 2006 00:05:04 -0700 Subject: [crossfire] Improved/redone client. In-Reply-To: <200610102329.09390.nicolas.weeger@laposte.net> References: <452A040C.20105@sonic.net> <200610102329.09390.nicolas.weeger@laposte.net> Message-ID: <452C97A0.4070205@sonic.net> > > A nice thing would be to have a generic client, with an interface layer. This > way we could apply different interfaces while retaining a common layer. Think > something like Firefox's XUL, maybe? (as a concept, i certainly don't suggest > to use that language for the interface). > Maybe with a "widget" system? Let users write (in Python? LUA?) their own > displaying widget to display game information? The problem/complication is that at some level, the UI becomes a pretty major portion of the code. And it probably makes more sense to spend our time to just get a good, thorough working client with (for lack of better term) hardcoded toolkits and not have some scripting writing language that no one really uses. Now an intersting side point to this is that the gtk2 client uses glade for all the layout. In theory, someone could write a new glade file/description, and as long as all the widgets remain the same, could just be dropped in place. This in fact may be the thing to do relative to high and low resolution clients - rather than trying to have layout to cover everything, having two glade files might not be that unreasonable. Now I do think the current code may need some additional work. In such a model, I could certainly see some versions not implementing all the widgets (for space reasons, whatever else). That can easily enough be handled I think in the code to make sure the widget isn't null, but that checking isn't there right now. From lalo.martins at gmail.com Fri Oct 13 01:36:34 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri, 13 Oct 2006 14:36:34 +0800 Subject: [crossfire] Improved/redone client. References: <452A040C.20105@sonic.net> Message-ID: On Mon, 09 Oct 2006 01:10:52 -0700, Mark Wedel wrote: > Make client fullscreen. > > Reasoning here is that most games run in fullscreen mode, so it becomes more > like most games. It can also ensure that other applications are not grabbing > keystrokes/button presses (eg, window manager, etc), so if we tell the player to > press a key, we can know for sure that if the player presses that key, the > client gets it. For lots of reasons, would still need to support a windowed > mode of operation. > > My thoughts: I personally find fullscreen applications annoying, so would also > use the window mode (I think most people using unix don't expect full screen > apps). While we can run fullscreen, I don't think we can or should attempt to > switch resolution. This does then mean that client could be asked to run at odd > dimensions. I think this issue needs to be investigated further - it may be > possible to make the pointer captive in a non full screen window. I also think > that if we do full screen window, it needs to be pretty clear how to get out of > it (nothing more annoying than an app taking over your system) It may have happened while I was in Hong Kong, but from the UI discussions I've seen, I don't remember anyone defending fullscreen clients. Rather, we (myself included) used the term "foolscreen" loosely to describe something else entirely, which is probably more correctly termed "fullwindow". The idea is that the current clients display way too much information; someone has described them as "geeky". Typically, when playing, you're interested: in the map (always), hp/sp/grace/food (almost always), important messages (almost always), chat (often), exp (often), and "look" list (frequently). Everything else only needs to be looked at occasionally. By the basic rules of UI design, it follows that these are the elements that should be always there; if possible, progressively less intrusive in the order above. Other elements should be easy to bring up, but off by default. The solution usually thought of as the best is a design similar to other games, like experimented with in sdlclient and the cfplus client; the map is the main element, taking up almost the whole area, and the other important elements are around the map, possibly in the form of a HUD. Messages and chat could be overlayed on the top left / bottom left of the map, where they're less likely to obscure something important. Pressing ' brings up the "console", where not only you can type, but you can scroll back trough old messages and maybe even see messages that your client was configured not to display in real-time. Other keys (or clicking on "handles" on the edges of the window) would bring up everything else -- basic stats, resists, inventory, spell list, the works. Then of course this raises a separate discussion of widgets. I think "custom" widgets are more appealing, but they have all the disadvantages pointed out by Quinet (specially, clipboard support), and they're obviously extra work. I think such a design is not at all impossible to implement using gtk+ widgets; it may even evolve from the codebase of the current v2 client. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From lalo.martins at gmail.com Fri Oct 13 01:43:17 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri, 13 Oct 2006 14:43:17 +0800 Subject: [crossfire] Pupland Monunent Service References: <451DCF5A.2050406@telus.net> Message-ID: On Fri, 29 Sep 2006 19:58:50 -0600, Alex Schultz wrote: > Currently, the hall of fame in pupland just sits there static, so I'm > thinking that perhaps I should make a python script replacement for the > monument service, to inscribe the names of those who have beat the evil > masters if they want it inscribed. Anyone have any objections to > replacing the monument with a 'magical' python based one? Awesome. As long as some of the names that are there now are kept statically in the top of the list -- specially those of pupland contributors if they're there. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From alex_sch at telus.net Fri Oct 13 09:27:52 2006 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 13 Oct 2006 08:27:52 -0600 Subject: [crossfire] SVN revions in version Message-ID: <452FA268.9070105@telus.net> A few times, tracking the svn revision instead of the $Id strings has been brought up. IMHO this should be done, both in the client and server. I propose we implement it as follows in both: Create a version.h file containing something like: #include "svnversion.h" #define BASE_VERSION "2.0.0-dev" #ifdef SVN_REV #define VERSION BASE_VERSION"-r"SVN_REV #else #define VERSION BASE_VERSION #endif In release tarballs, the "-dev" postfix to BASE_VERSION will be removed and it will be adjusted to ignore SVN_REV. Then have a defaultly blank svnversion.h file, which the building process will create simply in the form of: #define SVN_REV "5678" The ./configure stage will check for the presence of .svn and the svnversion command, while the build process will run svnversion. The build process running svnversion because not all revisions require ./configure to be re-run. Also, it will only write svnversion.h if a check shows that it was checked out from official crossfire svn, this is to ensure all revision numbers correspond to the same repository. This version would both be used in the client for outputing to the console instead of the rcs-id values, and the server will use this version for reporting to the metaserver as well as console output. Does this model make sense to everyone? Alex Schultz From brenlally at gmail.com Fri Oct 13 12:15:08 2006 From: brenlally at gmail.com (Brendan Lally) Date: Fri, 13 Oct 2006 18:15:08 +0100 Subject: [crossfire] SVN revions in version In-Reply-To: <452FA268.9070105@telus.net> References: <452FA268.9070105@telus.net> Message-ID: <7903f03c0610131015h52ff7b30i2767421a24468da2@mail.gmail.com> On 10/13/06, Alex Schultz wrote: > A few times, tracking the svn revision instead of the $Id strings has > been brought up. IMHO this should be done, both in the client and > server. I propose we implement it as follows in both: > > .... > > This version would both be used in the client for outputing to the > console instead of the rcs-id values, and the server will use this > version for reporting to the metaserver as well as console output. Does > this model make sense to everyone? I'm not sure it is such a great idea to send the revision number to the metaserver, certainly not if the metaserver is going to push that information out to clients, in that case, someone who wished to be annoying could look for servers with revisions predating certain bug fixes or balance tweaks and abuse or exploit them. If you are talking about sending the revision as a seperate field to the metaserver, that isn't for propagation to clients. then that is a different issue altogether, and could provide useful information about things like how quickly updates are made available in practice. Likewise, although the clients need only open a connection to the metaserver to recieve the server list, having the official clients send their revision numbers by default would give some indication as to which versions of the clients are in use. (assuming the metaserver were suitably modified to read that information from the socket). From alex_sch at telus.net Fri Oct 13 16:37:37 2006 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 13 Oct 2006 15:37:37 -0600 Subject: [crossfire] SVN revions in version In-Reply-To: <7903f03c0610131015h52ff7b30i2767421a24468da2@mail.gmail.com> References: <452FA268.9070105@telus.net> <7903f03c0610131015h52ff7b30i2767421a24468da2@mail.gmail.com> Message-ID: <45300721.2050607@telus.net> Brendan Lally wrote: > I'm not sure it is such a great idea to send the revision number to > the metaserver, certainly not if the metaserver is going to push that > information out to clients, in that case, someone who wished to be > annoying could look for servers with revisions predating certain bug > fixes or balance tweaks and abuse or exploit them. Hmm, well I guess that is somewhat of an issue. What about having ./configure time option to make it very easy for server admins to decide if they want the revision number included in the version string sent to the metaserver? Alex Schultz From cher at riedquat.de Fri Oct 13 15:36:18 2006 From: cher at riedquat.de (Christian Hujer) Date: Fri, 13 Oct 2006 22:36:18 +0200 Subject: [crossfire] SVN revions in version In-Reply-To: <7903f03c0610131015h52ff7b30i2767421a24468da2@mail.gmail.com> References: <452FA268.9070105@telus.net> <7903f03c0610131015h52ff7b30i2767421a24468da2@mail.gmail.com> Message-ID: <200610132236.22956.cher@riedquat.de> On Friday 13 October 2006 19:15 Brendan Lally wrote: > On 10/13/06, Alex Schultz wrote: > > A few times, tracking the svn revision instead of the $Id strings has > > been brought up. IMHO this should be done, both in the client and > > server. I propose we implement it as follows in both: > > > > .... > > > > This version would both be used in the client for outputing to the > > console instead of the rcs-id values, and the server will use this > > version for reporting to the metaserver as well as console output. Does > > this model make sense to everyone? > > I'm not sure it is such a great idea to send the revision number to > the metaserver, certainly not if the metaserver is going to push that > information out to clients, in that case, someone who wished to be > annoying could look for servers with revisions predating certain bug > fixes or balance tweaks and abuse or exploit them. Oh really? Yeah, there's so many different crossfire servers out there that I really need this information to choose the right ones to attack, otherwise the chances of finding a bogus one are hopeless ;-) (I hope it was obvious that I was ironic ;-) > If you are talking about sending the revision as a seperate field to > the metaserver, that isn't for propagation to clients. then that is a > different issue altogether, and could provide useful information about > things like how quickly updates are made available in practice. > > Likewise, although the clients need only open a connection to the > metaserver to recieve the server list, having the official clients > send their revision numbers by default would give some indication as > to which versions of the clients are in use. (assuming the metaserver > were suitably modified to read that information from the socket). Oh that would make it easy for a bogus server to abuse or exploit known client bugs to hack client machines. If balancing protecting clients from abuse vs. protecting servers from abuse, I'd say protecting clients is more important for several reasons: * There are more clients than servers (yes, even for crossfire ;-) * A typical client user puts blind trust in client software. * A typical server admins knows of the dangers of running public services. I definitely vote for including the server's revision in the meta server in public. This allows players to tell the mapset and set of bugfixes a server's most likely to be using. You could always make this field optional so anxious server admins can exclude that field from the metaserver information. I know that Brendan might have talked about game balance issues, not security concerns, yet I'm pro eventually optionally) including the server's revision in the metaserver. My 2 cents Cher :) -- Christian Hujer Free software developer mailto:cher at riedquat.de http://www.riedquat.de/ PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20061013/4fbd2d1e/attachment.pgp From brenlally at gmail.com Fri Oct 13 17:54:36 2006 From: brenlally at gmail.com (Brendan Lally) Date: Fri, 13 Oct 2006 23:54:36 +0100 Subject: [crossfire] SVN revions in version In-Reply-To: <200610132236.22956.cher@riedquat.de> References: <452FA268.9070105@telus.net> <7903f03c0610131015h52ff7b30i2767421a24468da2@mail.gmail.com> <200610132236.22956.cher@riedquat.de> Message-ID: <7903f03c0610131554r1efd1254k9cc71d548637af8f@mail.gmail.com> On 10/13/06, Christian Hujer wrote: > > > Likewise, although the clients need only open a connection to the > > metaserver to recieve the server list, having the official clients > > send their revision numbers by default would give some indication as > > to which versions of the clients are in use. (assuming the metaserver > > were suitably modified to read that information from the socket). > Oh that would make it easy for a bogus server to abuse or exploit known client > bugs to hack client machines. I apologise if I was unclear on that point, I'm talking about sending the information to the /metaserver/, not the individual servers for the purpose of determining client version usage rates. Currently the best guess as to which clients everyone is running is based on connections to metaforge, but most of these people probably query the metaserver first (since that is default behaviour). It would be nice to be able to tell roughly what versions everyone is running in terms of addressing issues of backwards compatibility (eg, is anyone using 1.4 or 1.5 still, and is it therefore safe to break compatibility? or, if a serious bug is found, is it worth making a new point release for a version that the majority of the userbase runs?) Likewise if the interface mode (gtk2, gtk, x11) were sent, then there would be some usage statistics to base the questions about client design on. I am thinking of something to go alongside http://crossfire.real-time.com/metaserver/ that instead of listing servers would list summary statistics for the clients, eg In the last week there were x client connections of which y were from unique IP addresses from n different countries. They were using the following versions: 1.7 ...% 1.7.1 ...% 1.8 ...% and so on. In terms of client abuse of servers though, I am thinking of annoying bugs and balance exploits and not security concerns. To give a recent example, if someone sees a server running revision <= 4995 then they may know they will be able to unequip cursed weapons by changing skill and abuse that bug, whereas it might not occur to them to check otherwise. From nicolas.weeger at laposte.net Sat Oct 14 10:27:39 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 14 Oct 2006 17:27:39 +0200 Subject: [crossfire] Client-side scripting In-Reply-To: <200609170959.05139.nicolas.weeger@laposte.net> References: <200608261927.52478.nicolas.weeger@laposte.net> <200609170959.05139.nicolas.weeger@laposte.net> Message-ID: <200610141727.39354.nicolas.weeger@laposte.net> > Hello. > > I've finished a first basic version. > > Patch is available on tracker at > https://sourceforge.net/tracker/index.php?func=detail&aid=1560052&group_id= >13833&atid=313833 So, no one has any comment? :) Does that mean it's wonderful (so everyone's speechless), and I can commit it? *evil grin* Nicolas From antonoussik at gmail.com Sat Oct 14 17:25:39 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Sat, 14 Oct 2006 23:25:39 +0100 Subject: [crossfire] Client-side scripting In-Reply-To: <200610141727.39354.nicolas.weeger@laposte.net> References: <200608261927.52478.nicolas.weeger@laposte.net> <200609170959.05139.nicolas.weeger@laposte.net> <200610141727.39354.nicolas.weeger@laposte.net> Message-ID: > So, no one has any comment? :) > > Does that mean it's wonderful (so everyone's speechless), and I can commit it? > *evil grin* Seems that way! :-) From kbulgrien at worldnet.att.net Sun Oct 15 21:37:29 2006 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 15 Oct 2006 21:37:29 -0500 Subject: [crossfire] Improved/redone client. In-Reply-To: References: <452A040C.20105@sonic.net> Message-ID: <200610152137.29963.kbulgrien@worldnet.att.net> > The idea is that the current clients display way too much information; > someone has described them as "geeky". Typically, when playing, you're > interested: in the map (always), hp/sp/grace/food (almost always), > important messages (almost always), chat (often), exp (often), and "look" > list (frequently). Everything else only needs to be looked at > occasionally. By the basic rules of UI design, it follows that these are > the elements that should be always there; if possible, progressively less > intrusive in the order above. Other elements should be easy to bring up, > but off by default. I have been giving this extra thought lately, and fired up the gtk2 client. I have to say I do not agree with the statement that the clients are too geeky, but then again, I score high on nerd tests too. At first I thought the gtk2 client tabbed information was cool, but, I still go back to the gtk1 client, again because I can see everything. The fact is, the more information you have at the ready, the better you can shoot the bogey's down. There really is no other way to do battle effectively. The resistances might qualify for hiding, but even they help remind you who not to go up against without checking equipment. Maybe if you are high-level, you never look at those things, but I would not find crossfire nearly as fun without the "geek factor" of the GTK1 client. Every time I try the GTK2 client I get frustrated at how much is not on screen. On another note, also probably indicating geekish tendency, I think the key binding interface would be just too cool if it supported some sort of rudimentary scripting capability... Why not have a client-embedded script that could trigger auto-keypresses, sound bites, or stuff like that? Maybe even some capability to glob things so, for instance, the same binding would work to equip, use, unequip a scroll, staff, or rod of something... and would work no matter which one you had. Now that... would be cool... ... and awesomely geeky.... How on earth does anyone come up with the idea that clients like this should not be geeky? ;-) From kbulgrien at worldnet.att.net Sun Oct 15 22:11:07 2006 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 15 Oct 2006 22:11:07 -0500 Subject: [crossfire] Client-side scripting In-Reply-To: <200610141727.39354.nicolas.weeger@laposte.net> References: <200608261927.52478.nicolas.weeger@laposte.net> <200609170959.05139.nicolas.weeger@laposte.net> <200610141727.39354.nicolas.weeger@laposte.net> Message-ID: <200610152211.07436.kbulgrien@worldnet.att.net> LOL,,, see my post of a few minutes ago under client improvements. Man, another dependency... ;-) Never heard of lua before. From alex_sch at telus.net Sun Oct 15 22:19:17 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 15 Oct 2006 21:19:17 -0600 Subject: [crossfire] Client-side scripting In-Reply-To: <200610152211.07436.kbulgrien@worldnet.att.net> References: <200608261927.52478.nicolas.weeger@laposte.net> <200609170959.05139.nicolas.weeger@laposte.net> <200610141727.39354.nicolas.weeger@laposte.net> <200610152211.07436.kbulgrien@worldnet.att.net> Message-ID: <4532FA35.4030203@telus.net> Kevin R. Bulgrien wrote: > LOL,,, see my post of a few minutes ago under client improvements. > > Man, another dependency... ;-) Never heard of lua before. Well, I was under the impression that Ryo was planning on putting the lua source base bundled with the client source. It's rather small, and to my understanding that's normal practice for many things that use lua. Alex Schultz From mwedel at sonic.net Sun Oct 15 23:22:20 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 15 Oct 2006 21:22:20 -0700 Subject: [crossfire] SVN revions in version In-Reply-To: <452FA268.9070105@telus.net> References: <452FA268.9070105@telus.net> Message-ID: <453308FC.3030203@sonic.net> Alex Schultz wrote: > A few times, tracking the svn revision instead of the $Id strings has > been brought up. IMHO this should be done, both in the client and > server. I propose we implement it as follows in both: > > Create a version.h file containing something like: > > #include "svnversion.h" > > #define BASE_VERSION "2.0.0-dev" It should actually get that version number from autoconf, like it does now. Then as part of that, for official releases, the -dev tag can be removed from configure.ac > In release tarballs, the "-dev" postfix to BASE_VERSION will be removed > and it will be adjusted to ignore SVN_REV. Then have a defaultly blank > svnversion.h file, which the building process will create simply in the > form of: > > #define SVN_REV "5678" > > The ./configure stage will check for the presence of .svn and the > svnversion command, while the build process will run svnversion. The check for .svn would be better done in the makefile. configure can check for svnversion. In addition, if the makefile doesn't find a .svn directory, or does not find svnversion, it should create a svnversion.h file with an empty SVN_REV, eg: #define SVN_REV "" To the best of my knowledge, there isn't really any way to include a file if it exists, don't include it if it doesn't. So it is just a lot simpler to always include it. You really don't want the svnversion.h file to be any part of SVN, because otherwise people will accidentally check it in and now have a version number that isn't correct. > The > build process running svnversion because not all revisions require > ./configure to be re-run. Also, it will only write svnversion.h if a > check shows that it was checked out from official crossfire svn, this is > to ensure all revision numbers correspond to the same repository. I think checking for official repository checkout is probably overkill and isn't needed. After all, if a developer really wants to have a bogus SVN_REV number, there are a lot easier ways to do it. > > This version would both be used in the client for outputing to the > console instead of the rcs-id values, and the server will use this > version for reporting to the metaserver as well as console output. Does > this model make sense to everyone? That sounds fine to me. From mwedel at sonic.net Sun Oct 15 23:28:00 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 15 Oct 2006 21:28:00 -0700 Subject: [crossfire] SVN revions in version In-Reply-To: <7903f03c0610131015h52ff7b30i2767421a24468da2@mail.gmail.com> References: <452FA268.9070105@telus.net> <7903f03c0610131015h52ff7b30i2767421a24468da2@mail.gmail.com> Message-ID: <45330A50.4070409@sonic.net> Brendan Lally wrote: > I'm not sure it is such a great idea to send the revision number to > the metaserver, certainly not if the metaserver is going to push that > information out to clients, in that case, someone who wished to be > annoying could look for servers with revisions predating certain bug > fixes or balance tweaks and abuse or exploit them. OTOH, this really isn't much different than right now. Server xyz is running 1.9.0, which doesn't have some bug fix in 1.9.1, etc. At some level, it becomes security through obscurity. And if we believe that 2.0 will take quite a while to finally get out and release, and that some servers may start running 2.0 for testing purposes, they may very well want to advertise their version. Of course, that is all up to the server - as far as the metaserver protocol is concerned, it is just a text string, so doesn't care what is in it (I could modify a server right now to claim it is version 2.5 for example). > > If you are talking about sending the revision as a seperate field to > the metaserver, that isn't for propagation to clients. then that is a > different issue altogether, and could provide useful information about > things like how quickly updates are made available in practice. Current metaserver protocol doesn't really support more fields. It wouldn't be hard to add. There was some discussion in the past about a new metaserver layout - that is a different discussion, but could be worth revisiting. > > Likewise, although the clients need only open a connection to the > metaserver to recieve the server list, having the official clients > send their revision numbers by default would give some indication as > to which versions of the clients are in use. (assuming the metaserver > were suitably modified to read that information from the socket). See note above. From mwedel at sonic.net Sun Oct 15 23:30:36 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 15 Oct 2006 21:30:36 -0700 Subject: [crossfire] SVN revions in version In-Reply-To: <45300721.2050607@telus.net> References: <452FA268.9070105@telus.net> <7903f03c0610131015h52ff7b30i2767421a24468da2@mail.gmail.com> <45300721.2050607@telus.net> Message-ID: <45330AEC.6000505@sonic.net> Alex Schultz wrote: > Brendan Lally wrote: >> I'm not sure it is such a great idea to send the revision number to >> the metaserver, certainly not if the metaserver is going to push that >> information out to clients, in that case, someone who wished to be >> annoying could look for servers with revisions predating certain bug >> fixes or balance tweaks and abuse or exploit them. > Hmm, well I guess that is somewhat of an issue. What about having > ./configure time option to make it very easy for server admins to decide > if they want the revision number included in the version string sent to > the metaserver? It should be a settings option, not a configure option. Putting it in the settings makes it a lot easier all around. configure options should really only be used for things that need a recompile to take affect (libraries, compiled in options, etc). It shouldn't be used for things that are easy to control at run time. It would also be pretty annoying to loose such a change because you re-run configure without specifying all the same options. From alex_sch at telus.net Sun Oct 15 23:35:48 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 15 Oct 2006 22:35:48 -0600 Subject: [crossfire] SVN revions in version In-Reply-To: <45330AEC.6000505@sonic.net> References: <452FA268.9070105@telus.net> <7903f03c0610131015h52ff7b30i2767421a24468da2@mail.gmail.com> <45300721.2050607@telus.net> <45330AEC.6000505@sonic.net> Message-ID: <45330C24.8020308@telus.net> Mark Wedel wrote: > Alex Schultz wrote: > >> Hmm, well I guess that is somewhat of an issue. What about having >> ./configure time option to make it very easy for server admins to decide >> if they want the revision number included in the version string sent to >> the metaserver? >> > It should be a settings option, not a configure option. Putting it in the > settings makes it a lot easier all around. Agreed. Actually, that thought happened to come to mind while I was bored at work today :) Alex Schultz From mwedel at sonic.net Sun Oct 15 23:42:15 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 15 Oct 2006 21:42:15 -0700 Subject: [crossfire] SVN revions in version In-Reply-To: <200610132236.22956.cher@riedquat.de> References: <452FA268.9070105@telus.net> <7903f03c0610131015h52ff7b30i2767421a24468da2@mail.gmail.com> <200610132236.22956.cher@riedquat.de> Message-ID: <45330DA7.8010700@sonic.net> Christian Hujer wrote: > On Friday 13 October 2006 19:15 Brendan Lally wrote: >> Likewise, although the clients need only open a connection to the >> metaserver to recieve the server list, having the official clients >> send their revision numbers by default would give some indication as >> to which versions of the clients are in use. (assuming the metaserver >> were suitably modified to read that information from the socket). > Oh that would make it easy for a bogus server to abuse or exploit known client > bugs to hack client machines. Well, right now, the client does support some basic information to the server when it connections (type of client, its last official version (1.9.0, 1.9.1, etc). Since generally speaking, there isn't any real way to fix old clients (if someone is still using 1.8.0 client, making a patch for known bugs to that client isn't likely to help, as most likely, person isn't going to get it updated), there could already be a pretty large list of exploits. Things like 'if client is older than 1.9.1, these bugs exist which I could exploit'. Whether the server knows the SVN number or not probably won't make a big difference. However, I do agree, there really isn't much reason for the server to know the SVN number. What would be more interesting, from a data collection standpoint, is knowing the number of people that are actually compiling out of SVN vs using officially downloaded clients. I'm not sure what I would do with that knowledge, other than to say 'hmm, interesting, x% of players get there client from SVN'. Related to that could be precompiled vs non precompiled clients somehow reporting that. However, that really is more dangerous. If a server admin was going to try to hijack a client, using a precompiled client is the way to do it. Any 'compile it yourself' client has so many variables (compiler options, version of the compiler, type of system it is compiled on) to make most all exploit bugs (typically buffer overflows) virtually impossible. However, if the developer can download the same client that players are using (precompiled), they can play around with the exploit, write the code that properly hijacks it, etc with a high level of success (different versions of some of the libraries may make a difference). So if anything, not having clients report their version doesn't make it harder for server admins, they just can't know who to target. And if the 'fixed' clients have some form of reporting (server abc sending bogus data that looks to be trying to exploit bug abc), and the server can't know which of those clients might report, that may make it so that the server admin won't try it. I would say that any server that is trying to do such things should be blacklisted from the metaserver (and potentially reported to the service provider). From alex_sch at telus.net Sun Oct 15 23:48:37 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 15 Oct 2006 22:48:37 -0600 Subject: [crossfire] SVN revions in version In-Reply-To: <453308FC.3030203@sonic.net> References: <452FA268.9070105@telus.net> <453308FC.3030203@sonic.net> Message-ID: <45330F25.9010107@telus.net> Mark Wedel wrote: > It should actually get that version number from autoconf, like it does > now. > Then as part of that, for official releases, the -dev tag can be removed from > configure.ac > I didn't know that autoconf currently stored that. That makes sense to me. > In addition, if the makefile doesn't find a .svn directory, or does not find > svnversion, it should create a svnversion.h file with an empty SVN_REV, eg: > > #define SVN_REV "" > > To the best of my knowledge, there isn't really any way to include a file if > it exists, don't include it if it doesn't. So it is just a lot simpler to > always include it. > Agreed with the reason below, but the problem with that, is that version.h shouldn't append "-r" unless it has a SVN_REV, and easier to check in defines if SVN_REV is defined at all, instead of checking if it's "" or not. Because of that, it seems like a better idea to me to leave the SVN_REV check as I suggested, not include svnversion.h in SVN, and make it just make an empty file if it doesn't have a revision. > You really don't want the svnversion.h file to be any part of SVN, because > otherwise people will accidentally check it in and now have a version number > that isn't correct. > Agreed, though see above. >> The >> build process running svnversion because not all revisions require >> ./configure to be re-run. Also, it will only write svnversion.h if a >> check shows that it was checked out from official crossfire svn, this is >> to ensure all revision numbers correspond to the same repository. >> > > I think checking for official repository checkout is probably overkill and > isn't needed. After all, if a developer really wants to have a bogus SVN_REV > number, there are a lot easier ways to do it. > Well, I was more thinking of server admins accidentally doing that. Of course, if they set up their own repositories, they should be competent enough to either disable sending the revision or to make the base version unique. Alex Schultz From mwedel at sonic.net Mon Oct 16 01:57:59 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 15 Oct 2006 23:57:59 -0700 Subject: [crossfire] SVN revions in version In-Reply-To: <45330F25.9010107@telus.net> References: <452FA268.9070105@telus.net> <453308FC.3030203@sonic.net> <45330F25.9010107@telus.net> Message-ID: <45332D77.70209@sonic.net> Alex Schultz wrote: > Agreed with the reason below, but the problem with that, is that > version.h shouldn't append "-r" unless it has a SVN_REV, and easier to > check in defines if SVN_REV is defined at all, instead of checking if > it's "" or not. Because of that, it seems like a better idea to me to > leave the SVN_REV check as I suggested, not include svnversion.h in SVN, > and make it just make an empty file if it doesn't have a revision. That would be fine. From mwedel at sonic.net Mon Oct 16 01:56:51 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 15 Oct 2006 23:56:51 -0700 Subject: [crossfire] Crossfire protocol cleanup In-Reply-To: <7903f03c0610101233ja549a0cq4b54eb4b46447df4@mail.gmail.com> References: <4529FC43.70909@sonic.net> <7903f03c0610101233ja549a0cq4b54eb4b46447df4@mail.gmail.com> Message-ID: <45332D33.3000807@sonic.net> Brendan Lally wrote: > On 10/9/06, Mark Wedel wrote: >> - May not be able to use a 2.0 client to play on an older server (depends on how >> old, and what protocol commands to use). Could still use the 1.x clients of course. > > Might I suggest then, that when the 2.0 protocol changes are (vaguey) > finalised, a version of the 1.x server be released which understands a > 2.x version number and acts as though all of the appropriate setup > flags were set (without adding any of the new features), and also is > aware of any new commands that can be sent to it, but merely ignores > them (with suitable draw_info-ed error messages). That way it should > be possible to have a compatibility upgrade to the server allowing > both sets of clients to work for however long it would be until most > distros have upgraded the versions they ship. It's really hard to say how well that will work until all the changes to the protocol are done. And I don't know right now what all those changes may be. There are several potential issues: - Some existing protocol command is removed from the trunk branch, replaced by something else. In this case, it is easy for the client or server to ignore the command, the problem is that if this command has critical information, doing so results in a broken setup. This scenario probably isn't too likely. - An existing command is extended to include values it did not include before. Depending on the direction of the command, this may or may not be easily handled. For example, if the 2.0 server will send some existing values that the 1.x server won't, that probably won't cause any issues for using a 2.0 client on a 1.x server (it can handle those values, would just never get them). A 1.x client on a 2.0 server will have problems - it will get what it sees as bogus data in some commands. The protocol commands are not self documenting, so the best the client can do is just ignore all data after that bogus value (it won't know the size of the bogus data so won't know how much to skip, etc). And if the change is in the C->S direction, then scenario is reversed - 2.0 client on 1.x server would have issues. I think this scenario is fairly likely to occur. - New values are not added, but rather the meaning or type of existing values are changed (something is currently sent as 16 bits, we decide it should be 32 bits, etc). This basically has all the same issues as the point above. So going back to the original point of the post, which was having a 1.x client that could play on 2.0 servers, this is what I would see have to be done: 1) the 1.x client would have to fully understand the 2.0 protocol. anything less, and there is too great a risk of serious functionality be missing or bugs happening, etc. 2) For this to make sense, this 1.x client would have to be released quite a while before 2.0 is released. releasing it 2 weeks before 2.0 wouldn't make sense - at that point, just grab the 2.0 client, etc 3) Such a client would still have to know/be valid on the protocol version numbers. The client itself could change what SC/CS_VERSION it reports to the server based on what the server tells it (basically lie). It would then choose not to do the setup command based on this. 4) To be compatible with 1.x server, basically all the code related to 1.x protocol commands has to be retained. Now as I type all this in, I see a major problem. If we do the above, it basically removes/obsoletes the 2.0/trunk version of the client. If the 1.x client is fully functional with everything, why do you need a 2.0 client? And it then makes other proposed changes more difficult (getting rid of some of the older client interfaces, doing a cleanup, etc). It would pretty much mean that the 1.x client branch would probably have to be maintained pretty for the duration of the 2.0 release. It's easier to remove old clients or support at the major release than later. In short, if when 2.0 comes out, we say you have to use a 2.0 client, people would not their head and say OK. If instead, when 2.0 comes out, you can use a 2.0 or 1.x client, it becomes very difficult when 2.1 comes out to say you can't use that 1.x client anymore (people will ask what has changed, what can be done, make patches, etc). I don't mind this being unofficially supported (can't control that anyways), but I don't want to support it personally. So what probably makes more sense is this: Release a 2.0 client some time (3 months?) before the projected 2.0 server release, to allow time to make it into the various distributions, etc. Maybe call it a beta release. This 2.0 client could only be used on 2.0 servers (likely missing support for 1.x servers). At the time of the client release, the 2.0 protocol version strings are frozen, and any changes made to the protocol have to go back to using the setup commands. This may have other advantages - I'd expect as we get near, we'd have various public servers running 2.0 code for testing purposes - for that reason, having some clients out there would make sense. The downside is that these 2.0 clients can be used on 1.x servers, but that probably isn't that big an issue. I don't think there should be anything preventing a use from having both 2.x and 1.x clients installed on a system, or if there are things preventing it, it probably just means changing the pathname here or there. From mwedel at sonic.net Mon Oct 16 02:08:54 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 16 Oct 2006 00:08:54 -0700 Subject: [crossfire] Improved/redone client. In-Reply-To: <200610152137.29963.kbulgrien@worldnet.att.net> References: <452A040C.20105@sonic.net> <200610152137.29963.kbulgrien@worldnet.att.net> Message-ID: <45333006.2070804@sonic.net> Kevin R. Bulgrien wrote: > I have been giving this extra thought lately, and fired up the gtk2 client. I > have to say I do not agree with the statement that the clients are too geeky, > but then again, I score high on nerd tests too. At first I thought the gtk2 > client tabbed information was cool, but, I still go back to the gtk1 client, again > because I can see everything. The fact is, the more information you have > at the ready, the better you can shoot the bogey's down. There really is no > other way to do battle effectively. The resistances might qualify for hiding, > but even they help remind you who not to go up against without checking > equipment. Maybe if you are high-level, you never look at those things, but > I would not find crossfire nearly as fun without the "geek factor" of the GTK1 > client. Every time I try the GTK2 client I get frustrated at how much is not > on screen. That may illustrate some of the problem however. I suspect that if we did a widescale pool, we'd get following results: Everyone would agree that some elements should always be displayed (hp, sp, some others). A mixture of people agreeing what other things should always be displayed. Some would say that ABC should always be displayed, but I don't need DEF. Other saying I really like DEF, but don't care about GHI, etc. And you'll get different input on how that data should be displayed. For example, in the gtk1 client, things like skills and protections are in scrolled windows - some people may find that annoying, etc. I think the best we can hope for is a try to get something that most people would agree on. I don't think we can ever get anything that everyone would agree on (and probably, even in the case of the current clients, everyone has something they'd like done slightly differently). From mwedel at sonic.net Mon Oct 16 02:36:52 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 16 Oct 2006 00:36:52 -0700 Subject: [crossfire] Improved/redone client. In-Reply-To: <20061009205740.46e55414.raphael@gimp.org> References: <452A040C.20105@sonic.net> <20061009205740.46e55414.raphael@gimp.org> Message-ID: <45333694.4030105@sonic.net> > Here is a screenshot of my gcfclient2, with some comments about where > some space optimizations could be implemented: > http://wilber.gimp.org/~raphael/crossfire/gcfclient-ui.png I don't think I ever responded to this. But one of your points is that the look/inventory icons are too big. You can already control this - -iconscale command line option, or there is also a space for them in the config windows. Set it to 50, and they are now half the size. Now it may be reasonable to make the default value something other than 100 (maybe 50?) Simply because when the tiles were increased from 24 to 32 pixels a while back, that obviously decreases density. From mwedel at sonic.net Mon Oct 16 02:52:15 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 16 Oct 2006 00:52:15 -0700 Subject: [crossfire] Improved/redone client. In-Reply-To: <452C2328.6050705@telus.net> References: <452A040C.20105@sonic.net> <200610102329.09390.nicolas.weeger@laposte.net> <452C2328.6050705@telus.net> Message-ID: <45333A2F.30806@sonic.net> Alex Schultz wrote: > -Less flexibly, as a gtk2 theme with small changes in logic and hacks to > make popups have custom title bars and stay within the game view (might > involve interesting platform specific code). > > The second would probably be less work, however IMHO more hackish and > more likely to have odd quirks. I'm not sure which I would deem better > overall though. Actually, that isn't an issue. Within gtk/x11, there are several placement methods. There is the general "I don't care where this window pops up", in which case some window managers let the user place it, other window managers decide for the user where it should go. There is the true pop up, which appears beneath the mouse pointer. Right click within a gnome-terminal and you get this. There is the window created by the application (what we've been calling pop ups, but aren't really). The application can set where these windows should appear, and the window manager will put them there. If the window manager doesn't, it is broken, and not something we can concern ourselves with. A basic example of this is the metaserver window within the gtk2 client. It is set to be centered on the parent, and that is where it shows up. We could do other things within gtk, like align on left edge, etc, if we so wanted. That said, these are still windows, so the window manager to still try to manager them (close the window, move them around by hand, etc). But if players start doing that, that is their decision. In fact, I could actually see that be a bonus for some players. The gtk2 client doesn't support splitwindows anymore, I don't think, but if we had an inventory window, being able to drag it of so it isn't on top of the client could be considered a plus. Well, at least for me it could be, given I run dual screens. From mwedel at sonic.net Mon Oct 16 02:59:24 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 16 Oct 2006 00:59:24 -0700 Subject: [crossfire] Improved/redone client. In-Reply-To: <452A040C.20105@sonic.net> References: <452A040C.20105@sonic.net> Message-ID: <45333BDC.6020202@sonic.net> I'm going to try and summarize the 20+ messages here. 19x19 map size: --------------- Didn't get many comments, but a few people expressed desire to be able to set this (either because of very small screens, or very large screens). Now scaling of the images (-mapscale already supports this) could be done to compensate for this, but that doesn't look really great. One thought is to at least set a minimum map size (must be set to 17x17 or something) so that map designers could know that a player can see 8 spaces away from them. Yes, people playing on a 25x25 display have an advantage, but so do those with faster connections, etc. I would also be inclined to require on display dimensions, so that the player is always in the center of the screen, not off by a tile. making client fullscreen: ------------------------- General consensus seems to be no on this point. I don't think I saw anyone that actually said they would use full screen, and to me, that is a red flag right there (if no developer is using it, no one will find bugs, etc). But more so, I think it is that in a linux environment, people are not expecting full screen apps. Full screen could allow custom widgets, but some dislike expressed on that. And I do think that is a valid point - being able to use GTK2 makes coding a lot simpler/faster. There is a reason that the gtk clients have a lot more features/abilities than the X11 client, which isn't using any widgets and thus has to have the widgets it does have done by hand. standardize on one client (gtk2): --------------------------------- Generally OK, but gtk2 client would need to work better on low resolution displays. At lease some people are still using 1024x768, which has more space issues. My thought might be to make a different glade layout file for lower resolution, which also chooses some other defaults Client ui improvements: ----------------------- - pop up window for inventory handling: Mixed reviews on this one. It could be that some sort of compromise/hybrid be done. My thought: Have a pop up window for in town use, etc, which could present a lot more items or data than currently provided. Within that, allow for some custom filters or favorite items, and have tabs (in the main window) for those, and have those in a smaller inventory area. So while in a dungeon, you can easily get to the items you need (more easily in fact, because they would be the only thing in particular tabs), but in town, can do everything you need to do. The look window would always be active like it is now (but when the popup is in use, maybe have that data replicated in the popup also to make it easier to access stuff) - add theme support: No real issues, as long as the ability to keep default theme is allowed (it would be). My thought is to handle this like firefox and lots of other apps do - you can use the system theme, but it may have various custom themes which could make it appear more 'gamey' - display important info: Figuring out what is important is hard. Generally, it seems that protections and skills (both) is important, general stats less so. Maybe should investigate to see if we could display both of those in one tab. Overall exp displayed should be added to the scrollbar stats window (sp/hp/grace/food), with the scrollbar representing percentage to next level. For exp values, maybe in the 'compact' list, display the last 5 (or X, where X is not a really large number) of skills that have gained exp? Thus, while in the dungeon, you'd see your combat skills in that window, and could track progress, and in town, you'd see your town based skills. Range attack is also listed as an important to know item. Also suggested that within the protections themselves, that maybe they go red/green for some amount of time when they change, making it easier to see when a spell expires. Could be used for all values that change. Text messages are always an issue. Other than the space used, I don't think the way the gtk2 client does it now is bad. I'm not sure that writing them over the map area would be useful - crossfire generates so many text messages, I think you'd always be bringing up the console to see what you missed, so having the console (text area) always up probably makes more sense. - improved help - should be done, now to just do it. - Improved key binding - should removed duplicate keybindings (or present warning). Also, should have some method of different key binding profiles, so you could load up the mage vs fighter profile (or maybe the dungeon vs town profile). If loading different keybindings can be done by a keybinding itself, this would be doable. In addition, more data on how the keybindings work should be added. - background music should be added. - Better magic map handling (colored dots like cf+?) I had also thought that instead of sending colors, maybe magic map should just send the actual face info for that space (uses more bandwidth, but could be used to fill in the map) - quick item/spell bar - click on item (or spell icon) and it activates. Doable, a bit more work as different items have different ways of being used (spell vs item mostly, but if you click on that staff, does that mean it should fire the staff, or just ready it?) - less text, more icons: A lot of stuff in the stats pane (protections, skills) is displayed with text strings. Using icons could be another way to pack more into the limited space (having a 16x16 icon representing 1 handed weapons woudl take like 10% of the space of 'one handed weapons'). Tooltips could be used to give more detailed information (hover over the icon and you get the skill name and anything else it knows about it). It would perhaps take some training to get use to the icons, but just a thought. From nicolas.weeger at laposte.net Sat Oct 21 13:01:29 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 21 Oct 2006 20:01:29 +0200 Subject: [crossfire] Client-side scripting In-Reply-To: <4532FA35.4030203@telus.net> References: <200608261927.52478.nicolas.weeger@laposte.net> <200610152211.07436.kbulgrien@worldnet.att.net> <4532FA35.4030203@telus.net> Message-ID: <200610212001.29090.nicolas.weeger@laposte.net> Le Lundi 16 Octobre 2006 05:19, Alex Schultz a ?crit?: > Kevin R. Bulgrien wrote: > > LOL,,, see my post of a few minutes ago under client improvements. > > > > Man, another dependency... ;-) Never heard of lua before. > > Well, I was under the impression that Ryo was planning on putting the > lua source base bundled with the client source. It's rather small, and > to my understanding that's normal practice for many things that use lua. I hadn't really thought about that, but sure, I could include it. Also, I had planned to make LUA an option to activate (or autodetect, but i'd need an autoconf/automake wizard level 50+ to help me, i'm only level 3 ^_-), so you wouldn't require it. So, anyone objects to committing? Nicolas From alex_sch at telus.net Sat Oct 21 13:30:58 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 21 Oct 2006 12:30:58 -0600 Subject: [crossfire] Client-side scripting In-Reply-To: <200610212001.29090.nicolas.weeger@laposte.net> References: <200608261927.52478.nicolas.weeger@laposte.net> <200610152211.07436.kbulgrien@worldnet.att.net> <4532FA35.4030203@telus.net> <200610212001.29090.nicolas.weeger@laposte.net> Message-ID: <453A6762.4030501@telus.net> Nicolas Weeger (Laposte) wrote: > Also, I had planned to make LUA an option to activate (or autodetect, but i'd > need an autoconf/automake wizard level 50+ to help me, i'm only level 3 ^_-), > so you wouldn't require it. > Recently I've been leveling at autoconf/automake skill, not sure if I'm over level 50 yet, but I might be of some assistance ;) Alex Schultz From nicolas.weeger at laposte.net Sun Oct 22 06:21:53 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 22 Oct 2006 13:21:53 +0200 Subject: [crossfire] About a bug (or feature?) Message-ID: <200610221321.53175.nicolas.weeger@laposte.net> Hello. On tracker there's a bug about bombs and shops, at https://sourceforge.net/tracker/index.php?func=detail&aid=1571556&group_id=13833&atid=113833 Basically, a player can with bombs destroy unpaid items in shops (even in non magic areas). Now the question is whether this is something we want to allow or not. Personnally I'd say we keep the behaviour as is, letting players destroy stuff if they want :) Nicolas From nicolas.weeger at laposte.net Sun Oct 22 12:11:14 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 22 Oct 2006 19:11:14 +0200 Subject: [crossfire] Player file corruption Message-ID: <200610221911.14981.nicolas.weeger@laposte.net> Hello. I'm tracking the bug https://sourceforge.net/tracker/index.php?func=detail&aid=1569017&group_id=13833&atid=113833 It's due to spell's last_sp/last_grace/last_eat being used in socket code for client-side spell list updating. Unfortunately last_grace is used in healing spell code to denote grace regeneration, so it's messy. Ragnor pointed on IRC that this means player files are now corrupted, at least their healing spells (any spell having the heal type). Fixing code should be easy, but fixing players will probably require a script to strip the last_grace/last_sp/last_eat fields from players's spells. Another messy option is to reset at loading fields, but i'm not that eager to do that, as it's a ponctual fix... Opinions? Nicolas From subs at eracc.com Sun Oct 22 14:33:48 2006 From: subs at eracc.com (ERACC Subscriptions) Date: Sun, 22 Oct 2006 14:33:48 -0500 Subject: [crossfire] Dragon player face Message-ID: <200610221433.49334.subs@eracc.com> Hi all, did someone mess with the dragon player face changes? Make them not change like they used to? My dragon, poof, is green with a blue vest (legendary electricity dragon). No one else with newer dragons seems to get that. Some of the players on metalforge think my dragon looks "cool" and want that face. If the face changes have been removed or changed from the old behavior that gave my dragon his face please put it back the way it was. Gene Alexander -- ERA Computers & Consulting We can provide you with VoIP phone service for your home and/or business. Our VoIP phone service has FREE long distance in the USA and Canada! Contact us! Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From fuchs.andy at gmail.com Sun Oct 22 15:37:24 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun, 22 Oct 2006 16:37:24 -0400 Subject: [crossfire] About a bug (or feature?) In-Reply-To: <200610221321.53175.nicolas.weeger@laposte.net> References: <200610221321.53175.nicolas.weeger@laposte.net> Message-ID: On 10/22/06, Nicolas Weeger (Laposte) wrote: ... > On tracker there's a bug about bombs and shops, at > https://sourceforge.net/tracker/index.php?func=detail&aid=1571556&group_id=13833&atid=113833 > > Basically, a player can with bombs destroy unpaid items in shops (even in non > magic areas). Ive seen this done a few times. > Now the question is whether this is something we want to allow or not. ... > Personnally I'd say we keep the behaviour as is, letting players destroy stuff > if they want :) I would say the same, except that it becomes very irritating when you can't buy something because the shop is blown up every time it resets. -- Andrew Fuchs From mwedel at sonic.net Sun Oct 22 22:58:32 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 22 Oct 2006 20:58:32 -0700 Subject: [crossfire] About a bug (or feature?) In-Reply-To: <200610221321.53175.nicolas.weeger@laposte.net> References: <200610221321.53175.nicolas.weeger@laposte.net> Message-ID: <453C3DE8.3000904@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > > > On tracker there's a bug about bombs and shops, at > https://sourceforge.net/tracker/index.php?func=detail&aid=1571556&group_id=13833&atid=113833 > > Basically, a player can with bombs destroy unpaid items in shops (even in non > magic areas). > > Now the question is whether this is something we want to allow or not. > > > Personnally I'd say we keep the behaviour as is, letting players destroy stuff > if they want :) It's a tough call. One one side, as time passes, various things get removed from the game as they are called abusive or unbalanced. But we have to look at how abusive they are/how big a problem they are, as at some point, it starts becoming 'this is the only way you can play the game', which can diminish the fun for a player. However, the problem in this particular case is as Andrew describes - a few (single) abusive player can continually destroy shop contents, which diminishes the fun for others. I'd personally be inclined to say that bombs should not detonate on no magic spaces (or if we believe they should blow up on no magic, then perhaps they don't blow up on shop spaces, but that is a costlier check) to prevent this. I suppose the teleporters could be changed to strip those objects out, but that seems a little odd to me (but perhaps no more odd than money being taken from you when you buy stuff). > > > Nicolas > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From ben at ancilla.ca Sun Oct 22 22:43:10 2006 From: ben at ancilla.ca (Ben Kelly) Date: Sun, 22 Oct 2006 23:43:10 -0400 Subject: [crossfire] Improved/redone client. In-Reply-To: <452A040C.20105@sonic.net> References: <452A040C.20105@sonic.net> Message-ID: <453C3A4E.1020002@ancilla.ca> Mark Wedel wrote: > Standardize on 19x19 map size. If the interface is also changed to be more of an overlay, this could work, but with the current UI...at 1280x960, 19x19 leaves very little room for the rest of the interface. > Make client fullscreen. > > Reasoning here is that most games run in fullscreen mode, so it becomes more > like most games. It can also ensure that other applications are not grabbing > keystrokes/button presses (eg, window manager, etc), so if we tell the player to > press a key, we can know for sure that if the player presses that key, the > client gets it. For lots of reasons, would still need to support a windowed > mode of operation. > > My thoughts: I personally find fullscreen applications annoying, so would also > use the window mode (I think most people using unix don't expect full screen > apps). While we can run fullscreen, I don't think we can or should attempt to > switch resolution. This does then mean that client could be asked to run at odd > dimensions. I think this issue needs to be investigated further - it may be > possible to make the pointer captive in a non full screen window. I also think > that if we do full screen window, it needs to be pretty clear how to get out of > it (nothing more annoying than an app taking over your system) A fullscreen/windowed option seems reasonable. Perhaps also a grab mouse/free mouse toggle? > Standardize on one client > > Doesn't make sense to be supporting 3 clients in the current client distribution > alone, plus a few others hanging around out there. This is just more work when > [...] > exist in the 1.x branch). Related to this, SDL mode in gtk2 client should > probably just go away (opengl will give us the features we need long term) On SDL/OpenGL: I have to disagree. SDL does the job well and has ports on almost everything. OpenGL may do it better (hardware scaling go!), but SDL should at least be available as a fallback on systems where OGL is unavailable or doesn't work properly. > My thoughts: As the writer and user of the gtk2 client, I'm biased, but keeping > the gtk2 clients seems fine to me. I know there are complaints about it, as > [...] > wouldn't have to update it, just like the unofficial clients out there now) The problem here is settling on a client that satisfies everyone. I'll be clinging to the X11 client until you pry it from my cold, dead finger-analogues - it's noticeably more responsive than the GTK2 one, and on windows (built with Cygwin, for those interested) it's much more stable, too. One of my friends feels the same way about the GTK2 client and can't live without his tabbed inventory pane. Etc. > > == > Improve client UI > > This is often discussed, but I hear few concrete suggestions. > > I'll be the first to admit I'm not wholly satisfied with the gtk2 client. Yet > at the same time, I'm not exactly sure what I'd change to make it better. > > Here are various thoughts and some suggestions I think people presented: > - Pop up window for inventory handling (one gets so many items in crossfire, > that the normal scrolled area really isn't sufficient) Having a scrollable inventory always present like that can be very useful given CF's realtime nature. At least, so long as you keep it organized (or use the GTK client's tabs?) so that you can quickly find that potion of fire resistance before the dragon catches up to you. Perhaps have two flavours? A roll-out scrollable side pane a la classic CF, and a larger popup that shows you everything at once, more suitable for when you aren't in a hurry? > - Maybe use themes to make the appearance more that of a game and less that of > an application (font size, background colors, etc) As long as there's a "classic X11 client" skin :) > - Improved help - I don't think the help in the client has much useful content - > I think a lot of the information currently in various places could make it to > the client so it has a real help system. Seconded. The in-game help is a lot better than nothing, but has some serious gaps. - Ben From mwedel at sonic.net Mon Oct 23 01:32:52 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 22 Oct 2006 23:32:52 -0700 Subject: [crossfire] character image size Message-ID: <453C6214.3090809@sonic.net> Recently on irc, there was a discussion about map size. One point raised in favor of very limited (11x11, 13x13) map size is that in larger maps, there ends up being so much data, the player can get lost in it. While I don't agree with having a small map size (which is a separate discussion), I do agree that the player can often get lost on the map. So I did a quick test. Using gimp, I took the warrior image, scaled it up 50%, used autocrop to eliminate the blank pixels around the image, and then centered it with a normal 32 pixel wide image. After the scaling phase, the images ranged from 28 to 33 pixels wide IIRC. The final size of the images where 32x40 ?2. I find that after this scaling, the player character is much mor noticable, as shown in the attached images. Scaling up 50% may be a little large (and for same races/classes, just may not be possible as it makes them too wide), but it would seem that increasing the size to eliminate most of the transparent pixels around the image may be good. Doing the math, it would seem that for the warrior at least, the actual solid bits are around 21x26. Even keeping the character within the 32x32 cell, that is still about a 25% increase that could be done. Other than making the character more visible, at least for things like equipment, it seems to help the scale some. Now the character is larger than a shield. The size of armor almost looks reasonable, etc. Yes, it does through the player image size off to other things (the armorer looks like a munchkin), but I think that will have to be the case if the idea is to make the player more visible (if the monsters get scaled up, then the player gets lost in the monsters). Thoughts? This is more just a random observation I thought I'd share than any definite proposal. -------------- next part -------------- A non-text attachment was scrubbed... Name: big.png Type: image/png Size: 54214 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20061022/e7ad35cc/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: small.png Type: image/png Size: 54784 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20061022/e7ad35cc/attachment-0003.png From tchize at myrealbox.com Mon Oct 23 06:44:26 2006 From: tchize at myrealbox.com (Tchize) Date: Mon, 23 Oct 2006 13:44:26 +0200 Subject: [crossfire] About a bug (or feature?) In-Reply-To: <453C3DE8.3000904@sonic.net> References: <200610221321.53175.nicolas.weeger@laposte.net> <453C3DE8.3000904@sonic.net> Message-ID: <453CAB1A.40201@myrealbox.com> Just put a weapon alarm on shop that detects bombs. I player try to enter with a bomb, he will be refused, and bomb will explode outside. Other solution: let the DMs handle this on the case by case basis. Some servers might want to make this kind of terrorism illegal ^ ^. But illegal does not mean impossible. Btw, a bomb exploding in a player's inventory should make lot's of damage to player :D (a real kamikaze) regards Mark Wedel a ?crit : > Nicolas Weeger (Laposte) wrote: > >> Hello. >> >> >> On tracker there's a bug about bombs and shops, at >> https://sourceforge.net/tracker/index.php?func=detail&aid=1571556&group_id=13833&atid=113833 >> >> Basically, a player can with bombs destroy unpaid items in shops (even in non >> magic areas). >> >> Now the question is whether this is something we want to allow or not. >> >> >> Personnally I'd say we keep the behaviour as is, letting players destroy stuff >> if they want :) >> > > It's a tough call. One one side, as time passes, various things get removed > from the game as they are called abusive or unbalanced. But we have to look at > how abusive they are/how big a problem they are, as at some point, it starts > becoming 'this is the only way you can play the game', which can diminish the > fun for a player. > > However, the problem in this particular case is as Andrew describes - a few > (single) abusive player can continually destroy shop contents, which diminishes > the fun for others. > > I'd personally be inclined to say that bombs should not detonate on no magic > spaces (or if we believe they should blow up on no magic, then perhaps they > don't blow up on shop spaces, but that is a costlier check) to prevent this. I > suppose the teleporters could be changed to strip those objects out, but that > seems a little odd to me (but perhaps no more odd than money being taken from > you when you buy stuff). > > > >> Nicolas >> >> _______________________________________________ >> crossfire mailing list >> crossfire at metalforge.org >> http://mailman.metalforge.org/mailman/listinfo/crossfire >> > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From subs at eracc.com Mon Oct 23 09:59:52 2006 From: subs at eracc.com (ERACC Subscriptions) Date: Mon, 23 Oct 2006 09:59:52 -0500 Subject: [crossfire] character image size In-Reply-To: <453C6214.3090809@sonic.net> References: <453C6214.3090809@sonic.net> Message-ID: <200610230959.53115.subs@eracc.com> On Monday 23 October 2006 01:32 am Mark Wedel wrote: [...] > So I did a quick test. Using gimp, I took the warrior image, scaled it up > 50%, used autocrop to eliminate the blank pixels around the image, and then > centered it with a normal 32 pixel wide image. [...] > Yes, it does through the player image size off to other things (the > armorer looks like a munchkin), but I think that will have to be the case > if the idea is to make the player more visible (if the monsters get scaled > up, then the player gets lost in the monsters). > > Thoughts? This is more just a random observation I thought I'd share > than any definite proposal. OOOoooo! I like the larger player graphic. Do dragons too please! :-) Also, there was discussion at one time to make a player using invisibility granting items (God Finger, etc.) able to find him/herself more easily on screen. IOW, make them appear "see-through ghostly" on the screen instead of totally transparent from the player's point of view. Has anything ever been attempted to "fix" this? Gene Alexander -- ERA Computers & Consulting We can provide you with VoIP phone service for your home and/or business. Our VoIP phone service has FREE long distance in the USA and Canada! Contact us! Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From kbulgrien at att.net Mon Oct 23 23:43:45 2006 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Mon, 23 Oct 2006 23:43:45 -0500 Subject: [crossfire] character image size References: <453C6214.3090809@sonic.net> Message-ID: The enlargement of the player is a significant artistic improvement as far as I am concerned... even apart from map view changes. I guess it is odd to have the NPC humans so small in comparison. As far as I am concerned, I'm not too worried about map size making a character get lost however, so for me, a change to player rendering would really be strictly for one's viewing pleasure. This player would look HUGE upside some of those minute human arches that look hardly the size of a kobold. How bad is that? Shrug. But that perspective change to the items is very cool. Kevin From toxicfrog at funkyhorror.net Tue Oct 24 00:26:14 2006 From: toxicfrog at funkyhorror.net (ToxicFrog) Date: Tue, 24 Oct 2006 01:26:14 -0400 Subject: [crossfire] Unidentified scrolls/wands have value 0 -> autopickup problems Message-ID: <453DA3F6.5090505@funkyhorror.net> When unidentified, scrolls, wands and staves (haven't tested rods yet) have a value of 0 - they are "worth nothing" and shops won't pay you anything for them. This seems kind of odd, but presumably there's a good reason for this change. However, it also affects the 'pickup command. Specifically, 'pickup 10 is supposedly the "magic density" that picks up all coins, gems, wands, staves, rods, scrolls, spellbooks, potions, etc...but since scrolls and wands appear to have a value of 0, they don't get automatically picked up and easily missed. Oddly, non-magical scrolls are still valuable even when not identified and will be automatically grabbed by 'pickup 10, which makes the seeming worthlessness of scrolls that are known to be magical (but not what kind of magic) even more peculiar. - TF From alex_sch at telus.net Tue Oct 24 08:39:07 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 24 Oct 2006 07:39:07 -0600 Subject: [crossfire] IRC traffic for Sunday Oct 22 Message-ID: <453E177B.2020001@telus.net> Hi all, Well, on Sunday alot was said on many many crossfire issues. Here's a summary of what was discussed for anyone interested. I'm hoping we can come up with some solid plans on some issues :) When replying, please only reply to one issue at a time, and change the subject line to account for what you are replying about :) Alex Schultz Lack of popularity: -No advertisement being a large reason -Google ads (Ryo_) (was the joking or not? :P) -Slashdot article for 2.0 (Rednaxela) -For 2.0 alpha/beta, like freeciv. Good for testing (cavehippo) -Should have a stable enough test server for 2.0 alpha/beta -Need to ignore trolls -UI nitpicks -Gameplay nitpicks -Don't want to go so far it bogs down servers. -Hopefully means more devs and content (map, image, etc) makers. -Improving Gridarta Gridarta Ideas: -Better 'connection' (i.e. buttons and gates) interface. Perhaps even give the server new object types for boolean logic, and give Gridarta a flow-chart-like interface to that. -NPC dialog editor -Understand @match syntax and the subset of regexp syntax -Warn users when they are doing 'the wrong thing', as in putting object on the map or in inventories that should never go there. -Daiminion already does this. Code just need to merge this code and make crossfire-specific rules for it. -Perhaps warn about connected object in inventories, because that doesn't work and could confuse map-makers. -"but I think more importantly, it should be possible to create a crappy 'my first map' in 10 minutes or less" - Cavehippo UI Ideas: -hp bars on player/monster images (darkschneider) Graphics: -Symbolic value lacking in some cases -Good symbolism means "recognizable at first glance" -Consistancy lacking it many cases -Larger? Hanuk: -Is he too easy to get too for how deadly he is? -Is he too deadly? -Are the warnings enough -Do players heed warnings enough? Why/Why not? Death penalties: -One of the things that bugs players the most -Remove them? -A "limbo" map? -a choice between certain penalties? -Could make them more "tangible" Map design: -Are maps designed badly so players can die too suddenly? -Proposed standard view size -Is it needed? Perhaps LOS should always limit seen distance instead of a hard map size limit. Why do people spend days leveling a skill up? -Because it would be useful at a higher level -Should we focus on making it just as fun to play at a low-level -Spell rebalancing and adding new spells as one specific case -"We played around in the arena a while ago: most spells are useless because nothing hurts a player. Or you use meteor swarm or banishment which kills instantly." --Ragnor From mwedel at sonic.net Wed Oct 25 02:26:43 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 25 Oct 2006 00:26:43 -0700 Subject: [crossfire] Graphics, was Re: IRC traffic for Sunday Oct 22 In-Reply-To: <453E177B.2020001@telus.net> References: <453E177B.2020001@telus.net> Message-ID: <453F11B3.8030709@sonic.net> Alex Schultz wrote: > Graphics: > -Symbolic value lacking in some cases > -Good symbolism means "recognizable at first glance" I'd think that those could be cleaned up as identified. > -Consistancy lacking it many cases That also needs to be cleaned up. I'd say that images should be consistent within the class of images themselves. For example, items you pick up would be one class, ground would be another class, etc. > -Larger? That should probably get sorted out sooner vs later, as it has lots of other effects. Going to larger images has a pretty direct impact on viewable map size. Making such a change is a huge amount of work. Choosing a large size could be seen as some advantage, as resizing smaller will generally yield good quality where as the reverse won't. That is to say, if the images are 64x64, some people in order to get the map size they want will scale the images down to 40x40. That will appear better than image the images are 32x32 and for some people, they get scaled up to 64x64. Disadvantage is more bandwidth to download them (but maybe not a huge amount, as I imagine on the 32x32 images, there is a fair amount of overhead for the png header itself?) As an aside, the server does support multiple image sets, so in theory, one could make a 'big' image set. The problem is that the client would have to know that these are bigger images (and not just big images), which would probably require extending the protocol some, but probably not much. Other thoughts: - As per other e-mail I sent out, should player images be made larger to be more visible? - There are still a fair number of images that were never resized properly - several of the shops appear 'small' because they are - only 48x48 (centered in a 64x64 tile). IIRC, this was done in the xpm->png conversion - scaling up the images was disliked because of bad results, so instead the same size was kept, with I believe the hope that they would eventually get scaled up and touched up. That might have been more likely to happen if the images had been scaled up - then they look ugly, and someone takes the task to do the touch up. - IMO, more multi tile images, and greater use of them could be nice. There will always be the problem with scale, so long as the player is a single tile and most of the images they deal with are single tiles. If you had a prety hard rule that all buildings must be at least 2x2 to better suggest scale, that helps things out (but is major map redesign work). But another case could just be terrain. Multi tile hill images, and more/bigger multitile mountains could add a bit more flavor/variety to the game. From mwedel at sonic.net Wed Oct 25 02:31:20 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 25 Oct 2006 00:31:20 -0700 Subject: [crossfire] UI changes, was Re: IRC traffic for Sunday Oct 22 In-Reply-To: <453E177B.2020001@telus.net> References: <453E177B.2020001@telus.net> Message-ID: <453F12C8.8070601@sonic.net> Alex Schultz wrote: > UI Ideas: > -hp bars on player/monster images (darkschneider) I've played some commercial games that does this - this is nice in some regards. But within crossfire, has some more issues. I think it is sort of interesting not knowing how close you are to killing creatures. First, I think on maps with lots of single tile monsters (which lots of crossfire maps have), this could create a lot of clutter. I'd presume that an bars must be a total percentage and not absolute value. If absolute value, the problem is that the high value is 5000+ HP. So at low levels, you wouldn't see anything in the bar, as monster HP are less than 50. But if a percentage, the problem is that for tougher monsters, the bar could appear not to change much, given they have so many hp From mwedel at sonic.net Wed Oct 25 02:42:20 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 25 Oct 2006 00:42:20 -0700 Subject: [crossfire] Death Penalty, was Re: IRC traffic for Sunday Oct 22 In-Reply-To: <453E177B.2020001@telus.net> References: <453E177B.2020001@telus.net> Message-ID: <453F155C.5020705@sonic.net> Alex Schultz wrote: > Death penalties: > -One of the things that bugs players the most I wonder if this is somewhat tied to some of the other points raised elsewhere, where players can die very easily. I have a feeling that if you had to be really stupid to die (have a low level character wander into a high level dungeon), deaths would be less common, and thus the death penalty wouldn't be so much an issue. > -Remove them? > -A "limbo" map? > -a choice between certain penalties? > -Could make them more "tangible" There are already a fair number of values in the settings file that could control this. I image if you set the death_penalty_percentage to 0, you wouldn't lose exp. I don't see any option to remove the depletion on death, but that would be an easy change to make. I'm not sure what the limbo map gets us. A choice between death penalties is interesting. But then you have to ask what the penalties are. Obvious choices: - exp loss - stat loss - monetary loss - time loss (character/player has to sit a while?) - other? The problem I think is that this is almost the same thing as removing the death penalty - a player at any decent level is going to choose the penalty that doesn't hurt. Eg, at relatively modest level, you can get potions of life, so the stat depletion isn't a big deal (if we change it to actual stat loss, that could be more a deal). If it means the character can't be played for half an hour or something, it means you grab dinner or a snack, or play a different character. The monetary one could be a way to remove money from the game. I do think the losses have to be tied somehow together, something like: 10000 exp = 10000 platinum = 1 stat point type of thing. Time loss should probably be fixed no matter what the loss. From mwedel at sonic.net Wed Oct 25 03:04:08 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 25 Oct 2006 01:04:08 -0700 Subject: [crossfire] Map Design, was Re: IRC traffic for Sunday Oct 22 In-Reply-To: <453E177B.2020001@telus.net> References: <453E177B.2020001@telus.net> Message-ID: <453F1A78.3030002@sonic.net> Alex Schultz wrote: > Map design: > -Are maps designed badly so players can die too suddenly? Some maps are. I don't have any specific maps in mind. And some of this is just the general speed of the game - the fact that a combat takes less than 5 seconds means that death can happen very quickly. The general case of problem maps are those in which you enter already in danger, and don't have a good clue on how dangerous it is before going down the exit. In some cases, in fact, I do a double apply - apply the exit to the map, and immediately hit apply again, so I can quickly see the layout of the map and what is on it and come up with a game plan. But the specific problems are maps you enter, get assaulted by monsters, and are pretty much dead immediately. I don't have a problem with maps that have monsters by the entrance if the difficulty progression is there (for example, if you just had to kill a dragon to get to the exit leading to the map, having an dragon by the entrance wouldn't be unheard of). But many maps have creatures that are much more difficult (or a completely different type, so you may be prepared for a dragon and get a titan) type of thing. > -Proposed standard view size > -Is it needed? Perhaps LOS should always limit seen distance > instead of > a hard map size limit. For indoor maps, that is often the case. But it also depends on what the hypothetical target is. I'd say there are not a lot of maps where a 25x25 map will see much more than a 19x19 map (but there are some that do have large open areas). But I'd say there are probably a lot of maps where 19x19 will see quite a bit more than 13x13. 13x13 means you are seeing 6 spaces way from you - even twisty dungeon maps often have straight passages here and there that are longer than 6 spaces. I would say that pretty much every underground map should use darkness code, which does limit visibility quite a bit. However, the player still has an advantage here - shoot an burning hands (or other flame spell) in some direction - that illuminates the area and also kills anything that is there. And I'd say that if things are done so that LOS makes it so that you never see beyond 9 spaces (thus, 19x19), you may as just make that the official map size. I recall the real issue here was what advantage do different players get for different sized maps. At the most basic level, I'd say let players use whatever map size they want. If they decide to play on an 11x11 map, they are making the choice to disadvantage themselves. The problem there, of course, is if some map has some visual clue that is 8 spaces away (pulling a handle operates that gate, etc) that you don't see on an 11x11 map but would on a 17x17 map. (as an aside, there is no way to prevent players from using small maps if they want, because they can always modify the client to show whatever size they want) So the issue really comes to mapmakers. If they want to hide something from the players, they should probably do it via LOS and not by distance (put the lever behind a bend in the wall, etc). But to be honest, I can't recall many issues where this comes up. The few cases where this does sometime come up isn't related to gameplay, but just visual continuity. Some maps have 'views' of the surround area (I'm think the comet quest, where when at the top level, you see the surrounding area). In many cases, those were designed for 11x11 mapview, so if you have a view larger than that, it doesn't look right. But that is in some sense easy to fix - if those are adjusted for 25x25 view, they would never be incorrect. One random musing in this: Dungeons maps are generally limited in size per level for various reasons (performance and monster creation being the main ones), with things like exits/stairs from one level to the next. It'd perhaps be interesting to make a rambling dungeon with map tiling, with monsters getting tougher the deeper you go in. Wonder if the random map code could be changed to make such maps. This would fix the problem you don't know what is about to kill you when you go down an exit - you'd always have a chance to see the monsters at some distance in such a tiled dungeon. From lalo.martins at gmail.com Wed Oct 25 09:15:35 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Wed, 25 Oct 2006 22:15:35 +0800 Subject: [crossfire] Death Penalty, was Re: IRC traffic for Sunday Oct 22 References: <453E177B.2020001@telus.net> <453F155C.5020705@sonic.net> Message-ID: On Wed, 25 Oct 2006 00:42:20 -0700, Mark Wedel wrote: > I'm not sure what the limbo map gets us. I just tossed that around as a possible mechanism to pick your choice of penalty. You could be moved to Limbo, where you can choose between the options you list below by stepping on different exits, or somesuch -- similar to the current Halls of Selection. > A choice between death penalties is interesting. But then you have to > ask what the penalties are. Obvious choices: > - exp loss > - stat loss > - monetary loss > - time loss (character/player has to sit a while?) > - other? I think monetary as in money proper is probably too cheap (and you probably won't be carrying enough to pay it); but sacrificing valuable artifacts adds a cool twist. Also, exp itself can be broken down; "step here to lose X points on your currently active skill" (so you ready_skill then go) in one place, and in another the current "step here to lose Y% exp on all your skills" (where X would have to be larger than Y% of course). I like stat loss, of course; but high-level players have piles of stat potions, so maybe that's only accepted up to a certain level? (Or in practise, it "costs" more and more stat points according to your overall exp, so that it always "hurts" sufficiently) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From brenlally at gmail.com Wed Oct 25 12:32:32 2006 From: brenlally at gmail.com (Brendan Lally) Date: Wed, 25 Oct 2006 18:32:32 +0100 Subject: [crossfire] Death Penalty, was Re: IRC traffic for Sunday Oct 22 In-Reply-To: References: <453E177B.2020001@telus.net> <453F155C.5020705@sonic.net> Message-ID: <200610251832.32777.brenlally@gmail.com> On Wednesday 25 October 2006 15:15, Lalo Martins wrote: > > I think monetary as in money proper is probably too cheap (and you > probably won't be carrying enough to pay it); but sacrificing valuable > artifacts adds a cool twist. That's why I suggested 'life insurance' (really 'death insurance' I guess) so that a player could pay an amount of money in advance to reduce the effect of the death penalty if a player dies during the span of the insurance policy. Probably that would have to be capped to a certain point (95% or so maybe) so that dying is still disadvantageous, then you would have cost being something like (% of death penalty to offset (1-95))^2*(hours for policy to last)^2*(level of player)^2*some scaling factor that is considered to make the costs sensible. This would mean that a player wanting to keep their death penalty low for a long period of time would have to pay a great deal of money, and anyone who happened to die when their insurance lapsed would have only themselves to blame for taking the full death penalty. From mwedel at sonic.net Thu Oct 26 01:51:49 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 25 Oct 2006 23:51:49 -0700 Subject: [crossfire] Death Penalty, was Re: IRC traffic for Sunday Oct 22 In-Reply-To: References: <453E177B.2020001@telus.net> <453F155C.5020705@sonic.net> Message-ID: <45405B05.7070203@sonic.net> Lalo Martins wrote: > On Wed, 25 Oct 2006 00:42:20 -0700, Mark Wedel wrote: >> I'm not sure what the limbo map gets us. > > I just tossed that around as a possible mechanism to pick your choice of > penalty. You could be moved to Limbo, where you can choose between the > options you list below by stepping on different exits, or somesuch -- > similar to the current Halls of Selection. Note that for any limbo map, they player would have to appear in an area controlled by gates. EG, if I'm attacking something, I'm running in some direction - if I die, I don't want to accidentally run into something that makes my choice. I know that maps are the easiest way to do things, but IMO, we should really go to the extra step and just have some menu that pops up asking the player what to do. This also has some advantage in that you could even provide some mix and match. Eg, I don't want to lose 10%, nor do I want to lose 4 stat points. But 5% and 2 stat points would be OK. Also, I think it this can provide better information. Having a pad that says 'step here and lose 10% exp' is so so - I'd much rather have a window which shows exactly how much exp that means, how many level(s) that affects, etc. I think we should learn from the hallofselection - a good method, but providing actual menus provides a better experience for the player. > >> A choice between death penalties is interesting. But then you have to >> ask what the penalties are. Obvious choices: >> - exp loss >> - stat loss >> - monetary loss >> - time loss (character/player has to sit a while?) >> - other? > > I think monetary as in money proper is probably too cheap (and you > probably won't be carrying enough to pay it); but sacrificing valuable > artifacts adds a cool twist. My thought for monetary, if chosen, is that that some invisible force gets added to the player that has incredibly severe penalties (-10 to various stats, etc), and that force is removed when the player pays off the cost. Maybe in the form of donation on an altar (repenting to your god?) Something similar could be done for artifact sacrifice (player may not be carrying it, so put in some force). Money may be cheap, OTOH, if the cost is really high, players may end up not having so much money (keep paying off those deaths costs could add up). and if the goal is to reduce the death penalty, making it money is one of the ways to do it. > I like stat loss, of course; but high-level players have piles of stat > potions, so maybe that's only accepted up to a certain level? (Or in > practise, it "costs" more and more stat points according to your overall > exp, so that it always "hurts" sufficiently) As things are now, at high levels, most likely only exp loss would be painful, as that is the only thing you can't really buy back. there had been discussions about changing the way stats work (make stats 1-100, make stat potions of some chance of increasing a stat, etc). If that was done, such that it was pretty much impossible to get 100 stats, then players wouldn't have stat potions about (they'd always use them), so stat loss actually would be painful. From alex_sch at telus.net Thu Oct 26 07:43:14 2006 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 26 Oct 2006 06:43:14 -0600 Subject: [crossfire] Death Penalty, was Re: IRC traffic for Sunday Oct 22 In-Reply-To: <453F155C.5020705@sonic.net> References: <453E177B.2020001@telus.net> <453F155C.5020705@sonic.net> Message-ID: <4540AD62.4070809@telus.net> Mark Wedel wrote: > A choice between death penalties is interesting. But then you have to ask > what the penalties are. Obvious choices: > - exp loss > - stat loss > - monetary loss > - time loss (character/player has to sit a while?) > - other? Another interesting possible choice would be to complete some sort of quest that takes a while to complete and isn't the same every time. Perhaps put in a riddle generator and other little things. It would have the same sort of effect as time loss, only would be less boring for the player. Alex Schultz From mwedel at sonic.net Fri Oct 27 00:47:27 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 26 Oct 2006 22:47:27 -0700 Subject: [crossfire] Death Penalty, was Re: IRC traffic for Sunday Oct 22 In-Reply-To: <4540AD62.4070809@telus.net> References: <453E177B.2020001@telus.net> <453F155C.5020705@sonic.net> <4540AD62.4070809@telus.net> Message-ID: <45419D6F.2090707@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: >> A choice between death penalties is interesting. But then you have to ask >> what the penalties are. Obvious choices: >> - exp loss >> - stat loss >> - monetary loss >> - time loss (character/player has to sit a while?) >> - other? > Another interesting possible choice would be to complete some sort of > quest that takes a while to complete and isn't the same every time. > Perhaps put in a riddle generator and other little things. It would have > the same sort of effect as time loss, only would be less boring for the > player. That could just be annoying, however, if it is actually a requirement. And if it actually gives any benefit to the character (items, exp, whatever), then that becomes less a deterant. Plus, it seems that any maps we can make should be generally available. From alex_sch at telus.net Fri Oct 27 08:51:31 2006 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 27 Oct 2006 07:51:31 -0600 Subject: [crossfire] Death Penalty, was Re: IRC traffic for Sunday Oct 22 In-Reply-To: <45419D6F.2090707@sonic.net> References: <453E177B.2020001@telus.net> <453F155C.5020705@sonic.net> <4540AD62.4070809@telus.net> <45419D6F.2090707@sonic.net> Message-ID: <45420EE3.5020503@telus.net> Mark Wedel wrote: > Alex Schultz wrote: > >> Another interesting possible choice would be to complete some sort of >> quest that takes a while to complete and isn't the same every time. >> Perhaps put in a riddle generator and other little things. It would have >> the same sort of effect as time loss, only would be less boring for the >> player. >> > > That could just be annoying, however, if it is actually a requirement. > > And if it actually gives any benefit to the character (items, exp, whatever), > then that becomes less a deterant. Plus, it seems that any maps we can make > should be generally available. I was thinking of it being not a requirement but an option if there's a choice of things to do. I would agree it wouldn't work so well as a requirement. Also, I'm thinking of having it in the format of something like a largish randomly generated maze, perhaps with a few 0 exp monsters that based on the level it should be able to beat easily regardless of race/etc., with a riddle at the exit, and the option for the player to go back and choose a different option at any time if they feel stuck. I feel this option could be useful to give players another way out when they don't feel they can afford to give up any stats or tons of money, while being a slightly more interesting penalty than a time penalty. Alex Schultz From alex_sch at telus.net Sat Oct 28 13:13:45 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 28 Oct 2006 12:13:45 -0600 Subject: [crossfire] Client-side scripting In-Reply-To: <200608261927.52478.nicolas.weeger@laposte.net> References: <200608261927.52478.nicolas.weeger@laposte.net> Message-ID: <45439DD9.6070908@telus.net> Nicolas Weeger (Laposte) wrote: > Hello. > > I would like to enhance client-side scripting with a LUA engine, and before > potentially applying my changes I'd like to discuss that, and reply to > objections. > Note I don't plan on trashing current scripting system, just on adding > things :) Just a thought, I'm thinking that perhaps the LUA patch should be put in trunk for 2.x but not in 1.x. Also, to me it would make a bit of sense to also remove the current scripting system in 2.x in favor of that provided that the LUA engine can be supported on all platforms and is built-in. While the old scripting system is nice, I would say it is somewhat unintuitive and perhaps not worth keeping in 2.x if the LUA engine is built-in. Alex Schultz From alex_sch at telus.net Sat Oct 28 16:02:23 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 28 Oct 2006 15:02:23 -0600 Subject: [crossfire] 2.0 object-type refactoring Message-ID: <4543C55F.3060605@telus.net> Hi all, For a while now I've been throwing the idea of separating the server's object-type-specific code by object types. Currently things are rather disorganized with code for how an object type works being spread all around the code. I plan to begin to implement the plan on the following wiki page soon if nobody has any objections: /http://wiki.metalforge.net/doku.php/dev_todo:refactor/ Also, would be nice for some others to help a bit once it's started :) Alex Schultz From alex_sch at telus.net Sun Oct 29 01:21:08 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 29 Oct 2006 00:21:08 -0600 Subject: [crossfire] 2.0 object-type refactoring In-Reply-To: <4543C55F.3060605@telus.net> References: <4543C55F.3060605@telus.net> Message-ID: <45444854.5010502@telus.net> Alex Schultz wrote: > For a while now I've been throwing the idea of separating the server's > object-type-specific code by object types. Currently things are rather > disorganized with code for how an object type works being spread all > around the code. I plan to begin to implement the plan on the following > wiki page soon if nobody has any objections: > /http://wiki.metalforge.net/doku.php/dev_todo:refactor/ > Also, would be nice for some others to help a bit once it's started :) Just a note, since my original mailing list posting, made a small revision to the page/plan based on IRC discussion. http://wiki.metalforge.net/doku.php/dev_todo:refactor?rev=1162054825&do=diff Alex Schultz From nicolas.weeger at laposte.net Sun Oct 29 15:37:16 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 29 Oct 2006 22:37:16 +0100 Subject: [crossfire] Client-side scripting In-Reply-To: <45439DD9.6070908@telus.net> References: <200608261927.52478.nicolas.weeger@laposte.net> <45439DD9.6070908@telus.net> Message-ID: <200610292237.16910.nicolas.weeger@laposte.net> > Just a thought, I'm thinking that perhaps the LUA patch should be put in > trunk for 2.x but not in 1.x. Also, to me it would make a bit of sense > to also remove the current scripting system in 2.x in favor of that > provided that the LUA engine can be supported on all platforms and is > built-in. While the old scripting system is nice, I would say it is > somewhat unintuitive and perhaps not worth keeping in 2.x if the LUA > engine is built-in. Fine for me to put in 2.x (aka trunk) and add a --with-lua configure switch (but I'll need some wizard's help ;p). Removing existing scripting, well, I'm not too eager, I think people are used to it... Nicolas From fuchs.andy at gmail.com Sun Oct 29 16:22:03 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun, 29 Oct 2006 17:22:03 -0500 Subject: [crossfire] Client-side scripting In-Reply-To: <200610292237.16910.nicolas.weeger@laposte.net> References: <200608261927.52478.nicolas.weeger@laposte.net> <45439DD9.6070908@telus.net> <200610292237.16910.nicolas.weeger@laposte.net> Message-ID: On 10/29/06, Nicolas Weeger (Laposte) wrote: ... > Removing existing scripting, well, I'm not too eager, I think people are used > to it... I have a strange feeling that this might evolve into a plugin system. :-/ -- Andrew Fuchs From mwedel at sonic.net Sun Oct 29 23:35:12 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 29 Oct 2006 21:35:12 -0800 Subject: [crossfire] 2.0 object-type refactoring In-Reply-To: <45444854.5010502@telus.net> References: <4543C55F.3060605@telus.net> <45444854.5010502@telus.net> Message-ID: <45458F10.4050303@sonic.net> Few questions: Use form of server/types/foo.c or server/types/foo/bar.c depending on if the object type requires multiple C files to be clean. With the fact that the SVN repository is called server, it is unclear exactly what server refers to. If we include the repository name, is it: server/server/types server/common (example of existing directory) Or server/types common/ (being the exististing directory) IMO, I'd prefer the second form - put the types directory at the top level, relative to the server directory. This is how the socket code is, doesn't have any real disadvantage, but could have some advantages (better for unit tests? Better for stand alone program that does simulations, etc?) Function pointers: It's not specifically mentioned on how the callbacks are registed. I see one of two ways: register_apply_callback(type, funcpointer); or register_callback(type, funcpointer, callback_type) Both have pros and cons. The first case has the advantage that the compiler can do actual type checking on funcpointer. The second has the advantage you don't need as many callback functions, and it makes it easier to add new callbacks (add the new callback_type #define, update the number of callback types, and recompile. One could even do things like: callbacks[ob->type][CALLBACK_TYPE](....) It's also not really mentioned on how the callbacks themselves are registered (that code has to be someplace). And rather than having a single function that registers all the callbacks for all the object types, I'd suggest that each type file has something like init_callbacks_weapons (or something). Then in some other place, you have that function that calls all the init_callbacks - having a function of MAX_TYPES lines longer is much better than one of MAX_TYPES * MAX_CALLBACK_METHODS lines long. The other advantage of this is that the individual types files themselves can then declare all the functions except the init function static, so that it can't be called by other functions. I suppose that one could use various system function calls to try and look up the function names and call them (presuming a standard naming scheme, like init_callbacks_46, where 46 is the type number for that object), but that may be overly complicating things. Other thoughts: It may be better working on getting all of this infrastructure/callback methods in place, and implementing one type of object using them instead of focusing on the specific callback method (the web page mentioned doing all the apply stuff). Why? That way, if someone does write code for a new object type, all the pieces are in place so they can use the new method. If only the apply callback is implemented, they can use that logic, but are left using old coding method for the other areas, that then needs to be converted down the road. Also, by doing all the different callback methods, it provides better coverage of the callback logic, eg, if there are issues with any of the methods, they will be found sooner vs later. Second, if we're going to be writing all new functions, we should use some other 'best practices'. In particular, for anything that would return a string value, they should be modified so that a string pointer (and length of that pointer) is passed in, instead of using static return buffers. This will assist if we ever thread the server, but it will also help prevent a few bugs (related to this, sprintf, strcat, and strcpy should never be used, but rather snprintf, strncat, and strncpy instead) From alex_sch at telus.net Mon Oct 30 00:36:54 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 29 Oct 2006 23:36:54 -0700 Subject: [crossfire] 2.0 object-type refactoring In-Reply-To: <45458F10.4050303@sonic.net> References: <4543C55F.3060605@telus.net> <45444854.5010502@telus.net> <45458F10.4050303@sonic.net> Message-ID: <45459D86.5020106@telus.net> Mark Wedel wrote: > > > IMO, I'd prefer the second form - put the types directory at the top level, > relative to the server directory. This is how the socket code is, doesn't have > any real disadvantage, but could have some advantages (better for unit tests? > Better for stand alone program that does simulations, etc?) > I was originally thinking of as a subdirectory of the server directory as in the first form, but now that I think of it, what you suggest I think is a bit better. > Function pointers: > It's not specifically mentioned on how the callbacks are registed. I see one of > two ways: > > register_apply_callback(type, funcpointer); > > or > > register_callback(type, funcpointer, callback_type) > I'm currently thinking of using the first form, largely so it matches what I plan on using for calling the callback itself. I decided on using ob_apply() ob_drop() instead of my old idea of cf_method(ob, type, ...) primarily due to compiler type checking. > It's also not really mentioned on how the callbacks themselves are registered > (that code has to be someplace). And rather than having a single function that > registers all the callbacks for all the object types, I'd suggest that each type > file has something like init_callbacks_weapons (or something). Then in some > other place, you have that function that calls all the init_callbacks - having a > function of MAX_TYPES lines longer is much better than one of MAX_TYPES * > MAX_CALLBACK_METHODS lines long. > Yes, that makes sense and was my original plan to use such init functions. Good idea with how everything except the init could be static, that is a nice bonus I didn't think of. > > > Other thoughts: > It may be better working on getting all of this infrastructure/callback methods > in place, and implementing one type of object using them instead of focusing on > the specific callback method (the web page mentioned doing all the apply stuff). > Why? That way, if someone does write code for a new object type, all the > pieces are in place so they can use the new method. If only the apply callback > is implemented, they can use that logic, but are left using old coding method > for the other areas, that then needs to be converted down the road. > > Also, by doing all the different callback methods, it provides better coverage > of the callback logic, eg, if there are issues with any of the methods, they > will be found sooner vs later. > Well, my original thinking, was that if I were to do it by completing an object type, instead of a callback type, then it would be somewhat of a pain to make it redirect to legacy methods for other object types not yet implemented in the new system. What's your view on that issue? > Second, if we're going to be writing all new functions, we should use some other > 'best practices'. In particular, for anything that would return a string value, > they should be modified so that a string pointer (and length of that pointer) is > passed in, instead of using static return buffers. This will assist if we ever > thread the server, but it will also help prevent a few bugs (related to this, > sprintf, strcat, and strcpy should never be used, but rather snprintf, strncat, > and strncpy instead) Well, I wouldn't say necessarily writing all new functions: I believe some existing functions can be tweaked fairly easily to fit into the new system. However I believe that when moving functions that map well over, we should hand review them anyways, and perhaps use a checklist of things such as those issues you mention like avoiding static buffer returns. Alex Schultz From mwedel at sonic.net Mon Oct 30 01:59:22 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 29 Oct 2006 23:59:22 -0800 Subject: [crossfire] 2.0 object-type refactoring In-Reply-To: <45459D86.5020106@telus.net> References: <4543C55F.3060605@telus.net> <45444854.5010502@telus.net> <45458F10.4050303@sonic.net> <45459D86.5020106@telus.net> Message-ID: <4545B0DA.30202@sonic.net> Alex Schultz wrote: >> It may be better working on getting all of this infrastructure/callback methods >> in place, and implementing one type of object using them instead of focusing on >> the specific callback method (the web page mentioned doing all the apply stuff). >> Why? That way, if someone does write code for a new object type, all the >> pieces are in place so they can use the new method. If only the apply callback >> is implemented, they can use that logic, but are left using old coding method >> for the other areas, that then needs to be converted down the road. >> >> Also, by doing all the different callback methods, it provides better coverage >> of the callback logic, eg, if there are issues with any of the methods, they >> will be found sooner vs later. >> > Well, my original thinking, was that if I were to do it by completing an > object type, instead of a callback type, then it would be somewhat of a > pain to make it redirect to legacy methods for other object types not > yet implemented in the new system. What's your view on that issue? Some of it depends on how this is done. If you replaced the specific calls to apply, drop, etc as they are sprinkled throughout the code, then doing one type of function is easier. However, what I was thinking is those functions would still exist, but instead of the case statements they have now, they would have something like: if (callback_Exists_for_this_type) do_callback() else { do switch statement} In that model, doing a few types at a time is easier to do. I also think you still want to have common top level/generic functions so that you can have some common code. An example of this (albeit a trivial one) is checking that objects are paid for before doing an apply. Rather than have that duplicated in every object type apply function, you have it in the one generic one that calls the specific ones. A better case here may be something like examine/describe item, where many objects may have some specific/unique properties, but many also have common properties (value, cursed, applied, etc). > >> Second, if we're going to be writing all new functions, we should use some other >> 'best practices'. In particular, for anything that would return a string value, >> they should be modified so that a string pointer (and length of that pointer) is >> passed in, instead of using static return buffers. This will assist if we ever >> thread the server, but it will also help prevent a few bugs (related to this, >> sprintf, strcat, and strcpy should never be used, but rather snprintf, strncat, >> and strncpy instead) > Well, I wouldn't say necessarily writing all new functions: I believe > some existing functions can be tweaked fairly easily to fit into the new > system. However I believe that when moving functions that map well over, > we should hand review them anyways, and perhaps use a checklist of > things such as those issues you mention like avoiding static buffer returns. I think a lot of existing code can be re-used. I'm not sure how many functions can be re-used completely. I suppose the apply code is a reasonable example. For some object types, the logic has been broken apart into its own function. But some object types are still handled within a case statement. In those cases, you'll basically need to write a new function. But this really needs to be thought at the time of callbacks, as you'll need to set up the function pointers to consistent. To be honest, the only case I can think of right now would be the describe/examine object logic. Other thought not related to the above: Given this is a major restructure, would it make sense to collapse/redo some of the types, particularly the equipable equipment? With the change of equipment (body info), for the most part, there is not the need of all the types right now (boots, shield, helmet, etc) Really, the only types (or subtypes) needed are likely: WEAPON - some classes or gods are prohibited from using them so need to know what are weapons and what are not. BOW - like weapon above, but these also fire other objects ARMOR - some classes can't use armor, so need this info. helmets, boots, gloves, shields, etc fall into this. MISC - anything else equipable that is not in the above that conveys adjustments to the players (eg, wands/rods/horns are not here, because they do not provide ac, protections to the player simply by equipping them). But things like rings, amulets, necklaces (some of these don't exist but are being used as examples) would be in this category From alex_sch at telus.net Mon Oct 30 08:16:47 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 30 Oct 2006 07:16:47 -0700 Subject: [crossfire] 2.0 object-type refactoring In-Reply-To: <4545B0DA.30202@sonic.net> References: <4543C55F.3060605@telus.net> <45444854.5010502@telus.net> <45458F10.4050303@sonic.net> <45459D86.5020106@telus.net> <4545B0DA.30202@sonic.net> Message-ID: <4546094F.8070902@telus.net> Mark Wedel wrote: > Alex Schultz wrote: > >> Well, my original thinking, was that if I were to do it by completing an >> object type, instead of a callback type, then it would be somewhat of a >> pain to make it redirect to legacy methods for other object types not >> yet implemented in the new system. What's your view on that issue? >> > > Some of it depends on how this is done. > > If you replaced the specific calls to apply, drop, etc as they are sprinkled > throughout the code, then doing one type of function is easier. > > However, what I was thinking is those functions would still exist, but instead > of the case statements they have now, they would have something like: > > if (callback_Exists_for_this_type) do_callback() > else { do switch statement} > > In that model, doing a few types at a time is easier to do. > > I also think you still want to have common top level/generic functions so that > you can have some common code. > Well, the way I was thinking of doing it, would be to replace specific calls to apply, drop, etc as they are sprinkled throughout the code, and keep common code such as you say, in a "common" subdirectory of the types directory, and then have the callback called by ob_apply(), call something like ob_apply_common() at the start of it's code. IMHO, with this method, the best way to handle legacy non-separated logic would be to move that legacy logic to the "types/common" subdirectory, and set it up so ob_apply() and such will call that if it can't find a callback registered for the type. > > A better case here may be something like examine/describe item, where many > objects may have some specific/unique properties, but many also have common > properties (value, cursed, applied, etc). > Well, I'd be inclined to say this could follow the same model rather well. Simply have examine/describe as a callback like any others. The callback at it's option can call code stored in something like types/common/describe.c for behavior common to multiple types (get the string for generic properties of it). If ob_describe() finds no callback, it falls back to a generic function in types/common/describe.c IMHO this model allows the most flexibility for cases where we might want the 'common' behavior overridden for a type. Also I believe this model would be very valuable if per-object or per-arch hooks are implemented and the plugin system given access to that. > Other thought not related to the above: > Given this is a major restructure, would it make sense to collapse/redo some of > the types, particularly the equipable equipment? IMHO This should be done as well, though one question is: would it be worth completely redoing the type numbers and converting all of the maps/arches? Or should we try to keep the numbers the same where possible, and have the loader change type values that were collapsed to the new value? Alex Schultz From nicolas.weeger at laposte.net Mon Oct 30 15:42:58 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Mon, 30 Oct 2006 22:42:58 +0100 Subject: [crossfire] 2.0 object-type refactoring In-Reply-To: <4543C55F.3060605@telus.net> References: <4543C55F.3060605@telus.net> Message-ID: <200610302242.58214.nicolas.weeger@laposte.net> Hello. > For a while now I've been throwing the idea of separating the server's > object-type-specific code by object types. Currently things are rather > disorganized with code for how an object type works being spread all > around the code. I plan to begin to implement the plan on the following > wiki page soon if nobody has any objections: > /http://wiki.metalforge.net/doku.php/dev_todo:refactor/ Sounds ok to me. I guess not everything is planned, so there'll probably be adjustments later on, but fine for me :) > Also, would be nice for some others to help a bit once it's started :) I'll try to help when i get time. Nicolas From mwedel at sonic.net Mon Oct 30 23:58:49 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 30 Oct 2006 21:58:49 -0800 Subject: [crossfire] 2.0 object-type refactoring In-Reply-To: <4546094F.8070902@telus.net> References: <4543C55F.3060605@telus.net> <45444854.5010502@telus.net> <45458F10.4050303@sonic.net> <45459D86.5020106@telus.net> <4545B0DA.30202@sonic.net> <4546094F.8070902@telus.net> Message-ID: <4546E619.3010804@sonic.net> Alex Schultz wrote: > Well, the way I was thinking of doing it, would be to replace specific > calls to apply, drop, etc as they are sprinkled throughout the code, and > keep common code such as you say, in a "common" subdirectory of the > types directory, and then have the callback called by ob_apply(), call > something like ob_apply_common() at the start of it's code. > IMHO, with this method, the best way to handle legacy non-separated > logic would be to move that legacy logic to the "types/common" > subdirectory, and set it up so ob_apply() and such will call that if it > can't find a callback registered for the type. That works I suppose. You do get into various questions that have no clear answer. Like 'should the main drop function be in the commands.c file (since it is a command the player issues) or should it be in the types/common.c file' I'd be somewhat inclined to have the command logic still in the command (c_...) files, and from there, it does the callback. It seems (to me at least) that is a little better - the basic command logic is still in the commands file, and the actual object specific drop is in the types area. But I can also see the other point - lets put all the common object operations together. I also do think that if there are standards in place that all objects should follow (like not letting unpaid objects be used), that should be enforced, and not something that is affected by object type. If some objects really should change the behaviour, I'd be more inclined to say they should have specific flags for such variations - one reason there are some many object types right now is that there is some of that 'if type==FOO, I behave 95% like BAR, except for this one little case'. The problem this leads to is down the road, someone says 'which do I use, FOO or BAR', where if there was just a flag which controlled that basic actions, that is clearer. The other reason I'd like there to be common functions is that I think it will make debugging a little easier. With a single function that then makes the callbacks if necessary, I can easily set a breakpoint in there to catch when any object of any type does that action. Otherwise, there isn't any easy way to catch 'if any object of any type is dropped' type of thing, unless there is a common function that every object type uses 100% of the time. But it probably is more stylistically - to me, this seems cleaner: void action() { some common code make object callback } vs void action_for_type() { make_common_call_for_all_types() do my specific code } It just seems that if everything is going to call make_common_call_for_all_types(), why not just call that in the first place? >> Other thought not related to the above: >> Given this is a major restructure, would it make sense to collapse/redo some of >> the types, particularly the equipable equipment? > IMHO This should be done as well, though one question is: would it be > worth completely redoing the type numbers and converting all of the > maps/arches? Or should we try to keep the numbers the same where > possible, and have the loader change type values that were collapsed to > the new value? If maps are changing the object types, they are broken. While it is sometimes done, changing object types is pretty much never good behaviour, because other aspects of the object are not updated. However, for the archetypes, they should be updated with the new numbers - it shouldn't be hard to do, and is definitely the right approach. From alex_sch at telus.net Tue Oct 31 00:49:29 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 30 Oct 2006 23:49:29 -0700 Subject: [crossfire] 2.0 object-type refactoring In-Reply-To: <4546E619.3010804@sonic.net> References: <4543C55F.3060605@telus.net> <45444854.5010502@telus.net> <45458F10.4050303@sonic.net> <45459D86.5020106@telus.net> <4545B0DA.30202@sonic.net> <4546094F.8070902@telus.net> <4546E619.3010804@sonic.net> Message-ID: <4546F1F9.2020201@telus.net> Mark Wedel wrote: > Alex Schultz wrote: > > >> Well, the way I was thinking of doing it, would be to replace specific >> calls to apply, drop, etc as they are sprinkled throughout the code, and >> keep common code such as you say, in a "common" subdirectory of the >> types directory, and then have the callback called by ob_apply(), call >> something like ob_apply_common() at the start of it's code. >> IMHO, with this method, the best way to handle legacy non-separated >> logic would be to move that legacy logic to the "types/common" >> subdirectory, and set it up so ob_apply() and such will call that if it >> can't find a callback registered for the type. >> > > That works I suppose. You do get into various questions that have no clear > answer. Like 'should the main drop function be in the commands.c file (since it > is a command the player issues) or should it be in the types/common.c file' > > I'd be somewhat inclined to have the command logic still in the command > (c_...) files, and from there, it does the callback. It seems (to me at least) > that is a little better - the basic command logic is still in the commands file, > and the actual object specific drop is in the types area. But I can also see > the other point - lets put all the common object operations together. > To me it also seems best to keep command logic in the command files, and that does the callback. However IMHO only bits about decoding the command, and providing certain types of player feedback, should be handled in the command files. That way, it is easy to make code that does an action that is (currently) normally a player action, with code common to it, and without giving feedback to the player that isn't valid considering the player didn't make that action. Basically, I believe that player-actions should keep their command-decoding, player-feedback, and other code that should only happen when a player is triggering the action directly, in the command code, but delegate all action code in the callback system. Also, along the same sort of lines, unpaid checks should for the most part be done in the command code as opposed to the actual action code. > > > The other reason I'd like there to be common functions is that I think it will > make debugging a little easier. With a single function that then makes the > callbacks if necessary, I can easily set a breakpoint in there to catch when any > object of any type does that action. Otherwise, there isn't any easy way to > catch 'if any object of any type is dropped' type of thing, unless there is a > common function that every object type uses 100% of the time. > Well, I was planning on having ob_apply(), ob_drop() functions to run the callbacks. I would say that's even easier to do breakpoints and debugging with, than leaving things to run a callback directly in many places in the code such as the commands files as it would be if we just inserted a callback check before the existing case statements and such. I do think there should be common functions, but I believe they should be in a central file relating to this callback system. > But it probably is more stylistically - to me, this seems cleaner: > > void action() > { > some common code > make object callback > } > > vs > > void action_for_type() > { > make_common_call_for_all_types() > do my specific code > } > > It just seems that if everything is going to call > make_common_call_for_all_types(), why not just call that in the first place? > Well, the issue IMHO, is for things such as applying, what if one specific type wants to put restrictions on when one can apply an object? Due to that, it seems to me that the second option would be a more flexible and desirable way to call the common code for all types. Also, I believe that such common code should be more specific name than "make_common_call_for_all_types()", perhaps more along the lines of something like can_apply() and complete_apply(), with can_apply() doing common checks on if it can be applied, and complete_apply() doing common code about what applying the object does. (also, just a note for others reading, for the sake of clarity I'll note, in the second case, the action() function becomes simply "void action() { make object callback }" and eventually extended to include things like integrating into the plugin system.) Alex Schultz From mwedel at sonic.net Tue Oct 31 02:25:40 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 31 Oct 2006 00:25:40 -0800 Subject: [crossfire] 2.0 object-type refactoring In-Reply-To: <4546F1F9.2020201@telus.net> References: <4543C55F.3060605@telus.net> <45444854.5010502@telus.net> <45458F10.4050303@sonic.net> <45459D86.5020106@telus.net> <4545B0DA.30202@sonic.net> <4546094F.8070902@telus.net> <4546E619.3010804@sonic.net> <4546F1F9.2020201@telus.net> Message-ID: <45470884.4030904@sonic.net> Alex Schultz wrote: >> The other reason I'd like there to be common functions is that I think it will >> make debugging a little easier. With a single function that then makes the >> callbacks if necessary, I can easily set a breakpoint in there to catch when any >> object of any type does that action. Otherwise, there isn't any easy way to >> catch 'if any object of any type is dropped' type of thing, unless there is a >> common function that every object type uses 100% of the time. >> > Well, I was planning on having ob_apply(), ob_drop() functions to run > the callbacks. I would say that's even easier to do breakpoints and > debugging with, than leaving things to run a callback directly in many > places in the code such as the commands files as it would be if we just > inserted a callback check before the existing case statements and such. > I do think there should be common functions, but I believe they should > be in a central file relating to this callback system. Ok. If that's the case, that is fine. What it sound liked was that you were going to change it so that where right now it does something like apply_special() call, it would instead be replaced with callbacks[ob->type](...) If all you are changing ins apply_special() to ob_apply() (or similar type logic) and ob_apply is then doing the callbacks[ob->type](), that is fine. In that mode, I still think it would be easy to do an object type at a time - you'd have something like: ob_apply() { if (we have callback) do_callback() else call_old_apply_function() } type of thing. OTOH, all this discussion about intermediary progress may really just be overthinking it. With a concerted effort, it shouldn't take too long to make all the changes and then it no longer becomes any issue what things looked like while the changes were being made. > >> But it probably is more stylistically - to me, this seems cleaner: >> >> void action() >> { >> some common code >> make object callback >> } >> >> vs >> >> void action_for_type() >> { >> make_common_call_for_all_types() >> do my specific code >> } >> >> It just seems that if everything is going to call >> make_common_call_for_all_types(), why not just call that in the first place? >> > Well, the issue IMHO, is for things such as applying, what if one > specific type wants to put restrictions on when one can apply an object? > Due to that, it seems to me that the second option would be a more > flexible and desirable way to call the common code for all types. Also, > I believe that such common code should be more specific name than > "make_common_call_for_all_types()", perhaps more along the lines of > something like can_apply() and complete_apply(), with can_apply() doing > common checks on if it can be applied, and complete_apply() doing common > code about what applying the object does. > (also, just a note for others reading, for the sake of clarity I'll > note, in the second case, the action() function becomes simply "void > action() { make object callback }" and eventually extended to include > things like integrating into the plugin system.) I'd say we are probably talking about two different things. If certain object types want to put further restrictions on objects, that is completely reasonable. It would have that logic in its type specific handling function, or if several types of objects wanted that logic, would perhaps have some common function to handle that. To some extent, that is the entire purpose of the type specific code. What I'm talking about is common behavior that all objects share, regardless of type, and changing that behavior really shouldn't be allowed. The previous example I had was about applying unpaid objects. I can't think of any case where that should be allowed, and if there was some specific reason, I think a flag on the object should control that, and not object type (as presumably, that object would have some behavior like existing objects). I think it is cleaner to have it like: ob_apply() { if object_is_unpaid { display message about unpaid objects, return} } vs ob_weapon_apply() { if common_object_apply_check() return } where presumably common_object_apply_check() will print out any messages. Once again, may not be as big a deal, but it just seems cleaner to me to have the upper function do those checks vs the lower level functions having to make calls into the same function. IMO, the only case it makes sense for the type specific function to make the function call for the common logic is if there is no upper level function from which to do those checks. (another different case here is dropping of damned/cursed objects - regardless of type, that shouldn't be allowed save for something special (DM)) From lalo.martins at gmail.com Tue Oct 31 06:30:14 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue, 31 Oct 2006 20:30:14 +0800 Subject: [crossfire] 2.0 object-type refactoring References: <4543C55F.3060605@telus.net> <45444854.5010502@telus.net> <45458F10.4050303@sonic.net> <45459D86.5020106@telus.net> <4545B0DA.30202@sonic.net> <4546094F.8070902@telus.net> Message-ID: On Mon, 30 Oct 2006 07:16:47 -0700, Alex Schultz wrote: > Well, the way I was thinking of doing it, would be to replace specific > calls to apply, drop, etc as they are sprinkled throughout the code, and > keep common code such as you say, in a "common" subdirectory of the > types directory, and then have the callback called by ob_apply(), call > something like ob_apply_common() at the start of it's code. > IMHO, with this method, the best way to handle legacy non-separated > logic would be to move that legacy logic to the "types/common" > subdirectory, and set it up so ob_apply() and such will call that if it > can't find a callback registered for the type. for that matter... if you're refactoring into a proper object system, why not go all the way and do subclasses? Create a "BASEOBJECT" type, put all the "common" code as methods of this type, and then call that from the top of the specialised methods just like you'd do "super.foo()" in other languages. That keeps the way open for you to decide that, in the future, you need more than one level of inheritance -- eg a "BASEARMOR" type that the armor subtypes inherit from. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From alex_sch at telus.net Tue Oct 31 08:44:00 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 31 Oct 2006 07:44:00 -0700 Subject: [crossfire] 2.0 object-type refactoring In-Reply-To: References: <4543C55F.3060605@telus.net> <45444854.5010502@telus.net> <45458F10.4050303@sonic.net> <45459D86.5020106@telus.net> <4545B0DA.30202@sonic.net> <4546094F.8070902@telus.net> Message-ID: <45476130.8000308@telus.net> Lalo Martins wrote: > if you're refactoring into a proper object system, why not go all the way > and do subclasses? Create a "BASEOBJECT" type, put all the "common" code > as methods of this type, and then call that from the top of the > specialised methods just like you'd do "super.foo()" in other languages. > That keeps the way open for you to decide that, in the future, you need > more than one level of inheritance -- eg a "BASEARMOR" type that the armor > subtypes inherit from. Well, a simple way to implement that within the proposed method, would be to add a "ob_methods *fallback" entry to the ob_methods struct, and then simply have a default constant ob_methods struct as the "BASEOBJECT". That system could work quite well IMHO, and could simplify introduction of per-arch and per-object things too. Alex Schultz From alex_sch at telus.net Tue Oct 31 21:31:19 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 31 Oct 2006 20:31:19 -0700 Subject: [crossfire] 2.0 object-type refactoring In-Reply-To: <45470884.4030904@sonic.net> References: <4543C55F.3060605@telus.net> <45444854.5010502@telus.net> <45458F10.4050303@sonic.net> <45459D86.5020106@telus.net> <4545B0DA.30202@sonic.net> <4546094F.8070902@telus.net> <4546E619.3010804@sonic.net> <4546F1F9.2020201@telus.net> <45470884.4030904@sonic.net> Message-ID: <45481507.9070208@telus.net> Mark Wedel wrote: > > In that mode, I still think it would be easy to do an object type at a time - > you'd have something like: > > ob_apply() > { > if (we have callback) do_callback() > else call_old_apply_function() > } > > type of thing. > Yes, I agree and do now believe that doing it one-type-at-a-time would work better overall than one-callback-type-at-a-time. The way you say above is about what I'm thinking. Another thought, perhaps instead of the "else" though, we could use the "BASECLASS" via another ob_methods structure as mentioned in a different mail, to implement the falling back to the old function. Not only is it well suited to falling back to the old function, it IMHO might prove a useful system to have in place for after the conversion is complete, particularly once getting into per-arch and per-object ones with plugin support. > > The previous example I had was about applying unpaid objects. I can't think > of any case where that should be allowed, and if there was some specific reason, > I think a flag on the object should control that, and not object type (as > presumably, that object would have some behavior like existing objects). I > think it is cleaner to have it like: > > > (another different case here is dropping of damned/cursed objects - regardless > of type, that shouldn't be allowed save for something special (DM)) > Well, IMHO those dropping and unpaid restrictions should either be in the command code, or give the callback an 'override' parameter, because of the "save for something special" cases. Either works for me, but I am inclined against the 'override' parameter as it IMHO creates unnecessary complexity. Alex Schultz