From owner-crossfire Tue Jul 2 21:35:16 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Tue, 2 Jul 1996 21:35:16 +0200 Received: from uni-kl.de (mmdf@stepsun.uni-kl.de [131.246.136.50]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 2 Jul 1996 21:35:12 +0200 Received: from corp-200.dfki.uni-kl.de by stepsun.uni-kl.de id aa17196; 2 Jul 96 21:34 MET DST Received: from corp-201.dfki.uni-kl.de (root@corp-201 [131.246.241.106]) by corp-200.dfki.uni-kl.de (8.7.5/8.7.3) with ESMTP id VAA18033; Tue, 2 Jul 1996 21:34:57 +0200 (MET DST) Organization: DFKI Kaiserslautern GmbH, D 67663 Kaiserslautern Received: from localhost (elsbernd@isg-201 [131.246.241.71]) by corp-201.dfki.uni-kl.de (8.7.5/8.7.3) with ESMTP id VAA19690; Tue, 2 Jul 1996 21:34:53 +0200 (MET DST) Message-Id: <199607021934.VAA19690@corp-201.dfki.uni-kl.de> X-Mailer: exmh version 1.6.7 5/3/96 Mime-Version: 1.0 To: Raphael.Quinet@eed.ericsson.se cc: elsbernd@dfki.uni-kl.de, crossfire@ifi.uio.no Subject: Re: HTML for docs? (was Re: CF: proposed docs (longish)) X-url: http://www.dfki.uni-kl.de/~elsbernd/elsbernd.html X-face: $M>Bn@FmY_i=WI\TEedu:D?W-?1t#J|YJ(jfuT-@,!K=ADK?n<}T[j65V<%d/r46~0b[oXI <\;T\,vrg#=BMNs)z$I2PI5K_Qo(+k2~sC5X&(?ZX~y1qu(>^$Ey75zK@eN5@lJ39v"9_sP9UeHr$, 9;KU6I$G|5[[%m"Tl[_KvBi+E?WGKU%8=LazP}`uM4$zus8.RKRz"v4>\8sk3#'h6"CK In-reply-to: Your message of "Fri, 28 Jun 1996 15:13:00 MET DST." <199606281510.23850.mne.ifi.uio.no@ifi.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 02 Jul 1996 21:34:40 +0200 From: Klaus Elsbernd Sender: owner-crossfire Precedence: bulk Status: RO Hello Raphael.Quinet@eed.ericsson.se wrote: > > I would vote against html. I instead suggest {la}tex2html, to convert= > > the documents to html. > = > The conversion from TeX or LaTeX to HTML is not very good, especially i= f > you want to have nice tables and color images in your documentation. I don't think so(see http://www.ifi.uio.no/~larso/spoiler2/spoiler.shtml)= =2E > Let's face it: nowadays, many more people will be able to read HTML > files than LaTeX or PostScript files. Also, as Mark mentioned, it > will then be easy to put the docs on a WWW server, which could be very > useful. I suspect (and hope) that several people who have been > reluctant at updating the docs for CrossFire because they don't know > TeX or LaTeX will prefer to edit HTML docs. Mind you, I have been > using LaTeX for years and I like it (very good for writing technical > reports) but now I think that HTML is more appropriate for documents > that are distributed on the Internet. As I said it before, I don't think that it is 'very' usefull, having documentation in html. I know, that it is modern to have them. I won't be= unmodern, I like to 'sync with time', but most of the time, the docs will= be printed :-(. As you can see, Lars Henrik B=F8ler Olafsen made a ver= y nice conversion within days, or minutes :-). I although use LaTeX since years, and I have no trouble writing small text in LaTeX. But I have many difficults, in writing 'blinking buttons',= 'running texts' and other features of WWW-Browser (and I don't know, if this feature is only available on this version of the browser). And all this features won't be needed to this extent within crossfire docs. (Imho= =2E) (It's not as difficult for me, as I wrote, because it's my job, but for many lusers. At least in our environment.) Someone mentioned, that LaTeX is not running on all platforms. I know of no major platform, where no TeX is running (especially under unix). But I= know of serveral platforms not running netscape (if you use their special= l table support) Beside that. There will always be some code/shell-scripts in awk, perl lisp or whatever, to generate parts (the stat/wapon/amour/... tables), which can produce either TeX-Code. (And they can produce html too :-)) So you have to combine many tools, to generate a documentation. This task= is not easy, and probably will not be in the near future. So you need someone, which knows all, or most of the tools. And if this person knows LaTeX, it would produce better output. MfG Klaus ps: I'm not good in writing english, but I hope I could express my opinio= n. And so, I shouldn't argue to loud, because I can't write the docs :-( (If someone has difficults with LaTeX and LaTeX-Scripts-Interfaces, I'll = be = glad to help him/her) -- = =2E_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.= _._._._. | Klaus Elsbernd, DFKI/Universit"at Kaiserslautern | elsbernd@dfki.uni-k= l.de | ! System Administrator and BOFH | = | | 67657 Kaiserslautern; Germany | Tel: (+49) 0631/205= -3486| |_._._._._._._._._._._._._._._._._._._._._._._._._._|_._._._._._._._._._.= _._._| From owner-crossfire Tue Jul 2 14:03:12 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Tue, 2 Jul 1996 14:03:12 +0200 Received: from ifi.uio.no (logi.ifi.uio.no [129.240.64.5]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id ; Tue, 2 Jul 1996 14:03:07 +0200 Message-Id: <199607021203.OAA23655@ifi.uio.no> X-Mailer: exmh version 1.6.7 5/3/96 Mime-Version: 1.0 To: Kristofer Bosland , mwedel@pyramid.com cc: Brian Thomas , crossfire@ifi.uio.no Subject: Re: HTML for docs? (was Re: CF: proposed docs (longish)) In-reply-to: Your message of "Mon, 01 Jul 1996 13:35:03 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Jul 1996 14:03:06 +0200 From: =?iso-8859-1?Q?Lars_Henrik_B=F8ler_Olafsen?= Sender: owner-crossfire Precedence: bulk Status: RO Kris Bosland wrote: >Brian Thomas wrote: > > As far as laTeX vs. html goes: I agree that the WWW stuff has > > more utility, but the authour of the pages has to continually > > update them. If we design a document using Latex/gawk scripts, > > then the document will auto-matically update itself with each > > new version; clearly desireable too. I wonder if there is > > a way to easily incorperate gawk to auto update Web pages... > > > The concept is fundamentally similar. The source for both of these > formats is plain ascii text embedded in control codes for the > formatting. The difference right now, is that someone has experience > using Awk to hack up the LaTeX files from internal CrossFire data, and > this experience may not be present for HTML. The spoiler docs was originally made to in order to learn awk. (Just like Frank wrote crossfire to learn X better). LaTeX was chosen because: 1. Latex supported tables, html didn't at that time(I think). 2. You got a ready to print dvi file from LaTeX. 3. I thought LaTeX was cool (Still do). Converting the scripts to generate html code shouldn't really be too hard. (I guess). Actually the code can be written to generate both. Some points: - You will get *a lot* of small gif files. (~300 of them, total size: ~500K) - There is no reason the scripts should stay awk. If someone likes perl .... Humm. Boff. Ok .. [6 Hours Later] Ok. I've made a rough transition. The result can be viewed at http://www.ifi.uio.no/~larso/spoiler2/spoiler.shtml I'll mail the uuencoded source files to Mark Wedel and Brian Thomas. Feel free to alter anything you (dont) like.. (like some hyperlinking) -Lars From owner-crossfire Mon Jul 1 22:56:30 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Mon, 1 Jul 1996 22:56:30 +0200 Received: from ender.ring.org (krisb@DNS.RING.ORG [204.27.179.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 1 Jul 1996 22:56:25 +0200 Received: (from krisb@localhost) by ender.ring.org (8.6.12/8.6.9) id NAA01137; Mon, 1 Jul 1996 13:35:12 -0700 Date: Mon, 1 Jul 1996 13:35:03 -0700 (PDT) From: Kristofer Bosland Mime-Version: 1.0 To: Brian Thomas cc: crossfire@ifi.uio.no, thomas@xplorer.gsfc.nasa.gov Subject: Re: HTML for docs? (was Re: CF: proposed docs (longish)) In-Reply-To: <199607011659.MAA00798@xplorer.gsfc.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-crossfire Precedence: bulk Status: RO The concept is fundamentally similar. The source for both of these formats is plain ascii text embedded in control codes for the formatting. The difference right now, is that someone has experience using Awk to hack up the LaTeX files from internal CrossFire data, and this experience may not be present for HTML. I vote for HTML myself, particularly because the information is mainly for the inexperienced, and we will reach a broader audience with HTML. If you go the meta-doc-thru-awk route, maybe both could be done. -Kris Bosland On Mon, 1 Jul 1996, Brian Thomas wrote: > > > > Ok, > > I thought I'd throw in my 2 cents here, then re-outline a plan > for the CF docs. > > As far as laTeX vs. html goes: I agree that the WWW stuff has > more utility, but the authour of the pages has to continually > update them. If we design a document using Latex/gawk scripts, > then the document will auto-matically update itself with each > new version; clearly desireable too. I wonder if there is > a way to easily incorperate gawk to auto update Web pages... > > Well, whatever. For now, I will work to build 2 versions of the > players handbook, one will be a web page (ill announce a trial > location to the list later this week) and one will be a laTeX > document that should auto-update. > > -b.t. > From owner-crossfire Tue Jul 2 19:35:49 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Tue, 2 Jul 1996 19:35:49 +0200 Received: from mbmartin.bevc.blacksburg.va.us (martinm@mbmartin.bevc.blacksburg.va.us [198.82.204.58]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 2 Jul 1996 19:35:45 +0200 Received: (from martinm@localhost) by mbmartin.bevc.blacksburg.va.us (8.6.12/8.6.9) id NAA03952; Tue, 2 Jul 1996 13:36:11 -0400 Date: Tue, 2 Jul 1996 13:36:11 -0400 (EDT) From: "Michael B. Martin" Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: OpenWorld update Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-crossfire Precedence: bulk Status: RO Well, I got in touch with the person working on the OpenWorld project (generic game engine for crossfire-like games) over the weekend. I am including his full reply at the end of this message. It basically says that he has selected the BeBox (see http://www.be.com/ if you don't know what this is) as his initial development platform, and that he has begun working on server code. It looks like it will be a while (maybe a long while) before he has something really usable ready. Oh, well. -Michael ---------------------------------------------------------------------------- From bull@cs.unr.edu Date: Sun, 30 Jun 96 13:14:57 PDT From: "W.E.B" To: "Michael B. Martin" Subject: Re: OpenWorld Well, I'm now working on writing the server on my new BeBox. I'll be putting the specs for the development system up, I suppose next weekend. (I'm looking at a $50/annual web site for my BeBox development pages.) What does this mean? There's two directions this will be going: 1) There will be an open standard/protocol for client and server communication. This will explain the requirements for the clients pasar and the rest is up to the client for requesting retrieval and other information. 2) My first goal is now working on an enhanced communication system using the SOM (CORBA 2.0 compliant) API which Be Inc. is adopting. This will be for accelerated and simplified development for BeBox players. Why the BeBox? First of all it's POSIX compatible. ie. There's UNIX underneath. Next, it's fast and cheap and may very well be the next pc-desktop workstation low cost pc-organ-donor multiprocessor CHIRP/PREP compliant computer to take over the planet. Well, to be honest it has a lot going for it and is really going to be great for running servers and such. The development tools are in place and the power to price performance can't really be beaten (especially looking long term.) And finally, the API (application programming interface) is SLICK, simple to use and object oriented. It supports shared memory and libraries and we're receiving a lot of help from the developer guys at Be Inc. How long is this going to take to be public and all over the place? Well, first a solid design on the BeBox will have to be running. Once the core is up, it can be ported to UNIX very easily. I'm not saying much online about this since I want to make sure it's object model is done well. I don't have a huge requirement for a lot of help since it's just me and Mike Brown (and the rest of the world doesn't have a BeBox yet.) We're working on two BeBoxes in an office in the University of Nevada, Reno and still have classes and such pressing heavily upon us. How about a recap? The goal is still for a modular networkable game development system. We're concentrating less on the game itself and more on the tools for developing gaming 'systems'. Since the difficulties with platform independent coding hasn't been resolved with Java (although we work very hard a making it do-so) we are now resloving back to C++, our preferred language. The system will consists of a driver (much like a mud) and a rule library for the style of game the driver is running. There will be a dynamic editor/creation system to expand the rule library and manipulte the data common to the system. The BeBox has a very powerful integrated database in the OS. This will be tightly coupled to the driver and allow for excellent response time in managing the system as a whole. The common message system within the BeOS also makes reusing data (such as a standard graphics object, pictures, text, etc.) much more managable in a drag and drop development environment. Will this be public? We hope so. I'm not in this for the money, but there's nothing stopping me from doing a total rewrite a few years from now to put out a professional version of the developer and association modelling system we're working on. --- Please be patient, we're really trying to do something right in what little time we have. Since we're being held up by Be for the next version of the OS, dr8 we've been told to wait for the CORBA networking parts. Once this is released most of the networking specs will be much more definative. I'll get to you and outline of the system a.s.a.p., if not on the web at least ftp'able so you can read more about how we inted to implement the networking protocols and the development ontology. From owner-crossfire Mon Jul 1 19:00:25 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Mon, 1 Jul 1996 19:00:25 +0200 Received: from xplorer.gsfc.nasa.gov (xplorer.gsfc.nasa.gov [128.183.126.216]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 1 Jul 1996 19:00:21 +0200 Received: (from thomas@localhost) by xplorer.gsfc.nasa.gov (LHEA9504/950407.s1) id MAA00798; Mon, 1 Jul 1996 12:59:13 -0400 Date: Mon, 1 Jul 1996 12:59:13 -0400 From: Brian Thomas Message-Id: <199607011659.MAA00798@xplorer.gsfc.nasa.gov> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: Re: HTML for docs? (was Re: CF: proposed docs (longish)) Cc: thomas@xplorer.gsfc.nasa.gov Sender: owner-crossfire Precedence: bulk Status: RO Ok, I thought I'd throw in my 2 cents here, then re-outline a plan for the CF docs. As far as laTeX vs. html goes: I agree that the WWW stuff has more utility, but the authour of the pages has to continually update them. If we design a document using Latex/gawk scripts, then the document will auto-matically update itself with each new version; clearly desireable too. I wonder if there is a way to easily incorperate gawk to auto update Web pages... Well, whatever. For now, I will work to build 2 versions of the players handbook, one will be a web page (ill announce a trial location to the list later this week) and one will be a laTeX document that should auto-update. -b.t. From owner-crossfire Wed Jul 3 15:20:41 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 3 Jul 1996 15:20:41 +0200 Received: from maud.ifi.uio.no (0@maud.ifi.uio.no [129.240.74.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 3 Jul 1996 15:20:05 +0200 Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se [193.180.251.38]) by maud.ifi.uio.no ; Wed, 3 Jul 1996 15:11:43 +0200 (MET DST) Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.132.130]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with ESMTP id PAA01530 for ; Wed, 3 Jul 1996 15:08:08 +0200 (MET DST) Received: (from eedraq@localhost) by chapelle.eed.ericsson.se (8.7.1/8.7.1) id PAA20564 for crossfire@ifi.uio.no; Wed, 3 Jul 1996 15:08:06 +0200 (MET DST) Date: Wed, 3 Jul 1996 15:08:06 +0200 (MET DST) Message-Id: <199607031308.PAA20564@chapelle.eed.ericsson.se> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: minor bug fixes for god_intervention (gods.c) From: Raphael.Quinet@eed.ericsson.se Sender: owner-crossfire Precedence: bulk Status: RO Here are some small bug fixes for god_intervention in server/gods.c. The bugs were: - in two cases, the function returned early without continuing down to the message "You feel rapture". - the global variable "name" was used instead of the local variable "godname" when changing the title of a weapon. The result was that you got a "weapon of crossfire" instead of a "weapon of God" (or whatever your god is). ---------- cut here ---------- *** gods.c.orig Sun Apr 21 07:07:38 1996 --- gods.c Wed Jul 3 14:42:28 1996 *************** *** 173,180 **** if (op->type==PLAYER&&success) { new_draw_info(NDI_UNIQUE, 0,op, "You feel like someone is helping you."); draw_inventory(op); } - return; } /* Fix drained stats? */ --- 173,180 ---- if (op->type==PLAYER&&success) { new_draw_info(NDI_UNIQUE, 0,op, "You feel like someone is helping you."); draw_inventory(op); + return; } } /* Fix drained stats? */ *************** *** 233,242 **** for(weapon=op->inv;weapon;weapon=weapon->below) if(weapon->type==WEAPON&&QUERY_FLAG(weapon,FLAG_APPLIED)) break; ! if(!weapon) return; ! ! /* hallow the weapon to slay enemies */ ! if(!weapon->slaying&&strcmp("none",Gods[godnr].enemy_race)) { char buf[MAX_BUF]; weapon->slaying = add_string(Gods[godnr].enemy_race); --- 233,240 ---- for(weapon=op->inv;weapon;weapon=weapon->below) if(weapon->type==WEAPON&&QUERY_FLAG(weapon,FLAG_APPLIED)) break; ! /* allow the weapon to slay enemies */ ! if(weapon&&weapon->slaying&&strcmp("none",Gods[godnr].enemy_race)) { char buf[MAX_BUF]; weapon->slaying = add_string(Gods[godnr].enemy_race); *************** *** 245,251 **** new_draw_info_format(NDI_UNIQUE,0,op, "Your %s now hungers to slay enemies of your god!", weapon->name); ! sprintf(buf,"of %s",name); weapon->title=add_string(buf); if(op->type==PLAYER) draw_inventory(op); } --- 243,249 ---- new_draw_info_format(NDI_UNIQUE,0,op, "Your %s now hungers to slay enemies of your god!", weapon->name); ! sprintf(buf,"of %s",godname); weapon->title=add_string(buf); if(op->type==PLAYER) draw_inventory(op); } *************** *** 253,266 **** } /* add the gods attacktype*/ ! if(!(RANDOM()%2)&&!(weapon->attacktype&Gods[godnr].attacktype)) { new_draw_info(NDI_UNIQUE,0,op,"Your weapon suddenly glows!"); weapon->attacktype=weapon->attacktype|Gods[godnr].attacktype; return; } /* higher magic value */ ! if(!(RANDOM()%2)&&weapon->magic<(level/5)) { new_draw_info(NDI_UNIQUE,0,op, "A phosphorescent glow envelops your weapon!"); weapon->magic++; --- 251,264 ---- } /* add the gods attacktype*/ ! if(weapon&&!(RANDOM()%2)&&!(weapon->attacktype&Gods[godnr].attacktype)) { new_draw_info(NDI_UNIQUE,0,op,"Your weapon suddenly glows!"); weapon->attacktype=weapon->attacktype|Gods[godnr].attacktype; return; } /* higher magic value */ ! if(weapon&&!(RANDOM()%2)&&weapon->magic<(level/5)) { new_draw_info(NDI_UNIQUE,0,op, "A phosphorescent glow envelops your weapon!"); weapon->magic++; *************** *** 275,288 **** int spell=0; /*generate a random rare clerical spell*/ ! do { ! do ! spell=RANDOM()%NROFREALSPELLS; ! while(spells[spell].books); ! } while (!spells[spell].cleric); ! while((spells[spell].books!=0)&&!spells[spell].cleric) - spell = RANDOM()%NROFREALSPELLS; /* The god will only teach the spell if its not against the nature * of the cult, the priest is high enough in level *and* the priest --- 273,281 ---- int spell=0; /*generate a random rare clerical spell*/ ! do ! spell = RANDOM()%NROFREALSPELLS; while((spells[spell].books!=0)&&!spells[spell].cleric) /* The god will only teach the spell if its not against the nature * of the cult, the priest is high enough in level *and* the priest ---------- cut here ---------- -Raphael From owner-crossfire Wed Jul 3 14:47:07 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 3 Jul 1996 14:47:07 +0200 Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se [193.180.251.38]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 3 Jul 1996 14:46:56 +0200 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.132.130]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with ESMTP id OAA29009 for ; Wed, 3 Jul 1996 14:46:45 +0200 (MET DST) Received: (from eedraq@localhost) by chapelle.eed.ericsson.se (8.7.1/8.7.1) id OAA20237 for crossfire@ifi.uio.no; Wed, 3 Jul 1996 14:46:43 +0200 (MET DST) Date: Wed, 3 Jul 1996 14:46:43 +0200 (MET DST) Message-Id: <199607031246.OAA20237@chapelle.eed.ericsson.se> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: bug/feature with saving throw? From: Raphael.Quinet@eed.ericsson.se Sender: owner-crossfire Precedence: bulk Status: RO There is something strange with the "saving throw" code in attack.c. If a weapon has several attack types and one of them allows saving throws, then the whole attack can fail because of that, even if the other attack types could have done some damage. I think this is a bug rather than a feature. I discovered this when I prayed on an altar and I was lucky enough to get a God intervention which added the attack types "weaponmagic" and "fear" to my current weapon (a Frostbrand). The result was disastrous: instead of improving the weapon, it ruined it because AT_FEAR allows a saving throw which can cancel the whole attack. Here is a proposed patch to server/attack.c. Instead of returning immediately when the saving throw succeeds, it clears the affected attack types and returns only if there is no attack left. I don't think there are any side effects, but I might have overlooked something. Comments are welcome... ---------- cut here ---------- *** attack.c.orig Sun Apr 21 07:07:37 1996 --- attack.c Wed Jul 3 14:11:53 1996 *************** *** 511,517 **** /* the following includes a secret saving throw for magic: you get TWO saving throws for magical attacks! */ (RANDOM()%20+((op->protected&type)?5:1) >= savethrow[op->level])) ! return 0; CLEAR_FLAG(op,FLAG_SCARED); /* Or the monster won't hit back */ if(get_owner(hitter)) --- 511,523 ---- /* the following includes a secret saving throw for magic: you get TWO saving throws for magical attacks! */ (RANDOM()%20+((op->protected&type)?5:1) >= savethrow[op->level])) ! { ! /* do not bail out immediately if other attack types can succeed */ ! type &= ~(AT_PARALYZE|AT_FEAR|AT_POISON|AT_CONFUSION|AT_SLOW| ! AT_CANCELLATION|AT_DEPLETE); ! if (!type) ! return 0; ! } CLEAR_FLAG(op,FLAG_SCARED); /* Or the monster won't hit back */ if(get_owner(hitter)) ---------- cut here ---------- -Raphael From owner-crossfire Wed Jul 3 01:33:09 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 3 Jul 1996 01:33:09 +0200 Received: from gossip.pyramid.com (gossip.pyramid.com [129.214.1.101]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Wed, 3 Jul 1996 01:33:01 +0200 Received: from stealth-news.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA12649; Tue, 2 Jul 96 16:32:28 -0700 Received: by stealth.eng.pyramid.com (8.6.12/Pyramid_Internal_Configuration) id QAA25638; Tue, 2 Jul 1996 16:32:25 -0700 From: "Mark Wedel" Message-Id: <9607021632.ZM25631@stealth.eng.pyramid.com> Date: Tue, 2 Jul 1996 16:32:23 -0700 In-Reply-To: Klaus Elsbernd "Re: HTML for docs? (was Re: CF: proposed docs (longish))" (Jul 2, 9:34pm) References: <199607021934.VAA19690@corp-201.dfki.uni-kl.de> X-Mailer: Z-Mail (3.2.0 06sep94) Mime-Version: 1.0 To: Klaus Elsbernd , Raphael.Quinet@eed.ericsson.se Subject: Re: HTML for docs? (was Re: CF: proposed docs (longish)) Cc: crossfire@ifi.uio.no Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19607021632.ZM25631.eng.pyramid.com" Sender: owner-crossfire Precedence: bulk Status: RO --PART-BOUNDARY=.19607021632.ZM25631.eng.pyramid.com Content-Description: Text Content-Type: text/plain ; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Zm-Decoding-Hint: mimencode -q -u On Jul 2, 9:34pm, Klaus Elsbernd wrote: > Subject: Re: HTML for docs? (was Re: CF: proposed docs (longish)) > > I don't think so(see http://www.ifi.uio.no/~larso/spoiler2/spoiler.shtm= l). > The impression I get from Lars message is that he rewrote the various sc= ripts that process the output to generate HTML. He did not use a latex->html conversion program. This is a major difference. > As I said it before, I don't think that it is 'very' usefull, having > documentation in html. I know, that it is modern to have them. I won't = be > unmodern, I like to 'sync with time', but most of the time, the docs wi= ll > be printed :-(. > As you can see, Lars Henrik B=F8ler Olafsen made a v= ery > nice conversion within days, or minutes :-). As said, that was a conversion of the spoiler processing scripts. That = case is a bit easier, because most of the spoiler information is generated fro= m output of the program. Most of the other docs are much more likely to be= generated from human input. > I although use LaTeX since years, and I have no trouble writing small > text in LaTeX. But I have many difficults, in writing 'blinking buttons= ', > 'running texts' and other features of WWW-Browser (and I don't know, if= > this feature is only available on this version of the browser). And all= > this features won't be needed to this extent within crossfire docs. (Im= ho.) > (It's not as difficult for me, as I wrote, because it's my job, but for= > many lusers. At least in our environment.) And as an example, I am mostly opposite. I can write HTML code, but can= not write in tex/latex. I won't dispute that some people only know tex, and = others only know HTML. I would just venture that more are/will know HTML than l= atex. However, that said, at present time, I will take the docs in most whatev= er it is written in - this is the authors preferance. I just think HTML is a g= ood choice for now/the future. > > Someone mentioned, that LaTeX is not running on all platforms. I know o= f > no major platform, where no TeX is running (especially under unix). But= I > know of serveral platforms not running netscape (if you use their speci= all > table support) > But compiler tex/latex is hardly a simple task. Certainly, there are platforms where netscape is not available (but mosaic is available in sou= rce format.) I don't know if the latest mosaic handles tables yet, however. > Beside that. There will always be some code/shell-scripts in awk, perl > lisp or whatever, to generate parts (the stat/wapon/amour/... tables), > which can produce either TeX-Code. (And they can produce html too :-)) > So you have to combine many tools, to generate a documentation. This ta= sk > is not easy, and probably will not be in the near future. So you need > someone, which knows all, or most of the tools. And if this person know= s > LaTeX, it would produce better output. Apparantly, Lars was able to convert/make new scripts to generate the spo= iler information in 6 hours. I am not sure what other scripts are really out = there. As a quick summary, here are my thoughts: HTML is good because it is fairly easy to learn, pretty standard, viewin= g tools are available on a good many machines. If people actually write new docs and submit them, I will take them if t= hey are in html, latex, postscript, whatever. Docs in whatever format are be= tter than no docs at all. Even if docs are written in HTML we can still easily generate postscript= versions of those files, and distribute those who lack HTML tools or want= a hard copy. The only real reason I can see to use latex is if the author prefers it.= From a user standpoint, we can do everything in HTML format as we can in latex= =2E Only if people are dealing with the source format, it shouldn't make a difference. -- = --Mark --PART-BOUNDARY=.19607021632.ZM25631.eng.pyramid.com-- From owner-crossfire Fri Jul 5 04:10:39 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Fri, 5 Jul 1996 04:10:39 +0200 Received: from alpha.pulsar.net (link@alpha.pulsar.net [206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 5 Jul 1996 04:10:35 +0200 Received: (from link@localhost) by alpha.pulsar.net (8.7.5/8.7.3) id VAA02601; Thu, 4 Jul 1996 21:57:03 -0400 Date: Thu, 4 Jul 1996 21:57:01 -0400 (EDT) From: Matt Cortes Mime-Version: 1.0 To: Mark Wedel cc: Florian Beck , crossfire@ifi.uio.no Subject: Re: CF: Map Generation In-Reply-To: <9606241710.ZM1696@stealth.eng.pyramid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-crossfire Precedence: bulk Status: RO This has nothing to do with the thread "Map Generation", but the subject made me think of something I think we should have implemented a long time ago. I think we should start to focus on random generated dungeons, towns, etc. I don't think its hard to do, its very easy to setup rules to make the random map generator generate "sensable" maps, etc. But doing something like this will make the landscapes new and long time players will have a higher level of exploring. :> I thought about this when I see that map generations are currently kinda low for the game, there is alot of quests, and maps that aren't even finished yet, let alone any new maps. But I think if we take a random generation approach, like Nethack, It would pay off big. Nethack never gets tiring for this reason. And no I don't think we should go COMPLETELY RANDOM like nethack. I believe in the standard locations of towns, etc. Especially for the quests. Its kinda hard to do a completely laid out quest if things are random (Actually, no.. with a certain set of rules, it would be possible for some of the search/locate/destroy/recover quests to be random.. we do that on the MUD called MoonGate we run here matter a fact.). But what I was basicly thinking of is using a random map/town/dungeon generator as a filler for empty space. We could call it the unmapped wilderness or something. Basicly, we have our basic maps in crossfire and constantly add upon that, but on the outer rim of the maps would continue on into a random world. This world is generated whenever the random map generator util or whatever is ran. At any rate.. Its a rough idea, I'm writting this pretty darn late in the day so the above may seem a bit "blah blah blah..", but basicly we need some things to allow VERY easy expansion, etc. It might not be a bad idea to take on alot of the ideas/spells/items from Nethack. Nothing wrong with engulfing a game into another game. It could only improve it. :> Ok, thats it. I'll shut up now. Thanks, -Matt From frankj Sat Jul 6 10:59:48 1996 Subject: Re: CF: Map Generation To: crossfire@ifi.uio.no Date: Sat, 6 Jul 1996 10:59:48 +0000 (BST) In-Reply-To: from "frankj" at Jul 6, 96 10:59:09 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1527 Status: RO > If you use the random encounters, this is a bit different, but random > encounters becomes a bit tedious after a short while (and the times you find > them on normal dungeon maps is a real pain.) There is a flag you can set in maps to have it not generate random encounters. But I guess it would be better to add the opposite flag, and make no encounters the default unless this flag is set. > A better random encounter method could probably be done. My thought would be > that for each type of terrain, have a list of monsters it could generate, and > a chance (I guess you could use a treasure list for this..) Then, have a > random chance of it generating that treasure. My original plan when I made random encounters was to check maps for a certain flag, and if it was set, let the player travel _only_ through random encounters based on that map. That way, if you make a huge overview map, like the world, which lacks in detail, you could have random encounters generate the detail. And when you reach the end of one such random map, you enter the next. Since these were stored you could walk back the same path and recognize where you have been. Also, every archetype would have some effect on the encounter map. Cities and roads would expand in the random maps, coustlines would grow less rough (more detailed)..all in all, more detail would be automatically added to the map. It should be easy to expand the encounter routines. For starters, more maps could be put in the maps/generic directory. -Frank. From owner-crossfire Sat Jul 6 01:34:06 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Sat, 6 Jul 1996 01:34:06 +0200 Received: from gossip.pyramid.com (gossip.pyramid.com [129.214.1.101]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Sat, 6 Jul 1996 01:34:01 +0200 Received: from stealth-news.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA06808; Fri, 5 Jul 96 16:33:29 -0700 Received: by stealth.eng.pyramid.com (8.6.12/Pyramid_Internal_Configuration) id QAA11288; Fri, 5 Jul 1996 16:33:25 -0700 From: "Mark Wedel" Message-Id: <9607051633.ZM11286@stealth.eng.pyramid.com> Date: Fri, 5 Jul 1996 16:33:24 -0700 In-Reply-To: Matt Cortes "Re: CF: Map Generation" (Jul 4, 9:57pm) References: X-Mailer: Z-Mail (3.2.0 06sep94) Mime-Version: 1.0 To: Matt Cortes Subject: Re: CF: Map Generation Cc: crossfire@ifi.uio.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-crossfire Precedence: bulk Status: RO My only thought on random maps is this: If the random map is done on a each individual server, it would seem that once generated, they must remain on that server. Otherwise, if a player wanders out into a randomly generated town and saves his character, when he comes back, that map might not exist. But this then gets into the issue - should the world be infinately large? With random maps, a character could keep wandering west, and keep finding new terrain. If the map generator is done as part of the standard distribution, then I don't see much of a point. I would rather have good designed maps put in place. There are already a lot of hack/slash dungeons, and I don't see a need for a lot more of those. However, a map generator could be an OK thing as a developement aid. If it does a good job, you oculd have it make the continent, and make some adjustments as desired (or have it make the city, or whatever else.) But right now, a lot of map area doesn't mean a lot - it is just stuff that needs to be travelled accross, and just spreads some of the stuff out. If you use the random encounters, this is a bit different, but random encounters becomes a bit tedious after a short while (and the times you find them on normal dungeon maps is a real pain.) A better random encounter method could probably be done. My thought would be that for each type of terrain, have a list of monsters it could generate, and a chance (I guess you could use a treasure list for this..) Then, have a random chance of it generating that treasure. For reasons of speed, it might be reasonable to only check/generate these items if they are within some range of the player (maybe the 11x11 viewing area.) This way, you might meet the off monster while travelling here and there, but not the large encounter maps that you get right now (if ocmpiled with random encounters..) -- --Mark From owner-crossfire Wed Jul 10 13:58:47 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 10 Jul 1996 13:58:47 +0200 Received: from xplorer.gsfc.nasa.gov (xplorer.gsfc.nasa.gov [128.183.126.216]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 10 Jul 1996 13:58:44 +0200 Received: (from thomas@localhost) by xplorer.gsfc.nasa.gov (LHEA9504/950407.s1) id HAA17794; Wed, 10 Jul 1996 07:57:21 -0400 Date: Wed, 10 Jul 1996 07:57:21 -0400 From: Brian Thomas Message-Id: <199607101157.HAA17794@xplorer.gsfc.nasa.gov> Mime-Version: 1.0 To: crossfire@ifi.uio.no, Raphael.Quinet@eed.ericsson.se Subject: Re: CF: Comments on documentation, 2 magic system Sender: owner-crossfire Precedence: bulk Status: RO > From: Raphael.Quinet writes: > > Speaking about that... I modified the "cast" command on my server so > that when you use it without arguments, it lists the spells and > prayers in two sections, like this: > [snip] I like it, perhaps a configuration choice? (but it seems too small a change to justify it). > > Also, I use the same technique as the one used for shop listings in > order to pause after each page when listing the spells and prayers. > This is very useful for me, because I have one character which knows > 135 spells and it is not possible to have all of them on the screen at > the same time (with the "old" pseudo-client which lacks a scrollbar). > > Should this feature be integrated in the next release of Crossfire? My vote is a HUGE YES for this. -b.t. From owner-crossfire Wed Jul 10 13:31:40 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 10 Jul 1996 13:31:40 +0200 Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se [193.180.251.38]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 10 Jul 1996 13:31:35 +0200 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.132.130]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with ESMTP id NAA21327 for ; Wed, 10 Jul 1996 13:31:33 +0200 (MET DST) Received: (from eedraq@localhost) by chapelle.eed.ericsson.se (8.7.1/8.7.1) id NAA12986 for crossfire@ifi.uio.no; Wed, 10 Jul 1996 13:31:31 +0200 (MET DST) Date: Wed, 10 Jul 1996 13:31:31 +0200 (MET DST) Message-Id: <199607101131.NAA12986@chapelle.eed.ericsson.se> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: Re: CF: Comments on documentation, 2 magic system From: Raphael.Quinet@eed.ericsson.se Sender: owner-crossfire Precedence: bulk Status: RO On Wed, 10 Jul 96, "Brian Thomas" wrote: [...] > c. Perhaps it would be valuable to split the > 'spells' section into 2 tables, one for > 'cleric' magic, the other for 'wizard' > magic. Speaking about that... I modified the "cast" command on my server so that when you use it without arguments, it lists the spells and prayers in two sections, like this: > cast Cast what spell? Choose one of: [sp] spell name [01] magic bullet [06] small lightning [gr] prayer name [04] holy word I prefer to see the list of spells and prayers like this, because I can immediately know which spells will use mana points and which ones will use grace points. Also, I use the same technique as the one used for shop listings in order to pause after each page when listing the spells and prayers. This is very useful for me, because I have one character which knows 135 spells and it is not possible to have all of them on the screen at the same time (with the "old" pseudo-client which lacks a scrollbar). Should this feature be integrated in the next release of Crossfire? Should it be configurable? If most people on this list are interested in this, then I will post my patch here or send it to Mark Wedel for inclusion in the next release (by the way, I'd like to know what is the best way to send small or medium patches - post them here or wait until the next release?). -Raphael P.S.: While I'm at it... I have already asked that, but are there any plans to drop the current pseudo-client code and only support the "real" client/server code, so that everyone has to use it and we can assume that it's there when developping new code? From owner-crossfire Wed Jul 10 11:33:14 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 10 Jul 1996 11:33:14 +0200 Received: from nexus.astro.psu.edu (nexus.astro.psu.edu [128.118.147.20]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Wed, 10 Jul 1996 11:33:07 +0200 Received: from zaphod.astro.psu.edu by nexus.astro.psu.edu (4.1/Nexus-1.3) id AA17452; Wed, 10 Jul 96 05:33:42 EDT Received: by zaphod.astro.psu.edu (4.1/Client-1.3) id AA21775; Wed, 10 Jul 96 05:33:03 EDT Date: Wed, 10 Jul 96 05:33:03 EDT From: "Brian Thomas" Message-Id: <9607100933.AA21775@zaphod.astro.psu.edu> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: Comments on documentation, 2 magic system Sender: owner-crossfire Precedence: bulk Status: RO Working on the player's handbook has brought a number of issues to my attention which I would like to share here for opinions. 1) Since the 2 magic system came to be, we have a confusing definition for 'spell'. If can mean both a magic formula that only 'wizards' cast AND it can mean all magic cast. How do we resolve this? One possiblity is to use a new nomenclature: wizard magic --> "wizardry" cleric magic --> ??, perhaps "divine magic" spells --> means both stuff that ``cleric'' and ``wizard'' cast. prayers --> ``cleric'' spells. incantations --> ``wizard'' spells. praybooks --> leave the same. spellbooks --> ?? perhaps call them 'grimore'? 2) Actually a continuation of 1). What do we call the 'spellcasting' skill? This is also confusing. Perhaps we could name it 'wizardry' or some such. 3) Overall I think the spoiler is an excellent resource, but I have some comments: a. I think the + designation for AC and damage in the character table is misleading. These are base values, not bonuses! b. Armour tables are a bit confusing. Why not make the 'magic' column into 'notes'. For example, the 'eyeglasses' give a better dexterity and worse charisma. The effect is not supposed to be magical at all. Also, 'magic clothing' seems to be the wrong name to use since the non-magical 'sandals' appear there. Why not change it to 'other clothing'? c. Perhaps it would be valuable to split the 'spells' section into 2 tables, one for 'cleric' magic, the other for 'wizard' magic. Well, thats all for now. I am nearly finished w/ the players handbook. But more on that soon. Caio, b.t. From owner-crossfire Wed Jul 10 23:35:46 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 10 Jul 1996 23:35:46 +0200 Received: from gossip.pyramid.com (gossip.pyramid.com [129.214.1.101]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Wed, 10 Jul 1996 23:35:42 +0200 Received: from stealth-news.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA04195; Wed, 10 Jul 96 14:35:10 -0700 Received: by stealth.eng.pyramid.com (8.6.12/Pyramid_Internal_Configuration) id OAA09823; Wed, 10 Jul 1996 14:35:05 -0700 From: "Mark Wedel" Message-Id: <9607101435.ZM9821@stealth.eng.pyramid.com> Date: Wed, 10 Jul 1996 14:35:04 -0700 In-Reply-To: Raphael.Quinet@eed.ericsson.se "Re: CF: Comments on documentation, 2 magic system" (Jul 10, 1:31pm) References: <199607101131.NAA12986@chapelle.eed.ericsson.se> X-Mailer: Z-Mail (3.2.0 06sep94) Mime-Version: 1.0 To: Raphael.Quinet@eed.ericsson.se, crossfire@ifi.uio.no Subject: Re: CF: Comments on documentation, 2 magic system Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-crossfire Precedence: bulk Status: RO On Jul 10, 1:31pm, Raphael.Quinet@eed.ericsson.se wrote: > Subject: Re: CF: Comments on documentation, 2 magic system > On Wed, 10 Jul 96, "Brian Thomas" wrote: > [...] > > c. Perhaps it would be valuable to split the > > 'spells' section into 2 tables, one for > > 'cleric' magic, the other for 'wizard' > > magic. > > Speaking about that... I modified the "cast" command on my server so > that when you use it without arguments, it lists the spells and > prayers in two sections, like this: > > > cast > Cast what spell? Choose one of: > > [sp] spell name > [01] magic bullet > [06] small lightning > > [gr] prayer name > [04] holy word > > I prefer to see the list of spells and prayers like this, because I > can immediately know which spells will use mana points and which ones > will use grace points. Seems like a reasonable change. Best long term method would be to have some spell listing display specifics (ie, sort by type, sort by cost, sort by level, etc..) > > Also, I use the same technique as the one used for shop listings in > order to pause after each page when listing the spells and prayers. > This is very useful for me, because I have one character which knows > 135 spells and it is not possible to have all of them on the screen at > the same time (with the "old" pseudo-client which lacks a scrollbar). > > Should this feature be integrated in the next release of Crossfire? > Should it be configurable? If most people on this list are interested > in this, then I will post my patch here or send it to Mark Wedel for > inclusion in the next release (by the way, I'd like to know what is > the best way to send small or medium patches - post them here or wait > until the next release?). The 'problem' with the pause screens is that all that code then needs to be removed in true client/server happens. By the natuer of the game, any time you have information like that, you need to store some of the information in the player structure (if you use static vars in the function, you then have problems if 2 people do that action at the same time..) Arguably, a cleaner way to do this until the clien/server comes along would be to integrates the client's scrollbar into the server code. Generally speaking, my time is a bit limited to do this, but if someone else takes on the task and gives me a patch, I will use it. (probably isn't really hard to do - most of the functions could probalby be used as it - what would need to be changed is the variables that are used..) Patches can be sent either directly to me or to the list - either way I get them and will save and apply them (if appropriate.) What method you choose probably depends on how public you want the patch - if you send it to the list, many people will probably apply it, and if it is still in the expiremental stage, you may not want that. > > -Raphael > > P.S.: While I'm at it... I have already asked that, but are there any > plans to drop the current pseudo-client code and only support the > "real" client/server code, so that everyone has to use it and we > can assume that it's there when developping new code? > >-- End of excerpt from Raphael.Quinet@eed.ericsson.se Real client still needs some more work. I haven't played it lately, but I know for sure that it is lacking magic mapping ability, and support for anything except xpm images (I believe pixmap support has been put in on at least one side.) Problem is that I don't think anyone is really doing much work on it right now.. -- --Mark From owner-crossfire Thu Jul 11 11:57:24 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Thu, 11 Jul 1996 11:57:24 +0200 Received: from xplorer.gsfc.nasa.gov (xplorer.gsfc.nasa.gov [128.183.126.216]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 11 Jul 1996 11:57:20 +0200 Received: (from thomas@localhost) by xplorer.gsfc.nasa.gov (LHEA9504/950407.s1) id FAA24329 for crossfire@ifi.uio.no; Thu, 11 Jul 1996 05:55:57 -0400 Date: Thu, 11 Jul 1996 05:55:57 -0400 From: Brian Thomas Message-Id: <199607110955.FAA24329@xplorer.gsfc.nasa.gov> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: Player's Handbook Sender: owner-crossfire Precedence: bulk Status: RO Whew. After about a week of intensive typing, I believe Ive got a document ready. Its a monster --- about 45 pages! and thats the version compiled w/o little decorative icons everywhere. I would like to have people grab the prototype from my ftp site -- ftp.astro.psu (pub/thomas) and take a look. Two things remain to be done 1- some editing. look over to see if I missed something, or if its too much written (or poorly written). 2- content/style adjustment. How do people like the layout? I had to make up some definitions and I am pretty flexible about changing them. Here's the main ones: --definitions of display windows --primary, secondary stats --wizardry and divine magic to describe "cleric" and "wizard" magic. --"incantations" are what wizards cast; "spells" means both "prayers" and "incantations". --still need a good name for wizard "spellbooks" Ideas? So, Ill shut up now. Im gonna take a rest, then post my ideas for changing the throwing and oratory code. Oh yeah... IF you help edit this document, Ill put you in as a co-authour (a *small* slice of your 15 min of fame ;). I tried to perserve silly british spelling for the document, let me know where I mis-spelled something... -b.t. From owner-crossfire Thu Jul 11 09:53:37 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Thu, 11 Jul 1996 09:53:37 +0200 Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se [193.180.251.38]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 11 Jul 1996 09:53:32 +0200 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.132.130]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with ESMTP id JAA11622; Thu, 11 Jul 1996 09:50:05 +0200 (MET DST) Received: (from eedraq@localhost) by chapelle.eed.ericsson.se (8.7.1/8.7.1) id JAA25442; Thu, 11 Jul 1996 09:50:04 +0200 (MET DST) Date: Thu, 11 Jul 1996 09:50:04 +0200 (MET DST) Message-Id: <199607110750.JAA25442@chapelle.eed.ericsson.se> Mime-Version: 1.0 To: mwedel@pyramid.com Subject: client/server (was Re: CF: Comments on documentation, 2 magic system) Cc: crossfire@ifi.uio.no From: Raphael.Quinet@eed.ericsson.se Sender: owner-crossfire Precedence: bulk Status: RO On Wed, 10 Jul 1996, "Mark Wedel" wrote: [...] > Arguably, a cleaner way to do this until the clien/server comes along would be > to integrates the client's scrollbar into the server code. [...] I thought about this, but I didn't want to do that because it would make the old pseudo-client better and this would be remove one of the reasons to move to the real client/server code. So I hope that nobody will write a patch to do that... > Patches can be sent either directly to me or to the list - either way I get > them and will save and apply them (if appropriate.) What method you choose > probably depends on how public you want the patch - if you send it to the list, > many people will probably apply it, and if it is still in the expiremental > stage, you may not want that. OK, that's what I thought. Anyway, I don't think I will send the patch for pausing in the list of spells, because that one is not perfect yet. But I have a few bug fixes for other parts of the code which could help everybody here, so I will post them to the list. If I have the time, I will also re-do one patch for splitting the spells and prayers in two lists, but without the scrolling trick. > > P.S.: While I'm at it... I have already asked that, but are there any > > plans to drop the current pseudo-client code and only support the > > "real" client/server code, so that everyone has to use it and we > > can assume that it's there when developping new code? > > Real client still needs some more work. I haven't played it lately, but I > know for sure that it is lacking magic mapping ability, and support for > anything except xpm images (I believe pixmap support has been put in on at > least one side.) Problem is that I don't think anyone is really doing much > work on it right now.. Well, I don't mind if only XPM is supported, because I don't use anything else... :-) But here is the problem: About one year ago (or was it two years?), I said on this list that I would revamp my old sound code and add new environmental sounds and other nice effects as soon as the client/server code is done. I've been waiting since then, hoping that one of the releases would drop all support for the old code so that I don't have to maintain two different versions of the code (which would be very different because sounds would have to be handled by the client). I don't want to start with these major changes if the old code is still supported, because I feel that I would be wasting my time. I tried the client/server version some time ago and it seemed promising, although unfinished. Since then, I recompiled my server with the old pseudo-client system, because many people are still using that and improvements and bug fixes are more useful if they are done against the old code. So I have to work on the old code if I want to make patches that are useful to most people, but I don't like that. Also, this prevents me from working on user interface improvements, because that part of the code is very different in the new client/server version. In summary, from my point of view, supporting two versions of the code slows things down and prevents me (and possibly others) from working on some improvements that I would like to add to Crossfire. It should be a "political" decision to drop the old pseudo-client code and clean up the source tree, and you and Frank are probably the ones who should decide how/when/if this is done. When (if?) only the new code is supported, it will be possible to improve the client and the server independently, thus allowing some people to make the user interface more attractive while others are adding new features to the server. A better client would probably attract more people to Crossfire (and potential developers too). -Raphael From owner-crossfire Fri Jul 12 06:08:05 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Fri, 12 Jul 1996 06:08:05 +0200 Received: from ender.ring.org (krisb@ender.ring.org [204.27.179.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 12 Jul 1996 06:08:01 +0200 Received: (from krisb@localhost) by ender.ring.org (8.6.12/8.6.9) id TAA02818; Thu, 11 Jul 1996 19:27:21 -0700 Date: Thu, 11 Jul 1996 19:27:10 -0700 (PDT) From: Kristofer Bosland Mime-Version: 1.0 To: Mark Wedel cc: crossfire@ifi.uio.no Subject: Re: client/server (was Re: CF: Comments on documentation, 2 magic system) In-Reply-To: <9607111801.ZM28921@stealth.eng.pyramid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-crossfire Precedence: bulk Status: RO On Thu, 11 Jul 1996, Mark Wedel wrote: > A new client is a good idea. A wonder if a worthwhile strategy right now > might be to just make the client fully functional and not care too much about > network utilitization (as long as it isn't incredibly inefficient), and then > work on streamlining and cleaning it up at a later point. A lot of people are > still playing on a local network, so efficiency isn't fully needed, but a > working client is. Arguable, you could even make assumptions that the client > has full access to the pixmaps to start out, and worry about transferring them > at a later time. > > Right now, I think we need to look into anything that gets us a fully working > client. You can hardly say use the client right now, when some things are not > supported. > > -- > --Mark > We definately should not worry about pix/XPM dynamic loading with the client right now. I think that we should not duplicate things like Mouse Events, but I don't know how the code goes from there to "Game" things. I think that the client/server interface can start out resembling some internal function calls from inside the current server, and then let it evolve. -Kris From owner-crossfire Fri Jul 12 03:02:19 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Fri, 12 Jul 1996 03:02:19 +0200 Received: from gossip.pyramid.com (gossip.pyramid.com [129.214.1.101]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 12 Jul 1996 03:02:15 +0200 Received: from stealth-news.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA29011; Thu, 11 Jul 96 18:01:43 -0700 Received: by stealth.eng.pyramid.com (8.6.12/Pyramid_Internal_Configuration) id SAA28923; Thu, 11 Jul 1996 18:01:36 -0700 From: "Mark Wedel" Message-Id: <9607111801.ZM28921@stealth.eng.pyramid.com> Date: Thu, 11 Jul 1996 18:01:34 -0700 In-Reply-To: Raphael.Quinet@eed.ericsson.se "client/server (was Re: CF: Comments on documentation, 2 magic system)" (Jul 11, 9:50am) References: <199607110750.JAA25442@chapelle.eed.ericsson.se> X-Mailer: Z-Mail (3.2.0 06sep94) Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: Re: client/server (was Re: CF: Comments on documentation, 2 magic system) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-crossfire Precedence: bulk Status: RO On Jul 11, 9:50am, Raphael.Quinet@eed.ericsson.se wrote: > Subject: client/server (was Re: CF: Comments on documentation, 2 magic sys > On Wed, 10 Jul 1996, "Mark Wedel" wrote: > [...] > > Arguably, a cleaner way to do this until the clien/server comes along would be > > to integrates the client's scrollbar into the server code. [...] > > I thought about this, but I didn't want to do that because it would > make the old pseudo-client better and this would be remove one of the > reasons to move to the real client/server code. So I hope that nobody > will write a patch to do that... That was also some of the reason I also didn't merge it in (along with the time issues.) It is also much easier to work on that stuff on the client - server can keep on running, and only a quick recompile is needed of the client is needed to see if it works.. > Well, I don't mind if only XPM is supported, because I don't use > anything else... :-) But here is the problem: > > (much discussion about plans and client/server cut for brevity) I agree that the client and server should be separated. but someone actually needs to take this task on (I don't have the time to work on that right now.) Is anyone out there serious working on client/server right now, or has it pretty much stagnated again? > In summary, from my point of view, supporting two versions of the code > slows things down and prevents me (and possibly others) from working > on some improvements that I would like to add to Crossfire. It should > be a "political" decision to drop the old pseudo-client code and clean > up the source tree, and you and Frank are probably the ones who should > decide how/when/if this is done. In some sense, it is really two complete seperate versions. For example, most all of the code Brian has put in will be pretty much the same no matter how client/server works out. Anything interface related would need to go in both versions, however. > > When (if?) only the new code is supported, it will be possible to > improve the client and the server independently, thus allowing some > people to make the user interface more attractive while others are > adding new features to the server. A better client would probably > attract more people to Crossfire (and potential developers too). A new client is a good idea. A wonder if a worthwhile strategy right now might be to just make the client fully functional and not care too much about network utilitization (as long as it isn't incredibly inefficient), and then work on streamlining and cleaning it up at a later point. A lot of people are still playing on a local network, so efficiency isn't fully needed, but a working client is. Arguable, you could even make assumptions that the client has full access to the pixmaps to start out, and worry about transferring them at a later time. Right now, I think we need to look into anything that gets us a fully working client. You can hardly say use the client right now, when some things are not supported. -- --Mark From owner-crossfire Sat Jul 13 03:56:11 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Sat, 13 Jul 1996 03:56:11 +0200 Received: from gossip.pyramid.com (gossip.pyramid.com [129.214.1.101]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Sat, 13 Jul 1996 03:56:07 +0200 Received: from stealth-news.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA19650; Fri, 12 Jul 96 18:55:34 -0700 Received: by stealth.eng.pyramid.com (8.6.12/Pyramid_Internal_Configuration) id SAA08853; Fri, 12 Jul 1996 18:55:28 -0700 From: "Mark Wedel" Message-Id: <9607121855.ZM8851@stealth.eng.pyramid.com> Date: Fri, 12 Jul 1996 18:55:27 -0700 In-Reply-To: Eric Anderson "Re: CF: players' handbook, client/server" (Jul 12, 6:32pm) References: <9607111801.ZM28921@stealth.eng.pyramid.com> <199607130132.SAA16910@u98.CS.Berkeley.EDU> X-Mailer: Z-Mail (3.2.0 06sep94) Mime-Version: 1.0 To: Eric Anderson , John W Klar Subject: Re: CF: players' handbook, client/server Cc: crossfire@ifi.uio.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-crossfire Precedence: bulk Status: RO As a quick note, there are docs in the client distribution that gives a reasonably detailed description of the various lower level options. Also, all the docs that Eric sent in his last message have been previously put in with the client. Generally speaking, this is how it works: The client sends high level commands to the server for player actions. Meaning, that if the player clicks on the map, or presses a key, it translates that into a 'move north (or appropriate direction)', and does not send something like 'key XX was pressed or button yy pressed.'. This also means the keybindings are handled on the client side now. For items, the client interperts buttonpresses the same way. If you click on something in the inventory, it will send an examine, drop, or apply command with the item id. On the server side, line of site and animations is calculated on the server. The server than packs up the changes from the last frame, and sends them to the client. In practice, animations should be handled by the client at some point in time. On Jul 12, 6:32pm, Eric Anderson wrote: > Subject: Re: CF: players' handbook, client/server > So I sent a long message to this list with a lot of details about the > client/server pieces I wrote. I've replicated it below. > > jklar@lucent.com writes: > > item transfers examined item info > > drawinfo tells the client to send a text message to user > > stats transfers character stats > > pixmap transfers pixmap data > > bitmap transfers bitmap data > > version transfers version data > > player transfers (trivial) player object info > > > > foo(*) tells client to output a string to STDOUT > > bar(*) NOP(?) > > > > addme_failed(*) tells client to print a failure string to STDOUT > > addme_success(*)tells client to print a success string to STDOUT > > > > query tells the client to get a response from the user > > > > (*) I'm assuming these are debugging commands > Yes. It's easy to convert foo to bar, which is why bar serves as a noop. > It also lets you tell what code the server is executing to make sure > that you understand what's going on inside the server without having to > implement anything new on the client. > > > Hmmm, how is Line-Of-Sight handled? Looks like I'm going to have to hunt > > around for the client->server messages. With any sort of luck and motivation, > > I should have the basic protocol (commands w/arguments) documented by the end > > of the weekend. > line of sight is handled on the server. This is the way it should remain > since you don't want to give the client any information it shouldn't have. > -Eric > > ****Message from before:***** > So I felt a little bad as one of the people that worked on the client > for not documenting, so here is some documentation for the different pieces: > If people have questions, they can feel free to send them to me. I don't > expect to spend any time working on crossfire in the near future. > -Eric > > Client side: > > Overall, the client talks to the server through a tcpsocket. It recieves > messages telling it what to do, and it sends inputs to the server. Many > of the commands are more low-level than would be preferrable, but the > low-level commands mesh better with the current crossfire implementation. > > client.c: > * this file sets up a few global variables, connects to the server, > * tells it what kind of pictures it wants, adds the client and enters > * the main dispatch loop > * > * the main event loop (event_loop()) checks the tcp socket for input and > * then polls for x events. This should be fixed since you can just block > * on both filedescriptors. > * > * The DoClient function recieves a message (an ArgList), unpacks it, and > * in a slow for loop dispatches the command to the right function through > * the commands table. ArgLists are essentially like RPC things, only > * they don't require going through RPCgen, and it's easy to get variable > * length lists. They are just lists of longs, strings, characters, and > * byte arrays that can be converted to a machine independent format > > commands.c: > * this file contains most of the commands for the dispatch loop most of > * the functions are self-explanatory, the pixmap/bitmap commands recieve > * the picture, and display it. The drawinfo command draws a string > * in the info window, the stats command updates the local copy of the stats > * and displays it. handle_query prompts the user for input. > * send_reply sends off the reply for the input. > * player command gets the player information. > * ItemCmd grabs and display information for items in the inventory > * MapScroll scrolls the map on the client by some amount > * MapCmd displays the map either with layer packing or stack packing. > * packing/unpacking is best understood by looking at the server code > * (server/ericserver.c) > * stack packing is easy, for every map entry that changed, we pack > * 1 byte for the x/y location, 1 byte for the count, and 2 bytes per > * face in the stack. > * layer packing is harder, but I seem to remember more efficient: > * first we pack in a list of all map cells that changed and are now > * empty. The end of this list is a 255, which is bigger that 121, the > * maximum packed map location. > * For each changed location we also pack in a list of all the faces and > * X/Y coordinates by layer, where the layer is the depth in the map. > * This essentially takes slices through the map rather than stacks. > * Then for each layer, (max is MAXMAPCELLFACES, a bad name) we start > * packing the layer into the message. First we pack in a face, then > * for each place on the layer with the same face, we pack in the x/y > * location. We mark the last x/y location with the high bit on > * (11*11 = 121 < 128). We then continue on with the next face, which > * is why the code marks the faces as -1 if they are finished. Finally > * we mark the last face in the layer again with the high bit, clearly > * limiting the total number of faces to 32767, the code comments it's > * 16384, I'm not clear why, but the second bit may be used somewhere > * else as well. > * The unpacking routines basically perform the opposite operations. > > player.c: > * does most of the work for sending messages to the server > * Again, most of these appear self explanatory. Most send a bunch of > * commands like apply, examine, fire, run, etc. This looks like it > * was done by Mark to remove the old keypress stupidity I used. > > item.c: > * I didn't write this piece, so don't really know how it works. > > Server Side: > > server/ericserver.c: > * This file implements all of the goo on the server side for handling > * clients. It's got a bunch of global variables for keeping track of > * each of the clients. > * SWH sends a message, protecting against certain exceptions being thrown. > * InitConnection initializes the connection with the client, and sends > * the server's protocol version (the client sends one of these too) > * PlayerCmd executes commands from the player > * VersionCmd checks the version number of the client > * AddMeCmd adds the player to the game. > * KeyConversion/KeyPress/KeyRelease are deprecated. > * Examine,Apply,Move Cmd handle those things > * dropconnection destroys the connection from the client. > * init_ericserver reads in all of the bitmap information, and initializes > * lots of spoo. > * CmdMapping is the dispatch table for the server, used in HandleClient, > * which gets called when the client has input. > * esrv_remove_player removes a player (called from xfire sources) > * esrv_drawinfo sends drawing info to the client > * send_query asks the client to query the user > * esrv_print_msg draws a normal message on the client > * esrv_write_ch is deprecated > * esrv_foo and esrv_bar are for debugging and just ship across server > * messages > * esrv_update_stats sends a statistics update. > * blah blah blah more esrv_* commands > * esrv_send_face sends a face to a client if they are in pixmap mode > * nothing gets sent in bitmap mode. > * esrv_map_new starts updating the map > * esrv_map_clearcell clears a map cell > * esrv_map_setbelow allows filling in all of the faces for the map. > * if a face has not already been sent to the client, it is sent now. > * mapcellchanged, compactlayer, compactstack, perform the map compressing > * operations > * esrv_map_doneredraw finishes the map update, and ships across the > * map updates. > * esrv_map_scroll tells the client to scroll the map, and does similarily > * for the locally cached copy. >-- End of excerpt from Eric Anderson -- --Mark From owner-crossfire Sat Jul 13 03:33:16 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Sat, 13 Jul 1996 03:33:16 +0200 Received: from u98.CS.Berkeley.EDU (u98.CS.Berkeley.EDU [128.32.38.222]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 13 Jul 1996 03:33:11 +0200 Received: (from eanders@localhost) by u98.CS.Berkeley.EDU (8.6.11/8.6.9) id SAA16910; Fri, 12 Jul 1996 18:32:39 -0700 Date: Fri, 12 Jul 1996 18:32:39 -0700 Message-Id: <199607130132.SAA16910@u98.CS.Berkeley.EDU> From: Eric Anderson Mime-Version: 1.0 To: John W Klar Cc: crossfire@ifi.uio.no Subject: Re: CF: players' handbook, client/server In-Reply-To: References: <9607111801.ZM28921@stealth.eng.pyramid.com> Sender: owner-crossfire Precedence: bulk Status: RO So I sent a long message to this list with a lot of details about the client/server pieces I wrote. I've replicated it below. jklar@lucent.com writes: > item transfers examined item info > drawinfo tells the client to send a text message to user > stats transfers character stats > pixmap transfers pixmap data > bitmap transfers bitmap data > version transfers version data > player transfers (trivial) player object info > > foo(*) tells client to output a string to STDOUT > bar(*) NOP(?) > > addme_failed(*) tells client to print a failure string to STDOUT > addme_success(*)tells client to print a success string to STDOUT > > query tells the client to get a response from the user > > (*) I'm assuming these are debugging commands Yes. It's easy to convert foo to bar, which is why bar serves as a noop. It also lets you tell what code the server is executing to make sure that you understand what's going on inside the server without having to implement anything new on the client. > Hmmm, how is Line-Of-Sight handled? Looks like I'm going to have to hunt > around for the client->server messages. With any sort of luck and motivation, > I should have the basic protocol (commands w/arguments) documented by the end > of the weekend. line of sight is handled on the server. This is the way it should remain since you don't want to give the client any information it shouldn't have. -Eric ****Message from before:***** So I felt a little bad as one of the people that worked on the client for not documenting, so here is some documentation for the different pieces: If people have questions, they can feel free to send them to me. I don't expect to spend any time working on crossfire in the near future. -Eric Client side: Overall, the client talks to the server through a tcpsocket. It recieves messages telling it what to do, and it sends inputs to the server. Many of the commands are more low-level than would be preferrable, but the low-level commands mesh better with the current crossfire implementation. client.c: * this file sets up a few global variables, connects to the server, * tells it what kind of pictures it wants, adds the client and enters * the main dispatch loop * * the main event loop (event_loop()) checks the tcp socket for input and * then polls for x events. This should be fixed since you can just block * on both filedescriptors. * * The DoClient function recieves a message (an ArgList), unpacks it, and * in a slow for loop dispatches the command to the right function through * the commands table. ArgLists are essentially like RPC things, only * they don't require going through RPCgen, and it's easy to get variable * length lists. They are just lists of longs, strings, characters, and * byte arrays that can be converted to a machine independent format commands.c: * this file contains most of the commands for the dispatch loop most of * the functions are self-explanatory, the pixmap/bitmap commands recieve * the picture, and display it. The drawinfo command draws a string * in the info window, the stats command updates the local copy of the stats * and displays it. handle_query prompts the user for input. * send_reply sends off the reply for the input. * player command gets the player information. * ItemCmd grabs and display information for items in the inventory * MapScroll scrolls the map on the client by some amount * MapCmd displays the map either with layer packing or stack packing. * packing/unpacking is best understood by looking at the server code * (server/ericserver.c) * stack packing is easy, for every map entry that changed, we pack * 1 byte for the x/y location, 1 byte for the count, and 2 bytes per * face in the stack. * layer packing is harder, but I seem to remember more efficient: * first we pack in a list of all map cells that changed and are now * empty. The end of this list is a 255, which is bigger that 121, the * maximum packed map location. * For each changed location we also pack in a list of all the faces and * X/Y coordinates by layer, where the layer is the depth in the map. * This essentially takes slices through the map rather than stacks. * Then for each layer, (max is MAXMAPCELLFACES, a bad name) we start * packing the layer into the message. First we pack in a face, then * for each place on the layer with the same face, we pack in the x/y * location. We mark the last x/y location with the high bit on * (11*11 = 121 < 128). We then continue on with the next face, which * is why the code marks the faces as -1 if they are finished. Finally * we mark the last face in the layer again with the high bit, clearly * limiting the total number of faces to 32767, the code comments it's * 16384, I'm not clear why, but the second bit may be used somewhere * else as well. * The unpacking routines basically perform the opposite operations. player.c: * does most of the work for sending messages to the server * Again, most of these appear self explanatory. Most send a bunch of * commands like apply, examine, fire, run, etc. This looks like it * was done by Mark to remove the old keypress stupidity I used. item.c: * I didn't write this piece, so don't really know how it works. Server Side: server/ericserver.c: * This file implements all of the goo on the server side for handling * clients. It's got a bunch of global variables for keeping track of * each of the clients. * SWH sends a message, protecting against certain exceptions being thrown. * InitConnection initializes the connection with the client, and sends * the server's protocol version (the client sends one of these too) * PlayerCmd executes commands from the player * VersionCmd checks the version number of the client * AddMeCmd adds the player to the game. * KeyConversion/KeyPress/KeyRelease are deprecated. * Examine,Apply,Move Cmd handle those things * dropconnection destroys the connection from the client. * init_ericserver reads in all of the bitmap information, and initializes * lots of spoo. * CmdMapping is the dispatch table for the server, used in HandleClient, * which gets called when the client has input. * esrv_remove_player removes a player (called from xfire sources) * esrv_drawinfo sends drawing info to the client * send_query asks the client to query the user * esrv_print_msg draws a normal message on the client * esrv_write_ch is deprecated * esrv_foo and esrv_bar are for debugging and just ship across server * messages * esrv_update_stats sends a statistics update. * blah blah blah more esrv_* commands * esrv_send_face sends a face to a client if they are in pixmap mode * nothing gets sent in bitmap mode. * esrv_map_new starts updating the map * esrv_map_clearcell clears a map cell * esrv_map_setbelow allows filling in all of the faces for the map. * if a face has not already been sent to the client, it is sent now. * mapcellchanged, compactlayer, compactstack, perform the map compressing * operations * esrv_map_doneredraw finishes the map update, and ships across the * map updates. * esrv_map_scroll tells the client to scroll the map, and does similarily * for the locally cached copy. From owner-crossfire Fri Jul 12 23:41:35 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Fri, 12 Jul 1996 23:41:35 +0200 Received: from xplorer.gsfc.nasa.gov (xplorer.gsfc.nasa.gov [128.183.126.216]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 12 Jul 1996 23:41:31 +0200 Received: (from thomas@localhost) by xplorer.gsfc.nasa.gov (LHEA9504/950407.s1) id RAA26088 for crossfire@ifi.uio.no; Fri, 12 Jul 1996 17:40:06 -0400 Date: Fri, 12 Jul 1996 17:40:06 -0400 From: Brian Thomas Message-Id: <199607122140.RAA26088@xplorer.gsfc.nasa.gov> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: part2: newskills Sender: owner-crossfire Precedence: bulk Status: RO Ok, here's my 2nd part--the new skills. -b.t. THROWING -- CF has been hurting for a real throwing skill for some time; I would like to take a stab at it but I must admit that my first attempt to write this code a few months back crashed and burned. In essence, I would like to re-use the arrow/missile code for thrown objects. As a first attempt, all thrown (flying) items will use the same face as they had when they were 'unthrown'. I will construct a thrown object form the object to be thrown, then insert the original object into the thrown object. When the thrown object hits something, the original object is re-inserted into the map or target inventory as appropriate. Sometimes thrown objects break. So we need a contingency table for this too. ie potions need to effect the target, containers need to spill their contents, and we should allow torches (or other burning stuff) to light stuff near (or on!) the target on fire. NPC's should be able to throw stuff. 2-handed melee. Yesterday I was scanning through the player classes mentally checking off which ones were harder and easier. THen I came to the swashbuckler. I realized that this was the one class I have never played. Why? basically poor swashbuckler suffers from low INT, and a shitty special skill (singing, feh). Lets give him a better skill. In two-handed melee, the user can use 2 weapons (bet you guessed that). Here's some conditions for using it: o you need to know melee weapons skill first (not a biggie -- since all players currently start with this) o you earn fractionly less experience from using it (since its really an advantage in combat). Possible fraction ~ 2/3. o place a weight limit on the combined weight of the 'primary' and secondary weapons. o sheild is unapplied if you use this. Now, what will it do?? You get 2 possibilities: - under normal usage, you just add in the secondary weapon's damage. - if you use a 'special' attack (cf melee weapons) of the 'primary' weapon, the secondary weapon damage is reduced by 1/2. Lets also allow a text option, ie use_skill 2-handed that you could bind to a key, allowing you to use *either* the primary or secondary weapon in a 'special' attack. So, for example, lets say a player has a mace (bash) and a dagger (parry). The player can either: use_skill 2-handed mace (excuting special bash 'attack') or use_skill 2-handed dagger (excuting special parry 'attack') From owner-crossfire Fri Jul 12 23:20:40 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Fri, 12 Jul 1996 23:20:40 +0200 Received: from xplorer.gsfc.nasa.gov (xplorer.gsfc.nasa.gov [128.183.126.216]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 12 Jul 1996 23:20:36 +0200 Received: (from thomas@localhost) by xplorer.gsfc.nasa.gov (LHEA9504/950407.s1) id RAA26075 for crossfire@ifi.uio.no; Fri, 12 Jul 1996 17:19:12 -0400 Date: Fri, 12 Jul 1996 17:19:12 -0400 From: Brian Thomas Message-Id: <199607122119.RAA26075@xplorer.gsfc.nasa.gov> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: New, revamped skills Sender: owner-crossfire Precedence: bulk Status: RO Hi again, I wanted to throw out a couple of proposals for revamping some of the skills, and introducing 2 new ones. Revamp these: oratory skill, melee weapons, jump New skills: 2-weapons, throwing Since its alot of text, Ill break it up into 2 mail messages. In this first one, lets discuss the revamps. -b.t. SKILLS TO REVAMP >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ORATORY skill --- synopsis: Currently this skill is poorly implemented. I would like to 'fix' this skill by making it more likely to success (esp. at lower levels) and by allowing it to have 'options'. In effect, the 'default' skill remains the same -- you can recruit monsters w/ it, but we add on some nice options: - attack follower(s) will attack named creature *or* if no name given will attack all non-friendly creatures (incl. nuetrals). - wait, sleep follower this is told to stops moving. - come, awake follower moves again. - bye follower if 'freed' from service - talk follower suggests (randomly) topics from its msg buffer *or* will describe what its holding. - follow follower will follow player instead. - use follower will use if in inventory. - drop follower will drop . MELEE WEAPONS --- synopsis: Currently ok implement, lets add spice. In one of the skills docs TODO list I meantion how neat it would be to do something more w/ melee weapons. Well, I guess its time. Here's the idea. For all weapons, allow a 'special' attack to be made. THis is executed by the player readying the melee weapons skill, then making a 'ranged attack' (ie explicitly using the melee weapons skill rather than just running into stuff -- you can do this already, but its the same as 'normal' combat). I would like to 'flag' the weapons archetypes so that the code will know what to do when you make a 'special' attack. Heres my list: 'bash' - weapon destroys (worn) armour, then makes the target get moved back (under certain conditions). 'chop' - weapon does 3x damage versus inanimate objects like doors and chests. Can be used to 'destroy' weapons held by others. 'parry' - weapon will parry, in game terms, weapon damage is subtracted from player damage total, but player AC and armour are enhanced. 'disarm' - weapon will cause a 'disarm' versus targets weapon. Now, each weapon gets only one type of special attack, and if we dont flag a weapon w/ 'bash' 'chop' or 'disarm' then its a parrying weapon, *unless* it has the 'noparry' option. In that case, the weapon gets *no* special attack. Cases of 'weapons' w/o special attacks include tables, chairs, and magnifying glasses. NPC's should be able to use all of these attacks. Whether they do or not will be a factor of their INT and what they are wielding! JUMPING --- synopis: implemented primarily as 'movement' I want to enchance the damage done w/ jumping. Lets also allow it a 'bash' attack (but it never damages armour). From owner-crossfire Fri Jul 12 22:30:28 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Fri, 12 Jul 1996 22:30:28 +0200 Received: from xplorer.gsfc.nasa.gov (xplorer.gsfc.nasa.gov [128.183.126.216]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 12 Jul 1996 22:30:25 +0200 Received: (from thomas@localhost) by xplorer.gsfc.nasa.gov (LHEA9504/950407.s1) id QAA25992 for crossfire@ifi.uio.no; Fri, 12 Jul 1996 16:29:00 -0400 Date: Fri, 12 Jul 1996 16:29:00 -0400 From: Brian Thomas Message-Id: <199607122029.QAA25992@xplorer.gsfc.nasa.gov> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: IP address for ftp.astro.psu.edu Sender: owner-crossfire Precedence: bulk Status: RO Name: tabloid.astro.psu.edu Address: 128.118.147.36 Aliases: ftp.astro.psu.edu Cheers! b.t. From owner-crossfire Fri Jul 12 14:50:18 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Fri, 12 Jul 1996 14:50:18 +0200 Received: from ihgw2.att.com (ihgw2.att.com [207.19.48.2]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 12 Jul 1996 14:50:13 +0200 From: jklar@lucent.com Received: from nesuns2.oms.lucent.com. by ihig2.att.att.com (SMI-8.6/EMS-1.2 sol2) id HAA26473; Fri, 12 Jul 1996 07:46:49 -0500 Received: from kinderlinux (jwk@neppp01.oms.lucent.com [135.114.250.241]) by nesuns2.oms.lucent.com. (8.7.5/OMS960320) with SMTP id IAA06386 for ; Fri, 12 Jul 1996 08:22:10 -0400 (EDT) Date: Fri, 12 Jul 1996 08:53:15 -0400 (EDT) Original-From: John W Klar Reply-To: John W Klar Subject: CF: players' handbook, client/server Mime-Version: 1.0 To: crossfire@ifi.uio.no In-Reply-To: <9607111801.ZM28921@stealth.eng.pyramid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-crossfire Precedence: bulk Status: RO Re: players' handbook Hey! Good start! A few other comments... - In a typeset document you want to stay away from underlining - There are several '--' pairs that should be converted to a single dash. Pairs are valid for monospaced fonts, but an em-dash should be used in a typeset document. - Use a monospace font for email addresses - What's a 20 kg Sheila? (pg 35, towards end of section 6.3.1) :) - I have been unable to find anything crossfire on ftp.i.net Other Suggestions: - Add a walkthru of one of the newbie dungeons or at least point new players to the Begginers' - An example is needed of some gods, what powers they grant, what vulnerabilities they inflict Re: client/server I've just been poking at this -- please don't take it as a commitment :) On Fri, 12 Jul 1996, Kris Bosland wrote: > I think that the client/server interface can start out resembling some > internal function calls from inside the current server, and then let it > evolve. That's pretty much the case. The c/s conversation is something of a multilayered (at least 2) protocol: The eutl library encodes the messages into a stream of Longs, Strings, Buffers and Char's and prepends an overall message length. The latter makes a big difference in performance (an event/interrupt per message intstead of per byte). The next layer embodies the c/s conversation. According to cf-client-0.92.4 the following server->client commands are understood: map transfers encoded map data map_scroll tells the client to reposition the viewport item transfers examined item info drawinfo tells the client to send a text message to user stats transfers character stats pixmap transfers pixmap data bitmap transfers bitmap data version transfers version data player transfers (trivial) player object info foo(*) tells client to output a string to STDOUT bar(*) NOP(?) addme_failed(*) tells client to print a failure string to STDOUT addme_success(*)tells client to print a success string to STDOUT query tells the client to get a response from the user (*) I'm assuming these are debugging commands Hmmm, how is Line-Of-Sight handled? Looks like I'm going to have to hunt around for the client->server messages. With any sort of luck and motivation, I should have the basic protocol (commands w/arguments) documented by the end of the weekend. John From owner-crossfire Tue Jul 16 14:14:19 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Tue, 16 Jul 1996 14:14:19 +0200 Received: from cbgw1.att.com (cbgw1.att.com [192.20.239.133]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 16 Jul 1996 14:14:13 +0200 From: jklar@lucent.com Cc: Eric Anderson , John W Klar , crossfire@ifi.uio.no Received: from nesuns2.oms.lucent.com. by cbig1.att.att.com (SMI-8.6/EMS-1.2 sol2) id IAA23085; Tue, 16 Jul 1996 08:09:26 -0400 Received: from kinderlinux (jwk@neppp01.oms.lucent.com [135.114.250.241]) by nesuns2.oms.lucent.com. (8.7.5/OMS960320) with SMTP id HAA07639; Tue, 16 Jul 1996 07:46:15 -0400 (EDT) Date: Tue, 16 Jul 1996 08:17:39 -0400 (EDT) Original-From: John W Klar Reply-To: John W Klar Subject: Re: CF: client/server Mime-Version: 1.0 To: Mark Wedel Original-cc: Eric Anderson , John W Klar , crossfire@ifi.uio.no In-Reply-To: <9607121855.ZM8851@stealth.eng.pyramid.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="13109504-1169529124-837519460=:122" Sender: owner-crossfire Precedence: bulk Status: RO --13109504-1169529124-837519460=:122 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > > As a quick note, there are docs in the client distribution that gives a > reasonably detailed description of the various lower level options. Also, > all the docs that Eric sent in his last message have been previously put > in with the client. > Yes and quite helpful. > Generally speaking, this is how it works: > > The client sends high level commands to the server for player actions. > Meaning, that if the player clicks on the map, or presses a key, it > translates that into a 'move north (or appropriate direction)', and does > not send something > like 'key XX was pressed or button yy pressed.'. This also means the > keybindings are handled on the client side now. > > For items, the client interperts buttonpresses the same way. If you click > on something in the inventory, it will send an examine, drop, or apply > command with > the item id. > > On the server side, line of site and animations is calculated on the > server. > The server than packs up the changes from the last frame, and sends them to > the client. Hmmm, I think the root of my confusion is the Protocol file in the client. What's outlined there is NOT what happens today. > In practice, animations should be handled by the client at > some point in time. Might want to throw in something to detect whether the client has a 'full' set of pixmaps instead of sending them over the link (although, in practice, it works better than I thought it would). What I have attempted to do is to create some documentation of the conversation between the client and server to aid the effort to create an X-less client. eutl.gz: describes the message protocol protocol.gz: describes the client/server conversation maplayer.gz: describes the map layer packing format --13109504-1169529124-837519460=:122 Content-Type: APPLICATION/octet-stream Content-Transfer-Encoding: BASE64 Content-Description: eutl.gz H4sICCSG6zEAA2V1dGwAlVLRbtMwFH2/X3E0HoGIDZ4q8cCmbiBVqbS1H+Da t61FYle2A0SK9u1cJ2m6DjaBLdnxzTnH9x7f+Xq1QKVaDvR5GoTnY37Zr1dP Io7w9v0f8xGP04opQuiAih3yDtnQpQ7muKIoiumbnfkfZcq6M9Qco9pxPuzS niAhuaipNxzgtyKaguVISDmeTy1Se2CCOQWMSoqo9IlnUFWFuqmS3bSJ8UNV DUeowLAOFyWnnz58x3X+twyGwwXRTfAxbq1AmijYtGdwkypUdhOUqEcpLEL7 ulb5Yxt8De8Y0RpG8j3ByxIKmiu9nyrS3iVlXezBI70AVgKX22LCJ+QcYy4z azznUQ4OthwhgYV2Dh8VHf86CY4KPUz7xmUOjU6KZVodYlOpxAYj6EzL5WR5 8GHgvIPqTe/lydY1Gyv0qsUhsGZzdG16jIJIhMTRbPzWN6GnxxnRYlneyfa0 T6THPkh3ZR668z/0sLr/Vt7RX/tq5F5OHaplDh2pu5cZY9+9yT7qvQpKJw4x O/EgxbqdAIZOyiUNIdiIcrlCuV4sIOjauuwe0fX69nZ+/2p6V1N6RuaQnvnH 9IbXlMyGBr/5+mW6S5Q/nsqk32C/o/IOBAAA --13109504-1169529124-837519460=:122 Content-Type: APPLICATION/octet-stream Content-Transfer-Encoding: BASE64 Content-Description: maplayer.gz H4sICD5q6DEAA21hcGxheWVyAJVTXWvbMBR9rn7FoTDWsiZbxsrAow9J18BY NsJaKHuU7avZoEpBktcYSn/7rqQkpG62Ud8H60r345xzpeX08uvVZ3ybLrGY /rz6gaWzwVZWi4u/feI6uK4KnSNYhdAQju/k6hhlpxS5QojvNlAhjtY9yFS2 phpln3dwgXX/djL5JI76tH4V10JgKV3ABKMRKk3SoSKtvWD/wMfhb0Z7JvBQ smE8HscVN62HEQM/2iMen2be5D9wqMIuQ6AsdrSYYWWtq30UIkJGsJmAwE2B d2ulcMLF4nFmeLoj+z6SlXUNJSs6TDXCjk2HQA7bhlAkwFTUPrXZA+YD/ynV F3YRUEXCfQbVOh/SfF97NO2vBmUbthrM/x3lKfxfTpbo7Fnh2YuSYh+BKWsd L2tEhNbUbSVDupppd3K+uJ7hZGW9b0vdY/KB/dPtBVewjiUU+C11R7EDyarZ nqbL+rzkx1hxE1LGArOczsMOjQxQVmt7z2P4oiD5sPWJVGcCOWL80lhOdRvA ew045TK/DwZSEmon7w18YztdRz+JxDiS6hx825DJNNIY5sNOghU0oTWZWX6A JSnrcmlwXKshWdo28PwyXRlPraExS7uQPbm85ckErrK6s9wpAxB/AJBrbGJk BAAA --13109504-1169529124-837519460=:122 Content-Type: APPLICATION/octet-stream Content-Transfer-Encoding: BASE64 Content-Description: protocol.gz H4sICHcn5zEAA3Byb3RvY29sAM1ZW5MauRV+bn6Fyi+GFGZ3vXmJN6kpMjAz VM3ABJi1/USJbgHt7W4RST0DSeW/5zuS+gLdjCfZPMRVtkE65+jczyexeHp4 GM6/djrXSSwyw4xkC6Geher85exPB4s6llkQGMUzvcE35pdYxA0nVu1YeRSl AnQiSbRfo10ss0y8sG6efYiz2MQ8if8hoh7bJ/zoSMJcKVJjy1PR+U0cQ5n5 M7p/6NHCXgmt/WclEsG1oG/iwNM4azlTiyxinKXg4lvBIqFDFa/jbMvk+psI DVMClogsFFGH7/fJsUVtWmZxtpEMpjbZUvnccjCtMrMTTO9FGG9iATVSmcM2 uWkRooQ7u3Tt33OhjjGYoH8OsSDWe5lpUfNzKNMU+3W20B5BTH6TaaPI3I2S qRNU8XfgOjYS8GnIDZToLEr1XTo0kyDl+/pxUF5GMA3LZRKEjhVLKzhbJon3 TVhmmN7FG2Od8xyLl71UphMbkZ4IdgGNGG0451eiI8VfaKkhWOZmn5tavLFG x5DdHW240Se+2nHFQwODC9WJ1p+xjw9ntnaVQFA0HHWFlLXbbYzr2LzG6Lbb GN9QX4Vutl7qhL6CfF6dkW+kRKCDhrf2SAxTd9ViOZo9LTtrriz9dPboSnm1 4XEiojMB0Nzudntlrjk6z6TzMITs73NZQmRRx+Z8U8+toJCW+W8zuYyqzeHJ +5RxrfOUMp0rqvN1vt3SN3+I7qDFzdDrpqOFLY/h/PbpYTxdLt7S+oKiCd3P prdFVHq/dIKgFPMJX6oIUmr72MUIHzpAypMO0V8vJ7MpEftWgb/UHRBCJY0M ZVIyptyEO+KZjxePs+liTFxTmYkrLDof/jqbjJpqEM3pWaDWsJrlVdc9S5ki Fev99+zoeFPENyDtqa/WkqM7fbq/79WyLghEosUZrc+JBnEn8AXvPOyUWsVR 07hyyzq50t7zn9r9Cys6csgpp4RWzytPuXK8Xbnvn5x3ZnWXkwgKkNygfIvW 010s55PpbZnEXd2rD5dOUFev6vMDCh3Nk//aTsv9Bist3SUby+wjKrKtVVm2 PlZc/1O/oJbzxPRRG2GSR3Y8IYlyLPdpPFrdabVSixxHI9X5zcg+O3Wg/57l 6Vqoldw0HWqkOzuRGHZUX+WQlq+4myiwXcq12+4badpC/P3QEFk9MmRNzZBT Gzw78ehq6+zsCzGz7naFXVp9SkpblFRqm6euDk+CfHVFvcZiEx9Yts5bfIvF MrCuSac8EsUBrk/X3bIkXNTMwDrEMSXJe120JXDu0UsoM+yoYBsJsLKLi2Ex aOuWtFgko80RC5H6zNsTpi3FZ0mcRQAINlniFE4UG3PFyKvgojl1MNUQo7bp DXatlVpfwMR2wN7tuTJH9k1iFtwoEQ2fRbZFl383uOiWciyYHTc1oWzHCXXJ fLurdHJhxgCh3ur6uNeK/qJva8kiKXSLf+A9eDOKFdUYIzAIB2sCuiSGxkAp SxxEmBvqYcEbgGIAlNP969PNzXj+Ss6c48dBo3w8DHDlE8Wa3LCy2NLAqfke XMASFBJHSHayzNvV3eQGXYV8F4qdTCLovMkzF1JKHg5GWKoEhw4w7nDVazn2 Acfl2Z6Hv9kYdKF6H26qnyrIDud7soVaoUpdxZV4BWxlpVFk6GxtpKqyH02R 8AIVawJglkp1HHzHDRFSvOkFJBkasj7B2Bero0LqrkCig++m0bEZtugQBAe0 n40WlHcR8Nqx+noSPY+rLNp3qlhgGrvcCoHy4A7Fj0XZOCmaqhxgjrB/BuW5 4zzYXI6OpQfbstnZQ1eG76cehbO4X5BeJI1dDxdj9tMnRiFGEeDehxuo4XGm KSjkYOZcg2+Br8gYV9QMYTwynUhzZWm6QiI9SokfIREc7M8/nonohpwQbcK3 tQ30bxpEvrfHEaRTL1Csa/4zumBw8s/bxZ+p/zPUj8SGIz3f5gJLhItnTgdk zysb93/a1Tfr4AjJNTqw/9ZWX0S83ZmC3X2rM6HaS9kpLjduz3f8DE2t2KXP dvNfbSq3ubBJUnNXlftFJgWRSITBGEGyY2bbbLMNoXRZLUkKYuQxEzzc1aY8 vIU5WLQSN1qaIn7+FLheYA/SVEAV0YVqKZHb9d1wjnRPpCqHY6q3bcMRJP6/ QkM7CjEN1qJoTvaaAH43RS/st7ULeyv1ndRfTcsOCnlVB3V9pFCo9s7i24lb Lsgvdgv7LNC9H09vl3cs7TNm/UCrFo0tvz6ObX/os8Fg0PRGWoBDcgXCZ1sT ZkuSSLh1SwjOier+1AtedjGiSgss1ha5ULsg6bRrKf1Z7lgkg3LPILCJdmvi PvYK1o8ttV5QpT9UdPZzm8uRLApJQxqp3CEvx/6DLdw9jxWAOQ1J7V1u13kY SmXRGCL7UuAUawS9eABTaEAKAjUAeUoisJSZXjnnAJEB8JgCbvjhpdEPbLgW y+FyNRkhu+kTG40X1/PJIykfjIbLoXUSyD64PyD70PInKD+RwYuVFXr3iIrx d9272LBHSUkXUPeoUT0MvxDhAz/Uic6pFjVZiz1NtYvSFl7aa2QoPdhrIG5r do3DJtNlwCYZPZHEW4LxDYrPk0XAPsc6kkjN883R+EsAkHdAwGNzbGxfw7Ps GhDcxCY39injnOJuCIodV7FOeWN3/AUGjg97uhi26XY//nV8H7B78SySpnKf r6G44LgCAFUCATQIhiAYKqCiC/uj4QOs49Txm9KH84fZ09wJyFVzf/E4Ho8C Co2Imrs3sxk2b6Rs2fs8Hj7aLPDKexFnVI+zzwFC/iJazr6dD6/HVRbdKt7i POSPpbMZ1E4yH05vIWfOM+sB18Vr+8vJ8h77y9gktf0LjdE9cTpI6D7bhvga sCrJfKfzr6S+15XIq3o7PZ8BFQOP6F5A1xq3lMRrxQEwLAqsjRDcbjJB9x5O WPmCKe7R1ZniPltTbKffbP2H9fbEuAZoLPi8bf4ht7Jtg1kH1C+2CrfHyI0f 4sPyGljzfJk8UXsMPvdEJb70hF/6XZ74v3vIpMfp19CGhRD+N4zyhf8CdHCb 2sKE8jn7clJw1W0d6Tw72utjsOVqTeixdWZus/Lm9oKrZYlWLp538lp6+eX2 7AocbtxU/PDj4E8fB39k33JdYiTYW7/tOy/1acK+qx/27g3OOH2efU27M9f/ Lv38eW9R0D74OIxqbwMlRkW6pXvT1NbdHOx/VDnPgPu28Bx9Pafcivtx7CU2 u4vAlMh0+aRlaT3kqX5is081lpIyyYPPPpV9Ag20/SGDfk88+RWjz/wTUuQe fMBavoVR7zh9EAOounbiqLo8AndS0S6oZmR0goStK06R8M398DYojPQYKiig lJsYf3saz7+uvo4X0xkwrntRqe8s4P37MUUk8Na5GzMHgMu2KIjy9zV7XcFd 11PxwmHUsaQhBNirC76bjMaT6ePTMohk9t4wEe4ka/VH8bJYTxj7a0P9ybJ3 5r3OvwFUeo0i9B4AAA== --13109504-1169529124-837519460=:122-- From owner-crossfire Wed Jul 17 23:00:44 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 17 Jul 1996 23:00:44 +0200 Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se [193.180.251.38]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 17 Jul 1996 23:00:41 +0200 Received: from ebcs08.ebc.ericsson.se (ebcs08.ebc.ericsson.se [130.100.114.67]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with ESMTP id XAA12960 for ; Wed, 17 Jul 1996 23:00:40 +0200 (MET DST) Received: from ebcw405.ebc.ericsson.se (ebcw405.ebc.ericsson.se [130.100.167.197]) by ebcs08.ebc.ericsson.se (8.7.5/8.7.3) with SMTP id WAA08708 for ; Wed, 17 Jul 1996 22:59:49 +0200 (MET DST) Received: by ebcw405.ebc.ericsson.se (SMI-8.6/client-1.5) id XAA12717; Wed, 17 Jul 1996 23:00:05 +0200 Date: Wed, 17 Jul 1996 23:00:05 +0200 Message-Id: <199607172100.XAA12717@ebcw405.ebc.ericsson.se> From: Raphael.Quinet@eed.ericsson.se (Raphael Quinet) Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: minor bug fix in gods.c Sender: owner-crossfire Precedence: bulk Status: RO A small patch for server/gods.c: when the god that you were worshipping was nice enough to fix your drained stats, he forgot to remove the archetype of depletion. Silly him! -Raphael ---------- cut here ---------- cut here ---------- cut here ---------- *** server/gods.c.orig Wed Jul 3 14:58:30 1996 --- server/gods.c Fri Jul 12 20:08:46 1996 *************** *** 194,199 **** --- 194,201 ---- if (get_attr_value(&depl->stats, i)) { new_draw_info(NDI_UNIQUE,0,op, restore_msg[i]); } + remove_ob(depl); + free_object(depl); fix_player(op); return; } ---------- cut here ---------- cut here ---------- cut here ---------- From owner-crossfire Wed Jul 17 22:43:28 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 17 Jul 1996 22:43:28 +0200 Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se [193.180.251.38]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 17 Jul 1996 22:43:25 +0200 Received: from ebcs08.ebc.ericsson.se (ebcs08.ebc.ericsson.se [130.100.114.67]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with ESMTP id WAA12032 for ; Wed, 17 Jul 1996 22:43:24 +0200 (MET DST) Received: from ebcw405.ebc.ericsson.se (ebcw405.ebc.ericsson.se [130.100.167.197]) by ebcs08.ebc.ericsson.se (8.7.5/8.7.3) with SMTP id WAA08463 for ; Wed, 17 Jul 1996 22:42:33 +0200 (MET DST) Received: by ebcw405.ebc.ericsson.se (SMI-8.6/client-1.5) id WAA12697; Wed, 17 Jul 1996 22:42:48 +0200 Date: Wed, 17 Jul 1996 22:42:48 +0200 Message-Id: <199607172042.WAA12697@ebcw405.ebc.ericsson.se> From: Raphael.Quinet@eed.ericsson.se (Raphael Quinet) Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: bug fixes for crossfire 0.92.4 Sender: owner-crossfire Precedence: bulk Status: RO Here is a patch for server/spell_util.c and server/skills.c. I hope that nobody will complain because of the size of the message in their mailbox (it's only 6K). I found that several parts of the code are using get_map_op() without checking if the coordinates are within the map or not. Since get_map_op() is a macro which adds pointers, nasty things can happen with out-of-bounds accesses to the map data. I crashed the game several times when searching for traps or using the oratory skill near one corner of the map or when a bomb explodes on a map that has no walls on the edges. This also happened with monsters reading scrolls. These two patches add the necessary calls to the macro out_of_map() in various parts of the code, before the calls to get_map_ob(). I hope that I didn't forget any of them. Note to the programmers adding new spells or skills: be very careful when you call get_map_ob()! If you check first with one function such as wall(), blocks_view() or blocked(), then you are safe because they all call out_of_map(). But if you don't, then make sure that you check out_of_map() before calling get_map_ob(). Otherwise, Bad Things happen... ---------- cut here ---------- cut here ---------- cut here ---------- *** server/spell_util.c.orig Fri Jul 5 11:12:11 1996 --- server/spell_util.c Fri Jul 5 11:25:05 1996 *************** *** 1360,1365 **** --- 1360,1369 ---- if(blocked(op->map,op->x,op->y)) { object *tmp; remove_ob(op); + if(out_of_map(op->map,op->x,op->y)) { + free_object(op); + return; + } if(explode_object(op)) return; for(tmp=get_map_ob(op->map,op->x,op->y);tmp!=NULL;tmp=tmp->above) *************** *** 1402,1407 **** --- 1406,1415 ---- } if(blocked(op->map,op->x,op->y)) { object *tmp; + if(out_of_map(op->map,op->x,op->y)) { + free_object(op); + return; + } if(explode_object(op)) return; for(tmp=get_map_ob(op->map,op->x,op->y);tmp!=NULL;tmp=tmp->above) *************** *** 1458,1468 **** if(!tmp || !QUERY_FLAG(tmp,FLAG_MONSTER)) tmp=op; } else ! for(tmp=get_map_ob(op->map,op->x+freearr_x[dir],op->y+freearr_y[dir]); ! tmp!=NULL; ! tmp=tmp->above) ! if(tmp->type==PLAYER) ! break; if(tmp==NULL) /* didn't find a player there, look in current square for a player */ for(tmp=get_map_ob(op->map,op->x,op->y);tmp!=NULL;tmp=tmp->above) if(tmp->type==PLAYER) --- 1466,1481 ---- if(!tmp || !QUERY_FLAG(tmp,FLAG_MONSTER)) tmp=op; } else ! { ! if (out_of_map(op->map,op->x+freearr_x[dir],op->y+freearr_y[dir])) ! tmp = NULL; ! else ! for(tmp=get_map_ob(op->map,op->x+freearr_x[dir],op->y+freearr_y[dir]); ! tmp!=NULL; ! tmp=tmp->above) ! if(tmp->type==PLAYER) ! break; ! } if(tmp==NULL) /* didn't find a player there, look in current square for a player */ for(tmp=get_map_ob(op->map,op->x,op->y);tmp!=NULL;tmp=tmp->above) if(tmp->type==PLAYER) *** server/skills.c.orig Fri Jul 5 10:16:00 1996 --- server/skills.c Fri Jul 5 11:27:48 1996 *************** *** 179,184 **** --- 179,190 ---- sprintf(buf, "There is no lock there."); + if (out_of_map(pl->map,x,y)) + { + new_draw_info(NDI_UNIQUE, 0,pl,buf); + return 0; + } + for(tmp=get_map_ob(pl->map,x,y); tmp; tmp=tmp->above) { if(!tmp) continue; switch(tmp->type) { *************** *** 345,350 **** --- 351,360 ---- remove_ob(pl); SET_FLAG(pl,FLAG_FLYING); for(i=0;i<=spaces;i++) { + if(out_of_map(pl->map,pl->x+dx,pl->y+dy)) { + (void) stop_jump(pl,i,spaces); + return calc_skill_exp(pl,NULL); + } for(tmp=get_map_ob(pl->map,pl->x+dx,pl->y+dy); tmp;tmp=tmp->above) { if(wall(tmp->map,tmp->x,tmp->y)) { /* Jump into wall*/ *************** *** 373,383 **** return calc_skill_exp(pl,NULL); } } ! if(out_of_map(pl->map,pl->x+dx,pl->y+dy)) { ! (void) stop_jump(pl,i,spaces); ! return calc_skill_exp(pl,NULL); ! } else ! pl->x+=dx,pl->y+=dy; } (void) stop_jump(pl,i,spaces); return calc_skill_exp(pl,NULL); --- 383,390 ---- return calc_skill_exp(pl,NULL); } } ! pl->x+=dx; ! pl->y+=dy; } (void) stop_jump(pl,i,spaces); return calc_skill_exp(pl,NULL); *************** *** 554,559 **** --- 561,567 ---- object *tmp; if(pl->type!=PLAYER) return 0; /* only players use this skill */ + if(out_of_map(pl->map,x,y)) return 0; for(tmp=get_map_ob(pl->map,x,y);tmp;tmp=tmp->above) { if(!tmp) return 0; *************** *** 633,642 **** if(pl->type!=PLAYER) return 0; /* only players use this skill */ new_draw_info_format(NDI_UNIQUE,0,pl, "You sing"); ! for(i=dir;i<(dir+MIN(SK_level(pl),SIZEOFFREE));i++) for(tmp=get_map_ob(pl->map,pl->x+freearr_x[i],pl->y+freearr_y[i]); tmp;tmp=tmp->above) { - if(!tmp) return 0; if(!QUERY_FLAG(tmp,FLAG_MONSTER)) continue; /* can't affect players */ if(tmp->type==PLAYER || tmp->stats.Int) continue; --- 641,651 ---- if(pl->type!=PLAYER) return 0; /* only players use this skill */ new_draw_info_format(NDI_UNIQUE,0,pl, "You sing"); ! for(i=dir;i<(dir+MIN(SK_level(pl),SIZEOFFREE));i++) { ! if (out_of_map(pl->map,pl->x+freearr_x[i],pl->y+freearr_y[i])) ! continue; for(tmp=get_map_ob(pl->map,pl->x+freearr_x[i],pl->y+freearr_y[i]); tmp;tmp=tmp->above) { if(!QUERY_FLAG(tmp,FLAG_MONSTER)) continue; /* can't affect players */ if(tmp->type==PLAYER || tmp->stats.Int) continue; *************** *** 667,672 **** --- 676,682 ---- "Too bad the %s is'nt listening!\n",query_name(tmp)); } } + } return exp; } *************** *** 1024,1050 **** int i,x,y,success=0; for(i=0;i<9;i++) { ! x = op->x + freearr_x[i]; ! y = op->y + freearr_y[i]; ! if(out_of_map(op->map,x,y)) { ! new_draw_info(NDI_UNIQUE,0,op,"There are no traps there!"); ! return 0; ! } ! /* Check everything in the square for trapness */ ! for(tmp = get_map_ob(op->map,x,y);tmp!=NULL;tmp=tmp->above) { ! /* And now we'd better do an inventory traversal of each ! * of these objects' inventory */ ! for(tmp2=tmp->inv;tmp2!=NULL;tmp2=tmp2->below) if(tmp2->type==RUNE&&tmp2->stats.Cha<=1) { trap_show(tmp2,tmp); if(trap_disarm(op,tmp2,1)) success += calc_skill_exp(op,tmp2); } ! if(tmp->type==RUNE&&tmp->stats.Cha<=1) { trap_show(tmp,tmp); if (trap_disarm(op,tmp,1)) success += calc_skill_exp(op,tmp); --- 1034,1058 ---- int i,x,y,success=0; for(i=0;i<9;i++) { ! x = op->x + freearr_x[i]; ! y = op->y + freearr_y[i]; ! if(out_of_map(op->map,x,y)) ! continue; ! /* Check everything in the square for trapness */ ! for(tmp = get_map_ob(op->map,x,y);tmp!=NULL;tmp=tmp->above) { ! /* And now we'd better do an inventory traversal of each ! * of these objects' inventory */ ! for(tmp2=tmp->inv;tmp2!=NULL;tmp2=tmp2->below) if(tmp2->type==RUNE&&tmp2->stats.Cha<=1) { trap_show(tmp2,tmp); if(trap_disarm(op,tmp2,1)) success += calc_skill_exp(op,tmp2); } ! if(tmp->type==RUNE&&tmp->stats.Cha<=1) { trap_show(tmp,tmp); if (trap_disarm(op,tmp,1)) success += calc_skill_exp(op,tmp); ---------- cut here ---------- cut here ---------- cut here ---------- I am sending this patch to the list because it significantly improves the stability of the game, and thus it is probably useful for most of you. This is especially true if you have a high-level character for which the spells and skills with large area effects have a greater chance of reaching out of the map. -Raphael From owner-crossfire Wed Jul 17 22:18:25 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 17 Jul 1996 22:18:25 +0200 Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se [193.180.251.38]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 17 Jul 1996 22:18:22 +0200 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.132.130]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with ESMTP id WAA10658 for ; Wed, 17 Jul 1996 22:18:19 +0200 (MET DST) Received: (from eedraq@localhost) by chapelle.eed.ericsson.se (8.7.1/8.7.1) id WAA12316 for crossfire@ifi.uio.no; Wed, 17 Jul 1996 22:18:16 +0200 (MET DST) Date: Wed, 17 Jul 1996 22:18:15 +0200 (MET DST) Message-Id: <199607172018.WAA12316@chapelle.eed.ericsson.se> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: Bug found in crossfire 0.92.4 From: Raphael.Quinet@eed.ericsson.se Sender: owner-crossfire Precedence: bulk Status: RO I have already fixed a few bugs in Crossfire 0.92.4 (patches coming very soon), but one of them got me puzzled for a while. I got the error "Trying to remove removed object" several times, and I couldn't find why. Now I understand, but I don't know what is the best way to fix it. That's why I'm reporting the bug to the list, hoping that someone will make sensible suggestions. Here is the description of the bug: if you cast a spell that leaves a deadly object on the map (such as "pool of chaos", "firewall", "wall of thorns", etc.) and a multi-square monster gets killed when moving over it, the game crashes with the error "Trying to remove removed object". This happens because the monster is moved by removing it from its old position, then re-inserting it in the new position. While doing that, the routine insert_ob_in_map() calls check_walk_on() to see if the monster is stepping over a special object. If the monster gets killed by this object, the routine hit_player() tries to remove it, but it crashes because the monster (or at least parts of it) has already been removed and is not yet completely re-inserted in the map. Here is a backtrace of what happens when a dragon steps over a wall of thorns: > gdb crossfire core (gdb) bt #0 0xef621c1c in _kill () #1 0xef5ed834 in abort () #2 0x719ec in remove_ob (op=0x289ce8) at object.c:854 #3 0x25098 in hit_player (op=0x289ce8, dam=514, hitter=0x22c510, type=1) at attack.c:792 #4 0x20574 in apply (op=0x28a168, tmp=0x293958) at apply.c:1257 #5 0x73784 in check_walk_on (op=0x28a168) at object.c:1567 #6 0x72a48 in insert_ob_in_map (op=0x28a168, m=0x242260) at object.c:1231 #7 0x725d8 in insert_ob_in_map (op=0x28a048, m=0x242260) at object.c:1143 #8 0x725d8 in insert_ob_in_map (op=0x289f28, m=0x242260) at object.c:1143 #9 0x725d8 in insert_ob_in_map (op=0x289e08, m=0x242260) at object.c:1143 #10 0x725d8 in insert_ob_in_map (op=0x289ce8, m=0x242260) at object.c:1143 #11 0x3b99c in move_object (op=0x289ce8, dir=6) at monster.c:1061 #12 0x399f8 in move_monster (op=0x289ce8) at monster.c:289 #13 0x58b1c in process_object (op=0x289ce8) at time.c:653 #14 0x388dc in process_events (map=0x0) at main.c:692 #15 0x38e74 in main (argc=4, argv=0xeffffaa4, env=0xeffffab8) at main.c:876 In frame #11, move_object() calls insert_ob_in_map() after having removed it. In frame #5, insert_ob_in_map() calls check_walk_on(), which in turn calls hit_player(). Since the dragon's health is below 0, hit_player() tries to remove it and crashes because the dragon has not been re-inserted in the map yet. Now my question is: how can we fix that? A very ugly solution would be to have yet another global variable which is used as a flag. This flag would be set when entering check_walk_on() and reset on exit. If the flag is set when some object dies from hit_player(), then remove_ob() would not be called. But there must be a better way to do that... I'm waiting for your suggestions... -Raphael From owner-crossfire Wed Jul 17 16:59:52 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 17 Jul 1996 16:59:52 +0200 Received: from mne.ifi.uio.no (kjetilho@mne.ifi.uio.no [129.240.70.5]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 17 Jul 1996 16:59:49 +0200 Received: (from kjetilho@localhost) by mne.ifi.uio.no ; Wed, 17 Jul 1996 16:59:46 +0200 Message-Id: <199607171459.19447.mne.ifi.uio.no@ifi.uio.no> Date: Wed, 17 Jul 1996 14:47:49 +0100 From: Daniel Haas Subject: CF: Bugs in Crossfire 0.92.4 Mime-Version: 1.0 To: crossfire@ifi.uio.no Sender: owner-crossfire Precedence: bulk Status: RO [Note, Daniel is not on the list. - Kjetil T.] Hi, I hope this mail gets to the correct place. I installed and compiled crossfire 0.92.4 successfully on a DEC Alpha 3000/600. But I get some serious crashes while playing in two cases: * One seems to be a problem with special keys. They will not get removed from my inventory after using them and get a negative weight sometimes this freezes everything and sets my speed to zero. Removing the keys manually from the player-file fixes everything. * The second is worse: I have a lots of problems with magic - One problem that crossfire crashes sometimes when I try to enter the magic shop - seems to be dependent from the items in the shop - Crossfire crashes regularly when I meet spellcasting monsters, so playing on a high level is not very funny (I cannot kill beholdereyes skulls, wyverns, dragons etc without crashing...) Any help will be appreciated... Daniel *************************************************************** Daniel Haas Physikalisches Institut Universitaet Basel email: haasd@ubaclu.unibas.ch (no NeXT- or MIME-mail please) smail: D. Haas, Kreuzstrasse 150, D-79540 Loerrach, Germany *************************************************************** From owner-crossfire Fri Jul 19 16:12:16 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Fri, 19 Jul 1996 16:12:16 +0200 Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se [193.180.251.38]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 19 Jul 1996 16:12:12 +0200 Received: from ebcs08.ebc.ericsson.se (ebcs08.ebc.ericsson.se [130.100.114.67]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with ESMTP id QAA01863 for ; Fri, 19 Jul 1996 16:12:10 +0200 (MET DST) Received: from ebcw405.ebc.ericsson.se (ebcw405.ebc.ericsson.se [130.100.167.197]) by ebcs08.ebc.ericsson.se (8.7.5/8.7.3) with SMTP id QAA27070 for ; Fri, 19 Jul 1996 16:11:17 +0200 (MET DST) Received: by ebcw405.ebc.ericsson.se (SMI-8.6/client-1.5) id QAA16040; Fri, 19 Jul 1996 16:11:31 +0200 Date: Fri, 19 Jul 1996 16:11:31 +0200 Message-Id: <199607191411.QAA16040@ebcw405.ebc.ericsson.se> From: Raphael.Quinet@eed.ericsson.se (Raphael Quinet) Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: one more patch for out-of-map objects (spell_effect.c) Sender: owner-crossfire Precedence: bulk Status: RO Guess what? Yet another bug fix! This is a complement to what I sent on Wednesday for all spells and skills trying to access objects out of the map. This patch fixes the spells "light", "drain magic", "charm monsters" and "charm undead". All of them could crash the game if they were used near the edges of the map, especially by high-level players or monsters. Now these problems should be solved. This should make the game much more stable and get rid of the frequent crashes caused by monsters reading scrolls or using wands. Maybe it will soon be time for 0.92.5? My version of Crossfire is now rather stable (I applied all the patches from Brian Thomas as well as the ones I sent to this list, of course). The only major bug that I can still see is the one that I described on Wednesday about dragons or other monsters being killed by a wall of thorns, a pool of chaos or other objects on which they walk. -Raphael ---------- cut here ---------- cut here ---------- cut here ---------- *** server/spell_effect.c~ Fri Jul 19 12:14:42 1996 --- server/spell_effect.c Fri Jul 19 15:57:44 1996 *************** *** 732,743 **** x=op->x+freearr_x[dir],y=op->y+freearr_y[dir]; ! for(target=get_map_ob(op->map,x,y);target;target=target->above) ! if(QUERY_FLAG(target,FLAG_MONSTER)) { /* coky doky. got a target monster. Lets make a blinding attack */ ! if(target->head) target = target->head; ! (void) hit_player(target,dam,op,(AT_BLIND|AT_MAGIC)); ! return 1; /* one success only! */ } /* no live target, perhaps a wall is in the way? */ --- 732,744 ---- x=op->x+freearr_x[dir],y=op->y+freearr_y[dir]; ! if (!out_of_map(op->map,x,y)) ! for(target=get_map_ob(op->map,x,y);target;target=target->above) ! if(QUERY_FLAG(target,FLAG_MONSTER)) { /* coky doky. got a target monster. Lets make a blinding attack */ ! if(target->head) target = target->head; ! (void) hit_player(target,dam,op,(AT_BLIND|AT_MAGIC)); ! return 1; /* one success only! */ } /* no live target, perhaps a wall is in the way? */ *************** *** 2055,2067 **** /* drain_magic: peterm */ /* drains all the magic out of the victim. */ int drain_magic(object *op,int dir) { ! object *tmp; ! for(tmp=get_map_ob(op->map,op->x+freearr_x[dir],op->y+freearr_y[dir]); ! tmp!=NULL; ! tmp=tmp->above) if(QUERY_FLAG(tmp, FLAG_ALIVE)) ! break; /* If we did not find a player in the specified direction, transfer to anyone on top of us. */ --- 2056,2069 ---- /* drain_magic: peterm */ /* drains all the magic out of the victim. */ int drain_magic(object *op,int dir) { ! object *tmp = NULL; ! if (!out_of_map(op->map,op->x+freearr_x[dir],op->y+freearr_y[dir])) ! for(tmp=get_map_ob(op->map,op->x+freearr_x[dir],op->y+freearr_y[dir]); ! tmp!=NULL; ! tmp=tmp->above) if(QUERY_FLAG(tmp, FLAG_ALIVE)) ! break; /* If we did not find a player in the specified direction, transfer to anyone on top of us. */ *************** *** 2153,2158 **** --- 2155,2162 ---- object *tmp,*effect; for(i=1;imap,op->x+freearr_x[i],op->y+freearr_y[i])) + continue; for(tmp=get_map_ob(op->map,op->x+freearr_x[i],op->y+freearr_y[i]); tmp&&(!QUERY_FLAG(tmp,FLAG_MONSTER));tmp=tmp->above); if(!tmp) continue; *************** *** 2183,2188 **** --- 2187,2194 ---- object *tmp,*effect; for(i=1;imap,op->x+freearr_x[i],op->y+freearr_y[i])) + continue; for(tmp=get_map_ob(op->map,op->x+freearr_x[i],op->y+freearr_y[i]); tmp&&(!QUERY_FLAG(tmp,FLAG_MONSTER));tmp=tmp->above); if(!tmp) continue; ---------- cut here ---------- cut here ---------- cut here ---------- From owner-crossfire Fri Jul 19 15:37:58 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Fri, 19 Jul 1996 15:37:58 +0200 Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se [193.180.251.38]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 19 Jul 1996 15:37:56 +0200 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.132.130]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with ESMTP id PAA28342; Fri, 19 Jul 1996 15:37:04 +0200 (MET DST) Received: (from eedraq@localhost) by chapelle.eed.ericsson.se (8.7.1/8.7.1) id PAA08533; Fri, 19 Jul 1996 15:37:03 +0200 (MET DST) Date: Fri, 19 Jul 1996 15:37:02 +0200 (MET DST) Message-Id: <199607191337.PAA08533@chapelle.eed.ericsson.se> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: Re: CF: Bugs in Crossfire 0.92.4 Cc: haasd@ubaclu.unibas.ch From: Raphael.Quinet@eed.ericsson.se Sender: owner-crossfire Precedence: bulk Status: RO On Thu, 18 Jul 1996, Brian Thomas wrote: > Daniel Haas writes: > > - Crossfire crashes regularly when I meet spellcasting monsters, > > so playing on a high level is not very funny (I cannot kill beholdereyes > > skulls, wyverns, dragons etc without crashing...) > > > > Hmm. Another new problem. No idea why this might occur. > I think that this is related to the patch that I posted to this list on Wednesday for all spells and skills that were trying to access areas outside the map (i.e. were not checking for map boundaries). High-level monsters, which are more likely to cast spells, also have larger area effects due to their level, and thus were more likely to crash the game. Applying the patch that I sent on Wednesday fixes a lot of these problems. But since there are other bugs in 0.92.4 (see the bug fix that I just posted for create_missile), I didn't CC my patch to Daniel Haas, because it will be better for him to wait until 0.92.5 or to go back to an earlier version in the meantime. -Raphael From owner-crossfire Fri Jul 19 15:23:06 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Fri, 19 Jul 1996 15:23:06 +0200 Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se [193.180.251.38]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 19 Jul 1996 15:23:02 +0200 Received: from ebcs08.ebc.ericsson.se (ebcs08.ebc.ericsson.se [130.100.114.67]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with ESMTP id PAA26895 for ; Fri, 19 Jul 1996 15:23:01 +0200 (MET DST) Received: from ebcw405.ebc.ericsson.se (ebcw405.ebc.ericsson.se [130.100.167.197]) by ebcs08.ebc.ericsson.se (8.7.5/8.7.3) with SMTP id PAA26635 for ; Fri, 19 Jul 1996 15:22:09 +0200 (MET DST) Received: by ebcw405.ebc.ericsson.se (SMI-8.6/client-1.5) id PAA15962; Fri, 19 Jul 1996 15:22:24 +0200 Date: Fri, 19 Jul 1996 15:22:24 +0200 Message-Id: <199607191322.PAA15962@ebcw405.ebc.ericsson.se> From: Raphael.Quinet@eed.ericsson.se (Raphael Quinet) Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: bug fix for create_missile Sender: owner-crossfire Precedence: bulk Status: RO Here is a bug fix for spell_effect.c. It fixes the "create missile" spell, which was crashing the game when read from a scroll. Tracking down this bug was a nightmare for me and I spent more than five hours trying to understand what was wrong. I could have written a one-line fix and a short message explaining it, but since I spent so much time trying to find the bug, I will go for the long version. :-) I noticed several times that the game was crashing shortly (but not immediately) after I read a scroll of create missile, but I didn't understand why. Crossfire was crashing in different ways: "free object on active list", "object has no speed", or straight core dump in the middle of some function. I put lots of debugging statements in the code, but I found nothing unusual. Then I ran Crossfire through Purify and I finally discovered what was happening: one of the pointers in the active list was pointing to an area of the stack! Of course, some "interesting" things happened in process_events(), when that object was used or modified... with annoying consequences... I eventually found where that problem came from: when a player or monster casts a spell (a "known spell"), the function cast_spell() uses the caster object directly. But if you cast a spell by using an object (scroll, wand, etc.), cast_spell() uses a temporary copy of the player or monster, in order to be able to modify the caster's level and other stuff according to the level of the object. This means that all functions that are called within cast_spell() get either a pointer to the caster object, or a pointer to the temporary copy allocated on the stack. Bad Things happen if one of these functions modifies the object (without knowing if it is the real one or a temporary copy of it) or puts a pointer to that object in some other object. If the spell is used from a scroll or a wand, you will be using a pointer to an area that will not be valid after cast_spell() returns. That's what happened with cast_create_missile(), which was calling pick_up() if the arrows were created under the player (this happens if the spell is invoked from a scroll or if there is a wall in front of the player). And pick_up() was using a reference to the temporary copy of the player, which had disastrous consequences when the active list was processed later. NOTE: If you are a programmer and you ever add or modify a spell, be extremely careful with the value of "op" inside cast_spell() and all functions called from it! Fixing bugs that corrupt the stack is a nightmare... So here is my patch to cast_create_missile() in spell_effect.c. The only important difference is at the end of the function, when calling pick_up(). But I also modified some other parts of the function so that it is safer to use it in some other cases; I also added some comments. -Raphael P.S.: Since nobody complained about the fact that I'm sending the patches to the list, I keep on doing it. That's for the bug fixes only. When I finish my patches for new features, I will send these to Mark Wedel directly. ---------- cut here ---------- cut here ---------- cut here ---------- *** server/spell_effect.c.orig Sun Apr 21 07:07:39 1996 --- server/spell_effect.c Fri Jul 19 12:14:42 1996 *************** *** 1416,1441 **** * Sets the plus based on the casters level. It is also settable with the * invoke command. If the caster attempts to create missiles with too * great a plus, the default is used. ! * The # of arrows create also goes up with level, so if a 30th level mage * wants LOTS of arrows, and doesn't care what the plus is he could * create nonnmagic arrows, or even -1, etc... * ! * Written by Ben Fennema (huma@netcom.com) */ int cast_create_missile(object *op, int dir, char *stringarg) { ! int missile_plus=0, missile_nrof; ! char *missile_name = NULL; ! object *tmp, *missile=NULL, *weap=NULL; for (tmp=op->inv; tmp != NULL; tmp=tmp->below) if (tmp->type == BOW && QUERY_FLAG(tmp, FLAG_APPLIED)) ! weap= tmp; ! ! if (weap==NULL) missile_name = "arrow"; ! else if (!strcmp(weap->race,"arrows")) missile_name="arrow"; ! else missile_name = "bolt"; if (stringarg) missile_plus = atoi(stringarg); --- 1416,1442 ---- * Sets the plus based on the casters level. It is also settable with the * invoke command. If the caster attempts to create missiles with too * great a plus, the default is used. ! * The # of arrows created also goes up with level, so if a 30th level mage * wants LOTS of arrows, and doesn't care what the plus is he could * create nonnmagic arrows, or even -1, etc... * ! * Written by Ben Fennema (huma@netcom.com) - bugs fixed by Raphael Quinet */ int cast_create_missile(object *op, int dir, char *stringarg) { ! int missile_plus=0; ! char *missile_name; ! object *tmp, *missile; + missile_name = "arrow"; for (tmp=op->inv; tmp != NULL; tmp=tmp->below) if (tmp->type == BOW && QUERY_FLAG(tmp, FLAG_APPLIED)) ! { ! if (strstr(tmp->race, "bolt")) /* crossbow bolts */ ! missile_name = "bolt"; ! break; ! } if (stringarg) missile_plus = atoi(stringarg); *************** *** 1447,1466 **** missile_plus = 4; else if (missile_plus < -4) missile_plus = -4; ! missile_nrof = SP_PARAMETERS[SP_CREATE_MISSILE].bdur * ! ((1 + SP_level_strength_adjust(op, SP_CREATE_MISSILE)) - ! (3 * missile_plus)); ! if (find_archetype(missile_name)==NULL) { ! LOG(llevDebug, "Cast create_missile: could not find archtype %s\n", missile_name); ! return 0; ! } missile = get_archetype(missile_name); ! missile->nrof = missile_nrof; missile->magic = missile_plus; ! missile->value=0; SET_FLAG(missile, FLAG_IDENTIFIED); if (!cast_create_obj(op,missile,dir) && op->type==PLAYER) ! pick_up(op, missile); return 1; } --- 1448,1477 ---- missile_plus = 4; else if (missile_plus < -4) missile_plus = -4; ! if (find_archetype(missile_name)==NULL) ! { ! LOG(llevDebug, "Cast create_missile: could not find archetype %s\n", ! missile_name); ! return 0; ! } missile = get_archetype(missile_name); ! missile->nrof = SP_PARAMETERS[SP_CREATE_MISSILE].bdur ! * ((1 + SP_level_strength_adjust(op, SP_CREATE_MISSILE)) ! - (3 * missile_plus)); ! if (missile->nrof < 1) ! missile->nrof = 1; missile->magic = missile_plus; ! missile->value = 0; /* it would be too easy to get money by creating ! arrows +4 and selling them, even with value = 1 */ SET_FLAG(missile, FLAG_IDENTIFIED); if (!cast_create_obj(op,missile,dir) && op->type==PLAYER) ! { ! tmp = get_owner(op); ! if (tmp == NULL) ! pick_up(op, missile); /* op points to the real player object */ ! else ! pick_up(tmp, missile); /* op points to a copy of the player object */ ! } return 1; } ---------- cut here ---------- cut here ---------- cut here ---------- From owner-crossfire Thu Jul 18 16:02:37 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Thu, 18 Jul 1996 16:02:37 +0200 Received: from xplorer.gsfc.nasa.gov (xplorer.gsfc.nasa.gov [128.183.126.216]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 18 Jul 1996 16:02:34 +0200 Received: (from thomas@localhost) by xplorer.gsfc.nasa.gov (LHEA9504/950407.s1) id KAA07792; Thu, 18 Jul 1996 10:01:00 -0400 Date: Thu, 18 Jul 1996 10:01:00 -0400 From: Brian Thomas Message-Id: <199607181401.KAA07792@xplorer.gsfc.nasa.gov> Mime-Version: 1.0 To: crossfire@ifi.uio.no, Raphael.Quinet@eed.ericsson.se Subject: Re: CF: Bug found in crossfire 0.92.4 Sender: owner-crossfire Precedence: bulk Status: RO > From: Raphael.Quinet writes: > > Here is the description of the bug: if you cast a spell that leaves a > deadly object on the map (such as "pool of chaos", "firewall", "wall > of thorns", etc.) and a multi-square monster gets killed when moving > over it, the game crashes with the error "Trying to remove removed > object". This happens because the monster is moved by removing it > from its old position, then re-inserting it in the new position. > While doing that, the routine insert_ob_in_map() calls check_walk_on() > to see if the monster is stepping over a special object. If the > monster gets killed by this object, the routine hit_player() tries to > remove it, but it crashes because the monster (or at least parts of > it) has already been removed and is not yet completely re-inserted in > the map. > Perhaps have a check in hit_player for multi-sqaure monsters? It goes through the linked object tree checking for removed status. If its already removed, it just skips ahead to the next part of the monster. I ll try to implement this. If it works, Ill send in a patch. shooting from the hip, -b.t. From owner-crossfire Thu Jul 18 15:56:33 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Thu, 18 Jul 1996 15:56:33 +0200 Received: from xplorer.gsfc.nasa.gov (xplorer.gsfc.nasa.gov [128.183.126.216]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 18 Jul 1996 15:56:29 +0200 Received: (from thomas@localhost) by xplorer.gsfc.nasa.gov (LHEA9504/950407.s1) id JAA07780; Thu, 18 Jul 1996 09:54:55 -0400 Date: Thu, 18 Jul 1996 09:54:55 -0400 From: Brian Thomas Message-Id: <199607181354.JAA07780@xplorer.gsfc.nasa.gov> Mime-Version: 1.0 To: crossfire@ifi.uio.no, HAASD@ubaclu.unibas.ch Subject: Re: CF: Bugs in Crossfire 0.92.4 Sender: owner-crossfire Precedence: bulk Status: RO > From: Daniel Haas writes: > > Hi, > I hope this mail gets to the correct place. I installed and compiled > crossfire 0.92.4 successfully on a DEC Alpha 3000/600. > > But I get some serious crashes while playing in two cases: > > * One seems to be a problem with special keys. They will not get > removed from my inventory after using them and get a negative weight > sometimes this freezes everything and sets my speed to zero. Removing > the keys manually from the player-file fixes everything. > I have never heard of this one before--sounds archetecture dependant.. > * The second is worse: I have a lots of problems with magic > - One problem that crossfire crashes sometimes when I try to enter > the magic shop - seems to be dependent from the items in the shop This is a fatal bug in the reading code; I sent out a patch for this (more below). > - Crossfire crashes regularly when I meet spellcasting monsters, > so playing on a high level is not very funny (I cannot kill beholdereyes > skulls, wyverns, dragons etc without crashing...) > Hmm. Another new problem. No idea why this might occur. > Any help will be appreciated... > Version 0.92.4 was *very* buggy. I suggest that you duck back to version 0.92.2 (last stable one I am aware of) until version 0.92.5 comes out. Then we might be able to attack your new problems. -b.t. > Daniel > > *************************************************************** > Daniel Haas > Physikalisches Institut > Universitaet Basel > email: haasd@ubaclu.unibas.ch (no NeXT- or MIME-mail please) > smail: D. Haas, Kreuzstrasse 150, D-79540 Loerrach, Germany > *************************************************************** > From owner-crossfire Thu Aug 1 03:51:40 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Thu, 1 Aug 1996 03:51:40 +0200 Received: from mne.ifi.uio.no (1232@mne.ifi.uio.no [129.240.70.5]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 1 Aug 1996 03:51:36 +0200 Received: (from kjetilho@localhost) by mne.ifi.uio.no ; Thu, 1 Aug 1996 03:51:34 +0200 Message-Id: <199608010151.2163.mne.ifi.uio.no@ifi.uio.no> From: "Sebastien Loisel" Date: Wed, 31 Jul 1996 17:25:23 -0700 Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: Bug on my compilation of the thing Sender: owner-crossfire Precedence: bulk Status: RO When I attempt to move in any direction, weird stuff happens. I'm new to this and I just built crossfire. It almost works. I isolated the code that appears to me to be causing the problem (note: I'm using the supposedly latest and greatest version, 0.92.5). The code snippet you see below is from move.c in the server directory. The only change I made to it was to add a call to new_draw_info_format to see what was happening. Each time I move, I see a "2" printed in the output window, indicating that this piece of code was executed. It is my opinion that the program thinks that the whole map is impassable for some obscure reason. Has anyone experienced this before, is there a fix, does anyone have magical insights into this? Should this be reported to someone else? -------------Cut here----------------------------------------------------------- * This code section is for cases when an object CAN NOT move into * that space. */ if(QUERY_FLAG(op,FLAG_WIZPASS)?out_of_map(op->map,op->x+freearr_x[dir], op->y+freearr_y[dir]): blocked_two(op,op->x+freearr_x[dir],op->y+freearr_y[dir])) { /* Re insert object if we removed it above */ if(op->more!=NULL && op->head==NULL) insert_ob_in_map(op,op->map); if (op->type==PLAYER) op->contr->freeze_look=0; new_draw_info_format(NDI_UNIQUE, 0, op, "2"); return 0; } -------------Cut here----------------------------------------------------------- -- , Sebastien Loisel SGI Graphics Engineering/NextGen Graphics (ISD) zed@sgi.com zed@cs.mcgill.ca http://www.cs.mcgill.ca/~zed From owner-crossfire Thu Aug 1 03:49:05 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Thu, 1 Aug 1996 03:49:05 +0200 Received: from mne.ifi.uio.no (1232@mne.ifi.uio.no [129.240.70.5]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 1 Aug 1996 03:49:01 +0200 Received: (from kjetilho@localhost) by mne.ifi.uio.no ; Thu, 1 Aug 1996 03:49:00 +0200 Message-Id: <199608010149.2157.mne.ifi.uio.no@ifi.uio.no> From: "Sebastien Loisel" Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: Installation problems Date: Wed, 31 Jul 1996 11:30:08 -0700 Sender: owner-crossfire Precedence: bulk Status: RO Hello people. I'm new to this so bear with me. On the other hand, I'm a graphics engineer at SGI so I can figure out the stupider stuff by myself. I'm currently installing crossfire on my machine (I had to set up a bridge out of the firewall first, but that works now.) Now, I can't exactly say that the installation is exactly straightforward. I _know_ there are better ways of doing this. What I'm worried about is, if I have a hard time with it, how many people are going to be able to play it at all? Anyway, flames aside, eutl refuses to compile on my machine. Furthermore, after perusing through all the documentation I could find, it's still not clear to me what eutl is used for. For now, I'm compiling with eutl turned off and I'll see what happens. The eutl makefile assumes the sh shell (I think), and that caused me mischief (my SHELL variable was set to tcsh). Couldn't someone fix that? I'd be willing to make one very stupid very small program that would generate the crosssite.def file for you, instead of having to edit it manually and probably make mistakes, if someone can explain to me the process with more detail than what the doc says. If some of you are interested in seeing just how eutl fails, here goes: -----------------Cut here------------------------------------------------------ cyberus 44% make all rm .*-make touch .normal-make for i in include errlib tcplib xmalloc debuglib dynarray xfile chain-hash arglist; do \ (cd $i;make CC="gcc" CFLAGS="-g -Wall -I../include" arlib);\ done rm chain-hash.h debuglib.h dynarray.h errlib.h tcplib.h timelib.h xfile.h xmalloc.h arglist.h *\~ Cannot access *~: No such file or directory *** Error code 2 (bu21) (ignored) for i in chain-hash.h debuglib.h dynarray.h errlib.h tcplib.h timelib.h xfile.h xmalloc.h arglist.h; do \ ln -s ../*/$i $i; \ done gcc -g -Wall -I../include -c tcplib.c tcplib.c: In function `BecomeServer': tcplib.c:226: warning: implicit declaration of function `close' tcplib.c: In function `GetConnection': tcplib.c:263: warning: implicit declaration of function `bcopy' tcplib.c: In function `__DoSendMsg': tcplib.c:344: warning: implicit declaration of function `write' tcplib.c: In function `eread': tcplib.c:461: warning: implicit declaration of function `read' tcplib.c:463: `EReadError' undeclared (first use this function) tcplib.c:463: (Each undeclared identifier is reported only once tcplib.c:463: for each function it appears in.) *** Error code 1 (bu21) *** Error code 1 (bu21) cyberus 45% ls COPYRIGHT README dynarray xfile ChangeLog arglist errlib xmalloc DefectList chain-hash include Makefile copyright.berkeley tcplib Notes debuglib timelib cyberus 46% cat README The copyright is in the COPYRIGHT file. This software is in beta test -- it is still mostly undocumented. After compiling the software (make all) you should run make check to do some simple tests of the software. The dllist stuff and the ICE stuff are unfinished, and so can be revised substantially before distribution. The debuglib stuff requires the new berkeley hash stuff, this can be retrieved from any of the freebsd sites. Berkeley's copyright can be found as copyright.berkeley. In short, I have used something produced by the University of California, Berkeley, and its contributors, don't hold them responsible if their part fails. cyberus 47% make check for i in include errlib tcplib xmalloc debuglib dynarray xfile chain-hash arglist; do\ echo "Checking in $i";\ (cd $i;make CC="gcc" CFLAGS="-g -Wall -I../include" check);\ done Checking in include don't know how to make check (bu42). *** Error code 1 (bu21) -- , Sebastien Loisel SGI Graphics Engineering/NextGen Graphics (ISD) zed@sgi.com zed@cs.mcgill.ca http://www.cs.mcgill.ca/~zed From owner-crossfire Wed Jul 31 11:34:51 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Wed, 31 Jul 1996 11:34:51 +0200 Received: from gossip.pyramid.com (gossip.pyramid.com [129.214.1.101]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Wed, 31 Jul 1996 11:34:42 +0200 Received: from stealth-news.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA15115; Wed, 31 Jul 96 02:34:10 -0700 Received: by stealth.eng.pyramid.com (8.6.12/Pyramid_Internal_Configuration) id CAA17869; Wed, 31 Jul 1996 02:33:59 -0700 From: "Mark Wedel" Message-Id: <9607310233.ZM17867@stealth.eng.pyramid.com> Date: Wed, 31 Jul 1996 02:33:58 -0700 In-Reply-To: Corey Sweeney "CF: experience bug in .92.5 (and .4)" (Jul 29, 11:54am) References: <199607301036.1327.mne.ifi.uio.no@ifi.uio.no> X-Mailer: Z-Mail (3.2.0 06sep94) Mime-Version: 1.0 To: Corey Sweeney Subject: Re: CF: experience bug in .92.5 (and .4) Cc: crossfire@ifi.uio.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-crossfire Precedence: bulk Status: RO On Jul 29, 11:54am, Corey Sweeney wrote: > Subject: CF: experience bug in .92.5 (and .4) > > there appears to be another oratory bug that causes a killed follower to > turn into several royal gaurds.... some of the time. I'll report more > on this after the system is more stable with oratory. This bug probably happens if your follower is someone you get in town. Many of the normal people have royal guards as their treasure (theory being that you kill them, and now you ahve some guards you need to deal with.) How they get killed doesn't make a differnce. Might not be a bad idea to change the charm monster skill (and summone monster spells) to remove any living objects from the monsters inventory, so this doesn't happen. -- --Mark From owner-crossfire Tue Jul 30 17:42:43 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Tue, 30 Jul 1996 17:42:43 +0200 Received: from rulway.leidenuniv.nl (rulway.LeidenUniv.nl [132.229.8.6]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 30 Jul 1996 17:42:40 +0200 Received: from chemde4.LeidenUniv.nl by rulway.leidenuniv.nl with SMTP id AA23008 (5.67b/IDA-1.5 for <@RULWAY.LEIDENUNIV.NL:crossfire@ifi.uio.no>); Tue, 30 Jul 1996 17:42:34 +0200 Received: by chemde4.leidenuniv.nl (920330.SGI/920502.SGI) for @RULWAY.LEIDENUNIV.NL:corey@interaccess.com id AA12555; Tue, 30 Jul 96 17:44:01 +0200 Date: Tue, 30 Jul 96 17:44:01 +0200 From: frits@chemde4.leidenuniv.nl (Frits Daalmans) Message-Id: <9607301544.AA12555@chemde4.leidenuniv.nl> Mime-Version: 1.0 To: Corey Sweeney Subject: Re: CF: experience bug in .92.5 (and .4) Cc: crossfire@ifi.uio.no Sender: owner-crossfire Precedence: bulk Status: RO Hmm. I haven't noticed that in 0.92.4 OR 0.92.5 But.. I am not using the client/server code; I run single-user (SERVER commented out, even) at home. So maybe, that's where the problem is. Two other things: I did notice a slightly annoying buglet that I could not seem to get any experience at all for the "sense curse" skill (while I could with "sense magic"; i play a mage) so I changed the code so that it will give at least 1 exp for successfully detecting a cursed item. (Hey, 1 exp is not too much, is it? :-)) One annoying bug that was still in 0.92.5 even though the code had changed was in lookup_skill_by_name(); I'll send my patch if you like; It was, basically, impossible to use "sense curse" skill because it was later in the list than "sense magic", and had 2 words in it. BTW: thanks for the great game, all, and thanks Brian for the alchemy patch :-) (now all I have to do is find a cauldron) Bye, Frits Frits Daalmans OIO Conformational Analysis Gorlaeus Laboratoria Leiden, The Netherlands E-mail: frits@chemde4.leidenuniv.nl Tel: [+31] (0)71-5274505 From owner-crossfire Tue Jul 30 14:48:39 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Tue, 30 Jul 1996 14:48:39 +0200 Received: from cbgw1.att.com (cbgw1.att.com [192.20.239.133]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 30 Jul 1996 14:48:36 +0200 From: jklar@lucent.com Cc: crossfire@ifi.uio.no Received: from nesuns2.oms.lucent.com. by cbig1.att.att.com (SMI-8.6/EMS-1.2 sol2) id IAA11784; Tue, 30 Jul 1996 08:43:36 -0400 Received: from kinderlinux (jwk@neppp01.oms.lucent.com [135.114.250.241]) by nesuns2.oms.lucent.com. (8.7.5/OMS960320) with SMTP id IAA13182; Tue, 30 Jul 1996 08:17:40 -0400 (EDT) Date: Tue, 30 Jul 1996 08:50:20 -0400 (EDT) Original-From: John W Klar Reply-To: John W Klar Subject: Re: CF: experience bug in .92.5 (and .4) Mime-Version: 1.0 To: Corey Sweeney Original-cc: crossfire@ifi.uio.no In-Reply-To: <199607301036.1327.mne.ifi.uio.no@ifi.uio.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-crossfire Precedence: bulk Status: RO > we've uncovered what would appear to be a fairly severe bug in crossfire > .92.5 running on a linux 1.3.100 system (recent debian distribution). > > our charactors appear to no longer collect any experience points for the > catagories of wizard spells, or prayers. I can take a guy back and > demonstrate for the exact same motions that a guy will get significant > points under .92.2. > > I believe that it does not say "you killed chinese dragon with fireball" > on the screen when we see this bug. that is probably somehow related. > > i believe that we may have gotten a point or two, but if we have, it's > been so infrequent that we haven't noticed. > > we've tested it against everything from orcs to dragons. I've noticed something very similar myself, and I think the experience bug Brian Thomas has been chasing for months. I run a single user 0.92.4 server at home (life behind a corporate firewall, sigh :). Usually, shutting down the game and restarting helps. The clue I get that no experience is forthcoming is that spell ranges are 1 sqaure beyond the caster. OTOH, I've just finished my morning coffee and it hasn't quite made it to the bloodstream so names and details could be skewed. John Klar PS - Re: client/server: In the documents I mailed the list, I missed a few pieces: TYPE Long has some odd encoding, and I completely left out the Server to Client "player" command. I'll revise the affected files REAL SOON NOW :) From owner-crossfire Tue Jul 30 14:05:31 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Tue, 30 Jul 1996 14:05:31 +0200 Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se [193.180.251.38]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 30 Jul 1996 14:05:25 +0200 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.132.130]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with ESMTP id OAA10895; Tue, 30 Jul 1996 14:05:23 +0200 (MET DST) Received: (from eedraq@localhost) by chapelle.eed.ericsson.se (8.7.1/8.7.1) id OAA16291; Tue, 30 Jul 1996 14:05:21 +0200 (MET DST) Date: Tue, 30 Jul 1996 14:05:21 +0200 (MET DST) Message-Id: <199607301205.OAA16291@chapelle.eed.ericsson.se> Mime-Version: 1.0 To: corey@interaccess.com Subject: Re: CF: experience bug in .92.5 (and .4) Cc: crossfire@ifi.uio.no From: Raphael.Quinet@eed.ericsson.se Sender: owner-crossfire Precedence: bulk Status: RO On Mon, 29 Jul 1996, Corey Sweeney wrote: > our charactors appear to no longer collect any experience points for the > catagories of wizard spells, or prayers. I can take a guy back and > demonstrate for the exact same motions that a guy will get significant > points under .92.2. > > I believe that it does not say "you killed chinese dragon with fireball" > on the screen when we see this bug. that is probably somehow related. Hmmm... I've noticed something similar, although it doesn't affect all spells. Note that my server is currently a mix between 0.92.4 and 0.92.5 because I'm in the process of moving code to the new version in order to be able to submit patches to Mark, so maybe some of the comments that follow do not apply to the "standard" 0.92.5. There seems to be a problem with the fireball spell and it looks like the reference to the player is lost once the fireball explodes. I haven't had the time to look into that and I could be completely wrong (or it could be a side effect of my mixed code), but I think that the op->owner field is not always set correctly for the fireball. This could be a problem with all spells which throw objects, so it could also affect poison cloud and comet spells. I will look into that after I finish updating my patches. Also, you don't get any experience points for spells that are cast by objects such as scrolls, rods or wands. Maybe that should be changed so that you get some experience, but not as much as you would have got with your own spells ("known spells"). Hmmm... Maybe something like this: new_exp = old_exp * (object_level + 1) / (player_level + 1) / 5 > while i'm at it... there appears to be a oratory bug in .92.4 that > causes the system to crash when you have a large group of followers, and you > try to go to a differnt city. This has gotten worse in .92.5 in the fact > that it will crash with only one follower. I haven't seen that one yet. I managed to convince a bunch of castle guards and other monsters to follow me, and the game didn't crash. Do you also have the same problem with "summon pet monster"? > [...] does anyone have any ideas what we could do > to fix it? or is there any specific information we could send to the > list to help with a solution? [...] A few things that would help when you want to report a bug (besides what is already explained in the README file): - What error message (if any) is printed on the server's console when the game crashes? - Tell what you have changed in config/crossite.def and include/config.h (except for the pathnames which are site-specific). Or send the output of "crossfire -o" (but keep only the interesting lines). - Check if you can reproduce the bug. Try to explain how to do it, so that others can try it on their system. You should also try to reproduce the bug with different characters. Some spells can be affected by the objects that are readied or your current skills, so be sure to describe that if necessary. - Re-compile crossfire with debug mode enabled and see if you get any interesting error reports on the server's console. - If you have defined MANY_CORES and you have gdb or another debugger, run "gdb crossfire core" when the server crashes and type "bt" to see the call stack. The output of that command can be very useful for locating bugs. Well, it can take some time to write a good bug report, but writing a good bug report is the best thing you can do if you want others to be able to fix it easily. -Raphael From owner-crossfire Tue Jul 30 12:36:35 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Tue, 30 Jul 1996 12:36:35 +0200 Received: from mne.ifi.uio.no (1232@mne.ifi.uio.no [129.240.70.5]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 30 Jul 1996 12:36:33 +0200 Received: (from kjetilho@localhost) by mne.ifi.uio.no ; Tue, 30 Jul 1996 12:36:31 +0200 Message-Id: <199607301036.1327.mne.ifi.uio.no@ifi.uio.no> Date: Mon, 29 Jul 1996 11:54:36 -0500 (CDT) From: Corey Sweeney Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: experience bug in .92.5 (and .4) Sender: owner-crossfire Precedence: bulk Status: RO we've uncovered what would appear to be a fairly severe bug in crossfire .92.5 running on a linux 1.3.100 system (recent debian distribution). our charactors appear to no longer collect any experience points for the catagories of wizard spells, or prayers. I can take a guy back and demonstrate for the exact same motions that a guy will get significant points under .92.2. I believe that it does not say "you killed chinese dragon with fireball" on the screen when we see this bug. that is probably somehow related. i believe that we may have gotten a point or two, but if we have, it's been so infrequent that we haven't noticed. we've tested it against everything from orcs to dragons. ---------------------- while i'm at it... there appears to be a oratory bug in .92.4 that causes the system to crash when you have a large group of followers, and you try to go to a differnt city. This has gotten worse in .92.5 in the fact that it will crash with only one follower. there appears to be another oratory bug that causes a killed follower to turn into several royal gaurds.... some of the time. I'll report more on this after the system is more stable with oratory. the system also seems to crash after leaving a city some of the time... it's quite strange... i'll send more info to the list as i get it. --------------- the second group of bugs are livable, because the game can be restarted, and continued, it's just the experience bug that's really plaguing us, since it cripples our guys. does anyone have any ideas what we could do to fix it? or is there any specific information we could send to the list to help with a solution? i can't imagine that nobody has noticed this unless it's platform specific in some way... info on my site: in my config file i enabled xpm, and put the files in /usr/local/games please send responced to my e-mail address, since i just subscribed to the list a couple of muinites ago, and don't want to miss it... Thanks, Corey Sweeney From owner-crossfire Mon Jul 29 10:03:44 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Mon, 29 Jul 1996 10:03:44 +0200 Received: from mne.ifi.uio.no (1232@mne.ifi.uio.no [129.240.70.5]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 29 Jul 1996 10:03:41 +0200 Received: (from kjetilho@localhost) by mne.ifi.uio.no ; Mon, 29 Jul 1996 10:03:39 +0200 Message-Id: <199607290803.29760.mne.ifi.uio.no@ifi.uio.no> Date: Sat, 27 Jul 1996 18:00:03 -0400 (EDT) From: Chuck Robey Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: debugging Sender: owner-crossfire Precedence: bulk Status: RO I am trying to port this to FreeBSD, but the initial screen always fails to confirm the password. Any particular areas I should be looking at? I have it compiling fine, and have eliminated any explicit error messages (there were some about setsocket params). Thanks. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-crossfire Mon Jul 22 13:45:02 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Mon, 22 Jul 1996 13:45:02 +0200 Received: from xplorer.gsfc.nasa.gov (xplorer.gsfc.nasa.gov [128.183.126.216]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 22 Jul 1996 13:44:57 +0200 Received: (from thomas@localhost) by xplorer.gsfc.nasa.gov (LHEA9504/950407.s1) id HAA10972 for crossfire@ifi.uio.no; Mon, 22 Jul 1996 07:43:18 -0400 Date: Mon, 22 Jul 1996 07:43:18 -0400 From: Brian Thomas Message-Id: <199607221143.HAA10972@xplorer.gsfc.nasa.gov> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: Re: WWW players handbook... Sender: owner-crossfire Precedence: bulk Status: RO Argh, the WWW address I gave isnt quite right (although it seems to work!). Use this URL: http://www.astro.psu.edu/users/thomas/handbook -bt From owner-crossfire Mon Jul 22 13:43:44 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Mon, 22 Jul 1996 13:43:44 +0200 Received: from xplorer.gsfc.nasa.gov (xplorer.gsfc.nasa.gov [128.183.126.216]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 22 Jul 1996 13:43:38 +0200 Received: (from thomas@localhost) by xplorer.gsfc.nasa.gov (LHEA9504/950407.s1) id HAA10968 for crossfire@ifi.uio.no; Mon, 22 Jul 1996 07:41:58 -0400 Date: Mon, 22 Jul 1996 07:41:58 -0400 From: Brian Thomas Message-Id: <199607221141.HAA10968@xplorer.gsfc.nasa.gov> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: WWW players handbook... Sender: owner-crossfire Precedence: bulk Status: RO Hi, Well, I found that latex2html didnt do too bad of a job on the handbook, IF I removed all of the cutesy icons from the text (pretty easy.. just change one define) AND I moved the text definitions from local.sty to handbook.tex. My slightly modified results are viewable at the location: http://www.astro.psu.edu/users/thomas/handbook/. I DONT think that I will have these pages up for a very long time, so is there a kind individual out there who might be able to host these pages? If there is enough interest (and you cant seem to find latex2html for making your own WWW pages) I might make my html files available via ftp (since it would be a PAIN to download them via netscape :). This marks the end of my development of the handbook. Enjoy! -b.t. From owner-crossfire Sun Jul 21 18:56:01 1996 Return-Path: Received: (from mdomo@localhost) by ifi.uio.no (8.6.11/ifi2.4) id for crossfire-ut ; Sun, 21 Jul 1996 18:56:01 +0200 Received: from xplorer.gsfc.nasa.gov (xplorer.gsfc.nasa.gov [128.183.126.216]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sun, 21 Jul 1996 18:55:57 +0200 Received: (from thomas@localhost) by xplorer.gsfc.nasa.gov (LHEA9504/950407.s1) id MAA10502 for crossfire@ifi.uio.no; Sun, 21 Jul 1996 12:54:19 -0400 Date: Sun, 21 Jul 1996 12:54:19 -0400 From: Brian Thomas Message-Id: <199607211654.MAA10502@xplorer.gsfc.nasa.gov> Mime-Version: 1.0 To: crossfire@ifi.uio.no Subject: CF: Players Handbook Sender: owner-crossfire Precedence: bulk Status: RO I guess the handbook is about as close to finished as its going to get. I have put several files related to it on ftp.astro.psu.edu in pub/thomas. These are: handbook.ps.gz : Players handbook. handbook_noicon.gz : Players handbook w/o icons (less memory, ~same # of pages) playbook.tar.gz : files to build the Handbook with. unpack it in the top directory. If anyone catches some glaring errors, Id be willing to fix them. Other than that, this should be the final edition. Enjoy, -b.t.