From tanner at real-time.com Thu Jun 22 02:15:37 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:57:22 2005 Subject: [CF-Devel] Testing Message-ID: <20000622021537.E9366@real-time.com> -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From tanner at real-time.com Tue Jun 27 01:32:35 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:57:22 2005 Subject: [CF-Devel] [CF:1385] Bug in 0.95.6: 'drop n whatever reports "Nothing to drop" Message-ID: <20000627013235.M22840@real-time.com> > server: SuSE Linux 6.4, 486DX4-100, 32 Mb RAM > client: same machine (X11 client) > Crossfire 0.95.6 public release. > > Tried to report this to 'bugzilla', but it's not aware of 0.95.6 yet. Sorry about that. I have updated bugzilla. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 Received: from enchanter.real-time.com (IDENT:root@enchanter.real-time.com [206.10.252.9]) by sprite.real-time.com (8.10.2/8.10.2) with ESMTP id e5S1LWm22146 for ; Tue, 27 Jun 2000 20:21:33 -0500 Received: from crusader.real-time.com (IDENT:root@crusader.real-time.com [206.10.253.23]) by enchanter.real-time.com (8.10.1/8.10.2) with ESMTP id e5S174d30188 for ; Tue, 27 Jun 2000 20:07:04 -0500 Received: (from bugzilla@localhost) by crusader.real-time.com (8.10.1/8.10.1) id e5S10ax07390; Tue, 27 Jun 2000 20:00:36 -0500 Date: Tue, 27 Jun 2000 20:00:36 -0500 Message-Id: <200006280100.e5S10ax07390@crusader.real-time.com> From: bugs@real-time.com To: crossfire-devel@lists.real-time.com Cc: ReplyTo: bugs@real-time.com Subject: [CF-Devel] [Bug 26] New - 'drop n objects reports "Nothing to drop" Sender: crossfire-devel-admin@lists.real-time.com Errors-To: crossfire-devel-admin@lists.real-time.com X-BeenThere: crossfire-devel@lists.real-time.com X-Mailman-Version: 2.0beta2 Precedence: bulk List-Id: Crossfire CVS Commit Mailing List http://bugzilla.real-time.com/show_bug.cgi?id=26 *** shadow/26 Tue Jun 27 20:00:36 2000 --- shadow/26.tmp.7387 Tue Jun 27 20:00:36 2000 *************** *** 0 **** --- 1,46 ---- + Bug#: 26 + Product: Crossfire + Version: 0.95.6 + Platform: PC + OS/Version: Linux + Status: NEW + Resolution: + Severity: normal + Priority: P2 + Component: server + AssignedTo: crossfire-devel@lists.real-time.com + ReportedBy: frank_mckenney@mindspring.com + URL: + Cc: + Summary: 'drop n objects reports "Nothing to drop" + + Server: 0.95.6 public release + SuSE Linux 6.4 + 486DX4-100, 32 Mb RAM + Client: 0.95.6 public release (X11 client) same machine + + + There appears to be a bug in the 'drop command in 0.95.6. + + If a character has, for example, 25 silver coins, the reponse to + the command + + 'drop 1 silver is + + Nothing to drop. + + Given time and space, this can be worked around. For the above example, + use the mouse to drop all (25) silver coins, then issue the command + + 'get 1 silver (which works as expected) + + This occurs with an old or a freshly-created character. + + After this problem (and several others) first appeared, I deleted all(?) + traces of all versions of Crossfire from my Linux system and + re-installed it. The problem still occurs. + + Please feel free to get in touch with me if I can provide any further + information. + + Frank McKenney Received: from enchanter.real-time.com (IDENT:root@enchanter.real-time.com [206.10.252.9]) by sprite.real-time.com (8.10.2/8.10.2) with ESMTP id e5S1pWm22246 for ; Tue, 27 Jun 2000 20:51:33 -0500 Received: from crusader.real-time.com (IDENT:root@crusader.real-time.com [206.10.253.23]) by enchanter.real-time.com (8.10.1/8.10.2) with ESMTP id e5S1b4d31243 for ; Tue, 27 Jun 2000 20:37:04 -0500 Received: (from bugzilla@localhost) by crusader.real-time.com (8.10.1/8.10.1) id e5S1UO607531; Tue, 27 Jun 2000 20:30:24 -0500 Date: Tue, 27 Jun 2000 20:30:24 -0500 Message-Id: <200006280130.e5S1UO607531@crusader.real-time.com> From: bugs@real-time.com To: crossfire-devel@lists.real-time.com Cc: ReplyTo: bugs@real-time.com Subject: [CF-Devel] [Bug 28] New - Torches dim and go out, but icon does not change Sender: crossfire-devel-admin@lists.real-time.com Errors-To: crossfire-devel-admin@lists.real-time.com X-BeenThere: crossfire-devel@lists.real-time.com X-Mailman-Version: 2.0beta2 Precedence: bulk List-Id: Crossfire CVS Commit Mailing List http://bugzilla.real-time.com/show_bug.cgi?id=28 *** shadow/28 Tue Jun 27 20:30:24 2000 --- shadow/28.tmp.7528 Tue Jun 27 20:30:24 2000 *************** *** 0 **** --- 1,27 ---- + Bug#: 28 + Product: Crossfire + Version: 0.95.6 + Platform: Other + OS/Version: Linux + Status: NEW + Resolution: + Severity: minor + Priority: P4 + Component: server + AssignedTo: crossfire-devel@lists.real-time.com + ReportedBy: frank_mckenney@mindspring.com + URL: + Cc: + Summary: Torches dim and go out, but icon does not change + + Server: 0.95.6 public release + Intel x86 PC, 486DX4-100, 32 Mb RAM, SuSE Linux 6.4 + Client: 0.95.6 public release (X11 client) + (same machine) + + If a torch is lit to illuminate, say, the Zombie Church in Scorn, then + light it provides will eventually dim and go out. However, the icon + will remain "lit", and multiple "extinguished" torches will not combine + in the Inventory until the character is logged out and later returns. + + Visually annoying, but as far as I can tell, harmless otherwise. Received: from enchanter.real-time.com (IDENT:root@enchanter.real-time.com [206.10.252.9]) by sprite.real-time.com (8.10.2/8.10.2) with ESMTP id e5S1pXm22250 for ; Tue, 27 Jun 2000 20:51:33 -0500 Received: from crusader.real-time.com (IDENT:root@crusader.real-time.com [206.10.253.23]) by enchanter.real-time.com (8.10.1/8.10.2) with ESMTP id e5S1b4d31248 for ; Tue, 27 Jun 2000 20:37:04 -0500 Received: (from bugzilla@localhost) by crusader.real-time.com (8.10.1/8.10.1) id e5S1SN607498; Tue, 27 Jun 2000 20:28:23 -0500 Date: Tue, 27 Jun 2000 20:28:23 -0500 Message-Id: <200006280128.e5S1SN607498@crusader.real-time.com> From: bugs@real-time.com To: crossfire-devel@lists.real-time.com Cc: ReplyTo: bugs@real-time.com Subject: [CF-Devel] [Bug 27] New - "Arrows of mystery" appear in inventory, vanish at logout Sender: crossfire-devel-admin@lists.real-time.com Errors-To: crossfire-devel-admin@lists.real-time.com X-BeenThere: crossfire-devel@lists.real-time.com X-Mailman-Version: 2.0beta2 Precedence: bulk List-Id: Crossfire CVS Commit Mailing List http://bugzilla.real-time.com/show_bug.cgi?id=27 *** shadow/27 Tue Jun 27 20:28:23 2000 --- shadow/27.tmp.7495 Tue Jun 27 20:28:23 2000 *************** *** 0 **** --- 1,44 ---- + Bug#: 27 + Product: Crossfire + Version: 0.95.6 + Platform: Other + OS/Version: Linux + Status: NEW + Resolution: + Severity: minor + Priority: P4 + Component: server + AssignedTo: crossfire-devel@lists.real-time.com + ReportedBy: frank_mckenney@mindspring.com + URL: + Cc: + Summary: "Arrows of mystery" appear in inventory, vanish at logout + + Server: 0.95.6 public release + Intel x86 PC, 486DX4-100, 32 Mb RAM, SuSE Linux 6.4 + Client: 0.95.6 public release (X11 client) + (same machine) + + + Following combat one or more odd icons labelled 'a arrow' may appear in + my character's inventory. These entries are unusual in several + respects: + + 1) The icon is not the usual 'arrow' icon. Instead, it is a single + arrow pointing at one of the major compass points (N, NE, etc.). + If more than one "AOM" entry is present, the arrows may or may + not point in the same direction. + + 2) The entry cannot (as far as I have been able to tell) be dropped, + either by mouse or the 'drop command, nor can it be 'marked'. + + Fortunately, + + 3) The entries disappear at character logout. At the next login, even + if the server and client are still running, the entries are gone. + + These most frequently appear follwing a visit to Goth's basement, but I + have seen them in other locations. I have had as many as five of these + AOMs in my inventory at one time. + + Visually annoying, but as far as I can tell, harmless otherwise. From mwedel at scruznet.com Tue Jun 27 23:23:08 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:22 2005 Subject: [CF-Devel] CVS update: crossfire Message-ID: <200006280423.VAA02170@boltzmann.EECS.Berkeley.EDU> Date: Tuesday June 27, 2000 @ 21:23 Author: cvs Update of /home/cvs/CVS/crossfire In directory boltzmann:/tmp/cvs-serv2167 Modified Files: INSTALL README CHANGES Log Message: INSTALL, README: Update mailing address to real-time address. MSW 6/27/2000 server/login.c: Load and save usekeys value in player save file. MSW 6/27/2000 **************************************** Index: crossfire/INSTALL diff -u crossfire/INSTALL:1.2 crossfire/INSTALL:1.3 --- crossfire/INSTALL:1.2 Fri Jun 16 21:58:47 2000 +++ crossfire/INSTALL Tue Jun 27 21:23:08 2000 @@ -67,10 +67,10 @@ these scripts are run as the normal compilation & installation process, so this is only a real problem if you plan to rebuild the archetypes. -5) Compile the program: type 'make'. It should take a little while. If - you get errors that abort the compile, copy them down (either using cut - and paste, or redirect the output of the compile to a file), and send - those to the bug alias (crossfire-bugs@ifi.uio.no), along with what +5) Compile the program: type 'make'. It should take a little while. If you + get errors that abort the compile, copy them down (either using cut and + paste, or redirect the output of the compile to a file), and send those to + the bug alias (crossfire-devel@listserv.real-time.com), along with what machine type & OS you are using. Also, include the compile line with its various options. A message saying 'it failed to compile main.c' tells me little, and I can not fix problems with that little detail. Index: crossfire/README diff -u crossfire/README:1.8 crossfire/README:1.9 --- crossfire/README:1.8 Mon Jun 26 20:29:23 2000 +++ crossfire/README Tue Jun 27 21:23:08 2000 @@ -172,7 +172,7 @@ you up on your offer. If you make such an offer, I will assume that you have oberyed whatever usage rules/policies are applicable for your site. - Mail the bug report to crossfire-bugs@ifi.uio.no + Mail the bug report to crossfire-devel@listserv.real-time.com ------------------------------------------------------------------------------ SUBMITTING PATCHES: See the doc/programming_guide file. @@ -198,15 +198,12 @@ version: 0.95.3 -Note that the whitestar.pyrsonal.org server is not listed, as it is likely -to go away soon. - COPYRIGHT Don't get scared by the below, it's included just for "safety" reasons 8) (Don't want anyone to start selling the game) - Copyright (C) 1994 Mark Wedel + Copyright (C) 2000 Mark Wedel Copyright (C) 1992 Frank Tore Johansen This program is free software; you can redistribute it and/or modify @@ -223,4 +220,4 @@ along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - The author can be reached via e-mail to mwedel@scruznet.com + The author can be reached via e-mail to mwedel@scruz.net Index: crossfire/CHANGES diff -u crossfire/CHANGES:1.109 crossfire/CHANGES:1.110 --- crossfire/CHANGES:1.109 Mon Jun 26 20:34:33 2000 +++ crossfire/CHANGES Tue Jun 27 21:23:08 2000 @@ -17,6 +17,10 @@ else. With this, include the file(s) that you changed. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +INSTALL, README: Update mailing address to real-time address. MSW 6/27/2000 + +server/login.c: Load and save usekeys value in player save file. MSW 6/27/2000 + Patch by Jeffry Hantin which fixes glow objects in map. insert_ob_in_map_simple now will call the appropriate light updating code. Applied by MSW 6/26/2000 From mwedel at scruznet.com Tue Jun 27 23:23:09 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:23 2005 Subject: [CF-Devel] CVS update: crossfire/server Message-ID: <200006280423.VAA02177@boltzmann.EECS.Berkeley.EDU> Date: Tuesday June 27, 2000 @ 21:23 Author: cvs Update of /home/cvs/CVS/crossfire/server In directory boltzmann:/tmp/cvs-serv2167/server Modified Files: login.c Log Message: INSTALL, README: Update mailing address to real-time address. MSW 6/27/2000 server/login.c: Load and save usekeys value in player save file. MSW 6/27/2000 **************************************** Index: crossfire/server/login.c diff -u crossfire/server/login.c:1.7 crossfire/server/login.c:1.8 --- crossfire/server/login.c:1.7 Fri May 26 02:50:49 2000 +++ crossfire/server/login.c Tue Jun 27 21:23:09 2000 @@ -1,6 +1,6 @@ /* * static char *rcsid_login_c = - * "$Id: login.c,v 1.7 2000/05/26 09:50:49 jec Exp $"; + * "$Id: login.c,v 1.8 2000/06/28 04:23:09 cvs Exp $"; */ /* @@ -346,6 +346,9 @@ fprintf(fp,"pickup %d\n", pl->mode); fprintf(fp,"outputs_sync %d\n", pl->outputs_sync); fprintf(fp,"outputs_count %d\n", pl->outputs_count); + /* Match the enumerations but in string form */ + fprintf(fp,"usekeys %s\n", pl->usekeys==key_inventory?"key_inventory": + (pl->usekeys==keyrings?"keyrings":"containers")); #ifdef BACKUP_SAVE_AT_HOME if (op->map!=NULL && flag==0) @@ -627,6 +630,15 @@ pl->orig_stats.Wis=value; else if (!strcmp(buf,"Cha")) pl->orig_stats.Cha=value; + else if (!strcmp(buf,"usekeys")) { + if (!strcmp(bufall+8,"key_inventory\n")) + pl->usekeys=key_inventory; + else if (!strcmp(bufall+8,"keyrings\n")) + pl->usekeys=keyrings; + else if (!strcmp(bufall+8,"containers\n")) + pl->usekeys=containers; + else LOG(llevDebug,"load_player: got unknown usekeys type: %s\n", bufall+8); + } else if (!strcmp(buf,"lev_array")){ for(i=1;i<=value;i++) { int j; From mwedel at scruznet.com Tue Jun 27 23:53:58 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:23 2005 Subject: [CF-Devel] CVS update: crossfire Message-ID: <200006280453.VAA02360@boltzmann.EECS.Berkeley.EDU> Date: Tuesday June 27, 2000 @ 21:53 Author: cvs Update of /home/cvs/CVS/crossfire In directory boltzmann:/tmp/cvs-serv2356 Modified Files: CHANGES Log Message: server/c_object.c: Fix command_drop which was doing incorrect check for invisible object - it was supposed to skip over them and only do visible objects, instead it was doing the reverse. Fixes the 'drop command. MSW 6/27/2000 server/input.c: Make the inventory command more robust for very long object names - specify a maximum number of characters we will take from the name. Without this, you could get buffer overruns that cause crashes. No normally generated items would ever likely have names long enough to exploit this bug however. MSW 6/27/2000 **************************************** Index: crossfire/CHANGES diff -u crossfire/CHANGES:1.110 crossfire/CHANGES:1.111 --- crossfire/CHANGES:1.110 Tue Jun 27 21:23:08 2000 +++ crossfire/CHANGES Tue Jun 27 21:53:58 2000 @@ -17,6 +17,17 @@ else. With this, include the file(s) that you changed. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +server/c_object.c: Fix command_drop which was doing incorrect check for +invisible object - it was supposed to skip over them and only do visible +objects, instead it was doing the reverse. Fixes the 'drop command. +MSW 6/27/2000 + +server/input.c: Make the inventory command more robust for very long +object names - specify a maximum number of characters we will take from +the name. Without this, you could get buffer overruns that cause crashes. +No normally generated items would ever likely have names long enough to +exploit this bug however. MSW 6/27/2000 + INSTALL, README: Update mailing address to real-time address. MSW 6/27/2000 server/login.c: Load and save usekeys value in player save file. MSW 6/27/2000 From mwedel at scruznet.com Tue Jun 27 23:53:58 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:23 2005 Subject: [CF-Devel] CVS update: crossfire/server Message-ID: <200006280453.VAA02366@boltzmann.EECS.Berkeley.EDU> Date: Tuesday June 27, 2000 @ 21:53 Author: cvs Update of /home/cvs/CVS/crossfire/server In directory boltzmann:/tmp/cvs-serv2356/server Modified Files: c_object.c input.c Log Message: server/c_object.c: Fix command_drop which was doing incorrect check for invisible object - it was supposed to skip over them and only do visible objects, instead it was doing the reverse. Fixes the 'drop command. MSW 6/27/2000 server/input.c: Make the inventory command more robust for very long object names - specify a maximum number of characters we will take from the name. Without this, you could get buffer overruns that cause crashes. No normally generated items would ever likely have names long enough to exploit this bug however. MSW 6/27/2000 **************************************** Index: crossfire/server/c_object.c diff -u crossfire/server/c_object.c:1.8 crossfire/server/c_object.c:1.9 --- crossfire/server/c_object.c:1.8 Wed Jun 21 02:34:56 2000 +++ crossfire/server/c_object.c Tue Jun 27 21:53:58 2000 @@ -1,6 +1,6 @@ /* * static char *rcsid_c_object_c = - * "$Id: c_object.c,v 1.8 2000/06/21 09:34:56 jec Exp $"; + * "$Id: c_object.c,v 1.9 2000/06/28 04:53:58 cvs Exp $"; */ /* CrossFire, A Multiplayer game for X-windows @@ -827,7 +827,7 @@ for (tmp=op->inv; tmp; tmp=next) { next=tmp->below; if (QUERY_FLAG(tmp,FLAG_NO_DROP) || - !tmp->invisible) continue; + tmp->invisible) continue; if (item_matched_string(op,tmp,params)) { drop(op, tmp); did_one=1; Index: crossfire/server/input.c diff -u crossfire/server/input.c:1.10 crossfire/server/input.c:1.11 --- crossfire/server/input.c:1.10 Sun Jun 18 15:35:59 2000 +++ crossfire/server/input.c Tue Jun 27 21:53:58 2000 @@ -1,6 +1,6 @@ /* * static char *rcsid_input_c = - * "$Id: input.c,v 1.10 2000/06/18 22:35:59 jec Exp $"; + * "$Id: input.c,v 1.11 2000/06/28 04:53:58 cvs Exp $"; */ /* CrossFire, A Multiplayer game for X-windows @@ -330,7 +330,7 @@ new_draw_info(NDI_UNIQUE, 0,op,"You carry nothing."); return; } else { - length = 30; + length = 28; in = ""; if (op) clear_win_info(op); @@ -340,7 +340,7 @@ if (items==0) return; else { - length = 30; + length = 28; in = " "; } } @@ -349,10 +349,11 @@ (inv && inv->type != CONTAINER && !QUERY_FLAG(tmp, FLAG_APPLIED)))) continue; if((!op || QUERY_FLAG(op, FLAG_WIZ))) - (void) sprintf(buf,"%s- %-*s (%5d) %-8s", in, length, query_name(tmp), - tmp->count,query_weight(tmp)); + (void) sprintf(buf,"%s- %-*.*s (%5d) %-8s", in, length, length, + query_name(tmp), tmp->count,query_weight(tmp)); else - (void) sprintf(buf,"%s- %-*s %-8s", in, length+8, query_name(tmp), + (void) sprintf(buf,"%s- %-*.*s %-8s", in, length+8, + length+8, query_name(tmp), query_weight(tmp)); new_draw_info(NDI_UNIQUE, 0,op,buf); } From bugs at real-time.com Tue Jun 27 23:54:17 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:23 2005 Subject: [CF-Devel] [Bug 26] Changed - 'drop n objects reports "Nothing to drop" Message-ID: <200006280454.e5S4sHL08244@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=26 *** shadow/26 Tue Jun 27 20:00:36 2000 --- shadow/26.tmp.8241 Tue Jun 27 23:54:17 2000 *************** *** 3,10 **** Version: 0.95.6 Platform: PC OS/Version: Linux ! Status: NEW ! Resolution: Severity: normal Priority: P2 Component: server --- 3,10 ---- Version: 0.95.6 Platform: PC OS/Version: Linux ! Status: RESOLVED ! Resolution: FIXED Severity: normal Priority: P2 Component: server From mwedel at scruznet.com Wed Jun 28 00:57:04 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:23 2005 Subject: [CF-Devel] CVS update: arch/door/Locked Message-ID: <200006280557.WAA02704@boltzmann.EECS.Berkeley.EDU> Date: Tuesday June 27, 2000 @ 22:57 Author: cvs Update of /home/cvs/CVS/arch/door/Locked In directory boltzmann:/tmp/cvs-serv2684/door/Locked Modified Files: key2.arc Log Message: door/Locked/key2.arc, misc/Container/bag.arc, misc/Container/bookshelf.arc, misc/Container/cauldron.arc, misc/Container/chest_2.arc, misc/Container/depositbox.arc, misc/Container/key_ring.arc, misc/Container/mailbox.arc, misc/Container/pouch.arc, misc/Container/r_sack.arc misc/Container/sack.arc: Remove the 'a' from the objects name. The client adds it anyways, so you see 'a a bag' for example, but also when using the commands like 'drop that match on an item name, having to match against the 'a ' is a bit non intuitive. MSW 6/27/2000 **************************************** Index: arch/door/Locked/key2.arc diff -u arch/door/Locked/key2.arc:1.1 arch/door/Locked/key2.arc:1.2 --- arch/door/Locked/key2.arc:1.1 Sun Mar 28 20:51:37 1999 +++ arch/door/Locked/key2.arc Tue Jun 27 22:57:04 2000 @@ -1,5 +1,5 @@ Object key2 -name a strange key +name strange key race keys slaying set_individual_value face key2.111 From mwedel at scruznet.com Wed Jun 28 00:57:04 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:23 2005 Subject: [CF-Devel] CVS update: arch Message-ID: <200006280557.WAA02699@boltzmann.EECS.Berkeley.EDU> Date: Tuesday June 27, 2000 @ 22:57 Author: cvs Update of /home/cvs/CVS/arch In directory boltzmann:/tmp/cvs-serv2684 Modified Files: CHANGES Log Message: door/Locked/key2.arc, misc/Container/bag.arc, misc/Container/bookshelf.arc, misc/Container/cauldron.arc, misc/Container/chest_2.arc, misc/Container/depositbox.arc, misc/Container/key_ring.arc, misc/Container/mailbox.arc, misc/Container/pouch.arc, misc/Container/r_sack.arc misc/Container/sack.arc: Remove the 'a' from the objects name. The client adds it anyways, so you see 'a a bag' for example, but also when using the commands like 'drop that match on an item name, having to match against the 'a ' is a bit non intuitive. MSW 6/27/2000 **************************************** Index: arch/CHANGES diff -u arch/CHANGES:1.12 arch/CHANGES:1.13 --- arch/CHANGES:1.12 Tue Jun 20 21:32:35 2000 +++ arch/CHANGES Tue Jun 27 22:57:04 2000 @@ -1,5 +1,14 @@ Changes for CVS top of tree: +door/Locked/key2.arc, misc/Container/bag.arc, misc/Container/bookshelf.arc, +misc/Container/cauldron.arc, misc/Container/chest_2.arc, +misc/Container/depositbox.arc, misc/Container/key_ring.arc, +misc/Container/mailbox.arc, misc/Container/pouch.arc, +misc/Container/r_sack.arc misc/Container/sack.arc: Remove the 'a' from the +objects name. The client adds it anyways, so you see 'a a bag' for example, +but also when using the commands like 'drop that match on an item name, having +to match against the 'a ' is a bit non intuitive. MSW 6/27/2000 + ------------------------------------------------------------------------------ Changes for Crossfire 0.95.6: From mwedel at scruznet.com Wed Jun 28 00:57:05 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:23 2005 Subject: [CF-Devel] CVS update: arch/misc/Container Message-ID: <200006280557.WAA02709@boltzmann.EECS.Berkeley.EDU> Date: Tuesday June 27, 2000 @ 22:57 Author: cvs Update of /home/cvs/CVS/arch/misc/Container In directory boltzmann:/tmp/cvs-serv2684/misc/Container Modified Files: bag.arc bookshelf.arc cauldron.arc chest_2.arc depositbox.arc key_ring.arc mailbox.arc pouch.arc r_sack.arc sack.arc Log Message: door/Locked/key2.arc, misc/Container/bag.arc, misc/Container/bookshelf.arc, misc/Container/cauldron.arc, misc/Container/chest_2.arc, misc/Container/depositbox.arc, misc/Container/key_ring.arc, misc/Container/mailbox.arc, misc/Container/pouch.arc, misc/Container/r_sack.arc misc/Container/sack.arc: Remove the 'a' from the objects name. The client adds it anyways, so you see 'a a bag' for example, but also when using the commands like 'drop that match on an item name, having to match against the 'a ' is a bit non intuitive. MSW 6/27/2000 **************************************** Index: arch/misc/Container/bag.arc diff -u arch/misc/Container/bag.arc:1.1 arch/misc/Container/bag.arc:1.2 --- arch/misc/Container/bag.arc:1.1 Sun Mar 28 20:54:13 1999 +++ arch/misc/Container/bag.arc Tue Jun 27 22:57:04 2000 @@ -1,5 +1,5 @@ Object bag -name a bag +name bag other_arch close_bag face bag.111 type 122 Index: arch/misc/Container/bookshelf.arc diff -u arch/misc/Container/bookshelf.arc:1.1 arch/misc/Container/bookshelf.arc:1.2 --- arch/misc/Container/bookshelf.arc:1.1 Sun Mar 28 20:54:15 1999 +++ arch/misc/Container/bookshelf.arc Tue Jun 27 22:57:04 2000 @@ -1,5 +1,5 @@ Object bookshelf -name a bookshelf +name bookshelf other_arch close_shelf face bookshelf.111 type 122 Index: arch/misc/Container/cauldron.arc diff -u arch/misc/Container/cauldron.arc:1.1 arch/misc/Container/cauldron.arc:1.2 --- arch/misc/Container/cauldron.arc:1.1 Sun Mar 28 20:54:15 1999 +++ arch/misc/Container/cauldron.arc Tue Jun 27 22:57:04 2000 @@ -12,7 +12,7 @@ color_fg black end Object bad_cauldron -name a cracked cauldron +name cracked cauldron other_arch cauldron_open face cauldron.111 type 122 Index: arch/misc/Container/chest_2.arc diff -u arch/misc/Container/chest_2.arc:1.1 arch/misc/Container/chest_2.arc:1.2 --- arch/misc/Container/chest_2.arc:1.1 Sun Mar 28 20:54:14 1999 +++ arch/misc/Container/chest_2.arc Tue Jun 27 22:57:04 2000 @@ -1,5 +1,5 @@ Object chest_2 -name a chest +name chest other_arch close_chest face chest_1.111 type 122 Index: arch/misc/Container/depositbox.arc diff -u arch/misc/Container/depositbox.arc:1.1 arch/misc/Container/depositbox.arc:1.2 --- arch/misc/Container/depositbox.arc:1.1 Sun Mar 28 20:54:14 1999 +++ arch/misc/Container/depositbox.arc Tue Jun 27 22:57:04 2000 @@ -1,5 +1,5 @@ Object depositbox -name a deposit box +name deposit box other_arch close_dbox race gold and jewels face depositbox.111 Index: arch/misc/Container/key_ring.arc diff -u arch/misc/Container/key_ring.arc:1.1 arch/misc/Container/key_ring.arc:1.2 --- arch/misc/Container/key_ring.arc:1.1 Sun Mar 28 20:54:14 1999 +++ arch/misc/Container/key_ring.arc Tue Jun 27 22:57:04 2000 @@ -1,5 +1,5 @@ Object key_ring -name a key ring +name key ring other_arch close_key_ring race keys face key_ring.111 Index: arch/misc/Container/mailbox.arc diff -u arch/misc/Container/mailbox.arc:1.1 arch/misc/Container/mailbox.arc:1.2 --- arch/misc/Container/mailbox.arc:1.1 Sun Mar 28 20:54:15 1999 +++ arch/misc/Container/mailbox.arc Tue Jun 27 22:57:04 2000 @@ -1,5 +1,5 @@ Object mailbox -name a mailbox +name mailbox other_arch close_mail face mailbox.111 type 122 Index: arch/misc/Container/pouch.arc diff -u arch/misc/Container/pouch.arc:1.1 arch/misc/Container/pouch.arc:1.2 --- arch/misc/Container/pouch.arc:1.1 Sun Mar 28 20:54:14 1999 +++ arch/misc/Container/pouch.arc Tue Jun 27 22:57:04 2000 @@ -1,5 +1,5 @@ Object pouch -name a pouch +name pouch other_arch close_pouch race gold and jewels face pouch.111 Index: arch/misc/Container/r_sack.arc diff -u arch/misc/Container/r_sack.arc:1.1 arch/misc/Container/r_sack.arc:1.2 --- arch/misc/Container/r_sack.arc:1.1 Sun Mar 28 20:54:15 1999 +++ arch/misc/Container/r_sack.arc Tue Jun 27 22:57:04 2000 @@ -1,5 +1,5 @@ Object r_sack -name a rucksack +name rucksack other_arch close_rsack face r_sack.111 type 122 Index: arch/misc/Container/sack.arc diff -u arch/misc/Container/sack.arc:1.1 arch/misc/Container/sack.arc:1.2 --- arch/misc/Container/sack.arc:1.1 Sun Mar 28 20:54:13 1999 +++ arch/misc/Container/sack.arc Tue Jun 27 22:57:04 2000 @@ -1,5 +1,5 @@ Object sack -name a sack +name sack other_arch close_sack face sack.111 type 122 From mwedel at scruznet.com Wed Jun 28 01:19:19 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:23 2005 Subject: [CF-Devel] CVS update: crossfire/lib Message-ID: <200006280619.XAA02867@boltzmann.EECS.Berkeley.EDU> Date: Tuesday June 27, 2000 @ 23:19 Author: cvs Update of /home/cvs/CVS/crossfire/lib In directory boltzmann:/tmp/cvs-serv2861/lib Modified Files: archetypes Log Message: lib/archetypes: Update to keep in sync with arch tree. Changes to about a dozen arch's to remove the 'a' in their name. MSW 6/27/2000 **************************************** Index: crossfire/lib/archetypes diff -u crossfire/lib/archetypes:1.9 crossfire/lib/archetypes:1.10 --- crossfire/lib/archetypes:1.9 Wed Jun 21 21:58:12 2000 +++ crossfire/lib/archetypes Tue Jun 27 23:19:19 2000 @@ -4460,7 +4460,7 @@ editable 16 end Object key2 -name a strange key +name strange key race keys slaying set_individual_value face key2.111 @@ -10110,7 +10110,7 @@ value 1000 end Object bag -name a bag +name bag other_arch close_bag face bag.111 type 122 @@ -10132,7 +10132,7 @@ editable 0 end Object bookshelf -name a bookshelf +name bookshelf other_arch close_shelf face bookshelf.111 type 122 @@ -10165,7 +10165,7 @@ editable 128 end Object bad_cauldron -name a cracked cauldron +name cracked cauldron other_arch cauldron_open face cauldron.111 type 122 @@ -10197,7 +10197,7 @@ randomitems chest end Object chest_2 -name a chest +name chest other_arch close_chest face chest_1.111 type 122 @@ -10218,7 +10218,7 @@ editable 0 end Object depositbox -name a deposit box +name deposit box other_arch close_dbox race gold and jewels face depositbox.111 @@ -10239,7 +10239,7 @@ editable 0 end Object key_ring -name a key ring +name key ring other_arch close_key_ring race keys face key_ring.111 @@ -10276,7 +10276,7 @@ identified 1 end Object mailbox -name a mailbox +name mailbox other_arch close_mail face mailbox.111 type 122 @@ -10296,7 +10296,7 @@ identified 1 end Object pouch -name a pouch +name pouch other_arch close_pouch race gold and jewels face pouch.111 @@ -10344,7 +10344,7 @@ editable 0 end Object r_sack -name a rucksack +name rucksack other_arch close_rsack face r_sack.111 type 122 @@ -10366,7 +10366,7 @@ editable 0 end Object sack -name a sack +name sack other_arch close_sack face sack.111 type 122 From mwedel at scruznet.com Wed Jun 28 01:19:20 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:23 2005 Subject: [CF-Devel] CVS update: crossfire Message-ID: <200006280619.XAA02872@boltzmann.EECS.Berkeley.EDU> Date: Tuesday June 27, 2000 @ 23:19 Author: cvs Update of /home/cvs/CVS/crossfire In directory boltzmann:/tmp/cvs-serv2861 Modified Files: CHANGES Log Message: lib/archetypes: Update to keep in sync with arch tree. Changes to about a dozen arch's to remove the 'a' in their name. MSW 6/27/2000 **************************************** Index: crossfire/CHANGES diff -u crossfire/CHANGES:1.111 crossfire/CHANGES:1.112 --- crossfire/CHANGES:1.111 Tue Jun 27 21:53:58 2000 +++ crossfire/CHANGES Tue Jun 27 23:19:19 2000 @@ -17,6 +17,9 @@ else. With this, include the file(s) that you changed. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +lib/archetypes: Update to keep in sync with arch tree. Changes to +about a dozen arch's to remove the 'a' in their name. MSW 6/27/2000 + server/c_object.c: Fix command_drop which was doing incorrect check for invisible object - it was supposed to skip over them and only do visible objects, instead it was doing the reverse. Fixes the 'drop command. From mwedel at scruznet.com Wed Jun 28 14:27:30 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:23 2005 Subject: [CF-Devel] CVS update: maps/peterm/quests Message-ID: <200006281927.MAA06699@boltzmann.EECS.Berkeley.EDU> Date: Wednesday June 28, 2000 @ 12:27 Author: peterm Update of /home/cvs/CVS/maps/peterm/quests In directory boltzmann:/tmp/cvs-serv6695 Modified Files: mushroom_quest Log Message: Fix the mushrom. **************************************** Index: maps/peterm/quests/mushroom_quest diff -u maps/peterm/quests/mushroom_quest:1.3 maps/peterm/quests/mushroom_quest:1.4 --- maps/peterm/quests/mushroom_quest:1.3 Wed Jun 7 16:08:03 2000 +++ maps/peterm/quests/mushroom_quest Wed Jun 28 12:27:30 2000 @@ -1617,6 +1617,7 @@ y 27 end arch mushroom_3 +slaying bunion x 8 y 27 end From peterm at tesla.EECS.Berkeley.EDU Thu Jun 29 02:50:53 2000 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 17:57:23 2005 Subject: [CF-Devel] A lead on one of the bugs remaining in crossfire? Message-ID: <200006290750.AAA15982@tesla.EECS.Berkeley.EDU> So I pacified (sing) and then coopted (oratory) a kobold into a pet. Tiring of having a kobold around, I torched it with burning hands. This was the result: Remove_friendly_object: Can't find object (null) (0). Trying to free freed object. arch kobold face kobold.112 animation kobold Wis 8 Int 1 hp -18 maxhp 2 dam 2 wc 27 ac 18 x 6 y 15 attack_movement 16 level 1 direction 7 weight 30000 state 1 run_away 90 alive 1 no_pick 1 is_animated 1 monster 1 run_away 1 no_steal 1 end From bugs at real-time.com Thu Jun 29 03:33:40 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:23 2005 Subject: [CF-Devel] [Bug 18] Changed - CVS version: "Fall through Hole" message given too early Message-ID: <200006290833.e5T8XeL16916@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=18 *** shadow/18 Wed Jun 28 04:24:25 2000 --- shadow/18.tmp.16913 Thu Jun 29 03:33:40 2000 *************** *** 1,6 **** Bug#: 18 Product: Crossfire ! Version: 0.95.5 Platform: PC OS/Version: Linux Status: NEW --- 1,6 ---- Bug#: 18 Product: Crossfire ! Version: 0.95.6 Platform: PC OS/Version: Linux Status: NEW *************** *** 8,14 **** Severity: trivial Priority: P2 Component: server ! AssignedTo: crossfire-bugs@ifi.uio.no ReportedBy: mullern@mweb.co.za URL: Cc: --- 8,14 ---- Severity: trivial Priority: P2 Component: server ! AssignedTo: crossfire-devel@lists.real-time.com ReportedBy: mullern@mweb.co.za URL: Cc: From tanner at real-time.com Thu Jun 22 01:52:30 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:15 2005 Subject: [CF List] Testing Message-ID: <20000622015230.J8428@real-time.com> -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 Received: from enchanter.real-time.com (IDENT:root@enchanter.real-time.com [206.10.252.9]) by sprite.real-time.com (8.10.2/8.10.2) with ESMTP id e5M70dx25991 for ; Thu, 22 Jun 2000 02:00:39 -0500 Received: (from tanner@localhost) by enchanter.real-time.com (8.10.1/8.10.2) id e5M6k3m08861 for crossfire-list@lists.real-time.com; Thu, 22 Jun 2000 01:46:03 -0500 Date: Thu, 22 Jun 2000 01:46:03 -0500 From: Bob Tanner To: crossfire-list@lists.real-time.com Message-ID: <20000622014603.F8428@real-time.com> Mail-Followup-To: crossfire-list@lists.real-time.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Subject: [CF List] subscribe Sender: crossfire-list-admin@lists.real-time.com Errors-To: crossfire-list-admin@lists.real-time.com X-BeenThere: crossfire-list@lists.real-time.com X-Mailman-Version: 2.0beta2 Precedence: bulk List-Id: Crossfire Discussion Mailing List -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From tanner at real-time.com Tue Jun 27 01:32:35 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:16 2005 Subject: [CF List] [CF:1385] Bug in 0.95.6: 'drop n whatever reports "Nothing to drop" Message-ID: <20000627013235.M22840@real-time.com> > server: SuSE Linux 6.4, 486DX4-100, 32 Mb RAM > client: same machine (X11 client) > Crossfire 0.95.6 public release. > > Tried to report this to 'bugzilla', but it's not aware of 0.95.6 yet. Sorry about that. I have updated bugzilla. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From tanner at real-time.com Tue Jun 27 02:03:31 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:16 2005 Subject: [CF List] Testing Message-ID: <20000627020331.A24527@real-time.com> Testing mailing list. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From tanner at real-time.com Tue Jun 27 01:32:35 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:16 2005 Subject: [CF List] [CF:1385] Bug in 0.95.6: 'drop n whatever reports "Nothing to drop" Message-ID: <20000627013235.M22840@real-time.com> > server: SuSE Linux 6.4, 486DX4-100, 32 Mb RAM > client: same machine (X11 client) > Crossfire 0.95.6 public release. > > Tried to report this to 'bugzilla', but it's not aware of 0.95.6 yet. Sorry about that. I have updated bugzilla. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 - [you can put yourself on the announcement list only or unsubscribe altogether by sending an email stating your wishes to crossfire-request@ifi.uio.no] From tanner at real-time.com Tue Jun 27 02:09:59 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:16 2005 Subject: [CF List] [CF Announce] Mailing list cut-over complete Message-ID: <20000627020959.B24527@real-time.com> The mailing list cut-over is complete. The web site is up to date. All the old addresses will still work. Please let myself or leaf@real-time.com know of any problems. Thanks. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 _______________________________________________ crossfire-announce mailing list crossfire-announce@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-announce From Kimmo.Hoikka at Digia.com Tue Jun 27 02:15:16 2000 From: Kimmo.Hoikka at Digia.com (Kimmo Hoikka) Date: Thu Jan 13 18:03:16 2005 Subject: [CF List] Re: [CF:1372] new feature... References: <39567E2B.6B58A1D4@Digia.com> <3956FAD3.618AC3F0@scruznet.com> <3957B62E.F8289669@Digia.com> <39581E58.18205E92@scruznet.com> Message-ID: <39585483.9E0B6102@Digia.com> hmm... it seemed that the usekeys setting was not saved with normal save command, only when applied a bed of reality... voldsboks has forced reboots and that lost the setting, even though I save every 5 minutes or so. btw. could this lists reply-to address be changed to the new crossfire-list list so that changing to that would go smoothly? Mark Wedel wrote: > The is pretty strange then, as the change of keycode behaviour is all on the > server, and at the same time that change was made, the addition of the usekeys > command was also done. > > Kimmo Hoikka wrote: > > > > too bad the server doesn't seem to save the setting... at least not in > > voldsboks... > > > > Mark Wedel wrote: > > > > > Use the 'usekeys command to change the behaviour to the old behaviour. > > > > > > Kimmo Hoikka wrote: > > --------------------------------------------------------------------- > To submit a bug: http://bugzilla.real-time.com > To unsubscribe, e-mail: rte-crossfire-unsubscribe@listserv.real-time.com > For additional commands, e-mail: rte-crossfire-help@listserv.real-time.com -- .w w w. h o i k k a .c o m. .+ 3 5 8 4 0 7 3 8 0 7 4 7. .Eilen t?n??n oli huomenna. From erik at subnett.no Tue Jun 27 05:22:44 2000 From: erik at subnett.no (Erik Gjertsen) Date: Thu Jan 13 18:03:16 2005 Subject: [CF List] About the resurrection spells Message-ID: Hi, About the resurrection spells. Would it be possible to modify spellist.h to do something like: #ifndef RESURRECTION insert_old_stuff_with_resurrection_spells_with_bookchance_0; #else insert_resurrection_spells_with_reasonable_bookchance #endif ...without messing up spell enumeration? This might not be a terribly pretty solution, however it would allow resurrection spells to work out-of-the-box. ---[ erik gjertsen ]--------- - - - - - ---[ PGP: http://erik.subnett.no/pgp.txt ]- - - - From tanner at real-time.com Tue Jun 27 01:55:40 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:16 2005 Subject: [CF List] CF: Mailing list migration Message-ID: <20000627015540.U22840@real-time.com> I will be migrating rte-crossfire to a new mail server today 27-Jun-2000 at 02:00 CST. All your email addresses will go across with the migration. You will all receive a personal confirmation notice that your account has moved. If you do not receive this notification, PLEASE contact me directly at tanner@real-time.com. The current address of rte-crossfire@listserv.real-time.com will continue to work. But please use the new address crossfire-list@lists.real-time.com. Let me know if there are any problems. Thanks. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 - [you can put yourself on the announcement list only or unsubscribe altogether by sending an email stating your wishes to crossfire-request@ifi.uio.no] From bugs at real-time.com Tue Jun 27 02:10:01 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:03:16 2005 Subject: [CF List] Your Bugzilla buglist needs attention. Message-ID: <200006270710.e5R7A1331749@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-bugs@ifi.uio.no Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 From echter at informatik.uni-rostock.de Tue Jun 27 14:09:44 2000 From: echter at informatik.uni-rostock.de (Jan Echternach) Date: Thu Jan 13 18:03:16 2005 Subject: [CF List] Re: [CF:1371] Resurrection In-Reply-To: ; from erik@subnett.no on Sun, Jun 25, 2000 at 11:16:57PM -0100 References: Message-ID: <20000627210944.A4353@hokkaido.informatik.uni-rostock.de> On Sun, Jun 25, 2000 at 11:16:57PM -0100, Erik Gjertsen wrote: > I'm not sure if the resurrection/raise dead spells are properly > implemented. No books (type 93) ever seem to show up in stores, the spell > has a casting level of 200, and when creating a book with sp type 93, > reading it will only yield the message "The book is incomprehensible". Are you sure it has a level of 200? I think "raise dead" is level 10, "reincarnation" level 20, and "resurrection" level 25. They have a bookchance of 0, but you should be able to learn them through praying at an altar, provided the god you follow has attuned: restoration. -- Jan From peterm at tesla.EECS.Berkeley.EDU Tue Jun 27 14:40:38 2000 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:03:16 2005 Subject: [CF List] Re: [CF:1371] Resurrection In-Reply-To: Your message of "Tue, 27 Jun 2000 21:09:44 +0200." <20000627210944.A4353@hokkaido.informatik.uni-rostock.de> Message-ID: <200006271940.MAA31815@tesla.EECS.Berkeley.EDU> Jan is correct, at least in the CVS server code include/spellist.h. I just examined the code. Spell Level cost description raise dead 10 50 requires a corpse, exp*=.95 con-=2 resurrection 25 250 requires a corpse, exp*=.9 con-=1 reincarnation 20 150 no corpse, exp*=.8 These effects are clearly fubar, and not want I wanted when I wrote these spells. Reincarnation was supposed to be the most powerful/hardest. I'm changing it like this: raise dead 10 150 requires a corpse, exp*=.8 con-=2 resurrection 20 250 requires a corpse, exp*=.9 con-=1 reincarnation 25 350 no corpse, exp*=.95 Reincarnation is clearly the best spell, because no corpse is required. PeterM > On Sun, Jun 25, 2000 at 11:16:57PM -0100, Erik Gjertsen wrote: > > I'm not sure if the resurrection/raise dead spells are properly > > implemented. No books (type 93) ever seem to show up in stores, the spell > > has a casting level of 200, and when creating a book with sp type 93, > > reading it will only yield the message "The book is incomprehensible". > > Are you sure it has a level of 200? I think "raise dead" is level 10, > "reincarnation" level 20, and "resurrection" level 25. They have a > bookchance of 0, but you should be able to learn them through praying > at an altar, provided the god you follow has attuned: restoration. > > -- > Jan > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From erik at subnett.no Tue Jun 27 17:51:03 2000 From: erik at subnett.no (Erik Gjertsen) Date: Thu Jan 13 18:03:16 2005 Subject: [CF List] Re: [CF:1371] Resurrection In-Reply-To: <20000627210944.A4353@hokkaido.informatik.uni-rostock.de> Message-ID: On Tue, 27 Jun 2000, Jan Echternach wrote: > > I'm not sure if the resurrection/raise dead spells are properly > > implemented. No books (type 93) ever seem to show up in stores, the spell > > has a casting level of 200, and when creating a book with sp type 93, > > reading it will only yield the message "The book is incomprehensible". > > Are you sure it has a level of 200? I think "raise dead" is level 10, > "reincarnation" level 20, and "resurrection" level 25. They have a > bookchance of 0, but you should be able to learn them through praying > at an altar, provided the god you follow has attuned: restoration. You are right of course. I have no clue where I got those numbers - must've mixed up SP and LVL or something :) Anyways, I have now modified the level/exp and bookchance on my server and recompiled, seems to work nicely. Greetings go out to mr. "poorsucker" who had to die a *lot* while testing this :)) Rest assured, that it was all for a good cause. ---[ erik gjertsen ]--------- - - - - - ---[ PGP: http://erik.subnett.no/pgp.txt ]- - - - From erik at subnett.no Tue Jun 27 17:51:03 2000 From: erik at subnett.no (Erik Gjertsen) Date: Thu Jan 13 18:03:16 2005 Subject: [CF List] Re: [CF:1371] Resurrection In-Reply-To: <20000627210944.A4353@hokkaido.informatik.uni-rostock.de> Message-ID: On Tue, 27 Jun 2000, Jan Echternach wrote: > > I'm not sure if the resurrection/raise dead spells are properly > > implemented. No books (type 93) ever seem to show up in stores, the spell > > has a casting level of 200, and when creating a book with sp type 93, > > reading it will only yield the message "The book is incomprehensible". > > Are you sure it has a level of 200? I think "raise dead" is level 10, > "reincarnation" level 20, and "resurrection" level 25. They have a > bookchance of 0, but you should be able to learn them through praying > at an altar, provided the god you follow has attuned: restoration. You are right of course. I have no clue where I got those numbers - must've mixed up SP and LVL or something :) Anyways, I have now modified the level/exp and bookchance on my server and recompiled, seems to work nicely. Greetings go out to mr. "poorsucker" who had to die a *lot* while testing this :)) Rest assured, that it was all for a good cause. ---[ erik gjertsen ]--------- - - - - - ---[ PGP: http://erik.subnett.no/pgp.txt ]- - - - From peterm at tesla.EECS.Berkeley.EDU Tue Jun 27 14:55:13 2000 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:03:16 2005 Subject: [CF List] More on resurrection In-Reply-To: Your message of "Tue, 27 Jun 2000 12:40:38 PDT." <200006271940.MAA31815@tesla.EECS.Berkeley.EDU> Message-ID: <200006271955.MAA28730@tesla.EECS.Berkeley.EDU> It looks like the code in resurrection.c is so aged that it is completely unaware of skills. If someone cares, how about going through and fixing resurrection? Erik, if you want to modify how stuff works in server/resurrection.c, I'm willing to accept patches from you. The code is badly out of date and has suffered bit-rot. In particular, it won't suck experience from anything but the "global" experience counter, I believe. PeterM > Jan is correct, at least in the CVS server code include/spellist.h. > I just examined the code. > > Spell Level cost description > raise dead 10 50 requires a corpse, exp*=.95 con-=2 > resurrection 25 250 requires a corpse, exp*=.9 con-=1 > reincarnation 20 150 no corpse, exp*=.8 > > These effects are clearly fubar, and not want I wanted when > I wrote these spells. > > Reincarnation was supposed to be the most powerful/hardest. > > I'm changing it like this: > raise dead 10 150 requires a corpse, exp*=.8 con-=2 > resurrection 20 250 requires a corpse, exp*=.9 con-=1 > reincarnation 25 350 no corpse, exp*=.95 > > Reincarnation is clearly the best spell, because no corpse is required. > > PeterM > > > > > On Sun, Jun 25, 2000 at 11:16:57PM -0100, Erik Gjertsen wrote: > > > I'm not sure if the resurrection/raise dead spells are properly > > > implemented. No books (type 93) ever seem to show up in stores, the spell > > > has a casting level of 200, and when creating a book with sp type 93, > > > reading it will only yield the message "The book is incomprehensible". > > > > Are you sure it has a level of 200? I think "raise dead" is level 10, > > "reincarnation" level 20, and "resurrection" level 25. They have a > > bookchance of 0, but you should be able to learn them through praying > > at an altar, provided the god you follow has attuned: restoration. > > > > -- > > Jan > > _______________________________________________ > > crossfire-list mailing list > > crossfire-list@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-list > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From erik at subnett.no Tue Jun 27 18:07:17 2000 From: erik at subnett.no (Erik Gjertsen) Date: Thu Jan 13 18:03:16 2005 Subject: [CF List] More on resurrection In-Reply-To: <200006271955.MAA28730@tesla.EECS.Berkeley.EDU> Message-ID: On Tue, 27 Jun 2000, Peter Mardahl wrote: > Erik, if you want to modify how stuff works in server/resurrection.c, I'm > willing to accept patches from you. The code is badly out of date > and has suffered bit-rot. I will take a look at it and see what I can do. > In particular, it won't suck experience from anything but the "global" > experience counter, I believe. If I have understood it correctly, that was the purpose of PERM_DEATH. No XP drain and/or level loss, but if you manage to get resurrected you loose your stuff and quite a few skills? That's what seems to happen now, anyways. If there is any XP drain, it is marginal - and I feel it should be. Both having the XP drain of a NO_PERM_DEATH server and the hassle of having to resurrect, learn all the skills again and finding your stuff kinda makes dying a pain :) PERM_DEATH should probably have some advantages over NO_PERM_DEATH, shouldn't it? ---[ erik gjertsen ]--------- - - - - - ---[ PGP: http://erik.subnett.no/pgp.txt ]- - - - From mwedel at scruznet.com Tue Jun 27 22:16:27 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:16 2005 Subject: [CF List] Re: [CF:1388] Mailing list migration References: <20000627015540.U22840@real-time.com> Message-ID: <39596E0B.45AE70DF@scruznet.com> A few notes: Since the current ifi mailing lists are basically unmaintained, they will in theory work until someone over there notices it and disables them. However, these should not be used, and if you have a web site or any other documentation that refers to them, please update it. As far the rte-crossfire, I would suggest it should work as is for some limited amount of times as things get switched over (maybe until end of July), then get switched to bounce a message back the sender with the new lists and a brief description and say to use that instead. I'm just a little fearful that if rte-crossfire continues to exist/operate forever, people won't ever see the need to use the subdivided lists. perhaps if possible, around mid july, have it start bouncing back a message describing the different lists, but still forward to the rte-crossfire, then end of july have that forwarding stop. Bob Tanner wrote: > > I will be migrating rte-crossfire to a new mail server today 27-Jun-2000 at > 02:00 CST. > > All your email addresses will go across with the migration. > > You will all receive a personal confirmation notice that your account has > moved. If you do not receive this notification, PLEASE contact me directly at > tanner@real-time.com. > > The current address of rte-crossfire@listserv.real-time.com will continue to > work. But please use the new address crossfire-list@lists.real-time.com. > > Let me know if there are any problems. > > Thanks. > > -- > Bob Tanner | Phone : (612)943-8700 > http://www.mn-linux.org | Fax : (612)943-8500 > Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 > > --------------------------------------------------------------------- > To submit a bug: http://bugzilla.real-time.com > To unsubscribe, e-mail: rte-crossfire-unsubscribe@listserv.real-time.com > For additional commands, e-mail: rte-crossfire-help@listserv.real-time.com From mwedel at scruznet.com Tue Jun 27 22:30:49 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:16 2005 Subject: [CF List] About the resurrection spells References: Message-ID: <39597169.1658D3F3@scruznet.com> That would actually work out OK. Not too messy - fortunately the three spells are all together in the spellist.h file, so only one ifdef of that nature is needed. Erik Gjertsen wrote: > > Hi, > > About the resurrection spells. Would it be possible to modify spellist.h > to do something like: > > #ifndef RESURRECTION > insert_old_stuff_with_resurrection_spells_with_bookchance_0; > #else > insert_resurrection_spells_with_reasonable_bookchance > #endif > > ...without messing up spell enumeration? This might not be a terribly > pretty solution, however it would allow resurrection spells to work > out-of-the-box. > > ---[ erik gjertsen ]--------- - - - - - > ---[ PGP: http://erik.subnett.no/pgp.txt ]- - - - > > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From scott at campy.tymnet.com Tue Jun 27 22:30:31 2000 From: scott at campy.tymnet.com (scott) Date: Thu Jan 13 18:03:16 2005 Subject: [CF List] Re: [CF:1388] Mailing list migration Message-ID: <200006280330.VAA02923@moots.tymnet.com> Personally I do not understand the need for basically renaming rte-crossfire@listserv.real-time.com to the new name. The new name is hardly obvious since "crossfire-list" could be a list of servers or some other listing of crossfire resources. The original "rte-crossfire" made more sense since 'rte' was just some silly prefix apparently required by the site and "crossfire" clearly indicated it was the main mailing list regarding crossfire. If the name must be changed to anything then "crossfire@listserv.real-time.com" is clear and succient. In the current frenzy of redoing mailing lists that clarity apparently disqualified that name from consideration. sdw >Delivered-To: rte-crossfire@listserv.real-time.com >Date: Tue, 27 Jun 2000 20:16:27 -0700 >From: Mark Wedel >X-Accept-Language: en >Mime-Version: 1.0 >To: rte-crossfire@listserv.real-time.com >Content-Transfer-Encoding: 7bit >Subject: [CF List] Re: [CF:1388] Mailing list migration >X-Beenthere: crossfire-list@lists.real-time.com >X-Mailman-Version: 2.0beta2 >List-Id: Crossfire Discussion Mailing List > > > A few notes: > > Since the current ifi mailing lists are basically unmaintained, they will in >theory work until someone over there notices it and disables them. However, >these should not be used, and if you have a web site or any other documentation >that refers to them, please update it. > > As far the rte-crossfire, I would suggest it should work as is for some limited >amount of times as things get switched over (maybe until end of July), then get >switched to bounce a message back the sender with the new lists and a brief >description and say to use that instead. I'm just a little fearful that if >rte-crossfire continues to exist/operate forever, people won't ever see the need >to use the subdivided lists. perhaps if possible, around mid july, have it >start bouncing back a message describing the different lists, but still forward >to the rte-crossfire, then end of july have that forwarding stop. > > >Bob Tanner wrote: >> >> I will be migrating rte-crossfire to a new mail server today 27-Jun-2000 at >> 02:00 CST. >> >> All your email addresses will go across with the migration. >> >> You will all receive a personal confirmation notice that your account has >> moved. If you do not receive this notification, PLEASE contact me directly at >> tanner@real-time.com. >> >> The current address of rte-crossfire@listserv.real-time.com will continue to >> work. But please use the new address crossfire-list@lists.real-time.com. >> >> Let me know if there are any problems. >> >> Thanks. >> >> -- >> Bob Tanner | Phone : (612)943-8700 >> http://www.mn-linux.org | Fax : (612)943-8500 >> Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 >> >> --------------------------------------------------------------------- >> To submit a bug: http://bugzilla.real-time.com >> To unsubscribe, e-mail: rte-crossfire-unsubscribe@listserv.real-time.com >> For additional commands, e-mail: rte-crossfire-help@listserv.real-time.com >_______________________________________________ >crossfire-list mailing list >crossfire-list@lists.real-time.com >https://mailman.real-time.com/mailman/listinfo/crossfire-list From mwedel at scruznet.com Tue Jun 27 23:29:18 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:17 2005 Subject: [CF List] Re: [CF:1372] new feature... References: <39567E2B.6B58A1D4@Digia.com> <3956FAD3.618AC3F0@scruznet.com> <3957B62E.F8289669@Digia.com> <39581E58.18205E92@scruznet.com> <39585483.9E0B6102@Digia.com> Message-ID: <39597F1E.E3B1F5D1@scruznet.com> Actually, the usekeys setting was not being saved at all. I have made the change in the CVS repository so that the usekeys setting is saved with the character file. More than likely, this is a player setting (however, the server is the one that does the work). AT some point, some work should be done with the client storing values like this and then sending them to the server at startup, but that isn't that high a priority item. Kimmo Hoikka wrote: > > hmm... it seemed that the usekeys setting was not saved with normal save command, > only when applied a bed of reality... voldsboks has forced reboots and that lost > the setting, even though I save every 5 minutes or so. > > btw. could this lists reply-to address be changed to the new crossfire-list list > so that changing to that would go smoothly? > > Mark Wedel wrote: > > > The is pretty strange then, as the change of keycode behaviour is all on the > > server, and at the same time that change was made, the addition of the usekeys > > command was also done. > > > > Kimmo Hoikka wrote: > > > > > > too bad the server doesn't seem to save the setting... at least not in > > > voldsboks... > > > > > > Mark Wedel wrote: > > > > > > > Use the 'usekeys command to change the behaviour to the old behaviour. > > > > > > > > Kimmo Hoikka wrote: > > > > --------------------------------------------------------------------- > > To submit a bug: http://bugzilla.real-time.com > > To unsubscribe, e-mail: rte-crossfire-unsubscribe@listserv.real-time.com > > For additional commands, e-mail: rte-crossfire-help@listserv.real-time.com > > -- > .w w w. h o i k k a .c o m. > .+ 3 5 8 4 0 7 3 8 0 7 4 7. > .Eilen t?n??n oli huomenna. > > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From mwedel at scruznet.com Wed Jun 28 00:03:25 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:17 2005 Subject: [CF List] Re: [CF:1385] Bug in 0.95.6: 'drop n whatever reports "Nothing to drop" References: <200006270221.WAA21668@granger.mail.mindspring.net> Message-ID: <3959871D.1DD4C683@scruznet.com> Frank McKenney wrote: > Recreation: I create a new character ('Dave the human'), enable > scrolling, and try to drop one of some object I have multiple copies of. > For example, if I have 23 silver coins, I enter: > > 'drop 1 silver and the system responds with > Nothing to drop > > Is anyone else seeing this problem? > > Not only is this frequently inconvenient, I would _swear_ that it was > working correctly the first time I installed CF 0.95.6. There is, as > with all "bugs", the chance I didn't clear out _something_ that I should > have, so here are the steps I followed: The above has been fixed in the CVS repository. IT is highly doubtful it originally worked when you first installed it. However, the mouse drop functionality (which is probably what most people use) has been working fine for quite a while, so maybe you used that. From Kimmo.Hoikka at Digia.com Wed Jun 28 00:14:27 2000 From: Kimmo.Hoikka at Digia.com (Kimmo Hoikka) Date: Thu Jan 13 18:03:17 2005 Subject: [CF List] HallofQuests Message-ID: <395989B3.77933B71@Digia.com> the random map quest for the mushroom appears to be broken since the altar at /city/misc/HallofQuests reuires a bunion?? and the /peterm/quests/mushroom_quest has no such item. no map in the game has such item. the final map has one blue mushroom but it is normal mushroom_3 and a few mushroom_1 and _2. Also the random maps seem to crash every second boot when you enter it and after that the dont work until next boot. /city/misc/HallofQuests ... arch altar_trigger slaying bunion food 1 x 23 y 13 invisible 1 connected 7 end arch magic_mouth msg Drop the mushroom here. endmsg x 23 y 13 end ... -- .w w w. h o i k k a .c o m. .+ 3 5 8 4 0 7 3 8 0 7 4 7. .Eilen t?n??n oli huomenna. From mwedel at scruznet.com Wed Jun 28 01:21:12 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:17 2005 Subject: [CF List] Re: [CF:1366] CF 0.95.6: Character lost at sea, odd behavior following recovery References: <200006250109.VAA20630@smtp10.atl.mindspring.net> Message-ID: <39599958.54CC166@scruznet.com> Frank McKenney wrote: > > - 'Inventory:' items are no longer pluralized... until I drop them. > Once an item moves ot the 'You see:' window, it gets pluralized. > If I pick it up again, the plural vanishes. E.g., > > "20 gold coin" -> "20 gold coins" -> "20 gold coin" This is more because the client is supposed to handle the pluralization of words. This was done somewhat to conserve bandwidth (save transmitting the names when the only thing that has changed is the number.) However, the client doesn't do that right now. I think at one time I had attempted to write the client in to do that, but it did it incorrectly on enough items it appeared more annoying than the usefulness gained. A better approach would be to only send the name when the number of items change which also causes a change in the plural form (basically, if old or number of items =1, resend name). The problem with that approach is that the function that updates the client doesn't know the old value, and even many calling functions don't explicity know the value. I suppose an old_nrof field could be added to the object structure and use that to know if we should update the name or not. > > - When picking up items, the 'You see:' window will frequently reset > itself to display the top item on the stack rather than the items > surrounding the on(s) I picked up. Do you mean the scroll bar resets, or something different? Which client are you using? > > - The client dumps some new messages to stdout/stderr (I can't tell > which, since I'm capturing both): > > Playing on server type Crossfire Server > > Couldn't open /dev/dsp: No such device the /dev/dsp means it didn't find a sound card/driver for your system. Not critical - sounds are strictly optional and not used all that extensively anyways. > Could not find match for a sacred text of turn undead > Could not find match for a holy symbol Harmless but annoying. The client tries to sort items of a similar type together (so all your weapons are together, all your armor, etc). To do this, it parses the item_types file from which it makes it classifications. Not all names are in that file - especially as new items are added. > Wont send command search - window oversized 186 175 > Wont send command search - window oversized 189 178 > ---etc---etc---etc--- > Wont send command search - window oversized 236 225 > Wont send command search - window oversized 236 225 > Wont send command search - window oversized 236 225 I'll remove those warnings. With the split, it is theoretically possible for any number of commands to get cached by the server if you type them quickly or the character has a very slow speed. In order to keep a bit better interactive performance and not have the server get too far ahead, they use a mechanism so that if the client has sent so many more commands than the server has yet to process, the client won't send more commands to the server - that is what the above descibes. this can really happend if the key repeat rate on your system is pretty fast - each key generates a command to send to the server, and if you hold that key down, it is very easy for the client to have sent hundreds of commands to the server that have yet to be processed. This mechanism is to try and limit that to a reasonable number. > 2x Got update_item command for item we don't have (5794) > 2x Got update_item command for item we don't have (5908) > 2x Got update_item command for item we don't have (5908) > 2x Got update_item command for item we don't have (5794) Those are more a problem/mystery. IT basically means that the server believes the client has some object that the client does not think it has. The cause should be tracked down and fixed, since it means the client & server are not in a consistent state. My guess on the cause of these is that an object in the players inventory has changed its tag value because it merged with something else, but the client still thinks it has the old tag value. IT also means that try to access this object on the client won't work because the server won't claim any knowledge of it. From peterm at tesla.EECS.Berkeley.EDU Wed Jun 28 01:19:45 2000 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:03:17 2005 Subject: [CF List] HallofQuests In-Reply-To: Your message of "Wed, 28 Jun 2000 08:14:27 +0300." <395989B3.77933B71@Digia.com> Message-ID: <200006280619.XAA21489@tesla.EECS.Berkeley.EDU> It worked when last I tested it. "bunion" is just the lock code for the altar. You've got to find the special mushrooms which grow as described. PeterM > the random map quest for the mushroom appears to be broken since the > altar at /city/misc/HallofQuests reuires a bunion?? and the > /peterm/quests/mushroom_quest has no such item. no map in the game has > such item. the final map has one blue mushroom but it is normal > mushroom_3 and a few mushroom_1 and _2. > > Also the random maps seem to crash every second boot when you enter it > and after that the dont work until next boot. > > /city/misc/HallofQuests > ... > arch altar_trigger > slaying bunion > food 1 > x 23 > y 13 > invisible 1 > connected 7 > end > arch magic_mouth > msg > Drop the mushroom here. > endmsg > x 23 > y 13 > end > ... > > > > > > -- > .w w w. h o i k k a .c o m. > .+ 3 5 8 4 0 7 3 8 0 7 4 7. > .Eilen tänään oli huomenna. > > > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From scott at campy.tymnet.com Wed Jun 28 01:40:40 2000 From: scott at campy.tymnet.com (scott) Date: Thu Jan 13 18:03:17 2005 Subject: [CF List] Re: [CF:1366] CF 0.95.6: Character lost at sea, odd behavior following recovery Message-ID: <200006280640.AAA02971@moots.tymnet.com> >Date: Tue, 27 Jun 2000 23:21:12 -0700 >From: Mark Wedel > >Frank McKenney wrote: >> >> - 'Inventory:' items are no longer pluralized... until I drop them. >> Once an item moves ot the 'You see:' window, it gets pluralized. >> If I pick it up again, the plural vanishes. E.g., >> >> "20 gold coin" -> "20 gold coins" -> "20 gold coin" > > This is more because the client is supposed to handle the pluralization of >words. This was done somewhat to conserve bandwidth (save transmitting the >names when the only thing that has changed is the number.) > > However, the client doesn't do that right now. I think at one time I had >attempted to write the client in to do that, but it did it incorrectly on enough >items it appeared more annoying than the usefulness gained. > > A better approach would be to only send the name when the number of items >change which also causes a change in the plural form (basically, if old or >number of items =1, resend name). The problem with that approach is that the >function that updates the client doesn't know the old value, and even many >calling functions don't explicity know the value. I suppose an old_nrof field >could be added to the object structure and use that to know if we should update >the name or not. > That seems like a terrible approach. I think it makes far more sense to approach it similar to that for images. Image names are sent by the server and if the client doesn't have that image then client requests it from the server. Object name should be sent by server and if client doesn't know the plural of that name then it requests the plural name from the server. Client should quickly be able to cache every plural name. The artifacts file would thus have new option "plural" which is the name of the plural form of the object. It would default to merely adding an 's' to the singular form of the object. Thus, only irregular plural items would need to have the plural form specified. This approach also allows the client to know that a single gold coin is the same item type as "gold coins" since client knows them as being the same item name but with different display names. Also, this approach allows current clients to continue unchanged while new clients know to ask the server for the plural name. sdw From mwedel at scruznet.com Wed Jun 28 02:05:58 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:17 2005 Subject: [CF List] Re: [CF:1366] CF 0.95.6: Character lost at sea, odd behavior following recovery References: <200006280640.AAA02971@moots.tymnet.com> Message-ID: <3959A3D6.618716D2@scruznet.com> scott wrote: > That seems like a terrible approach. I think it makes far more sense > to approach it similar to that for images. Image names are sent by > the server and if the client doesn't have that image then client requests > it from the server. Object name should be sent by server and if client > doesn't know the plural of that name then it requests the plural name > from the server. Client should quickly be able to cache every plural > name. The artifacts file would thus have new option "plural" which > is the name of the plural form of the object. It would default to merely > adding an 's' to the singular form of the object. Thus, only irregular > plural items would need to have the plural form specified. You can do this on a object by object basis in the players inventory. However, unlike the images were names are constant, object names are much more dynamic. For example, there is no 'wand of fireballs' listed in the archetypes - rather, this is an item name that is generated at runtime. Item names can even change in the players inventory as more information is found out. For example, unidentified potions are just named 'potion(s)'. When you get them identified, they may then become 'potions of strength'. The end result would then be that client would have to see this name change and know that its current cached result for the singular of the item is no longer accurate ('potion'). A simpler approach, which would break compatibilty some, would be to just always send both the singular and plural version of the name whenever we send the name for something in the inventory. That way, the client never needs to request anything of have to worry about having an incorrectly cached entry. And this would not even be that hard to do - you could check the client version number and only in recent versions do this. Don't change the protocol, but instead add some character that would never occur in the item names as a string seperator (say control A). So even if a client does claim to support this but doesn't really, it will just have slightly strange item names and would not completely blow up. Fortunately, not too many places send the item names (login, and some things that change state - looking for UPD_NAME, I see it in apply.c (probably for enchanting items), gods.c, and spell_effect.c (identify & the like). So it wouldn't suck up that much more bandwidth. From bugs at real-time.com Wed Jun 28 02:10:02 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:03:17 2005 Subject: [CF List] Your Bugzilla buglist needs attention. Message-ID: <200006280710.e5S7A2w08784@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-bugs@ifi.uio.no Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 From Kimmo.Hoikka at Digia.com Wed Jun 28 04:21:50 2000 From: Kimmo.Hoikka at Digia.com (Kimmo Hoikka) Date: Thu Jan 13 18:03:17 2005 Subject: [CF List] Re: Your Bugzilla buglist needs attention. References: <200006020710.e527A3q06226@crusader.real-time.com> Message-ID: <3959C3AE.19462D25@Digia.com> could the bugzilla be changed to send the mails to the correct mailinglist? it still seems to send to ifi.uio.no bugs@real-time.com wrote: > [This e-mail has been automatically generated.] > > You have one or more bugs assigned to you in the Bugzilla > bugsystem (http://bugzilla.real-time.com/) that require > attention. > > All of these bugs are in the NEW state, and have not been touched > in 7 days or more. You need to take a look at them, and > decide on an initial action. > > Generally, this means one of three things: > > (1) You decide this bug is really quick to deal with (like, it's INVALID), > and so you get rid of it immediately. > (2) You decide the bug doesn't belong to you, and you reassign it to someone > else. (Hint: if you don't know who to reassign it to, make sure that > the Component field seems reasonable, and then use the "Reassign bug to > owner of selected component" option.) > (3) You decide the bug belongs to you, but you can't solve it this moment. > Just use the "Accept bug" command. > > To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): > > http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-bugs@ifi.uio.no > > Or, you can use the general query page, at > http://bugzilla.real-time.com/query.cgi. > > Appended below are the individual URLs to get to all of your NEW bugs that > haven't been touched for a week or more. > > You will get this message once a day until you've dealt with these bugs! > > http://bugzilla.real-time.com/show_bug.cgi?id=14 > > --------------------------------------------------------------------- > To submit a bug: http://bugzilla.real-time.com > To unsubscribe, e-mail: rte-crossfire-unsubscribe@listserv.real-time.com > For additional commands, e-mail: rte-crossfire-help@listserv.real-time.com -- Digital Information Architects Inc. Digia Oy Kimmo Hoikka Software engineer / Epoc www.digia.com mmm.digia.com From tanner at real-time.com Wed Jun 28 10:04:15 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:17 2005 Subject: [CF List] Your Bugzilla buglist needs attention. In-Reply-To: <200006280710.e5S7A2w08784@crusader.real-time.com>; from bugs@real-time.com on Wed, Jun 28, 2000 at 02:10:02AM -0500 References: <200006280710.e5S7A2w08784@crusader.real-time.com> Message-ID: <20000628100415.A20629@real-time.com> Argh. Sorry, I have bugzilla configured wrong. I'll fix this. Quoting bugs@real-time.com (bugs@real-time.com): > [This e-mail has been automatically generated.] > > You have one or more bugs assigned to you in the Bugzilla > bugsystem (http://bugzilla.real-time.com/) that require > attention. > > All of these bugs are in the NEW state, and have not been touched > in 7 days or more. You need to take a look at them, and > decide on an initial action. > > Generally, this means one of three things: > > (1) You decide this bug is really quick to deal with (like, it's INVALID), > and so you get rid of it immediately. > (2) You decide the bug doesn't belong to you, and you reassign it to someone > else. (Hint: if you don't know who to reassign it to, make sure that > the Component field seems reasonable, and then use the "Reassign bug to > owner of selected component" option.) > (3) You decide the bug belongs to you, but you can't solve it this moment. > Just use the "Accept bug" command. > > To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): > > http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-bugs@ifi.uio.no > > Or, you can use the general query page, at > http://bugzilla.real-time.com/query.cgi. > > Appended below are the individual URLs to get to all of your NEW bugs that > haven't been touched for a week or more. > > You will get this message once a day until you've dealt with these bugs! > > http://bugzilla.real-time.com/show_bug.cgi?id=18 > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From norbert.irmer at heim9.tu-clausthal.de Wed Jun 28 11:40:07 2000 From: norbert.irmer at heim9.tu-clausthal.de (Norbert Irmer) Date: Thu Jan 13 18:03:17 2005 Subject: [CF List] Your Bugzilla buglist needs attention. References: <200006280710.e5S7A2w08784@crusader.real-time.com> <20000628100415.A20629@real-time.com> Message-ID: <395A2A67.EC4CFA2F@heim9.tu-clausthal.de> Pheeew, thanks a lot ! This was starting to get onto my nerves :)) Bob Tanner wrote: > > Argh. Sorry, I have bugzilla configured wrong. I'll fix this. > > Quoting bugs@real-time.com (bugs@real-time.com): > > [This e-mail has been automatically generated.] > > > > You have one or more bugs assigned to you in the Bugzilla > > bugsystem (http://bugzilla.real-time.com/) that require > > attention. > > > > All of these bugs are in the NEW state, and have not been touched > > in 7 days or more. You need to take a look at them, and > > decide on an initial action. > > > > Generally, this means one of three things: > > > > (1) You decide this bug is really quick to deal with (like, it's INVALID), > > and so you get rid of it immediately. > > (2) You decide the bug doesn't belong to you, and you reassign it to someone > > else. (Hint: if you don't know who to reassign it to, make sure that > > the Component field seems reasonable, and then use the "Reassign bug to > > owner of selected component" option.) > > (3) You decide the bug belongs to you, but you can't solve it this moment. > > Just use the "Accept bug" command. > > > > To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): > > > > http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-bugs@ifi.uio.no > > > > Or, you can use the general query page, at > > http://bugzilla.real-time.com/query.cgi. > > > > Appended below are the individual URLs to get to all of your NEW bugs that > > haven't been touched for a week or more. > > > > You will get this message once a day until you've dealt with these bugs! > > > > http://bugzilla.real-time.com/show_bug.cgi?id=18 > > _______________________________________________ > > crossfire-list mailing list > > crossfire-list@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-list > > -- > Bob Tanner | Phone : (612)943-8700 > http://www.mn-linux.org | Fax : (612)943-8500 > Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 > > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list -- email: norbert.irmer@heim9.tu-clausthal.de web: http://gul.sourceforge.net From frank_mckenney at mindspring.com Wed Jun 28 19:08:53 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:17 2005 Subject: [CF List] Re: [CF:1385] Bug in 0.95.6: 'drop n whatever reports "Nothing to drop" References: <200006270221.WAA21668@granger.mail.mindspring.net> Message-ID: <200006282308.TAA21162@granger.mail.mindspring.net> Mark, Thank you for taking the time to respond. I'm taking the liberty of replying to you via the new mailing list instead of the old. > Frank McKenney wrote: --snip-- > > For example, if I have 23 silver coins, I enter: > > > > 'drop 1 silver and the system responds with > > Nothing to drop --snip-- > The above has been fixed in the CVS repository. Thanks. That's good to hear. > ... IT is highly doubtful it > originally worked when you first installed it. Thinking back, most of my initial testing with 0.95.6 was done with the 0.95.5(?) client. That may be the "working" instance I recall. (I'm taking _much_ better notes now (;-)). > ... However, the mouse drop > functionality (which is probably what most people use) has been working > fine for > quite a while, so maybe you used that. No, I do recall using 'drop x whatever (I don't know of any way to do a "partial" drop with the mouse, but then, I'm still pretty much a novice at this). How do things go from here, release-wise? That is, will there be a "fixed" 0.95.6 release in the near future? Or will fixes simply be rolled into the CVS tree and some future snapshot released as 0.95.7 or something? Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From frank_mckenney at mindspring.com Wed Jun 28 19:08:55 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:17 2005 Subject: [CF List] Re: [CF:1366] CF 0.95.6: Character lost at sea, odd behavior following recovery References: <200006250109.VAA20630@smtp10.atl.mindspring.net> Message-ID: <200006282308.TAA03466@granger.mail.mindspring.net> > Frank McKenney wrote: > > > > - 'Inventory:' items are no longer pluralized... until I drop them. > > Once an item moves ot the 'You see:' window, it gets pluralized. > > If I pick it up again, the plural vanishes. E.g., > > > > "20 gold coin" -> "20 gold coins" -> "20 gold coin" > > This is more because the client is supposed to handle the pluralization of > words. This was done somewhat to conserve bandwidth (save transmitting the > names when the only thing that has changed is the number.) > > However, the client doesn't do that right now. Okay. So this was not a result of somethign __I did during installation. Got it. --snip-- > > - When picking up items, the 'You see:' window will frequently reset > > itself to display the top item on the stack rather than the items > > surrounding the on(s) I picked up. > > Do you mean the scroll bar resets, or something different? Which client are > you using? Sorry, thought I included that in my original message. Client and Server 0.95.6. Assume you walk up to a location with your typical post-combat Pile-o-Junque(tm). The top item in the window is initially the first item on the list, but you scroll down looking for "interesting" stuff. Let's say there are three items in a row you want to pick up. You pick up the first, it pops into your 'Inventory:', and the 'You see:' window gets redrawn at the same point in the list, but without the item you just picked up. So far, all is normal, working as expected. Then you mouse-click on the _second_ item. It, too, gets transferred to your inventory, and the 'You see:' window gets redrawn. _This_ time, however, the top item in the 'You see:' window is the item(s) on top of the Pile-o-Junque. So... you scroll back down, finally relocate the second item, and pick _it_ up. Zap! The 'You see:' window is redrawn to show the _top_ of the Pile-o-Junque(tm), and you've lost your place again. This is one example. The window "reset" may occur after you pick up the first item, or not until later - or not at all. It does occur fairly frequently, however. > > - The client dumps some new messages to stdout/stderr (I can't tell > > which, since I'm capturing both): > > > > Playing on server type Crossfire Server > > > > Couldn't open /dev/dsp: No such device > > the /dev/dsp means it didn't find a sound card/driver for your system. Not > critical - sounds are strictly optional and not used all that extensively > anyways. Right. I just wanted to offer an "anchor" so you had some idea of where the mesages were appearing. > > Could not find match for a sacred text of turn undead > > Could not find match for a holy symbol > > Harmless but annoying. The client tries to sort items of a similar type > together (so all your weapons are together, all your armor, etc). To do this, > it parses the item_types file from which it makes it classifications. Not all > names are in that file - especially as new items are added. Okay. Not a problem for me as long as it doesn't represent some insidious corruption problem (;-). When one installs a "released" version of something one does not know well, one tends to assume any oddities are due to one's own clumsiness. > > Wont send command search - window oversized 186 175 > > Wont send command search - window oversized 189 178 > > ---etc---etc---etc--- > > I'll remove those warnings. With the split, it is theoretically possible for > any number of commands to get cached by the server if you type them quickly or > the character has a very slow speed. In order to keep a bit better interactive > performance and not have the server get too far ahead, they use a mechanism so > that if the client has sent so many more commands than the server has yet to > process, the client won't send more commands to the server - that is what the > above descibes. Does the presence of these messages indicate that commands _were_ getting lost? Or just that I was approaching some limit? I ask because of another "bug?" I was about to report regarding lost input. Let's say I have a key (say 'P') defined to 'use_skill praying' five times and I press 'P' four times quickly. Under 0.93,x, this would advance my 'Grace' value, if possible, by 20. With 0.95.6 this will often give me less than 20, and it _felt_ like this was worse in situations with some activity (animation, e.g. of your favorite horde-of-choice). > this can really happend if the key repeat rate on your system is pretty fast - > each key generates a command to send to the server, and if you hold that key > down, it is very easy for the client to have sent hundreds of commands to the > server that have yet to be processed. This mechanism is to try and limit that > to a reasonable number. I have been careful in most cases to use tap-tap-tap so I have some feel for how many keystrokes I'm sending. What you are describing sounds like a "command buffer full" situation and the server deciding to ignore input until things "calm down" a bit. My server/client machine is a lowly 486DX4-100 which ran 0.93.x just fine, but I realize Much Has Changed Since Then. It may simply be that my machine doesn't have the horsepower CF 0.95.6 requires. Still, I'd like to see how far I can get with it (see also: "glutton for punishment" (;-)). Is there a "control knob" somewhere I can tweak to control how/when the server makes this decision? > > 2x Got update_item command for item we don't have (5794) ---snip near-duplicates--- > Those are more a problem/mystery. IT basically means that the server believes > the client has some object that the client does not think it has. The cause > should be tracked down and fixed, since it means the client & server are not in > a consistent state. My guess on the cause of these is that an object in the > players inventory has changed its tag value because it merged with something > else, but the client still thinks it has the old tag value. IT also means that > try to access this object on the client won't work because the server won't > claim any knowledge of it. It sounds like these messages could be occurring because of the 'Arrows Of Mystery' (;-) problem I reported at: http://bugzilla.real-time.com/show_bug.cgi?id=27 Can't drop them, can't sell them, can't fire them... um. Come to think of it, I never _did_ try _firing_ one (;-). ... I realize this is taking up a bit of your time. Is there a list somewhere of these little 'quirks' in 0.95.6 that I can check before posting here and "Bugzilla"? Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From bugs at real-time.com Wed Jun 28 20:40:46 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:03:17 2005 Subject: [CF List] [Bug 17] Changed - Tobias Tower in Santo Domionion Traps Users Message-ID: <200006290140.e5T1ekp14750@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=17 *** shadow/17 Fri Jun 23 04:05:21 2000 --- shadow/17.tmp.14747 Wed Jun 28 20:40:46 2000 *************** *** 3,10 **** Version: 0.95.5 Platform: PC OS/Version: Linux ! Status: ASSIGNED ! Resolution: Severity: normal Priority: P2 Component: maps --- 3,10 ---- Version: 0.95.5 Platform: PC OS/Version: Linux ! Status: RESOLVED ! Resolution: FIXED Severity: normal Priority: P2 Component: maps From mwedel at scruznet.com Wed Jun 28 22:54:03 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:17 2005 Subject: [CF List] Re: [CF:1385] Bug in 0.95.6: 'drop n whatever reports "Nothing to drop" References: <200006270221.WAA21668@granger.mail.mindspring.net> <200006282308.TAA21162@granger.mail.mindspring.net> Message-ID: <395AC85B.772D0683@scruznet.com> Frank McKenney wrote: > > How do things go from here, release-wise? That is, will there be a > "fixed" 0.95.6 release in the near future? Or will fixes simply be > rolled into the CVS tree and some future snapshot released as 0.95.7 or > something? Once something is released, it is never re-released - that creates too much confusion (is that 0.95.6 patched or original?) Patches are not really being done either - if you want it with all the latest patches, grabbing a cvs snapshot is the way to go. At some point in the future, probably another or two, there will be an 0.95.7 release. From John.Cater at monash.edu.au Wed Jun 28 16:02:01 2000 From: John.Cater at monash.edu.au (John Cater) Date: Thu Jan 13 18:03:17 2005 Subject: [CF List] PNG Images Message-ID: <395A67C9.41C6@monash.edu.au> I have just downloaded the latest versions of the server and client from the cvs tree and got png support from gcfclient. All I can say is - Wow. I LOVE the large size of the images, and some of the new images are BRILLIANT, particularly dwarves, guards etc. Who did all this? Are they going to finish the rest? There are still some of my favourites to be touched though (Royal Guards, Half-Orcs etc). And it would be great to have the complete world looking this good. Some of the downlights though are : the ocean, lakes and magic shops. Also, the black border around many of the items is annoying. Is there any possibility of running : crossedit -png? Once more images are made nicer, I would recommend that png become our default image format. How can I easily edit the images myself if I want to help? Johnc & Co. -- John Cater From mwedel at scruznet.com Wed Jun 28 23:57:39 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:18 2005 Subject: [CF List] PNG Images References: <395A67C9.41C6@monash.edu.au> Message-ID: <395AD743.2E1B5DB1@scruznet.com> John Cater wrote: > > I have just downloaded the latest versions of the server and client from > the cvs tree and got png support from gcfclient. > > All I can say is - Wow. I LOVE the large size of the images, and some > of the new images are BRILLIANT, particularly dwarves, guards etc. > > Who did all this? Are they going to finish the rest? David Sundqvist did the work. I believe at the time, all were done, but some additional images have been added since he did the work. > > Some of the downlights though are : the ocean, lakes and magic shops. > Also, the black border around many of the items is annoying. I'll have to look at them. i noticed that at least on my system, imlib does not render all png's properly - this is definately a problem with imlib, as if I use a simple demo program from their website, it is not rendered properly, but other tools like gimp and imagemagick do the right thing. All our built on top of png, so I don't think it is a problem with the underlying png library. > > Is there any possibility of running : > crossedit -png? As of right now, no. It probably would not be really hard to add, but I haven't had time to really look at all that in crossedit. Certainly, all the hardcoded 24 image sizes would need to be redone to be image_size (24 or 32 depending on image type being used), and that also would correspond for things like map tiling and scroll lists. The loader could probably be taken pretty easily from the client the server code (which parses the png file) > > Once more images are made nicer, I would recommend that png become our > default image format. > > How can I easily edit the images myself if I want to help? If you have a tool that reads them, not too hard. Gimp will do it, and I believe some non unix tools like photoshop also supports png. What I would really like (if anyone really knows the png stuff) is a png -> X11 loader without all the extra buggy stuff imlib tosses in. There are a few reasons for this: 1) As describe above, imlib doesn't do all images correctly. 2) There is no way I could find to render a png already in memory to a pixmap. There is a function in imlib that will I think do that, but it just writes it to temp file first, which seems really stupid. 3) Imlib adds lots of functionality that is not needed, and also adds another library dependency, which makes it a bit less user friendly than say Xpm (which while not standard, you can at least find precompiled version of the Xpm library for a wide variety of platforms, like solaris.) From peterm at tesla.EECS.Berkeley.EDU Thu Jun 29 00:38:31 2000 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:03:18 2005 Subject: [CF List] PNG Images Message-ID: <200006290538.WAA32201@tesla.EECS.Berkeley.EDU> Hmm, I think a lot of the images are suffering from "bigger is better" syndrome. A lot of the older images were *really* good. In the PNG system, they're worse, because they've been scaled up. A lot of them would still look very good if they were just copied and centered and not magnified. PeterM From tanner at real-time.com Thu Jun 29 00:39:49 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:18 2005 Subject: [CF List] testing Message-ID: <20000629003949.A19523@real-time.com> Testing. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From peterm at tesla.EECS.Berkeley.EDU Thu Jun 29 00:56:15 2000 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:03:18 2005 Subject: [CF List] PNG Images Message-ID: <200006290556.WAA24596@tesla.EECS.Berkeley.EDU> One thing I could never figure out was how to use the 32x32 xpms? Also, how do I use The Gimp to pixelwise-edit the images? PeterM From John.Cater at monash.edu.au Wed Jun 28 18:12:31 2000 From: John.Cater at monash.edu.au (John Cater) Date: Thu Jan 13 18:03:18 2005 Subject: [CF List] PNG Images References: <200006290556.WAA24596@tesla.EECS.Berkeley.EDU> Message-ID: <395A865F.41C6@monash.edu.au> > Also, how do I use The Gimp to pixelwise-edit the images? First download the archetypes (which I guess you have). In the gimp I have been zooming in (using the + key) and then using the smallest circle brush. Dialogs->Brushes->Circle01 Johnc & Co From John.Cater at monash.edu.au Wed Jun 28 18:14:24 2000 From: John.Cater at monash.edu.au (John Cater) Date: Thu Jan 13 18:03:18 2005 Subject: [CF List] PNG Images References: <200006290538.WAA32201@tesla.EECS.Berkeley.EDU> Message-ID: <395A86D0.167E@monash.edu.au> > A lot of them would still look very good if they were just copied > and centered and not magnified. I agree, this would probably be the easiest thing to do for those images that have'nt been redraw (eg. Potions) Talking of potions, I find the .png potion images much harder to distinguish from each other. Johnc & Co. From bugs at real-time.com Thu Jun 29 02:10:01 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:03:18 2005 Subject: [CF List] Your Bugzilla buglist needs attention. Message-ID: <200006290710.e5T7A1t16016@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-bugs@ifi.uio.no Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 From bugs at real-time.com Thu Jun 29 03:33:40 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:03:18 2005 Subject: [CF List] [Bug 18] Changed - CVS version: "Fall through Hole" message given too early Message-ID: <200006290833.e5T8XeL16916@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=18 *** shadow/18 Wed Jun 28 04:24:25 2000 --- shadow/18.tmp.16913 Thu Jun 29 03:33:40 2000 *************** *** 1,6 **** Bug#: 18 Product: Crossfire ! Version: 0.95.5 Platform: PC OS/Version: Linux Status: NEW --- 1,6 ---- Bug#: 18 Product: Crossfire ! Version: 0.95.6 Platform: PC OS/Version: Linux Status: NEW *************** *** 8,14 **** Severity: trivial Priority: P2 Component: server ! AssignedTo: crossfire-bugs@ifi.uio.no ReportedBy: mullern@mweb.co.za URL: Cc: --- 8,14 ---- Severity: trivial Priority: P2 Component: server ! AssignedTo: crossfire-devel@lists.real-time.com ReportedBy: mullern@mweb.co.za URL: Cc: From rigelf at angelfire.com Thu Jun 29 12:33:09 2000 From: rigelf at angelfire.com (Rigel) Date: Thu Jan 13 18:03:18 2005 Subject: [CF List] installation: crossfire Message-ID: Hello there, I don't know if this is the right place to mail this, but would you please forward it if it is not? I have been trying to (unsuccessfully) install crossfire 0.95.6 onto my system. Said system is currently RedHat 6.0, with 2.2.5-15 kernel (soon to be upgraded to whatever RedHat can come up with), on an Intel 586 60Mhz. The server seems to work great but the client won't finish with the configure script. I can send the whole thing but I think the important part is the last error message: "configure: error: XPM library not found - you may need to use --with-xpm-lib=dir". Do you know what this xpm library is called and where it may be found? Thanks, Rigel Freden Angelfire for your free web-based e-mail. http://www.angelfire.com From John.Cater at monash.edu.au Thu Jun 29 13:15:09 2000 From: John.Cater at monash.edu.au (John Cater) Date: Thu Jan 13 18:03:18 2005 Subject: [CF List] installation: crossfire References: Message-ID: <395B922D.41C6@monash.edu.au> Rigel, > "configure: error: XPM library not found - you may need to use --with-xpm-lib=dir". > Do you know what this xpm library is called and where it may be found? Let's see - On RedHat 6.0 it should be: /usr/X11R6/lib/libXpm.a So your configure script should look something like: ./configure --width-xpm-lib=/usr/X11R6/lib If you can't find files on a linux system try the command: locate [Filename] Johnc & Co. From frank_mckenney at mindspring.com Thu Jun 29 23:28:27 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:18 2005 Subject: [CF List] CF 0.95.6 Client discards commands under "load" - feature, not bug Message-ID: <200006300328.XAA21076@maynard.mail.mindspring.net> Users with high-speed connections to relatively fast Crossfire servers will probably not need the following information. However, those with slower connections and/or slower servers may find it of interest. -- Crossfire clients and servers are hosted on a variety of systems. The client accepts commands from the user, pass them to the server, and present the results of the server's response back to the user. Under certain circumstances it is possible for the client to send commands to the server faster than the server can respond to them; if this continues long enough, commands will be buffered in the server and in the client (not to mention the keystrokes in the client's host system keyboard buffer) up to the limits of these buffers. The rate at which "the pipe" fills depends on several factors, including: - How fast the user is typing, - How "leveraged" any 'bound' keystrokes happen to be, - The speed of the link between the client and the server, - The basic speed of the Crossfire Server host machine, and - How much of a load Server and host machine are experiencing. The "leveraging" is an (oog!) key factor, since the Crossfire 'bind command makes it possible to define a single key to execute multiple commands. With a high leveraging factor (say, one key = 10 searches), pressing this key rapidly or holding it down to generate repeat keypresses continuously can easily generate commands from the client faster than some servers can respond to them. Used carelessly, this could be fatal. Imagine that you are "searching" a stack of chests for traps. You press the 'S' key (which you've defined to invoke 10 searches per keypress) and hold it down for several seconds to make sure you don't miss any well-hidden traps. Suddenly a Red Dragon appears... and you can't interrupt your searching. Foom! You just became a crisped critter! In CF 0.95.6, the client keeps track of the number of commands sent to the server and the number of responses received. If the number of outstanding commands exceeds a limit value (default of 10), the client will start discarding repeats of movement and 'firing' commands (including such things as skill use and spellcasting). The specifics can be found in the send_command() function in player.c. When commands are discarded, the Linux client writes messages to stderr like the following: Wont send command use_skill praying - window oversized 205 164 ... Wont send command search - window oversized 2 217 From mwedel at scruznet.com Thu Jun 29 22:57:09 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:18 2005 Subject: [CF List] PNG Images References: <200006290556.WAA24596@tesla.EECS.Berkeley.EDU> Message-ID: <395C1A95.108B891F@scruznet.com> Peter Mardahl wrote: > > One thing I could never figure out was how to use the 32x32 xpms? I'm not sure what you mean by this. 32x32 xpm's are not distributed/supported anywhere in crossfire. The png's are 32x32 because when David converted them, he decided to make them a bit bigger (with agreement from the list also) Now in theory, you could take the png's and convert them to a like sized xpm image - I don't really see the point - once png support gets a little better, I would actually see dropping the xpm images as pretty likely (not very bandwidth friendly and don't gain us anything of png). Actually one thing they gain is a smaller colorspace. With agreement with me, David also used more than the standard 20 or so colors we use for Xpm's - I think he went up to about 100 or so - enough so an 8 bit display could still show all of them, but also enough to improve quality. From mwedel at scruznet.com Thu Jun 29 23:09:05 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:18 2005 Subject: [CF List] CF 0.95.6 Client discards commands under "load" - feature, not bug References: <200006300328.XAA21076@maynard.mail.mindspring.net> Message-ID: <395C1D61.98B35759@scruznet.com> Good document. Note that connection speed is not all that relevant. The bandwidth it takes to send the commands to the server is minimal (maybe 30-40 bytes/command? presuming a minimal usuable speed is probably 3 K/second, tht is a lot of commands). And unless the command results in lots of output (map redraws or the like), the incoming bandwidth should not be much of a factor. Likewise, server speed only really comes in to play if the cpu on the server systems gets maxed out. Possible on slow systems, but on fast systems, this is fairly unlikely. Client speed is relevant, but similarly, really only if the cpu gets maxed out. One thing of major importance is the key repeat speed of the client. As another note, if you bind multiple commands to one key (like the 10 searches below), note that pressing that key would count as 10 commands as far as the client & server are concerned - in other words, the client expands the key and sends the actions to the server. So this can fill up that buffering quite a bit. Most servers use the 120 ms tick time (roughly 8/second). A player with speed 1.0 gets one action per tick. A player with 0.5 speed get 1 action every other tick. If you have your window size set to say 40, and your character speed is 0.5, that is 80 ticks (or roughly 10 seconds) it will take for the server to process all those buffered commands. One thing that could be nice is to have commands that get sent no matter what the windowing looks like. So for example, if the window is full (client will send no more commands) yet the player invokes the word of recall spell, it would still send that. Ideal solution would be for this to be set on a player by player basis. Ie, have some config file (or gui popup) with the list of commands and let the player set which ones are 'always send' commands, and which ones can be discarded. In theory, you could even get intermediate commands (if the queu is less than half full, send it, otherwise don't). Frank McKenney wrote: > > Users with high-speed connections to relatively fast Crossfire servers > will probably not need the following information. However, those with > slower connections and/or slower servers may find it of interest. > > -- > > Crossfire clients and servers are hosted on a variety of systems. The > client accepts commands from the user, pass them to the server, and > present the results of the server's response back to the user. Under > certain circumstances it is possible for the client to send commands to > the server faster than the server can respond to them; if this continues > long enough, commands will be buffered in the server and in the client > (not to mention the keystrokes in the client's host system keyboard > buffer) up to the limits of these buffers. > > The rate at which "the pipe" fills depends on several factors, > including: > > - How fast the user is typing, > - How "leveraged" any 'bound' keystrokes happen to be, > - The speed of the link between the client and the server, > - The basic speed of the Crossfire Server host machine, and > - How much of a load Server and host machine are experiencing. > > The "leveraging" is an (oog!) key factor, since the Crossfire 'bind > command makes it possible to define a single key to execute multiple > commands. With a high leveraging factor (say, one key = 10 searches), > pressing this key rapidly or holding it down to generate repeat > keypresses continuously can easily generate commands from the client > faster than some servers can respond to them. > > Used carelessly, this could be fatal. Imagine that you are "searching" > a stack of chests for traps. You press the 'S' key (which you've > defined to invoke 10 searches per keypress) and hold it down for several > seconds to make sure you don't miss any well-hidden traps. Suddenly a > Red Dragon appears... and you can't interrupt your searching. Foom! > You just became a crisped critter! > > In CF 0.95.6, the client keeps track of the number of commands sent to > the server and the number of responses received. If the number of > outstanding commands exceeds a limit value (default of 10), the client > will start discarding repeats of movement and 'firing' commands > (including such things as skill use and spellcasting). The specifics > can be found in the send_command() function in player.c. > > When commands are discarded, the Linux client writes > messages to stderr like the following: > > Wont send command use_skill praying - window oversized 205 164 > ... > Wont send command search - window oversized 2 217 > > >From a user standpoint, the "command windowing" has advantages and > disadvantages. On the good side, it tries to keep the client's view of > the universe from getting too far ahead of the server's view (e.g. the > chest/Dragon example above). The down side is that if enough many > commands are queued quickly enough to overrun the window size, what one > enters is not necessarily what one gets back. My attempt to issue 50 > 'search' commands, for example, actually executed some number less than > that (as shown by the error message above)... with potentially painful > consequences. > > Fortunately, the command window size is determined by the client. The > following describes how to turn this particular knob on the Linux client > (other clients may provide different mechanisms). > > The 'help command describes two commands of interest: > > 'cwindow N sets the window size to N (1...127), and > 'savedefaults creates a .crossfire/defaults file, which > will include the command_window setting. > > In my case both the client and the server on the same machine, a 32 Mb > 486DX4-100 with SuSE Linux 6.4. For the most part this works > acceptably, but until I cranked the 'cwindow setting up to 40 I was > losing a _lot_ of attempts to stack multiple 'use_skills praying' > commands. Even at 40, as you can see from the above error messages, I'm > not actually doing all the 'search'ing I _thought_ I was doing, so I'll > probably increase the setting to something in the 60-80 range and > monitor my stderr output. > > Hope this helps. > > -- > > My thanks to Mark Wedel, whose comments a few days back started my > research on this. However, I should point out that any typos, > misinterpretations, or misreadings of the Crossfire code are mine and > mine alone (;-). > > Frank McKenney > > Frank McKenney, McKenney Associates > Richmond, Virginia / (804) 320-4887 > E-mail: frank_mckenney@mindspring.com > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From frank_mckenney at mindspring.com Fri Jun 30 10:46:10 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:18 2005 Subject: [CF List] CF 0.95.6 Client discards commands under "load" - feature, not bug References: <200006300328.XAA21076@maynard.mail.mindspring.net> Message-ID: <200006301445.KAA30041@tisch.mail.mindspring.net> ** Reply to message from Mark Wedel on Thu, 29 Jun 2000 21:09:05 -0700 > Good document. Thanks, Mark. > Note that connection speed is not all that relevant. The bandwidth it > takes to > send the commands to the server is minimal (maybe 30-40 > bytes/command? > presuming a minimal usuable speed is probably 3 > K/second, tht is a lot of > commands). Agreed, the uplink speed is likely to be one of the lesser constraints in most situations. A 33KB uplink (call it 3K bytes/sec) would give the client 100 commands/sec... but, of course, a reasonably fast client _could_ exceed this when hit with a stream of "macro" commands (10 keystrokes with a 10:1 leveraging runs you right up to the limit). > ... And unless the command results > in lots of output (map redraws or the > like), the incoming bandwidth > should not be much of a factor. Agreed, in most cases (caveat added for the inevitable aficionado who is going to set up a 1200 Baud dial-in link so his friends can play on his Linux server (;-)). We still have the incoming bandwidth (from the server) to consider. Acknowledging that that there will likely be a _flood_ of bits outbound from the server when the character moves into a new map, are there any other situations which might generate copious server output? > Likewise, server speed only really comes in to play if the cpu on the > server > systems gets maxed out. Possible on slow systems, but on > fast systems, this is > fairly unlikely. Ah. Here we get to one of the critical points of my own ignorance. In the past I have often objected to the phrase "latest version" on the basis that it was ambiguous and often time-constrained. "Fast" and "slow" have the same problem here: (a) I don't have the experience to offer an opinion on what hardware might be considered "fast" or slow for CF 0.95.6 (except that a 32 Mb 486DX4-100 seems a little on the slow side (;-)), and (b) over time the Crossfire code, connection data rates and latency, and The Available Hardware will continue to change. Would some of the lurkers out there care to offer some examples of "slow", "acceptable", "really snappy", and "probably unplayably slow" hardware, specifically with respect to Crossfire 0.95.6? > Client speed is relevant, but similarly, really only if the cpu gets maxed > out. One thing of major importance is the key repeat speed of the client. Yes. I thought I had covered that part of it when I described the effects of "leveraging" commands. If this was unclear (and it apparently was), maybe there is a better way of saying it. Or were you attempting to address some aspect that _I_ missed? (The complexities and subtleties of human-human communication make Client-Server protocols look simple in comparison! (;-)) > Most servers use the 120 ms tick time (roughly 8/second). A player with speed > 1.0 gets one action per tick. A player with 0.5 speed get 1 action every other > tick. > > If you have your window size set to say 40, and your character speed is 0.5, > that is 80 ticks (or roughly 10 seconds) it will take for the server to process > all those buffered commands. Yup. Anyone care to offer odds that Crossfire users can be convinced _not_ to try to squeeze as much action as possible out of _every_ keystroke? > One thing that could be nice is to have commands that get sent no matter what > the windowing looks like. So for example, if the window is full (client will > send no more commands) yet the player invokes the word of recall spell, it would > still send that. Ideal solution would be for this to be set on a player by > player basis. > > Ie, have some config file (or gui popup) with the list of commands and let the > player set which ones are 'always send' commands, and which ones can be > discarded. In theory, you could even get intermediate commands (if the queu is > less than half full, send it, otherwise don't). This sounds like... um... "an interesting feature if _I_ don't have to code and debug it" (;-)) It also raises another point of ignorance (again, mine): _is_ this a serious problem? That is, I know my own system is a bit slow-ish, but I'm new enough to Crossfire that I have no sense of what hardware its servers (and clients) are running on. If everyone by me now has a 256Mb Athlon/P-III 600MHz box, my three-hour compilation (I'm slow and pedantic) may only be of use to one or two people. Do you (does anyone) have any idea how often users are actually exceeding (for whatever reason) the default command_window seting of 10? Frank Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From jhantin at derringer.net Fri Jun 30 13:09:15 2000 From: jhantin at derringer.net (Jeffrey Hantin) Date: Thu Jan 13 18:03:18 2005 Subject: [CF List] PNG Images In-Reply-To: <395C1A95.108B891F@scruznet.com> References: <200006290556.WAA24596@tesla.EECS.Berkeley.EDU> <395C1A95.108B891F@scruznet.com> Message-ID: <20000630.18091500@bullet.derringer.net> > Now in theory, you could take the png's and convert them to a like sized xpm > image - I don't really see the point - once png support gets a little better, I > would actually see dropping the xpm images as pretty likely (not very bandwidth > friendly and don't gain us anything of png). One thing I did notice as an advantage of xpm: a single xpm can support multiple colormaps for different color depths, thus allowing the client to choose a colormap appropriate to its visual and depth. This also eliminates the need to have separate monochrome xbm images, unless they're used to deal with downlevel clients-- and I don't know that clients that old are supported. So for that matter, why not drop the xbm? > Actually one thing they gain is a smaller colorspace. With agreement with me, > David also used more than the standard 20 or so colors we use for Xpm's - I > think he went up to about 100 or so - enough so an 8 bit display could still > show all of them, but also enough to improve quality. I think part of the issue is whether the graphics should look iconic or photographic. In 24x24 or even 32x32, I think it's a small enough space to warrant iconic style, which also copes well with a restricted colormap. From mwedel at scruznet.com Fri Jun 30 22:08:29 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:18 2005 Subject: [CF List] PNG Images References: <200006290556.WAA24596@tesla.EECS.Berkeley.EDU> <395C1A95.108B891F@scruznet.com> <20000630.18091500@bullet.derringer.net> Message-ID: <395D60AD.BEC0DBC5@scruznet.com> Jeffrey Hantin wrote: > One thing I did notice as an advantage of xpm: a single xpm can > support multiple colormaps for different color depths, thus allowing > the client to choose a colormap appropriate to its visual and depth. > This also eliminates the need to have separate monochrome xbm images, > unless they're used to deal with downlevel clients-- and I don't know > that clients that old are supported. So for that matter, why not drop > the xbm? Actually, png can also do this. I don't think the images as currently distributed have this set up. I remember asking about xbm a while ago, and apparantly there will still a number of people out there playing on monochrome x-terminals and the like. While xpm worked on those, you didn't gain much, but using them took up more bandwidth and memory, so xbm worked fine. Png at least doesn't use up nearly the space of png, but still a bit more than xbm (you can't really look at the ones in the arch distribution, as those are the text representation. In the crossfire.xbm file, they are converted to binary, and each one is 72 bytes). With pngs, the space isn't quite so bad (from a limited sample, it looks like the png's are roughly 3 times the xbm, and the xpm is 3-4 times bigger than the png) > I think part of the issue is whether the graphics should look iconic > or photographic. In 24x24 or even 32x32, I think it's a small enough > space to warrant iconic style, which also copes well with a restricted > colormap. I believe a lot of it was simply because the original 24 colors was not a really good represenation of the colors - it basically covered the 12 or so colors of the original game and I filled in some more, but I believe there were some colors that were basically absent that David wanted to use. I don't think even at 32x32 you can every really get them looking photographic - if you try that, more likely it will just appear as a blur. From mwedel at scruznet.com Fri Jun 30 22:16:25 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:19 2005 Subject: [CF List] CF 0.95.6 Client discards commands under "load" - feature, not bug References: <200006300328.XAA21076@maynard.mail.mindspring.net> <200006301445.KAA30041@tisch.mail.mindspring.net> Message-ID: <395D6289.2017A14B@scruznet.com> Frank McKenney wrote: > We still have the incoming bandwidth (from the server) to consider. > Acknowledging that that there will likely be a _flood_ of bits outbound > from the server when the character moves into a new map, are there any > other situations which might generate copious server output? Times that will consume a lot of bandwidth: 1) entering a new map 2) Stepping on a square with lots of objects on it (piles of sold stuff in shops for example, or if you have a narrow hallway and are killing a bunch of monsters on the same space) 3) Picking up that large pile of stuff. > Ah. Here we get to one of the critical points of my own ignorance. In > the past I have often objected to the phrase "latest version" on the > basis that it was ambiguous and often time-constrained. "Fast" and > "slow" have the same problem here: (a) I don't have the experience to > offer an opinion on what hardware might be considered "fast" or slow for > CF 0.95.6 (except that a 32 Mb 486DX4-100 seems a little on the slow > side (;-)), and (b) over time the Crossfire code, connection data rates > and latency, and The Available Hardware will continue to change. > > Would some of the lurkers out there care to offer some examples of > "slow", "acceptable", "really snappy", and "probably unplayably slow" > hardware, specifically with respect to Crossfire 0.95.6? Note that load on the server will vary this. A server with 10 active players certainly has different load than a single player server. I would say 32 mb of ram is on the low side in modern standards. One thing you can do use use the 'time (or is it times) command. This displays tick information - more importantly, how many times it was not able to complete all the desired stuff within the 120 ms time constraint. You will certainly get some long times, since map loading will happen in one tick, so that can make for some very long ticks here and there. > That is, I know my own system is a bit slow-ish, but I'm new enough to > Crossfire that I have no sense of what hardware its servers (and > clients) are running on. If everyone by me now has a 256Mb Athlon/P-III > 600MHz box, my three-hour compilation (I'm slow and pedantic) may only > be of use to one or two people. 3 hour? I would really look at adding some more ram. a 486 dx4-100 shouldn't be that slow. Compiling on a 100 mhz sparc 10 (hypersparc) only took about 8 minutes. On a p3-500, it took about 1 min 45 seconds. It is hard to really determine minimum system requirements. My own standard would be if it is usable/playable, it meats the minimum requirements. Note that I believe that now days, the client can easily use more cpu than the server for a single player, especially is using xpm/png graphics (this is also taking into account the xserver load it causes). > > Do you (does anyone) have any idea how often users are actually > exceeding (for whatever reason) the default command_window seting of 10? Just to be clear - I don't think exceeding it is necessarily a bad thing. I do at times exceed that when playing. Most often beacause I am running in some direction and enter a building or the like, so there is that brief pause. I generally find 10 about the right size - enough so that I can type a few things in advanced, but not so long that I get stuck against a wall waiting for all those movements to get resolved.