From crossfire-request Thu Nov 24 09:20:05 1994 Return-Path: Received: from aino.it.lut.fi (hevi@aino.it.lut.fi [157.24.11.71]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 24 Nov 1994 09:20:05 +0100 Received: from localhost (hevi@localhost) by aino.it.lut.fi (8.6.5/8.6.5/1.12.kim) id KAA19473; Thu, 24 Nov 1994 10:19:49 +0200 Date: Thu, 24 Nov 1994 10:19:47 +0200 (EET) From: Petri Heinila X-Sender: hevi@aino.it.lut.fi To: Brandon Van every cc: crossfire@ifi.uio.no Subject: Re: Crossfire on PPP is too slow In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 23 Nov 1994, Brandon Van every wrote: > I've just gotten the 0.91.5 client (no patch) to run on my Linux box. > I used a PPP connection to the Berkeley server. I found the > connection to be too sluggish to be useful. I really couldn't "run > at" things, because my keyboard history combined with net lag would > put me in odd locations. General, before playing, set the keyboard repeat off by: xset r off -- The Page -- From crossfire-request Thu Nov 24 04:42:57 1994 Return-Path: Received: from rbdc.rbdc.com (rbdc.rbdc.com [199.171.83.2]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 24 Nov 1994 04:42:56 +0100 Received: by rbdc.rbdc.com (/\==/\ Smail3.1.28.1 #28.10) id ; Wed, 23 Nov 94 22:41 EST Message-Id: Date: Wed, 23 Nov 94 22:41 EST From: vanevery@rbdc.rbdc.com (Brandon Van every) To: crossfire@ifi.uio.no Subject: Crossfire on PPP is too slow Status: RO Hey folks! I've just gotten the 0.91.5 client (no patch) to run on my Linux box. I used a PPP connection to the Berkeley server. I found the connection to be too sluggish to be useful. I really couldn't "run at" things, because my keyboard history combined with net lag would put me in odd locations. I'm curious if anyone's doing anything to make Crossfire usable over serial links. Also if anyone can comment on the triviality or extreme difficulty of making the necessary changes. I might be interested in working on it, if it's not too demanding a job. Cheers, Brandon From crossfire-request Wed Nov 23 22:38:59 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 23 Nov 1994 22:38:55 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id NAA09422; Wed, 23 Nov 1994 13:38:40 -0800 Message-Id: <199411232138.NAA09422@soda.CSUA.Berkeley.EDU> To: Tero Jyri Michael Pelander cc: crossfire@ifi.uio.no Subject: Re: problems in the Demonology towers??? In-reply-to: Your message of "Wed, 23 Nov 1994 20:20:54 +0200." <94Nov23.202102+0200_(eet).165853-2@utu.fi> Date: Wed, 23 Nov 1994 13:38:38 -0800 From: Peter Mardahl Status: RO In message <94Nov23.202102+0200_(eet).165853-2@utu.fi>, Tero Jyri Michael Pelan der writes: >> 3) If you are in the level HighTower1 and you say "down" as suggested for th >e >> teleporter, the program crash.... > >I have crashed the game multiple times by about this procedure: > - save your self to one level below > - cast some spells (armour,prot from attack) > - go up >I once had exactly this problem and I needed to use word of recall to get >to some other location as the game crashed always when I tried to continue >from the save and move up. Sometimes there are just message that I have >teleported to somewhere but I'm still on the same map. I tried to repeat this. It worked for me--no crash. I am using c91.5. PeterM From crossfire-request Wed Nov 23 22:28:37 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 23 Nov 1994 22:28:35 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id NAA08380; Wed, 23 Nov 1994 13:28:13 -0800 Message-Id: <199411232128.NAA08380@soda.CSUA.Berkeley.EDU> To: Tero Jyri Michael Pelander cc: crossfire@ifi.uio.no Subject: Re: problems in the Demonology towers??? In-reply-to: Your message of "Wed, 23 Nov 1994 20:20:54 +0200." <94Nov23.202102+0200_(eet).165853-2@utu.fi> Date: Wed, 23 Nov 1994 13:28:11 -0800 From: Peter Mardahl Status: RO In message <94Nov23.202102+0200_(eet).165853-2@utu.fi>, Tero Jyri Michael Pelan der writes: > >I have noticed that if the cleaning lady is next to you when you say the >second name only thing that happens is that she replies to your words. >For the gate to open you need to wait to the lady to be on the first >gates or you must kill her. > I don't know what to do about that. PeterM From crossfire-request Wed Nov 23 22:27:23 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 23 Nov 1994 22:27:17 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id NAA08223; Wed, 23 Nov 1994 13:26:55 -0800 Message-Id: <199411232126.NAA08223@soda.CSUA.Berkeley.EDU> To: Paola.Caluri@cselt.stet.it cc: crossfire@ifi.uio.no Subject: Re: problems in the Demonology towers??? In-reply-to: Your message of "Wed, 23 Nov 1994 10:17:22 +0100." <81BC215011FF202AB4@EI3500.CSELT.STET.IT> Date: Wed, 23 Nov 1994 13:26:52 -0800 From: Peter Mardahl Status: RO In message <81BC215011FF202AB4@EI3500.CSELT.STET.IT>, Paola.Caluri@cselt.stet.i t writes: >Exploring Demonology Tower, map world_a2, I had some problems, may be I was >wrong but looking at the maps I noted: >1) In the level AirStudy, The name for summoning the air elemental was >different from the one in the book, found in the level below. Somewhere it >has an "h" at the end, but not anywhere. You are right about this. The interesting thing is that it seems to work. I suspect it compares the shorter of the two strings or something like that. If this is the case, it is not good: imagine a mystery, you extract key words from someone by speaking all the letters of the alphabet. Woof woof! I've just discovered something, if you have the keyword right EXCEPT FOR THE LAST LETTER (which you may omit), it triggers the magic ear. Not a big bug. How funny. You should only have been able to discover this by looking at the map. For shame! >2) In the level Demon3, the 4 teleporter doesn't work: if you say the word in >the central square (7,7), you can hear a "click" but nothing else happens, >and if you say the word on a teleporter they doesn't work anywhere. Nothing SHOULD happen, if you're standing in the center. However, the teleporters not working afterward is disturbing. I spoke the Word in 7,7 and then on another of the teleporters and it worked. I don't know which you mean by the #4 teleporter. I tried all 4. They all worked. >3) If you are in the level HighTower1 and you say "down" as suggested for the >teleporter, the program crash.... Tried that too. They all worked. WHICH version of crossfire are you using? Demonology is a complex map, and it's possible it has features which your server cannot handle! PeterM From crossfire-request Wed Nov 23 19:21:09 1994 Return-Path: Received: from castor.cc.utu.fi (root@castor.cc.utu.fi [130.232.1.14]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 23 Nov 1994 19:21:09 +0100 Received: by utu.fi id <165853-2>; Wed, 23 Nov 1994 20:21:02 +0200 Subject: Re: problems in the Demonology towers??? From: Tero Jyri Michael Pelander To: crossfire@ifi.uio.no Date: Wed, 23 Nov 1994 20:20:54 +0200 (EET) In-Reply-To: <81BC215011FF202AB4@EI3500.CSELT.STET.IT> from "Paola.Caluri@cselt.stet.it" at Nov 23, 94 10:17:22 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Length: 1408 Message-Id: <94Nov23.202102+0200_(eet).165853-2@utu.fi> Status: RO > Exploring Demonology Tower, map world_a2, I had some problems, may be I was > wrong but looking at the maps I noted: > 1) In the level AirStudy, The name for summoning the air elemental was > different from the one in the book, found in the level below. Somewhere it > has an "h" at the end, but not anywhere. Hmmm. I didn't notice. I did solve it just by playing (with a friend). > 2) In the level Demon3, the 4 teleporter doesn't work: if you say the word in > the central square (7,7), you can hear a "click" but nothing else happens, > and if you say the word on a teleporter they doesn't work anywhere. I have noticed that if the cleaning lady is next to you when you say the second name only thing that happens is that she replies to your words. For the gate to open you need to wait to the lady to be on the first gates or you must kill her. > 3) If you are in the level HighTower1 and you say "down" as suggested for the > teleporter, the program crash.... I have crashed the game multiple times by about this procedure: - save your self to one level below - cast some spells (armour,prot from attack) - go up I once had exactly this problem and I needed to use word of recall to get to some other location as the game crashed always when I tried to continue from the save and move up. Sometimes there are just message that I have teleported to somewhere but I'm still on the same map. From crossfire-request Wed Nov 23 18:54:53 1994 Return-Path: Received: from surt.ifi.uio.no (1232@surt.ifi.uio.no [129.240.76.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id ; Wed, 23 Nov 1994 18:54:52 +0100 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by surt.ifi.uio.no ; Wed, 23 Nov 1994 18:54:51 +0100 Date: Wed, 23 Nov 1994 18:54:51 +0100 Message-Id: <199411231754.4880.surt.ifi.uio.no@ifi.uio.no> To: anthony@cit.gu.edu.au CC: crossfire@ifi.uio.no In-reply-to: <199411230608.AA05326@dragon.cit.gu.edu.au> (message from Anthony Thyssen on Wed, 23 Nov 1994 16:08:47 +1000) Subject: Re: crashes Status: RO +--- Anthony Thyssen: | Allocate colors as you have, when you run out THEN call | XCopyColormapAndFree() to allocate a seperate color map from the | default and continue where you left off. Correct me if I'm wrong, but I think the problem is that the XPM-library is allocating colours without hooks for adding behaviour like this. +--- Mark Wedel: | Also, as far as I know, the only accurate way to find out if there | is enough space is to try and allocate the colors, and if it fails, | free them and perhaps install a private color map. Oh no, you can't free them... Start crossfire, start xv, enter new map with colourful scenery == server crash... :-) Mark, you did specify a list of 28 colours which should be used in XPM-files. Do you think the graphics deviate from this? (shouldn't be too hard to check, actually...) Kjetil T. From crossfire-request Wed Nov 23 16:19:53 1994 Return-Path: Received: from POSTAL.CSELT.STET.IT (postal.cselt.stet.it [163.162.4.5]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 23 Nov 1994 16:19:52 +0100 Received: from DN-EI3500 by POSTAL.CSELT.STET.IT (PMDF V4.2-15 #4385) id <01HJTK8KD928000J8O@POSTAL.CSELT.STET.IT>; Wed, 23 Nov 1994 13:49:27 MET Received: from aragorn (125.0.90.149) by EI3500.CSELT.STET.IT; Wed, 23 Nov 94 10:17 GMT +1 Received: from localhost by aragorn with SMTP (1.38.193.4/16.2) id AA20338; Wed, 23 Nov 1994 10:17:25 +0100 Date: Wed, 23 Nov 1994 10:17:22 +0100 (MET) From: Paola.Caluri@cselt.stet.it Subject: problems in the Demonology towers??? To: crossfire@ifi.uio.no Message-id: <81BC215011FF202AB4@EI3500.CSELT.STET.IT> X-Envelope-to: crossfire@ifi.uio.no Content-transfer-encoding: 7BIT Status: RO Exploring Demonology Tower, map world_a2, I had some problems, may be I was wrong but looking at the maps I noted: 1) In the level AirStudy, The name for summoning the air elemental was different from the one in the book, found in the level below. Somewhere it has an "h" at the end, but not anywhere. 2) In the level Demon3, the 4 teleporter doesn't work: if you say the word in the central square (7,7), you can hear a "click" but nothing else happens, and if you say the word on a teleporter they doesn't work anywhere. 3) If you are in the level HighTower1 and you say "down" as suggested for the teleporter, the program crash.... Anyone had found the same problem????? *********************************************************************** * * * Paola Caluri * * CSELT - TORINO - ITALIA * * paola.caluri@cselt.stet.it * * * *********************************************************************** From crossfire-request Wed Nov 23 07:12:33 1994 Return-Path: Received: from dragon.cit.gu.edu.au (dragon.cit.gu.edu.au [132.234.5.27]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 23 Nov 1994 07:12:30 +0100 Received: by dragon.cit.gu.edu.au id AA05326 (5.67b/IDA-1.5 for crossfire@ifi.uio.no); Wed, 23 Nov 1994 16:08:47 +1000 Date: Wed, 23 Nov 1994 16:08:47 +1000 From: Anthony Thyssen Message-Id: <199411230608.AA05326@dragon.cit.gu.edu.au> To: master@rahul.net, crossfire@ifi.uio.no Subject: Re: crashes In-Reply-To: Mail from 'Mark Wedel ' dated: Tue, 22 Nov 1994 21:18:15 -0800 X-Face: "iO`19c"sFVLnS(9,80^_E^BqA&Ta,05p2lA`FWO.d8el_~lo2k2}{t#~Y{~M!hPV?Augr< d1w9Ai$pen`'0!Hn;}TZMK*}\N_"c)g8B>@'%'}9d\,From the Orielly's Xlib book ( X Windows R4/R5, Vol 1, page 243 ) XCopyColormapAndFree() Moves all of the client's existing colormap entries to a new colormap and frees those entries of the old colormap. This is used when colorcell allocation fails and some cells have already been allocated. It saves needing to create a colormap and start from the beginning allocating colors. For applications with special color needs that can't make do, they can call XCopyColormapAndFree(), set thier colormap window attribute, and continue allocating colors in the new colormap where they left off. Anthony Thyssen ( System Programmer ) http://www.cit.gu.edu.au/~anthony/ ------------------------------------------------------------------------------- East takes you out. Out takes you west. West takes you in. In takes you east. North and south brings you back. - Litany of Orbital Mechanics --- Larry Niven -- "Intergral Trees" ------------------------------------------------------------------------------- From crossfire-request Wed Nov 23 06:18:31 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 23 Nov 1994 06:18:26 +0100 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA22305 (5.67b8/IDA-1.5 for ); Tue, 22 Nov 1994 21:18:16 -0800 Received: by bolero.rahul.net id AA12501 (5.67b8/IDA-1.5); Tue, 22 Nov 1994 21:18:15 -0800 Date: Tue, 22 Nov 1994 21:18:15 -0800 From: Mark Wedel Message-Id: <199411230518.AA12501@bolero.rahul.net> To: crossfire@ifi.uio.no, philb@CSUA.Berkeley.EDU Subject: Re: crashes Status: RO but even if you have pseudo color, if you have enough space in the colormap, it is probably preferable to use the public colormap (crossfire only uses about 30-40 colors in XPM mode.) From crossfire-request Wed Nov 23 05:32:38 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 23 Nov 1994 05:32:37 +0100 Received: (philb@localhost) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) id UAA24044 for crossfire@ifi.uio.no; Tue, 22 Nov 1994 20:32:34 -0800 From: Philip Brown Message-Id: <199411230432.UAA24044@soda.CSUA.Berkeley.EDU> Subject: Re: crashes To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Tue, 22 Nov 1994 20:32:32 -0800 (PST) In-Reply-To: <"10223 Tue Nov 22 22:32:26 1994"@bnr.ca> from "tuan" at Nov 22, 94 09:32:00 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 306 Status: RO >>>>[From tuan] Give an option for using private color map. That way, for those who are not sure if they have enough memory for the colormap, won't crashes the server when trying to get in. How about just always use a private colourmap?? (unless you are on a truecolor display!) From crossfire-request Wed Nov 23 04:34:26 1994 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 23 Nov 1994 04:34:21 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 22 Nov 1994 22:32:49 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 22 Nov 1994 22:32:04 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Sun, 20 Nov 1994 22:32:00 -0500 Date: Tue, 22 Nov 1994 21:32:00 -0600 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.198:23.10.94.03.32.04] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: crashes From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"10223 Tue Nov 22 22:32:26 1994"@bnr.ca> To: master@rahul.net Cc: preston.crow@dancer.dartmouth.edu, crossfire@ifi.uio.no Subject: Re: crashes Status: RO In message "Re: crashes", 'master@rahul.net' writes: > But there is no real way to know if the color space is available, because >unless you start getting really smart by looking at the XPM image >data, there is no way to know how many colors the images actually use. > > Also, as far as I know, the only accurate way to find out if there is >enough space is to try and allocate the colors, and if it fails, free >them and perhaps install a private color map. > > --Mark Give an option for using private color map. That way, for those who are not sure if they have enough memory for the colormap, won't crashes the server when trying to get in. Regards, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 214-684-4575 Fax: 214-684-3716 Internet: tdoan@bnr.ca WWW: http://47.53.64.96/tdoan/tdoan.html From crossfire-request Wed Nov 23 03:23:47 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 23 Nov 1994 03:23:41 +0100 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA16708 (5.67b8/IDA-1.5 for ); Tue, 22 Nov 1994 18:23:16 -0800 Received: by bolero.rahul.net id AA28440 (5.67b8/IDA-1.5); Tue, 22 Nov 1994 18:23:13 -0800 Date: Tue, 22 Nov 1994 18:23:13 -0800 From: Mark Wedel Message-Id: <199411230223.AA28440@bolero.rahul.net> To: preston.crow@dancer.dartmouth.edu, tdoan@bnr.ca Subject: Re: crashes Cc: crossfire@ifi.uio.no Status: RO But there is no real way to know if the color space is available, because unless you start getting really smart by looking at the XPM image data, there is no way to know how many colors the images actually use. Also, as far as I know, the only accurate way to find out if there is enough space is to try and allocate the colors, and if it fails, free them and perhaps install a private color map. --Mark From crossfire-request Wed Nov 23 02:55:10 1994 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 23 Nov 1994 02:55:07 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 22 Nov 1994 20:53:54 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 22 Nov 1994 20:09:57 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 22 Nov 1994 17:44:00 -0500 Date: Tue, 22 Nov 1994 16:44:00 -0600 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.139:23.10.94.01.09.57] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: crashes From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"18786 Tue Nov 22 20:16:49 1994"@bnr.ca> To: preston.crow@dancer.dartmouth.edu Cc: crossfire@ifi.uio.no Subject: Re: crashes Status: RO In message "Re: crashes", 'preston.crow@dancer.dartmouth.edu' writes: >>Hope there are some patches >>out there. > >One was posted to this list a few days ago. > >Also, I've just noticed that it will crash the server if I try to start in >using XPM when there isn't enough room in the colormap. I haven't seen that >one in the list of bugs before. > >--PC Yep. I would say this is one of the most annoying bug. There has to be a better way of finding out if the colormap space is available _before_ using it. Regards, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 214-684-4575 Fax: 214-684-3716 Internet: tdoan@bnr.ca WWW: http://47.53.64.96/tdoan/tdoan.html From crossfire-request Tue Nov 22 14:58:13 1994 Return-Path: Received: from dartvax.dartmouth.edu (dartvax.dartmouth.edu [129.170.16.4]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 22 Nov 1994 14:58:10 +0100 Received: from dancer.Dartmouth.EDU (dancer.dartmouth.edu [129.170.208.7]) by dartvax.dartmouth.edu (8.6.9+DND/8.6.9) with SMTP id IAA09074 for ; Tue, 22 Nov 1994 08:58:07 -0500 Message-id: <9241775@dancer.Dartmouth.EDU> Date: 22 Nov 94 08:58:04 EST From: Preston.F.Crow@Dartmouth.EDU (Preston F. Crow) Reply-To: preston.crow@dancer.dartmouth.edu Subject: Re: crashes To: crossfire@ifi.uio.no Status: RO >Hope there are some patches >out there. One was posted to this list a few days ago. Also, I've just noticed that it will crash the server if I try to start in using XPM when there isn't enough room in the colormap. I haven't seen that one in the list of bugs before. --PC From crossfire-request Tue Nov 22 13:44:38 1994 Return-Path: Received: from nova.gmi.edu (nova.gmi.edu [192.138.137.2]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 22 Nov 1994 13:44:36 +0100 Received: from trofeo.gmi.edu.gmi.edu by nova.gmi.edu (4.1/SMI-4.1-DNI) id AA05283; Tue, 22 Nov 94 07:49:01 EST Date: Tue, 22 Nov 94 07:49:01 EST From: srin9340@nova.gmi.edu (Akshay Srinivasan) Message-Id: <9411221249.AA05283@nova.gmi.edu> To: crossfire@ifi.uio.no Subject: crashes Status: RO The new version tends to crash a lot. Havent been able to play for more than an hour without a crash. The main problem I have noticed so far is when some object is removed from a bag it instantly crashes. Hope there are some patches out there. By the way no error messages except the signal it recieved to quit. Maybe it shouldnt be too touchy about errors. Ripclaw (Maintainer) From crossfire-request Tue Nov 22 10:06:36 1994 Return-Path: Received: from doc.cc.utexas.edu (gap@doc.cc.utexas.edu [128.83.108.14]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 22 Nov 1994 10:06:35 +0100 Received: (from gap@localhost) by doc.cc.utexas.edu (8.6.8.1/8.6.6/cc-wf-sunos.mc-1.1) id DAA17910 for crossfire@ifi.uio.no; Tue, 22 Nov 1994 03:06:31 -0600 From: Elvis Impersonator Message-Id: <199411220906.DAA17910@doc.cc.utexas.edu> Subject: crossedit private colormap To: crossfire@ifi.uio.no Date: Tue, 22 Nov 1994 03:06:31 -0600 (CST) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 236 Status: RO Hm, while trying to use my nifty newly compiled crossedit, it died because I dont have enough colors to allocate (icky VGA, never loose your monitor manual) Is there a version that is robust enough to create a private colormap? gap From crossfire-request Tue Nov 22 09:26:27 1994 Return-Path: Received: from rbdc.rbdc.com (rbdc.rbdc.com [199.171.83.2]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 22 Nov 1994 09:26:24 +0100 Received: by rbdc.rbdc.com (/\==/\ Smail3.1.28.1 #28.10) id ; Tue, 22 Nov 94 03:25 EST Message-Id: Date: Tue, 22 Nov 94 03:25 EST From: vanevery@rbdc.rbdc.com (Brandon Van every) To: crossfire@ifi.uio.no Subject: Compiling crossfire under Linux? Status: RO Howdy folks! I seem to be missing the following header files under Linux. I've grepped all my /include directories recursively, they simply do not exist. Has anyone compiled crossfire under Linux? Can anyone tell me what these files are for? I know what tcp, malloc, etc. are, but Linux doesn't seem to have these headers. #include #include #include #include #include Thanks, Brandon From crossfire-request Tue Nov 22 00:11:48 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 22 Nov 1994 00:11:44 +0100 Received: (peterm@localhost) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) id PAA19524 for crossfire@ifi.uio.no; Mon, 21 Nov 1994 15:11:37 -0800 Date: Mon, 21 Nov 1994 15:11:37 -0800 From: Peter Mardahl Message-Id: <199411212311.PAA19524@soda.CSUA.Berkeley.EDU> To: crossfire@ifi.uio.no Subject: 2 new spells added Status: RO I sent patches to Mark for 2 new spells: show invisible, and xray vision. The first spell can be put in runes to show up nasty invisible players, the second can be turned off if you think that it gives yet another advantage to too-powerful spellcasters. PeterM (P.S., you can ftp these yourself if it amuses you: ftp.csua.berkeley.edu, pub/crossfire/2spell.tar -- they're based on 91.5, but should work fine in 91.6. ) From crossfire-request Mon Nov 21 21:24:49 1994 Return-Path: Received: from dartvax.dartmouth.edu (dartvax.dartmouth.edu [129.170.16.4]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 21 Nov 1994 21:24:43 +0100 Received: from fermat.dartmouth.edu (fermat.dartmouth.edu [129.170.28.31]) by dartvax.dartmouth.edu (8.6.9+DND/8.6.9) with SMTP id PAA08109 for ; Mon, 21 Nov 1994 15:24:41 -0500 Received: by fermat.dartmouth.edu (NX5.67d/NX3.0S) id AA02720; Mon, 21 Nov 94 15:21:13 -0500 Date: Mon, 21 Nov 94 15:21:13 -0500 From: Michael Glenn Message-Id: <9411212021.AA02720@fermat.dartmouth.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: CF: Location of eutl. Status: RO > Could someone who has ftp'd the eutl libraries give me > a site and directory to get it from. I can't seem to find > it on ifi.uio.no or any other place. Archie also throws > nothing my way. Thanks in advance. There is a eutl package in the submissions directory, but this was an older version missing the function ArgList_addChar(). After looking around, I found the directory "eric" in the submissions directory. This had another eutl package which was more recent, and seemed to compile. (After several modifications specific to my machine) My main concern about the installation was with compiling the cfclient program. In arglist.h, struct ArgList is defined. But this is also defined in /usr/include/X11/Intrinsic.h on my machine (i.e. in one of the system X11 files). I'm not sure how to resolve this. To get it to compile, I commented out the struct ArgList in the system file, but I am not sure this won't mess up other things. Michael From crossfire-request Mon Nov 21 18:17:10 1994 Return-Path: Received: from nova.gmi.edu (nova.gmi.edu [192.138.137.2]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 21 Nov 1994 18:17:01 +0100 Received: from prizm.gmi.edu.gmi.edu by nova.gmi.edu (4.1/SMI-4.1-DNI) id AA03140; Mon, 21 Nov 94 12:21:19 EST Date: Mon, 21 Nov 94 12:21:19 EST From: srin9340@nova.gmi.edu (Akshay Srinivasan) Message-Id: <9411211721.AA03140@nova.gmi.edu> To: crossfire@ifi.uio.no Status: RO Could someone who has ftp'd the eutl libraries give me a site and directory to get it from. I can't seem to find it on ifi.uio.no or any other place. Archie also throws nothing my way. Thanks in advance. Ripclaw (Maintainer) From crossfire-request Sun Nov 20 23:07:32 1994 Return-Path: Received: from dartvax.dartmouth.edu (dartvax.dartmouth.edu [129.170.16.4]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sun, 20 Nov 1994 23:07:31 +0100 Received: from dancer.Dartmouth.EDU (dancer.dartmouth.edu [129.170.208.7]) by dartvax.dartmouth.edu (8.6.9+DND/8.6.9) with SMTP id RAA26769; Sun, 20 Nov 1994 17:07:21 -0500 Message-id: <9155716@dancer.Dartmouth.EDU> Date: 20 Nov 94 17:07:20 EST From: Preston.F.Crow@Dartmouth.EDU (Preston F. Crow) Reply-To: preston.crow@dancer.dartmouth.edu Subject: Re: 90.1.6 problems To: master@rahul.net (Mark Wedel), scott@santafe.edu (Scott D. Yelich) Cc: crossfire@ifi.uio.no, Preston.F.Crow@Mac.dartmouth.edu Status: RO >Is using a client any faster than using 'add from the server? Not in network communication, but it makes it a simple command line, which is especially nice when the server is crashing frequently. Perhaps it should be re-written as a perl script--if I knew perl, I would volunteer. (That would mean not having to compile it, and would make modifications, if needed, simpler.) --PC From crossfire-request Sun Nov 20 20:04:45 1994 Return-Path: Received: from sfi.santafe.edu (sfi.santafe.edu [192.12.12.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sun, 20 Nov 1994 20:04:44 +0100 Received: by sfi.santafe.edu (4.1/SMI-4.1) id AA27001; Sun, 20 Nov 94 12:03:10 MST Date: Sun, 20 Nov 94 12:03:10 MST From: scott@santafe.edu (Scott D. Yelich) Message-Id: <9411201903.AA27001@sfi.santafe.edu> To: Mark Wedel Cc: crossfire@ifi.uio.no, preston.crow@dancer.dartmouth.edu Subject: Re: 90.1.6 problems In-Reply-To: Your message at 01:01:04 on Sun, 20 November 1994 References: <199411200901.AA10430@bolero.rahul.net> Status: RO >>>>> "Mark" == Mark Wedel writes: Mark> For the old client, version checking should probably be disabled Mark> - there I have never used the client. I always fire up the server and then use 'add. Why? The client I got with the server I compiled, never worked, it always complained about server versions. Is using a client any faster than using 'add from the server? Scott From crossfire-request Sun Nov 20 10:02:56 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sun, 20 Nov 1994 10:02:54 +0100 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA09513 (5.67b8/IDA-1.5 for ); Sun, 20 Nov 1994 01:02:49 -0800 Received: by bolero.rahul.net id AA10463 (5.67b8/IDA-1.5 for crossfire@ifi.uio.no); Sun, 20 Nov 1994 01:02:48 -0800 Date: Sun, 20 Nov 1994 01:02:48 -0800 From: Mark Wedel Message-Id: <199411200902.AA10463@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: 0.91.6 container/pickup fix. Status: RO Here is a patch. You will probably need to use the -l flag to patch, since this is just a quick cut and paste (and thus tabs are converted to spaces in this process) *** 1.12 1994/11/09 03:31:55 --- c_object.c 1994/11/19 06:17:22 *************** *** 281,287 **** void pick_up(object *op,object *alt) { ! object *tmp, *split; if(alt) tmp=alt; --- 281,287 ---- void pick_up(object *op,object *alt) { ! object *tmp=NULL, *split=NULL; if(alt) tmp=alt; *************** *** 326,334 **** * pick_up_object will split them again, but no easy solution * to that problem. */ ! if (tmp!=split) { tmp->nrof += split->nrof; ! free(split); } pick_up_object(op, alt, tmp, op->contr->count); op->contr->count=0; --- 326,334 ---- * pick_up_object will split them again, but no easy solution * to that problem. */ ! if (split && tmp!=split) { tmp->nrof += split->nrof; ! free_object(split); } pick_up_object(op, alt, tmp, op->contr->count); op->contr->count=0; --Mark From crossfire-request Sun Nov 20 10:01:17 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sun, 20 Nov 1994 10:01:16 +0100 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA09487 (5.67b8/IDA-1.5 for ); Sun, 20 Nov 1994 01:01:05 -0800 Received: by bolero.rahul.net id AA10430 (5.67b8/IDA-1.5); Sun, 20 Nov 1994 01:01:04 -0800 Date: Sun, 20 Nov 1994 01:01:04 -0800 From: Mark Wedel Message-Id: <199411200901.AA10430@bolero.rahul.net> To: crossfire@ifi.uio.no, preston.crow@dancer.dartmouth.edu Subject: Re: 90.1.6 problems Status: RO For the old client, version checking should probably be disabled - there is not protocol that the old client does - it is nothing more than a front end equivalant of using the telnet commands (it does the same thing.) The only thing the client does is some santiy checking (have usable display,etc.) It looks liek the only reason the client tries to compare versions is to see if you might have an up to date font. Since the font can easily be updated without the client knowing about it, there is not a lot of pont to do that. --Mark From crossfire-request Sat Nov 19 22:17:16 1994 Return-Path: Received: from dartvax.dartmouth.edu (dartvax.dartmouth.edu [129.170.16.4]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sat, 19 Nov 1994 22:17:15 +0100 Received: from dancer.Dartmouth.EDU (dancer.dartmouth.edu [129.170.208.7]) by dartvax.dartmouth.edu (8.6.9+DND/8.6.9) with SMTP id QAA08129 for ; Sat, 19 Nov 1994 16:17:13 -0500 Message-id: <9126000@dancer.Dartmouth.EDU> Date: 19 Nov 94 16:17:09 EST From: Preston.F.Crow@Dartmouth.EDU (Preston F. Crow) Reply-To: preston.crow@dancer.dartmouth.edu Subject: 90.1.6 problems To: crossfire@ifi.uio.no Status: RO Someone already mentioned that the server dies when you remove items from a container--we need a new release (or patch). Another problem that I found is that when connecting with the crossclient program, it refuses to let me use the 90.1.5 version, though since all it's doing is sending a few standard commands to a socket, it shouldn't need to be updated. Perhaps the server shouldn't make sure the version is current, or have the server know when the last change that really requires an upgrade was made. (Or have the commands changed in this version?) --PC From crossfire-request Sat Nov 19 16:27:59 1994 Return-Path: Received: from mailsun.aber.ac.uk (isode@mailsun.aber.ac.uk [144.124.16.7]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 19 Nov 1994 16:27:59 +0100 Received: from mailhost.aber.ac.uk (actually saturn.dcs.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (PP); Sat, 19 Nov 1994 15:27:52 +0000 To: crossfire@ifi.uio.no Subject: 09.1.6 Date: Sat, 19 Nov 1994 15:27:46 +0000 Message-ID: <3169.785258866@mailhost.aber.ac.uk> From: BENJAMIN THOMAS KETTERIDGE Status: RO I have finally managed to get crossfire 0.91.6 compiled after 3 days effort! And now I find that I can take things out of containers without crashing the game!! Help? Ben. +--------------------------------------------------------------------------+ | _|--|_ o | Disclaimer: I've got a baby, and I don't know what to do! | | (\/) +---+ +---------------------------------+-------------------------+ | vv / \ | But then, does anyone? :-) | btk@aber.ac.uk | +--------------+---------------------------------+-------------------------+ From crossfire-request Sat Nov 19 08:25:13 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 19 Nov 1994 08:25:11 +0100 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA06067 (5.67b8/IDA-1.5 for ); Fri, 18 Nov 1994 23:25:06 -0800 Received: by bolero.rahul.net id AA11340 (5.67b8/IDA-1.5 for crossfire@ifi.uio.no); Fri, 18 Nov 1994 23:25:00 -0800 Date: Fri, 18 Nov 1994 23:25:00 -0800 From: Mark Wedel Message-Id: <199411190725.AA11340@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: 0.91.6 release. Status: RO I have gotten several messages asking/reporting this problem, so I decided it would probably be a good idea to put out a global message about this. Several people have sent in reporting that they get errors like: ericserver.c: 5: Unable to find include file 'tcplib.h'. ericserver.c: 6: Unable to find include file 'xmalloc.h'. ericserver.c: 7: Unable to find include file 'libc.h'. ericserver.c: 8: Unable to find include file 'arglist.h'. ericserver.c: 9: Unable to find include file 'xfile.h'. When trying to compile. Two solutions: 1) Get the eutl library, which should be on the same ftp site you got this version of crossfire from. You then need to make the library before compiling crossfire (the process of making the library creates links to the header files in eutl/include). Mail any problems/bugs concerning the eutl library to Eric Anderson (eanders@cs.berkeley.edu), it is his package, and thus he maintains it. 2) Disable the #define ERICSERVER in include/newclient.h. Set it to be 0 instead of 1. Also, you need to remove the -leutl line from the common/crossfire.cf file (About line 115.) All of this has been fixed up for future versions, so it is just a simple #define in the config/crosssite.def file. -- I have also gotten reports of the function ArgList_AddChar missing from eutl (not sure if I got the caps right.) This may be due to using an old version of the eutl package, but I have yet to hear back from Eric if this is the cause. Unfortunately, no version is contained in the archive name, and I couldn't find a version looking through the actual files. I belive the archive that is 28691 bytes long is the latest release. --Mark From crossfire-request Sat Nov 19 01:43:33 1994 Return-Path: Received: from castor.cc.utu.fi (root@castor.cc.utu.fi [130.232.1.14]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sat, 19 Nov 1994 01:43:32 +0100 Received: by utu.fi id <165790-2>; Sat, 19 Nov 1994 02:43:27 +0200 Subject: Small map correction From: Tero Jyri Michael Pelander To: crossfire@ifi.uio.no Date: Sat, 19 Nov 1994 02:43:13 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Length: 395 Message-Id: <94Nov19.024327+0200_(eet).165790-2@utu.fi> Status: RO On location /world/world_a2 20,5 (version 0.91.6 maps) the teleporter throws the players to wrong location. This means that the players will end up in sea and they can't get away without 'dimension door' of 'word of recall' spells. The location is two squares west from the way to Santo Dominion. The Y coordinate should be 28, not 0. The previous map version seems to have the same bug too. From crossfire-request Fri Nov 18 12:28:49 1994 Return-Path: Received: from dira.bris.ac.uk (dira.bris.ac.uk [137.222.10.41]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 18 Nov 1994 12:28:39 +0100 Received: from kukini.cs.bris.ac.uk by dira.bris.ac.uk with SMTP (PP); Fri, 18 Nov 1994 11:28:15 +0000 Received: from talisker.pact.srf.ac.uk by kukini.compsci.bristol.ac.uk id aa19955; 18 Nov 94 11:30 GMT Received: from springbank.srf.ac.uk by pact.srf.ac.uk (5.0/SMI-SVR4) id AA19568; Fri, 18 Nov 94 11:27:41 GMT Received: from springbank (localhost) by springbank.srf.ac.uk (5.0/SMI-SVR4) id AA09676; Fri, 18 Nov 1994 11:27:34 +0000 Date: Fri, 18 Nov 1994 11:27:34 +0000 Message-Id: <9411181127.AA09676@springbank.srf.ac.uk> From: Simon McIntosh-Smith Sender: simonm@talisker.pact.srf.ac.uk To: crossfire@ifi.uio.no Mime-Version: 1.0 X-Mailer: Mozilla/0.9 beta (X11; SunOS 5.3 sun4m) Content-Type: multipart/mixed; boundary="-------------------------------1625111746835" Subject: crossfire server list X-Url: http://www.cm.cf.ac.uk/Crossfire/servers.html Content-Length: 4973 Status: RO ---------------------------------1625111746835 Content-Type: text/plain; charset=iso-8859-1 Here's the page of servers that I maintain on the web as promised. The URL to find the HTML version of this document is: http://www.cm.cf.ac.uk/Crossfire/servers.html Have fun! Simon > Crossfire Servers > > --------------------------------------------------- > > Last updated ... 18 Nov > > --------------------------------------------------- > > Here is an up-to-date list (last checked 18 Nov) of > crossfire servers that you can connect to and join in > the play! Use the following type of command: > > crossclient -server > > crossfire.csua.berkeley.edu (128.32.43.49) > port: 13326 (default) > running version: 0.91.5 > access time: 24 hours a day > max players: no restriction, but more than 4 is slow > other info: > X11R6 fontserver available on port 13325 > experimental server, may contain local developments > > clubx.anu.edu.au (150.203.63.36) > port: 13326 (default) > running version: 0.91.1 > access time: ?? > max players: ?? > other info: > unable to connect on last attempt - 17/11/94 > > yoko.ens-cachan.fr (138.231.10.24) > port: 13326 (default) > running version: 0.91.5 > access time: 24 hours a day > max players: no theoretical limit > other info: > running on a SparcStation > uses colour players > supports rplay option > unable to connect on last attempt - 17/11/94 > > corpse.ecst.csuchico.edu (132.241.5.10) > port: 13326 (default) > running version: 0.91.0 > access time: 24 hours a day > max players: no restriction, known to perform well with more than 8 > other info: > have been unable to connect for some time > > fermat.dartmouth.edu (129.170.28.31) > port: 13326 (default) > running version: 0.91.6 > access time: 24 hours a day > max players: ?? > other info: > running on a NeXT > development site for the Langley maps (Port Joseph) > > europa.informatik.uni-frankfurt.de (141.2.5.3) > port: 13326 (default) > running version: 0.91.2 > access time: ?? > max players: ?? > other info: > currently off-line? > > Want access to a game running behind an X firewall? > > If you know of others please e-mail me at the address below! > > ------------------------------------------------------------ > > > [Crossfire Home Page ] > Simon N. McIntosh-Smith > > Simon.N.Smith@cm.cf.ac.uk ---------------------------------1625111746835 Content-Type: text/plain [Image] Crossfire Servers ------------------------------------------------------------------------ Last updated ... 18 Nov ------------------------------------------------------------------------ Here is an up-to-date list (last checked 18 Nov) of crossfire servers that you can connect to and join in the play! Use the following type of command: crossclient -server crossfire.csua.berkeley.edu (128.32.43.49) port: 13326 (default) running version: 0.91.5 access time: 24 hours a day max players: no restriction, but more than 4 is slow other info: X11R6 fontserver available on port 13325 experimental server, may contain local developments clubx.anu.edu.au (150.203.63.36) port: 13326 (default) running version: 0.91.1 access time: ?? max players: ?? other info: unable to connect on last attempt - 17/11/94 yoko.ens-cachan.fr (138.231.10.24) port: 13326 (default) running version: 0.91.5 access time: 24 hours a day max players: no theoretical limit other info: running on a SparcStation uses colour players supports rplay option unable to connect on last attempt - 17/11/94 corpse.ecst.csuchico.edu (132.241.5.10) port: 13326 (default) running version: 0.91.0 access time: 24 hours a day max players: no restriction, known to perform well with more than 8 other info: have been unable to connect for some time fermat.dartmouth.edu (129.170.28.31) port: 13326 (default) running version: 0.91.6 access time: 24 hours a day max players: ?? other info: running on a NeXT development site for the Langley maps (Port Joseph) europa.informatik.uni-frankfurt.de (141.2.5.3) port: 13326 (default) running version: 0.91.2 access time: ?? max players: ?? other info: currently off-line? Want access to a game running behind an X firewall? If you know of others please e-mail me at the address below! ------------------------------------------------------------------------ [Crossfire Home Page ] Simon N. McIntosh-Smith Simon.N.Smith@cm.cf.ac.uk ---------------------------------1625111746835-- From crossfire-request Fri Nov 18 09:38:11 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 18 Nov 1994 09:38:10 +0100 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA12259 (5.67b8/IDA-1.5 for ); Fri, 18 Nov 1994 00:38:06 -0800 Received: by bolero.rahul.net id AA12250 (5.67b8/IDA-1.5 for crossfire@ifi.uio.no); Fri, 18 Nov 1994 00:38:06 -0800 Date: Fri, 18 Nov 1994 00:38:06 -0800 From: Mark Wedel Message-Id: <199411180838.AA12250@bolero.rahul.net> Subject: Re: servers list Cc: crossfire@ifi.uio.no Status: RO I try to keep an updated list of the servers in the README file that is in the top level of each crossfire distribution. If you have alterations/corrections from this list, let me know. You can send updates anytime you like, not just when a discussions starts about available servers. --Mark From crossfire-request Fri Nov 18 09:29:52 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 18 Nov 1994 09:29:49 +0100 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA12062 (5.67b8/IDA-1.5 for ); Fri, 18 Nov 1994 00:29:33 -0800 Received: by bolero.rahul.net id AA11891 (5.67b8/IDA-1.5); Fri, 18 Nov 1994 00:29:32 -0800 Date: Fri, 18 Nov 1994 00:29:32 -0800 From: Mark Wedel Message-Id: <199411180829.AA11891@bolero.rahul.net> To: master@rahul.net, tdoan@bnr.ca Subject: Re: Converting XPM to GIF problem Cc: crossfire@ifi.uio.no Status: RO Well, I am not responsible for compilation of other programs, and whether or not you have a messed up X11 installation. For example, if someone can not compile gcc (which they need to compile crossfire since they lack a native ansi C compiler), it is not me that they should send mail to on how to compile gcc. Likewise, xpmtoppm is not a program distributed or in any way associated with crossfire, except it can prove handy. Where to look in the xpmtoppm program to find its definition of where it expects the rgb.txt file, or where that file is actually installed on your system is not my problem. You will need to look through the files (and config options) of xpmtoppm and your system to see where the appropriate files are. IF you lack the knowledge or ability to do this, then contact your sysadmin or talk to someone who might know the answers (whoever maintains xpmtoppm if you can't find the seeting for the color database lcoation, or your site administartor for the location of the file.) My message was meant to state it was not any problem with the xpm images distributed with crossfire, but rather your installation of xpmtoppm. It is up to you to get that correct. --Mark From crossfire-request Fri Nov 18 01:21:21 1994 Return-Path: Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 18 Nov 1994 01:21:18 +0100 Received: from mail.crl.com by mail.crl.com with SMTP id AA14352 (5.65c/IDA-1.5 for ); Thu, 17 Nov 1994 16:20:09 -0800 Message-Id: <199411180020.AA14352@mail.crl.com> To: Simon McIntosh-Smith Cc: crossfire@ifi.uio.no, mehlhaff@crl.com Subject: Re: servers list In-Reply-To: Message from Simon McIntosh-Smith of Thu, 17 Nov 1994 19:19:00 +0000 <9411171919.AA09456@springbank.srf.ac.uk> Date: Thu, 17 Nov 1994 16:20:09 -0800 From: "'Most Excellent' Eric Mehlhaff" Status: RO Simon McIntosh-Smith recently wrote: >I can mail the page to this group if there are enough people without >web access who'd like a look. There are a handful of servers >detailed on the list that are still working, version 0.90.5 >being the most popular. > >Please mail me if you run a server and would like to advertise it! > >PS I'll try to keep the list more up-to-date in the future. The >date that the list was last modified is always displayed on >the page, so you know how reliable the information is when >you have a look for yourself... I just wanted to get your to modify the entry for teh CSUA crossfire server in your list -- it should point to 'crossfire.csua.berkeley.edu' instead of 'beer.csua.berkeley.edu'. They're currently teh same machine, but pointing players to the CNAME would make moving to better machines a lot easier for everyone involved. Eric Mehlhaff, mehlhaff@CSUA.berkeley.edu From crossfire-request Fri Nov 18 00:01:14 1994 Return-Path: Received: from eden-valley ([192.35.59.254]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 18 Nov 1994 00:01:04 +0100 Received: from albany (albany.aaii.oz.AU) by eden-valley with SMTP (5.65c/SMI-4.0/AAII) id AA05385; Fri, 18 Nov 1994 10:00:01 +1100 Received: from localhost by albany (8.6.8.1/8.6.6) with SMTP id KAA04777 for ; Fri, 18 Nov 1994 10:00:01 +1100 Message-Id: <199411172300.KAA04777@albany> X-Authentication-Warning: albany: rgg owned process doing -bs X-Authentication-Warning: albany: Host localhost didn't use HELO protocol To: crossfire@ifi.uio.no From: "Rupert G. Goldie" Reply-To: rgg@aaii.oz.au Subject: Re: Linux compiled? In-Reply-To: Message from Elvis Impersonator of 1994-Nov-17 3:40:9, <199411170940.DAA13364@doc.cc.utexas.edu> Date: Fri, 18 Nov 1994 10:00:00 +1100 Sender: rgg@aaii.oz.au Status: RO Elvis Impersonator wrote: > Anyone out there managed to compile Crossfire > on a linux box? I love crossfire but, the lag is > hellish over my Slip connection :) > I haven't tried the latest version, but I have happily compiled many of the last few versions of Crossfire quite easily under Linux. It works quite nicely as long as you have a bit of memory (When I had 4 Meg of RAM it was unusably slow) -- Rupert G. Goldie, Research Scientist rgg@aaii.oz.au Australian Artificial Intelligence Institute /\/\|| Level 6, 171 Latrobe Street, Melbourne, Australia From crossfire-request Thu Nov 17 20:20:16 1994 Return-Path: Received: from dira.bris.ac.uk (dira.bris.ac.uk [137.222.10.41]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 17 Nov 1994 20:20:04 +0100 Received: from kukini.cs.bris.ac.uk by dira.bris.ac.uk with SMTP (PP); Thu, 17 Nov 1994 19:19:35 +0000 Received: from talisker.pact.srf.ac.uk by kukini.compsci.bristol.ac.uk id aa29939; 17 Nov 94 19:21 GMT Received: from springbank.srf.ac.uk by pact.srf.ac.uk (5.0/SMI-SVR4) id AA15150; Thu, 17 Nov 94 19:19:07 GMT Received: by springbank.srf.ac.uk (5.0/SMI-SVR4) id AA09456; Thu, 17 Nov 1994 19:19:05 +0000 From: Simon McIntosh-Smith Message-Id: <9411171919.AA09456@springbank.srf.ac.uk> Subject: servers list To: crossfire@ifi.uio.no Date: Thu, 17 Nov 1994 19:19:00 +0000 (GMT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 911 Status: RO Hi all, following the recent discussion regarding up-to-date lists of active crossfire servers, I went through the list maintained within my Crossfire pages at Cardiff. Many of the older servers appear to have gone, perhaps unsurprisingly. This leaves the list looking a little bear, so perhaps we could add some new servers to it? The list can be found at: http://www.cm.cf.ac.uk/Crossfire/servers.html I can mail the page to this group if there are enough people without web access who'd like a look. There are a handful of servers detailed on the list that are still working, version 0.90.5 being the most popular. Please mail me if you run a server and would like to advertise it! Sy PS I'll try to keep the list more up-to-date in the future. The date that the list was last modified is always displayed on the page, so you know how reliable the information is when you have a look for yourself... From crossfire-request Thu Nov 17 10:40:23 1994 Return-Path: Received: from doc.cc.utexas.edu (gap@doc.cc.utexas.edu [128.83.108.14]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 17 Nov 1994 10:40:20 +0100 Received: (from gap@localhost) by doc.cc.utexas.edu (8.6.8.1/8.6.6/cc-wf-sunos.mc-1.1) id DAA13364 for crossfire@ifi.uio.no; Thu, 17 Nov 1994 03:40:13 -0600 From: Elvis Impersonator Message-Id: <199411170940.DAA13364@doc.cc.utexas.edu> Subject: Linux compiled? To: crossfire@ifi.uio.no Date: Thu, 17 Nov 1994 03:40:09 -0600 (CST) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 214 Status: RO Anyone out there managed to compile Crossfire on a linux box? I love crossfire but, the lag is hellish over my Slip connection :) btw, what does a cursed potion of magic power do? take your sp away? thanks gap From crossfire-request Thu Nov 17 10:38:36 1994 Return-Path: Received: from wilma.cs.city.ac.uk (wilma.cs.city.ac.uk [138.40.91.9]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 17 Nov 1994 10:38:35 +0100 Received: by wilma.cs.city.ac.uk (Smail3.1.28.1 #14) id m0r83II-0004Y5C; Thu, 17 Nov 94 09:38 GMT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.wilma.cs.city.ac.uk.sun4.41 via MS.5.6.wilma.cs.city.ac.uk.sun4_41; Thu, 17 Nov 1994 09:38:18 +0000 (GMT) Message-ID: Date: Thu, 17 Nov 1994 09:38:18 +0000 (GMT) From: Nick Williams To: crossfire@ifi.uio.no, BENJAMIN THOMAS KETTERIDGE Subject: Re: Colonization on ftp server cs.city.ac.uk CC: Paul M Davis In-Reply-To: <13115.784995847@mailhost.aber.ac.uk> References: <13115.784995847@mailhost.aber.ac.uk> Status: RO [please followup to me directly, or to pmd@cs.city.ac.uk] Excerpts from games.Crossfire: 16-Nov-94 BENJAMIN KETTERIDGE@aber (699) > On the ftp server at ftp.cs.ctiy.ac.uk, in the games directory, there > is crossfire, but next to it, there is a directory called colonization. > I'm intrigued! What is colonization, and why is there just an editor in > the directory on the ftp server. Colonization is a commercial game for PCs, which one of our dedicated computer science researchers doesn't spend any time at all playing. Oh no. Heaven forfend :). Anyway, he's written some sort of editor for the games maps, players and other things like that [I think]. For any more details about it, email pmd@cs.city.ac.uk. I'll get him to update the message/txt file in that directory to give people a bit more of a clue... Nick Williams, Systems Architecture Research Centre, City University, London, EC1V 0HB. UK. Web: http://web.cs.city.ac.uk/finger?njw E-mail: njw@sarc.city.ac.uk (MIME and ATK) Work Telephone: +44 71 477 8551 Work Fax: +44 71 477 8587 From crossfire-request Thu Nov 17 05:42:32 1994 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 17 Nov 1994 05:42:29 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 16 Nov 1994 23:41:33 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 16 Nov 1994 23:40:42 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 14 Nov 1994 23:40:00 -0500 Date: Wed, 16 Nov 1994 22:40:00 -0600 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.051:17.10.94.04.40.42] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Convertin... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"18089 Wed Nov 16 23:41:25 1994"@bnr.ca> To: master@rahul.net Cc: crossfire@ifi.uio.no Subject: Re: Converting XPM to GIF problem Status: RO In message "Re: Converting XPM to GIF problem", 'master@rahul.net' writes: > sounds to me that whenever xpmtoppm was compiled, the path to the X11 >color database was not set correctly. Forgive my ignorance, but the above doesn't help me a bit. What I need to know is what file(s) and where they should be. Our X11R5 library is probably screwed and I would like to know what is wrong :-) Thanks, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 214-684-4575 Fax: 214-684-3716 Internet: tdoan@bnr.ca WWW: http://47.53.64.96/tdoan/tdoan.html From crossfire-request Wed Nov 16 20:28:28 1994 Return-Path: Received: from dartvax.dartmouth.edu (dartvax.dartmouth.edu [129.170.16.4]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 16 Nov 1994 20:28:23 +0100 Received: from fermat.dartmouth.edu (fermat.dartmouth.edu [129.170.28.31]) by dartvax.dartmouth.edu (8.6.9+DND/8.6.9) with SMTP id OAA09961 for ; Wed, 16 Nov 1994 14:26:53 -0500 Received: by fermat.dartmouth.edu (NX5.67d/NX3.0S) id AA02536; Wed, 16 Nov 94 14:24:07 -0500 Date: Wed, 16 Nov 94 14:24:07 -0500 From: Michael Glenn Message-Id: <9411161924.AA02536@fermat.dartmouth.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: crossfire servers Status: RO I know several random people have popped onto my machine, so I knew my machine must have been listed somewhere. I found it... The www Cardiff Crossfire page has a link to what they say is an "up-to-date" listing of servers. The Cardiff page is at http://www.cm.cf.ac.uk/Crossfire/ and the server list is at: http://www.cm.cf.ac.uk/Crossfire/servers.html I can't speak for the other servers listed there, but mine (at fermat.dartmouth.edu 13326) is still up and running... The person who maintains the list is named there, so maybe people who have servers that are not on the list will (should?) send him mail? Michael From crossfire-request Wed Nov 16 15:24:49 1994 Return-Path: Received: from mailsun.aber.ac.uk (isode@mailsun.aber.ac.uk [144.124.16.7]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 16 Nov 1994 15:24:48 +0100 Received: from mailhost.aber.ac.uk (actually saturn.dcs.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (PP); Wed, 16 Nov 1994 14:24:20 +0000 To: crossfire@ifi.uio.no Date: Wed, 16 Nov 1994 14:24:07 +0000 Message-ID: <13115.784995847@mailhost.aber.ac.uk> From: BENJAMIN THOMAS KETTERIDGE Status: RO This is really only addressed to those at cs.city.ac.uk. On the ftp server at ftp.cs.ctiy.ac.uk, in the games directory, there is crossfire, but next to it, there is a directory called colonization. I'm intrigued! What is colonization, and why is there just an editor in the directory on the ftp server. Ben. +--------------------------------------------------------------------------+ | _|--|_ o | Disclaimer: I've got a baby, and I don't know what to do! | | (\/) +---+ +---------------------------------+-------------------------+ | vv / \ | But then, does anyone? :-) | btk@aber.ac.uk | +--------------+---------------------------------+-------------------------+ From crossfire-request Wed Nov 16 08:54:18 1994 Return-Path: Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 16 Nov 1994 08:54:15 +0100 Received: from mail.crl.com by mail.crl.com with SMTP id AA15142 (5.65c/IDA-1.5 for ); Tue, 15 Nov 1994 23:53:22 -0800 Message-Id: <199411160753.AA15142@mail.crl.com> To: Peter Mardahl Cc: crossfire@ifi.uio.no, mehlhaff@crl.com Subject: Re: crossfire servers In-Reply-To: Message from Peter Mardahl of Tue, 15 Nov 1994 22:59:00 -0800 <199411160659.WAA24256@soda.CSUA.Berkeley.EDU> Date: Tue, 15 Nov 1994 23:53:22 -0800 From: "'Most Excellent' Eric Mehlhaff" Status: RO Peter Mardahl recently wrote: > >The only puglic server that I know of which is still running >is our own: > >beer.csua.berkeley.edu >13326 Really, you all should be accessing that as 'crossfire.csua.berkeley.edu' in case we want to move it to a better machine. Eric Mehlhaff, mehlhaff@CSUA.berkeley.edu From crossfire-request Wed Nov 16 08:49:54 1994 Return-Path: Received: from dragon.cit.gu.edu.au (dragon.cit.gu.edu.au [132.234.5.27]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 16 Nov 1994 08:49:45 +0100 Received: by dragon.cit.gu.edu.au id AA22517 (5.67b/IDA-1.5 for crossfire@ifi.uio.no); Wed, 16 Nov 1994 17:49:06 +1000 Date: Wed, 16 Nov 1994 17:49:06 +1000 From: Anthony Thyssen Message-Id: <199411160749.AA22517@dragon.cit.gu.edu.au> To: crossfire@ifi.uio.no Subject: Re: crossfire servers In-Reply-To: Mail from 'Peter Mardahl ' dated: Tue, 15 Nov 1994 22:59:00 -0800 X-Face: "Ech/vWX*#{vKw-OiDaKqy:=y'Kqji( Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 16 Nov 1994 07:59:08 +0100 Received: (peterm@localhost) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) id WAA24256 for crossfire@ifi.uio.no; Tue, 15 Nov 1994 22:59:00 -0800 Date: Tue, 15 Nov 1994 22:59:00 -0800 From: Peter Mardahl Message-Id: <199411160659.WAA24256@soda.CSUA.Berkeley.EDU> To: crossfire@ifi.uio.no Subject: crossfire servers Status: RO The only puglic server that I know of which is still running is our own: beer.csua.berkeley.edu 13326 PeterM From crossfire-request Wed Nov 16 06:52:57 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 16 Nov 1994 06:52:54 +0100 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA01740 (5.67b8/IDA-1.5 for ); Tue, 15 Nov 1994 21:52:38 -0800 Received: by bolero.rahul.net id AA29752 (5.67b8/IDA-1.5); Tue, 15 Nov 1994 21:52:36 -0800 Date: Tue, 15 Nov 1994 21:52:36 -0800 From: Mark Wedel Message-Id: <199411160552.AA29752@bolero.rahul.net> To: crossfire@ifi.uio.no, tdoan@bnr.ca Subject: Re: Converting XPM to GIF problem Status: RO sounds to me that whenever xpmtoppm was compiled, the path to the X11 color database was not set correctly. From crossfire-request Wed Nov 16 06:45:50 1994 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 16 Nov 1994 06:45:47 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 16 Nov 1994 00:45:04 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 16 Nov 1994 00:44:57 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 14 Nov 1994 00:45:00 -0500 Date: Tue, 15 Nov 1994 23:45:00 -0600 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.135:16.10.94.05.44.57] X400-Content-Type: P2-1984 (2) Content-Identifier: Converting XP... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"17140 Wed Nov 16 00:45:00 1994"@bnr.ca> To: crossfire@ifi.uio.no Subject: Converting XPM to GIF problem Status: RO Hello, I'm trying to convert XPM to GIF using netpbm and I get the following error: xpmtoppm: can't open color names database - reconfigure with correct RGBDEF It would seem that the color names being used is not recognized by xpmtoppm. Is there a solution to this problem? Thanks, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 214-684-4575 Fax: 214-684-3716 Internet: tdoan@bnr.ca WWW: http://47.53.64.96/tdoan/tdoan.html From crossfire-request Wed Nov 16 06:32:21 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 16 Nov 1994 06:32:18 +0100 Received: (philb@localhost) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) id VAA14248 for crossfire@ifi.uio.no; Tue, 15 Nov 1994 21:32:12 -0800 From: Philip Brown Message-Id: <199411160532.VAA14248@soda.CSUA.Berkeley.EDU> Subject: Re: Crossfire 0.91.6 released. To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Tue, 15 Nov 1994 21:32:10 -0800 (PST) In-Reply-To: <9411160008.AA08002@erau.db.erau.edu> from "kochank@db.erau.edu" at Nov 15, 94 07:08:55 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 440 Status: RO (Hey... don't forget the lowly return key every 75 chars) >>>>[From kochank@db.erau.edu] Hey Mark.. How do I get the client to work? I know you want specifics but it won't even start to compile.. accualy when I type 'xmkfm -a' (or something like that :) it gives me a commandline for xmkfm.. weird.. Do it the hard way. xmkmf make Makefiles make depend make that's what the -a flag is supposed to do anyways. From crossfire-request Wed Nov 16 05:22:10 1994 Return-Path: Received: from whatever.cs.jhu.edu (jeffqyzt@whatever.cs.jhu.edu [128.220.13.27]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 16 Nov 1994 05:22:07 +0100 Received: by whatever.cs.jhu.edu; Tue, 15 Nov 1994 23:21:25 -0500 Sender: jeffqyzt@whatever.cs.jhu.edu Date: Tue, 15 Nov 1994 23:21:24 -0500 (EST) From: Jeff Goodson To: crossfire@ifi.uio.no Subject: Active servers lists? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Er, not to start a "me too," but I would also like to have a list of servers that are running crossfire; I'd like to play, but I don't have enough room on my computer to compile myself. It'd kinda defeat the multi-player aspects anyway; anyone willing to hook me up with a site or two? (")-(") If the mice are eating more than you are, buy cheaper food. (O O) If they're eating better than you are, eat the mice. =\ /= ---------------------------------------------------------------- * Jeff Goodson * jeffqyzt@cs.jhu.edu * jeffqyzt@jhunix.hcf.jhu.edu ---------- Forwarded message ---------- Date: Tue, 15 Nov 94 19:08:55 EST From: kochank@db.erau.edu To: crossfire@ifi.uio.no Subject: Re: Crossfire 0.91.6 released. Hey Mark.. How do I get the client to work? I know you want specifics but it won't even start to compile.. accualy when I type 'xmkfm -a' (or something like that :) it gives me a commandline for xmkfm.. weird.. Ohh well.. its proly my end.. I love crossfire :) Btw.. do you have a list of servers running crossfire? seems most of the ones I had refuse connection... Thanks, Q From crossfire-request Wed Nov 16 01:05:01 1994 Return-Path: Received: from db.erau.edu (db.erau.edu [155.31.1.13]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 16 Nov 1994 01:04:58 +0100 From: kochank@db.erau.edu Received: from erau.db.erau.edu by db.erau.edu with smtp (Smail3.1.28.1 #2) id m0r7XsQ-0007vtC; Tue, 15 Nov 94 19:05 EST Received: by erau.db.erau.edu (4.1/client/jimberau-1.0) id AA08002; Tue, 15 Nov 94 19:08:55 EST Date: Tue, 15 Nov 94 19:08:55 EST Message-Id: <9411160008.AA08002@erau.db.erau.edu> To: crossfire@ifi.uio.no Subject: Re: Crossfire 0.91.6 released. Status: RO Hey Mark.. How do I get the client to work? I know you want specifics but it won't even start to compile.. accualy when I type 'xmkfm -a' (or something like that :) it gives me a commandline for xmkfm.. weird.. Ohh well.. its proly my end.. I love crossfire :) Btw.. do you have a list of servers running crossfire? seems most of the ones I had refuse connection... Thanks, Q From crossfire-request Tue Nov 15 23:49:32 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 15 Nov 1994 23:49:28 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id OAA28909; Tue, 15 Nov 1994 14:15:55 -0800 Message-Id: <199411152215.OAA28909@soda.CSUA.Berkeley.EDU> To: scott@santafe.edu (Scott D. Yelich) cc: crossfire@ifi.uio.no Subject: Re: maps In-reply-to: Your message of "Tue, 15 Nov 1994 11:33:43 MST." <9411151833.AA03578@sfi.santafe.edu> Date: Tue, 15 Nov 1994 14:14:53 -0800 From: Peter Mardahl Status: RO In message <9411151833.AA03578@sfi.santafe.edu>, Scott D. Yelich writes: > > >I would *love* to work on a medium level map... if there was a nice >GUI map drawing program. > >what's the word? crossedit is the word. It comes with the crossfire distribution, and is quite a nifty map drawing program. PeterM From crossfire-request Tue Nov 15 19:35:15 1994 Return-Path: Received: from sfi.santafe.edu (sfi.santafe.edu [192.12.12.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 15 Nov 1994 19:35:12 +0100 Received: by sfi.santafe.edu (4.1/SMI-4.1) id AA03578; Tue, 15 Nov 94 11:33:43 MST Date: Tue, 15 Nov 94 11:33:43 MST From: scott@santafe.edu (Scott D. Yelich) Message-Id: <9411151833.AA03578@sfi.santafe.edu> To: crossfire@ifi.uio.no Subject: maps Status: RO I would *love* to work on a medium level map... if there was a nice GUI map drawing program. what's the word? Scott From crossfire-request Tue Nov 15 18:50:25 1994 Return-Path: Received: from sdaf1.cea.berkeley.edu (sdaf1.cea.berkeley.edu [128.32.154.11]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 15 Nov 1994 18:50:13 +0100 From: daemon@cea.Berkeley.EDU Received: from localhost (daemon@localhost) by sdaf1.cea.berkeley.edu (8.6.4/CEA) id JAA25737 for crossfire@ifi.uio.no; Tue, 15 Nov 1994 09:50:00 -0800 Date: Tue, 15 Nov 1994 09:50:00 -0800 Message-Id: <199411151750.JAA25737@sdaf1.cea.berkeley.edu> To: crossfire@ifi.uio.no Subject: Re: Crossfire 0.91.6 released. Status: RO The following mail is not deliverable. rfanta no longer works at the Space Sciences Lab, and there is no fowarding address. From owner-crossfire@ifi.uio.no Tue Nov 15 09:49:58 1994 Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by sdaf1.cea.berkeley.edu (8.6.4/CEA) with ESMTP id JAA25726 for ; Tue, 15 Nov 1994 09:49:54 -0800 Received: from surt.ifi.uio.no (1232@surt.ifi.uio.no [129.240.76.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 15 Nov 1994 17:20:15 +0100 Received: (from kjetilho@localhost) by surt.ifi.uio.no ; Tue, 15 Nov 1994 17:20:14 +0100 Date: Tue, 15 Nov 1994 17:20:14 +0100 Message-Id: <199411151620.8330.surt.ifi.uio.no@ifi.uio.no> To: crossfire-announce@ifi.uio.no From: Mark Wedel Sender: Kjetil T Homme Reply-To: Crossfire Discussion list Subject: Crossfire 0.91.6 released. Status: R [This was supposed to go out almost a week ago. I apologise for the mix-up -- Kjetil T.] There are four separate tar archives in the Crossfire 0.91.6 distribution: sums (bsd) filename 47339 600 crossfire-0.91.6.arch.tar.gz 64975 69 crossfire-0.91.6.client.tar.gz 03843 1361 crossfire-0.91.6.maps.tar.gz 60609 1280 crossfire-0.91.6.tar.g crossfire-0.91.6.tar.gz contains the actual program code, as well as premade archetype, bitmaps, and xpm files. See the CHANGES file in this archive for everything that has changed. crossfire-0.91.6.maps.tar.gz contains all the maps. I have started work on a second continent, but a lot more work is still needed. crossfire-0.91.6.arch.tar.gz contains the unpacked archetype (arch) directory. This file is not needed if you just want to compile the games and play. The contents of this archive is used to create the archetypes, bmaps, font, and X PixMap (XPM) files. You only need it if you want to add new archetypes, or mess around with the existing ones. I am not sure what has changed from the 0.91.5 version, but I do know that the tar files at least are different. crossfire-0.91.6.client.tar.gz is the client program. This is largely Eric Anderson's version, with some of my code added in. You do not need this file to play the game - the old X11 support is still in place NOTE: I originally was just going to make a 'snapshot' version so that other people working on client/server all have the same code. But I decided I might as well make a full release. As such, I am not fully sure of the stability of this version, but it is probably about as good as most other releases that are made. But all the 0.91.6 files should probably be considered about beta level The eutl package is required to compile the client and the server (if you want to use the new client code. If you don't, change the ERICSERVER #define in newclient.h to 0). Also, you will need to edit crossfire.cf (about line 115) (or the Makefile's) to remove -leutl. (I will fix this up for the next version). AVAILABILITY: Crossfire is avaible on the following ftp sites Primary: ftp.i.net:/pub/crossfire2 (192.243.32.18) ftp.ifi.uio.no:/pub/crossfire (129.240.82.2) Secondary: yoyo.cc.monash.edu.au:/pub/crossfire (130.194.9.1) ftp.cs.city.ac.uk:/pub/games/crossfire/ ftp.sunet.se:/pub/unix/games/crossfire (130.238.127.3) I uploaded this version to both primary sites, there may be a slight delay for the secondary sites to receive this. Note: The ftp.i.net site has two crossfire directories - /pub/crossfire and /pub/crossfire2 The new source is in the later directory. Mark Wedel master@rahul.net From crossfire-request Tue Nov 15 07:05:40 1994 Return-Path: Received: from ghoul.ecst.csuchico.edu (ghoul.ecst.csuchico.edu [132.241.7.10]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 15 Nov 1994 07:05:35 +0100 Received: (from tvangod@localhost) by ghoul.ecst.csuchico.edu (8.6.8/8.6.6) id WAA03509 for crossfire@ifi.uio.no; Mon, 14 Nov 1994 22:10:40 -0800 From: Tyler Van Gorder Message-Id: <199411150610.WAA03509@ghoul.ecst.csuchico.edu> Subject: skud maps To: crossfire@ifi.uio.no Date: Mon, 14 Nov 1994 22:10:40 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 728 Status: RO Hello, since I have had so many requests for the "complete" skud maps...well I finally got around to putting them on an ftp site: hairball.ecst.csuchico.edu in /pub/crossfire The problem: Its been a long time since I have played with the maps so......I am not sure which is the most complete set..I had two sets....so... There is a skud1.tar.gz <--- try that first... and there is a skud2.tar.gz <--- try that second if the first sucks :> I dont have crossedit any longers so i cant really say which is which..doh. anyway untar these in the direcorty /lib/maps/skud Tyler. ps. These maps are designed to work some of the higher level chars....be warned EVERY monster has been modified :> From crossfire-request Tue Nov 15 06:41:03 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 15 Nov 1994 06:40:59 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id VAA28798; Mon, 14 Nov 1994 21:40:48 -0800 Message-Id: <199411150540.VAA28798@soda.CSUA.Berkeley.EDU> To: Mark Wedel cc: crossfire@ifi.uio.no Subject: Re: CF: Another success story. In-reply-to: Your message of "Mon, 14 Nov 1994 21:13:47 PST." <199411150513.AA05642@bolero.rahul.net> Date: Mon, 14 Nov 1994 21:40:46 -0800 From: Peter Mardahl Status: RO In message <199411150513.AA05642@bolero.rahul.net>, Mark Wedel writes: > But to put it simply, most of the brittany/brest maps are not >particulary good. But it is one of the few sets of maps for high >level characters (dragon cave is another), so I don't really want >to take it completely out. > What do people think of the dragoncave map anyway? One person gave me some positive feedback on it, saying it was one of the few maps which was actually still challenging. I'm wondering if it's OK as is, or if i should add some more character to it? Is the treasure balanced? Is the difficulty curve too steep? Does it make folks think that fire/cold immunity don't belong in the game, or that electricity immunity should be added also? The pixmap artwork on that map is pretty good IMHO, and I encourage some people to "cut" and "paste" from those maps (and edit!) when you want to build cool caves. Different types of floors are easy to achieve also: just do a global search and replace on the archname of the common types of floors and clean the rest up by hand. It turns out that building realistic-looking cave walls is lots of work, and so I encourage people to borrow (cut and paste) from the dragoncave maps rather than building your own. Any other suggestions/comments on the dragoncave? (It's my newest set of maps so I still consider it in beta release....) Regards, PeterM From crossfire-request Tue Nov 15 06:14:39 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 15 Nov 1994 06:14:34 +0100 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA05281 (5.67b8/IDA-1.5 for ); Mon, 14 Nov 1994 21:13:48 -0800 Received: by bolero.rahul.net id AA05642 (5.67b8/IDA-1.5); Mon, 14 Nov 1994 21:13:47 -0800 Date: Mon, 14 Nov 1994 21:13:47 -0800 From: Mark Wedel Message-Id: <199411150513.AA05642@bolero.rahul.net> To: fermat@fermat.dartmouth.edu, peterm@CSUA.Berkeley.EDU Subject: Re: CF: Another success story. Cc: crossfire@ifi.uio.no Status: RO I fixed it up. Took out a bit of the treasure, took out most of the dragons, but put one buffed up ragon there instead. And put in a set of gates, and antimagic squres down the corrdier, so to kill the dragon, it will be able to attack you. This should be a bit more fair. But to put it simply, most of the brittany/brest maps are not particulary good. But it is one of the few sets of maps for high level characters (dragon cave is another), so I don't really want to take it completely out. --Mark From crossfire-request Mon Nov 14 22:19:15 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 14 Nov 1994 22:19:10 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id NAA01382; Mon, 14 Nov 1994 13:18:59 -0800 Message-Id: <199411142118.NAA01382@soda.CSUA.Berkeley.EDU> To: Michael Glenn cc: crossfire@ifi.uio.no Subject: Re: CF: Another success story. In-reply-to: Your message of "Mon, 14 Nov 1994 15:46:22 EST." <9411142046.AA24580@fermat.dartmouth.edu> Date: Mon, 14 Nov 1994 13:18:57 -0800 From: Peter Mardahl Status: RO In message <9411142046.AA24580@fermat.dartmouth.edu>, Michael Glenn writes: ..story of quick and easy money deleted... *sigh* Sounds like a broken map to me. Who wants to fix it? Regards, PeterM From crossfire-request Mon Nov 14 21:46:51 1994 Return-Path: Received: from dartvax.dartmouth.edu (dartvax.dartmouth.edu [129.170.16.4]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 14 Nov 1994 21:46:48 +0100 Received: from fermat.dartmouth.edu (fermat.dartmouth.edu [129.170.28.31]) by dartvax.dartmouth.edu (8.6.9+DND/8.6.9) with SMTP id PAA20939 for ; Mon, 14 Nov 1994 15:46:43 -0500 Received: by fermat.dartmouth.edu (NX5.67d/NX3.0S) id AA24580; Mon, 14 Nov 94 15:46:22 -0500 Date: Mon, 14 Nov 94 15:46:22 -0500 From: Michael Glenn Message-Id: <9411142046.AA24580@fermat.dartmouth.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: CF: Another success story. Status: RO Just thought I'd share this success story... Possible spoilers below! I had a 9th level Viking, working his way up slowly. I found a horn of fire. Yay!!!! I bought a scroll of word of recall, and went down into the church in Brest. Went through the maze to the single corridor that leads to the 30 or so electric dragons. It took about 20-25 minutes, but eventually I killed them all with repeated fire blasts. I got about 1 million xp's (from 230,000 to 1,280,000), went up to level 12, and got gobs and gobs of rings and wands and gems. Of course, I took 6 of the dragon scales back to make dragon armor and shield, and spent maybe half the money I made to buy them (cha 12). There is nothing stopping me from repeatedly going back to the dragons and getting all the money and gems I'll ever need. Oh, and there are often artifacts to be found in the secret compartments where the dragons are. I went through a second time today, and got dragon armor (which I sold cause I already made it the last time). :) Oh, a warning. If you never went down into the church before, be careful! Almost all of the squares in the maze will not allow you to cast spells to recall out. If you cannot solve the maze, you might be in trouble. Michael From crossfire-request Fri Nov 11 21:44:25 1994 Return-Path: Received: from gyda.ifi.uio.no (gyda.ifi.uio.no [129.240.78.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id ; Fri, 11 Nov 1994 21:44:24 +0100 From: =?iso-8859-1?Q?H=E5vard_Lindheim?= MIME-Version: 1.0 Received: (from haavarl@localhost) by gyda.ifi.uio.no ; Fri, 11 Nov 1994 21:43:53 +0100 Date: Fri, 11 Nov 1994 21:43:52 +0100 To: Tero Jyri Michael Pelander Cc: crossfire@ifi.uio.no Subject: Re: cf (0.91.5) - bug in comet spell (nasty) In-Reply-To: Tero Jyri Michael Pelander 's message of Fri, 11 Nov 1994 02:30:38 +0200 (EET) References: <94Nov11.023039+0200_(eet).165466-1@utu.fi> Message-ID: Status: RO > !!! when you have high enough level the initial impact from > !!! comet (weaponmagic attack) heals you!!!! > > For example at level 68 (int 30) it heals you 232 hitpoints. At level 89 it > heals about 200 hits. This heal can push your hitpoints over the maxinum. Ah yes. Then you should try the utter hp trick... If you're at high enough level, summon earth elemental and let him hit you. See how the hp's boost... Heh... might be changed in the new version though... H&L From crossfire-request Fri Nov 11 02:23:21 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 11 Nov 1994 02:23:18 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id RAA23714; Thu, 10 Nov 1994 17:23:00 -0800 Message-Id: <199411110123.RAA23714@soda.CSUA.Berkeley.EDU> To: Tero Jyri Michael Pelander cc: crossfire@ifi.uio.no Subject: Re: cf (0.91.5) - bug in comet spell (nasty) In-reply-to: Your message of "Fri, 11 Nov 1994 02:30:38 +0200." <94Nov11.023039+0200_(eet).165466-1@utu.fi> Date: Thu, 10 Nov 1994 17:22:57 -0800 From: Peter Mardahl Status: RO In message <94Nov11.023039+0200_(eet).165466-1@utu.fi>, Tero Jyri Michael Pelan der writes: >Ok. While playing with the comet spell I wondered how many of them it would >take to kill a jessy. I started testing this using the dm mode to >create a test character. What I found out was that > !!! when you have high enough level the initial impact from > !!! comet (weaponmagic attack) heals you!!!! > >For example at level 68 (int 30) it heals you 232 hitpoints. At level 89 it >heals about 200 hits. This heal can push your hitpoints over the maxinum. >Specially as there exists spell immunity to fire that will negate the >secondary attack the players can pump up the hitpoints with this. > >Btw. my real crossfire character is at level 68. Oh, how amusing. I know exactly why. The "damage" variable, dam, is a byte only, and think it's signed or something. So if it exceeds 127, it starts doing negative damage. I recommmend promoting the variable to int. Regards, PeterM From crossfire-request Fri Nov 11 01:30:43 1994 Return-Path: Received: from castor.cc.utu.fi (root@castor.cc.utu.fi [130.232.1.14]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 11 Nov 1994 01:30:42 +0100 Received: by utu.fi id <165466-1>; Fri, 11 Nov 1994 02:30:39 +0200 Subject: cf (0.91.5) - bug in comet spell (nasty) From: Tero Jyri Michael Pelander To: crossfire@ifi.uio.no Date: Fri, 11 Nov 1994 02:30:38 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Length: 644 Message-Id: <94Nov11.023039+0200_(eet).165466-1@utu.fi> Status: RO Ok. While playing with the comet spell I wondered how many of them it would take to kill a jessy. I started testing this using the dm mode to create a test character. What I found out was that !!! when you have high enough level the initial impact from !!! comet (weaponmagic attack) heals you!!!! For example at level 68 (int 30) it heals you 232 hitpoints. At level 89 it heals about 200 hits. This heal can push your hitpoints over the maxinum. Specially as there exists spell immunity to fire that will negate the secondary attack the players can pump up the hitpoints with this. Btw. my real crossfire character is at level 68. From crossfire-request Wed Nov 9 09:37:24 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 9 Nov 1994 09:37:11 +0100 Received: (philb@localhost) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) id AAA02702 for crossfire@ifi.uio.no; Wed, 9 Nov 1994 00:36:58 -0800 From: Philip Brown Message-Id: <199411090836.AAA02702@soda.CSUA.Berkeley.EDU> Subject: Re: Client/Server Implementation To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Wed, 9 Nov 1994 00:36:56 -0800 (PST) In-Reply-To: <199411050801.AA27576@bolero.rahul.net> from "Mark Wedel" at Nov 5, 94 00:01:50 am X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 759 Status: RO My vote for whatt is important: 12ACD :-) A more verbose description follows. Just follow good coding practice. 1) Stick to the write-up as much as possible. 2) Implement a minimally functioning set of the protocol, to get it out there fast, but bug-clean. 2.1) Have a very dumb client at first, that only uses the minimal protocol set. 3) add further protocol items from the list bit by bit, ensuring that each of them works as it is supposed to. A corollary: make it so that a client does not HAVE to know about all the nifty-special protocol commands available to it. This will make testing new clients much much easier. Note that, IMO, the goal is to get it out there FAST, but to ALSO get it out there _right_. From crossfire-request Wed Nov 9 08:22:58 1994 Return-Path: Received: from castor.cc.utu.fi (root@castor.cc.utu.fi [130.232.1.14]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 9 Nov 1994 08:22:57 +0100 Received: by utu.fi id <167290-2>; Wed, 9 Nov 1994 09:22:52 +0200 Subject: cf (0.91.5) crasher From: Tero Jyri Michael Pelander To: crossfire@ifi.uio.no Date: Wed, 9 Nov 1994 09:22:49 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Length: 94 Message-Id: <94Nov9.092252+0200_(eet).167290-2@utu.fi> Status: RO One more immediate crossfire crasher. "cast marking rune" and the cast it to some direction. From crossfire-request Wed Nov 9 03:22:42 1994 Return-Path: Received: from dragon.cit.gu.edu.au (dragon.cit.gu.edu.au [132.234.5.27]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 9 Nov 1994 03:21:56 +0100 Received: by dragon.cit.gu.edu.au id AA05271 (5.67b/IDA-1.5 for crossfire@ifi.uio.no); Wed, 9 Nov 1994 12:20:31 +1000 Date: Wed, 9 Nov 1994 12:20:31 +1000 From: Anthony Thyssen Message-Id: <199411090220.AA05271@dragon.cit.gu.edu.au> To: btk@aber.ac.uk, crossfire@ifi.uio.no Subject: Re: Skud maps In-Reply-To: Mail from 'BENJAMIN THOMAS KETTERIDGE ' dated: Tue, 08 Nov 1994 15:25:02 +0000 X-Face: "Ech/vWX*#{vKw-OiDaKqy:=y'Kqji( Received: from eden-valley (eden-valley.aaii.oz.AU [192.35.59.254]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 9 Nov 1994 00:15:53 +0100 Received: from wyndham-estates.aaii.oz.AU by eden-valley with SMTP (5.65c/SMI-4.0/AAII) id AA19601; Wed, 9 Nov 1994 10:14:22 +1100 Message-Id: <199411082314.AA19601@eden-valley> Received: from nagambie.aaii.oz.AU (nagambie) by wyndham-estates. (5.65c/SMI-4.0) id AA13202; Wed, 9 Nov 1994 10:14:22 +1100 Received: from localhost by nagambie.aaii.oz.AU (4.1/SMI-4.0) id AA18402; Wed, 9 Nov 94 10:14:12 EST To: crossfire@ifi.uio.no From: "Rupert G. Goldie" Reply-To: rgg@aaii.oz.au Subject: Re: path attuned for amulet of unholiness In-Reply-To: Message from Mark Wedel of 1994-Nov-7 19:54:3, <199411080354.AA15355@bolero.rahul.net> Date: Wed, 09 Nov 1994 10:13:55 +1100 Sender: rgg@aaii.oz.au Status: RO Mark Wedel wrote: > I think the point was that that amulet was both attuned and repelled > to the same path. Which doesn't make a lot of sense (I am not > even sure how the code handles this.) If both path_attuned and path_repelled are set the effect should be null. However there is one side effect of having both set - now no other object which has path_attuned or path_repelled with have an effect because it will be cancelled by the attuned or repelled of the amulet. > IT is similar to having an item that both protects from fire and > makes you vulnerable to file. Whats the point of that? (other than > you may take 1 point less damage due to rounding). It is the same as this, and an object with both protect and vulnerable doesn't give you an immediate benefit, but it does protect you from an object that gives you vulnerable. Rupert From crossfire-request Wed Nov 9 01:05:03 1994 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 9 Nov 1994 01:04:38 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 8 Nov 1994 19:03:15 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 8 Nov 1994 17:00:21 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 8 Nov 1994 17:00:00 -0500 Date: Tue, 8 Nov 1994 16:00:00 -0600 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.213:08.10.94.22.00.21] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: path attu... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"13262 Tue Nov 8 17:00:42 1994"@bnr.ca> To: master@rahul.net Cc: crossfire@ifi.uio.no, peterm@csua.berkeley.edu Subject: Re: path attuned for amulet of unholiness Status: RO In message "Re: path attuned for amulet of unholiness", 'master@rahul.net' writes: > I think the point was that that amulet was both attuned and repelled >to the same path. Which doesn't make a lot of sense (I am not >even sure how the code handles this.) > > IT is similar to having an item that both protects from fire and >makes you vulnerable to file. Whats the point of that? (other than >you may take 1 point less damage due to rounding). Well, half the time it protects from fire and the other half vulnerable :-) This sort of artifact is definitely _fun_ to have. Regards, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 214-684-4575 Fax: 214-684-3716 Internet: tdoan@bnr.ca WWW: http://47.53.64.96/tdoan/tdoan.html From crossfire-request Tue Nov 8 20:56:02 1994 Return-Path: Received: from toadflax.cs.ucdavis.edu (toadflax.cs.ucdavis.edu [128.120.56.188]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 8 Nov 1994 20:55:59 +0100 Received: from caliente.cs.ucdavis.edu by toadflax.cs.ucdavis.edu (4.1/UCD.CS.2.6) id AA16047; Tue, 8 Nov 94 11:55:51 PST Received: by caliente.cs.ucdavis.edu (5.65/UCD.CS.2.6) id AA28084; Tue, 8 Nov 1994 11:56:37 -0800 Date: Tue, 8 Nov 1994 11:56:37 -0800 From: iness@cs.ucdavis.edu (Jason Iness) Message-Id: <9411081956.AA28084@caliente.cs.ucdavis.edu> To: btk@aber.ac.uk, crossfire@ifi.uio.no Subject: Re: Skud maps Status: RO I believe the Skud maps are incomplete and have no keys. Jason Iness From crossfire-request Tue Nov 8 20:52:45 1994 Return-Path: Received: from ghoul.ecst.csuchico.edu (ghoul.ecst.csuchico.edu [132.241.7.10]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 8 Nov 1994 20:52:25 +0100 Received: (from tvangod@localhost) by ghoul.ecst.csuchico.edu (8.6.8/8.6.6) id LAA23039; Tue, 8 Nov 1994 11:56:37 -0800 From: Tyler Van Gorder Message-Id: <199411081956.LAA23039@ghoul.ecst.csuchico.edu> Subject: Re: Skud maps To: btk@aber.ac.uk (BENJAMIN THOMAS KETTERIDGE) Date: Tue, 8 Nov 1994 11:56:37 -0800 (PST) Cc: crossfire@ifi.uio.no In-Reply-To: <8870.784308302@mailhost.aber.ac.uk> from "BENJAMIN THOMAS KETTERIDGE" at Nov 8, 94 03:25:02 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 701 Status: RO > > Hi folks, a gaming question for once! > > Where the **** are the special keys for the doors in skud/court etc? > > Ben. > +--------------------------------------------------------------------------+ > | _|--|_ o | Disclaimer: I've got a baby, and I don't know what to do! | > | (\/) +---+ +---------------------------------+-------------------------+ > | vv / \ | But then, does anyone? :-) | btk@aber.ac.uk | > +--------------+---------------------------------+-------------------------+ > heh...would you believe it if I told I haven't quite finished it? :> I do however have some much more updated maps....if there is interest I can ftp them somewhere. Tyler. From crossfire-request Tue Nov 8 16:25:47 1994 Return-Path: Received: from mailsun.aber.ac.uk (isode@mailsun.aber.ac.uk [144.124.16.7]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 8 Nov 1994 16:25:47 +0100 Received: from mailhost.aber.ac.uk (actually saturn.dcs.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (PP); Tue, 8 Nov 1994 15:25:20 +0000 To: crossfire@ifi.uio.no Subject: Skud maps Date: Tue, 08 Nov 1994 15:25:02 +0000 Message-ID: <8870.784308302@mailhost.aber.ac.uk> From: BENJAMIN THOMAS KETTERIDGE Status: RO Hi folks, a gaming question for once! Where the **** are the special keys for the doors in skud/court etc? Ben. +--------------------------------------------------------------------------+ | _|--|_ o | Disclaimer: I've got a baby, and I don't know what to do! | | (\/) +---+ +---------------------------------+-------------------------+ | vv / \ | But then, does anyone? :-) | btk@aber.ac.uk | +--------------+---------------------------------+-------------------------+ From crossfire-request Tue Nov 8 05:27:52 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 8 Nov 1994 05:27:51 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id UAA23306; Mon, 7 Nov 1994 20:27:36 -0800 Message-Id: <199411080427.UAA23306@soda.CSUA.Berkeley.EDU> To: Mark Wedel cc: crossfire@ifi.uio.no, peterm@csua.berkeley.edu Subject: Re: path attuned for amulet of unholiness In-reply-to: Your message of "Mon, 07 Nov 1994 19:54:03 PST." <199411080354.AA15355@bolero.rahul.net> Date: Mon, 07 Nov 1994 20:27:35 -0800 From: Peter Mardahl Status: RO In message <199411080354.AA15355@bolero.rahul.net>, Mark Wedel writes: > I think the point was that that amulet was both attuned and repelled >to the same path. Which doesn't make a lot of sense (I am not >even sure how the code handles this.) > > IT is similar to having an item that both protects from fire and >makes you vulnerable to file. Whats the point of that? (other than >you may take 1 point less damage due to rounding). I'd remove the path_repelled abjuration, then. PeterM From crossfire-request Tue Nov 8 04:54:15 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 8 Nov 1994 04:54:14 +0100 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA20267 (5.67b8/IDA-1.5 for ); Mon, 7 Nov 1994 19:54:04 -0800 Received: by bolero.rahul.net id AA15355 (5.67b8/IDA-1.5); Mon, 7 Nov 1994 19:54:03 -0800 Date: Mon, 7 Nov 1994 19:54:03 -0800 From: Mark Wedel Message-Id: <199411080354.AA15355@bolero.rahul.net> To: crossfire@ifi.uio.no, peterm@CSUA.Berkeley.EDU Subject: Re: path attuned for amulet of unholiness Status: RO I think the point was that that amulet was both attuned and repelled to the same path. Which doesn't make a lot of sense (I am not even sure how the code handles this.) IT is similar to having an item that both protects from fire and makes you vulnerable to file. Whats the point of that? (other than you may take 1 point less damage due to rounding). From crossfire-request Mon Nov 7 23:56:38 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 7 Nov 1994 23:56:36 +0100 Received: (peterm@localhost) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) id OAA23408 for crossfire@ifi.uio.no; Mon, 7 Nov 1994 14:56:30 -0800 Date: Mon, 7 Nov 1994 14:56:30 -0800 From: Peter Mardahl Message-Id: <199411072256.OAA23408@soda.CSUA.Berkeley.EDU> To: crossfire@ifi.uio.no Subject: path attuned for amulet of unholiness Status: RO I think it is actually OK as it is. These spells go with abjuration: banishment, turn undead, holy word, cancellation, antimagic rune and counterspell. Summoning is an unholy power, you summon unholy monsters, so that makes sense for the amulet of unholiness, but the flip side of summoning is control, and control goes with banishment. Perhaps the problem is which spells go with abjuration as a path. As it stands, I think it's actually OK. It doesn't seem to me that amulets attuned to opposite gods should necessarily grant *all* opposite powers. Regards, PeterM From crossfire-request Mon Nov 7 21:23:56 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 7 Nov 1994 21:23:53 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id MAA10120; Mon, 7 Nov 1994 12:23:19 -0800 Message-Id: <199411072023.MAA10120@soda.CSUA.Berkeley.EDU> To: Tero Jyri Michael Pelander cc: crossfire@ifi.uio.no Subject: Re: small crossfire (0.91.5) bug In-reply-to: Your message of "Thu, 03 Nov 1994 22:40:01 +0200." <94Nov3.224007+0200_(eet).167099-3@utu.fi> Date: Mon, 07 Nov 1994 12:23:18 -0800 From: Peter Mardahl Status: RO In message <94Nov3.224007+0200_(eet).167099-3@utu.fi>, Tero Jyri Michael Peland er writes: >When you are levitating and try to take something out of an open container >you are carrying it says "you can't reach it". I vote that we fix this by allowing levitating people to touch the ground or go up/down stairs. The current mode seems to presume that one has no control over the levitation whatsoever, which is silly, because if one didn't, how to get through doorways, low ceilings, how come you are not plastered spreadeagled to the ceiling? PeterM From crossfire-request Mon Nov 7 00:54:07 1994 Return-Path: Received: from eden-valley (eden-valley.aaii.oz.AU [192.35.59.254]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 7 Nov 1994 00:53:50 +0100 Received: from wyndham-estates.aaii.oz.AU by eden-valley with SMTP (5.65c/SMI-4.0/AAII) id AA03478; Mon, 7 Nov 1994 10:32:08 +1100 Message-Id: <199411062332.AA03478@eden-valley> Received: from nagambie.aaii.oz.AU (nagambie) by wyndham-estates. (5.65c/SMI-4.0) id AA25841; Mon, 7 Nov 1994 10:32:08 +1100 Received: from localhost by nagambie.aaii.oz.AU (4.1/SMI-4.0) id AA11391; Mon, 7 Nov 94 10:52:38 EST To: crossfire@ifi.uio.no From: "Rupert G. Goldie" Reply-To: rgg@aaii.oz.au Subject: Re: Client/Server Implementation In-Reply-To: Message from "Eric A. Anderson" of 1994-Nov-5 19:58:1, Date: Mon, 07 Nov 1994 10:52:15 +1100 Sender: rgg@aaii.oz.au Status: RO "Eric A. Anderson" wrote: > Mark Wedel writes: > > 1) Finish the client/server split as soon as possible, and whether it > > doesn't handle things particularly well (or in a limited fashion), or th e > > protocol is not documented is not important. IT may also mean that > > the clients become frequently obsoleted as additional commands are added . > This gets my vote. [...] Me too. I think it is best to get a working client/server version ASAP and then add bells and whistles. Expect to cycle through several versions in a short period of time. > > 3) There should be good documentation on what the protocol is, good > > documentation on what the code does, as well as keeping the code readable. > This is a good idea too; but if writing documentation stalls the > release of the client for too long, I'd rather release an interim > version. Ditto. At least have a description of the protocol (which we do have at the moment). Details of the implementation can wait until the code has settled down. > > B) Client should have fast startup. > Yes, a startup on the order of 5 seconds I think is important. I disagree here. I don't think fast startup is particularly important. Most Crossfire play probably lasts hours, so taking 30 seconds at the start is no big deal (Even creating a character takes longer than that). > > C) Client should be able to take advantage of local image files so that > > they then do not need to be transmitted. > Without this, B is violated over 14.4 modems. It's a good idea anyway. > E) Playing with the client over 14.4 should be possible and should > not directly result in the players death because too much data needs > to be transmitted. I don't think we should worry about slow connections to start with. Get it working first, then make sure it works adequately over slow links. > F) Different speeds of connections should not substantially slow down > other players. Yup. > -Eric -- Rupert G. Goldie, Research Scientist rgg@aaii.oz.au Australian Artificial Intelligence Institute /\/\|| Level 6, 171 Latrobe Street, Melbourne, Australia From crossfire-request Mon Nov 7 00:34:12 1994 Return-Path: Received: from castor.cc.utu.fi (root@castor.cc.utu.fi [130.232.1.14]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 7 Nov 1994 00:34:12 +0100 Received: by utu.fi id <167239-1>; Mon, 7 Nov 1994 01:34:00 +0200 Subject: CF: amulet of Unholiness From: Tero Jyri Michael Pelander To: crossfire@ifi.uio.no Date: Mon, 7 Nov 1994 01:33:57 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Length: 637 Message-Id: <94Nov7.013400+0200_(eet).167239-1@utu.fi> Status: RO The amulet of unholiness had the following values with the distribution. path_repelled 385 path_attuned 131136 As this was a clear bug and someone told to change the values to path_repelled 385 path_attuned 192 But... Now the amulet looks like: amulet of Unholiness (Attuned: Summoning, Abjuration)(Repelled: Protection, Abjuration, Restoration) (damned) So it is both attuned and repelled to Abjuration. For comparison: amulet of Holiness (Wis+3)(Attunes: Protection, Abjuration, Restoration) So... I think the Abjuration should not be on the Attuned list on the amulet of Unholiness. What it should be I don't know. From crossfire-request Sun Nov 6 01:58:57 1994 Return-Path: Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sun, 6 Nov 1994 01:58:56 +0100 Received: (from postman@localhost) by andrew.cmu.edu (8.6.9/8.6.9) id TAA15887; Sat, 5 Nov 1994 19:58:47 -0500 Received: via switchmail; Sat, 5 Nov 1994 19:58:46 -0500 (EST) Received: from freehold.andrew.cmu.edu via qmail ID ; Sat, 5 Nov 1994 19:58:05 -0500 (EST) Received: from freehold.andrew.cmu.edu via qmail ID ; Sat, 5 Nov 1994 19:58:02 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.freehold.andrew.cmu.edu.sun4m.412 via MS.5.6.freehold.andrew.cmu.edu.sun4c_411; Sat, 5 Nov 1994 19:58:01 -0500 (EST) Message-ID: Date: Sat, 5 Nov 1994 19:58:01 -0500 (EST) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: Client/Server Implementation In-Reply-To: <199411050801.AA27576@bolero.rahul.net> References: <199411050801.AA27576@bolero.rahul.net> Status: RO Mark Wedel writes: > 1) Finish the client/server split as soon as possible, and whether it > doesn't handle things particularly well (or in a limited fashion), or the > protocol is not documented is not important. IT may also mean that > the clients become frequently obsoleted as additional commands are added. This gets my vote. So long as a version number is transmitted, you can maintain limited backward compatibility for some reasonable time -- say a couple of months, preferrably the time that I client would become obsolete would be displayed. Moreover, getting a client working lets us remove all of the X stuff from the server which will simplify it and make it easier to compile. > 3) There should be good documentation on what the protocol is, good > documentation on what the code does, as well as keeping the code readable. This is a good idea too; but if writing documentation stalls the release of the client for too long, I'd rather release an interim version. > A) Client should handle almost all player commands locally (things like > pickup modes, changing ranges, inventory display, etc.) In theory, the more the better. We'll find out as we do things. > B) Client should have fast startup. Yes, a startup on the order of 5 seconds I think is important. > C) Client should be able to take advantage of local image files so that > they then do not need to be transmitted. Without this, B is violated over 14.4 modems. > D) Client should be able to request all missing image files to be transmitted > at startup. Perhaps, but this seems like more of an implementation concern than anything else. E) Playing with the client over 14.4 should be possible and should not directly result in the players death because too much data needs to be transmitted. F) Different speeds of connections should not substantially slow down other players. -Eric ********************************************************* "It seemed like a good idea at the time" -The Mad Hatter "Yes, you're very smart. Shut up." -In "The Princess Bride" ********************************************************* From crossfire-request Sat Nov 5 09:02:06 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 5 Nov 1994 09:02:01 +0100 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA12527 (5.67b8/IDA-1.5 for ); Sat, 5 Nov 1994 00:01:51 -0800 Received: by bolero.rahul.net id AA27576 (5.67b8/IDA-1.5 for crossfire@ifi.uio.no); Sat, 5 Nov 1994 00:01:50 -0800 Date: Sat, 5 Nov 1994 00:01:50 -0800 From: Mark Wedel Message-Id: <199411050801.AA27576@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Client/Server Implementation Status: RO I've been doing some more work on the client/server stufff, most of which is merging Eric Anderson's and my own work together. But I thought it might be a good idea to get a more general idea of what people want/expect on the client. First, implementation of it. Which of the following do you consider important: 1) Finish the client/server split as soon as possible, and whether it doesn't handle things particularly well (or in a limited fashion), or the protocol is not documented is not important. IT may also mean that the clients become frequently obsoleted as additional commands are added. 2) Make the client/server smart - do good and complete commands, so that it will not need to be extended later, but means it will take longer to complete. IT may also mean that performance/efficiency of the commands may not be great. 3) There should be good documentation on what the protocol is, good documentation on what the code does, as well as keeping the code readable. Note that these are not necessarily exclusive of each other. #3 will probably delay either #1 or #2. Features: A) Client should handle almost all player commands locally (things like pickup modes, changing ranges, inventory display, etc.) B) Client should have fast startup. C) Client should be able to take advantage of local image files so that they then do not need to be transmitted. D) Client should be able to request all missing image files to be transmitted at startup. In both areas (1-3 and A-D), these are just the thoughts that I came up with. Feel free to add to this other things that you consider important. What I am trying to get is some idea of what the near term goal should be. If people want something done very quickly, that could happen, but it should then be recognized that it may not be quite up to various expectations. Likewise, if people want a really nice client that does everything, they could perhaps realize that it will be 6 months before they get it. --Mark From crossfire-request Fri Nov 4 08:51:23 1994 Return-Path: Received: from tel.vtt.fi (tel.vtt.fi [130.188.12.3]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 4 Nov 1994 08:51:23 +0100 Received: by tel.vtt.fi id AA17002 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Fri, 4 Nov 1994 09:50:51 +0200 From: Tero Haatanen Message-Id: <199411040750.AA17002@tel.vtt.fi> Subject: Re: Suggestion for reducing size of map files, ... To: crossfire@ifi.uio.no Date: Fri, 4 Nov 1994 09:50:50 +0200 (EET) In-Reply-To: <199411040336.AA23016@dragon.cit.gu.edu.au> from "Anthony Thyssen" at Nov 4, 94 01:36:35 pm Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Length: 2191 Status: RO > | and make creating new maps significantly faster. It's very fast in crossedit define the whole map in area and select archetype and fill the area ;) > | (I actually think setting a "visibility" attribute for certain objects, > | like buttons, would be a better approach, but that's another subject.) Isn't invisible flags just that, at least no magic squares in town aren't visible ;). > Yes, the server can transmit the general background type(s) for a map. > any other things can be placed on top of this background. I'm more interesting to lower memory requiments used by server than diskspace used by maps. In this form this only adds memory requiments for server and not even very little. If that general background isn't inserted in maps as a true objects, then almost all functions handling maps have to be changed (mountains slows player movements, etc). Using regions there is direct effect that this can't be used in the protocol easily. And bandwidth for floors should be not a problem, since if it doesn't change it won't be sended. > This should be very simple to implement without any real loss in > server execution time but client communications and save file size > would be potentially enormous. One map item for every map point > without any other floor type. Do a hear a volunteer? ;) Go for it, Mark surely wants to see your patches. And don't forget good support in crossedit. Only saving you will get is file sizes, and if this is a real problem, then there is needed the real solution for it (new map format?), IMHO. When you are changing a floor code, you could same fix some other annoyed bugs with the floors. The first one is assumption that floor can't change, isn't nobody using the editor in xpm mode? Other place was (is?) the encounter maps. And there are some other places as well (archetype lava, animated backgrounds). Then there is that 'nice' feature that multipart objects are saved end of the map file. It generally works well, no titans under the floor, but try dropping bunch of coins top of multipart building, enter that building and wait until previous map is swapped to disk, come back and where's your money? ;) -Tero From crossfire-request Fri Nov 4 04:36:46 1994 Return-Path: Received: from dragon.cit.gu.edu.au (dragon.cit.gu.edu.au [132.234.5.27]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 4 Nov 1994 04:36:42 +0100 Received: by dragon.cit.gu.edu.au id AA23016 (5.67b/IDA-1.5 for crossfire@ifi.uio.no); Fri, 4 Nov 1994 13:36:35 +1000 Date: Fri, 4 Nov 1994 13:36:35 +1000 From: Anthony Thyssen Message-Id: <199411040336.AA23016@dragon.cit.gu.edu.au> To: crossfire@ifi.uio.no Subject: Re: Suggestion for reducing size of map files, ... In-Reply-To: Mail from 'Ken Woodruff ' dated: Thu, 3 Nov 1994 07:55:45 -0800 X-Face: "Ech/vWX*#{vKw-OiDaKqy:=y'Kqji( ... This would not be possible if there was only one "background" element. | | I never meant to imply that there should be only one "background" | element, nor that the "stacking" of buttons and floor archetypes that | goes on in some maps should be eliminated. Floors would remain as | archetypes, you could put them over the background at will. (I | actually think setting a "visibility" attribute for certain objects, | like buttons, would be a better approach, but that's another subject.) | Yes, the server can transmit the general background type(s) for a map. any other things can be placed on top of this background. Altars and buttons can be made invisible by adding another floor image on top of that. The original floow would not be transmitted as client should already know it. server : background is "wood" ... server : at x,y "altar" server : at x,y "wood" As the background only needs to be saved and given once and other foor areas can layer over the top (like a road on a grass plain). This should be very simple to implement without any real loss in server execution time but client communications and save file size would be potentially enormous. One map item for every map point without any other floor type. Anthony Thyssen ( System Programmer ) http://www.cit.gu.edu.au/~anthony/ ------------------------------------------------------------------------------- Science(n): Record many facts. Try to see a pattern. Then make a wrong guess at the next fact. ------------------------------------------------------------------------------- From crossfire-request Thu Nov 3 21:40:14 1994 Return-Path: Received: from castor.cc.utu.fi (root@castor.cc.utu.fi [130.232.1.14]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 3 Nov 1994 21:40:14 +0100 Received: by utu.fi id <167099-3>; Thu, 3 Nov 1994 22:40:07 +0200 Subject: small crossfire (0.91.5) bug From: Tero Jyri Michael Pelander To: crossfire@ifi.uio.no Date: Thu, 3 Nov 1994 22:40:01 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Length: 122 Message-Id: <94Nov3.224007+0200_(eet).167099-3@utu.fi> Status: RO When you are levitating and try to take something out of an open container you are carrying it says "you can't reach it". From crossfire-request Thu Nov 3 17:10:39 1994 Return-Path: Received: from toadflax.cs.ucdavis.edu (toadflax.cs.ucdavis.edu [128.120.56.188]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 3 Nov 1994 17:10:25 +0100 Received: from caliente.cs.ucdavis.edu by toadflax.cs.ucdavis.edu (4.1/UCD.CS.2.6) id AA18851; Thu, 3 Nov 94 08:10:05 PST Received: by caliente.cs.ucdavis.edu (5.65/UCD.CS.2.6) id AA12521; Thu, 3 Nov 1994 08:10:47 -0800 Date: Thu, 3 Nov 1994 08:10:47 -0800 From: iness@cs.ucdavis.edu (Jason Iness) Message-Id: <9411031610.AA12521@caliente.cs.ucdavis.edu> To: crossfire@ifi.uio.no, master@rahul.net Subject: Re: How to cheat in crossfire v 0.91.5 Status: RO Hmm I think I must not have explained myself clearly. If a player is on a map saves- and then crashes the server the map will be counted as if someone has just left the map. If that person does not log back in immediately then the map will time reset after the 1hour or 2hour time effect kicks in that would normally reset the maps if someone has left. In effect it will look like a map that someone has left without the server ever having crashed. I agree that if a person logs back in after the 1hour or 2 hour time they will find that the treasure room is "full" but without saving that person at home base the person could now do this same maneuver every 10min after an autosave (assuming that the player can't save themselves). I look at the 1hour or 2hour time as not as profitable as they could have probably gotten more "treasure" if they had played during that 1hour or 2hour time frame. Jason Iness From crossfire-request Thu Nov 3 16:56:23 1994 Return-Path: Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 3 Nov 1994 16:56:21 +0100 Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id HAA08013 for ; Thu, 3 Nov 1994 07:56:18 -0800 Received: from cds9075.cadence.com(158.140.142.2) by mailgate.cadence.com via smap (V1.0mjr) id sma007965; Thu Nov 3 07:55:41 1994 Received: from localhost (woodruff@localhost) by cds9075.cadence.com (8.6.4/8.6.8) id HAA01838 for crossfire@ifi.uio.no; Thu, 3 Nov 1994 07:55:45 -0800 Date: Thu, 3 Nov 1994 07:55:45 -0800 From: Ken Woodruff Message-Id: <199411031555.HAA01838@cds9075.cadence.com> To: crossfire@ifi.uio.no Subject: Re: Suggestion for reducing size of map files, ... Status: RO Raphael Quinet writes: > The reason why I think it's important to have archetypes for floor, > walls, etc is that you can stack them: very often, I put a wall on > top of a floor because the floor can be seen ... because it looks > much nicer that way. ... > ... in the current map distribution there are still many maps designed > for the "old" version of the game, i.e. there is no floor under most > walls and then you see the default yellow floor around the walls when > you are using XPM. This is ugly. This is part of the motivation for my original suggestion. By specifying a background on which all other items appear will instantly resolve the problem of the "ugly yellow floor" under walls, doors, etc. and make creating new maps significantly faster. > ... This would not be possible if there was only one "background" element. I never meant to imply that there should be only one "background" element, nor that the "stacking" of buttons and floor archetypes that goes on in some maps should be eliminated. Floors would remain as archetypes, you could put them over the background at will. (I actually think setting a "visibility" attribute for certain objects, like buttons, would be a better approach, but that's another subject.) Let me restate my position in a slightly clearer way: There is no useful information content in 200 repeated instances of a single floor archetype that can't be contained in a single instance of a background. This is a big waste of space in the map files, server memory, and (I believe) client/server bandwidth. Additionally, creating aesthetically pleasing maps would be simpler if the mapmaker did not have the responsibility of placing the background under each object. Even if the server wants to store individual instances of the archetypes and deliver them to the client, there doesn't seem to be a rational motive for keeping them in the map files. I estimate that you could save an average of 25% in map file size using a simple, "one background replacing the most common floor archetype" in maps, and an average of 30-50% if you allow multiple rectangular regions of different archetypes (e.g. houses with woodfloor inside and grass outside). --Ken +------------------------+-------------------------------------+ | Ken Woodruff | "In every jumbled pile of person | | woodruff@cadence.com | there's a thinking part that | +------------------------+ wonders what the part that isn't | | Disclaimer: What tote | thinking isn't thinking of." | | bag full of $20 bills? | --They Might Be Giants | +------------------------+-------------------------------------+ From crossfire-request Thu Nov 3 15:43:24 1994 Return-Path: Received: from mailsun.aber.ac.uk (isode@mailsun.aber.ac.uk [144.124.16.7]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 3 Nov 1994 15:43:24 +0100 Received: from mailhost.aber.ac.uk (actually saturn.dcs.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (PP); Thu, 3 Nov 1994 14:42:41 +0000 To: crossfire@ifi.uio.no Subject: Re: Map Problems In-reply-to: Your message of "Thu, 03 Nov 1994 14:21:04 +1000." <199411030421.AA20880@dragon.cit.gu.edu.au> Date: Thu, 03 Nov 1994 14:42:10 +0000 Message-ID: <28381.783873730@mailhost.aber.ac.uk> From: BENJAMIN THOMAS KETTERIDGE Status: RO Anthony wrote: >Simularly the water dungeon with a floor of `water'! is not accessable >to the outside world and the exit of the dungeon is not to the >correct quest building in town. > >Then we have the deongeons earth,fire,water there seems to be no air >dungeon. > >It is a shame as this map set has the makings of a great quest. One of the >better in the game, if it was complete. I agree, this would be a great quest if it were complete. Also, can you (read 'the creator') please make it possible for a solo player to complete it? Even if you make it easier for teams, please don't absolutely prevent solo players from completing the quest! $0.02, Ben. +--------------------------------------------------------------------------+ | _|--|_ o | Disclaimer: I've got a baby, and I don't know what to do! | | (\/) +---+ +---------------------------------+-------------------------+ | vv / \ | But then, does anyone? :-) | btk@aber.ac.uk | +--------------+---------------------------------+-------------------------+ From crossfire-request Thu Nov 3 14:28:52 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be (vm1.ulg.ac.be [139.165.32.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 3 Nov 1994 14:28:51 +0100 Received: from verif6.montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Thu, 03 Nov 94 14:27:33 +0100 Received: from quinet@localhost by verif6.montefiore.ulg.ac.be (8.6.9/ULG-6.9) id OAA27000 at Thu, 3 Nov 1994 14:28:27 +0100 Date: Thu, 3 Nov 1994 14:28:27 +0100 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <199411031328.OAA27000@verif6.montefiore.ulg.ac.be> To: crossfire@ifi.uio.no, rgg@aaii.oz.au Subject: Re: Suggestion for reducing size of map files, server/client bandwidth Status: RO Rupert G. Goldie wrote: > It's worth mentioning, I think, that crossfire used to separate map objects > from floor objects (anyone else remember .oo and .om files ?) The current > method is more flexible and cleaner, but does use more memory, but that can > be fixed (as Mark has mentioned) I agree. The old solution was messy and this one is more flexible. But there is something strange in the messages I just read about floors: it looks like nobody is using XPM! Is this the case? I am always using CrossFire with XPM pixmaps instead of bitmaps, and I create my maps with XPM in mind. The reason why I think it's important to have archetypes for floor, walls, etc is that you can stack them: very otfen, I put a wall on top of a floor because the floor can be seen (if you are using XPM). Or when I build a pier, I add the sea archetype underneath, because it looks much nicer that way. This would not be possible if there was only one "background" element. BTW, in the current map distribution there are still many maps designed for the "old" version of the game, i.e. there is no floor under most walls and then you see the default yellow floor around the walls when you are using XPM. This is ugly. Is there someone working on this? -Raphael +---------------------------------------------------------------------------+ | Finger: finger quinet@finger.montefiore.ulg.ac.be for some useless info. | | Mosaic: http://www.montefiore.ulg.ac.be/~quinet (under construction) | | E-mail: eedraq@chapelle.ericsson.se or quinet@montefiore.ulg.ac.be | | S-mail: Raphael Quinet, 9 rue des Martyrs, 4550 Nandrin (Belgium) | | or: Raphael Quinet, Kapuzinergraben 2, 52062 Aachen (Germany) | +---------------------------------------------------------------------------+ From crossfire-request Thu Nov 3 14:15:40 1994 Return-Path: Received: from mailsun.aber.ac.uk (isode@mailsun.aber.ac.uk [144.124.16.7]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 3 Nov 1994 14:15:36 +0100 Received: from mailhost.aber.ac.uk (actually saturn.dcs.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (PP); Thu, 3 Nov 1994 13:15:12 +0000 To: crossfire@ifi.uio.no Subject: Re: Suggestion for reducing size of map files, server/client bandwidth In-reply-to: Your message of "Wed, 02 Nov 1994 13:08:28 PST." <199411022108.NAA01622@cds9075.cadence.com> Date: Thu, 03 Nov 1994 13:14:54 +0000 Message-ID: <24730.783868494@mailhost.aber.ac.uk> From: BENJAMIN THOMAS KETTERIDGE Status: RO Ken Woodruff wrote: >It occurs to me that in general there is very little use for floors >being represented in maps as individual, repeated archetypes. Since >these are generally intended to serve only an aesthetic purpose it would >seem to make more sense to allow a map to simply specify a "background". >One simple example is map city/houses/house2. Nearly half (230 out of >580) of the total archetype entries are "woodfloor". Additionally, >the aesthetics of many maps is ruined by the fact that the floor >used in most regions is not drawn under tables, chairs, generators, >etc., which leaves strange looking blank spaces when the objects >are destroyed (say by a fire). and Eric A. Anderson replied: >While this is initially a good suggestion, it won't really help the >case which is a large problem, i.e. when lots of things are changing. >The most recent representation will for that map take about 150-200 >bytes to do a full redisplay, and something pretty negligable when >you're wandering around. I don't think it's really the display overhead (or lack of) at issue here. If we could halve the size of most of the map _files_ by setting a background field then it would be a useful gain in terms of filestore usage, and map load times! I see no reason why this shouldn't be implemented, as it would change nothing in the data structures or display routines, just make the file interface more efficient. $0.02, Ben Ketteridge. +--------------------------------------------------------------------------+ | _|--|_ o | Disclaimer: I've got a baby, and I don't know what to do! | | (\/) +---+ +---------------------------------+-------------------------+ | vv / \ | But then, does anyone? :-) | btk@aber.ac.uk | +--------------+---------------------------------+-------------------------+ From crossfire-request Thu Nov 3 13:32:29 1994 Return-Path: Received: from kaisa.it.lut.fi (sonninen@kaisa.it.lut.fi [157.24.11.70]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 3 Nov 1994 13:32:28 +0100 Received: from localhost (sonninen@localhost) by kaisa.it.lut.fi (8.6.5/8.6.5/1.12.kim) id OAA29545; Thu, 3 Nov 1994 14:32:25 +0200 Date: Thu, 3 Nov 1994 14:32:25 +0200 From: Jarkko Sonninen Message-Id: <199411031232.OAA29545@kaisa.it.lut.fi> To: crossfire@ifi.uio.no Subject: Re: Suggestion for reducing size of map files, server/client bandwidth In-Reply-To: <199411030735.AA08043@tel.vtt.fi> References: <199411022108.NAA01622@cds9075.cadence.com> <199411030735.AA08043@tel.vtt.fi> Status: RO Tero Haatanen writes: > ... > Reducing the size of maps is needed since one object is about ~250 bytes, > so they eat too much memory in servers side, but I would like it happen > so that it won't affect the flexibility of the current map format. It > could be done splitting the object struct in many parts and let > load_object() decide what parts are needed and if some part isn't > needed then using it from archetype. It would not require any changes > existing maps, but it would still reduce memory used by server. Also > it would have effect reducing the memory used by walls, which is another > big group of dead objects. The vision follows: Object structure could be split to several structures containing attributes which belong together or have same nature. Object structure is only a set of pointers to those attribute structures. Every attribute structure has a copy-on-write flag or a reference count, which tells if there are several references in different objects to same attribute structure. When object is cloned only pointers are copied and reference counts are increased. In modifying an attribute the reference count has to be checked and whole structure cloned. In querying an attribute there are no problems. This system could provide some kind of inheritance of objects and save memory at the cost of speed. It could also clean up code by removing 'archetype' concept, which would only be one of the attribute structures. Memory management becomes a bit more complex, since there could be different sized structures. To implement this every reference to object attribute has to be changed to fuction or a macro call. Tero's idea would be faster, but it wouldn't give so much flexibility, because there has to be then some 'archattributes' which cannot be modified after loadtime, since they are shared by several objects. System would also be hardcoded for certain type of objects. - Jarkko From crossfire-request Thu Nov 3 09:25:44 1994 Return-Path: Received: from eden-valley (eden-valley.aaii.oz.AU [192.35.59.254]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 3 Nov 1994 09:25:35 +0100 Received: from wyndham-estates.aaii.oz.AU by eden-valley with SMTP (5.65c/SMI-4.0/AAII) id AA07058; Thu, 3 Nov 1994 19:03:50 +1100 Message-Id: <199411030803.AA07058@eden-valley> Received: from nagambie.aaii.oz.AU (nagambie) by wyndham-estates. (5.65c/SMI-4.0) id AA27491; Thu, 3 Nov 1994 19:03:50 +1100 Received: from localhost by nagambie.aaii.oz.AU (4.1/SMI-4.0) id AA28398; Thu, 3 Nov 94 19:24:20 EST To: crossfire@ifi.uio.no From: "Rupert G. Goldie" Reply-To: rgg@aaii.oz.au Subject: Re: Suggestion for reducing size of map files, server/client bandwidth In-Reply-To: Message from Ken Woodruff of 1994-Nov-2 13:8:28, <199411022108.NAA01622@cds9075.cadence.com> Date: Thu, 03 Nov 1994 19:24:01 +1100 Sender: rgg@aaii.oz.au Status: RO It's worth mentioning, I think, that crossfire used to separate map objects from floor objects (anyone else remember .oo and .om files ?) The current method is more flexible and cleaner, but does use more memory, but that can be fixed (as Mark has mentioned) Rupert From crossfire-request Thu Nov 3 08:36:16 1994 Return-Path: Received: from tel.vtt.fi (tel.vtt.fi [130.188.12.3]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 3 Nov 1994 08:36:15 +0100 Received: by tel.vtt.fi id AA08043 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Thu, 3 Nov 1994 09:35:43 +0200 From: Tero Haatanen Message-Id: <199411030735.AA08043@tel.vtt.fi> Subject: Re: Suggestion for reducing size of map files, server/client bandwidth To: crossfire@ifi.uio.no Date: Thu, 3 Nov 1994 09:35:42 +0200 (EET) In-Reply-To: <199411022108.NAA01622@cds9075.cadence.com> from "Ken Woodruff" at Nov 2, 94 01:08:28 pm Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Length: 2331 Status: RO > It occurs to me that in general there is very little use for floors > being represented in maps as individual, repeated archetypes. Since But it still has a use. The floor has a names, so you can hint a players changing a floor name (e.g. 'a burned floor'). The other effect is that different backgrounds affects to players speed in the different ways. It also makes thing much simpler for code, which is not a minor thing (you can treat every object in the same way). > these are generally intended to serve only an aesthetic purpose it would > seem to make more sense to allow a map to simply specify a "background". This is an interesting idea, but unfortunately it's not very useful a larger scale, think about a world map, where background is composed of grass, forest and many other archetypes. > the aesthetics of many maps is ruined by the fact that the floor > used in most regions is not drawn under tables, chairs, generators, > etc., which leaves strange looking blank spaces when the objects > are destroyed (say by a fire). Use the mapinfo command to look who is made the map and ask author to fix it and if author is unknown or he isn't interested fixing it, fix it yourself and send patches to Mark. Old maps don't came better just changing a little code, they need anyway manual editing. > A sophisticated solution would allow for rectangular "regions" > of a given background, but as a first pass a single background per > map would be of significant use. The problem which this raises is how do you implement squares, which don't have any background or have the different background. And it doesn't have to any real effect to bandwidth to client/server, since client have no maps, just player's view. Reducing the size of maps is needed since one object is about ~250 bytes, so they eat too much memory in servers side, but I would like it happen so that it won't affect the flexibility of the current map format. It could be done splitting the object struct in many parts and let load_object() decide what parts are needed and if some part isn't needed then using it from archetype. It would not require any changes existing maps, but it would still reduce memory used by server. Also it would have effect reducing the memory used by walls, which is another big group of dead objects. -Tero From crossfire-request Thu Nov 3 08:09:04 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 3 Nov 1994 08:09:02 +0100 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA29944 (5.67b8/IDA-1.5 for ); Wed, 2 Nov 1994 23:08:52 -0800 Received: by bolero.rahul.net id AA08143 (5.67b8/IDA-1.5); Wed, 2 Nov 1994 23:08:50 -0800 Date: Wed, 2 Nov 1994 23:08:50 -0800 From: Mark Wedel Message-Id: <199411030708.AA08143@bolero.rahul.net> To: anthony@cit.gu.edu.au, crossfire@ifi.uio.no Subject: Re: How to cheat in crossfire v 0.91.5 Status: RO Keeping maps aroudn for 24 hours would be a very bad idea. Because suppose a player clears out some level, pickups up the items, and saves in the treasure chamber. (then crashes the game.) If that map is not reset for 24 hours, it means no other players can go on that quest/map. (or at least not gain the treasure if they do.) And this may not be an intentional thing. Maybe someone is playing, and the game crashes. Player figures he will start again tomorrow (maybe just because the server has to be manualy restarted, or because this is as convenient as any time to quit.) The best solution is to fix the game crashes. I have gotten one more way that players can kill the server, and will likely fix that. If the players have a way of intentionally killing the server, it should be easy to track down and fix. --MNark From crossfire-request Thu Nov 3 06:02:50 1994 Return-Path: Received: from toadflax.cs.ucdavis.edu (toadflax.cs.ucdavis.edu [128.120.56.188]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 3 Nov 1994 06:02:48 +0100 Received: from caliente.cs.ucdavis.edu by toadflax.cs.ucdavis.edu (4.1/UCD.CS.2.6) id AA04851; Wed, 2 Nov 94 21:01:26 PST Received: by caliente.cs.ucdavis.edu (5.65/UCD.CS.2.6) id AA11205; Wed, 2 Nov 1994 21:02:12 -0800 Date: Wed, 2 Nov 1994 21:02:12 -0800 From: iness@cs.ucdavis.edu (Jason Iness) Message-Id: <9411030502.AA11205@caliente.cs.ucdavis.edu> To: crossfire@ifi.uio.no, iness@cs.ucdavis.edu, master@rahul.net Subject: Re: How to cheat in crossfire v 0.91.5 Status: RO I would not bother adding the force map save until the code has been added to "recover" across crashes as there is no point in doing so (won't gain a thing as you indicated). If you think the idea is reasonable I might be able to code up the "recover" a map from a crash code. I hope if there are any flaws that someone can think of them before I go about trying to code it up. Thanks, Jason Iness From crossfire-request Thu Nov 3 05:50:45 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 3 Nov 1994 05:50:43 +0100 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA26105 (5.67b8/IDA-1.5 for ); Wed, 2 Nov 1994 20:50:30 -0800 Received: by bolero.rahul.net id AA21565 (5.67b8/IDA-1.5); Wed, 2 Nov 1994 20:50:28 -0800 Date: Wed, 2 Nov 1994 20:50:28 -0800 From: Mark Wedel Message-Id: <199411030450.AA21565@bolero.rahul.net> To: crossfire@ifi.uio.no, iness@cs.ucdavis.edu Subject: Re: How to cheat in crossfire v 0.91.5 Status: RO Right now, when a map is saved, the only thing the server is doing is aving the map. So howerver long this take, all players are effectively frozen. Also, I am not sure if the current saving code allows a map to be saved in a non destructuve manner. I suppose it wouldn't be hard to add some option in config.h allow people set force teh map to be saved along with the player. But until preserving maps between crashes is added, I really don't know what this gains. Right now, in fact, a map is never saved if the player is on it.. That is because there is no reason to do so - maps are only saved right now so that the memory can be freed up. From crossfire-request Thu Nov 3 05:21:17 1994 Return-Path: Received: from dragon.cit.gu.edu.au (dragon.cit.gu.edu.au [132.234.5.27]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 3 Nov 1994 05:21:11 +0100 Received: by dragon.cit.gu.edu.au id AA20880 (5.67b/IDA-1.5 for crossfire@ifi.uio.no); Thu, 3 Nov 1994 14:21:04 +1000 Date: Thu, 3 Nov 1994 14:21:04 +1000 From: Anthony Thyssen Message-Id: <199411030421.AA20880@dragon.cit.gu.edu.au> To: crossfire@ifi.uio.no Subject: Map Problems In-Reply-To: Mail from 'Mark Wedel ' dated: Wed, 2 Nov 1994 18:55:59 -0800 X-Face: "Ech/vWX*#{vKw-OiDaKqy:=y'Kqji(