From crossfire-request Thu Dec 7 04:36:01 1995 Return-Path: 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 ; Thu, 7 Dec 1995 04:36:00 +0100 Received: from stealth.eng.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA28520; Wed, 6 Dec 95 19:35:28 -0800 Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA27250; Thu, 7 Dec 95 03:35:26 GMT From: "Mark Wedel" Message-Id: <9512061935.ZM27248@stealth.eng.pyramid.com> Date: Wed, 6 Dec 1995 19:35:25 -0800 In-Reply-To: bull@dws013.cs.unr.edu (W.E.B) "Re: From c to c++ (fwd)" (Dec 6, 7:10pm) References: <9512070310.AA22974@dws013.cs.unr.edu> X-Mailer: Z-Mail (3.2.0 06sep94) To: bull@dws013.cs.unr.edu (W.E.B), crossfire@ifi.uio.no Subject: Re: From c to c++ (fwd) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: RO On Dec 6, 7:10pm, W.E.B wrote: > Subject: Re: From c to c++ (fwd) > > Java isn't public domain, is it? In order to run Crossfire, > > one would have to license a Java interpreter or whatever, right? > > Are Java interpreters available for all platforms? > > > > Is Java fast enough to deal with a Crossfire server? > > > > I'd hate to see Crossfire work done in one company's pet > > language rather than mainstream languages with wide support. > > > > Regards, > > > > PeterM > > Java is an interesting concept. Our department has been discussing > purchasing the development system for it. (ie. it is a possibility.) > > On the otherhand all the Java interpreters I've seen are so-so at best. > (Of course these were running through netscape, for whatever that's worth.) > But in reality a java app for crossfire would be much better than its > current state as an X-window app. It cannot escape its current clique of > users because it has an enormous difficulty without client-server. Java > would, indeed, take care of this. > > Don't shunt Java it is something to look at. > > -web >-- End of excerpt from W.E.B It would seem to me that you would almost always want the server side code in C or C++ or something like that - I don't know much about Java, but crossfire seems to be a bit huge to sit as a java app. What would perhaps be more interesting is to make a java client that somehow interacts with the server. This opens up crossfire to everyone, removes the difficulty of having to port clients to every different system type, and does achive the long sought after client/server aspect. However, I have no real idea of how feasible this would be, or efficient also. -- --Mark From crossfire-request Fri Dec 8 02:40:52 1995 Return-Path: Received: from kultarr.cit.gu.edu.au ([132.234.42.2]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 8 Dec 1995 02:40:46 +0100 Received: by kultarr.cit.gu.edu.au id AA16693 (5.67b/IDA-1.5 for crossfire@ifi.uio.no); Fri, 8 Dec 1995 11:39:49 -1000 From: Karl Hagen Geppert Message-Id: <199512082139.AA16693@kultarr.cit.gu.edu.au> Subject: Re: Spell setting To: crossfire@ifi.uio.no Date: Fri, 8 Dec 1995 11:39:49 -1000 (EST) Cc: matsuda@arch.comp.kyutech.ac.jp, K.Geppert@cit.gu.edu.au In-Reply-To: <199512080123.DAA04523@new.ton.tut.fi> from "Jari Vanhala" at Dec 8, 95 03:23:45 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 776 Status: RO Jari Vanhala quite definitely said [typed] >>I think that not only magic spell, but other commands >>( save winpos etc. ) are difficult to remember. >>And inputing commands is very bother. > Yes, if you type those command.. You should bind those command to >keys and just push a button.. There just are not enough keys for the number of spells you can learn. A characacter that is good for both sides of magic can exceed several screensful worth of spells. I have all my function keys, keypad, special keys && most of the letters bound (not to forget the shift modified keys too), and still have to type 'cast commands regularly. However when I forget what the second key word of a spell is, the standard 'cast list gives me several screensfull of possibilities. Karl From crossfire-request Fri Dec 8 07:44:11 1995 Return-Path: Received: from arch.comp.kyutech.ac.jp (matsuda@arch.comp.kyutech.ac.jp [150.69.62.21]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 8 Dec 1995 07:43:22 +0100 Received: (from matsuda@localhost) by arch.comp.kyutech.ac.jp (8.7.1/3.4W3-951117) id PAA02627; Fri, 8 Dec 1995 15:42:42 +0900 (JST) Date: Fri, 8 Dec 1995 15:42:42 +0900 (JST) Message-Id: <199512080642.PAA02627@arch.comp.kyutech.ac.jp> To: crossfire@ifi.uio.no Subject: Environment variables of client From: matsuda@arch.comp.kyutech.ac.jp (Matsuda Takashi) X-Mailer: mnews [version 1.19] 1995-07/21(Fri) Status: RO Now, I'm modifying audio codes for supporting Network Audio System. To achive this, I must get client's environment variable 'AUDIOSERVER' to find where is audio server. Is there those mechanism? thanks. -Takashi Matsuda matsuda@arch.comp.kyutech.ac.jp From crossfire-request Fri Dec 8 06:33:17 1995 Return-Path: Received: from acy1.digex.net (acy1.digex.net [198.180.35.3]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 8 Dec 1995 06:33:16 +0100 Received: (from link@localhost) by acy1.digex.net (8.6.12/8.6.12) id AAA18493 ; for ; Fri, 8 Dec 1995 00:31:55 -0500 Date: Fri, 8 Dec 1995 00:31:54 -0500 (EST) From: Matt Cortes To: Mark Wedel cc: "Mattias 'Gerhardt' Goeransson" , crossfire@ifi.uio.no Subject: Demonology Temple In-Reply-To: <9512061534.ZM25280@stealth.eng.pyramid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Here I am again with yet another question.. :> I'm in the Elemental-summoning-woshiping-place (grin) and I made it to the top level, after killing the large guardian demons. In there is some teleporters and I have to say something while standing on them. I would love to know what it is, but also, if anyone could please tell me how I also missed such information, I was sure I searched everywhere and talked alot to the cleaning ladies, but somehow I found nothing on what to say there. Thanks, Matt link@acy.digex.net From crossfire-request Fri Dec 8 05:39:35 1995 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 8 Dec 1995 05:39:31 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 7 Dec 1995 23:38:41 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 7 Dec 1995 23:37:54 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 5 Dec 1995 23:36:00 -0500 Date: Thu, 7 Dec 1995 22:36:00 -0600 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.413:08.11.95.04.37.54] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Spell set... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"27438 Thu Dec 7 23:38:25 1995"@bnr.ca> To: crossfire@ifi.uio.no Subject: Re: Spell setting Status: RO In message "Re: Spell setting", 'K.Geppert@cit.gu.edu.au' writes: >Jari Vanhala quite definitely said [typed] > >>>I think that not only magic spell, but other commands >>>( save winpos etc. ) are difficult to remember. >>>And inputing commands is very bother. >> Yes, if you type those command.. You should bind those command to >>keys and just push a button.. > >There just are not enough keys for the number of spells you can learn. A >characacter that is good for both sides of magic can exceed several screensful >worth of spells. I have all my function keys, keypad, special keys && most of >the letters bound (not to forget the shift modified keys too), and still have >to type 'cast commands regularly. However when I forget what the second key >word of a spell is, the standard 'cast list gives me several screensfull of >possibilities. > >Karl Which brought up a good point, should every character "class" gets all the available spell? After all, if you can't memorize them, you shouldn't cast them. From crossfire-request Fri Dec 8 04:10:33 1995 Return-Path: Received: from smug.student.adelaide.edu.au (rennigeb@smug.student.adelaide.edu.au [129.127.40.25]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 8 Dec 1995 04:10:27 +0100 Received: (from rennigeb@localhost) by smug.student.adelaide.edu.au (8.7.2/CJP-951204) id NAA27804 for crossfire@ifi.uio.no; Fri, 8 Dec 1995 13:40:30 +1030 (CST) From: Stephen John Harley Message-Id: <199512080310.NAA27804@smug.student.adelaide.edu.au> Subject: Hit Points To: crossfire@ifi.uio.no Date: Fri, 8 Dec 1995 13:40:30 +0930 (CST) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO After playing the latest version I was surprised that I could increase my hit points by using skills like search. The classical definition of HP's is "the ability to resist/avoid injury" (in essence). Why does spotting a trap...an action that has no risk involved increase the character's ability to avoid injury. I suggest that hit points should be treated as a skill, with experience being attributed to the skill whenever hand-to-hand combat exp is recieved. The obvious disadvantage is that mages will rarely increase their HP's beyond skill level 1. To compensate for this, exp gained via killing by magic should also increase the "life level" but at a rate of 50% of the exp recieved. Attacking via missiles should increase "life level" at a rate of 75% of the full exp gained. These reduced rates are to reflect the reduced risks involved in ranged attacks. Hence characters can not become very powerful due to abuse of no-risk skills (eg. pickpocket, search). From crossfire-request Fri Dec 8 02:26:45 1995 Return-Path: Received: from new.ton.tut.fi (new.ton.tut.fi [193.166.81.63]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 8 Dec 1995 02:26:45 +0100 Received: from new (localhost [127.0.0.1]) by new.ton.tut.fi (8.6.12/8.6.4) with ESMTP id DAA04523; Fri, 8 Dec 1995 03:23:47 +0200 Message-Id: <199512080123.DAA04523@new.ton.tut.fi> X-Mailer: exmh version 1.6.2 7/18/95 To: matsuda@arch.comp.kyutech.ac.jp (Matsuda Takashi) cc: K.Geppert@cit.gu.edu.au, crossfire@ifi.uio.no Reply-To: crossfire@ifi.uio.no Subject: Re: Spell setting In-reply-to: Your message of "Fri, 08 Dec 1995 09:37:23 +0900." <199512080037.JAA29108@arch.comp.kyutech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Dec 1995 03:23:45 +0200 From: Jari Vanhala Status: RO Matsuda Takashi writes: >K.Geppert@cit.gu.edu.au writes: >>> Wondering if anyone thinks the following is a good enough idea to refine in >>> crossfire. I can never remember the name of the spell when I need to cast >it, >>> what with create wall, build wall, and wall of thorns sort of ambiguities. >>> Could it be arranged that when you type cast keyword, crossfire list all th >e >>> spells that you know that begin with that keyword? For example cast summon >>> would return summon water elemental, summon air elemental, summon fire >>> elemental. Just patch command_cast_spell() in server/input.c like: if (params && strncmp(params, spells[op->contr->known_spells[i]].name, strlen(params))) continue; before ifdef near else for(i=0;i<(int)op->contr->nrofknownspells;i++) { #ifdef SPELLPOINT_LEVEL_DEPEND Haven't tested, but should work.. >I think that not only magic spell, but other commands >( save winpos etc. ) are difficult to remember. >And inputing commands is very bother. Yes, if you type those command.. You should bind those command to keys and just push a button.. >I think zsh-like command expansion may very useful. >For example; > >cast [tab] [clip] >Of cause, unknown magic spells are not listed. Hum. To implement this (without kludge-code) is to do tab-list. And then show/complete word in commands.c. For commands there is list already, for command arguments list could be generated by special-function for each of those commands which we want tab working for its arguments. ++Jam, needs sleep From crossfire-request Fri Dec 8 01:39:15 1995 Return-Path: Received: from arch.comp.kyutech.ac.jp (matsuda@arch.comp.kyutech.ac.jp [150.69.62.21]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 8 Dec 1995 01:38:57 +0100 Received: (from matsuda@localhost) by arch.comp.kyutech.ac.jp (8.7.1/3.4W3-951117) id JAA29108; Fri, 8 Dec 1995 09:37:23 +0900 (JST) Date: Fri, 8 Dec 1995 09:37:23 +0900 (JST) Message-Id: <199512080037.JAA29108@arch.comp.kyutech.ac.jp> To: K.Geppert@cit.gu.edu.au Cc: crossfire@ifi.uio.no Subject: Re: Spell setting In-Reply-To: Your message of Thu, 7 Dec 1995 15:14:08 -1000 (EST). <199512080114.AA00889@kultarr.cit.gu.edu.au> From: matsuda@arch.comp.kyutech.ac.jp (Matsuda Takashi) X-Mailer: mnews [version 1.19] 1995-07/21(Fri) Status: RO Hi. I'm matsuda@arch.comp.kyutech.ac.jp . In article <199512080114.AA00889@kultarr.cit.gu.edu.au> K.Geppert@cit.gu.edu.au writes: >> G'day, >> >> Wondering if anyone thinks the following is a good enough idea to refine in >> crossfire. I can never remember the name of the spell when I need to cast it, >> what with create wall, build wall, and wall of thorns sort of ambiguities. >> Could it be arranged that when you type cast keyword, crossfire list all the >> spells that you know that begin with that keyword? For example cast summon >> would return summon water elemental, summon air elemental, summon fire >> elemental. I think that not only magic spell, but other commands ( save winpos etc. ) are difficult to remember. And inputing commands is very bother. I think zsh-like command expansion may very useful. For example; >cast [tab] --> fireball *, summon * --> >cast s[tab] --> >cast summon[tab] --> water elemental, air elemental, fire elemenal >cast summon [tab] --> >summon water elemental[tab] --> >summon air elemental[return] >pe[tab] --> >peasefull[return] Of cause, unknown magic spells are not listed. --------------------------------------------------------------------------- Takashi Matsuda Kyushu Institute of Technology, Faculty of Engineering, Department of Electrical, Electronic and Computer Engineering, IWANE Lab. E-Mail address: matsuda@arch.comp.kyutech.ac.jp --------------------------------------------------------------------------- From crossfire-request Thu Dec 7 18:33:27 1995 Return-Path: Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 7 Dec 1995 18:33:24 +0100 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id JAA13906; Thu, 7 Dec 1995 09:32:52 -0800 Received: from pacific.eng.sun.com (pacific-88.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02307; Thu, 7 Dec 1995 09:32:49 -0800 Received: from polyslo.eng.sun.com by pacific.eng.sun.com (5.x/SMI-SVR4) id AA21259; Thu, 7 Dec 1995 09:33:20 -0800 Received: from localhost by polyslo.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA12027; Thu, 7 Dec 1995 09:32:38 -0800 Message-Id: <199512071732.JAA12027@polyslo.eng.sun.com> To: Petri Heinila Cc: crossfire@ifi.uio.no Subject: Re: From c to c++ (or even java) In-Reply-To: Your message of "Thu, 07 Dec 1995 16:50:57 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Dec 1995 09:32:37 -0800 From: Michael Walker Status: RO Just a couple of points/clarifications. Java applets are a special (restricted) form of a java application which can run under a WEB browser. It is also possible to write stand-alone java applications which run under the Java virtual machine. An example of this would the HotJava browser that is available. This is actually a Java application which is a Web browser that is able to run Java applets. I think it would make a lot of sense to first do the client as a Java applet and maintain the client/server as a c/C++ application. This would give a wide number of client platforms while still maintaining the speed of the c/c++ server. In later stages it *might* be worth looking into converting the server into a Java application. Probably as Java has matured a little more (been streemlined) and when the Java 'just-in-time' compiler has been released. _Mike_ => => some points: => => * crossfire requires peer-to-peer communication with client- => server architecture (peer-to-peer means there is spontaneous => data exchange for both direction (server sends maps, client => send commands) not request-reply, client-server means => instantiation roles, server up first, client then with => known server address). => => * in java architecture program (applet) is created and precompiled => to bytecode in provider site. www browser the makes a request => for that program, that is then replyed to the browser. browser => starts plugin java-interpreter that runs byte-code, resulting => ususally graphical presentation to browser. => => * for crossfire I see there is possible to make java-client, => that when it's runned makes a connection to cf-server by => java-network-objects (does this exists ?) => => * for creating server by java is a bit problematic thing => with java architecture. It might not be reasonable to run => cf-server on www-browser with java-interpreter (does => there exist stand-alone java interpreters ?). => => more later ;) => => Petri.Heinila@lut.fi => -- --- Michael Walker Michael.Walker@Eng.Sun.Com From crossfire-request Thu Dec 7 17:19:13 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 7 Dec 1995 17:19:12 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id LAA27835; Thu, 7 Dec 1995 11:18:55 -0500 Date: Thu, 7 Dec 1995 11:18:55 -0500 From: Brian Thomas Message-Id: <199512071618.LAA27835@chaupher.gsfc.nasa.gov> To: thomas@chaupher.gsfc.nasa.gov, tdoan@bnr.ca Subject: re:weather/day/night/climate Cc: crossfire@ifi.uio.no Status: RO > From: "tuan (t.) doan" writes: > > In message "weather/day/night/climate", > 'thomas@chaupher.gsfc.nasa.gov' writes: > > > Hi, > > > > I have managed to sort-out all of the previous > > mentioned difficulties within the lighting code *and* > > add a few features. I will be posting again later > > to describe this. > > Kool, when can we expect this to be part of crossfire release? Uh, that depends on Mark. I will submit the same patch to him that I will make available later tonight. Sorry, got held up by work yesterday... ;) > > > I am posting now to discuss another idea that > > came out of this project--namely the possiblity to > > have weather, climate and night/day cycles on (specified) > > I've been thinking about this for a while as well; so I'll give my > 0.25 cents (inflation :-) inputs. > > My main concern is with how to represent the environment. With the > new lighting code, day and night would be pretty easy. Just have Agreed. Although it would take about 10 lines of code, I will hold off doing this in the lighting code perse. > for weather, it's a different story. For starter, how do we represent > weather? Wind does not need graphical representation, just its affects > on others. How about rain, snow, etc... Will weather restrict movement? Hmm. I was hoping to make weather primarily archetypes that would be put onto maps. For example, "rain" and "snow" would be inserted in random spots on a map to simulate this weather. These archs would be similar to "fog" in that they might blockview, slow movement and move around the map randomly. In some cases ("thunderstorm") weather might "cast spells" (ie lightning). Not sure if this would look too comical though.. Also, I expect most of the weather archs would be temporary.. this is to say, a snowstorm might move around the map for 1-10 moves then disappear leaving behind "snow" (a new 'floor') on the ground. Cold/hot conditions could be simulated by giving the weather an attacktype (but there are problems w/ this I wont further mention here). > Weather will definitely adds several new spells :-) Oh yes. An just having day/night and seasonal cycles introduces the posibility for "ritual" magic which only works at specified times of the year (!). This is one primary motivation for seasons day/night time. You could even make spellcasters path_attuned "day" and path_denied "night" so that those players got bonuses/penalties for casting magic during certain times. > How will we model the elements of weather (snow, water, cloud, etc...) See the above... > What are the attribute of weather (humidity, temperature, pressure, etc...) I am strongly aggainst using "scientific" terms for weather in a "fanasty" setting. Weather that occurs would be set by simiple conditions ie the current season in the game and the "climate" of the map. > Time will add to the game only if there are factors that uses it. Will > players have age and will age affects playing? Some spells may be able > to make use of time (spell duration can be affected.) I already addressed spells in the above. I don't think ageing should be introduced into the game (how many game hours to have to play before your character reaches the end of their life??!!). Certainly "potions of longevity" would have to become available then. I would not advocate ageing in the game. > > As far as labeling them, I vote we move away from the normal "earth-like" > 12 months, 24 days, 4 seasons. At least make it flexible for configuration. > Definitely. Use maybe a default of earth-like seasons but allow maintainers to "customize" them. The more things you have depend on the season (like spellcasting), the more difficult it will be to have a customizable (and simple) system of climate/season/weather. b.t. > Regards. > > > From crossfire-request Thu Dec 7 15:51:22 1995 Return-Path: Received: from hilja.it.lut.fi (hevi@hilja.it.lut.fi [157.24.11.72]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 7 Dec 1995 15:51:22 +0100 Received: from localhost (hevi@localhost) by hilja.it.lut.fi (8.6.5/8.6.5/1.12.kim) id QAA03197; Thu, 7 Dec 1995 16:51:19 +0200 Date: Thu, 7 Dec 1995 16:50:57 +0200 (EET) From: Petri Heinila X-Sender: hevi@hilja.it.lut.fi To: crossfire@ifi.uio.no Subject: Re: From c to c++ (or even java) In-Reply-To: <9512061935.ZM27248@stealth.eng.pyramid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 6 Dec 1995, Mark Wedel wrote: > It would seem to me that you would almost always want the server side code in > C or C++ or something like that - I don't know much about Java, but crossfire > seems to be a bit huge to sit as a java app. > > What would perhaps be more interesting is to make a java client that somehow > interacts with the server. This opens up crossfire to everyone, removes the > difficulty of having to port clients to every different system type, and does > achive the long sought after client/server aspect. some points: * crossfire requires peer-to-peer communication with client- server architecture (peer-to-peer means there is spontaneous data exchange for both direction (server sends maps, client send commands) not request-reply, client-server means instantiation roles, server up first, client then with known server address). * in java architecture program (applet) is created and precompiled to bytecode in provider site. www browser the makes a request for that program, that is then replyed to the browser. browser starts plugin java-interpreter that runs byte-code, resulting ususally graphical presentation to browser. * for crossfire I see there is possible to make java-client, that when it's runned makes a connection to cf-server by java-network-objects (does this exists ?) * for creating server by java is a bit problematic thing with java architecture. It might not be reasonable to run cf-server on www-browser with java-interpreter (does there exist stand-alone java interpreters ?). more later ;) Petri.Heinila@lut.fi From crossfire-request Thu Dec 7 04:31:59 1995 Return-Path: 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 ; Thu, 7 Dec 1995 04:31:58 +0100 Received: from stealth.eng.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA28092; Wed, 6 Dec 95 19:31:25 -0800 Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA27237; Thu, 7 Dec 95 03:31:23 GMT From: "Mark Wedel" Message-Id: <9512061931.ZM27235@stealth.eng.pyramid.com> Date: Wed, 6 Dec 1995 19:31:22 -0800 In-Reply-To: "W.E.B" "From c to c++" (Dec 6, 10:06am) References: <199512061806.KAA27789@hunter.cs.unr.edu> X-Mailer: Z-Mail (3.2.0 06sep94) To: "W.E.B" , crossfire@ifi.uio.no Subject: Re: From c to c++ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: RO On Dec 6, 10:06am, W.E.B wrote: > Subject: From c to c++ > I'm working with a group of students here at the University of > Nevada Reno who'd like to port crossfire to c++. I realize it's under the > GNU license but would like to hear from some of the people working on it. > > If this becomes a reality it would be an upper divisional class in > porting using crossfire as an example. With any luck, the class would > first abstract the code into some general classes and then address the > issues of static versus dynamic code. There are plenty of topics which > crossfire implements and is an excellent model to be divided up. Hopefully > the system would be easier to expand and maintain if we were to do a job > well done. > > If you have some ideas/suggestions we'd be very pleased to hear them. > > (Btw, I understand the game is in a state of flux and really would like > to let you know if we decide to do a rewrite/port anytime soon. I'd > prefer to work with the others already familiar with the system rather > than against.) > > -web > My main comment on such a project would be the fact that the crossfire source is very dynamic. As such, you will either need to be taking in patches that were written relative to the last version (Ansi C) or need to make frequent releases (that actually work properly, so that people can develope from that release) I think the other thing you woul need to be careful of is letting the crossfire programmers as a group know what you are doing, and at least get some ssort of agreement from them. If you effort goes in some direction that the crossfire programmers in general don't like, there may be a strong push to just keep using the ANSI C version instead of going to your C++ version. This may not mean a lot, but it does carry the chance that your porting effort leads to something that no one wants to use. I will agree with Tyler that the code is pretty messy (inconsisent might be a better word.) But I think that problem will always exist in a situation where numerous people are providing patches/additions to the program. I will also agree with Petri in that a good first goal would be to get the game to compile in both Ansi C and C++ (I believe this is acheivable) Also, while the present code is fairly messy, at the same time, at least a fair number of know it pretty good, such that if we want to change something, we know what areas of the code it effects and what ramifications it will have (or other areas that are dependant on it.) If you do a rewrite, that will not necesssarly be the case. If you are actually looking for something to rewrite, I think a better candidate would be some other program in which work has ceased. In that case, you don't need to worry about merging with peoples changes (since no one else will be working on it), and you don't need to worry about pleasing the people who are already using it - you can pretty much do anything you want, without having to worry about how anyone feels. Crossedit is almost such a case of this - know one is actively working on it. However, at the same time, I don't necessarily know if it needs a major rewrite. My other concern with such an effort is that it gets started, but never fully finished, and ends up leaving the game is a state that was really no better than before. This message is not meant to say not to convert crossfire. But I mentioned several worries above that I would like to see addressed/how they will be dealt with. Graphical code seperation: This is really related to William's comments, but was part of the discussion: Right now, I believe all actual display (output) code is contained in xio.c. It would not be especially difficult to write substitutions for all those functions to send it over a pipe or something (ala client.) The bigger issue is that there isn't a big reason to do that (so you use some other protocol instead of X, but what does it gain you?) The main issue on client server was to have a reasonably smart client - this partially exists. Some things this reasonably smart client does is keep track of items in the players inventory locally, and sends more abstract commands on what it does to these items. It also does stuff like handle keybinding on the client level, and not the server level. One goal of such a system was to make the client lower bandwidth (I don't know how much it achieved this or not), as well as remove the X11 code from the server. However, the main issue is that in order to do this, it requires much more than just replacing output routines - input routines also need to be redone, as well as logic for updating objects on the client side. At some time, doing animations locally on the client is a goal (right now, I believe the basic logic is that it just tells the client that the face has changed, and if you have lots of animated objects, it ends up sending bunches of those messages.) Whether you can do that and keep a client that is usuable for several different things is very debatable. One other issue is that right now, the server keeps track of a lot of information on what it last sent the client, so that it knows what has changed and only sends that. I don't know if all that state information is necessarily a nice idea, but a lot of it is just from the X11 code, that uses it to know what needs to be redrawn. -- --Mark From crossfire-request Thu Dec 7 07:34:17 1995 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Thu, 7 Dec 1995 07:34:15 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 7 Dec 1995 01:33:49 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 7 Dec 1995 01:33:08 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 4 Dec 1995 22:19:00 -0500 Date: Wed, 6 Dec 1995 21:19:00 -0600 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.146:07.11.95.06.33.08] X400-Content-Type: P2-1984 (2) Content-Identifier: re:weather/da... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"22171 Thu Dec 7 01:33:22 1995"@bnr.ca> To: thomas@chaupher.gsfc.nasa.gov Cc: crossfire@ifi.uio.no Subject: re:weather/day/night/climate Status: RO In message "weather/day/night/climate", 'thomas@chaupher.gsfc.nasa.gov' writes: > Hi, > > I have managed to sort-out all of the previous > mentioned difficulties within the lighting code *and* > add a few features. I will be posting again later > to describe this. Kool, when can we expect this to be part of crossfire release? > I am posting now to discuss another idea that > came out of this project--namely the possiblity to > have weather, climate and night/day cycles on (specified) > maps. These changes would occur "globally" ie all (loaded) > maps change at the same time. I've been thinking about this for a while as well; so I'll give my 0.25 cents (inflation :-) inputs. My main concern is with how to represent the environment. With the new lighting code, day and night would be pretty easy. Just have every square take a new variable (say: environment) that can be set according to the following sets of values (lighting,weather,etc...) Lighting via environment will just be another logic check. But for weather, it's a different story. For starter, how do we represent weather? Wind does not need graphical representation, just its affects on others. How about rain, snow, etc... Will weather restrict movement? Weather will definitely adds several new spells :-) How will we model the elements of weather (snow, water, cloud, etc...) What are the attribute of weather (humidity, temperature, pressure, etc...) Realism and flexibility will depend on the answers for the above 2 questions. Time will add to the game only if there are factors that uses it. Will players have age and will age affects playing? Some spells may be able to make use of time (spell duration can be affected.) As far as labeling them, I vote we move away from the normal "earth-like" 12 months, 24 days, 4 seasons. At least make it flexible for configuration. Regards. From crossfire-request Thu Dec 7 04:12:07 1995 Return-Path: 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 ; Thu, 7 Dec 1995 04:12:06 +0100 Received: from pyramid.cs.unr.edu (pyramid.cs.unr.edu [134.197.40.253]) by maud.ifi.uio.no ; Thu, 7 Dec 1995 04:12:04 +0100 Received: from dws013.cs.unr.edu (dws013 [134.197.42.13]) by pyramid.cs.unr.edu (8.6.9/8.6.9) with SMTP id TAA27385 for ; Wed, 6 Dec 1995 19:10:48 -0800 Received: by dws013.cs.unr.edu (5.65/Ultrix3.0-C) id AA22974; Wed, 6 Dec 1995 19:10:46 -0800 From: bull@dws013.cs.unr.edu (W.E.B) Message-Id: <9512070310.AA22974@dws013.cs.unr.edu> Subject: Re: From c to c++ (fwd) To: crossfire@ifi.uio.no Date: Wed, 6 Dec 95 19:10:45 PDT X-Mailer: ELM [version 2.2 PL16] Status: RO > Java isn't public domain, is it? In order to run Crossfire, > one would have to license a Java interpreter or whatever, right? > Are Java interpreters available for all platforms? > > Is Java fast enough to deal with a Crossfire server? > > I'd hate to see Crossfire work done in one company's pet > language rather than mainstream languages with wide support. > > Regards, > > PeterM > > > > Java is an interesting concept. Our department has been discussing purchasing the development system for it. (ie. it is a possibility.) On the otherhand all the Java interpreters I've seen are so-so at best. (Of course these were running through netscape, for whatever that's worth.) But in reality a java app for crossfire would be much better than its current state as an X-window app. It cannot escape its current clique of users because it has an enormous difficulty without client-server. Java would, indeed, take care of this. Don't shunt Java it is something to look at. -web From crossfire-request Thu Dec 7 04:03:34 1995 Return-Path: Received: from pyramid.cs.unr.edu (pyramid.cs.unr.edu [134.197.40.253]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 7 Dec 1995 04:03:33 +0100 Received: from dws013.cs.unr.edu (dws013 [134.197.42.13]) by pyramid.cs.unr.edu (8.6.9/8.6.9) with SMTP id TAA27362 for ; Wed, 6 Dec 1995 19:03:26 -0800 Received: by dws013.cs.unr.edu (5.65/Ultrix3.0-C) id AA22919; Wed, 6 Dec 1995 19:03:23 -0800 From: bull@dws013.cs.unr.edu (W.E.B) Message-Id: <9512070303.AA22919@dws013.cs.unr.edu> Subject: Re: From c to c++ (fwd) To: crossfire@ifi.uio.no Date: Wed, 6 Dec 95 19:03:20 PDT X-Mailer: ELM [version 2.2 PL16] Status: RO > * first task is to get a base on c++, meaning the code can > be compiled with c++-complier. It's quite straightforward > work thanks to ansi-c. And then get development package out. The lab where this would be worked on supports cc and gcc. We've got Solaris, SunOS, and MIPS Ultrix. Our personal feelings is to write neat, portable code. I don't believe that the transition is going to be so terribly difficult (luckily). > > * the set of c++ features should be decided, most complilers > provides templates, but exception handling is still uncomplete > in many compilers eg. g++-2.7.2 and what libraries to use; > STL is nice and available with libg++, but how other development > environments. > Most likely we would be working with g++. It is unfortunate that everything isn't completely settled about c++ but then again that is one of the issues the class would address. > * instead of full rewriting (unless you feel you have unlimited amount > of energy :) I suggest increamental modification, for example > considering the object/monster structure and using still same > user interface. > > Petri.Heinila@lut.fi > No, this would not be a total rewrite. There's a lot of working code in there. The general layout for the course would involve: 1) abstract into a loose object system 2) discuss the static portions of each system 3) document the existing systems (as objects) 4) explore the ineffeciencies of the current code and how to improve it. This would be used a pivoting point for many design issues. It would allow students an experience in porting existing code and having to discuss general 'plans of attack' (with respect to project management, etc.) The amount of work which is done really depends on the amount of interest generated. The more people who enivitably sign up for the class directly corresponds to the number of areas which are worked on intently. Please feel free to give me any more insight. If this were to develop into a larger rewrite, it would be advantageous to speak up. -web From crossfire-request Thu Dec 7 00:34:37 1995 Return-Path: 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 ; Thu, 7 Dec 1995 00:34:36 +0100 Received: from stealth.eng.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA05211; Wed, 6 Dec 95 15:34:04 -0800 Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA25282; Wed, 6 Dec 95 23:34:01 GMT From: "Mark Wedel" Message-Id: <9512061534.ZM25280@stealth.eng.pyramid.com> Date: Wed, 6 Dec 1995 15:34:00 -0800 In-Reply-To: "Mattias 'Gerhardt' Goeransson" "Color.." (Dec 6, 3:39pm) References: X-Mailer: Z-Mail (3.2.0 06sep94) To: "Mattias 'Gerhardt' Goeransson" , crossfire@ifi.uio.no Subject: Re: Color.. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: RO On Dec 6, 3:39pm, Mattias 'Gerhardt' Goeransson wrote: > Subject: Color.. > Hello. > > I have never been able to play in color. > I have tried to compile on color system, > but haven't been succesful there and I tried > to play on other sites, but I got no colors. > Only a few, like green, blue and yellow. > But it's not the nice colors that I've seen > on a WWW page (in France, damn your nukes :). > > Anyone? > > Best Regards. > > ,,, > (o o) > +-----o0O--(_)--O0o------------------------------------------- > | > | Mattias Goeransson > | > | Phone: 070-734 77 67, 0457-161 50 > | Internet: > | E-Mail: mda93mg@pt.hk-r.se > | URL: http://www.pt.hk-r.se/~mda93mg.html > | > | HCI - Be sure to check out the MDA-WWW: > | http://www.pt.hk-r.se/~mda-www/ > | > +------------------------------------------------------------- > > >-- End of excerpt from Mattias 'Gerhardt' Goeransson The problem is probably that you are not doing 'set xpm' when you connect to the server, or are not running crossclient -xpm. If you don't do that, you get the basic images that are only dual color. -- --Mark From crossfire-request Thu Dec 7 00:33:48 1995 Return-Path: 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 ; Thu, 7 Dec 1995 00:33:46 +0100 Received: from stealth.eng.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA05147; Wed, 6 Dec 95 15:32:58 -0800 Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA25277; Wed, 6 Dec 95 23:32:56 GMT From: "Mark Wedel" Message-Id: <9512061532.ZM25275@stealth.eng.pyramid.com> Date: Wed, 6 Dec 1995 15:32:55 -0800 In-Reply-To: aw@math.uni-sb.de (Arne Wichmann) "Re: steal abuse" (Dec 6, 2:19pm) References: <9512061319.AA01027@vieta.math.uni-sb.de> X-Mailer: Z-Mail (3.2.0 06sep94) To: aw@math.uni-sb.de (Arne Wichmann) Subject: Re: steal abuse Cc: crossfire@ifi.uio.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: RO On Dec 6, 2:19pm, Arne Wichmann wrote: > Subject: Re: steal abuse > Now for the second half... > > Also sprach Mark Wedel: > > On Nov 30, 2:08pm, Jonathan Hankins wrote: > > > Subject: Re: steal abuse > > > On Thu, 30 Nov 1995, Brian Thomas wrote: > > Having some options like that configurable could be done - but I don't want > > that in the config.h file - I really want to move that stuff to some other > > config file that is read when the game is run - I would like to reduce the > > amount of code that is conditional compilation, and rather have conditional > > execution. > > I would like to have both ways (at least for some things) so that I > can play with the options for some time, and later recompile with only > those enabled that I want, to get the game smaller and faster. > Some things might always remain configurable. The biggest problem with configurable options right now is code maintenance. I can verify that the options I compile with work pretty well, but there are other options out there that I don't use, and might not work at all. Having them all be standard would at least insure that the program compiles correctly either way. This should also just clean up the code right now. In some sections, the #ifdef, #elses, and so on make things quite messy. In terms of space, even with all options, I can't see the size of the code growing too much (not more than a few hundred K). If you are using those options, they will likely sit in swap. But in either case, with the memory of systems now days, I can't see of it being a very big deal. Ones that affect run time memory should perhaps be more tunable (if something adds a few fields to each object, that can start adding up to a bit of memory, that will not necessarily be able to sit on swap.) > Hmmm... I would like it if the permadeath would be a bit more > debugged... We run with some local patches over here, to get around > some problems. But other things remain (maybe we introduced > them...). I think, I will resend those patches... > > cu I have never seen any problems with permadeath, and have used it quite a bit. Can you be a bit more specific on the problems you are actually having with it? -- --Mark From crossfire-request Wed Dec 6 23:12:52 1995 Return-Path: Received: from elvis.seattleu.edu (elvis.seattleu.edu [199.237.224.12]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Wed, 6 Dec 1995 23:12:50 +0100 Received: from handel.seattleu.edu.seattleu.edu by elvis.seattleu.edu (4.1/SMI-4.1) id AA19540; Wed, 6 Dec 95 14:09:28 PST Received: by handel.seattleu.edu.seattleu.edu (4.1/SMI-4.1) id AA13358; Wed, 6 Dec 95 14:09:09 PST Date: Wed, 6 Dec 1995 14:03:35 -0800 (PST) From: "Kristofer M. Bosland" Subject: Re: From c to c++ To: "W.E.B" Cc: crossfire@ifi.uio.no In-Reply-To: <199512061806.KAA27789@hunter.cs.unr.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 6 Dec 1995, W.E.B wrote: > I'm working with a group of students here at the University of > Nevada Reno who'd like to port crossfire to c++. I realize it's under the > GNU license but would like to hear from some of the people working on it. > > If this becomes a reality it would be an upper divisional class in > porting using crossfire as an example. With any luck, the class would > first abstract the code into some general classes and then address the > issues of static versus dynamic code. There are plenty of topics which > crossfire implements and is an excellent model to be divided up. Hopefully > the system would be easier to expand and maintain if we were to do a job > well done. > > If you have some ideas/suggestions we'd be very pleased to hear them. > > (Btw, I understand the game is in a state of flux and really would like > to let you know if we decide to do a rewrite/port anytime soon. I'd > prefer to work with the others already familiar with the system rather > than against.) > > -web > > ---------------- > William Bull > ---------------- > bull@cs.unr.edu > Campus Computing > Services > ---------------- Please, if you are doing a major port of CrossFire, Separate the "Game" Code from the "Display" (X) Code. This will make Client/Server much easier to create. I am working on a game myself that is a roguelike graphical game, and I would be interested in seeing a generic front end that would work with several different servers (I am trying to write mine in tcl/tk). If the Front End/Cient is generic enough, we may be completely able to separate the game mechanics from the display mechanics (a big plus, IMHO). By the way, sounds like a really fun class! -Kris Bosland krisb@seattleu.edu From crossfire-request Wed Dec 6 22:49:30 1995 Return-Path: Received: from langmuir.EECS.Berkeley.EDU (langmuir.EECS.Berkeley.EDU [128.32.240.55]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 6 Dec 1995 22:49:28 +0100 Received: from landau.EECS.Berkeley.EDU (landau.EECS.Berkeley.EDU [128.32.240.94]) by langmuir.EECS.Berkeley.EDU (8.6.11/8.5) with SMTP id NAA04785; Wed, 6 Dec 1995 13:51:11 -0800 From: Peter Mardahl Received: from localhost by landau.EECS.Berkeley.EDU; (5.65/1.1.8.2/20Jun95-1153PM) id AA00927; Wed, 6 Dec 1995 13:51:15 -0800 Message-Id: <9512062151.AA00927@landau.EECS.Berkeley.EDU> To: Michael Walker Cc: crossfire@ifi.uio.no Subject: Re: From c to c++ In-Reply-To: Your message of "Wed, 06 Dec 95 12:43:37 PST." <199512062043.MAA13596@polyslo.eng.sun.com> Date: Wed, 06 Dec 95 13:51:15 -0800 X-Mts: smtp Status: RO > > > Just a thought on my part for someone who's just a lurker on this > alias. But if y'all are considering a complete re-write have you > thought about coding it in Java. Java isn't public domain, is it? In order to run Crossfire, one would have to license a Java interpreter or whatever, right? Are Java interpreters available for all platforms? Is Java fast enough to deal with a Crossfire server? I'd hate to see Crossfire work done in one company's pet language rather than mainstream languages with wide support. Regards, PeterM From crossfire-request Wed Dec 6 22:49:51 1995 Return-Path: Received: from gmi.edu (nova.gmi.edu [192.138.137.2]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Wed, 6 Dec 1995 22:49:50 +0100 Received: from prizm.gmi.edu by gmi.edu (5.x/SMI-SVR4) id AA11866; Wed, 6 Dec 1995 16:50:04 -0500 Received: by prizm.gmi.edu (5.x/SMI-SVR4) id AA00326; Wed, 6 Dec 1995 16:50:54 -0500 Date: Wed, 6 Dec 1995 16:50:54 -0500 From: srin9340@nova.gmi.edu (Akshay Srinivasan) Message-Id: <9512062150.AA00326@prizm.gmi.edu> To: crossfire@ifi.uio.no Subject: bt code X-Sun-Charset: US-ASCII Status: RO I think the seasonal code would be a great addition to the game. Also when will the new lighting code be available on ftp.astro.psu.edu? Have fun, Akshay From crossfire-request Wed Dec 6 21:44:28 1995 Return-Path: Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 6 Dec 1995 21:44:26 +0100 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id MAA25860; Wed, 6 Dec 1995 12:43:52 -0800 Received: from pacific.eng.sun.com by Eng.Sun.COM (5.x/SMI-5.3) id AA04691; Wed, 6 Dec 1995 12:43:49 -0800 Received: from polyslo.eng.sun.com by pacific.eng.sun.com (5.x/SMI-SVR4) id AA07298; Wed, 6 Dec 1995 12:44:19 -0800 Received: from localhost by polyslo.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA13596; Wed, 6 Dec 1995 12:43:39 -0800 Message-Id: <199512062043.MAA13596@polyslo.eng.sun.com> To: hevi@lut.fi, bull@cs.unr.edu Cc: crossfire@ifi.uio.no Subject: Re: From c to c++ In-Reply-To: Your message of "Wed, 06 Dec 1995 21:56:21 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Dec 1995 12:43:37 -0800 From: Michael Walker Status: RO Just a thought on my part for someone who's just a lurker on this alias. But if y'all are considering a complete re-write have you thought about coding it in Java. Some of the advantages of Java would be: o binaries are machine independent. You will instantly be able to run the client's all the machines that have the java virtual machine on it. Which currently includes many unix's Win95/NT and soon Mac too. o Object oriented languages very simular to C++ o Might win *big* prizes... I think that if crossfire were ported to JAVA it would ba a great candidate for the Java contest that Sun is currently running. For more info on Java and the contest start take a look at http://javacontest.sun.com. I'm only bummed because I'm a Sun employee I'm not uneligible for the contest. It's a thought and it might be a lot of fun. _Mike_ => On Wed, 6 Dec 1995, W.E.B wrote: => => > I'm working with a group of students here at the University of => > Nevada Reno who'd like to port crossfire to c++. I realize it's under the => > GNU license but would like to hear from some of the people working on it. => > => > If this becomes a reality it would be an upper divisional class in => > porting using crossfire as an example. With any luck, the class would => > first abstract the code into some general classes and then address the => > issues of static versus dynamic code. There are plenty of topics which => > crossfire implements and is an excellent model to be divided up. Hopefully => > the system would be easier to expand and maintain if we were to do a job => > well done. => > => > If you have some ideas/suggestions we'd be very pleased to hear them. => => * first task is to get a base on c++, meaning the code can => be compiled with c++-complier. It's quite straightforward => work thanks to ansi-c. And then get development package out. => => * the set of c++ features should be decided, most complilers => provides templates, but exception handling is still uncomplete => in many compilers eg. g++-2.7.2 and what libraries to use; => STL is nice and available with libg++, but how other development => environments. => => * instead of full rewriting (unless you feel you have unlimited amount => of energy :) I suggest increamental modification, for example => considering the object/monster structure and using still same => user interface. => => Petri.Heinila@lut.fi => -- Mike Walker Michael.Walker@Eng.Sun.COM From crossfire-request Wed Dec 6 21:26:22 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 6 Dec 1995 21:26:21 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id PAA27139 for crossfire@ifi.uio.no; Wed, 6 Dec 1995 15:26:19 -0500 Date: Wed, 6 Dec 1995 15:26:19 -0500 From: Brian Thomas Message-Id: <199512062026.PAA27139@chaupher.gsfc.nasa.gov> To: crossfire@ifi.uio.no Subject: weather/day/night/climate Status: RO Hi, I have managed to sort-out all of the previous mentioned difficulties within the lighting code *and* add a few features. I will be posting again later to describe this. I am posting now to discuss another idea that came out of this project--namely the possiblity to have weather, climate and night/day cycles on (specified) maps. These changes would occur "globally" ie all (loaded) maps change at the same time. For the maps, we would need to specify only the "climate". The value of the climate along with the current season could be used to determine the weather on that map. CONFIGUREABLE? ------------- A file could be made to control the timing of the changes so that the server maintainer would have some control over the occurance and duration of "night" and "day" and the "seasons". For example, In the file to specify the changes, we set variables/def's like: #define NIGHT 3600 /* base seconds to make night */ #define DAY 3600 /* base seconds to make day */ #define TWILIGHT 600 /* base seconds for sunrise/sunset */ #define START_TIME 1 /* which part of the day do we start with? * "1" for day, "2" for night, etc. Allow * a negative value to mean its random */ /* ordering of the seasons. Give the name and fraction to multiply * the day and night times by and relative duration of the season */ season[] = {{"winter", 0.5, 2.0, 10}, {"spring", 1.0, 1.0, 5}, {"summer", 2.0, 0.5, 10}, {"fall", 1.0, 1.0, 5}, { NULL, 0, 0, 0} }; So in the above we see that "winter" and "summer" will last 2x as long as "fall" and "spring". Note we could make up our own names and/or add entries. /* which season to start with when we power up the server. * Allow it to be specific season, random, or tied to the * season it is in reality */ starting_season = "random"; If the starting season is "reality" the relative durations of the seasons are meaningless. Allow another array to define the seaons by month in the case you want to have starting_seaon == "reality" /* array used for defining CF season by real month. I simulate * a schedule for Pennsylvania, USA below :) */ season_by_month[] = { {"winter", JAN}, {"winter", FEB}, {"winter", MAR}, {"winter", APR}, {"spring", MAY}, {"spring", JUN}, {"summer", JUL}, {"summer", AUG}, {"fall", SEP}, {"fall", OCT}, {"winter", SEP}, {"winter", SEP} }; Lets define the climates as flags: #define MAP_FLAG_DESERT 1 #define MAP_FLAG_TUNDRA 2 #define MAP_FLAG_FOREST 3 #define MAP_FLAG_PLAINS 4 ... and so on. Now, the most complex part, which is the heart of the scheme: lay out the effects which occur in each climate by season. Probably this will have to be done in some hardcoded function. Perhaps there is a more general way to do this but it escapes me at the moment. It would be nice to say, be able to configure the effects in a given season and climate. Well, its something to chew on. b.t. From crossfire-request Wed Dec 6 20:56:42 1995 Return-Path: Received: from dior.it.lut.fi (hevi@dior.it.lut.fi [157.24.23.48]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 6 Dec 1995 20:56:41 +0100 Received: (from hevi@localhost) by dior.it.lut.fi (8.6.12/8.6.6/1.20.kim) id VAA01872; Wed, 6 Dec 1995 21:56:36 +0200 Date: Wed, 6 Dec 1995 21:56:21 +0200 (EET) From: Petri Heinila X-Sender: hevi@dior.it.lut.fi To: crossfire@ifi.uio.no Subject: Re: From c to c++ In-Reply-To: <199512061806.KAA27789@hunter.cs.unr.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 6 Dec 1995, W.E.B wrote: > I'm working with a group of students here at the University of > Nevada Reno who'd like to port crossfire to c++. I realize it's under the > GNU license but would like to hear from some of the people working on it. > > If this becomes a reality it would be an upper divisional class in > porting using crossfire as an example. With any luck, the class would > first abstract the code into some general classes and then address the > issues of static versus dynamic code. There are plenty of topics which > crossfire implements and is an excellent model to be divided up. Hopefully > the system would be easier to expand and maintain if we were to do a job > well done. > > If you have some ideas/suggestions we'd be very pleased to hear them. * first task is to get a base on c++, meaning the code can be compiled with c++-complier. It's quite straightforward work thanks to ansi-c. And then get development package out. * the set of c++ features should be decided, most complilers provides templates, but exception handling is still uncomplete in many compilers eg. g++-2.7.2 and what libraries to use; STL is nice and available with libg++, but how other development environments. * instead of full rewriting (unless you feel you have unlimited amount of energy :) I suggest increamental modification, for example considering the object/monster structure and using still same user interface. Petri.Heinila@lut.fi From crossfire-request Wed Dec 6 19:37:18 1995 Return-Path: Received: from berlin.landacorp.com (root@berlin.landacorp.com [204.119.202.10]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 6 Dec 1995 19:37:15 +0100 Received: from california.landacorp.com (california.landacorp.com [204.119.202.62]) by berlin.landacorp.com (8.6.12/8.6.9) with ESMTP id LAA10418; Wed, 6 Dec 1995 11:37:42 -0800 Received: from seattle (seattle.landacorp.com [204.119.202.36]) by california.landacorp.com (8.6.12/8.6.9) with SMTP id NAA25144; Wed, 6 Dec 1995 13:46:05 -0500 Date: Wed, 6 Dec 1995 13:46:05 -0500 Message-Id: <199512061846.NAA25144@california.landacorp.com> X-Sender: tkv@california.landacorp.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "W.E.B" , crossfire@ifi.uio.no From: tkv@landacorp.com (Tyler Van Gorder) Subject: Re: From c to c++ Status: RO At 10:06 AM 12/6/95 PDT, W.E.B wrote: > I'm working with a group of students here at the University of >Nevada Reno who'd like to port crossfire to c++. I realize it's under the >GNU license but would like to hear from some of the people working on it. > >If this becomes a reality it would be an upper divisional class in >porting using crossfire as an example. With any luck, the class would >first abstract the code into some general classes and then address the >issues of static versus dynamic code. There are plenty of topics which >crossfire implements and is an excellent model to be divided up. Hopefully >the system would be easier to expand and maintain if we were to do a job >well done. > >If you have some ideas/suggestions we'd be very pleased to hear them. > >(Btw, I understand the game is in a state of flux and really would like >to let you know if we decide to do a rewrite/port anytime soon. I'd >prefer to work with the others already familiar with the system rather >than against.) > >-web > > ---------------- > William Bull > ---------------- > bull@cs.unr.edu > Campus Computing > Services > ---------------- > > Good to hear that someone is interested in this. Crossfire is in DIRE need of a rewrite, its the main reason I stopped working on it. It would be great to get some coding standards in place and clean up naming conventions for variables. Its really hard to tell if a pointer "op" is a player or an object. Its rediculous to name variables like "p", "i", etc...give them more meaningful names. Finally, it would be cool if the object structure was cleaned up, so that food doesn't mean food if the object is a door. Tyler. tvangod@ecst.csuchico.edu -------------------------------------------------------------------- Tyler Van Gorder Senior Developer Landacorp "The opinions contained herein do not represent those of Landacorp." Nor am I responsible for the Power Rangers. From crossfire-request Wed Dec 6 19:39:02 1995 Return-Path: Received: from berlin.landacorp.com (root@berlin.landacorp.com [204.119.202.10]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 6 Dec 1995 19:38:58 +0100 Received: from california.landacorp.com (california.landacorp.com [204.119.202.62]) by berlin.landacorp.com (8.6.12/8.6.9) with ESMTP id LAA10418; Wed, 6 Dec 1995 11:37:42 -0800 Received: from seattle (seattle.landacorp.com [204.119.202.36]) by california.landacorp.com (8.6.12/8.6.9) with SMTP id NAA25144; Wed, 6 Dec 1995 13:46:05 -0500 Date: Wed, 6 Dec 1995 13:46:05 -0500 Message-Id: <199512061846.NAA25144@california.landacorp.com> X-Sender: tkv@california.landacorp.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "W.E.B" , crossfire@ifi.uio.no From: tkv@landacorp.com (Tyler Van Gorder) Subject: Re: From c to c++ Status: RO At 10:06 AM 12/6/95 PDT, W.E.B wrote: > I'm working with a group of students here at the University of >Nevada Reno who'd like to port crossfire to c++. I realize it's under the >GNU license but would like to hear from some of the people working on it. > >If this becomes a reality it would be an upper divisional class in >porting using crossfire as an example. With any luck, the class would >first abstract the code into some general classes and then address the >issues of static versus dynamic code. There are plenty of topics which >crossfire implements and is an excellent model to be divided up. Hopefully >the system would be easier to expand and maintain if we were to do a job >well done. > >If you have some ideas/suggestions we'd be very pleased to hear them. > >(Btw, I understand the game is in a state of flux and really would like >to let you know if we decide to do a rewrite/port anytime soon. I'd >prefer to work with the others already familiar with the system rather >than against.) > >-web > > ---------------- > William Bull > ---------------- > bull@cs.unr.edu > Campus Computing > Services > ---------------- > > Good to hear that someone is interested in this. Crossfire is in DIRE need of a rewrite, its the main reason I stopped working on it. It would be great to get some coding standards in place and clean up naming conventions for variables. Its really hard to tell if a pointer "op" is a player or an object. Its rediculous to name variables like "p", "i", etc...give them more meaningful names. Finally, it would be cool if the object structure was cleaned up, so that food doesn't mean food if the object is a door. Tyler. tvangod@ecst.csuchico.edu -------------------------------------------------------------------- Tyler Van Gorder Senior Developer Landacorp "The opinions contained herein do not represent those of Landacorp." Nor am I responsible for the Power Rangers. From crossfire-request Wed Dec 6 18:49:49 1995 Return-Path: Received: from acy1.digex.net (acy1.digex.net [198.180.35.3]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 6 Dec 1995 18:49:48 +0100 Received: (from link@localhost) by acy1.digex.net (8.6.12/8.6.12) id MAA28112 ; for ; Wed, 6 Dec 1995 12:49:32 -0500 Date: Wed, 6 Dec 1995 12:49:30 -0500 (EST) From: Matt Cortes To: Arne Wichmann cc: Mark Wedel , jhankins@pc11.hhs.homewood.k12.al.us, crossfire@ifi.uio.no Subject: Gamming help.. :> In-Reply-To: <9512061319.AA01027@vieta.math.uni-sb.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I hate to ask this, but I'm going nuts.. :> In the bow & arrow shop with the Elf (Scorn City), there is a back room with a long bow, boots, etc. There is also a brasskey under some stuff that I foudn with elvin text on it. Well I kinda figured that key would get me in the back room, but I can't seem to interact with that door at all. Anyone fill me in on this nagging secret? :> Thanks, -Link link@acy.digex.net From crossfire-request Wed Dec 6 19:07:00 1995 Return-Path: Received: from hunter.cs.unr.edu (hunter.cs.unr.edu [134.197.40.62]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 6 Dec 1995 19:06:57 +0100 Received: (from bull@localhost) by hunter.cs.unr.edu (8.6.9/8.6.9) id KAA27789 for crossfire@ifi.uio.no; Wed, 6 Dec 1995 10:06:55 -0800 From: "W.E.B" Message-Id: <199512061806.KAA27789@hunter.cs.unr.edu> Subject: From c to c++ To: crossfire@ifi.uio.no Date: Wed, 6 Dec 95 10:06:54 PDT X-Mailer: ELM [version 2.2 PL16] Status: RO I'm working with a group of students here at the University of Nevada Reno who'd like to port crossfire to c++. I realize it's under the GNU license but would like to hear from some of the people working on it. If this becomes a reality it would be an upper divisional class in porting using crossfire as an example. With any luck, the class would first abstract the code into some general classes and then address the issues of static versus dynamic code. There are plenty of topics which crossfire implements and is an excellent model to be divided up. Hopefully the system would be easier to expand and maintain if we were to do a job well done. If you have some ideas/suggestions we'd be very pleased to hear them. (Btw, I understand the game is in a state of flux and really would like to let you know if we decide to do a rewrite/port anytime soon. I'd prefer to work with the others already familiar with the system rather than against.) -web ---------------- William Bull ---------------- bull@cs.unr.edu Campus Computing Services ---------------- From crossfire-request Wed Dec 6 15:43:52 1995 Return-Path: Received: from jupiter.pt.hk-r.se (root@jupiter.pt.hk-r.se [194.47.132.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 6 Dec 1995 15:43:51 +0100 Received: from portia.pt.hk-r.se (portia.pt.hk-r.se [194.47.134.15]) by jupiter.pt.hk-r.se (8.6.9/8.6.9) with ESMTP id PAA19174 for ; Wed, 6 Dec 1995 15:44:09 +0100 Received: (mda93mg@localhost) by portia.pt.hk-r.se (8.6.11/8.6.11) id PAA11337; Wed, 6 Dec 1995 15:39:07 +0100 Date: Wed, 6 Dec 1995 15:39:05 +0100 (MET) From: "Mattias 'Gerhardt' Goeransson" To: crossfire@ifi.uio.no Subject: Color.. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Hello. I have never been able to play in color. I have tried to compile on color system, but haven't been succesful there and I tried to play on other sites, but I got no colors. Only a few, like green, blue and yellow. But it's not the nice colors that I've seen on a WWW page (in France, damn your nukes :). Anyone? Best Regards. ,,, (o o) +-----o0O--(_)--O0o------------------------------------------- | | Mattias Goeransson | | Phone: 070-734 77 67, 0457-161 50 | Internet: | E-Mail: mda93mg@pt.hk-r.se | URL: http://www.pt.hk-r.se/~mda93mg.html | | HCI - Be sure to check out the MDA-WWW: | http://www.pt.hk-r.se/~mda-www/ | +------------------------------------------------------------- From crossfire-request Wed Dec 6 14:26:13 1995 Return-Path: Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Wed, 6 Dec 1995 14:26:12 +0100 Received: from sbusol.rz.uni-sb.de by relay.xlink.net id <35420-0@relay.xlink.net>; Wed, 6 Dec 1995 14:23:13 +0000 Received: from vieta.math.uni-sb.de (aw@vieta.math.uni-sb.de [134.96.32.23]) by sbusol.rz.uni-sb.de (8.6.12/v2.0) with SMTP id OAA06876; Wed, 6 Dec 1995 14:23:12 +0100 Received: by vieta.math.uni-sb.de (4.1/math-SB.srv.910605) id AA01027; Wed, 6 Dec 95 14:19:59 +0100 From: aw@math.uni-sb.de (Arne Wichmann) Message-Id: <9512061319.AA01027@vieta.math.uni-sb.de> Subject: Re: steal abuse To: mwedel@pyramid.com (Mark Wedel) Date: Wed, 6 Dec 1995 14:19:57 +0100 (MET) Cc: jhankins@pc11.hhs.homewood.k12.al.us, crossfire@ifi.uio.no In-Reply-To: <9511301153.ZM28873@stealth.eng.pyramid.com> from "Mark Wedel" at Nov 30, 95 11:53:33 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1257 Status: RO Now for the second half... Also sprach Mark Wedel: > On Nov 30, 2:08pm, Jonathan Hankins wrote: > > Subject: Re: steal abuse > > On Thu, 30 Nov 1995, Brian Thomas wrote: > Having some options like that configurable could be done - but I don't want > that in the config.h file - I really want to move that stuff to some other > config file that is read when the game is run - I would like to reduce the > amount of code that is conditional compilation, and rather have conditional > execution. I would like to have both ways (at least for some things) so that I can play with the options for some time, and later recompile with only those enabled that I want, to get the game smaller and faster. > Certainly, it would be possible to make various things not as > nasty. You could just comment out most of the bad PERMADEATH > effects, or change the code. Reqires some hacking, but not that > much. Hmmm... I would like it if the permadeath would be a bit more debugged... We run with some local patches over here, to get around some problems. But other things remain (maybe we introduced them...). I think, I will resend those patches... cu AW -- Wer geteilt ist hat nichts mitzuteilen (Einstuerzende Neubauten) Arne Wichmann (aw@math.uni-sb.de) From crossfire-request Sun Dec 3 21:18:20 1995 Return-Path: Received: from usc.edu (usc.edu [128.125.253.136]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sun, 3 Dec 1995 21:18:18 +0100 Received: by usc.edu (8.6.12/SMI-3.0DEV3-USC+3.1) id MAA12260; Sun, 3 Dec 1995 12:18:16 -0800 >Received: by runner.wds.disney.com (NX5.67e/NX3.0M-rr.4) id AA07937; Sun, 3 Dec 95 12:15:22 -0800 Date: Sun, 3 Dec 95 12:15:22 -0800 From: Richard Ruth Message-Id: <9512032015.AA07937@runner.wds.disney.com> Received: from runner by usc.edu.usc.edu; Sun, 3 Dec 1995 12:18 PST Received: by runner.wds.disney.com (NX5.67e/NX3.0M-rr.4) id AA07937; Sun, 3 Dec 95 12:15:22 -0800 Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: compile errors - crossfire-0.92.0 Content-Type: text Content-Length: 1565 Status: RO I am receiving the following error when doing a make of crossfire-0.92.0. I am compiling crossfire on a NeXTStation, using NS 3.2 & CoXist 3.3 (x-Windows V11 R5): ============== rm -f crossfire cc -DNeXT -DBSD -o crossfire apply.o attack.o ban.o c_bind.o c_chat.o c_misc.o c_move.o c_new.o c_object.o c_party.o c_wiz.o commands.o daemon.o egoitem.o encounter.o ericserver.o hiscore.o init.o input.o login.o main.o monster.o move.o newitem.o obwin.o pets.o player.o resurrection.o rune.o shop.o socket.o sounds.o spell_effect.o spell_util.o swamp.o swap.o thief.o time.o xio.o -pipe -arch 'm68k' -L../common -lcross -lXext -lX11 ld: warning table of contents of library: ../common/libcross.a not sorted slower link editing will result (use the ranlib(1) -s option) ld: Undefined symbols: _S_ISDIR *** Exit 1 Stop. *** Exit 1 Stop. ============== I found the following references to S_ISDIR in the source code, am I missing any? runner> cd ../common runner>grep ISDIR * map.c:#ifndef S_ISDIR map.c:#define S_ISDIR(x) (((x) & S_IFMT) == S_IFDIR) map.c: if (stat (buf, &statbuf) || !S_ISDIR (statbuf.st_mode)) { porting.c: if (S_ISDIR(st.st_mode)) runner> cd ../server runner>grep ISDIR * login.c:#ifndef S_ISDIR login.c:#define S_ISDIR(x) (((x) & S_IFMT) == S_IFDIR) Any assistance would be appreciated. --- Richard richard%runner.uucp@usc.edu (100K bytes max -- ok to send NeXTMail) From crossfire-request Sun Dec 3 02:43:39 1995 Return-Path: Received: from panix3.panix.com (panix3.panix.com [198.7.0.4]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sun, 3 Dec 1995 02:43:38 +0100 Received: from digitek.dialup.access.net (digitek.dialup.access.net [166.84.192.202]) by panix3.panix.com (8.7/8.7/PanixU1.3) with SMTP id UAA27341 for ; Sat, 2 Dec 1995 20:43:36 -0500 (EST) Message-ID: <30C10093.772E@panix.com> Date: Sat, 02 Dec 1995 20:42:43 -0500 From: Yury German Organization: DigiTek Consulting X-Mailer: Mozilla 2.0b2 (Windows; I; 32bit) MIME-Version: 1.0 To: crossfire@ifi.uio.no Subject: Crossfire On-line? References: <199512011227.HAA24074@chaupher.gsfc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Can anyone recomend a few sights which run crossfire so I can actually try out the game? -- ========================================================== Yury German mailto: digitek@panix.com DigiTek Consulting Iphone: yury (general) -- Unix, WWW Administration and Design -- From crossfire-request Sun Dec 3 01:28:29 1995 Return-Path: Received: from pc11.hhs.homewood.k12.al.us (jhankins@pc11.hhs.homewood.k12.al.us [199.88.16.12]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sun, 3 Dec 1995 01:28:27 +0100 Received: (from jhankins@localhost) by pc11.hhs.homewood.k12.al.us (8.6.11/8.6.9) id TAA27012; Sat, 2 Dec 1995 19:28:11 -0600 Date: Sat, 2 Dec 1995 19:28:11 -0600 (CST) From: Jonathan Hankins To: Brian Thomas cc: crossfire@ifi.uio.no Subject: Re: Dreads??? In-Reply-To: <199512021506.KAA24799@chaupher.gsfc.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Sat, 2 Dec 1995, Brian Thomas wrote: > I tryed this out with my 10th level priest.. I managed to > kill 2 dreads with one holy servant, but that was the best > I could do (I was worshiping God too, btw). I couldnt kill the > electric dragon at all this way. But Perhaps the spell is > still too strong... I will try to resubmit a new spell_params > file to Mark to help balance out the new spells. > > While Iam here.. has anyone else noticed some spell imbalances > (w/ the new spells).?? While I was pounding more dreads today ;-) I got an idea...from the old days of AD&D, I remember there being tons of different types of golems. WHy not make the summon golem/call holy servant spells work like the summon pet monster spells, in that they summon a creature based on the character's level...you could be tough with the level restrictions too, since a lot of the people on this list seem to have characters of levels above 30 (I have only gotten to 15, maybe they have too much free time? ;-) j/k...) Anyways, clay golem, flesh golem, iron golem, brass, obsidian....there was a great variety of them as I remember. I bet one of the gifted xmp artsist could do up some fancy images for them, too :) (IMHO) modifications like this to existing spells make the game more fun, as well as more balanced...making someone's spells just less effective tends to make them unhappy....but I'd eagerly work my way to a higher level to get a new kind of golem, etc (maybe *I* have too much free time :) ----------+ Jonathan Hankins +--------------------------------------------- email: jhankins@cs.hhs.homewood.k12.al.us WWW: http://www.hhs.homewood.k12.al.us/class95/jrh/ --------------------------------------------------------------------------- "After the war, what does a soldier become?" --------------------------------------------------------------------------- From crossfire-request Sat Dec 2 16:06:23 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 2 Dec 1995 16:06:22 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id KAA24799; Sat, 2 Dec 1995 10:06:16 -0500 Date: Sat, 2 Dec 1995 10:06:16 -0500 From: Brian Thomas Message-Id: <199512021506.KAA24799@chaupher.gsfc.nasa.gov> To: jhankins@pc11.hhs.homewood.k12.al.us Subject: Re: Dreads??? Cc: crossfire@ifi.uio.no Status: RO > From: Jonathan Hankins writes: > On Fri, 1 Dec 1995, Brian Thomas wrote: > > > Hmm. Sounds like that spell needs some tuning. BTW, which > > God were you worshiping? Lythander? > > > I was worshiping God...it was pretty cute to see "You killed Grukk with > holy servant of God!" :) But yeah, the spell is a bit too > powerful...though very useful for mid level priest characters who don't have > the brawn of some better-equipped fighters. Considering the sparseness of > attack-type spells for priests, I wouldn't want to downgrade it TOO much. I tryed this out with my 10th level priest.. I managed to kill 2 dreads with one holy servant, but that was the best I could do (I was worshiping God too, btw). I couldnt kill the electric dragon at all this way. But Perhaps the spell is still too strong... I will try to resubmit a new spell_params file to Mark to help balance out the new spells. While Iam here.. has anyone else noticed some spell imbalances (w/ the new spells).?? > > I would also like to recogmend that the Dreads have higher speed > > than they currently do. Otherwise they are just too easy to kill, > > and yeild too much xp. > > > The dreads are slow, and pretty stupid...all they ever seem to cast is > magic missile, burning hands, and icestorm. I figured such powerful Yeah. I strongly recomend that the speed of the dreads be brought up to ~electric dragon speed/ and/or give them quite a bit more armour/immunities. Certainly a speed of 0.2 would be a minimum to make them a challange (IMHO). Of course, another solution would be to *decrease* the xp award too. As they stand, I bet the Dread is really only worth 5000-10,000 xp. b.t. > ----------+ Jonathan Hankins +--------------------------------------------- > email: jhankins@cs.hhs.homewood.k12.al.us > WWW: http://www.hhs.homewood.k12.al.us/class95/jrh/ > --------------------------------------------------------------------------- > "After the war, what does a soldier become?" > --------------------------------------------------------------------------- > > From crossfire-request Fri Dec 1 18:43:13 1995 Return-Path: Received: from pc11.hhs.homewood.k12.al.us (jhankins@pc11.hhs.homewood.k12.al.us [199.88.16.12]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 1 Dec 1995 18:43:10 +0100 Received: (from jhankins@localhost) by pc11.hhs.homewood.k12.al.us (8.6.11/8.6.9) id MAA23181; Fri, 1 Dec 1995 12:42:41 -0600 Date: Fri, 1 Dec 1995 12:42:41 -0600 (CST) From: Jonathan Hankins To: Matthias Olsson cc: crossfire@ifi.uio.no Subject: Re: Dreads??? In-Reply-To: <199511230511.PAA24307@florence.teaching.cs.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 23 Nov 1995, Colin wrote: > etc> > etc> > etc>How do you kill a Dread? Cold, lightning or physical?? > etc> > etc>Please answer asap! > etc> > etc>(Im doing the nine gates of hell and am on the seventh) > etc> > > A dread is just a nastier skull, thankfully they are also > bigger and slower. > > Just hit them hard and fast and hope they die! > Or else use mystic fist.... I got suprised the other night when I took out "Grukk" of Grukk's tower, as well as the 4 dreads in the tower in Brest (twice) with a "holy servant" I averaged 1.5 dreads per holy servant..just hide around a corner while the golem beats up on the uglies...I went from level 9 to level 14 in about 10 minutes... :) ----------+ Jonathan Hankins +--------------------------------------------- email: jhankins@cs.hhs.homewood.k12.al.us WWW: http://www.hhs.homewood.k12.al.us/class95/jrh/ --------------------------------------------------------------------------- "After the war, what does a soldier become?" --------------------------------------------------------------------------- From crossfire-request Fri Dec 1 13:35:39 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 1 Dec 1995 13:35:38 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id HAA24080 for crossfire@ifi.uio.no; Fri, 1 Dec 1995 07:35:37 -0500 Date: Fri, 1 Dec 1995 07:35:37 -0500 From: Brian Thomas Message-Id: <199512011235.HAA24080@chaupher.gsfc.nasa.gov> To: crossfire@ifi.uio.no Subject: Re: steal abuse Status: RO > From: "Mark Wedel" writes: > > Certainly, it would be possible to make various things not as nasty. You > could just comment out most of the bad PERMADEATH effects, or change the code. > Reqires some hacking, but not that much. > > At the same time, you could hack a lot of stuff. In the experience functions, > you could obviously just add some multiplication effect so you get more for the > same thing. > Yeah. Actually this is quite trivial and easy and requires no hacking of the code. Just edit the lib/skill_params file so that all of the skills experience multipliers are many times their present value. You will watch your character quickly ascend to Godhood (if that's your desire :) b.t. > -- > --Mark > From crossfire-request Fri Dec 1 13:27:29 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 1 Dec 1995 13:27:28 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id HAA24074; Fri, 1 Dec 1995 07:27:26 -0500 Date: Fri, 1 Dec 1995 07:27:26 -0500 From: Brian Thomas Message-Id: <199512011227.HAA24074@chaupher.gsfc.nasa.gov> To: crossfire@ifi.uio.no Subject: Re: version 0.92.1 Cc: thomas@chaupher.gsfc.nasa.gov Status: RO > 'Raphael.Quinet@eed.ericsson.se' writes: > > >Here is a translation of that french message... I started translating it Thanks Raphael. Clearly, Mr. Maillet likes bomb throwing. Let me attempt to "disarm" some of the "points" he makes: > >Here is what Ludovic Maillet had to say: > > > > Some skills are interesting but existed in another form in the previous > > version: > > - What's the point in learning new skills (without a chance to fail) in > > order to be able to do things that one could do before without learning > > them? > Yah. I have considered putting this in the code. I note that this will make the game more difficult (contrary to your feelings of how difficult the game has become!). Imagine dropping that 2000 platinum for the scroll of smithing, then failing to learn it! > > > - What's the point in lockpicking a door in order to increase one's > > lockpick skill and open doors more easily, if it was so easy to hit > > them? I don't know yet if it is possible to lockpick a door which > > requires a special key, but if this is so, then some quests are doomed. > It is easy to hit (damage) doors only when you are high level &/or have a great weapon. I have never known any of my low-intermediate characters to be able to knock down a door faster than he/she may pick it. The experience award (I think) makes sense. As for special doors--no. You cant pick them with this skill. > > - Some spells became clerical and so are very hard to use by sorcerers. > > I'm not a cleric by vocation, but a sorcerer, and being denied the use > > of some spells is unfair. > What spells would one think to have as duplicate? And, if you do have duplicate spells, then it robs the point of having seperate classes of spell casters. This arrangement (unique spells for each "class" of spellcaster) was an idea I originally resisted when Peter Mardahl and I were hacking the new magic system; I now have come to believe it is the best approach. His (and now mine also) theory is that the clerics be able to cast magic which is "spiritual" in nature. Clearly, "spiritual" is a broad definition, which I wont go into detail here. Practically, it means that "magicians" will get all the "physical" high-damage spells, whilst clerics will get the "spiritual" spells (ie better "summoning" and "healing" spells). Also, unlike magicians, cleric spells will be "flavored" by the God they worship. This connection is what allows them to cast the special "holy word" spells that allow them to (better than even magicians) damage certain classes of creatures (like the "undead"). But generally, clerics will not be out in the game raising physical mayhem. No cleric should have access to a "fireball" spell (unless they are also a wizard). > > powerful warrior and vice versa). There should be a version which > > really separates them. For example some skills (that really add > > something) specific to each class: clerical spells, prayers, graces and > > gods for the clerics, simple battle spells and the like for the > > sorcerers, and martial skills as strong melee weapons for the warriors. But this *is* in the newest version. Havent you made any attempt to play it beyond 2 seconds?!? > > It should be impossible for some class to use some skills... > heh. I guess. I proposed this early on, but now, I feel that its not worth the effort. Imagine if you do this.. you have to make sure that the playbalance is *really* good. All of my high level (60+ level) characters have used a variety of skills to acquire needed xp. Limiting the access to various skills will also (again, counter to your original thesis that the game is now too hard) make the game harder. > > 2. The new version has new spells that weren't in the old one, but since > > there are so few of them and they are divided in two categories, there > > are in fact less spells. Some useful spells such as heal, fireball,... > > [should be common], the differences being on "exotic" spells such as > > earth to dust, holy word,... There should be twice as many spells, > > each kind being specific to one class (clerical spells for clerics). > > Very few spells for warriors and very specific (battle skills). > I strongly disagree. Why should you gain *any* ability to cast spells if you spend all of your time chopping creatures to bits with an axe?!?. > > 4. Keep the old unique ranking system which avoided painful and pointless > > calculations and reflected very well the power of the character in his > > domain. > One thing that can be done is to show the player the number of xp they have in each experience category. This would better allow them to gauge their "power" in an area than just knowing the "level". > > 5. Maybe create very high level spells (> 20) besides spells with power > > increasing according to the level (which is good). For example, a > > level 40 spell for summoning big beasts, or a permanent spell, or a Well... I don't think its too much of a spoiler to say that high-level spells do exist already (the highest currently is 80th level I believe). As of the current version, there is a way to gain knowledge of some of these spells. As for how this is done, to quote many of my teachers, I leave that as an exercise for the student... :) > > 6. Create a system which allows old players to be integrated in the history > > of the game. Example: being allowed to buy a house, to have a plate I commented on this already, but I would like to mention something I would like to see... Player shops. Why not make it possible for a player to buy a place where they make leave "spare" equipment to be bought by other players? b.t. > Regards. > From crossfire-request Mon Dec 18 06:15:27 1995 Return-Path: Received: from zebedee.teaching.cs.adelaide.edu.au (celear@zebedee.teaching.cs.adelaide.edu.au [129.127.104.27]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 18 Dec 1995 06:15:21 +0100 Received: from celear@zebedee.teaching.cs.adelaide.edu.au by zebedee.teaching.cs.adelaide.edu.au (8.6.12/AndrewR-MatthewD-950530-CS) id PAA27612; Mon, 18 Dec 1995 15:45:03 +1030 X-Authentic-Sender: celear@zebedee.teaching.cs.adelaide.edu.au From: Colin Message-Id: <199512180515.PAA27612@zebedee.teaching.cs.adelaide.edu.au> Subject: Re: Runes and Disarm To: peterm@langmuir.EECS.Berkeley.EDU (Peter Mardahl) Date: Mon, 18 Dec 1995 15:45:03 +1030 (CST) Cc: crossfire@ifi.uio.no In-Reply-To: <9512180502.AA13174@landau.EECS.Berkeley.EDU> from "Peter Mardahl" at Dec 17, 95 09:02:20 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2519 Status: RO etc> etc>> etc>> I know someone who tried the idea of giving a spellbook etc>> of rune of death to an angel. etc>> etc>> It made it heaps easy to get to some outrageous level etc>> and according to them it was perfectly safe since etc>> detonating the runes didn't even do anything, steping etc>> on them didn't seem to cause any harm to the player. etc> etc>If you're patient enough, you can get an infinite amount of etc>experience with no risk in many ways. It sounds like etc>this guy must have spent many hours doing this. etc> etc>At any rate, the amount of experience should depend on etc>the relative level of the rune and the player. etc> etc>Runes inherit the level of the caster, and a Rune of Death etc>won't hurt someone with a higher level than the rune. etc> This seems pretty silly to me but then I can't actually think of a better way to do it, so I won't criticize it. etc>But a rune of death will happily kill anyone (even the owner) etc>who steps on it, so far as I can remember. etc> etc>> This is one of the reasons I think the disarm spell etc>> shouldn't give any experience for actually disarming etc>> the rune. It should only give a little for actually casting etc>> it. etc> etc>I disagree. The amount of experience granted should depend on etc>the relative level of the rune and the player. For exercising etc>a skill, you should get experience. You should get a trivial etc>amount of experience from disarming a trivial trap, however. etc> etc>Regards, etc> If you actually use the skill the disarm spell isn't a skill it's a cheap way to get crap loads of experience without any risk whatsoever, basically it sucks. Is it possible to weaken the spell so it doesn't always disarm a rune without any risk or to make it back fire or something. Another bug with runes is the rune of (insert favourite cone spell here), the cone spell originates under the person who trips it meaning that if you stand still it doesn't hit you. This is kind of silly on doors. Again I don't know how to fix it, so I will refrain from belittling the programmer(who is no doubt smarter than I). However to the programmer of the spell of disarm it is a crock it gives too much experience for how easy it is to get and it's too cheap to cast. It can give a few levels in a swing if I remember rightly, pretty silly really. Runes are a huge source of experience perhaps the chance of disarming runes should be a little less random or give a lot less experience or something etc> etc>PeterM etc> From crossfire-request Sun Dec 17 08:52:52 1995 Return-Path: Received: from bertha.pyramid.com (bertha.pyramid.com [129.214.1.100]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id ; Sun, 17 Dec 1995 08:52:51 +0100 Received: from stealth.eng.pyramid.com by bertha.pyramid.com (5.67/OSx5.1a Pyramid-Internet-Gateway) id AA13800; Sun, 17 Dec 95 07:51:46 GMT Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA26146; Sun, 17 Dec 95 07:51:45 GMT Date: Sun, 17 Dec 95 07:51:45 GMT From: mwedel@pyramid.com (Mark Wedel) Message-Id: <9512170751.AA26146@stealth.eng.pyramid.com> To: larso@ifi.uio.no, thomas@chaupher.gsfc.nasa.gov Subject: Spoiler generation (was Re: reading books) Cc: crossfire@ifi.uio.no Status: RO One problem with the spoiler is that is requires several tools that are not on most unix systems (Net Pbm and latex, and dvips) I guess Net Pbm proibably isn't totally uncommon, since a lot of web stuff might use it. (also, I seem to recall that the latex stuff also needs a special layout file that is normally not part of it) I wonder how hard it would be to convert output of the spoiler to html format -- net browsers are pretty common out there, and most all of them do have a html to postscript conversion in them..) --Mark From crossfire-request Sun Dec 17 08:48:10 1995 Return-Path: Received: from bertha.pyramid.com (bertha.pyramid.com [129.214.1.100]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Sun, 17 Dec 1995 08:48:09 +0100 Received: from stealth.eng.pyramid.com by bertha.pyramid.com (5.67/OSx5.1a Pyramid-Internet-Gateway) id AA13717; Sun, 17 Dec 95 07:47:37 GMT Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA26141; Sun, 17 Dec 95 07:47:36 GMT Date: Sun, 17 Dec 95 07:47:36 GMT From: mwedel@pyramid.com (Mark Wedel) Message-Id: <9512170747.AA26141@stealth.eng.pyramid.com> To: crossfire@ifi.uio.no Subject: Re: Readable hack: Status: RO > Brian Thomas writes: > > Hey all, > > I would like to passby everyone an idea that I am > working on -- development of the "READABLE" hack. > > Main Idea -- books for players > > One thing, I think, that will go a long way to improving th e > atmosphere of the game is to create code that will support the > development of non-magical reading material, which for lack of > a better (singular) word I will refer to as "books". > > As of the current code, the only non-magical books are those > specifically created on maps. Why not have several types of > (general and specific) information be available in shops and/or > monster treasure hoards? Examples of things that I would > put into books: > > (numerous example books removed) > > Clearly some of this information is already available in the spoiler. > But, with the ability of a given server maintainer to have different > archetypes/gods/spells/etc, the spoiler can sometimes be useless. A > vehicle through which to impart *server specific* information is also > needed. But that wouldnt even be the main value of such a system, > the enchancement to the atmosphere of the game (I think) is the main > point. > Also, there is some information that really should be documented within the game but is not (like how improvement scrolls work). You shouldn't need be reading outside docs on that, but it is cleary too complicated for someone to really figure it out on their own. > > Susequent Idea -- modification of the writing skill. > > I would like to propose that the writing skill be expanded to > allow players to write messages/keep notes in "books". This > would be (err, actually, "is") very easy to do. > > Secondarily, I can't see why players should be able to write if > they cant read! I propose that the Literacy skil be required > for a player to use "writing". IT seems reasonable. Actually, you could probably write if you are not literate, just the end result would be gibberish (game could take whta is written and randomize it. This idea could be expanded - a skill check on writing and literacy is made, and depending on if it is made/how successful the roll was, it determines the output. If the person just barely fails, perhaps every 5 character is randomized or transposed with another one, etc.) > > Susequent Idea -- modification of the literacy skill. > > I would like to further propose that the literacy skill be modified. > Why allow players to read books if they arent literate! Ditto > for spellbooks. PRoblem with this for normal books is that it then becomes a trivial issue for someone to create a 'literate' character who reads books. For spellbooks, this doesn't do any good, but for normal books, this would work, since all it contains is generic information. > > I would further propose that reading skill be adopted. If a > player's literacy level is less than the level of the book (I > wont explain how that's assigned) and/or the level of the > spell/prayer in the book, then they get the "gibberish" message. Like I said above, how close the roll is could determine how much gibberish the person gets. However, this would require that some standard formula be made, and/or only one attempt could be made (if you get different partial messages each time, eventually you could put the information together). Probably a better idea for different levels would be the idea that they are a foreign language (perhaps have some field where language is determined). Perhaps for these different languages, different character sets could be made. I seem to remember that ultima IV or ultima V did something like this - it used its own character set for signs and stuff. Same coudl be done in crossfire, just that if you know the language (Determined by skill level), you get it in normal characters. >Matt Cortes writes: > >I don't know if anyone has ever played it. But there was an old game on >the Sega Genesis called Fatal Labrynth. It was a random RPG game, each >time you go through it, it was different here and there.. its actually >alot like crossfire in a few ways. Anyway, it had a feature I thought >was pretty neat. Each time you killed a specific creature, say blue >slime.. You would gain in knowledge on how that creature reacts, etc. >I'm thinking maybe we could add the ability to have knowledge on each >creature's moves, attacks, etc. The more knowledge you have on the >creature, the better modifiers you get on Dex, Str, Int, etc for each >move you do against that creature. These books you purpose could also >increase the players knowledge the first time the book is read for each >of the creatures in there, then the book could be refered to later on for >things such as best protection spells/items to use, best spells, weaknesses, >max HP, etc for each creature listed in that book. > I know the moria did the same thing. I am not sure how it implemented it, but I guess that it pretty much stored how many of each type of monster you killed, and depending on that number, would tell you varying amounts of data about it. You actually didn't get to attack it any better, but you just knew what it did. The problem I see with getting bonuses (to hit, etc) in crossfire is that each time you attacked something, it would need to check and see if you have extra informatin about this monster, and that you should then get some benefit. The other problem is where to store this information. Number of monsters is hardly static (the way such a method should probably be done is invisible objects in the players inventory that contain monster and how many killed.) > >Good points. And instead of having to write new books per server, why >not make the books call upon the different variables set for each server? >Example: > The Dread's weaknesses are , his max hitpts is >. > Nice idea. I do see 2 problems: IT could get pretty time consuming. If such a system was done, a standard naming convention would need to be done (something like arch name:variable name). But this would add a bit of code. I don't really like adding that idea just for books - something like that should probably also be added to message parsing them (ie, you talk to someone, and he would respond in a similar fashion.) Also, the other problem would be one of the following 2: 1) either those values are filled in when the book is created, which means it could be out of date if archetypes are changed, or 2) The content of the book actually changes (read it once, and it says that dreads have 1500 hp. Save the game, come back at some later time, and your book now says dreads have 2000 hp. That would be a bit strange > >In another message, Brian writes: > This brings up a "tangential" idea I had. For those of you > out there who played "nethack", remember the "magic marker"? > > I thought I might make something like that. It would > allow the player to inscribe a permanent message on the > floor/wall/etc. The way to code this would be to create a > invisible, unique "talk" object where the player was standing. > In this way, even though the map had been re-loaded, the > players message would still be there to be read. The only > problems I see w/ this are the 1) stability of the unique > objects code and 2) the number of unique messages that might > build up over time. Will this cause problems? > > OF course, the rune of marking allows something similar to this, but it isn't permanent (ie, when map resets, it disappears). In terms of number of messages, each time the map is saved or loaded, a check could be made, and there is some chance that a written object disappears. This would then come to an equilibrium at some point on number of messages. unique item code is something that I should probably look at - there is a lot of potential uses for it (written messages above, safety deposity boxes for storing stuff, etc). Someone just brought up the thought of allowing permanent influences by players, and unique items is probably the way to do it. Also, I believe in some message, the idea that all of the above would need a new object type. I fail to see a reason why all of the above couldn't be implemenet in the existing old scroll and old book format (ie, non spell scroll and non spell book). In terms of filling with random information, if you ahve a book with auto_apply set (or some other flag), then it automatically fills it with random information (and flag gets cleared.) IT seems like a waste to use a non object type when all of the above is so similar to how existing books/scrolls work. --Mark From crossfire-request Sun Dec 17 07:48:54 1995 Return-Path: Received: from bertha.pyramid.com (bertha.pyramid.com [129.214.1.100]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Sun, 17 Dec 1995 07:48:53 +0100 Received: from stealth.eng.pyramid.com by bertha.pyramid.com (5.67/OSx5.1a Pyramid-Internet-Gateway) id AA12521; Sun, 17 Dec 95 06:48:20 GMT Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA26032; Sun, 17 Dec 95 06:48:18 GMT Date: Sun, 17 Dec 95 06:48:18 GMT From: mwedel@pyramid.com (Mark Wedel) Message-Id: <9512170648.AA26032@stealth.eng.pyramid.com> To: casino@jsp.umontreal.ca, mwedel@pyramid.com Subject: Re: reading books, another idea I am working on Cc: crossfire@ifi.uio.no Status: RO > On Dec 15, 6:43pm, GESTIONNAIRE DU Casino wrote: >> This is a problem right now. You may (jsut from experience) know that cer! >> spells work good against monsters or whatever else. However, on some maps, >> those monsters may have been changed so this is no longer the case. > >Yes, it's a problem right now... Someone should check all for places >where this is not the case (archetypre override without name change), and >change the name... Any volunteer ? :-) > >> The ideal solution is that when stats are changed, the monster name is also >> changed, so that you know it is not the same thing. > > The perl scripts that go through and check maps for various consistencies could probably also check to see if immunities/attacks/protections have been changed. The problem is more to recognize how substantial the change is. For example, if the only change is that immunity to fear have been added, this is not really major, and it is reasonable for the monster to retain the same name. However, if it is a monster that is now immune to fire instead of cold, that is pretty substantial, and it should be renamed. I am not sure if the perl scripts should try to make that differentiation - probably for the script, it should just sound out the warning, and let the person using the script see if that is something worth worrying about. --Mark From crossfire-request Sun Dec 17 03:52:58 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sun, 17 Dec 1995 03:52:54 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id VAA08235; Sat, 16 Dec 1995 21:51:57 -0500 Date: Sat, 16 Dec 1995 21:51:57 -0500 (EST) From: Matt Cortes To: GESTIONNAIRE DU Casino cc: "Michael B. Martin" , crossfire@ifi.uio.no Subject: Re: Misc notes/thoughts. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 15 Dec 1995, GESTIONNAIRE DU Casino wrote: > I agree, but that's a wole lot different... I wouldn't mind having > borgish clients around, as long as there's a way for the server to detect > them and accept only legit ones... > What I have a problem with is giving the character data to the player, > because it means the player can do backups of the character... > I think i really love with crossfire is the inability to save before > trying a new dungeons, so there's a risk involved... If you give the > players the responsability to keep his character, why wouldn't he keep a > copy around just in case something bad happens ? Even Netrek doesn't > allow this! > > > > > popular.edu, it will read my player file, find a server key that is not > > in its list of keys, and refuse my player file. Basicly, each server has > > a list of keys they accept and/or don't accept (whatever the owner of the > > server wants) and it'll check for that key in the player file. From that > > point maybe we could go a step further and the server that now approves > > Problem with this : Once you have a server key, why not applying it to > all one's characters ? > > Then the problem of encryption : to move a character from one server to > the next, the character must be encrypted in a way both servers can > decrypt it... This means the sharing of RSA decryption keys... So either > just not anybody can set-up a server, or that the decryption key will be > public, thus useless... > > > SO um.. still sound stupid? :> > > Not stupid, just unmanageable :-) > > --- > Casino > From crossfire-request Sat Dec 16 23:44:14 1995 Return-Path: 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 ; Sat, 16 Dec 1995 23:44:13 +0100 Received: from harfang.CC.UMontreal.CA (harfang.CC.UMontreal.CA [132.204.2.102]) by maud.ifi.uio.no ; Sat, 16 Dec 1995 23:44:12 +0100 Received: from epsom.jsp.umontreal.ca (epsom.JSP.UMontreal.CA [132.204.45.25]) by harfang.CC.UMontreal.CA with ESMTP id RAA26766 (8.6.11/IDA-1.6); Sat, 16 Dec 1995 17:40:59 -0500 Received: from derby.jsp.umontreal.ca (derby.jsp.umontreal.ca [132.204.46.26]) by epsom.jsp.umontreal.ca via ESMTP (951211.SGI.8.6.12.PATCH1042/5.17) id RAA22830 ; Sat, 16 Dec 1995 17:42:17 -0500 Received: (from casino@localhost) by derby.jsp.umontreal.ca (951211.SGI.8.6.12.PATCH1042/5.17) id RAA07769 ; Sat, 16 Dec 1995 17:41:51 -0500 Date: Sat, 16 Dec 1995 17:41:51 -0500 (EST) From: GESTIONNAIRE DU Casino To: Mark Wedel cc: Matt Cortes , Brian Thomas , crossfire@ifi.uio.no Subject: Re: reading books, another idea I am working on In-Reply-To: <9512152337.ZM24609@stealth.eng.pyramid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 15 Dec 1995, Mark Wedel wrote: > On Dec 15, 6:43pm, GESTIONNAIRE DU Casino wrote: > > > What about those times one uses an archetype on a map, but override all > > the stats/hits/etc ? The information wouldn't be valid, but the player > > has no way of knowing that... > > > > It's a good idea, though... > > This is a problem right now. You may (jsut from experience) know that certain > spells work good against monsters or whatever else. However, on some maps, > those monsters may have been changed so this is no longer the case. Yes, it's a problem right now... Someone should check all for places where this is not the case (archetypre override without name change), and change the name... Any volunteer ? :-) > The ideal solution is that when stats are changed, the monster name is also > changed, so that you know it is not the same thing. --- Casino From crossfire-request Sat Dec 16 16:40:16 1995 Return-Path: Received: from hilja.it.lut.fi (hevi@hilja.it.lut.fi [157.24.11.72]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 16 Dec 1995 16:40:16 +0100 Received: from localhost (hevi@localhost) by hilja.it.lut.fi (8.6.5/8.6.5/1.12.kim) id RAA21387; Sat, 16 Dec 1995 17:40:01 +0200 Date: Sat, 16 Dec 1995 17:40:00 +0200 (EET) From: Petri Heinila X-Sender: hevi@hilja.it.lut.fi To: crossfire@ifi.uio.no Subject: Re: Misc notes/thoughts. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 15 Dec 1995, GESTIONNAIRE DU Casino wrote: > On Thu, 14 Dec 1995, Matt Cortes wrote: > > > On Wed, 13 Dec 1995, GESTIONNAIRE DU Casino wrote: > > > > > No no no... It would be too easy to cheat. Imagine : I install a server > > > on my machine, and create a map with free armor/spells/money/etc. I get a > > > munchkin character, then move it to the ultra-strict server where you > > > play, and bash everythng about... > > > > Actually. That is handled quite easily with Netrek. Its true they don't > > share player information with other servers (I'll work on them soon too > > ), but they let people write their own clients, and there are clients > > that are made for the purpose of cheating, called Borg Clients. Anyway, > > I agree, but that's a wole lot different... I wouldn't mind having > borgish clients around, as long as there's a way for the server to detect > them and accept only legit ones... I point in restricting (cy)borg clients is that it is not just fun. Making own enchanted military grade borg client is fun for trying and implement features in client. I think the client should not restructed in no way, there is protocol and that is it. Client should be able utilize all the information server give to it. > > popular.edu, it will read my player file, find a server key that is not > > in its list of keys, and refuse my player file. Basicly, each server has > > a list of keys they accept and/or don't accept (whatever the owner of the > > server wants) and it'll check for that key in the player file. From that > > point maybe we could go a step further and the server that now approves > > Problem with this : Once you have a server key, why not applying it to > all one's characters ? > > Then the problem of encryption : to move a character from one server to > the next, the character must be encrypted in a way both servers can > decrypt it... This means the sharing of RSA decryption keys... So either > just not anybody can set-up a server, or that the decryption key will be > public, thus useless... I see charactes can be well moved between servers, not by server-client-server manner but just server-server manner with server-to-server protocol. Petri.Heinila@lut.fi From crossfire-request Sat Dec 16 08:38:05 1995 Return-Path: Received: from bertha.pyramid.com (bertha.pyramid.com [129.214.1.100]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Sat, 16 Dec 1995 08:38:04 +0100 Received: from stealth.eng.pyramid.com by bertha.pyramid.com (5.67/OSx5.1a Pyramid-Internet-Gateway) id AA10923; Sat, 16 Dec 95 07:37:32 GMT Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA24611; Sat, 16 Dec 95 07:37:26 GMT From: "Mark Wedel" Message-Id: <9512152337.ZM24609@stealth.eng.pyramid.com> Date: Fri, 15 Dec 1995 23:37:26 -0800 In-Reply-To: GESTIONNAIRE DU Casino "Re: reading books, another idea I am working on" (Dec 15, 6:43pm) References: X-Mailer: Z-Mail (3.2.0 06sep94) To: GESTIONNAIRE DU Casino , Matt Cortes Subject: Re: reading books, another idea I am working on Cc: Brian Thomas , crossfire@ifi.uio.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: RO On Dec 15, 6:43pm, GESTIONNAIRE DU Casino wrote: > What about those times one uses an archetype on a map, but override all > the stats/hits/etc ? The information wouldn't be valid, but the player > has no way of knowing that... > > It's a good idea, though... > > --- > Casino > This is a problem right now. You may (jsut from experience) know that certain spells work good against monsters or whatever else. However, on some maps, those monsters may have been changed so this is no longer the case. Whether you got your information from a book or just from playing a bit, the result is the same. The ideal solution is that when stats are changed, the monster name is also changed, so that you know it is not the same thing. -- --Mark From crossfire-request Sat Dec 16 07:51:37 1995 Return-Path: Received: from bertha.pyramid.com (bertha.pyramid.com [129.214.1.100]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Sat, 16 Dec 1995 07:51:36 +0100 Received: from stealth.eng.pyramid.com by bertha.pyramid.com (5.67/OSx5.1a Pyramid-Internet-Gateway) id AA09818; Sat, 16 Dec 95 06:51:04 GMT Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA24567; Sat, 16 Dec 95 06:51:02 GMT From: "Mark Wedel" Message-Id: <9512152251.ZM24565@stealth.eng.pyramid.com> Date: Fri, 15 Dec 1995 22:51:02 -0800 In-Reply-To: GESTIONNAIRE DU Casino "Map creation" (Dec 15, 6:52pm) References: X-Mailer: Z-Mail (3.2.0 06sep94) To: GESTIONNAIRE DU Casino , crossfire@ifi.uio.no Subject: Re: Map creation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: RO On Dec 15, 6:52pm, GESTIONNAIRE DU Casino wrote: > Subject: Map creation > > Hi... > I'm in the process of creating news maps for crossfire (mainly building > up houses for Scorn - the city seems too much empty for my taste :-) > > i'd like to know a few things (I'm kind of a newbie to the list, though a > long time player...) > 1- How often is there a new version of crossfire, patched with the > bugs fix/enhancement ? In general, once every month to once every other month. Depends how much stuff changes and how much time I have to put it together. I will probably try and make a new release by the end of this month. > 2- How often a new map archive is distributed, with new maps ? If maps have changed, I will make an archive the same time I make a new source release (even if the changes are very minor) > 3- What are the requirements for new maps ? I'd like to make them good the > first time, if possible... And what happens if two persons sends maps for > the same building ? > 4- Is there any MAPS TO DO list of some kind ? > Both of these questions should be answered/clarified if you look at doc/mapguide. I've never had a case yet where 2 people sent maps for the same building. In general, map creation doesn't happen all that often/fast. > > --- > Casino > >-- End of excerpt from GESTIONNAIRE DU Casino -- --Mark From crossfire-request Sat Dec 16 01:20:40 1995 Return-Path: Received: from bertha.pyramid.com (bertha.pyramid.com [129.214.1.100]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Sat, 16 Dec 1995 01:20:38 +0100 Received: from stealth.eng.pyramid.com by bertha.pyramid.com (5.67/OSx5.1a Pyramid-Internet-Gateway) id AA26199; Sat, 16 Dec 95 00:20:07 GMT Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA21848; Sat, 16 Dec 95 00:20:05 GMT From: "Mark Wedel" Message-Id: <9512151620.ZM21846@stealth.eng.pyramid.com> Date: Fri, 15 Dec 1995 16:20:04 -0800 In-Reply-To: Karl Hagen Geppert "Enchanting weapons" (Dec 14, 2:54pm) References: <199512150054.AA21491@kultarr.cit.gu.edu.au> X-Mailer: Z-Mail (3.2.0 06sep94) To: Karl Hagen Geppert , crossfire@ifi.uio.no Subject: Re: Enchanting weapons Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: RO On Dec 14, 2:54pm, Karl Hagen Geppert wrote: > Subject: Enchanting weapons > G'day, > > We've been playing on a 0.92.1 server for a few weeks, and find great trouble > with trying to use enchanted weapons. Weapons that were usable in 0.92 server > now are rendered unusable with the message 'this weapon is too powerful'. > We have had characters go from level 20 to level 60 with significant increases > in power statistics, and they are still not able to use a weapon that has been > enchanted only a few times. Is this deliberate or merely a miscalculation of > stat's somewhere along the line? > Well, this is because the power of weapons that a character can be used was greatly changed. 2 things changed - first it uses your combat skill level instead of overall level, and it uses that level divided by 5 +5 (ie, (level/5)+5). Thus, even a 60'th level person could only use a weapon enchanted 17 times > Also, if you enchant a weapon that you are wielding, there appears to be no > checking done on the power of the weapon. You can enchant your wielded blade > to blazes (so to speak (and did someone say vorpal)), but if you unwield the > weapon, it will not allow you to pick it up again. Should you be forced to > unwield the weapon once it becomes too powerful? If so, could we please have > some warning messages or a skill or something that lets us know when it is > going to be too powerful. This would save spendin unecessary amounts of > platinum on our deux ex machinas (sic) > It is suposed to not let you enchant a wielded weapon above what you can use. I got a patch for this that I believe will fix this again (I think the problem was that in some areas, the check was for skill level, and other places it was for overall level, which created inconsistencies). So this will be fixed in the next version > Karl > karlg@cit.gu.edu.au >-- End of excerpt from Karl Hagen Geppert -- --Mark From crossfire-request Sat Dec 16 00:52:10 1995 Return-Path: Received: from harfang.CC.UMontreal.CA (harfang.CC.UMontreal.CA [132.204.2.102]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 16 Dec 1995 00:52:09 +0100 Received: from epsom.jsp.umontreal.ca (epsom.JSP.UMontreal.CA [132.204.45.25]) by harfang.CC.UMontreal.CA with ESMTP id SAA13365 (8.6.11/IDA-1.6 for ); Fri, 15 Dec 1995 18:51:31 -0500 Received: from derby.jsp.umontreal.ca (derby.jsp.umontreal.ca [132.204.46.26]) by epsom.jsp.umontreal.ca via ESMTP (951211.SGI.8.6.12.PATCH1042/5.17) id SAA23668 for ; Fri, 15 Dec 1995 18:52:47 -0500 Received: (from casino@localhost) by derby.jsp.umontreal.ca (951211.SGI.8.6.12.PATCH1042/5.17) id SAA04456 ; Fri, 15 Dec 1995 18:52:22 -0500 Date: Fri, 15 Dec 1995 18:52:22 -0500 (EST) From: GESTIONNAIRE DU Casino To: crossfire@ifi.uio.no Subject: Map creation In-Reply-To: <199512152036.PAA06091@chaupher.gsfc.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Hi... I'm in the process of creating news maps for crossfire (mainly building up houses for Scorn - the city seems too much empty for my taste :-) i'd like to know a few things (I'm kind of a newbie to the list, though a long time player...) 1- How often is there a new version of crossfire, patched with the bugs fix/enhancement ? 2- How often a new map archive is distributed, with new maps ? 3- What are the requirements for new maps ? I'd like to make them good the first time, if possible... And what happens if two persons sends maps for the same building ? 4- Is there any MAPS TO DO list of some kind ? --- Casino From crossfire-request Sat Dec 16 00:43:51 1995 Return-Path: Received: from harfang.CC.UMontreal.CA (harfang.CC.UMontreal.CA [132.204.2.102]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 16 Dec 1995 00:43:45 +0100 Received: from epsom.jsp.umontreal.ca (epsom.JSP.UMontreal.CA [132.204.45.25]) by harfang.CC.UMontreal.CA with ESMTP id SAA13255 (8.6.11/IDA-1.6); Fri, 15 Dec 1995 18:42:38 -0500 Received: from derby.jsp.umontreal.ca (derby.jsp.umontreal.ca [132.204.46.26]) by epsom.jsp.umontreal.ca via ESMTP (951211.SGI.8.6.12.PATCH1042/5.17) id SAA23364 ; Fri, 15 Dec 1995 18:43:55 -0500 Received: (from casino@localhost) by derby.jsp.umontreal.ca (951211.SGI.8.6.12.PATCH1042/5.17) id SAA04269 ; Fri, 15 Dec 1995 18:43:29 -0500 Date: Fri, 15 Dec 1995 18:43:29 -0500 (EST) From: GESTIONNAIRE DU Casino To: Matt Cortes cc: Brian Thomas , crossfire@ifi.uio.no Subject: Re: reading books, another idea I am working on In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 14 Dec 1995, Matt Cortes wrote: > On Wed, 13 Dec 1995, Brian Thomas wrote: > > > As of the current code, the only non-magical books are those > > specifically created on maps. Why not have several types of > > (general and specific) information be available in shops and/or > > monster treasure hoards? Examples of things that I would > > put into books: > > > > -> Compendiums on monsters/racial groups. Their powers/abilities > > and how to kill them. > move you do against that creature. These books you purpose could also > increase the players knowledge the first time the book is read for each > of the creatures in there, then the book could be refered to later on for > things such as best protection spells/items to use, best spells, weaknesses, > max HP, etc for each creature listed in that book. What about those times one uses an archetype on a map, but override all the stats/hits/etc ? The information wouldn't be valid, but the player has no way of knowing that... It's a good idea, though... --- Casino From crossfire-request Sat Dec 16 00:37:16 1995 Return-Path: Received: from harfang.CC.UMontreal.CA (harfang.CC.UMontreal.CA [132.204.2.102]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 16 Dec 1995 00:37:14 +0100 Received: from epsom.jsp.umontreal.ca (epsom.JSP.UMontreal.CA [132.204.45.25]) by harfang.CC.UMontreal.CA with ESMTP id SAA13190 (8.6.11/IDA-1.6); Fri, 15 Dec 1995 18:36:29 -0500 Received: from derby.jsp.umontreal.ca (derby.jsp.umontreal.ca [132.204.46.26]) by epsom.jsp.umontreal.ca via ESMTP (951211.SGI.8.6.12.PATCH1042/5.17) id SAA23266 ; Fri, 15 Dec 1995 18:37:45 -0500 Received: (from casino@localhost) by derby.jsp.umontreal.ca (951211.SGI.8.6.12.PATCH1042/5.17) id SAA04183 ; Fri, 15 Dec 1995 18:37:20 -0500 Date: Fri, 15 Dec 1995 18:37:20 -0500 (EST) From: GESTIONNAIRE DU Casino To: Matt Cortes cc: "Michael B. Martin" , crossfire@ifi.uio.no Subject: Re: Misc notes/thoughts. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 14 Dec 1995, Matt Cortes wrote: > On Wed, 13 Dec 1995, GESTIONNAIRE DU Casino wrote: > > > No no no... It would be too easy to cheat. Imagine : I install a server > > on my machine, and create a map with free armor/spells/money/etc. I get a > > munchkin character, then move it to the ultra-strict server where you > > play, and bash everythng about... > > Actually. That is handled quite easily with Netrek. Its true they don't > share player information with other servers (I'll work on them soon too > ), but they let people write their own clients, and there are clients > that are made for the purpose of cheating, called Borg Clients. Anyway, I agree, but that's a wole lot different... I wouldn't mind having borgish clients around, as long as there's a way for the server to detect them and accept only legit ones... What I have a problem with is giving the character data to the player, because it means the player can do backups of the character... I think i really love with crossfire is the inability to save before trying a new dungeons, so there's a risk involved... If you give the players the responsability to keep his character, why wouldn't he keep a copy around just in case something bad happens ? Even Netrek doesn't allow this! > popular.edu, it will read my player file, find a server key that is not > in its list of keys, and refuse my player file. Basicly, each server has > a list of keys they accept and/or don't accept (whatever the owner of the > server wants) and it'll check for that key in the player file. From that > point maybe we could go a step further and the server that now approves Problem with this : Once you have a server key, why not applying it to all one's characters ? Then the problem of encryption : to move a character from one server to the next, the character must be encrypted in a way both servers can decrypt it... This means the sharing of RSA decryption keys... So either just not anybody can set-up a server, or that the decryption key will be public, thus useless... > SO um.. still sound stupid? :> Not stupid, just unmanageable :-) --- Casino From crossfire-request Fri Dec 15 21:36:34 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 15 Dec 1995 21:36:32 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id PAA06091; Fri, 15 Dec 1995 15:36:27 -0500 Date: Fri, 15 Dec 1995 15:36:27 -0500 From: Brian Thomas Message-Id: <199512152036.PAA06091@chaupher.gsfc.nasa.gov> To: thomas@chaupher.gsfc.nasa.gov, Steve.Wray@vuw.ac.nz, thomas@chaupher.gsfc.nasa.gov Subject: Re spoiler compile... Cc: crossfire@ifi.uio.no Status: RO Oh yeah, I bet the one that youre crashing on (in the message) is "lokanth", one of mine too. Its the treasure that is the problem. Take a look a the treasures file you have and let me know what the treasure for lokanth is. b.t. From crossfire-request Fri Dec 15 21:33:44 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 15 Dec 1995 21:33:43 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id PAA06085; Fri, 15 Dec 1995 15:33:37 -0500 Date: Fri, 15 Dec 1995 15:33:37 -0500 From: Brian Thomas Message-Id: <199512152033.PAA06085@chaupher.gsfc.nasa.gov> To: thomas@chaupher.gsfc.nasa.gov, Steve.Wray@vuw.ac.nz Subject: Re: reading books, another idea I am working on Cc: crossfire@ifi.uio.no Status: RO > From: Stephen Wray writes: > > I would really like to recompile the spoiler. But when it runs crossfire -m2 > this happens; > > ~(2)$ crossfire -m2 > Welcome to CrossFire, v0.92.1 > Copyright (C) 1994 Mark Wedel. > Copyright (C) 1992 Frank Tore Johansen. > speedball | 2| 0| 30|(lightning fast movement)(levitate)(see invisible)(Attacks: magical, ghosthit)|speedball|speedballwall > Avatar | 1000| 500|-10|(fast movement)(armour+45)(Immune: magical)|avatar| > golem | 50| 50| 5|(slow movement)|golem| > Servant | 50| 50| 4|(normal movement)(armour+25)(Immune: magical)|holy_servant| > [big snip] > lamia |100000|3000|-10|(fast movement)(armour+30)(see invisible)(wield weapon)(archer)(wear armour)(wear ring)(read scroll)(fire wand)(use rod)(use horn)(spellcaster)(Spell abilities:)(paralyze spells)(fear)(Attacks: physical, acid)(Immune: acid, poison, fear, chaos)(Protected: magical)|lamia| > living chaos | 50000| 250|-15|(extremely fast movement)(levitate)(spellcaster)(Spell abilities:)(create pool of chaos)(Attacks: chaos)(Immune: ghosthit, poison, fear, death, chaos)(Protected: physical, magical, fire, electricity, cold)(Vulnerable: confusion, drain, weaponmagic)|living_chaos| > > SIGSEGV received. > IOT trap/Abort > ~(3)$ > > Any clues? > Yeah. (and I meant to tell the list about this earlier...) what is happening is that some of the archs are crashing the compile. I have some notes on bad ones around here, jsut a sec... Ah, yeah, here's some I found: -firechest - appears to need "monster 1" -gargoyle - treasure list not accessible, I think I fixed this Others? I think so, but my notes are woefully stained w/ coke rings.. sorry. :) bt. > - -- > - --- > **********************T***H***E***L***E***M***A********************** > 44. For pure will, unassuaged of purpose, delivered from the lust of > result, is every way perfect. -- LIBER AL vel LEGIS > ******************************IN*LVX********************************* > Stephen Wray > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.i > > iQCVAgUBMNHahSt7qh9JVcfZAQEI/gP/TofW2dnv+oaRXId7Dez9ez+fBpepLBMp > XXIT5b4TdgIEWVR+ucR3AzsQIM7i9xm+DDJwJLhbloGlaBBdzo9zkTtwJpVMLsB0 > ylaSIqfqcEnC3auH1Q6s6fpoH2xeTV2intdU/ZgUezzqCjcAmN36dRpTN6DEMsTr > lOE62SSer9U= > =1chZ > -----END PGP SIGNATURE----- > From crossfire-request Fri Dec 15 18:51:59 1995 Return-Path: Received: from mne.ifi.uio.no (mne.ifi.uio.no [129.240.70.5]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id ; Fri, 15 Dec 1995 18:51:59 +0100 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by mne.ifi.uio.no ; Fri, 15 Dec 1995 18:51:28 +0100 Date: Fri, 15 Dec 1995 18:51:28 +0100 Message-Id: <199512151751.22197.mne.ifi.uio.no@ifi.uio.no> To: "Michael B. Martin" CC: crossfire@ifi.uio.no In-reply-to: <199512151706.MAA07618@mbmartin.bevc.blacksburg.va.us> Subject: Re: Sounds Status: RO [Michael B. Martin] | Also, what about stereo? If a well is on your left, have a | dripping sound come out of the left channel, if your hardware has | one? Give the client the map coordinates of the sound source, and the client can implement Dolby Surround if it has the hardware. Would be cool if you could hear the owls tooting far away, out of sight. We should restrict the number of objects with sounds on every map so that it is feasible to let them all be active. Idea: Make a general event queue. Throw dice to see how long till next sound. Put it in the event queue (a priority queue). Similar for monster movement etc. You can have one queue for the whole game, or one for each map. Kjetil T. From crossfire-request Fri Dec 15 17:04:44 1995 Return-Path: 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 ; Fri, 15 Dec 1995 17:04:43 +0100 Received: (from martinm@localhost) by mbmartin.bevc.blacksburg.va.us (8.6.12/8.6.9) id MAA07618 for crossfire@ifi.uio.no; Fri, 15 Dec 1995 12:06:26 -0500 From: "Michael B. Martin" Message-Id: <199512151706.MAA07618@mbmartin.bevc.blacksburg.va.us> Subject: Re: Sounds (various ideas - long) To: crossfire@ifi.uio.no Date: Fri, 15 Dec 1995 12:06:26 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5290 Status: RO > The problem is sound files can be quite large. If you are on a low > bandwidth connection, do you really want to freeze up for a few seconds as > that sound gets sent down the pipe? > > There could be several ways to do this. Have a common list of symbolic > sound names between the client and server. At startup, have the server send > down what it thinks are the proper sound (.au) files for each symbolic name > - client is free to do whatever it wants with this information. It seems to me that the best way (bandwidth-wise) to handle something like this is to have the client store all sound files with itself (a default selection of sounds could come with the client app). Then, when the client connects to the server, the client can ask it which sounds it has (by number?) and then request any new sounds that have been added to that server. Thus the only data files that are transmitted over the network are exactly the ones needed, and they are transferrred before the real game session starts so it won't be interrupted in the middle. (The same thing could be done with the graphics.) If a player has a sound he likes better than one of the default ones, he could just replace the appropriate one with the new one (either by renaming the physical file or, better yet, editing a configuration file which binds each sound number to a specific sound file). And if for some reason the client doesn't have a sound that the server told it to play, it could just ignore the command. > Priority gets to be a strange issue (different people will think different > actions have different importance). But I guess that between symbolic sound > names and priority, it would be pretty easy for the client to do filtering > (only play monster_hit_player if priority>80 type of thing. But this would > assume that priority would vary) Well, would the server or client handle priorities? And how exactly are the priorities to be used? I interpreted it to be something like: the server has three sound events to be processed; it checks the sounds' priorities, finds that sound #2 has the highest priority, and sends a command to the client to play sound #2. Obviously, this is ignoring the possibility of mixing multiple sounds. > >There should be a way to have background music too, although I don't think > >this is so important. One way to do it would be to have more entries in > >the config file (for example, "music 1", "music 2" and so on). All sound > >types beginning with "music" would be played in a loop instead of being > >played only once. And only one of them can be played at a time. But using > >simple numbers for background music would not help people to set the right > >atmosphere for their map. > > I don't necessarily know whether numbers or actual names would work > better. I guess it depends on the music (some you just can't really > describe in 1 word, but there could be types.) In any case, it would be a > trivial matter to use some field (preferably a string format) in the map > object to specify what background sound to play. I like the idea of "background" sounds, but I have mixed feelings on music. First of all, if you add background sounds, crossfire could get quite complex "audially" (does such a word exist?). What I mean is that you could potentially have a lot of sound effects going on "simultaneously". Having music on top of that could make things just too noisy. Also, there is the question of musical format. MIDI has some nice features, but coding a MIDI player is not trivial and many systems don't have one, I believe. Protracker-style (.mod, .669, .s3m, etc.) modules have the advantage that they give you good quality music for relatively little data size and such players (at least for the most basic .mod format) are ubiquitous. But playing .mod files can often eat up a lot of CPU to handle the sound mixing (except for those with hardware that can handle the mixing, like a GUS in an ix86-based system). Besides, what kind of music would you like to have while playing crossfire? I personally can't think of anything that good. > Perhaps even have some mechanism/special object that would change the > background music (so you step over one onto a new one and it changes.) With MIDI or .mod files, you could even have it jump to another place within the same song without much trouble. Also, what about stereo? If a well is on your left, have a dripping sound come out of the left channel, if your hardware has one? This would make the background sounds much more ambient and would probably be easy to implement (the server can just add an extra parameter to the "play this sound" command to specify which channel(s); a client with only mono sound could just ignore the channel specification). The only problem I can see with this from the client's point of view is the situation where the server tells a monoaural-sound-only client to play one sound each on each channel within a very short time (so the two should be playing "simultaneously"). Does the client try to mix them together, or just interrupt the first one when the second needs to start playing? Either way, I guess this would be purely a client issue (clients on different platforms could handle it differently). -Michael From crossfire-request Fri Dec 15 17:49:45 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id ; Fri, 15 Dec 1995 17:49:44 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id LAA05154; Fri, 15 Dec 1995 11:49:42 -0500 Date: Fri, 15 Dec 1995 11:49:42 -0500 From: Brian Thomas Message-Id: <199512151649.LAA05154@chaupher.gsfc.nasa.gov> To: thomas@chaupher.gsfc.nasa.gov, larso@ifi.uio.no Subject: Re: reading books, another idea I am working on Cc: crossfire@ifi.uio.no Status: RO > From larso@ifi.uio.no : > > If you didn't already know this: > The spoiler was created with this in mind. Everytime you edit e.g. the > /lib/archetypes file, you can run a make in the /docs/spoiler directory. > The spoiler will then contain the changes you made in the source etc. > Sure. But few players or even server maintainer know how to/take time to recompile the spoiler after they hack on the archetypes. Having books present up-to-date info would help get around the situation. I am, btw, a fan of the spoiler. I plan to utilize some of the naming conventions (like monster speeds) in READABLE hack. b.t. > Ofcourse the spoiler is, as it says, a spoiler. Books containing minute > information would be cool. > > -Lars > > > -- > DoD# 1755 > BACKUPS? We don't need no steenking bac^&sys 92595 Abort, Retry, Fail? > > > From crossfire-request Fri Dec 15 17:32:14 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 15 Dec 1995 17:32:14 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id LAA05145; Fri, 15 Dec 1995 11:32:12 -0500 Date: Fri, 15 Dec 1995 11:32:12 -0500 From: Brian Thomas Message-Id: <199512151632.LAA05145@chaupher.gsfc.nasa.gov> To: crossfire@ifi.uio.no, Tero.Haatanen@tel.vtt.fi Subject: Re: Sounds (various ideas - long) Status: RO > From: Tero Haatanen > > > Now the map designer can add "sound owls" to some of his trees. > > That was my idea also. But i think you need other parameter also, > how large area the sound is heard and that should be able also add > to each objects. > I would recomend against having a range for sounds. If you do that then there will have to be code calculating what sounds a player can hear based on his position. This problem is a bit like the lighting code w/ light sources. The amount of computational time will scale with the number of "sound-sources". BUT, with sounds you have an additional problem in that they can occur whether the player moved or not! Yech. Unless its done properly a map with several sounds and players could bring the game to a crawl on most systems. b.t. From crossfire-request Fri Dec 15 16:48:37 1995 Return-Path: Received: from beyla.ifi.uio.no (3822@beyla.ifi.uio.no [129.240.96.3]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id ; Fri, 15 Dec 1995 16:48:37 +0100 Message-Id: <199512151548.QAA07687@ifi.uio.no> X-Mailer: exmh version 1.6.4 10/10/95 To: Brian Thomas cc: crossfire@ifi.uio.no Subject: Re: reading books, another idea I am working on In-reply-to: Your message of "Wed, 13 Dec 1995 14:33:37 EST." <199512131933.OAA02060@chaupher.gsfc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Dec 1995 16:48:36 +0100 From: =?iso-8859-1?Q?Lars_Henrik_B=F8ler_Olafsen?= Status: RO > Hey all, >[...] > > Clearly some of this information is already available in the spoiler. > But, with the ability of a given server maintainer to have different > archetypes/gods/spells/etc, the spoiler can sometimes be useless. If you didn't already know this: The spoiler was created with this in mind. Everytime you edit e.g. the /lib/archetypes file, you can run a make in the /docs/spoiler directory. The spoiler will then contain the changes you made in the source etc. Ofcourse the spoiler is, as it says, a spoiler. Books containing minute information would be cool. -Lars -- DoD# 1755 BACKUPS? We don't need no steenking bac^&sys 92595 Abort, Retry, Fail? From crossfire-request Fri Dec 15 13:09:25 1995 Return-Path: Received: from bertha.pyramid.com (bertha.pyramid.com [129.214.1.100]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 15 Dec 1995 13:09:21 +0100 Received: from stealth.eng.pyramid.com by bertha.pyramid.com (5.67/OSx5.1a Pyramid-Internet-Gateway) id AA15381; Fri, 15 Dec 95 12:07:40 GMT Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA17294; Fri, 15 Dec 95 12:07:37 GMT Date: Fri, 15 Dec 95 12:07:37 GMT From: mwedel@pyramid.com (Mark Wedel) Message-Id: <9512151207.AA17294@stealth.eng.pyramid.com> To: crossfire@ifi.uio.no, Raphael.Quinet@eed.ericsson.se Subject: Re: Sounds (various ideas - long) Status: RO >---------- >> Date: Wed, 13 Dec 95 10:29:46 GMT >> From: mwedel@pyramid.com (Mark Wedel) >> >> Sound Improvement: >> >> Raphael mentioned that he would like to improve sound code, but wait for >> client/server to do it. A few thoughts: >> >> IT seems to me that rewriting the sounds config file isn't really dependant >> on client server. [...] > >I could of course re-write the part of the code that reads the config file >without waiting for the client/server split. But I also want to be able to >play these sounds, and this is where the problems begin... It would be nice >if each user could choose to enable or disable some sounds, for example. >Thus each player would need his/her own config file. Adding such features to >the current code would be a nightmare. I agree. I think it will be really nice for the the player using a client to say that I don't want these sounds, but do want these. And this will work best with symbolic sound names, so that the client user can see that he doesn't want the "player hit monster" sound, vs "bap.au" or "sound 53". > >> I guess Raphael's thought is more that the server will send truly symbolic >> commands to the client (ie, "play hit door" sound, vs "play bash.au" sound > >Right. Although I am starting to change my mind... In some cases, the >people who run a server may want to add a special sound effect and the best >way to do this would be to send the sound file directly. Hmmm... > The problem is sound files can be quite large. If you are on a low bandwidth connection, do you really want to freeze up for a few seconds as that sound gets sent down the pipe? There could be several ways to do this. Have a common list of symbolic sound names between the client and server. At startup, have the server send down what it thinks are the proper sound (.au) files for each symbolic name - client is free to do whatever it wants with this information. I do certainly believe that support for special unique sound effects needs to be supported. Perhaps in the case, there is a slight variation of the play sound that specifies the sound file to be played (client might already have it, if the player visited that spot before.) I guess the question would be, however, is how the client goes and gets that sound if it doesn't have it. One method woudl be to request it from the server, and just have th server send it down. This would probably work pretty good (you get a minor delay as the client first sees it doesn't have the sound file). Still have the problem of possible saturation - the only real method to avoid that would be to have something in the client that asks a question before it goes and gets the new sound. >The parameters which should be sent by the server are: >- Sound type (i.e. "hit door", "arrow", "large lightning", ...) >- Attenuation. This tells how much the maximum volume of the sound (set by > the client) should be reduced because of the distance between the source > of the sound and the player. >- Priority. Some machines will only be able to mix a limited number of > sounds, so there should be a way to specify which ones are the most > important. For example, the sound of the player being hit should have a > high priority, even if it doesn't have a high volume. > Priority gets to be a strange issue (different people will think different actions have different importance). But I guess that between symbolic sound names and priority, it would be pretty easy for the client to do filtering (only play monster_hit_player if priority>80 type of thing. But this would assume that priority would vary) >Among the "other events" should be the ambient sounds, such as the sound of >the leaves of a tree in the wind, or water dripping. I will have to find >new names for these, such as: > >ambient water drip = drip.au, 10 >ambient waterfall = waterfall.au, 20 >ambient leaves = # Empty entries are allowed too >ambient wind = wind.au, 10 >ambient storm = wind.au, 20; lightning.au, 50; wind.au, 20; wind.au, 10 >ambient silly example = chill.au, 100 > Perhaps a repeat/sleep time between them should also be in place? Or how does an ambient sound differ from a normal sound? I would assume that ambient sounds would repeat, but in the case of somethign like drip.au, you don't want it on continuesly - probably want it every 20-30 seconds. But you then need some mechanism for turning them off and stuff (could get pretty complicated. Suppose there are 2 wells that generate the drip sound. you walk within range of one, and start getting the drop. You keep iously leave some extension in the protocol to specify which channel (for quite a while, it may just be ignored, or certainly clients probably will). But at least that way, when it does start to get use, the protocol doesn't need to be expanded. >There should be a way to have background music too, although I don't think >this is so important. One way to do it would be to have more entries in >the config file (for example, "music 1", "music 2" and so on). All sound >types beginning with "music" would be played in a loop instead of being >played only once. And only one of them can be played at a time. But using >simple numbers for background music would not help people to set the right >atmosphere for their map. > I don't necessarily know whether numbers or actual names would work better. I guess it depends on the music (some you just can't really describe in 1 word, but there could be types.) In any case, it would be a trivial matter to use some field (preferably a string format) in the map object to specify what background sound to play. Perhaps even have some mechanism/special object that would change the background music (so you step over one onto a new one and it changes.) A more interesting idea would be to expand the msg parsing for npcs, magic mouths, etc, to specify sounds to play. >-Raphael > --Mark From crossfire-request Fri Dec 15 12:43:36 1995 Return-Path: Received: from bertha.pyramid.com (bertha.pyramid.com [129.214.1.100]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 15 Dec 1995 12:43:33 +0100 Received: from stealth.eng.pyramid.com by bertha.pyramid.com (5.67/OSx5.1a Pyramid-Internet-Gateway) id AA14595; Fri, 15 Dec 95 11:42:55 GMT Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA17211; Fri, 15 Dec 95 11:42:53 GMT Date: Fri, 15 Dec 95 11:42:53 GMT From: mwedel@pyramid.com (Mark Wedel) Message-Id: <9512151142.AA17211@stealth.eng.pyramid.com> To: crossfire@ifi.uio.no, Tero.Haatanen@tel.vtt.fi Subject: Re: Mist thoughts (long) Status: RO >> DM MODE > >I meant character name, so that DM could be saved as any other character >and when you login the game (using charaster name and password) then if >character file have 'was_wiz 1' and 'wiz 1' (?) set then player would be >in DM mode. This has nothing to do with dm command. The problem is >how those wiz-flags are set in the first place (using the text editor or >dm command)? > This makes a bit of sense - obviously a DM character can not get on the scoreboard, but being able to save a DM character could be very handy when testing out maps. Perhaps even a special 'save and quit' priveledge should be granted. So I guess basically, the plan would be this: 1) increase dm security by using name, password, and host/display name access. Any of these could be wildcarded. For example, an entry like: *:fireball:* Would just be like the old dm password option. Something like mwedel:magic:xmwedel Would restrict dm access to those named mwedel, and connecting from the host xmwedel and providing the proper password. 2) Dm access over sockets (telnet session) would be allowed. The telnet stuff will probably go away when new client/server is done, but to add support for dm of socket is just removing a couple lines of code (if it involved a lot, I probably wouldn't do it.) 3) Once someone becomes dm, they can save their character, they just don't go on the scoreboard. Anyone see any major problems with that? >Client/server: > >I have looked the code and I have a general idea how the server and client >works. It uses eutl library that has not been decumented (it also has >is own licance that is not GPL). I think that Eric who made the initial >implemetation had used the same library in other project, so it was easy >choice for him (even not the rest of us). Basically it offers the >TCP/IP sockets and dymamic list structure called ArgList. The later >is used to build and send protocol packets. > >Since the server have already TCP/IP code and the ArgList routines really >are overkill to building packets (they dynamically malloc all parameters >for every packet) I thought to try build the server without eutl-library. I am really glad someone is still doing serious work on the client stuff (it is something I want to see happen). From that last line above, does that mean you plan to try, or you have tried? IT seems to me it is more just the effort of going throught and changing on all the code that uses it more than anything else. >> Things that need to worked out to get if fully playable: >> >> 1) Magic mapping spell does not work. > >This is a real problem, and probably needs a general solution. >(special command to support magic mapping should be simple). > The ideal thing would be a send image command (this could be very nice for the future, in case support for special images is ever added.) The problem with that for magic mapping is that the spell uses different strategies dependign if the system is color or not. In the ideal world, the server really should not care what the client is using (it just sends the data, let the client dither it or whatever). The problem I see with that approach for the spell is that a dither magic mapping thing really may not be useful. (for a quick refresh on how magic mapping works: On color systems, the color of the object determines how that square appears on the magic mapping spell (thus you can typically tell walls because they are all the same color, and you know what they are). For black on white, it basically just draws the walls vs floors, and uses a choice of 2 stipple images or other objects.) The problem I see with dithering is that the dither pattern for a wall and floor could be quite close, even if the colors are different. I also wonder if we really want the client to deal with dithering and stuff (on the other hand, we could just invoke some other image viewer (xv, whatever), and just let that figure it out. I may have to try capturing a magic mapping spell and see what a black and white dithered results looks like.) >> 2) Containers do not work > >Hmm, I must look this, it should easy to fix. But the real solution >is to redesign whole container model in a server. The original >containers were used to make inventories smaller, but client can >implement this feature without a server. The real use of containers >then are locked chests, bag of holdings and similar items. Correct. I think containers may also affect how some spells effect a players items (like cancellation) - I don't know if it will descend into containers or not. Also, there are many specialized containers now (only store certain objects, and weight reduction.) From the code I looked over (Assume it is erics), it looks like the idea was that the client would tell the server to move item x to container y. It just seems this doesn't work quite right. > >> 3) things that depend on inventory order will not work, since client >> re-orders objects (not much depends on this) > >I think this should not be a bad problem, please send examples if this is a >real problem. Some commands that needs specific items (enchant weapon?) >can use either weapon that is applied or apply command can supply the >target list (APPLY 'scroll of enchant weapon' 'sword'). If command is >applied many items (identify) then it should make no difference (randomly >identified objects can be thought as feature). > >It also makes game more interesting (dip scrolls to water, mix potion, etc) >when players are allowed to apply object to other objects. Yes - I believe the only thing that depends on item order is improve scrolls. I think it would be nice for the server to be able to request a list of items, and then let the player select them (this could be real nice for stuff like identify - I want to identify x, y, and z first). I suppose that each time the client could send along the items that the applyer is applyign to (like you said) - I like that idea in that it doesn't create state in the server (if the server requests a list, it then needs to know why it wanted that list when it gets it.) If applying items to items could be done in a clean fashion on the client, I would really like it. I guess for most things (identify), if it is not supplied a list, it just goes in whatever order it wants. For things like weapon improvement, it could require an item/list to be provided or it doesn't apply the item. In that way, a player doesn't need to know what cases he needs to specify the item or not. In the case of weapon improvement, it tells him. In the case of some spells, it just adds some functionality (in the case of other spells, it does nothing at all.) > >> 4) Only supports XPM mode. Pixmap mode should be supported. I don't know >> if there is any good reason to support font mode. > >The pixmap mode should be simple add when other features works. Since >fonts requires that all images are available at startup time, I think >that font mode has a low priority (it can be added later without any(?) >changes to a protocol. Eric has said that a fair amount of the code is in place. I will look into finishing it up sometime I have free time (which might be quite a while from now) > >> 6) Handling commands from the client. Right now, it pretty much executes >> the commands as it gets them. > >Yes, this really needs to done, but I haven't idea how the timings >work on the server side. I have understand correctly there is a way >to specify how long different commands take. How this is a implemented >and is these times really used anywhere else than moving around? Any >comments about this is welcome. Well, when I originally had time and did some work on client/server, I added how much time each command takes. Right now, I believe they either take 1.0 time or 0.0 time (but there is nothing preventing them from taking more or less.) What should probably be done on the server side is read all commands the client sends and buffer them. Have an option that the player sets on whether he wants these extra commands executed (buffered) or thrown out (flushed). And some extra timing/flags for certain commands that must always be executed (can never be flushed). Things like fire off and run off. Also add some flags (in both commands on player setable) for commands that can be executed out of order. Most of these would probably be administrative commands (who, maps, etc). Thus, when you are paralyzed, you could still do other things. Also, there may be some other that fall into this category (fire_off and run_off, for example. Looking for those may also improve perceived performance) > >I try document the existing protocol and send that to Mark the same time >as I send other changes. There are many features that needs to done >before the client can replace the current version, but my highest >priority currently is get documented protocol and a stable client >in which it is easy to add missing features. > > -Tero > Sounds great.. --Mark From crossfire-request Fri Dec 15 11:52:53 1995 Return-Path: Received: from tel1.tte.vtt.fi (tel1.tte.vtt.fi [130.188.12.3]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 15 Dec 1995 11:52:53 +0100 Received: (from hat@localhost) by tel1.tte.vtt.fi (8.6.11/8.6.11) id MAA01370 for crossfire@ifi.uio.no; Fri, 15 Dec 1995 12:52:22 +0200 From: Tero Haatanen Message-Id: <199512151052.MAA01370@tel1.tte.vtt.fi> Subject: Re: Sounds (various ideas - long) To: crossfire@ifi.uio.no Date: Fri, 15 Dec 1995 12:52:21 +0200 (EET) In-Reply-To: <199512150237.21940.mne.ifi.uio.no@ifi.uio.no> from "Kjetil Torgrim Homme" at Dec 15, 95 03:37:41 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1431 Status: RO > No, an extra attribute "sound" is needed. I think it should be made > somewhat like treasure, so that it can be "programmed". > > lib/sound: > sound jessy > hit file=swoosh.au vol=40 pri=2;\ > file=bang.au vol=80 pri=1 > move file=clank.au vol=30 pri=9 > random file=swear.au vol=50 chance=.01 pri=3 > random file=flutter.au vol=50 chance=.1 pri=3 > end Just make one more level indirection and remove .au from each sound and have that mapping done lower level (like images: bag.111 -> bag.111.xpm or bag.111.bitmap). Probably there should be more general way to define how objects react specific events. Since sounds are optional part, it would be little odd that when jessy hits (or is hit?) there are easy way to change sound, but there is no way to send any text or change bitmap or doing some other basic thing like that. > Now the map designer can add "sound owls" to some of his trees. That was my idea also. But i think you need other parameter also, how large area the sound is heard and that should be able also add to each objects. > It might be nice to be able to change some of the sound parameters in > the individual objects, but I don't think we need further bloat in the > object structure... If I understand rigth what you are saying then that can be achieved by adding the more bloat to lib/sound file ;). -Tero From crossfire-request Fri Dec 15 06:56:57 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 15 Dec 1995 06:56:53 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id AAA03138; Fri, 15 Dec 1995 00:56:54 -0500 Date: Fri, 15 Dec 1995 00:56:54 -0500 (EST) From: Matt Cortes To: Brian Thomas cc: thomas@chaupher.gsfc.nasa.gov, crossfire@ifi.uio.no Subject: Re: reading books, another idea I am working on In-Reply-To: <199512141832.NAA02801@chaupher.gsfc.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 14 Dec 1995, Brian Thomas wrote: > > I'm wondering how hard it would be to say.. choose a religon? Make > > strict rules for clerics once they choose a god to worship. The > > advantage is random favors from the god based on how faithful the cleric > > has been. Do simple things like Elemental gods, Demon gods, etc. Cleric > > studies the arts, practices etc for the god of his choose, as he advances > > he gains the strengths and weakness of such practices. For example, > > studing under the Fire God increases his ability with fire, but makes him > > weaker toward cold, etc. Something like this should be done for all > > types of characters by the way.. Make spells more intense, likely to > > succeed, harmful, as the players level raises (reads more books on type > > of spell ). > > > Hmm. Well, all of this is already possible with the MULTIGOD > option! Oh really? I didn't even know it existed. Guess most of this is found out by wading through the source huh? :> Is it possible then please to get some explantion to what MULTIGOD does exactly and on its use? > > What the heck is the writing skill and stylus pen used for now anyway?? > > > You can use it to "overwrite" magical scrolls with spells > that you know. In this way, it is easy to keep a few > "cure confusion" scrolls (or whatever you find useful) > around. AH, ok. Cool idea. Thank you for making me alittle less ignorant to the game. :> > Yeah. I though that the player aught to be able to write > in *any* non-magical book, even the ones you find on the > maps. Anything a player writes would be appended to the > end of the previous message. Pretty easy to code this. Yes, I do program somewhat.. It does sound easy to do, I have yet to actually look at the crossfire code though. > > Also maybe a "note paper" item for small "Link was here first!!" > > messages, etc. :> > > > This brings up a "tangential" idea I had. For those of you > out there who played "nethack", remember the "magic marker"? > > I thought I might make something like that. It would > allow the player to inscribe a permanent message on the > floor/wall/etc. The way to code this would be to create a > invisible, unique "talk" object where the player was standing. > In this way, even though the map had been re-loaded, the > players message would still be there to be read. The only > problems I see w/ this are the 1) stability of the unique > objects code and 2) the number of unique messages that might > build up over time. Will this cause problems? Well, #2 could be solved. Everything wears away over time.. Also, not all surfaces should be able to have marks on it. make them for weak, easily marked walls, etc in hard to get to places. Or at least not as many public places. Like that huge wall in the city to the west (forget the name), it already has writing on it, but something like that. Also only allow those areas to contain so many lines. The newer stuff speeds up fading away of the older stuff. Also the dm's job could be to go around and clean up and nonsense messages? Just some extra ideas thown out anyway.. > > > I would further propose that reading skill be adopted. If a > > > player's literacy level is less than the level of the book (I > > > wont explain how that's assigned) and/or the level of the > > > spell/prayer in the book, then they get the "gibberish" message. > > > > Thats pretty much already doing that if a player buys/gets a spellbook > > thats higher then his level and he tries to read it. > > > Right, but that's the point. Replace the old system w/ this > one. Ok, I see what your saying. Yes, some of these new features would be alot easier/better if the whole system for this was rewritten. > > > Allow a nominal amound of xp to be awarded for translation of > > > a book (based on the readers level and the level of the book of > > > course). > > > > Or, why not make different xp catagories? Pysical, Mental, etc. That > > would open up a whole new world of stuff, then have seperate levels as well. > > In AD&D you can be a fighter/mage/thief, etc. Maybe we can implement > > something like that and have xp awarded to each catagory depending on > > what acts we do? > > > > Take a look at the skills system... are you playing 0.92.1? > Enable the ALLOW_SKILLS code and you will find all of this > (more or less) already exists. :) How bout that. Yes, I'm using the latest one. Like I said, I haven't messed with the code at all, so alot of this I didn't know about. But its interesting to see these ideas have already been thought of, used etc. My only problem is how come its not enabled now? We shouldn't have a bunch of different rules lieing around. Come up with a standard set which we can always add to later on. Thanks, -Matt From crossfire-request Fri Dec 15 03:38:12 1995 Return-Path: Received: from mne.ifi.uio.no (mne.ifi.uio.no [129.240.70.5]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 15 Dec 1995 03:38:12 +0100 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by mne.ifi.uio.no ; Fri, 15 Dec 1995 03:37:41 +0100 Date: Fri, 15 Dec 1995 03:37:41 +0100 Message-Id: <199512150237.21940.mne.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: <199512131757.SAA22086@chapelle.eed.ericsson.se> Subject: Re: Sounds (various ideas - long) Status: RO [Tero Haatanen] | I think that sounds don't need any special archetypes, but just | build-in support in objects like faces are now. [Raphael Quinet] | This would be a problem for ambient sounds, because you need to | know at least two things: | - the type of sound that should be played: "wind", "water | dripping", "owls"... | - how often the sound should be played (ambient sounds are repeated | at random, but some of the should be played more often) | These parameters have to be stored somewhere on the map. Thats why | I suggest adding some (invisible) objects to the map, that are | only playing sounds. No, an extra attribute "sound" is needed. I think it should be made somewhat like treasure, so that it can be "programmed". lib/sound: sound jessy hit file=swoosh.au vol=40 pri=2;\ file=bang.au vol=80 pri=1 move file=clank.au vol=30 pri=9 random file=swear.au vol=50 chance=.01 pri=3 random file=flutter.au vol=50 chance=.1 pri=3 end sound owls random file=hoohoo.au vol=40 chance=.002 pri=3 end sound river random file=water.au vol=30 chance=1 pri=10 end Now the map designer can add "sound owls" to some of his trees. Note that "river" has chance 1, meaning a continous sound, since the random test never fails. It might be nice to be able to change some of the sound parameters in the individual objects, but I don't think we need further bloat in the object structure... | The easiest way to have background music would be to play a (long) .au | file at a low level and mix it with other sound effects, because MIDI is | not available on all systems. But the music files would of course take | a few Mb... Also consider using ProTracker-modules -- good music for very few bytes. I think tracker-players are more common than MIDI-players. Especially without special hardware... DOn't know how they mix with rplay or NAS. | Yes, but these proposals will only become interesting once someone starts | implementing them. Yep, can't help there :-) Kjetil T. From crossfire-request Fri Dec 15 03:18:42 1995 Return-Path: Received: from bertha.pyramid.com (bertha.pyramid.com [129.214.1.100]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 15 Dec 1995 03:18:41 +0100 Received: from stealth.eng.pyramid.com by bertha.pyramid.com (5.67/OSx5.1a Pyramid-Internet-Gateway) id AA27119; Fri, 15 Dec 95 02:18:08 GMT Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA14392; Fri, 15 Dec 95 02:18:06 GMT From: "Mark Wedel" Message-Id: <9512141818.ZM14390@stealth.eng.pyramid.com> Date: Thu, 14 Dec 1995 18:18:05 -0800 In-Reply-To: Matt Cortes "Re: Misc notes/thoughts." (Dec 14, 11:49am) References: X-Mailer: Z-Mail (3.2.0 06sep94) To: Matt Cortes , GESTIONNAIRE DU Casino Subject: Re: Misc notes/thoughts. Cc: "Michael B. Martin" , crossfire@ifi.uio.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: RO On Dec 14, 11:49am, Matt Cortes wrote: > Subject: Re: Misc notes/thoughts. > > Actually. That is handled quite easily with Netrek. Its true they don't > share player information with other servers (I'll work on them soon too > ), but they let people write their own clients, and there are clients > that are made for the purpose of cheating, called Borg Clients. Anyway, > we then have what is called RSA Blessed clients and servers. Basicly you > can make all the clients you want, and run them on servers that don't > insist on Blessed clients. But if you want to make a client to run on > all servers, the code needs to be approved, etc. What I'm purposing here > is that each player file be encrypted with a server key. If I go and > play on your server, then later I want to move to another server, say > popular.edu, it will read my player file, find a server key that is not > in its list of keys, and refuse my player file. Basicly, each server has > a list of keys they accept and/or don't accept (whatever the owner of the > server wants) and it'll check for that key in the player file. From that > point maybe we could go a step further and the server that now approves > of this player file sends it its server key, and so forth. SO then if I > move to popular2.edu which also doesn't support your server, so it > refuses the first key listed, it does support popular.edu's key and lets > me play, as well as writes its key to the player file. > > SO um.. still sound stupid? :> > > -Matt > >-- End of excerpt from Matt Cortes As I previously said, the client/server model for crossfire was designed with the assumption that clients are not secure - thus no extra information other than the player should know about will be sent to the client. I do not ever expect to see this change - it has already been designed and implemented this way, and I really doubt we will re-write it in any fashion. Also, it seems that having blessed clients actually hurts expandibility. If a Java client is done, can you ever really make it secure? Likewise, it means that clients for all machines must be compiled by a secure person and stored in some place. But mainly, I fail to see any good reason why crossfire client should really be sent non known data. And as previously said, in the crossfire player file you often have lots of information that the player does not know about. Is the same true with netrek save files? -- --Mark From crossfire-request Thu Dec 14 05:55:30 1995 Return-Path: Received: from kultarr.cit.gu.edu.au ([132.234.42.2]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Thu, 14 Dec 1995 05:55:22 +0100 Received: by kultarr.cit.gu.edu.au id AA21491 (5.67b/IDA-1.5 for crossfire@ifi.uio.no); Thu, 14 Dec 1995 14:54:17 -1000 From: Karl Hagen Geppert Message-Id: <199512150054.AA21491@kultarr.cit.gu.edu.au> Subject: Enchanting weapons To: crossfire@ifi.uio.no Date: Thu, 14 Dec 1995 14:54:16 -1000 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1107 Status: RO G'day, We've been playing on a 0.92.1 server for a few weeks, and find great trouble with trying to use enchanted weapons. Weapons that were usable in 0.92 server now are rendered unusable with the message 'this weapon is too powerful'. We have had characters go from level 20 to level 60 with significant increases in power statistics, and they are still not able to use a weapon that has been enchanted only a few times. Is this deliberate or merely a miscalculation of stat's somewhere along the line? Also, if you enchant a weapon that you are wielding, there appears to be no checking done on the power of the weapon. You can enchant your wielded blade to blazes (so to speak (and did someone say vorpal)), but if you unwield the weapon, it will not allow you to pick it up again. Should you be forced to unwield the weapon once it becomes too powerful? If so, could we please have some warning messages or a skill or something that lets us know when it is going to be too powerful. This would save spendin unecessary amounts of platinum on our deux ex machinas (sic) Karl karlg@cit.gu.edu.au From crossfire-request Thu Dec 14 19:32:28 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 14 Dec 1995 19:32:27 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id NAA02801; Thu, 14 Dec 1995 13:32:19 -0500 Date: Thu, 14 Dec 1995 13:32:19 -0500 From: Brian Thomas Message-Id: <199512141832.NAA02801@chaupher.gsfc.nasa.gov> To: thomas@chaupher.gsfc.nasa.gov, link@alpha.pulsar.net Subject: Re: reading books, another idea I am working on Cc: crossfire@ifi.uio.no Status: RO > From: Matt Cortes writes: > > Slightly off topic here, but.. > I'm wondering how hard it would be to say.. choose a religon? Make > strict rules for clerics once they choose a god to worship. The > advantage is random favors from the god based on how faithful the cleric > has been. Do simple things like Elemental gods, Demon gods, etc. Cleric > studies the arts, practices etc for the god of his choose, as he advances > he gains the strengths and weakness of such practices. For example, > studing under the Fire God increases his ability with fire, but makes him > weaker toward cold, etc. Something like this should be done for all > types of characters by the way.. Make spells more intense, likely to > succeed, harmful, as the players level raises (reads more books on type > of spell ). > Hmm. Well, all of this is already possible with the MULTIGOD option! > > > Susequent Idea -- modification of the writing skill. > > What the heck is the writing skill and stylus pen used for now anyway?? > You can use it to "overwrite" magical scrolls with spells that you know. In this way, it is easy to keep a few "cure confusion" scrolls (or whatever you find useful) around. > > I would like to propose that the writing skill be expanded to > > allow players to write messages/keep notes in "books". This > > would be (err, actually, "is") very easy to do. > > That would be a great idea. You should see how much notes I have over > here on my desk just for crossfire. :> > Make a buyable item (Diary) to do things like this I guess. Yeah. I though that the player aught to be able to write in *any* non-magical book, even the ones you find on the maps. Anything a player writes would be appended to the end of the previous message. Pretty easy to code this. > Also maybe a "note paper" item for small "Link was here first!!" > messages, etc. :> > This brings up a "tangential" idea I had. For those of you out there who played "nethack", remember the "magic marker"? I thought I might make something like that. It would allow the player to inscribe a permanent message on the floor/wall/etc. The way to code this would be to create a invisible, unique "talk" object where the player was standing. In this way, even though the map had been re-loaded, the players message would still be there to be read. The only problems I see w/ this are the 1) stability of the unique objects code and 2) the number of unique messages that might build up over time. Will this cause problems? > > Susequent Idea -- modification of the literacy skill. > > > > I would like to further propose that the literacy skill be modified. > > Why allow players to read books if they arent literate! Ditto > > for spellbooks. > > > > I would further propose that reading skill be adopted. If a > > player's literacy level is less than the level of the book (I > > wont explain how that's assigned) and/or the level of the > > spell/prayer in the book, then they get the "gibberish" message. > > Thats pretty much already doing that if a player buys/gets a spellbook > thats higher then his level and he tries to read it. > Right, but that's the point. Replace the old system w/ this one. > > Allow a nominal amound of xp to be awarded for translation of > > a book (based on the readers level and the level of the book of > > course). > > Or, why not make different xp catagories? Pysical, Mental, etc. That > would open up a whole new world of stuff, then have seperate levels as well. > In AD&D you can be a fighter/mage/thief, etc. Maybe we can implement > something like that and have xp awarded to each catagory depending on > what acts we do? > Take a look at the skills system... are you playing 0.92.1? Enable the ALLOW_SKILLS code and you will find all of this (more or less) already exists. :) -b.t. From crossfire-request Thu Dec 14 19:16:43 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 14 Dec 1995 19:16:41 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id NAA02795; Thu, 14 Dec 1995 13:16:24 -0500 Date: Thu, 14 Dec 1995 13:16:24 -0500 From: Brian Thomas Message-Id: <199512141816.NAA02795@chaupher.gsfc.nasa.gov> To: thomas@chaupher.gsfc.nasa.gov, Tero.Haatanen@tel.vtt.fi Subject: Re: reading books Cc: crossfire@ifi.uio.no Status: RO > From: Tero Haatanen writes: > > > -> "Bibles" -- properties/characteristics of a God/religon > > I haven't looked a new god code, but maybe there should be temples > somewhere? > Yeah. I put a few down on my maps. But temples arent needed per se to use the MULTIGOD code. Still, temples may not provide information to the players, and more importantly, will be map-dependant. That is to say, if a particular server maintainer decided to make a new god, there wouldnt necessiarily be a temple for them, so how does the player learn about the new god then? That is one purpose of the books. > > -> Random information drawn from a file in lib/. > > If you mean something like nethack rumors, then this might be interesting > idea. > Definitely. I plan to provide a starting file with 10-20 "pieces" of information that can be added to. > > parts of this code between now and christmas. Ideas/comments? > > I really don't know how you are going to implement these, but I think > that it should not require any new code, just making book archetypes > and fix a treasure file. This allow all normal object attributes > used with these book. That random information part probably could > be read from a separate file, if that seems a best choice. > Oh, I think you read my mind (mostly). The majority of the hack will involve common/treasures.c with the rest involving apply.c (unpaid books shouldnt be readable!) and skills.c (modification to writing, literacy?). No new archetypes (or object TYPE) is actually needed to implement the books. I wonder if it would be worthwhile to modify maps.c so that empty books on newly loaded maps have a chance of being filled with information too? b.t. > -Tero > > > > From crossfire-request Thu Dec 14 18:30:43 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 14 Dec 1995 18:30:37 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id MAA14629; Thu, 14 Dec 1995 12:31:01 -0500 Date: Thu, 14 Dec 1995 12:31:01 -0500 (EST) From: Matt Cortes To: Brian Thomas cc: crossfire@ifi.uio.no Subject: Re: reading books, another idea I am working on In-Reply-To: <199512131933.OAA02060@chaupher.gsfc.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 13 Dec 1995, Brian Thomas wrote: > I would like to passby everyone an idea that I am > working on -- development of the "READABLE" hack. > > Because I expect some of the idea will be controversial > I have segmented it into parts of increasingly acceptablity. > (I, of course, think its all reasonable :). First off, let me tell you I think everything listed here is a great idea and all quite reasonable too! Let me go through each one if I may... > Main Idea -- books for players > > One thing, I think, that will go a long way to improving th e > atmosphere of the game is to create code that will support the > development of non-magical reading material, which for lack of > a better (singular) word I will refer to as "books". There are already a bunch of books on the map, mostly empty though when you go to read them. And as well as scrolls that I've found with clues to quests in the game, etc. > As of the current code, the only non-magical books are those > specifically created on maps. Why not have several types of > (general and specific) information be available in shops and/or > monster treasure hoards? Examples of things that I would > put into books: > > -> Compendiums on monsters/racial groups. Their powers/abilities > and how to kill them. I don't know if anyone has ever played it. But there was an old game on the Sega Genesis called Fatal Labrynth. It was a random RPG game, each time you go through it, it was different here and there.. its actually alot like crossfire in a few ways. Anyway, it had a feature I thought was pretty neat. Each time you killed a specific creature, say blue slime.. You would gain in knowledge on how that creature reacts, etc. I'm thinking maybe we could add the ability to have knowledge on each creature's moves, attacks, etc. The more knowledge you have on the creature, the better modifiers you get on Dex, Str, Int, etc for each move you do against that creature. These books you purpose could also increase the players knowledge the first time the book is read for each of the creatures in there, then the book could be refered to later on for things such as best protection spells/items to use, best spells, weaknesses, max HP, etc for each creature listed in that book. > -> Compendiums of spells/prayers in a given level. Rare spells > (bookchance==0) might have a chance of appearing. > -> "Bibles" -- properties/characteristics of a God/religon Slightly off topic here, but.. I'm wondering how hard it would be to say.. choose a religon? Make strict rules for clerics once they choose a god to worship. The advantage is random favors from the god based on how faithful the cleric has been. Do simple things like Elemental gods, Demon gods, etc. Cleric studies the arts, practices etc for the god of his choose, as he advances he gains the strengths and weakness of such practices. For example, studing under the Fire God increases his ability with fire, but makes him weaker toward cold, etc. Something like this should be done for all types of characters by the way.. Make spells more intense, likely to succeed, harmful, as the players level raises (reads more books on type of spell ). > -> Compendiums explaining the powers of 2-3 artifacts I definitly need this one. :> > -> Random information drawn from a file in lib/. This would > give mapmakers an easy way to make "teaser" info available > in areas outside of their own maps! Plus server specific info > could easily be made available here too. Thats cruel. But it made me think of an idea. (just deleted it though once I read it and found my idea to be really retarded. :>) > Clearly some of this information is already available in the spoiler. > But, with the ability of a given server maintainer to have different > archetypes/gods/spells/etc, the spoiler can sometimes be useless. A > vehicle through which to impart *server specific* information is also > needed. But that wouldnt even be the main value of such a system, > the enchancement to the atmosphere of the game (I think) is the main > point. Good points. And instead of having to write new books per server, why not make the books call upon the different variables set for each server? Example: The Dread's weaknesses are , his max hitpts is . > Susequent Idea -- modification of the writing skill. What the heck is the writing skill and stylus pen used for now anyway?? > I would like to propose that the writing skill be expanded to > allow players to write messages/keep notes in "books". This > would be (err, actually, "is") very easy to do. That would be a great idea. You should see how much notes I have over here on my desk just for crossfire. :> Make a buyable item (Diary) to do things like this I guess. Also maybe a "note paper" item for small "Link was here first!!" messages, etc. :> > Susequent Idea -- modification of the literacy skill. > > I would like to further propose that the literacy skill be modified. > Why allow players to read books if they arent literate! Ditto > for spellbooks. > > I would further propose that reading skill be adopted. If a > player's literacy level is less than the level of the book (I > wont explain how that's assigned) and/or the level of the > spell/prayer in the book, then they get the "gibberish" message. Thats pretty much already doing that if a player buys/gets a spellbook thats higher then his level and he tries to read it. > Allow a nominal amound of xp to be awarded for translation of > a book (based on the readers level and the level of the book of > course). Or, why not make different xp catagories? Pysical, Mental, etc. That would open up a whole new world of stuff, then have seperate levels as well. In AD&D you can be a fighter/mage/thief, etc. Maybe we can implement something like that and have xp awarded to each catagory depending on what acts we do? -Matt (Just throwing out ideas, may not like them.. But if there is one ya like, hey.. Wasn't it worth it? :>) From crossfire-request Thu Dec 14 17:49:25 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 14 Dec 1995 17:49:22 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id LAA14504; Thu, 14 Dec 1995 11:49:39 -0500 Date: Thu, 14 Dec 1995 11:49:39 -0500 (EST) From: Matt Cortes To: GESTIONNAIRE DU Casino cc: "Michael B. Martin" , crossfire@ifi.uio.no Subject: Re: Misc notes/thoughts. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 13 Dec 1995, GESTIONNAIRE DU Casino wrote: > On Mon, 11 Dec 1995, Tadah wrote: > > > ATTENTION all programmers.. Idea here.. :> > > Why not have encrypted RSA player files kept on the players computer? > > Netrek does something like this with its clients so that people can't mod > > clients and cheat. Why not do this with player files, and to what > > advantage? It would be great to be able to move your player to other > > servers should a server go down, become slow, or whatever. No? > > Well, anyway. Just an idea.. :> > > No no no... It would be too easy to cheat. Imagine : I install a server > on my machine, and create a map with free armor/spells/money/etc. I get a > munchkin character, then move it to the ultra-strict server where you > play, and bash everythng about... Actually. That is handled quite easily with Netrek. Its true they don't share player information with other servers (I'll work on them soon too ), but they let people write their own clients, and there are clients that are made for the purpose of cheating, called Borg Clients. Anyway, we then have what is called RSA Blessed clients and servers. Basicly you can make all the clients you want, and run them on servers that don't insist on Blessed clients. But if you want to make a client to run on all servers, the code needs to be approved, etc. What I'm purposing here is that each player file be encrypted with a server key. If I go and play on your server, then later I want to move to another server, say popular.edu, it will read my player file, find a server key that is not in its list of keys, and refuse my player file. Basicly, each server has a list of keys they accept and/or don't accept (whatever the owner of the server wants) and it'll check for that key in the player file. From that point maybe we could go a step further and the server that now approves of this player file sends it its server key, and so forth. SO then if I move to popular2.edu which also doesn't support your server, so it refuses the first key listed, it does support popular.edu's key and lets me play, as well as writes its key to the player file. SO um.. still sound stupid? :> -Matt From owner-crossfire Thu Dec 14 17:47:31 1995 Return-Path: Received: from jedi.cis.temple.edu (awrobel@jedi.cis.temple.edu [155.247.207.70]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 14 Dec 1995 17:47:27 +0100 Received: (from awrobel@localhost) by jedi.cis.temple.edu (8.6.12/8.6.12) id LAA12903; Thu, 14 Dec 1995 11:45:13 -0500 Date: Thu, 14 Dec 1995 11:45:13 -0500 (EST) From: Phoenix To: crossfire-bugs@ifi.uio.no Subject: Problem compiling crossfire Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-874846392-818959513=:11826" Status: RO This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-874846392-818959513=:11826 Content-Type: TEXT/PLAIN; charset=US-ASCII I am currently trying to compile Crossfire 0.92.1 on a Sun Sparc 10 running SunOS 4.1.3 with X11R6 windowing system using GCC version 2.7.2 compiler. I have attached the Imakefile and the resulting Makefile after I did xmkmf. After I did the xmkmf, I typed make Makefiles and the error that I go was: Makefile:577: *** missing `endef', unterminated `define'. Stop. I know my way around makefiles, like what to add and delete, but I've never gotten this error before. So I am at a loss. Any help or suggestions would be appreciated. Thank You Andrew Wrobel awrobel@jedi.cis.temple.edu --0-874846392-818959513=:11826 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=Makefile Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: IyBNYWtlZmlsZSBnZW5lcmF0ZWQgYnkgaW1ha2UgLSBkbyBub3QgZWRpdCEN CiMgJFhDb25zb3J0aXVtOiBpbWFrZS5jLHYgMS42NSA5MS8wNy8yNSAxNzo1 MDoxNyByd3MgRXhwICQNCiMNCiMgVGhlIGNwcCB1c2VkIG9uIHRoaXMgbWFj aGluZSByZXBsYWNlcyBhbGwgbmV3bGluZXMgYW5kIG11bHRpcGxlIHRhYnMg YW5kDQojIHNwYWNlcyBpbiBhIG1hY3JvIGV4cGFuc2lvbiB3aXRoIGEgc2lu Z2xlIHNwYWNlLiAgSW1ha2UgdHJpZXMgdG8gY29tcGVuc2F0ZQ0KIyBmb3Ig dGhpcywgYnV0IGlzIG5vdCBhbHdheXMgc3VjY2Vzc2Z1bC4NCiMNCg0KIyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQojIE1ha2VmaWxlIGdlbmVy YXRlZCBmcm9tICJJbWFrZS50bXBsIiBhbmQgPEltYWtlZmlsZT4NCiMgJFhD b25zb3J0aXVtOiBJbWFrZS50bXBsLHYgMS4xMzkgOTEvMDkvMTYgMDg6NTI6 NDggcndzIEV4cCAkDQojDQojIFBsYXRmb3JtLXNwZWNpZmljIHBhcmFtZXRl cnMgbWF5IGJlIHNldCBpbiB0aGUgYXBwcm9wcmlhdGUgPHZlbmRvcj4uY2YN CiMgY29uZmlndXJhdGlvbiBmaWxlcy4gIFNpdGUtc3BlY2lmaWMgcGFyYW1l dGVycyBzaG91bGQgYmUgc2V0IGluIHRoZSBmaWxlDQojIHNpdGUuZGVmLiAg RnVsbCByZWJ1aWxkcyBhcmUgcmVjb21tZW5kZWQgaWYgYW55IHBhcmFtZXRl cnMgYXJlIGNoYW5nZWQuDQojDQojIElmIHlvdXIgQyBwcmVwcm9jZXNzb3Ig ZG9lcyBub3QgZGVmaW5lIGFueSB1bmlxdWUgc3ltYm9scywgeW91IHdpbGwg bmVlZA0KIyB0byBzZXQgQk9PVFNUUkFQQ0ZMQUdTIHdoZW4gcmVidWlsZGlu ZyBpbWFrZSAodXN1YWxseSB3aGVuIGRvaW5nDQojICJtYWtlIFdvcmxkIiB0 aGUgZmlyc3QgdGltZSkuDQojDQoNCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KIyBzaXRlLXNwZWNpZmljIGNvbmZpZ3VyYXRpb24gcGFyYW1l dGVycyB0aGF0IG5lZWQgdG8gY29tZSBiZWZvcmUNCiMgdGhlIHBsYXRmb3Jt LXNwZWNpZmljIHBhcmFtZXRlcnMgLSBlZGl0IHNpdGUuZGVmIHRvIGNoYW5n ZQ0KDQojIHNpdGU6ICAkWENvbnNvcnRpdW06IHNpdGUuZGVmLHYgMS4yIDkx LzA3LzMwIDIwOjI2OjQ0IHJ3cyBFeHAgJA0KDQojIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiMgcGxhdGZvcm0tc3BlY2lmaWMgY29uZmlndXJh dGlvbiBwYXJhbWV0ZXJzIC0gZWRpdCBzdW4uY2YgdG8gY2hhbmdlDQoNCiMg cGxhdGZvcm06ICAkWENvbnNvcnRpdW06IHN1bi5jZix2IDEuNjggOTEvMDcv MzAgMTE6MzQ6MzkgcndzIEV4cCAkDQoNCiMgb3BlcmF0aW5nIHN5c3RlbTog IFN1bk9TIDQuMS4zDQoNCiMgJFhDb25zb3J0aXVtOiBzdW5MaWIucnVsZXMs diAxLjcgOTEvMTIvMjAgMTE6MTk6NDcgcndzIEV4cCAkDQoNCiMgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIyBzaXRlLXNwZWNpZmljIGNvbmZp Z3VyYXRpb24gcGFyYW1ldGVycyB0aGF0IGdvIGFmdGVyDQojIHRoZSBwbGF0 Zm9ybS1zcGVjaWZpYyBwYXJhbWV0ZXJzIC0gZWRpdCBzaXRlLmRlZiB0byBj aGFuZ2UNCg0KIyBzaXRlOiAgJFhDb25zb3J0aXVtOiBzaXRlLmRlZix2IDEu MiA5MS8wNy8zMCAyMDoyNjo0NCByd3MgRXhwICQNCg0KICAgICAgICAgICAg U0hFTEwgPSAvYmluL3NoDQoNCiAgICAgICAgICAgICAgVE9QID0gLg0KICAg ICAgQ1VSUkVOVF9ESVIgPSAuDQoNCiAgICAgICAgICAgICAgIEFSID0gYXIg Y2xxDQogIEJPT1RTVFJBUENGTEFHUyA9DQogICAgICAgICAgICAgICBDQyA9 IGdjYw0KICAgICAgICAgICAgICAgQVMgPSBhcw0KDQogICAgICAgICBDT01Q UkVTUyA9IGNvbXByZXNzDQogICAgICAgICAgICAgIENQUCA9IC9saWIvY3Bw ICQoU1REX0NQUF9ERUZJTkVTKQ0KICAgIFBSRVBST0NFU1NDTUQgPSBjYyAt RSAkKFNURF9DUFBfREVGSU5FUykNCiAgICAgICAgICBJTlNUQUxMID0gaW5z dGFsbA0KICAgICAgICAgICAgICAgTEQgPSBsZA0KICAgICAgICAgICAgIExJ TlQgPSBsaW50DQogICAgICBMSU5UTElCRkxBRyA9IC1DDQogICAgICAgICBM SU5UT1BUUyA9IC1heHoNCiAgICAgICAgICAgICAgIExOID0gbG4gLXMNCiAg ICAgICAgICAgICBNQUtFID0gbWFrZQ0KICAgICAgICAgICAgICAgTVYgPSBt dg0KICAgICAgICAgICAgICAgQ1AgPSBjcA0KDQogICAgICAgICAgIFJBTkxJ QiA9IHJhbmxpYg0KICBSQU5MSUJJTlNURkxBR1MgPQ0KDQogICAgICAgICAg ICAgICBSTSA9IHJtIC1mDQogICAgICAgICAgICBUUk9GRiA9IHBzcm9mZg0K ICAgICAgICAgTVNNQUNST1MgPSAtbXMNCiAgICAgICAgICAgICAgVEJMID0g dGJsDQogICAgICAgICAgICAgIEVRTiA9IGVxbg0KICAgICBTVERfSU5DTFVE RVMgPQ0KICBTVERfQ1BQX0RFRklORVMgPQ0KICAgICAgU1REX0RFRklORVMg PQ0KIEVYVFJBX0xPQURfRkxBR1MgPQ0KICBFWFRSQV9MSUJSQVJJRVMgPQ0K ICAgICAgICAgICAgIFRBR1MgPSBjdGFncw0KDQogICAgU0hBUkVEQ09ERURF RiA9IC1EU0hBUkVEQ09ERQ0KICAgICAgICAgU0hMSUJERUYgPSAtRFNVTlNI TElCDQoNCiAgICBQUk9UT19ERUZJTkVTID0NCg0KICAgICBJTlNUUEdNRkxB R1MgPQ0KDQogICAgIElOU1RCSU5GTEFHUyA9IC1tIDA3NTUNCiAgICAgSU5T VFVJREZMQUdTID0gLW0gNDc1NQ0KICAgICBJTlNUTElCRkxBR1MgPSAtbSAw NjQ0DQogICAgIElOU1RJTkNGTEFHUyA9IC1tIDA0NDQNCiAgICAgSU5TVE1B TkZMQUdTID0gLW0gMDQ0NA0KICAgICBJTlNUREFURkxBR1MgPSAtbSAwNDQ0 DQogICAgSU5TVEtNRU1GTEFHUyA9IC1nIGttZW0gLW0gMjc1NQ0KDQogICAg ICBQUk9KRUNUUk9PVCA9IC91c3IvbG9jYWwNCg0KICAgICBUT1BfSU5DTFVE RVMgPSAtSSQoSU5DUk9PVCkNCg0KICAgICAgQ0RFQlVHRkxBR1MgPSAtTzIN CiAgICAgICAgQ0NPUFRJT05TID0gLXBpcGUNCg0KICAgICAgQUxMSU5DTFVE RVMgPSAkKElOQ0xVREVTKSAkKEVYVFJBX0lOQ0xVREVTKSAkKFRPUF9JTkNM VURFUykgJChTVERfSU5DTFVERVMpDQogICAgICAgQUxMREVGSU5FUyA9ICQo QUxMSU5DTFVERVMpICQoU1REX0RFRklORVMpICQoRVhUUkFfREVGSU5FUykg JChQUk9UT19ERUZJTkVTKSAkKERFRklORVMpDQogICAgICAgICAgIENGTEFH UyA9ICQoQ0RFQlVHRkxBR1MpICQoQ0NPUFRJT05TKSAkKEFMTERFRklORVMp DQogICAgICAgIExJTlRGTEFHUyA9ICQoTElOVE9QVFMpIC1ETElOVCAkKEFM TERFRklORVMpDQoNCiAgICAgICAgICAgTERMSUJTID0gJChTWVNfTElCUkFS SUVTKSAkKEVYVFJBX0xJQlJBUklFUykNCg0KICAgICAgICBMRE9QVElPTlMg PSAkKENERUJVR0ZMQUdTKSAkKENDT1BUSU9OUykgJChMT0NBTF9MREZMQUdT KSAtTCQoVVNSTElCRElSKQ0KDQogICBMRENPTUJJTkVGTEFHUyA9IC1YIC1y DQogICAgICBERVBFTkRGTEFHUyA9DQoNCiAgICAgICAgTUFDUk9GSUxFID0g c3VuLmNmDQogICAgICAgICAgIFJNX0NNRCA9ICQoUk0pICouQ0tQICoubG4g Ki5CQUsgKi5iYWsgKi5vIGNvcmUgZXJycyAsKiAqfiAqLmEgLmVtYWNzXyog dGFncyBUQUdTIG1ha2UubG9nIE1ha2VPdXQNCg0KICAgIElNQUtFX0RFRklO RVMgPQ0KDQogICAgICAgICBJUlVMRVNSQyA9ICQoQ09ORklHRElSKQ0KICAg ICAgICBJTUFLRV9DTUQgPSAkKElNQUtFKSAtRFVzZUluc3RhbGxlZCAtSSQo SVJVTEVTUkMpICQoSU1BS0VfREVGSU5FUykNCg0KICAgICBJQ09ORklHRklM RVMgPSAkKElSVUxFU1JDKS9JbWFrZS50bXBsICQoSVJVTEVTUkMpL0ltYWtl LnJ1bGVzIFwNCgkJCSQoSVJVTEVTUkMpL1Byb2plY3QudG1wbCAkKElSVUxF U1JDKS9zaXRlLmRlZiBcDQoJCQkkKElSVUxFU1JDKS8kKE1BQ1JPRklMRSkg JChFWFRSQV9JQ09ORklHRklMRVMpDQoNCiMgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KIyBYIFdpbmRvdyBTeXN0ZW0gQnVpbGQgUGFyYW1ldGVy cw0KIyAkWENvbnNvcnRpdW06IFByb2plY3QudG1wbCx2IDEuMTM4LjEuMSA5 Mi8xMS8xMSAwOTo0OToxOSByd3MgRXhwICQNCg0KIyAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQojIFggV2luZG93IFN5c3RlbSBtYWtlIHZhcmlh YmxlczsgdGhpcyBuZWVkIHRvIGJlIGNvb3JkaW5hdGVkIHdpdGggcnVsZXMN Cg0KICAgICAgICAgIFBBVEhTRVAgPSAvDQogICAgICAgIFVTUkxJQkRJUiA9 IC91c3IvbG9jYWwvbGliDQogICAgICAgICAgIEJJTkRJUiA9IC9ob21lL3lv ZGEvYXdyb2JlbC9iaW4NCiAgICAgICAgICBJTkNST09UID0gL3Vzci9sb2Nh bC9pbmNsdWRlDQogICAgIEJVSUxESU5DUk9PVCA9ICQoVE9QKQ0KICAgICAg QlVJTERJTkNESVIgPSAkKEJVSUxESU5DUk9PVCkvWDExDQogICAgICBCVUlM RElOQ1RPUCA9IC4uDQogICAgICAgICAgIElOQ0RJUiA9ICQoSU5DUk9PVCkv WDExDQogICAgICAgICAgIEFETURJUiA9IC91c3IvYWRtDQogICAgICAgICAg IExJQkRJUiA9ICQoVVNSTElCRElSKS9YMTENCiAgICAgICAgQ09ORklHRElS ID0gJChMSUJESVIpL2NvbmZpZw0KICAgICAgIExJTlRMSUJESVIgPSAkKFVT UkxJQkRJUikvbGludA0KDQogICAgICAgICAgRk9OVERJUiA9ICQoTElCRElS KS9mb250cw0KICAgICAgICAgWElOSVRESVIgPSAkKExJQkRJUikveGluaXQN CiAgICAgICAgICAgWERNRElSID0gJChMSUJESVIpL3hkbQ0KICAgICAgICAg ICBUV01ESVIgPSAkKExJQkRJUikvdHdtDQogICAgICAgICAgTUFOUEFUSCA9 IC9ob21lL3lvZGEvYXdyb2JlbC9tYW4NCiAgICBNQU5TT1VSQ0VQQVRIID0g JChNQU5QQVRIKS9tYW4NCiAgICAgICAgTUFOU1VGRklYID0gMQ0KICAgICBM SUJNQU5TVUZGSVggPSAzDQogICAgICAgICAgIE1BTkRJUiA9ICQoTUFOU09V UkNFUEFUSCkkKE1BTlNVRkZJWCkNCiAgICAgICAgTElCTUFORElSID0gJChN QU5TT1VSQ0VQQVRIKSQoTElCTUFOU1VGRklYKQ0KICAgICAgICAgICBOTFNE SVIgPSAkKExJQkRJUikvbmxzDQogICAgICAgIFBFWEFQSURJUiA9ICQoTElC RElSKS9QRVgNCiAgICAgIFhBUFBMT0FERElSID0gJChMSUJESVIpL2FwcC1k ZWZhdWx0cw0KICAgICAgIEZPTlRDRkxBR1MgPSAtdA0KDQogICAgIElOU1RB UFBGTEFHUyA9ICQoSU5TVERBVEZMQUdTKQ0KDQogICAgICAgICAgICBJTUFL RSA9IGltYWtlDQogICAgICAgICAgIERFUEVORCA9IG1ha2VkZXBlbmQNCiAg ICAgICAgICAgICAgUkdCID0gcmdiDQoNCiAgICAgICAgICAgIEZPTlRDID0g YmRmdG9wY2YNCg0KICAgICAgICBNS0ZPTlRESVIgPSAvdXNyL2xvY2FsL2Jp bi9ta2ZvbnRkaXINCiAgICAgICAgTUtESVJISUVSID0gL2Jpbi9zaCAvdXNy L2xvY2FsL2Jpbi9ta2RpcmhpZXINCg0KICAgICAgICBDT05GSUdTUkMgPSAk KFRPUCkvY29uZmlnDQogICAgICAgRE9DVVRJTFNSQyA9ICQoVE9QKS9kb2Mv dXRpbA0KICAgICAgICBDTElFTlRTUkMgPSAkKFRPUCkvY2xpZW50cw0KICAg ICAgICAgIERFTU9TUkMgPSAkKFRPUCkvZGVtb3MNCiAgICAgICAgICAgTElC U1JDID0gJChUT1ApL2xpYg0KICAgICAgICAgIEZPTlRTUkMgPSAkKFRPUCkv Zm9udHMNCiAgICAgICBJTkNMVURFU1JDID0gJChUT1ApL1gxMQ0KICAgICAg ICBTRVJWRVJTUkMgPSAkKFRPUCkvc2VydmVyDQogICAgICAgICAgVVRJTFNS QyA9ICQoVE9QKS91dGlsDQogICAgICAgIFNDUklQVFNSQyA9ICQoVVRJTFNS Qykvc2NyaXB0cw0KICAgICAgIEVYQU1QTEVTUkMgPSAkKFRPUCkvZXhhbXBs ZXMNCiAgICAgICBDT05UUklCU1JDID0gJChUT1ApLy4uL2NvbnRyaWINCiAg ICAgICAgICAgRE9DU1JDID0gJChUT1ApL2RvYw0KICAgICAgICAgICBSR0JT UkMgPSAkKFRPUCkvcmdiDQogICAgICAgIERFUEVORFNSQyA9ICQoVVRJTFNS QykvbWFrZWRlcGVuZA0KICAgICAgICAgSU1BS0VTUkMgPSAkKENPTkZJR1NS QykNCiAgICAgICAgIFhBVVRIU1JDID0gJChMSUJTUkMpL1hhdQ0KICAgICAg ICAgIFhMSUJTUkMgPSAkKExJQlNSQykvWA0KICAgICAgICAgICBYTVVTUkMg PSAkKExJQlNSQykvWG11DQogICAgICAgVE9PTEtJVFNSQyA9ICQoTElCU1JD KS9YdA0KICAgICAgIEFXSURHRVRTUkMgPSAkKExJQlNSQykvWGF3DQogICAg ICAgT0xEWExJQlNSQyA9ICQoTElCU1JDKS9vbGRYDQogICAgICBYRE1DUExJ QlNSQyA9ICQoTElCU1JDKS9YZG1jcA0KICAgICAgQkRGVE9TTkZTUkMgPSAk KEZPTlRTUkMpL2JkZnRvc25mDQogICAgICBCREZUT1NORlNSQyA9ICQoRk9O VFNSQykvY2xpZW50cy9iZGZ0b3NuZg0KICAgICAgQkRGVE9QQ0ZTUkMgPSAk KEZPTlRTUkMpL2NsaWVudHMvYmRmdG9wY2YNCiAgICAgTUtGT05URElSU1JD ID0gJChGT05UU1JDKS9jbGllbnRzL21rZm9udGRpcg0KICAgICAgICAgRlNM SUJTUkMgPSAkKEZPTlRTUkMpL2xpYi9mcw0KICAgIEZPTlRTRVJWRVJTUkMg PSAkKEZPTlRTUkMpL3NlcnZlcg0KICAgICBFWFRFTlNJT05TUkMgPSAkKFRP UCkvZXh0ZW5zaW9ucw0KICAgICAgICAgWElMSUJTUkMgPSAkKEVYVEVOU0lP TlNSQykvbGliL3hpbnB1dA0KICAgICAgICBQRVhMSUJTUkMgPSAkKEVYVEVO U0lPTlNSQykvbGliL1BFWGxpYg0KICAgICAgUEhJR1NMSUJTUkMgPSAkKEVY VEVOU0lPTlNSQykvbGliL1BFWA0KDQojICRYQ29uc29ydGl1bTogc3VuTGli LnRtcGwsdiAxLjE0LjEuMiA5Mi8xMS8xMSAwOTo1NTowMiByd3MgRXhwICQN Cg0KU0hMSUJMREZMQUdTID0gLWFzc2VydCBwdXJlLXRleHQNClBJQ0ZMQUdT ID0gLXBpYw0KDQogIERFUEVYVEVOU0lPTkxJQiA9DQogICAgIEVYVEVOU0lP TkxJQiA9IC1sWGV4dA0KDQogICAgICAgICAgREVQWExJQiA9ICQoREVQRVhU RU5TSU9OTElCKQ0KICAgICAgICAgICAgIFhMSUIgPSAkKEVYVEVOU0lPTkxJ QikgLWxYMTENCg0KICAgICAgICBERVBYTVVMSUIgPSAkKFVTUkxJQkRJUikv bGliWG11LnNhLiQoU09YTVVSRVYpDQogICAgICAgWE1VTElCT05MWSA9IC1s WG11DQogICAgICAgICAgIFhNVUxJQiA9IC1sWG11DQoNCiAgICAgICBERVBP TERYTElCID0NCiAgICAgICAgICBPTERYTElCID0gLWxvbGRYDQoNCiAgICAg IERFUFhUT09MTElCID0gJChVU1JMSUJESVIpL2xpYlh0LnNhLiQoU09YVFJF VikNCiAgICAgICAgIFhUT09MTElCID0gLWxYdA0KDQogICAgICAgIERFUFhB V0xJQiA9ICQoVVNSTElCRElSKS9saWJYYXcuc2EuJChTT1hBV1JFVikNCiAg ICAgICAgICAgWEFXTElCID0gLWxYYXcNCg0KICAgICAgICBERVBYSUxJQiA9 DQogICAgICAgICAgIFhJTElCID0gLWxYaQ0KDQogICAgICAgIERFUFBFWExJ QiA9DQogICAgICAgICAgIFBFWExJQiA9IC1sUEVYNQ0KDQogICAgICAgIFNP WExJQlJFViA9IDQuMTANCiAgICAgICAgICBTT1hUUkVWID0gNC4xMA0KICAg ICAgICAgU09YQVdSRVYgPSA1LjANCiAgICAgICAgU09PTERYUkVWID0gNC4x MA0KICAgICAgICAgU09YTVVSRVYgPSA0LjEwDQogICAgICAgIFNPWEVYVFJF ViA9IDQuMTANCiAgICAgIFNPWElOUFVUUkVWID0gNC4xMA0KICAgICAgICAg U09QRVhSRVYgPSAxLjANCg0KICAgICAgREVQWEFVVEhMSUIgPSAkKFVTUkxJ QkRJUikvbGliWGF1LmENCiAgICAgICAgIFhBVVRITElCID0gIC1sWGF1DQog ICAgICBERVBYRE1DUExJQiA9ICQoVVNSTElCRElSKS9saWJYZG1jcC5hDQog ICAgICAgICBYRE1DUExJQiA9ICAtbFhkbWNwDQoNCiAgICAgICAgREVQUEhJ R1NMSUIgPSAkKFVTUkxJQkRJUikvbGlicGhpZ3MuYQ0KICAgICAgICAgICBQ SElHU0xJQiA9ICAtbHBoaWdzDQoNCiAgICAgICBERVBYQlNETElCID0gJChV U1JMSUJESVIpL2xpYlhic2QuYQ0KICAgICAgICAgIFhCU0RMSUIgPSAgLWxY YnNkDQoNCiBMSU5URVhURU5TSU9OTElCID0gJChMSU5UTElCRElSKS9sbGli LWxYZXh0LmxuDQogICAgICAgICBMSU5UWExJQiA9ICQoTElOVExJQkRJUikv bGxpYi1sWDExLmxuDQogICAgICAgICAgTElOVFhNVSA9ICQoTElOVExJQkRJ UikvbGxpYi1sWG11LmxuDQogICAgICAgIExJTlRYVE9PTCA9ICQoTElOVExJ QkRJUikvbGxpYi1sWHQubG4NCiAgICAgICAgICBMSU5UWEFXID0gJChMSU5U TElCRElSKS9sbGliLWxYYXcubG4NCiAgICAgICAgICAgTElOVFhJID0gJChM SU5UTElCRElSKS9sbGliLWxYaS5sbg0KICAgICAgICAgIExJTlRQRVggPSAk KExJTlRMSUJESVIpL2xsaWItbFBFWDUubG4NCiAgICAgICAgTElOVFBISUdT ID0gJChMSU5UTElCRElSKS9sbGliLWxwaGlncy5sbg0KDQogICAgICAgICAg REVQTElCUyA9ICQoREVQWEFXTElCKSAkKERFUFhNVUxJQikgJChERVBYVE9P TExJQikgJChERVBYTElCKQ0KDQogICAgICAgICBERVBMSUJTMSA9ICQoREVQ TElCUykNCiAgICAgICAgIERFUExJQlMyID0gJChERVBMSUJTKQ0KICAgICAg ICAgREVQTElCUzMgPSAkKERFUExJQlMpDQoNCiMgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KIyBJbWFrZSBydWxlcyBmb3IgYnVpbGRpbmcgbGli cmFyaWVzLCBwcm9ncmFtcywgc2NyaXB0cywgYW5kIGRhdGEgZmlsZXMNCiMg cnVsZXM6ICAkWENvbnNvcnRpdW06IEltYWtlLnJ1bGVzLHYgMS4xMjMgOTEv MDkvMTYgMjA6MTI6MTYgcndzIEV4cCAkDQoNCiMgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KIyBzdGFydCBvZiBJbWFrZWZpbGUNCg0KSU1BS0Vf REVGSU5FUz0tSSQoTkVXVE9QKS8uLiAtSSQoTkVXVE9QKS9jb25maWcgLUkk KE5FV1RPUCkNCkVYVFJBX0lOQ0xVREVTID0gLUkvaG9tZS95b2RhL2F3cm9i ZWwvaW5jbHVkZQ0KRVhUUkFfTElCUkFSSUVTID0gLUwvaG9tZS95b2RhL2F3 cm9iZWwvbGliDQoNCmRlZmluZSBGb3JjZUNDT1BUSU9OUyAtTzINCg0KQVdL ID0gZ2F3aw0KDQpWRVJTSU9OID0gY3Jvc3NmaXJlLTAuOTIuMQ0KDQpNQU5T VUZGSVggPSA2DQpNQU5QQVRIID0gL3Vzci9sb2NhbC9tYW4NCg0KTUFOUEFU SCA9IC9ob21lL3lvZGEvYXdyb2JlbC9tYW4NCg0KTUFOU1VGRklYID0gNg0K DQpDREVCVUdGTEFHUyA9ICQoREVCVUdGTEFHUykgJChFWFRSQV9GTEFHUykN Cg0KTk9MT05HSlVNUFMgPSAtRExPTkdKVU1QDQoNClNUVVBJRFNVTkhFQURF UlMgPSAtRFN0dXBpZFN1bkhlYWRlcnMNCg0KWFBNX0xJQkRJUiA9IC1ML2hv bWUveW9kYS9hd3JvYmVsL2xpYi8NCg0KWFBNX0RFRklORVMgPSAtRFhwbV9Q aXggLUkvaG9tZS95b2RhL2F3cm9iZWwvaW5jbHVkZQ0KDQpYUE1fTElCUyA9 ICQoWFBNX0xJQkRJUikgLWxYcG0NCg0KRVVUTF9MSUJESVIgPSAtTC9ob21l L3lvZGEvYXdyb2JlbC9saWINCg0KRVVUTF9JTkNMVURFUyA9IC1JL2hvbWUv eW9kYS9hd3JvYmVsL2luY2x1ZGUvZXV0bA0KDQpFVVRMX0xJQlMgPSAkKEVV VExfTElCRElSKSAtbGV1dGwNCkVVVExfREVGSU5FUyA9IC1ERVJJQ19TRVJW RVI9MQ0KDQpFWFRSQV9ERUZJTkVTID0gJChOT0xPTkdKVU1QUykgJChTVFVQ SURTVU5IRUFERVJTKSAkKFhQTV9ERUZJTkVTKSBcDQoJJChNQUxMT0NfREVG SU5FUykgICQoU09VTkRfREVGKSAkKEVVVExfREVGSU5FUykNCg0KQ0MgPSBn Y2MNCg0KQ19CSU5ESVIgPSAvaG9tZS95b2RhL2F3cm9iZWwvYmluDQoNCkNf TElCRElSID0gL2hvbWUveW9kYS9hd3JvYmVsL2xpYg0KDQpBRE1ESVIgPSAk KENfTElCRElSKS9hZG0NCg0KRk9OVERJUiA9IC9ob21lL3lvZGEvYXdyb2Jl bC9saWIvWDExL2ZvbnRzDQoNCkZPTlROQU1FPWNyb3NzZmlyZQ0KDQpGT05U VFlQRT1wY2YNCg0KSU1BS0VfREVGSU5FUyA9IC1EQ3Jvc3NGaXJlIC1JJChU T1ApLy4uLy4uIC1JJChUT1ApLy4uL2NvbmZpZw0KDQogICAgICBUQVIgPSB0 YXINCiAgICAgUEVSTCA9IHBlcmwNCiBCQVNFTkFNRSA9IGJhc2VuYW1lDQog ICAgIFNIQVIgPSBzaGFyDQoNCk1LRElSSElFUiA9IG1rZGlyaGllcg0KDQpE RUZJTkVTID0gLURGT05URElSPVwiJHtGT05URElSfVwiIC1ERk9OVE5BTUU9 XCIkKEZPTlROQU1FKVwiICQoVEFSR0VUKSBcDQogICAgICAgIC1ETElCRElS PVwiJChDX0xJQkRJUilcIg0KDQpNQUtFID0gbWFrZQ0KDQpTVUJESVJTID0g Y29tbW9uIGRvYyBzZXJ2ZXIgY2xpZW50IHV0aWxzIGNyb3NzZWRpdCBpbmNs dWRlIGNvbmZpZyBsaWINCg0KRklMRVMgPSBDSEFOR0VTIENSRURJVFMgREVW RUxPUEVSUyBET05FIEltYWtlZmlsZSBJTlNUQUxMIExpY2Vuc2UgUkVBRE1F IFwNCglUT0RPDQoNCmFsbDo6IGVtcHR5cnVsZQ0KDQpXb3JsZDo6DQoJQGVj aG8gIiINCglAZWNobyAiU3RhcnRpbmcgdG8gYnVpbGQgY3Jvc3NmaXJlLiAg VGltZSB0byBzdGFydCBwcmF5aW5nIDgpIg0KCUBlY2hvICIiDQoJQGRhdGUN CglAZWNobyAiIg0KCSQoWE1LTUYpDQoJbWFrZSBNYWtlZmlsZXMNCgkkKE1B S0UpICQoTUZMQUdTKSBjbGVhbg0KCSQoTUFLRSkgJChNRkxBR1MpIGluY2x1 ZGVzDQoJJChNQUtFKSAkKE1GTEFHUykgZGVwZW5kDQoJJChNQUtFKSAkKE1G TEFHUykgYWxsDQoJQGVjaG8gIiINCglAZGF0ZQ0KCUBlY2hvICIiDQoJQGVj aG8gIkNvbXBsZXRlIGJ1aWxkIG9mIGNyb3NzZmlyZSAoaG9wZWZ1bGx5KSBm aW5pc2hlZC4iDQoJQGVjaG8gIiINCg0KYWxsOjoNCglAY2FzZSAnJHtNRkxB R1N9JyBpbiAqW2lrXSopIHNldCArZTs7IGVzYWM7IFwNCglmb3IgaSBpbiAk KFNVQkRJUlMpIDtcDQoJZG8gXA0KCShjZCAkJGkgOyBlY2hvICJtYWtpbmci IGFsbCAiaW4gJChDVVJSRU5UX0RJUikvJCRpLi4uIjsgXA0KCSQoTUFLRSkg JChNRkxBR1MpICdDREVCVUdGTEFHUz0kKENERUJVR0ZMQUdTKScgYWxsKTsg XA0KCWRvbmUNCg0KZGVwZW5kOjoNCglAY2FzZSAnJHtNRkxBR1N9JyBpbiAq W2lrXSopIHNldCArZTs7IGVzYWM7IFwNCglmb3IgaSBpbiAkKFNVQkRJUlMp IDtcDQoJZG8gXA0KCShjZCAkJGkgOyBlY2hvICJkZXBlbmRpbmciICJpbiAk KENVUlJFTlRfRElSKS8kJGkuLi4iOyBcDQoJJChNQUtFKSAkKE1GTEFHUykg IGRlcGVuZCk7IFwNCglkb25lDQoNCnJlbGluazoNCgkkKFJNKSBzZXJ2ZXIv Y3Jvc3NmaXJlDQoJJChSTSkgY2xpZW50L2Nyb3NzY2xpZW50DQoJJChSTSkg Y3Jvc3NlZGl0L2Nyb3NzZWRpdA0KCSQoUk0pIGltYWdlcy94Ym10b2JkZg0K CSQoTUFLRSkgJChNS0ZMQUdTKSBhbGwNCg0KaWZpOg0KCShjZCBjb21tb247 ICQoTUFLRSkgJChNS0ZMQUdTKSBhbGwpDQoJKGNkIHNlcnZlcjsgJChNQUtF KSAkKE1LRkxBR1MpIGlmaSkNCgkoY2QgY2xpZW50OyAkKE1BS0UpICQoTUtG TEFHUykgaWZpKQ0KDQoJKGNkIGltYWdlczsgJChNQUtFKSAkKE1LRkxBR1Mp IGluc3RhbGwpDQoNCm1hcHM6DQoJJChSTSkgJChWRVJTSU9OKS5tYXBzLnRh ci5aICQoVkVSU0lPTikubWFwcy50YXINCgl0YXIgY3ZmaCAkKFZFUlNJT04p Lm1hcHMudGFyIGxpYi9SRUFETUUgbGliL2FyY2hldHlwZXMgbGliL2FydGlm YWN0cyBsaWIvdHJlYXN1cmVzIGxpYi9tYXBpbmRleCBsaWIvbW90ZCBsaWIv bWFwcyBsaWIvcnBsYXkuY29uZiBsaWIvc291bmRzDQoJY29tcHJlc3MgJChW RVJTSU9OKS5tYXBzLnRhcg0KDQpBVE9QID0gL3RtcC8kKFZFUlNJT04pDQpU QVIgPSBndGFyDQphcmNoaXZlOiBzdWJhcmNoaXZlDQoJJChSTSkgJChWRVJT SU9OKS50YXIuWg0KCShjZCAkKEFUT1ApO2NkIC4uO1wNCgkkKFJNKSAkKFZF UlNJT04pLnRhciAkKFZFUlNJT04pLnRhci5aO1wNCgkkKFRBUikgY3ZmaHog JChWRVJTSU9OKS50YXIuZ3ogYCQoQkFTRU5BTUUpICQoQVRPUClgO1wNCikN CgkkKE1WKSAkKEFUT1ApLy4uLyQoVkVSU0lPTikudGFyLmd6IC4NCgkkKFJN KSAtciAkKEFUT1ApDQoNCnN1YmFyY2hpdmU6Og0KCUBjYXNlICcke01GTEFH U30nIGluICpbaWtdKikgc2V0ICtlOzsgZXNhYzsgXA0KCWZvciBpIGluICQo U1VCRElSUykgO1wNCglkbyBcDQoJKGNkICQkaSA7IGVjaG8gImFyY2hpdmlu ZyIgImluICQoQ1VSUkVOVF9ESVIpLyQkaS4uLiI7IFwNCgkkKE1BS0UpICQo TUZMQUdTKSAnQVRPUD0kKEFUT1ApJyBzdWJhcmNoaXZlKTsgXA0KCWRvbmUN Cg0Kc3ViYXJjaGl2ZTo6DQoJQGlmIFsgLWQgJChBVE9QKS8uIF07IHRoZW4g c2V0ICt4OyBcDQoJZWxzZSAoc2V0IC14OyAkKE1LRElSSElFUikgJChBVE9Q KS8uKTsgZmkNCgkkKENQKSAkKEZJTEVTKSAkKEFUT1ApLy4NCg0KZGlzdDog YXJjaGl2ZQ0KDQpzaGFyOg0KCSQoUk0pICQoVkVSU0lPTikuc2hhci4qDQoJ c2hhciAtbiAkKFZFUlNJT04pIC1hIC1zIGZyYW5rakBpZmkudWlvLm5vIC1j IC1vICQoVkVSU0lPTikuc2hhciAtTDUwICQoRklMRVMpICQoU1VCRElSUykN Cg0KcHJvdG86DQoJKGNkIGNvbW1vbjsgbWFrZSBwcm90bykNCgkoY2QgY2xp ZW50OyBtYWtlIHByb3RvKQ0KCShjZCBzZXJ2ZXI7IG1ha2UgcHJvdG8pDQoJ KGNkIGNyb3NzZWRpdDsgbWFrZSBwcm90bykNCg0KY2xlYW46Og0KCShjZCBp bmNsdWRlOyAkKFJNKSAqfiAqcHJvdG8uaC5vcmlnKQ0KCShjZCBjcm9zc2Vk aXQ7ICQoUk0pICpwcm90by5oLm9yaWcpDQoJKGNkIGNsaWVudDsgJChSTSkg KnByb3RvLmgub3JpZykNCg0KZGlzdGNsZWFuOiBjbGVhbg0KCSQoUk0pICov TWFrZWZpbGUgTWFrZWZpbGUNCg0KbG92ZTo6DQoJQGVjaG8gVW11d3pHIG5p Q3RCLiAgS3d6bSBsQ3V4bWwuIHwgdHIgSS1aYS16QS1IIEEtWmEteg0KDQoj IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiMgY29tbW9uIHJ1bGVz IGZvciBhbGwgTWFrZWZpbGVzIC0gZG8gbm90IGVkaXQNCg0KZW1wdHlydWxl OjoNCg0KY2xlYW46Og0KCSQoUk1fQ01EKSAiIyIqDQoNCk1ha2VmaWxlOjoN CgktQGlmIFsgLWYgTWFrZWZpbGUgXTsgdGhlbiBzZXQgLXg7IFwNCgkkKFJN KSBNYWtlZmlsZS5iYWs7ICQoTVYpIE1ha2VmaWxlIE1ha2VmaWxlLmJhazsg XA0KCWVsc2UgZXhpdCAwOyBmaQ0KCSQoSU1BS0VfQ01EKSAtRFRPUERJUj0k KFRPUCkgLURDVVJESVI9JChDVVJSRU5UX0RJUikNCg0KdGFnczo6DQoJJChU QUdTKSAtdyAqLltjaF0NCgkkKFRBR1MpIC14dyAqLltjaF0gPiBUQUdTDQoN CnNhYmVyOg0KCSMgbG9hZCAkKEFMTERFRklORVMpICQoU1JDUykNCg0Kb3Nh YmVyOg0KCSMgbG9hZCAkKEFMTERFRklORVMpICQoT0JKUykNCg0KIyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQojIHJ1bGVzIGZvciBidWlsZGlu ZyBpbiBTVUJESVJTIC0gZG8gbm90IGVkaXQNCg0KaW5zdGFsbDo6DQoJQGNh c2UgJyR7TUZMQUdTfScgaW4gKltpa10qKSBzZXQgK2U7OyBlc2FjOyBcDQoJ Zm9yIGkgaW4gJChTVUJESVJTKSA7XA0KCWRvIFwNCgkoY2QgJCRpIDsgZWNo byAiaW5zdGFsbGluZyIgImluICQoQ1VSUkVOVF9ESVIpLyQkaS4uLiI7IFwN CgkkKE1BS0UpICQoTUZMQUdTKSBERVNURElSPSckKERFU1RESVIpJyBpbnN0 YWxsKTsgXA0KCWRvbmUNCg0KaW5zdGFsbC5tYW46Og0KCUBjYXNlICcke01G TEFHU30nIGluICpbaWtdKikgc2V0ICtlOzsgZXNhYzsgXA0KCWZvciBpIGlu ICQoU1VCRElSUykgO1wNCglkbyBcDQoJKGNkICQkaSA7IGVjaG8gImluc3Rh bGxpbmcgbWFuIHBhZ2VzIiAiaW4gJChDVVJSRU5UX0RJUikvJCRpLi4uIjsg XA0KCSQoTUFLRSkgJChNRkxBR1MpIERFU1RESVI9JyQoREVTVERJUiknIGlu c3RhbGwubWFuKTsgXA0KCWRvbmUNCg0KY2xlYW46Og0KCUBjYXNlICcke01G TEFHU30nIGluICpbaWtdKikgc2V0ICtlOzsgZXNhYzsgXA0KCWZvciBpIGlu ICQoU1VCRElSUykgO1wNCglkbyBcDQoJKGNkICQkaSA7IGVjaG8gImNsZWFu aW5nIiAiaW4gJChDVVJSRU5UX0RJUikvJCRpLi4uIjsgXA0KCSQoTUFLRSkg JChNRkxBR1MpIFJNX0NNRD0nJChSTV9DTUQpJyBjbGVhbik7IFwNCglkb25l DQoNCnRhZ3M6Og0KCUBjYXNlICcke01GTEFHU30nIGluICpbaWtdKikgc2V0 ICtlOzsgZXNhYzsgXA0KCWZvciBpIGluICQoU1VCRElSUykgO1wNCglkbyBc DQoJKGNkICQkaSA7IGVjaG8gInRhZ2dpbmciICJpbiAkKENVUlJFTlRfRElS KS8kJGkuLi4iOyBcDQoJJChNQUtFKSAkKE1GTEFHUykgVEFHUz0nJChUQUdT KScgdGFncyk7IFwNCglkb25lDQoNCk1ha2VmaWxlczo6DQoJQGNhc2UgJyR7 TUZMQUdTfScgaW4gKltpa10qKSBzZXQgK2U7OyBlc2FjOyBcDQoJZm9yIGkg aW4gJChTVUJESVJTKSA7XA0KCWRvIFwNCgllY2hvICJtYWtpbmcgTWFrZWZp bGVzIGluICQoQ1VSUkVOVF9ESVIpLyQkaS4uLiI7IFwNCgljYXNlICIkJGki IGluIFwNCgkuLz8qLz8qLz8qLz8qKSBuZXd0b3A9Li4vLi4vLi4vLi4vIHN1 Yj1zdWJzdWJzdWJzdWI7OyBcDQoJLi8/Ki8/Ki8/KikgbmV3dG9wPS4uLy4u Ly4uLyBzdWI9c3Vic3Vic3ViOzsgXA0KCS4vPyovPyopIG5ld3RvcD0uLi8u Li8gc3ViPXN1YnN1Yjs7IFwNCgkuLz8qKSBuZXd0b3A9Li4vIHN1Yj1zdWI7 OyBcDQoJKi8/Ki8/Ki8/KikgbmV3dG9wPS4uLy4uLy4uLy4uLyBzdWI9c3Vi c3Vic3Vic3ViOzsgXA0KCSovPyovPyopIG5ld3RvcD0uLi8uLi8uLi8gc3Vi PXN1YnN1YnN1Yjs7IFwNCgkqLz8qKSBuZXd0b3A9Li4vLi4vIHN1Yj1zdWJz dWI7OyBcDQoJKikgbmV3dG9wPS4uLyBzdWI9c3ViOzsgXA0KCWVzYWM7IFwN CgljYXNlICIkKFRPUCkiIGluIFwNCgkvPyopIG5ld3RvcD0gdXBwcmVmaXg9 IDs7IFwNCgkqKSB1cHByZWZpeD0uLi8gOzsgXA0KCWVzYWM7IFwNCgkkKE1B S0UpICQke3N1Yn1kaXJNYWtlZmlsZXMgVVBQUkVGSVg9JCR1cHByZWZpeCBO RVdUT1A9JCRuZXd0b3AgXA0KCU1BS0VGSUxFX1NVQkRJUj0kJGkgTkVXX0NV UlJFTlRfRElSPSQoQ1VSUkVOVF9ESVIpLyQkaTtcDQoJZG9uZQ0KDQpzdWJk aXJNYWtlZmlsZXM6DQoJJChSTSkgJChNQUtFRklMRV9TVUJESVIpL01ha2Vm aWxlLmJhaw0KCS1AaWYgWyAtZiAkKE1BS0VGSUxFX1NVQkRJUikvTWFrZWZp bGUgXTsgdGhlbiBzZXQgLXg7IFwNCgkkKE1WKSAkKE1BS0VGSUxFX1NVQkRJ UikvTWFrZWZpbGUgJChNQUtFRklMRV9TVUJESVIpL01ha2VmaWxlLmJhazsg XA0KCWVsc2UgZXhpdCAwOyBmaQ0KCWNkICQoTUFLRUZJTEVfU1VCRElSKTsg JChJTUFLRV9DTUQpIC1EVE9QRElSPSQoVVBQUkVGSVgpJChUT1ApIC1EQ1VS RElSPSQoTkVXX0NVUlJFTlRfRElSKTsgXA0KCSQoTUFLRSkgJChNRkxBR1Mp IE1ha2VmaWxlcw0KDQpzdWJzdWJkaXJNYWtlZmlsZXM6DQoJJChSTSkgJChN QUtFRklMRV9TVUJESVIpL01ha2VmaWxlLmJhaw0KCS1AaWYgWyAtZiAkKE1B S0VGSUxFX1NVQkRJUikvTWFrZWZpbGUgXTsgdGhlbiBzZXQgLXg7IFwNCgkk KE1WKSAkKE1BS0VGSUxFX1NVQkRJUikvTWFrZWZpbGUgJChNQUtFRklMRV9T VUJESVIpL01ha2VmaWxlLmJhazsgXA0KCWVsc2UgZXhpdCAwOyBmaQ0KCWNk ICQoTUFLRUZJTEVfU1VCRElSKTsgJChJTUFLRV9DTUQpIC1EVE9QRElSPSQo VVBQUkVGSVgpJChVUFBSRUZJWCkkKFRPUCkgLURDVVJESVI9JChORVdfQ1VS UkVOVF9ESVIpOyBcDQoJJChNQUtFKSAkKE1GTEFHUykgTWFrZWZpbGVzDQoN CnN1YnN1YnN1YmRpck1ha2VmaWxlczoNCgkkKFJNKSAkKE1BS0VGSUxFX1NV QkRJUikvTWFrZWZpbGUuYmFrDQoJLUBpZiBbIC1mICQoTUFLRUZJTEVfU1VC RElSKS9NYWtlZmlsZSBdOyB0aGVuIHNldCAteDsgXA0KCSQoTVYpICQoTUFL RUZJTEVfU1VCRElSKS9NYWtlZmlsZSAkKE1BS0VGSUxFX1NVQkRJUikvTWFr ZWZpbGUuYmFrOyBcDQoJZWxzZSBleGl0IDA7IGZpDQoJY2QgJChNQUtFRklM RV9TVUJESVIpOyAkKElNQUtFX0NNRCkgLURUT1BESVI9JChVUFBSRUZJWCkk KFVQUFJFRklYKSQoVVBQUkVGSVgpJChUT1ApIC1EQ1VSRElSPSQoTkVXX0NV UlJFTlRfRElSKTsgXA0KCSQoTUFLRSkgJChNRkxBR1MpIE1ha2VmaWxlcw0K DQpzdWJzdWJzdWJzdWJkaXJNYWtlZmlsZXM6DQoJJChSTSkgJChNQUtFRklM RV9TVUJESVIpL01ha2VmaWxlLmJhaw0KCS1AaWYgWyAtZiAkKE1BS0VGSUxF X1NVQkRJUikvTWFrZWZpbGUgXTsgdGhlbiBzZXQgLXg7IFwNCgkkKE1WKSAk KE1BS0VGSUxFX1NVQkRJUikvTWFrZWZpbGUgJChNQUtFRklMRV9TVUJESVIp L01ha2VmaWxlLmJhazsgXA0KCWVsc2UgZXhpdCAwOyBmaQ0KCWNkICQoTUFL RUZJTEVfU1VCRElSKTsgJChJTUFLRV9DTUQpIC1EVE9QRElSPSQoVVBQUkVG SVgpJChVUFBSRUZJWCkkKFVQUFJFRklYKSQoVVBQUkVGSVgpJChUT1ApIC1E Q1VSRElSPSQoTkVXX0NVUlJFTlRfRElSKTsgXA0KCSQoTUFLRSkgJChNRkxB R1MpIE1ha2VmaWxlcw0KDQppbmNsdWRlczo6DQoJQGNhc2UgJyR7TUZMQUdT fScgaW4gKltpa10qKSBzZXQgK2U7OyBlc2FjOyBcDQoJZm9yIGkgaW4gJChT VUJESVJTKSA7XA0KCWRvIFwNCgkoY2QgJCRpIDsgZWNobyBpbmNsdWRpbmcg ImluICQoQ1VSUkVOVF9ESVIpLyQkaS4uLiI7IFwNCgkkKE1BS0UpICQoTUZM QUdTKSAgaW5jbHVkZXMpOyBcDQoJZG9uZQ0KDQojIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiMgZGVwZW5kZW5jaWVzIGdlbmVyYXRlZCBieSBt YWtlZGVwZW5kDQoNCg== --0-874846392-818959513=:11826 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=Imakefile Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: LyogICBDcm9zc0ZpcmUsIEEgTXVsdGlwbGF5ZXIgZ2FtZSBmb3IgWC13aW5k b3dzDQogKg0KICogICAkSWQ6IEltYWtlZmlsZSx2IDEuMTYgMTk5NS8xMS8x MyAwNzo1OToxMiBtYXN0ZXIgRXhwIG1hc3RlciAkDQogKg0KICogICBDb3B5 cmlnaHQgKEMpIDE5OTIgRnJhbmsgVG9yZSBKb2hhbnNlbg0KICoNCiAqICAg VGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0 cmlidXRlIGl0IGFuZC9vciBtb2RpZnkNCiAqICAgaXQgdW5kZXIgdGhlIHRl cm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJs aXNoZWQgYnkNCiAqICAgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsg ZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUgTGljZW5zZSwgb3INCiAqICAgKGF0 IHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4NCiAqDQogKiAgIFRo aXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0 IHdpbGwgYmUgdXNlZnVsLA0KICogICBidXQgV0lUSE9VVCBBTlkgV0FSUkFO VFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZg0KICog ICBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFS IFBVUlBPU0UuICBTZWUgdGhlDQogKiAgIEdOVSBHZW5lcmFsIFB1YmxpYyBM aWNlbnNlIGZvciBtb3JlIGRldGFpbHMuDQogKg0KICogICBZb3Ugc2hvdWxk IGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJs aWMgTGljZW5zZQ0KICogICBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYg bm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQ0KICogICBGb3VuZGF0 aW9uLCBJbmMuLCA2NzUgTWFzcyBBdmUsIENhbWJyaWRnZSwgTUEgMDIxMzks IFVTQS4NCiAqDQogKiAgIFRoZSBhdXRob3IgY2FuIGJlIHJlYWNoZWQgdmlh IGUtbWFpbCB0byBmcmFua2pAaWZpLnVpby5uby4NCiAqLw0KDQpJTUFLRV9E RUZJTkVTPS1JJChORVdUT1ApLy4uIC1JJChORVdUT1ApL2NvbmZpZyAtSSQo TkVXVE9QKQ0KRVhUUkFfSU5DTFVERVMgPSAtSS9ob21lL3lvZGEvYXdyb2Jl bC9pbmNsdWRlDQpFWFRSQV9MSUJSQVJJRVMgPSAtTC9ob21lL3lvZGEvYXdy b2JlbC9saWINCiNpbmNsdWRlICJjb25maWcvY3Jvc3NzaXRlLmRlZiINCiNp bmNsdWRlICJjb25maWcvY3Jvc3NmaXJlLnRtcGwiDQoNCk1BS0UgPSBtYWtl DQojZGVmaW5lIElIYXZlU3ViZGlycw0KDQpTVUJESVJTID0gY29tbW9uIGRv YyBzZXJ2ZXIgY2xpZW50IHV0aWxzIGNyb3NzZWRpdCBpbmNsdWRlIGNvbmZp ZyBsaWINCg0KRklMRVMgPSBDSEFOR0VTIENSRURJVFMgREVWRUxPUEVSUyBE T05FIEltYWtlZmlsZSBJTlNUQUxMIExpY2Vuc2UgUkVBRE1FIFwNCglUT0RP IA0KDQpBbGxUYXJnZXQoZW1wdHlydWxlKQ0KDQpXb3JsZDo6DQoJQGVjaG8g IiINCglAZWNobyAiU3RhcnRpbmcgdG8gYnVpbGQgY3Jvc3NmaXJlLiAgVGlt ZSB0byBzdGFydCBwcmF5aW5nIDgpIg0KCUBlY2hvICIiDQoJQGRhdGUNCglA ZWNobyAiIg0KCSQoWE1LTUYpDQoJbWFrZSBNYWtlZmlsZXMNCgkkKE1BS0Up ICQoTUZMQUdTKSBjbGVhbg0KCSQoTUFLRSkgJChNRkxBR1MpIGluY2x1ZGVz DQoJJChNQUtFKSAkKE1GTEFHUykgZGVwZW5kDQoJJChNQUtFKSAkKE1GTEFH UykgYWxsDQoJQGVjaG8gIiINCglAZGF0ZQ0KCUBlY2hvICIiDQoJQGVjaG8g IkNvbXBsZXRlIGJ1aWxkIG9mIGNyb3NzZmlyZSAoaG9wZWZ1bGx5KSBmaW5p c2hlZC4iDQoJQGVjaG8gIiINCg0KDQpNYWtlU3ViZGlycygkKFNVQkRJUlMp KQ0KRGVwZW5kU3ViZGlycygkKFNVQkRJUlMpKQ0KDQpyZWxpbms6DQoJJChS TSkgc2VydmVyL2Nyb3NzZmlyZQ0KCSQoUk0pIGNsaWVudC9jcm9zc2NsaWVu dA0KCSQoUk0pIGNyb3NzZWRpdC9jcm9zc2VkaXQNCgkkKFJNKSBpbWFnZXMv eGJtdG9iZGYNCgkkKE1BS0UpICQoTUtGTEFHUykgYWxsDQoNCmlmaToNCgko Y2QgY29tbW9uOyAkKE1BS0UpICQoTUtGTEFHUykgYWxsKQ0KCShjZCBzZXJ2 ZXI7ICQoTUFLRSkgJChNS0ZMQUdTKSBpZmkpDQoJKGNkIGNsaWVudDsgJChN QUtFKSAkKE1LRkxBR1MpIGlmaSkNCi8qCShjZCBjcm9zc2VkaXQ7ICQoTUFL RSkgJChNS0ZMQUdTKSBpZmkpKi8NCgkoY2QgaW1hZ2VzOyAkKE1BS0UpICQo TUtGTEFHUykgaW5zdGFsbCkNCg0KbWFwczoNCgkkKFJNKSAkKFZFUlNJT04p Lm1hcHMudGFyLlogJChWRVJTSU9OKS5tYXBzLnRhcg0KCXRhciBjdmZoICQo VkVSU0lPTikubWFwcy50YXIgbGliL1JFQURNRSBsaWIvYXJjaGV0eXBlcyBs aWIvYXJ0aWZhY3RzIGxpYi90cmVhc3VyZXMgbGliL21hcGluZGV4IGxpYi9t b3RkIGxpYi9tYXBzIGxpYi9ycGxheS5jb25mIGxpYi9zb3VuZHMNCgljb21w cmVzcyAkKFZFUlNJT04pLm1hcHMudGFyDQoNClBhY2tBcmNoaXZlKCQoVkVS U0lPTikpDQoNCk1ha2VBcmNoaXZlKCQoU1VCRElSUykpDQoNCkluc2VydEFy Y2hpdmUoJChGSUxFUyksLikNCg0KZGlzdDogYXJjaGl2ZQ0KDQpzaGFyOiAv KiBEb2Vzbid0IHdvcmsgYW55bW9yZSAqLw0KCSQoUk0pICQoVkVSU0lPTiku c2hhci4qDQoJc2hhciAtbiAkKFZFUlNJT04pIC1hIC1zIGZyYW5rakBpZmku dWlvLm5vIC1jIC1vICQoVkVSU0lPTikuc2hhciAtTDUwICQoRklMRVMpICQo U1VCRElSUykNCg0KcHJvdG86DQoJKGNkIGNvbW1vbjsgbWFrZSBwcm90bykN CgkoY2QgY2xpZW50OyBtYWtlIHByb3RvKQ0KCShjZCBzZXJ2ZXI7IG1ha2Ug cHJvdG8pDQoJKGNkIGNyb3NzZWRpdDsgbWFrZSBwcm90bykNCg0KY2xlYW46 Og0KCShjZCBpbmNsdWRlOyAkKFJNKSAqfiAqcHJvdG8uaC5vcmlnKQ0KCShj ZCBjcm9zc2VkaXQ7ICQoUk0pICpwcm90by5oLm9yaWcpDQoJKGNkIGNsaWVu dDsgJChSTSkgKnByb3RvLmgub3JpZykNCg0KZGlzdGNsZWFuOiBjbGVhbg0K CSQoUk0pICovTWFrZWZpbGUgTWFrZWZpbGUNCg0KbG92ZTo6DQoJQGVjaG8g VW11d3pHIG5pQ3RCLiAgS3d6bSBsQ3V4bWwuIHwgdHIgSS1aYS16QS1IIEEt WmEteg0K --0-874846392-818959513=:11826-- From crossfire-request Thu Dec 14 09:46:46 1995 Return-Path: Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 14 Dec 1995 09:46:27 +0100 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.132.130]) by mailgate.ericsson.se (8.6.11/1.0) with ESMTP id JAA21132; Thu, 14 Dec 1995 09:44:29 +0100 Received: (from eedraq@localhost) by chapelle.eed.ericsson.se (8.7.1/8.7.1) id JAA27186; Thu, 14 Dec 1995 09:43:41 +0100 (MET) Date: Thu, 14 Dec 1995 09:43:41 +0100 (MET) Message-Id: <199512140843.JAA27186@chapelle.eed.ericsson.se> To: Steve.Wray@vuw.ac.nz, crossfire@ifi.uio.no, mwedel@pyramid.com Subject: cut and paste (was Re: Mist thoughts (long)) From: Raphael.Quinet@eed.ericsson.se Status: RO Mark Wedel wrote: > [quote from Stephen Wray ] > > Something which is sorely missing is CUT AND PASTE in the message > > window. > > > > This is such an obvious deficiency, there must be a *really* good reason > > why it hasn't been done already. > > The reason it isn't in place is because it isn't something that is really > easy to do. [...] > This truly is an issue that should wait for client server with like an Xt or > other interface that provides all of those functions without special coding. Right. I am familiar with the AsciiText widget, and I know that it would require less than 100 lines of codes to handle cut and paste correctly, as well as proper scrolling (with a customizable number of saved lines) and sharing the cut buffer with other applications. Well, if someone ever manages to separate the client from the server (i.e. no common dependencies), then I could volunteer for re-writing the message output part using the standard Athena widgets (Xaw). As well as the sound code, of course. But it looks like this won't be done tomorrow... -Raphael From crossfire-request Thu Dec 14 06:30:33 1995 Return-Path: Received: from mail02.mail.aol.com (mail02.mail.aol.com [152.163.172.66]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 14 Dec 1995 06:30:33 +0100 From: SHixson362@aol.com Received: by mail02.mail.aol.com (8.6.12/8.6.12) id AAA07335 for crossfire@ifi.uio.no; Thu, 14 Dec 1995 00:30:01 -0500 Date: Thu, 14 Dec 1995 00:30:01 -0500 Message-ID: <951214002052_72483136@mail02.mail.aol.com> To: crossfire@ifi.uio.no Subject: new member Status: RO SUBSCRIBE SHixson362@aol.com From crossfire-request Wed Dec 13 22:31:19 1995 Return-Path: Received: from bertha.pyramid.com (bertha.pyramid.com [129.214.1.100]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Wed, 13 Dec 1995 22:31:17 +0100 Received: from stealth.eng.pyramid.com by bertha.pyramid.com (5.67/OSx5.1a Pyramid-Internet-Gateway) id AA02536; Wed, 13 Dec 95 21:30:37 GMT Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA04679; Wed, 13 Dec 95 21:30:35 GMT From: "Mark Wedel" Message-Id: <9512131330.ZM4677@stealth.eng.pyramid.com> Date: Wed, 13 Dec 1995 13:30:34 -0800 In-Reply-To: Stephen Wray "Re: Mist thoughts (long)" (Dec 14, 9:06am) References: <199512132006.JAA10946@debretts.comp.vuw.ac.nz> X-Mailer: Z-Mail (3.2.0 06sep94) To: Steve.Wray@vuw.ac.nz, mwedel@pyramid.com, crossfire@ifi.uio.no Subject: Re: Mist thoughts (long) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: RO > Something which is sorely missing is CUT AND PASTE in the message > window. > > This is such an obvious deficiency, there must be a *really* good reason why > it hasn't been done already. > > The reason it isn't in place is because it isn't something that is really easy to do. Doing paste wouldn't be really hard, except I am not sure how easy it would be to actually put the paste data for the server to think as input. Cutting becomes a little more problematic in that you need to do mouse button selections, dragging, etc. This truly is an issue that should wait for client server with like an Xt or other interface that provides all of those functions without special coding. > - --- >-- End of excerpt from Stephen Wray -- --Mark From crossfire-request Wed Dec 13 21:47:24 1995 Return-Path: Received: from harfang.CC.UMontreal.CA (harfang.CC.UMontreal.CA [132.204.2.102]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 13 Dec 1995 21:47:11 +0100 Received: from epsom.jsp.umontreal.ca (epsom.JSP.UMontreal.CA [132.204.45.25]) by harfang.CC.UMontreal.CA with ESMTP id PAA02952 (8.6.11/IDA-1.6); Wed, 13 Dec 1995 15:45:43 -0500 Received: from derby.jsp.umontreal.ca (derby.jsp.umontreal.ca [132.204.46.26]) by epsom.jsp.umontreal.ca via ESMTP (950911.SGI.8.6.12.PATCH825/5.17) id PAA29749 ; Wed, 13 Dec 1995 15:46:56 -0500 Received: (from casino@localhost) by derby.jsp.umontreal.ca (950911.SGI.8.6.12.PATCH825/5.17) id PAA02496 ; Wed, 13 Dec 1995 15:46:32 -0500 Date: Wed, 13 Dec 1995 15:46:31 -0500 (EST) From: GESTIONNAIRE DU Casino To: Tadah cc: "Michael B. Martin" , crossfire@ifi.uio.no Subject: Re: Misc notes/thoughts. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 11 Dec 1995, Tadah wrote: > ATTENTION all programmers.. Idea here.. :> > Why not have encrypted RSA player files kept on the players computer? > Netrek does something like this with its clients so that people can't mod > clients and cheat. Why not do this with player files, and to what > advantage? It would be great to be able to move your player to other > servers should a server go down, become slow, or whatever. No? > Well, anyway. Just an idea.. :> No no no... It would be too easy to cheat. Imagine : I install a server on my machine, and create a map with free armor/spells/money/etc. I get a munchkin character, then move it to the ultra-strict server where you play, and bash everythng about... --- Casino From crossfire-request Wed Dec 13 21:07:51 1995 Return-Path: Received: from kaukau.comp.vuw.ac.nz (kaukau.comp.vuw.ac.nz [130.195.5.20]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 13 Dec 1995 21:07:49 +0100 Received: from debretts.comp.vuw.ac.nz (debretts.comp.vuw.ac.nz [130.195.8.46]) by kaukau.comp.vuw.ac.nz (8.6.B/8.6.9-VUW) with ESMTP id JAA01090; Thu, 14 Dec 1995 09:06:03 +1300 From: Stephen Wray Received: (stevew@localhost) by debretts.comp.vuw.ac.nz (8.6.10/8.6.6) id JAA10946; Thu, 14 Dec 1995 09:06:19 +1300 Date: Thu, 14 Dec 1995 09:06:19 +1300 Message-Id: <199512132006.JAA10946@debretts.comp.vuw.ac.nz> To: mwedel@pyramid.com, crossfire@ifi.uio.no In-reply-to: <9512131029.AA02213@stealth.eng.pyramid.com> (mwedel@pyramid.com) Subject: Re: Mist thoughts (long) Reply-to: Steve.Wray@vuw.ac.nz Status: RO -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Mark" == Mark Wedel writes: Mark> ------------------------------------------------------------------------------ Mark> Message output: Mark> Well, there is already scrollbars in use in crossfire for the inventory and Mark> look windows. Since all that code is there, it would at least be worth Mark> looking at and seeing if it can at least be generalized some. Mark> I don't really like the idea of using some toolkit just for scrollbar Mark> usage. Seems like overkill, and probably won't do much for performance Mark> either. Something which is sorely missing is CUT AND PASTE in the message window. This is such an obvious deficiency, there must be a *really* good reason why it hasn't been done already. - --- **********************T***H***E***L***E***M***A********************** 44. For pure will, unassuaged of purpose, delivered from the lust of result, is every way perfect. -- LIBER AL vel LEGIS ******************************IN*LVX********************************* Stephen Wray -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQCVAgUBMM8yNCt7qh9JVcfZAQEL6QP/QQSjmyy6KGrQ8g6UvI+pKc8chBIGSY1y YWqXnpOxPpBLn81mZqETiasOAr8ccXIXvPfILZFEfHYD8cgBs0Sof+/aKkQ3BMMw AbAZvPJuNMMblH2Vci64eJZO6MYPhD7FcsXfxATMDainQvFtHMB4PnMXhlmev+Bd oE4QT0fGPfo= =Kgp5 -----END PGP SIGNATURE----- From crossfire-request Wed Dec 13 20:33:46 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 13 Dec 1995 20:33:45 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id OAA02060 for crossfire@ifi.uio.no; Wed, 13 Dec 1995 14:33:37 -0500 Date: Wed, 13 Dec 1995 14:33:37 -0500 From: Brian Thomas Message-Id: <199512131933.OAA02060@chaupher.gsfc.nasa.gov> To: crossfire@ifi.uio.no Subject: reading books, another idea I am working on Status: RO Hey all, I would like to passby everyone an idea that I am working on -- development of the "READABLE" hack. Because I expect some of the idea will be controversial I have segmented it into parts of increasingly acceptablity. (I, of course, think its all reasonable :). Main Idea -- books for players One thing, I think, that will go a long way to improving th e atmosphere of the game is to create code that will support the development of non-magical reading material, which for lack of a better (singular) word I will refer to as "books". As of the current code, the only non-magical books are those specifically created on maps. Why not have several types of (general and specific) information be available in shops and/or monster treasure hoards? Examples of things that I would put into books: -> Compendiums on monsters/racial groups. Their powers/abilities and how to kill them. -> Compendiums of spells/prayers in a given level. Rare spells (bookchance==0) might have a chance of appearing. -> "Bibles" -- properties/characteristics of a God/religon -> Compendiums explaining the powers of 2-3 artifacts -> Alchemical Formulae (err..refers to another hack I am working on, sorry!) -> Random information drawn from a file in lib/. This would give mapmakers an easy way to make "teaser" info available in areas outside of their own maps! Plus server specific info could easily be made available here too. Clearly some of this information is already available in the spoiler. But, with the ability of a given server maintainer to have different archetypes/gods/spells/etc, the spoiler can sometimes be useless. A vehicle through which to impart *server specific* information is also needed. But that wouldnt even be the main value of such a system, the enchancement to the atmosphere of the game (I think) is the main point. Susequent Idea -- modification of the writing skill. I would like to propose that the writing skill be expanded to allow players to write messages/keep notes in "books". This would be (err, actually, "is") very easy to do. Secondarily, I can't see why players should be able to write if they cant read! I propose that the Literacy skil be required for a player to use "writing". Susequent Idea -- modification of the literacy skill. I would like to further propose that the literacy skill be modified. Why allow players to read books if they arent literate! Ditto for spellbooks. I would further propose that reading skill be adopted. If a player's literacy level is less than the level of the book (I wont explain how that's assigned) and/or the level of the spell/prayer in the book, then they get the "gibberish" message. Allow a nominal amound of xp to be awarded for translation of a book (based on the readers level and the level of the book of course). Well.. Thats it. I expect to be working on the (acceptable) parts of this code between now and christmas. Ideas/comments? b.t. From crossfire-request Wed Dec 13 19:34:41 1995 Return-Path: Received: from noc.msc.edu (noc.msc.edu [137.66.12.254]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Wed, 13 Dec 1995 19:34:40 +0100 Received: from ww.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA23799; Wed, 13 Dec 95 12:34:38 -0600 Received: from localhost (brett@localhost) by ww.msc.edu (8.7.1/8.6.6) with SMTP id MAA05173; Wed, 13 Dec 1995 12:34:37 -0600 (CST) Message-Id: <199512131834.MAA05173@ww.msc.edu> X-Authentication-Warning: ww.msc.edu: brett owned process doing -bs X-Authentication-Warning: ww.msc.edu: Host brett@localhost didn't use HELO protocol To: Raphael.Quinet@eed.ericsson.se Cc: crossfire@ifi.uio.no Subject: Re: Sounds (various ideas - long) In-Reply-To: Your message of "Wed, 13 Dec 1995 18:57:26 +0100." <199512131757.SAA22086@chapelle.eed.ericsson.se> Date: Wed, 13 Dec 1995 12:34:36 -0600 From: Brett Rabe Status: RO >Also, more and more machines support stereo sound. Would this be interesting >for Crossfire? Should "left" and "right" be associated with "west" and "east" >on the map, or should they change according to the direction the player is >facing? My first thought was, obviously, it should be reflective of the direction the player is facing. But that's silly. Obviously, it should be configurable. :-) ------ Brett Rabe Email: brett@msc.edu Network and System Administration Voice: 612/337-3443 Minnesota Supercomputer Center Inc. Pager: 612/538-8406 1200 South Washington Avenue, Minneapolis, MN 55415 FAX: 612/337-3400 From crossfire-request Wed Dec 13 18:57:45 1995 Return-Path: Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 13 Dec 1995 18:57:37 +0100 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.132.130]) by mailgate.ericsson.se (8.6.11/1.0) with ESMTP id SAA17086 for ; Wed, 13 Dec 1995 18:57:28 +0100 Received: (from eedraq@localhost) by chapelle.eed.ericsson.se (8.7.1/8.7.1) id SAA22086 for crossfire@ifi.uio.no; Wed, 13 Dec 1995 18:57:26 +0100 (MET) Date: Wed, 13 Dec 1995 18:57:26 +0100 (MET) Message-Id: <199512131757.SAA22086@chapelle.eed.ericsson.se> To: crossfire@ifi.uio.no Subject: Sounds (various ideas - long) From: Raphael.Quinet@eed.ericsson.se Status: RO I think it's better to put all replies to the messages about sounds in a single thread, so here we go... ---------- > From: Tero Haatanen > Date: Mon, 11 Dec 1995 13:15:56 +0200 (EET) > > I think that sounds don't need any special archetypes, but just build-in > support in objects like faces are now. [...] This would be a problem for ambient sounds, because you need to know at least two things: - the type of sound that should be played: "wind", "water dripping", "owls"... - how often the sound should be played (ambient sounds are repeated at random, but some of the should be played more often) These parameters have to be stored somewhere on the map. Thats why I suggest adding some (invisible) objects to the map, that are only playing sounds. ---------- > Date: Mon, 11 Dec 1995 11:11:22 -0500 (EST) > From: Tadah > > Yes, I have played Hexen. Its a pretty cool game and I love the idea of > atmosphere type sounds. What would be nice though is to also have some > music perhaps? .MIDs are great but I have never seen a midi player for > unix, so I don't know. [...] The easiest way to have background music would be to play a (long) .au file at a low level and mix it with other sound effects, because MIDI is not available on all systems. But the music files would of course take a few Mb... ---------- > From: "tuan (t.) doan" > Date: Mon, 11 Dec 1995 19:45:00 -0600 > > I would like to added to the format the number of times (or looping). For > example, > > magic missiles = 3, Whoosh.au, 50 > > or better yet, able to specified as many sounds to a particular action > > comet = Whoosh.au, 70; Boom.au, 100 Good idea. I prefer the second version: if you want to play the same sound several times, you could of course include the same .au file more than once. I don't think you will ever want to play more than four or five times the same sound (unless it's background music, but it should be handled separately), so it shouldn't be a problem. > >Another improvement would be to use "environmental" sounds; that would add > >a lot to the atmosphere. Those who have played games like Hexen know what I > > This would be great; but make sure that the volume is low (or at least > settable by the user) The sounds should be handled on the client side, so the user will be able to change the volume. > It's great to see that proposals for "better" crossfire comes in many > directions. Yes, but these proposals will only become interesting once someone starts implementing them. ---------- > Date: Wed, 13 Dec 95 10:29:46 GMT > From: mwedel@pyramid.com (Mark Wedel) > > Sound Improvement: > > Raphael mentioned that he would like to improve sound code, but wait for > client/server to do it. A few thoughts: > > IT seems to me that rewriting the sounds config file isn't really dependant > on client server. [...] I could of course re-write the part of the code that reads the config file without waiting for the client/server split. But I also want to be able to play these sounds, and this is where the problems begin... It would be nice if each user could choose to enable or disable some sounds, for example. Thus each player would need his/her own config file. Adding such features to the current code would be a nightmare. > I guess Raphael's thought is more that the server will send truly symbolic > commands to the client (ie, "play hit door" sound, vs "play bash.au" sound Right. Although I am starting to change my mind... In some cases, the people who run a server may want to add a special sound effect and the best way to do this would be to send the sound file directly. Hmmm... ---------- > From: Tero Haatanen > Date: Wed, 13 Dec 1995 17:04:11 +0200 (EET) > > I think that server should offer all sounds and refer them as symbolic > names (or numbers), but how much protocol support is needed to play them? > Some that comes to mind are sound, volume, how many times sound is played, > and is this a background music? Maybe Raphael can offer some thoughts > about this? OK, I'm thinking... The parameters which should be sent by the server are: - Sound type (i.e. "hit door", "arrow", "large lightning", ...) - Attenuation. This tells how much the maximum volume of the sound (set by the client) should be reduced because of the distance between the source of the sound and the player. - Priority. Some machines will only be able to mix a limited number of sounds, so there should be a way to specify which ones are the most important. For example, the sound of the player being hit should have a high priority, even if it doesn't have a high volume. The client does the mapping between sound types and file names, sets the volume, etc. As I explained previously (and with the suggestion from Tuan), the format of the file should look like this: hit door = tap2.au, 50 # Silly comments are allowed too hit player = clunk.au, 30; ouch.au, 50 # Comments start with "#" player hurt = ouch.au, 100 magic missile = Whoosh.au, 50 comet = Whoosh.au, 70; Boom.au, 100 There is one entry for each spell (using the spell name) and several entries for other events. Each sound is played only once, but it is possible to repeat a sound effect by inserting the same file name several times on the line. Among the "other events" should be the ambient sounds, such as the sound of the leaves of a tree in the wind, or water dripping. I will have to find new names for these, such as: ambient water drip = drip.au, 10 ambient waterfall = waterfall.au, 20 ambient leaves = # Empty entries are allowed too ambient wind = wind.au, 10 ambient storm = wind.au, 20; lightning.au, 50; wind.au, 20; wind.au, 10 ambient silly example = chill.au, 100 If we want to have lots of sounds in the game, we should also have sounds for the monsters: troll idle = growl.au, 20 troll attack = clunk.au, 100 troll die = crumble.au, 80 dragon idle = growl.au, 40 dragon attack = # The firestorm spell will already make some noise dragon die = sally.au, 100 This should only be done for high-level monsters. I don't want to imagine what could happen when you enter a room with 100 kobolds and 50 goblins and they all start making noises... There are still a few problems: I'm sure that people would like to be able to play specific sounds on the client machine, for an event that is unique to some map or server. I don't know how to handle this. This is the biggest problem in this proposal. Also, more and more machines support stereo sound. Would this be interesting for Crossfire? Should "left" and "right" be associated with "west" and "east" on the map, or should they change according to the direction the player is facing? There should be a way to have background music too, although I don't think this is so important. One way to do it would be to have more entries in the config file (for example, "music 1", "music 2" and so on). All sound types beginning with "music" would be played in a loop instead of being played only once. And only one of them can be played at a time. But using simple numbers for background music would not help people to set the right atmosphere for their map. -Raphael From crossfire-request Wed Dec 13 16:04:47 1995 Return-Path: Received: from tel1.tte.vtt.fi (tel1.tte.vtt.fi [130.188.12.3]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 13 Dec 1995 16:04:47 +0100 Received: (from hat@localhost) by tel1.tte.vtt.fi (8.6.11/8.6.11) id RAA21518 for crossfire@ifi.uio.no; Wed, 13 Dec 1995 17:04:11 +0200 From: Tero Haatanen Message-Id: <199512131504.RAA21518@tel1.tte.vtt.fi> Subject: Re: Mist thoughts (long) To: crossfire@ifi.uio.no Date: Wed, 13 Dec 1995 17:04:11 +0200 (EET) In-Reply-To: <9512131029.AA02213@stealth.eng.pyramid.com> from "Mark Wedel" at Dec 13, 95 10:29:46 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 4972 Status: RO > Sound Improvement: > > I guess Raphael's thought is more that the server will send truly symbolic > commands to the client (ie, "play hit door" sound, vs "play bash.au" sound I think that server should offer all sounds and refer them as symbolic names (or numbers), but how much protocol support is needed to play them? Some that comes to mind are sound, volume, how many times sound is played, and is this a background music? Maybe Raphael can offer some thoughts about this? > DM MODE I meant character name, so that DM could be saved as any other character and when you login the game (using charaster name and password) then if character file have 'was_wiz 1' and 'wiz 1' (?) set then player would be in DM mode. This has nothing to do with dm command. The problem is how those wiz-flags are set in the first place (using the text editor or dm command)? Of course a server could make some extra checks based on hostname, if that level of security is wanted. Client/server: > I am curious (and maybe Tero can answer this) on how important the > underlying eutl library is. Certainly, there are some handy functions here > and there in it, but at the same time, I know that there are areas of the > code that pretty much explicity avoid some functions because of their > overhead. I have looked the code and I have a general idea how the server and client works. It uses eutl library that has not been decumented (it also has is own licance that is not GPL). I think that Eric who made the initial implemetation had used the same library in other project, so it was easy choice for him (even not the rest of us). Basically it offers the TCP/IP sockets and dymamic list structure called ArgList. The later is used to build and send protocol packets. Since the server have already TCP/IP code and the ArgList routines really are overkill to building packets (they dynamically malloc all parameters for every packet) I thought to try build the server without eutl-library. > IT would also seem to me that the eutl library would make porting > to some other systems even more difficult, since the library would also need > to be ported. I agree with this. It probably should compile in many unix systems, but I'm unsure how portable it really is (at least ArgList routines seemed to pack packets portable way). > Things that need to worked out to get if fully playable: > > 1) Magic mapping spell does not work. This is a real problem, and probably needs a general solution. (special command to support magic mapping should be simple). > 2) Containers do not work Hmm, I must look this, it should easy to fix. But the real solution is to redesign whole container model in a server. The original containers were used to make inventories smaller, but client can implement this feature without a server. The real use of containers then are locked chests, bag of holdings and similar items. > 3) things that depend on inventory order will not work, since client > re-orders objects (not much depends on this) I think this should not be a bad problem, please send examples if this is a real problem. Some commands that needs specific items (enchant weapon?) can use either weapon that is applied or apply command can supply the target list (APPLY 'scroll of enchant weapon' 'sword'). If command is applied many items (identify) then it should make no difference (randomly identified objects can be thought as feature). It also makes game more interesting (dip scrolls to water, mix potion, etc) when players are allowed to apply object to other objects. > 4) Only supports XPM mode. Pixmap mode should be supported. I don't know > if there is any good reason to support font mode. The pixmap mode should be simple add when other features works. Since fonts requires that all images are available at startup time, I think that font mode has a low priority (it can be added later without any(?) changes to a protocol. > 5) Client doesn't really do any caching of data. At mininum, I believe > client should be able to cache pixmaps/xpm images. Yes, this is a true and requires some commands at startup time, but remember that the current model don't do it either. > 6) Handling commands from the client. Right now, it pretty much executes > the commands as it gets them. Yes, this really needs to done, but I haven't idea how the timings work on the server side. I have understand correctly there is a way to specify how long different commands take. How this is a implemented and is these times really used anywhere else than moving around? Any comments about this is welcome. I try document the existing protocol and send that to Mark the same time as I send other changes. There are many features that needs to done before the client can replace the current version, but my highest priority currently is get documented protocol and a stable client in which it is easy to add missing features. -Tero From crossfire-request Wed Dec 13 11:30:25 1995 Return-Path: Received: from bertha.pyramid.com (bertha.pyramid.com [129.214.1.100]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Wed, 13 Dec 1995 11:30:23 +0100 Received: from stealth.eng.pyramid.com by bertha.pyramid.com (5.67/OSx5.1a Pyramid-Internet-Gateway) id AA01158; Wed, 13 Dec 95 10:29:48 GMT Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA02213; Wed, 13 Dec 95 10:29:46 GMT Date: Wed, 13 Dec 95 10:29:46 GMT From: mwedel@pyramid.com (Mark Wedel) Message-Id: <9512131029.AA02213@stealth.eng.pyramid.com> To: crossfire@ifi.uio.no Subject: Re: Mist thoughts (long) Status: RO This contains many topics from the 40 or so mail messages that I got in the past few days. Each topic is seperated by a line of hyphens, so it should hopefully make the things you want to know about easier to find. ------------------------------------------------------------------------------ Sound Improvement: Raphael mentioned that he would like to improve sound code, but wait for client/server to do it. A few thoughts: IT seems to me that rewriting the sounds config file isn't really dependant on client server. While this should probably go in the other message I am about to send it, it seems to me that only thing that will really change is how the send information is sent to the client. that is, right now, rplay protocol is used to send sound requests, with client/server, there will be some protocol command that tells the client to play the sound. I guess Raphael's thought is more that the server will send truly symbolic commands to the client (ie, "play hit door" sound, vs "play bash.au" sound ------------------------------------------------------------------------------ DM MODE So it seems a name & associated password might be the way to go (and you then do something like 'dm password and become dm if you have the appropriate name.) This would be easy to change, and could keep it in the existing dm file (could be nice so that you can change dm password without recompiling the program.) Tero Haatanen wrote: >Yes, I wondered why the password was removed and changed to a name check. >Generally I would like that dm would be like other players and using >the player name and password. Of course there is a problem how to make >those dm chacacters in a first place. I have problems really grasping what the last few lines are saying. Is it basically the saying that dm username=character name (ie, what is displayed at the top of the status, vs other username, which is what uid crossfire is running under or what the person specifies as name) I do note that we can verify the host a user is coming from (we can't verify who they are on that host, but client/server doesn't help that out.) person who did most of the work is no longer working on it, and left no documentation on what he had really done so far. Thus, if you want to start working on it/fixing bugs in it, you have to spend quite a bit of time just figuring out what he did/how he sends messages. It doesn't make things easier in that he also decided to use a library that he wrote which does numerous things. Library looks fairly nice, but lacks any documentation. Certainly client/server is the way to go. However, I hardly have the time (or inclination for that matter) to really work on it much - there is still a lot of stuff that needs to be done on the server side of things, and at least I know what that code is doing. As for the idea of not coding stuff on the server that belongs on the client, this is fine as long as the client goes someplace. As I said, I probably won't be working on it. Why current client isn't enough to work with: As I have previously said, even on very fast connected networks (ie, client is running on the same system as the server), there is a noticable lag in the client. Plus there are aspects of the client that are still missing - if you use the client, you aren't getting full functionality of the game (I believe it was missing container support, magic mapping, and seemed to ahve some bugs.) I am glad that at least someone is working on the client - this gives hope that it is going someplace. However, to me at least, the client has to be working at least equally good as the present server method for many people to switch over. If more people want to work on the client server, you are more than welcome to. I will give you whatever support you have, but you might want to contact Tero Haatanen, since he still seems to be working on it, and may know how things work better than I do. What I would really like is some documentation on how the existing stuff works. I have put notes in the Protocol file on the commands I added, and some logic on how they work. Getting this done is really mandatory if we ever hope for clients beyond the one that is presently being worked on. If there is a file the clearly says has data is passed back and forth, people can write their Java or NT or whatever else clients for it. I am curious (and maybe Tero can answer this) on how important the underlying eutl library is. Certainly, there are some handy functions here and there in it, but at the same time, I know that there are areas of the code that pretty much explicity avoid some functions because of their overhead. IT would also seem to me that the eutl library would make porting to some other systems even more difficult, since the library would also need to be ported. All that said, a few notes: A C version of the client/server does exist, and is reasonably playable. Things that need to worked out to get if fully playable: 1) Magic mapping spell does not work. 2) Containers do not work 3) things that depend on inventory order will not work, since client re-orders objects (not much depends on this) A way to handle this might be something like 'S->C:request item_id', and then the player on the client clicks on whatever item 4) Only supports XPM mode. Pixmap mode should be supported. I don't know if there is any good reason to support font mode. 5) Client doesn't really do any caching of data. At mininum, I believe client should be able to cache pixmaps/xpm images. However, to do this would mean increased start time, as client tells server what it already has. The client does handle local commands, and keybindings are stored locally. 6) Handling commands from the client. Right now, it pretty much executes the commands as it gets them. Some form of buffering needs to be added, along with looking at what we got, and perhaps running some out of order. As someone else said, there is little point getting into a discussion of what the client should and should not do. Unless it is rewritten from scratch, what we have in place now will probably remain. One consideration that was made is that the client is assumed to not be secure (with it being in source code, this is a good bet). Thus, information that the player does not know about will not be sent to him. This means that for the visible map, only information about squares that he can see in that area will be sent. Something the next square off will not be sent - player doesn't know about it. Likewise, only basic item information is sent (item name, and appropriate flags). Thus, if the player has a +1 sword but hasn't been identified, as far as the client knows, it is just a sword that weighs a certain amount. That said, it will never be possible to have your character saved locally on the system you are running the client on (without adding special hooks, like a dump player command that the server can choose to respond to.) And at the same time, I never see moving players between servers to happen. Hell, I could start up a server here and make a super character quite easily. I doubt people would like me to move it to some other server where it is very difficult to do that. What the client/server needs more than anything else is for people to actually work on the coding. Saying how/why/what should be done is all great and dandy, but we have already been through that. Now it is just a situation of actually doing it. ------------------------------------------------------------------------------ C++ conversion: I was more just curious to see how close/far it is. I have no plans to convert to C++ anytime in the future. I thought I would just toss out my findings. IF such a conversion was to take place, I think a line by line rewrite would probably be in order. Have the present code in one window, while you type in the new code in another. OF course, I doubt the end product of the conversion would look a lot like the original. I do not think that keeping it in ANSI C will be a major limitation. IF nothing else, at least there are at least several people writing code for it now, with many more at least having some idea what the code presently done. AS previously said, after a conversion, only those involved will really know much about it. ------------------------------------------------------------------------------ Message output: Well, there is already scrollbars in use in crossfire for the inventory and look windows. Since all that code is there, it would at least be worth looking at and seeing if it can at least be generalized some. I don't really like the idea of using some toolkit just for scrollbar usage. Seems like overkill, and probably won't do much for performance either. As for waiting for client: There are at least a few notes - if scrollbar support was added to server, it would be fairly straightforward to add it to the client (most of the existing display code for the client is stuff from the server, just copied over). So certainly, if I add support in the server for it, I would do the same for the client. The bigger issue is how long do I wait for the client to happen. Work started over a year ago on it, and I remember telling friends at the time 'message output is a client issue'. I still believe it is, but unless I see a strong indication that the client is what everyone will be using pretty soon, I find it hard to keep waiting for that. Also, for sites that use X-terminals, a client/server model really adds very little (since the client part will also be running a server, with display going to the terminal). The only major gain in that is that dealign with x-errors won't need to be done. ------------------------------------------------------------------------------ Player interaction: The one question I have on that is: Why would you ever not save in scorn then? If you are high level, it is easy to get back to scorn to save (or other well established in), and typically not that hard to get to where you were. Hell, even if I was a high level person, I don't think I would save out in the woods, just on the off chance that a higher level person might wander buy. The other problem is that when a player saves on some other map, will that map then reset? If not, it then becomes possible for some player to make it so a map can not be accessed by any other players (cleans it out, rolls a boulder in such a way that things are now blocked, etc). If it does recent, then I really doubt a player would want to save on a map, only to rejoin the game later and found out that he has no safe exit back and is surrounded by nasty monsters. Also, I don't know if I would ever really want an AI playing a character. Suppose another player attacks you while you have left, and AI takes over. Now AI thinks that usign that wand of lightning is a good idea, and uses up. You come back, to find out that your wand of lightning is out of charges, and you needed it to kill the monster in the next room. Before any of this takes place, I think AI needs to be improved just so monsters are much smarter (how often do you see vampires and other monsters read scrolls that do them no good?) ------------------------------------------------------------------------------ Exp for levels: Experience is a little strange in crossfire in that how much experience you get also depends on the relative level of the monster. If you notice, at first level you get a reasonable amount of exp for killing kobolds. At 10'th level, you get nothing. At the same time, if you are 8'th level and kill a troll (Say with an arrow of assinating trolls) you get gobs of experience. As you gain a few levels, you don't. This is because the amount of exp you get depends on the relative level of the monster compared to your level (I don't know if with teh skill code if it is still over all level or skill level). IT is pretty much monster level/your level. Thus, at 10'th level, you only get 10% as much exp for killing a kobold as you did at first. This has some good effects and bad effects. On the good side, it means that you can't get to really high level by just killing monsters, since eventually you get 0 exp for them (however, if exp was exponentional, it would take a long time the other way). On the other side, it means that it can be frustrating at some levels, because the monsters you killed a level or 2 ago don't really give you any exp, and you can't handle tougher ones yet. Note that the above formula really makes a difference at low levels (going from level 9 to 10 is a 10% difference. Going from level 4 to 5 is a 25% difference. However, going to level 30 to 31 is around a 3% difference). Thus, at low levels, the amount of exp you get for monsters drastically varies one level to the next, while at high levels, it really doesn't change much at all. This does tend to make it easy to gain levels fairly easily at some point - once you can kill a high exp monster, it now becomes a quest just to find them and kill them. I don't know if each level should be doubled, but I will concede that things may be a bit flat right now (however, I would like to have the skill code played out more to see how it works out). So perhaps the exp should be bumped up. Do people think that relative exp for killing monsters is a good or bad thing? --Mark From crossfire-request Wed Dec 13 05:15:49 1995 Return-Path: Received: from chat.ecp.fr (chat.ecp.fr [138.195.33.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 13 Dec 1995 05:15:48 +0100 Received: from lynx.cti.ecp.fr (lynx.cti.ecp.fr [138.195.33.1]) by chat.ecp.fr (8.7.1/jtpda-5.1) with ESMTP id FAA11539 for ; Wed, 13 Dec 1995 05:16:07 +0100 (MET) Received: from barbara.cti.ecp.fr (aubryl7@linda [138.195.33.59]) by lynx.cti.ecp.fr (8.6.12/jtpda-5.1) with ESMTP id FAA17663 for ; Wed, 13 Dec 1995 05:15:45 +0100 Received: from (aubryl7@localhost) by barbara.cti.ecp.fr (8.6.12/jtpda-5.1) id FAA12554 ; Wed, 13 Dec 1995 05:15:42 +0100 Date: Wed, 13 Dec 1995 05:15:40 +0100 (MET) From: AUBRY Ludovic X-Sender: aubryl7@linda To: crossfire@ifi.uio.no Subject: unsubscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO From crossfire-request Tue Dec 12 09:58:41 1995 Return-Path: Received: from kaukau.comp.vuw.ac.nz (kaukau.comp.vuw.ac.nz [130.195.5.20]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 12 Dec 1995 09:58:34 +0100 Received: from debretts.comp.vuw.ac.nz (debretts.comp.vuw.ac.nz [130.195.8.46]) by kaukau.comp.vuw.ac.nz (8.6.B/8.6.9-VUW) with ESMTP id VAA17329; Tue, 12 Dec 1995 21:57:49 +1300 From: Stephen Wray Received: (stevew@localhost) by debretts.comp.vuw.ac.nz (8.6.10/8.6.6) id VAA03854; Tue, 12 Dec 1995 21:58:05 +1300 Date: Tue, 12 Dec 1995 21:58:05 +1300 Message-Id: <199512120858.VAA03854@debretts.comp.vuw.ac.nz> To: xkd@CSUA.Berkeley.EDU, crossfire@ifi.uio.no In-reply-to: <199512120212.SAA23913@soda.CSUA.Berkeley.EDU> (message from Kundi Xue on Mon, 11 Dec 1995 18:12:19 -0800 (PST)) Subject: Re: I give up. How *do* I set up shop door mats? Reply-to: Steve.Wray@vuw.ac.nz Status: RO -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Kundi" == Kundi Xue writes: Kundi> Hello, Kundi> I just tested out to find that if two doormats are too distant Kundi> apart they don't work. The spacing seemed to have to be less than 4 Kundi> spaces away. But I didn't encounter the problem as you said that Kundi> it works one way and not the other. I discovered what was going wrong... You know how sometimes when you arrive in a shop thru a door and find yourself on a mat, and have to move off the mat and back on to get thru... What I was doing was have a setup like this; |-+ Where M = a mat andD = a door DM| |-+ |M | so when I come thru the door, and am standing on the door, I move onto the outer mat and go thru into the shop. When I move onto the inner mat, I appear not to move. What is *actually* happening (I suspect) is that I am bouncing from the inner to outer mat so fast... Strange how it gives no appearance of change... Strange how it doesn't move you onte the doorway. - --- **********************T***H***E***L***E***M***A********************** 44. For pure will, unassuaged of purpose, delivered from the lust of result, is every way perfect. -- LIBER AL vel LEGIS ******************************IN*LVX********************************* Stephen Wray -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQCVAgUBMM1EECt7qh9JVcfZAQFTYwQAif+iSLxssSKz+h5GeBiw8AqZU2JF9KSJ 1xK7tSx5oo3dF4Jju44SDCTkWXb3Oq/gP5JTXHQ+D3gu6M8GFH66Emndme9XG+eo NW+YLa+AymYGQIBLtLJupEtCjcOgZ3xN+Mrg4Tg0gbH2MVa3QmKGCehJ99xRLly4 geT6o4SoJjI= =UT8j -----END PGP SIGNATURE----- From crossfire-request Tue Dec 12 05:53:02 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 12 Dec 1995 05:52:57 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id XAA01107; Mon, 11 Dec 1995 23:52:07 -0500 Date: Mon, 11 Dec 1995 23:52:07 -0500 (EST) From: Tadah To: "Michael B. Martin" cc: crossfire@ifi.uio.no Subject: Re: Misc notes/thoughts. In-Reply-To: <199512111845.NAA04725@mbmartin.bevc.blacksburg.va.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 11 Dec 1995, Michael B. Martin wrote: > > > Player interactivity I think is the biggest focus we should have on > > crossfire. I love the fact we keep adding to it, it keeps the game > > alive, but as fun as new features are for us, we need to start cleaning > > up some stuff. Make crossfire easier to install/upgrade/addto. Make it > > available, like you just stated, on other OSes like WIn95 (I think Java > > is a superb idea!). Optimize the the game for smaller bandwidth so we > > can get modem players, etc. Also lets put more into the party idea and > > other player to player interaction. > > I agree with this. I think the greatest feature of crossfire is its > multi-player ability, and adding clients for non-UN*X OS's could help > add a *lot* of new players (hopefully not appearing overnight, though, > so those people running servers would have a chance to upgrade the > memory on their machines ;). To this end it would seem to make sense > to have a well-defined client-server model (the server code being > maintained in C or C++, say) with the clients relatively easily > recodable in whatever language you want (having read the propaganda on > Sun's Web site, Java does indeed sound like a good option for a > crossfire client). Happy to see you agree. Like I said, from the programmers point of view, who has no trouble running it the way it is, has much more fun adding new spells, weapons, etc rather then making it more "user friendly". Hey, I can use it now too, so great. But its a hassle each time a new version comes out, or someone releases a addon (or in my case, recently found out about), you have to recompile etc. First off, make easy installation scripts. Or better yet in some cases, compress some already compiled directory trees for popular OSes, like Linux (I think thats what most of us use, or SunOS, right?), etc. Some great documentation would be nice too. Heck, I'd like to write it (Yes, I am very capable of writing better then this. This is my "I've still got 400messages to go" writing style) myself but I'm still finding things out about the game. Would love at least a brief summary text on all commands, spells so far. Things like that would make this game extremely popular. > Now, I admit to knowing practically nothing about how the current > client/server stuff works. However, IMHO, the client should handle > the game window(s), including keeping a list of the players inventory > and position. When there is an input event (key, mouse, etc.), the Actually. I'm glad you brought this up. I have an idea.. :> ATTENTION all programmers.. Idea here.. :> Why not have encrypted RSA player files kept on the players computer? Netrek does something like this with its clients so that people can't mod clients and cheat. Why not do this with player files, and to what advantage? It would be great to be able to move your player to other servers should a server go down, become slow, or whatever. No? Well, anyway. Just an idea.. :> > event gets processed by the client and is forwarded to the server if > appropriate. The client should be in charge of managing map/item > graphics and any scrolling of windows (as recently suggested--I think > just making the spell list pageable like shop inventories would be the > best quick (?) option). Some people requested the ability to play > over a modem. I don't think that is reasonable unless the client has > its own copy of the bitmaps/pixmaps (and sounds, if desired), the way > many games like Doom achieve great multi-player speed). Sending the > pixmaps over the network is just too slow without Ethernet speeds > (even with Ethernet it would make things faster). The only data > that should have to pass between the client and server include updates > on positions, item pickups/drops, etc, i.e. information that > corresponds to an interaction between the player and the crossfire > world. If a player resorts his inventory, for example, the server > need not know this (have the client handle it). Then if the player > wants to apply an "Enchant Weapon" scroll to the weapon he just moved > to the top of this inventory, the client tells the server that player > such-and-such is trying to apply the scroll, and that weapon X is the > first item in his inventory. Does this sound feasible? Right now it > seems to me that the server has so much to do that a good client could > handle instead that the server would not be able to support a very > large number of players (when in fact it could if the client took on a > much larger share of the work). Exactly! I am on a 57.6k direct connection and still feel everything is just too slow. We are all using the same maps, aren't we? Even if we weren't, what would be nice is some kind of one-time updating system. Maybe a directory for each server your on (In case the maps are different at all), in that will be stored all maps, pics, etc that are needed. A file in that directory will tell the server when this directory has last been updated. If there are newer items, maps, etc.. It would then know how much must be updated on the players side so that a whole resend need not be the case. If every client carried their own load, play would be so much more faster!! > > Also, why make the player disappear when you save for the day? I > > remember playing RPG type games on BBSes, some of you might remember > > them.. "Land of Devestation (LOD)", "Operation OverKill", etc. They > > were pretty fun, allowed teams, also allowed the build of forts which > > would be a cool idea for crossfire. If a player saves in a inn, fine, > > can't touch him. But allow for camping out. Be able to save anywhere, > > but if your not in a well built inn (like in Scorn city, not like in port > > joesph where you have to watch your back ), leave some chances to at > > least get something stolen from the player if another player finds him in > > a not well protected area. Also, allow fighting when the other player is > > not on, assign some AI values to the otherwise inactive player. Sound > > cruel? Not if its not made to penilize the player that is not on. Make > > it so the active player can gain exp, etc from the player he killed, but > > still maintain the players save file, changing little if at all. > > Well, for starters, crossfire is currently such that you must use a > "bed to reality" to sleep/save your character. So at this time you > can't save your guy just anywhere (anyone tried carrying a bed to > reality around?). If people really want this feature, perhaps someone > could create a "bedroll to reality" or something similar which you Actually, it does work right now. Ever messed with the client on just your local machine? type "'save" and you'll see it acts the exact same way as if you applied the bed to reality. I must confess to why I know this to be true.. I (In the spirit of learning the technical aspects of the game of course) typed the save command, then copying my .pl file to a backup file just before I did something major. If I messed up, I copied it back then started playing again. It starts right at the very spot you typed save. So yes, it is very possible. Its in there matter a fact. :> > could easily carry. But when you use it your guy would "disappear" > under the current code while sleeping, so you couldn't steal stuff or Well, I'm sure it couldn't be too hard to change it arround so that the character doesn't disapper. Maybe simply make him disapper, copy the character file over to a temp NPC file, stick the NPC in a sleep state, wola. Or something like that. :> > kill him. At any rate, I would not save *my* character in the woods > if he could be attacked. Supposedly, you do get experience for Well. I suppose we could get some incentives in there. And sometimes its just easier to save near the area your working in. The place your currently at may not be near anything safe. Some of these dungeons are quite huge and its hard to imagine anyone completing them in one day. SO why not be able to camp inside of them? Which is ok as long as the area is secured first. Also, what about the small towns/villages that don't have guards in them? Any place with a guard could be deamed totally safe for the player. Places without town guards, even inns, could be considered risky places to sleep. But even then, why not make it no risk whatsoever for the player that goes to sleep? When he wakes up, he would have lost nothing, or like I said, loss something small for getting killed (whatever). The player who attacked and wins gets all. > killing other characters at this time, but not that much (and the risk > may not be worth it--ever try to kill a 60+ level character? It's not Well, thats the players judgement on what he should, should not attack. :> -Link From crossfire-request Tue Dec 12 05:18:22 1995 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 12 Dec 1995 05:18:21 +0100 Received: (philb@localhost) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) id UAA04845; Mon, 11 Dec 1995 20:18:09 -0800 From: Philip Brown Message-Id: <199512120418.UAA04845@soda.CSUA.Berkeley.EDU> Subject: Re: Misc notes/thoughts. To: duncan@HASP.com (Duncan J Watson) Date: Mon, 11 Dec 1995 20:18:01 -0800 (PST) Cc: martinm@mbmartin.bevc.blacksburg.va.us, krisb@seattleu.edu, crossfire@ifi.uio.no In-Reply-To: <9512111852.ZM100@titan.hasp.com> from "Duncan J Watson" at Dec 11, 95 06:52:13 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 809 Status: RO This person is confused when it comes to java. >>>>[From Duncan J Watson] There are java clients on many platforms. Java support is now in Netscape v2.0 Betas, freely available and the HotJava browser has had an official port by Sun to Win32 which includes WinNT and Win95. Hotjava is still using the alpha version of java. Which makes it almost useless for these purposes. Netscape provides support for the following platforms: Win 3.1x Win 95 Win NT MacOS Unix: HP-UX, IRIX, Sun Solaris, and SunOS . Netscape runs under the above platofrms. However, there is no java support in the win3.1 and MacOS versions. ( I THINK it works with the win95 version... but I'm not so sure) The official beta JDK is available only for Solaris 2.[345], MSwin95, or NT. From crossfire-request Tue Dec 12 04:58:38 1995 Return-Path: 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 ; Tue, 12 Dec 1995 04:58:37 +0100 Received: from zaphod.astro.psu.edu by nexus.astro.psu.edu (4.1/Nexus-1.3) id AA20488; Mon, 11 Dec 95 22:58:47 EST Received: by zaphod.astro.psu.edu (4.1/Client-1.3) id AA21932; Mon, 11 Dec 95 22:58:34 EST Date: Mon, 11 Dec 95 22:58:34 EST From: "Brian Thomas" Message-Id: <9512120358.AA21932@zaphod.astro.psu.edu> To: crossfire@ifi.uio.no Subject: invoke bug Status: RO I was wrong. The problem was with the handling of check_skill_to_fire() which should have , but wasnt called by the invoke command. I put a patch tar file in my directory /pub/thomas on ftp.astro.psu.edu. The tar file is called invoke.tar.gz. b.t. From crossfire-request Tue Dec 12 04:33:12 1995 Return-Path: Received: from eden-valley (eden-valley.aaii.oz.AU [192.35.59.242]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 12 Dec 1995 04:33:07 +0100 Received: from yarra-glen.aaii.oz.AU by eden-valley with SMTP (5.65c/SMI-4.0/AAII) id AA12879; Tue, 12 Dec 1995 14:32:21 +1100 Received: from nagambie (nagambie [192.35.59.17]) by yarra-glen.aaii.oz.au (8.6.8.1/8.6.6) with SMTP id OAA14084 for ; Tue, 12 Dec 1995 14:32:22 +1100 Message-Id: <199512120332.OAA14084@yarra-glen.aaii.oz.au> X-Authentication-Warning: yarra-glen: Host nagambie didn't use HELO protocol To: crossfire@ifi.uio.no From: "Rupert G. Goldie" Reply-To: rgg@aaii.oz.au Subject: Re: Crossfire port In-Reply-To: Message from "W.E.B" of 1995-Dec-11 18:48:5, <199512120248.SAA06805@hunter.cs.unr.edu> Date: Tue, 12 Dec 1995 14:32:18 +1100 Sender: rgg@aaii.oz.au Status: RO "W.E.B" wrote: > I just thought I'd let you know that the class is porting Crossfire to Java. [...] > Additionally I should say that you shouldn't worry about it too much > since it probably will be a significant rewrite. We're starting in about > two weeks, the deadline is March 31. The primary discussion we've > involved ourselves in is how to make the game more dynamic, expandable or > evolvable. There are a lot of *very* fresh ideas, we hope to let you hear > about what we're doing as it happens. It would be good if your implementation used a client/server model and used the protocol that is currently defined. That would mean that people could use your Java client with the current crossfire. -- Rupert G. Goldie, Research Scientist rgg@aaii.oz.au Australian Artificial Intelligence Institute /\/\|| Level 6, 171 Latrobe Street, Melbourne, Australia From crossfire-request Tue Dec 12 03:12:19 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 12 Dec 1995 03:12:18 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id VAA00471; Mon, 11 Dec 1995 21:12:16 -0500 Date: Mon, 11 Dec 1995 21:12:16 -0500 From: Brian Thomas Message-Id: <199512120212.VAA00471@chaupher.gsfc.nasa.gov> To: crossfire@ifi.uio.no, celear@teaching.cs.adelaide.edu.au Subject: Re: Experience Status: RO > From: Colin writes: > > I have inadvertantly discovered a very real problem with > invoking spells. > > As a matter of habit from the days when I used to cheat > I got used to invoking all my spells. Now with the new skills > I can raise my level in any skill I wish merely by > using invoke while my skill field is set to whatever > skill I wish to improve in. > Indeed. I just checked this out. I will send a patch to Mark as soon as I can find a good solution for it. The one I am thinking of now will work; but will treat the invoke command a "special case" in the code. Kinda yucky solution if you ask me. > > Can this be easily fixed or is it as I think something > inherent in the game setting the skill flag when you invoke > a spell doesn't stop you from barging off and fighting > something thereby changing your skill flag. > The fix is fairly easy (if you dont care about its 'beauty'). The problem comes because when you gain experience the code is set up to add exp to the experience category of the current skill in use. In the case where we might gain xp from an object controlled by the player (like killing stuff with spells eg. 'golem' or 'fireball') the controlled object gets a pointer set to the appropriate experience category (based on the current skill in use). Objects created by the spell object (such as the exploding fragments of a bomb) inherit the pointer. Thus, if you cast a spell, then decide to pick a lock while the spell is still killing stuff, the gained xp still goes to the right place. The problem with invoking spells is that the correct skill is never readied by the code; at first look this is a result of the NO_AUTO_SKILL_SWITCH, but I am not sure yet. Again, I will post a patch to Mark when I have it figured out. -b.t. From crossfire-request Tue Dec 12 03:48:11 1995 Return-Path: Received: from hunter.cs.unr.edu (hunter.cs.unr.edu [134.197.40.62]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 12 Dec 1995 03:48:10 +0100 Received: (from bull@localhost) by hunter.cs.unr.edu (8.6.9/8.6.9) id SAA06805 for crossfire@ifi.uio.no; Mon, 11 Dec 1995 18:48:06 -0800 From: "W.E.B" Message-Id: <199512120248.SAA06805@hunter.cs.unr.edu> Subject: Crossfire port To: crossfire@ifi.uio.no Date: Mon, 11 Dec 95 18:48:05 PDT X-Mailer: ELM [version 2.2 PL16] Status: RO I just thought I'd let you know that the class is porting Crossfire to Java. Although this may seem odd but there are quite of few reasons behind it. I'll send out some mare mail later when I have time, but generally the distributed processing behind it will reach a *great* deal more people. Additionally I should say that you shouldn't worry about it too much since it probably will be a significant rewrite. We're starting in about two weeks, the deadline is March 31. The primary discussion we've involved ourselves in is how to make the game more dynamic, expandable or evolvable. There are a lot of *very* fresh ideas, we hope to let you hear about what we're doing as it happens. -web From crossfire-request Wed Dec 13 02:01:38 1995 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Wed, 13 Dec 1995 02:01:37 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 12 Dec 1995 20:00:40 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 12 Dec 1995 19:59:41 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Sat, 9 Dec 1995 20:45:00 -0500 Date: Mon, 11 Dec 1995 19:45:00 -0600 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.017:13.11.95.00.59.41] X400-Content-Type: P2-1984 (2) Content-Identifier: re:Sounds (wa... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"19036 Tue Dec 12 19:59:58 1995"@bnr.ca> To: Raphael.Quinet@eed.ericsson.se Cc: link@acy.digex.net, crossfire@ifi.uio.no Subject: re:Sounds (was Re: Environment variables of client) Status: RO In message "Sounds (was Re: Environment variables of client)", 'Raphael.Quinet@eed.ericsson.se' writes: >The first improvement would be to re-write the syntax of the "lib/sounds" >file which defines which sound has to be played when some event occurs. >Instead of relying on the entries to be in a fixed order, I would use symbolic >names for each type of event. For example, the new file could have lines >like these: > hit door = crush.au, 80 # = , > hit ennemy = tap2.au, 100 > small fireball = Whoosh.au, 70 > large fireball = Whoosh.au, 100 >It would then be easier to maintain this file, and it wouldn't be a problem >if the number of spells changes. I would like to added to the format the number of times (or looping). For example, magic missiles = 3, Whoosh.au, 50 or better yet, able to specified as many sounds to a particular action comet = Whoosh.au, 70; Boom.au, 100 >Another improvement would be to use "environmental" sounds; that would add >a lot to the atmosphere. Those who have played games like Hexen know what I >mean. It should be possible to add some new "sound" archetypes that can be >placed on a map and play sounds from time to time. For example, a player >could hear the water dripping if he/she comes near a pit, owls crying in the >forest, bells ringing in the church, etc. The new proposal for "weather >effects" would also be a great way to add environmental sounds: a storm could >make a lot of noise. And of course, the monsters could be noisy too. This would be great; but make sure that the volume is low (or at least settable by the user) >I have several other ideas and I know how to add some of them to the code, >but I don't want to add this to the current code. It would be much easier >to write and to maintain the new sounds code if CrossFire was really split >between a client and a server, like this was discussed some time ago. Will >this ever be done? > >-Raphael It's great to see that proposals for "better" crossfire comes in many directions. From crossfire-request Tue Dec 12 01:20:06 1995 Return-Path: Received: from chopper.poohsticks.org (root@drew-to-hub.village.org [198.137.146.27]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 12 Dec 1995 01:20:01 +0100 Received: from chopper.poohsticks.org (localhost [127.0.0.1]) by chopper.poohsticks.org (8.6.12/8.6.6) with ESMTP id RAA20629; Mon, 11 Dec 1995 17:19:15 -0700 Message-Id: <199512120019.RAA20629@chopper.poohsticks.org> To: "Kristofer M. Bosland" cc: GESTIONNAIRE DU Casino , "Michael B. Martin" , Tadah , crossfire@ifi.uio.no Subject: Re: Misc notes/thoughts. In-reply-to: Your message of "Mon, 11 Dec 1995 15:46:40 PST." Date: Mon, 11 Dec 1995 17:19:14 -0700 From: Drew Eckhardt Status: RO In message , krisb@seat tleu.edu writes: > >On Mon, 11 Dec 1995, GESTIONNAIRE DU Casino wrote: > >> On Mon, 11 Dec 1995, Kristofer M. Bosland wrote: >> >> >> So when you leave a map, you flush all the data for it, and load all the >> new one... Why not do a bit a caching ? >> Usually maps won't change a lot.... So the client could keep the maps in >> memory for a certain amount of time, say 10 minutes, and when the player >> enters a map, the client either asks for the whole map, if it doesn't >> have it in memory, or aks for a diff since time x. >> But then, the server needs to remember :-) >> What is the important factor ? optimising the client/server >> communication, or the memory requirement of both client and server ? >> >> --- >> Casino >> > > Well, first I think that this is less important than agreeing on >the "Architecture" of the communiation. By this, I mean to address >Orthoganality and Generality, and to enable more possible clients (i.e. >Tcl/Tk can't handle 0x00 generally, so text based communication is better >than some binary format). The Servers memory requirements will probably >not change much, but may go down (I wouldn't expect the server to remember >what the clients contain). As far as BW Vs. Client Memory Requirements, I >think that we should lean towards more mem, less BW. The choke point for >many people is their 1 byte/sec comm link, not their 100MHz CPU or 8MB >Memory. Latency is the other big issue - it takes me 500ms and 30,000 miles to make the round trip between my house and office three miles down the road. From crossfire-request Tue Dec 12 00:03:17 1995 Return-Path: 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, 12 Dec 1995 00:03:16 +0100 Received: (from martinm@localhost) by mbmartin.bevc.blacksburg.va.us (8.6.12/8.6.9) id TAA04934; Mon, 11 Dec 1995 19:04:53 -0500 From: "Michael B. Martin" Message-Id: <199512120004.TAA04934@mbmartin.bevc.blacksburg.va.us> Subject: Re: Misc notes/thoughts. To: krisb@seattleu.edu (Kristofer M. Bosland) Date: Mon, 11 Dec 1995 19:04:52 -0500 (EST) Cc: crossfire@ifi.uio.no In-Reply-To: from "Kristofer M. Bosland" at Dec 11, 95 11:06:44 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1389 Status: RO > I was thinking of Tcl/Tk, which has also been recently ported to > WinDoze, and the Mac. Does Java have a working interpreter on these > platforms, or are they in the works? > > -Kris Bosland > krisb@seattleu.edu Hmm, Java is pretty new, and I don't think they have many (any?) stand-alone interpreters yet for non-Sun platforms, especially for Mac/MS-Windows. Sun's Web site should have the definitive answer on this. Netscape 2.0 (including the latest beta, I think) is supposed to have support for Java apps, but I don't know exactly what that means. On the other hand, Tcl has been around a long time and, as you say, has been widely ported, so it might be a good first choice (do it in Tcl/Tk and then maybe Java later). I suggested Java because it sounds like it's rather similar to C/C++ (thus potentially less porting work). Someone (sorry, I'm too busy at the moment to look up the reference--you know who you are) asked about whether communication bandwidth or memory requirements was a higher priority. If people want to play using modems, I think the former is definitely the higher priority. Even a "fast" 28.8k modem can't sustain a full 4KB/s (uncompressed), which isn't much bandwidth. Also, I think it's reasonable to expect players to have, say, 4MB of RAM on their (client) machine reserved for crossfire. That should be plenty. -Michael From crossfire-request Mon Dec 11 23:59:07 1995 Return-Path: Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 23:59:00 +0100 Message-Id: <199512112259.XAA25777@ifi.uio.no> Received: from staff.cs.su.oz.au by staff.cs.su.OZ.AU (mail from ftww for crossfire@ifi.uio.no) with MHSnet; Tue, 12 Dec 1995 09:58:49 +1100 Subject: Re: Misc notes/thoughts. To: crossfire@ifi.uio.no Date: Tue, 12 Dec 1995 09:58:44 +1000 (EST) From: "Fred the Wonder Worm" In-Reply-To: <9512110809.AA13635@stealth.eng.pyramid.com> from "Mark Wedel" at Dec 11, 95 08:09:52 am X-Face: )\c`u_%V|7EQUDUt%5v'IJ?=@^Wf^<#,~CjzL`/2q0=-O6XW/Z8A2j.kgg:| 7|YZPSxy}rIuw8qD|/cQZ9^6kb:1XLleXhOl-U>(c~d`bC)%7FItZOUEw?=x%TBQ~NFJ,U|3wi[jzXd5-bMC Reply-To: ftww@cs.su.oz.au Content-Type: text Content-Length: 2426 Status: RO > So I have 2 questions: Any reason not to just go back to a global > password for dm access? It gives just as good security as exists now. Or > should dm protection be improved (also include authorized hosts/displays > to become dm from. Or may add passwords in addition to just names - at > least it would be 2 things that need to be guessed.) The other is, is there > really any reason to restrict dm access from sockets? Ok. That is more > than 2 questions. Dm mode should be password protected. Maybe with multiple passwords (any one of which will work), but you should definitely need to know a password. I don't see any good reason why you shouldn't be able to use dm mode from sockets. > Third: Message output. A few days ago, I think I said I would probably > come up with something that would do paging. But what someone just mentioned > made a lot of sense - add a scrollbar. Originally, it was my opinion > that this is something that is better suited for the client (actually, > it is still my opinion, but the client isn't going anyplace right now.) Agreed. This is definitely a client problem. As for getting the client thing happening, I think that what is needed is a mindless version to get the ball rolling. In the server, translate any X calls into some ASCII form and send that. The client can then convert them back into X commands. Likewise for any client events. _Don't_ try to be clever and save lots of bandwidth - I think this is where the previous discussions got bogged down, arguing the merits of ASCII vs binary and TCP vs UDP, and trying to get great algorithms to minimise bandwidth for changes in field of view. I would use ASCII to start with for its ease of debugging. Once there's a working client server separation, then all sorts of things can be improved - clients can do funky scrolling, remember parts of maps no longer visible; protocol can be worked on so that it actually does save bandwidth, etc. But the big hurdle is the initial separation. Anyone out there got the time and inclination? (I have the inclination, but not the time. :( ) Cheers, Geoff. ------------------------------------------------------------------------------- Geoff Bailey (Fred the Wonder Worm) | Programmer by trade -- ftww@cs.su.oz.au | Gameplayer by vocation. ------------------------------------------------------------------------------- From crossfire-request Tue Dec 12 01:23:13 1995 Return-Path: Received: from eden-valley.aaii.oz.au (eden-valley.aaii.oz.AU [192.35.59.242]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 12 Dec 1995 01:23:07 +0100 Received: from yarra-glen.aaii.oz.AU by eden-valley with SMTP (5.65c/SMI-4.0/AAII) id AA10238; Tue, 12 Dec 1995 10:58:39 +1100 Received: from nagambie (nagambie [192.35.59.17]) by yarra-glen.aaii.oz.au (8.6.8.1/8.6.6) with SMTP id KAA12579 for ; Tue, 12 Dec 1995 10:58:40 +1100 Message-Id: <199512112358.KAA12579@yarra-glen.aaii.oz.au> X-Authentication-Warning: yarra-glen: Host nagambie didn't use HELO protocol To: crossfire@ifi.uio.no From: "Rupert G. Goldie" Reply-To: rgg@aaii.oz.au Subject: Re: Misc notes/thoughts. In-Reply-To: Message from "Michael B. Martin" of 1995-Dec-11 19:4:52, <199512120004.TAA04934@mbmartin.bevc.blacksburg.va.us> Date: Tue, 12 Dec 1995 10:58:38 +1100 Sender: rgg@aaii.oz.au Status: RO "Michael B. Martin" wrote: > Someone (sorry, I'm too busy at the moment to look up the > reference--you know who you are) asked about whether communication > bandwidth or memory requirements was a higher priority. If people > want to play using modems, I think the former is definitely the higher > priority. Even a "fast" 28.8k modem can't sustain a full 4KB/s > (uncompressed), which isn't much bandwidth. Also, I think it's > reasonable to expect players to have, say, 4MB of RAM on their > (client) machine reserved for crossfire. That should be plenty. The initial spec aimed to support reasonable play over 9600bps. It is possible to play crossfire over a 9600bps line. I have done it. I was running X on a Linux box and ran crossfire in font display mode and had a copy of the font on my local machine. crossfire was running on the remote machine and displaying on my Linux box. -- Rupert G. Goldie, Research Scientist rgg@aaii.oz.au Australian Artificial Intelligence Institute /\/\|| Level 6, 171 Latrobe Street, Melbourne, Australia From crossfire-request Tue Dec 12 01:22:30 1995 Return-Path: Received: from eden-valley.aaii.oz.au (eden-valley.aaii.oz.AU [192.35.59.242]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 12 Dec 1995 01:22:23 +0100 Received: from yarra-glen.aaii.oz.AU by eden-valley with SMTP (5.65c/SMI-4.0/AAII) id AA10204; Tue, 12 Dec 1995 10:54:12 +1100 Received: from nagambie (nagambie [192.35.59.17]) by yarra-glen.aaii.oz.au (8.6.8.1/8.6.6) with SMTP id KAA12562 for ; Tue, 12 Dec 1995 10:54:13 +1100 Message-Id: <199512112354.KAA12562@yarra-glen.aaii.oz.au> X-Authentication-Warning: yarra-glen: Host nagambie didn't use HELO protocol To: crossfire@ifi.uio.no From: "Rupert G. Goldie" Reply-To: rgg@aaii.oz.au Subject: Client/Server Date: Tue, 12 Dec 1995 10:54:11 +1100 Sender: rgg@aaii.oz.au Status: RO Before everyone gets too excited defining a client/server protocol I suggest you have a look at the one which was beaten out on this list a year or so ago. You will find it in the crossfire-0.92.1.client directory as a file called (guess what) Protocol. Java would be a good language for implementing the client as it is currently ported to Solaris (that's the baseline), Windows NT, Win 95, Netscape have java support in their SunOS netscape. There are at least two companies porting to the Mac. Someone is doing an OSF port for the alpha. Now that Microsoft have licensed Java from Sun (insert gratuitous smirking), Java is pretty well assured of becoming widespread. However, given the protocol, the client could be implemented in any language. There is currently a C version of the client - is anyone using it ? -rgg -- Rupert G. Goldie, Research Scientist rgg@aaii.oz.au Australian Artificial Intelligence Institute /\/\|| Level 6, 171 Latrobe Street, Melbourne, Australia From crossfire-request Tue Dec 12 00:48:07 1995 Return-Path: Received: from dockmaster.hasp.com (dockmaster.hasp.com [204.5.88.177]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 12 Dec 1995 00:48:06 +0100 Received: (from news@localhost) by dockmaster.hasp.com (8.6.9/8.6.9-djw) id PAA01745; Mon, 11 Dec 1995 15:50:05 -0500 Received: from rigel.hasp.com(204.5.89.50) by dockmaster.hasp.com via smap (V1.3) id sma001743; Mon Dec 11 15:49:57 1995 Received: from titan.hasp.com (titan.hasp.com [204.5.89.46]) by rigel.hasp.com (8.6.12/8.6.12) with SMTP id SAA01044; Mon, 11 Dec 1995 18:46:01 -0500 From: duncan@hasp.com (Duncan J Watson) Message-Id: <9512111852.ZM100@titan.hasp.com> Date: Mon, 11 Dec 1995 18:52:13 -0500 In-Reply-To: "Michael B. Martin" "Re: Misc notes/thoughts." (Dec 11, 7:04pm) References: <199512120004.TAA04934@mbmartin.bevc.blacksburg.va.us> X-Mailer: ZM-Win (3.2.1 11Sep94) To: "Michael B. Martin" , krisb@seattleu.edu (Kristofer M. Bosland) Subject: Re: Misc notes/thoughts. Cc: crossfire@ifi.uio.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: RO On Dec 11, 7:04pm, Michael B. Martin wrote: > Subject: Re: Misc notes/thoughts. > > > I was thinking of Tcl/Tk, which has also been recently ported to > > WinDoze, and the Mac. Does Java have a working interpreter on these > > platforms, or are they in the works? > > > > -Kris Bosland > > krisb@seattleu.edu > > Hmm, Java is pretty new, and I don't think they have many (any?) > stand-alone interpreters yet for non-Sun platforms, especially for > Mac/MS-Windows. Sun's Web site should have the definitive answer on > this. Netscape 2.0 (including the latest beta, I think) is supposed > to have support for Java apps, but I don't know exactly what that > means. On the other hand, Tcl has been around a long time and, as you > say, has been widely ported, so it might be a good first choice (do it > in Tcl/Tk and then maybe Java later). I suggested Java because it > sounds like it's rather similar to C/C++ (thus potentially less > porting work). [snip] There are java clients on many platforms. Java support is now in Netscape v2.0 Betas, freely available and the HotJava browser has had an official port by Sun to Win32 which includes WinNT and Win95. It does not run under Win32s since it requires thread support. Netscape provides support for the following platforms: Win 3.1x Win 95 Win NT MacOS Unix: HP-UX, IRIX, Sun Solaris, and SunOS . The version of Java that Netscape supports is the beta version not the alpha version. They are not compatible with one another though Sun provides utilities to convert alpha java into beta java. You can get more Java info from http://java.sun.com/ Java has won the battle, Microsoft, IBM, and Adobe have all licensed it. Safe Tcl development has been stagnant because Java is so cool. I would support Java for any client development. djw -- Duncan J Watson Email:Duncan@hasp.com Tech Support Manager/Sys Admin Ph#: +1 212 564 5678 Aladdin Software Security Inc Fax#: +1 212 564 3377 :::finger Duncan@hasp.com for PGP key::: http://www.aks.com/ From crossfire-request Tue Dec 12 01:03:09 1995 Return-Path: Received: from elvis.seattleu.edu (elvis.seattleu.edu [199.237.224.12]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 12 Dec 1995 01:03:08 +0100 Received: from handel.seattleu.edu.seattleu.edu by elvis.seattleu.edu (4.1/SMI-4.1) id AA07923; Mon, 11 Dec 95 15:59:34 PST Received: by handel.seattleu.edu.seattleu.edu (4.1/SMI-4.1) id AA03921; Mon, 11 Dec 95 15:59:13 PST Date: Mon, 11 Dec 1995 15:46:40 -0800 (PST) From: "Kristofer M. Bosland" Subject: Re: Misc notes/thoughts. To: GESTIONNAIRE DU Casino Cc: "Michael B. Martin" , Tadah , crossfire@ifi.uio.no In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 11 Dec 1995, GESTIONNAIRE DU Casino wrote: > On Mon, 11 Dec 1995, Kristofer M. Bosland wrote: > > > So when you leave a map, you flush all the data for it, and load all the > new one... Why not do a bit a caching ? > Usually maps won't change a lot.... So the client could keep the maps in > memory for a certain amount of time, say 10 minutes, and when the player > enters a map, the client either asks for the whole map, if it doesn't > have it in memory, or aks for a diff since time x. > But then, the server needs to remember :-) > What is the important factor ? optimising the client/server > communication, or the memory requirement of both client and server ? > > --- > Casino > Well, first I think that this is less important than agreeing on the "Architecture" of the communiation. By this, I mean to address Orthoganality and Generality, and to enable more possible clients (i.e. Tcl/Tk can't handle 0x00 generally, so text based communication is better than some binary format). The Servers memory requirements will probably not change much, but may go down (I wouldn't expect the server to remember what the clients contain). As far as BW Vs. Client Memory Requirements, I think that we should lean towards more mem, less BW. The choke point for many people is their 1 byte/sec comm link, not their 100MHz CPU or 8MB Memory. -Kris Bosland krisb@seattleu.edu From crossfire-request Tue Dec 12 00:02:04 1995 Return-Path: Received: from norbert.int.titech.ac.jp (norbert.int.titech.ac.jp [131.112.189.1]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 12 Dec 1995 00:02:00 +0100 Received: by norbert.int.titech.ac.jp (5.65+1.6W/tit-mx1.1); Tue, 12 Dec 95 08:05:00 JST Received: by kasumi.int.titech.ac.jp (4.1/titint-1.1/SS) id AA08465; Tue, 12 Dec 95 07:59:49 JST Message-Id: <9512112259.AA08465@kasumi.int.titech.ac.jp> To: crossfire@ifi.uio.no Subject: Bug report Mime-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Date: Tue, 12 Dec 1995 07:59:48 +0900 From: Supachai Vorapojpisut Status: RO I have found an error occured while trying to play crossfire 0.92.1 in my Linux machine. Now, I use Linux from Slackware 3.0 with kernel 1.2.13 and gcc 2.7.0. I can compile it with no error but when I tried to call crossfire, it said `Error getting protobyname'. Since I am a new one in this world, I don't know what it's mean. The second bug is in map. I found that the map in subdirectory `thomas' seem to contain several archetypes that not match with predefined archetypes that come with standard crossfire. For example, I found `farmland', t_thouse etc. ************************************************************************* Supachai Vorapojpisut (B) CU-Intania 70 ------------------------------------*------------------------------------ Hara lab. Dept. of Control System | Meijirodai Gakusei Heim Tokyo Institute of Technology | 1-32-5 Zoshigaya, Toshima-ku 4259 Nagatsuta-cho, Midori-ku, | Tokyo 171, Tokyo Yokohama 227, Japan | Tel: (813)3983-3272 Ext.405 Tel: (8145)924-5530 | supachai@int.titech.ac.jp | ************************************************************************* From crossfire-request Mon Dec 11 22:57:59 1995 Return-Path: Received: from harfang.CC.UMontreal.CA (harfang.CC.UMontreal.CA [132.204.2.102]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 22:57:57 +0100 Received: from epsom.jsp.umontreal.ca (epsom.JSP.UMontreal.CA [132.204.45.25]) by harfang.CC.UMontreal.CA with ESMTP id QAA02563 (8.6.11/IDA-1.6); Mon, 11 Dec 1995 16:56:54 -0500 Received: from derby.jsp.umontreal.ca (derby.jsp.umontreal.ca [132.204.46.26]) by epsom.jsp.umontreal.ca via ESMTP (950911.SGI.8.6.12.PATCH825/5.17) id QAA03833 ; Mon, 11 Dec 1995 16:58:05 -0500 Received: (from casino@localhost) by derby.jsp.umontreal.ca (950911.SGI.8.6.12.PATCH825/5.17) id QAA29313 ; Mon, 11 Dec 1995 16:57:41 -0500 Date: Mon, 11 Dec 1995 16:57:41 -0500 (EST) From: GESTIONNAIRE DU Casino To: "Kristofer M. Bosland" cc: "Michael B. Martin" , Tadah , crossfire@ifi.uio.no Subject: Re: Misc notes/thoughts. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 11 Dec 1995, Kristofer M. Bosland wrote: > I was thinking of just keeping the objects relating to the player, > and the objects on the map the player was in. This would then be flushed > everytime the player change maps. I don't expect much more than an order > of 1k objects per map, which means with text names you should be below > ~50k for this. Without this mechanism, the Client/Server traffic would be > dominated by "refreshes" of data containing objects that have not > changed/moved (Client: "Is that Grass still there?"; Server: "Yeah"; > Client "I'll draw it again, then..."). I think a differential approach > would be much lower bandwidth. So when you leave a map, you flush all the data for it, and load all the new one... Why not do a bit a caching ? Usually maps won't change a lot.... So the client could keep the maps in memory for a certain amount of time, say 10 minutes, and when the player enters a map, the client either asks for the whole map, if it doesn't have it in memory, or aks for a diff since time x. But then, the server needs to remember :-) What is the important factor ? optimising the client/server communication, or the memory requirement of both client and server ? --- Casino From crossfire-request Mon Dec 11 22:49:24 1995 Return-Path: Received: from harfang.CC.UMontreal.CA (harfang.CC.UMontreal.CA [132.204.2.102]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 22:49:23 +0100 Received: from epsom.jsp.umontreal.ca (epsom.JSP.UMontreal.CA [132.204.45.25]) by harfang.CC.UMontreal.CA with ESMTP id QAA02285 (8.6.11/IDA-1.6 for ); Mon, 11 Dec 1995 16:48:48 -0500 Received: from derby.jsp.umontreal.ca (derby.jsp.umontreal.ca [132.204.46.26]) by epsom.jsp.umontreal.ca via ESMTP (950911.SGI.8.6.12.PATCH825/5.17) id QAA03537 for ; Mon, 11 Dec 1995 16:50:00 -0500 Received: (from casino@localhost) by derby.jsp.umontreal.ca (950911.SGI.8.6.12.PATCH825/5.17) id QAA28785 ; Mon, 11 Dec 1995 16:49:36 -0500 Date: Mon, 11 Dec 1995 16:49:36 -0500 (EST) From: GESTIONNAIRE DU Casino To: crossfire@ifi.uio.no Subject: Bug report In-Reply-To: <199512111942.LAA26309@corpse.ecst.csuchico.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I have no idea if this is the right place to do so, but I found a bug in crossfire 0.92.1, with the alchemy spell. AFAIK, the bug was present in 0.89.6 (not 100% sure of the version, I wasn't the maintainer of the casino generic account...). Anyway, the problem appears when trying to transform unpaid objects into gold nuggets with the spell: For most objects, they simply disappear as they should (or as I think they should after taking a look at the code). But for gems and money, they do not disappear, you get 1/3 of their value... And since it's very easy to get unpaid gems from the shops, it's very easy money.... Here's my quick fix: crossfire-0.92.1/server/spell_effect.c, circa line 1456: original code: (from memory, should be very close to this) if (obj->type==MONEY || obj->type==GEM) value /=3; else if (QUERY_FLAG(obj,FLAG_UNPAID)) value = 0; else value *= 0.9; modified code: if (QUERY_FLAG(obj,FLAG_UNPAID)) value=0; else if (obj->type==MONEY || obj->type==GEM) value /=3; else value *= 0.9; as far as I can tell, this fixes the problem with no ill effect. --- Casino From crossfire-request Mon Dec 11 22:10:05 1995 Return-Path: Received: from elvis.seattleu.edu (elvis.seattleu.edu [199.237.224.12]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 22:10:04 +0100 Received: from handel.seattleu.edu.seattleu.edu by elvis.seattleu.edu (4.1/SMI-4.1) id AA00182; Mon, 11 Dec 95 13:06:47 PST Received: by handel.seattleu.edu.seattleu.edu (4.1/SMI-4.1) id AA01782; Mon, 11 Dec 95 13:05:55 PST Date: Mon, 11 Dec 1995 12:59:47 -0800 (PST) From: "Kristofer M. Bosland" Subject: Re: Misc notes/thoughts. To: GESTIONNAIRE DU Casino Cc: "Michael B. Martin" , Tadah , crossfire@ifi.uio.no In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 11 Dec 1995, GESTIONNAIRE DU Casino wrote: > On Mon, 11 Dec 1995, Kristofer M. Bosland wrote: > > [Snip] > > I also think that the Server should give the Client ids for each > > object, and these can be refered to during intercationn (so that each one > > does not completely need to be redescribed). I.e. object77 moves north 1, > > or object77 moves to 22,16. I think that you could get alot of > > functionality with a minimum of bandwidth this way. Occasional > > I agree, but won't it use up a lot of memory, keeping all those handles ? > > --- > Casino > I was thinking of just keeping the objects relating to the player, and the objects on the map the player was in. This would then be flushed everytime the player change maps. I don't expect much more than an order of 1k objects per map, which means with text names you should be below ~50k for this. Without this mechanism, the Client/Server traffic would be dominated by "refreshes" of data containing objects that have not changed/moved (Client: "Is that Grass still there?"; Server: "Yeah"; Client "I'll draw it again, then..."). I think a differential approach would be much lower bandwidth. -Kris Bosland krisb@seattleu.edu From crossfire-request Mon Dec 11 22:03:22 1995 Return-Path: Received: from elvis.seattleu.edu (elvis.seattleu.edu [199.237.224.12]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 22:03:21 +0100 Received: from handel.seattleu.edu.seattleu.edu by elvis.seattleu.edu (4.1/SMI-4.1) id AA29834; Mon, 11 Dec 95 13:00:06 PST Received: by handel.seattleu.edu.seattleu.edu (4.1/SMI-4.1) id AA01737; Mon, 11 Dec 95 12:58:53 PST Date: Mon, 11 Dec 1995 12:57:48 -0800 (PST) From: "Kristofer M. Bosland" Subject: Re: Misc notes/thoughts. To: Brett Rabe Cc: "Michael B. Martin" , Tadah , crossfire@ifi.uio.no In-Reply-To: <199512111958.NAA04225@ww.msc.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Sorry, I guess I meant "Windows Stuff". I think you know what type of things I mean. I've just been working with X recently. On Mon, 11 Dec 1995, Brett Rabe wrote: > > > The Client should handle all X stuff, including all X type > >Binaries (i.e. XPM, AU), Windows, and Events. The Client/Server > >interaction should be moderately readable text, and asynchronous. The > >Server Should reference Display Items (such as > >pix/humans/players/barbarian) and the Client can render them as > >appropriate (Fonts, XPM, Animation). Should sounds be separate, or part > >of the "Image" of an Object? The later may lead to invisible objects to > >provide environmental sounds. > > Why limit yourself to an X client only? Provided you set up a decent > model for interaction between clients and the server, you should be able > to design any number of clients for various platforms and graphical > systems. > > ------ > Brett Rabe Email: brett@msc.edu > Network and System Administration Voice: 612/337-3443 > Minnesota Supercomputer Center Inc. Pager: 612/538-8406 > 1200 South Washington Avenue, Minneapolis, MN 55415 FAX: 612/337-3400 From crossfire-request Mon Dec 11 20:58:30 1995 Return-Path: Received: from harfang.CC.UMontreal.CA (harfang.CC.UMontreal.CA [132.204.2.102]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 20:58:27 +0100 Received: from epsom.jsp.umontreal.ca (epsom.JSP.UMontreal.CA [132.204.45.25]) by harfang.CC.UMontreal.CA with ESMTP id OAA23413 (8.6.11/IDA-1.6); Mon, 11 Dec 1995 14:57:44 -0500 Received: from derby.jsp.umontreal.ca (derby.jsp.umontreal.ca [132.204.46.26]) by epsom.jsp.umontreal.ca via ESMTP (950911.SGI.8.6.12.PATCH825/5.17) id OAA25242 ; Mon, 11 Dec 1995 14:58:56 -0500 Received: (from casino@localhost) by derby.jsp.umontreal.ca (950911.SGI.8.6.12.PATCH825/5.17) id OAA20765 ; Mon, 11 Dec 1995 14:58:26 -0500 Date: Mon, 11 Dec 1995 14:58:26 -0500 (EST) From: GESTIONNAIRE DU Casino To: "Kristofer M. Bosland" cc: "Michael B. Martin" , Tadah , crossfire@ifi.uio.no Subject: Re: Misc notes/thoughts. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 11 Dec 1995, Kristofer M. Bosland wrote: > > > Now, I admit to knowing practically nothing about how the current > > client/server stuff works. However, IMHO, the client should handle > > the game window(s), including keeping a list of the players inventory > > and position. When there is an input event (key, mouse, etc.), the > > event gets processed by the client and is forwarded to the server if > > appropriate. The client should be in charge of managing map/item I agree, else the game will always need bazillion of bandwidth... > The Client should handle all X stuff, including all X type > Binaries (i.e. XPM, AU), Windows, and Events. The Client/Server > interaction should be moderately readable text, and asynchronous. The > Server Should reference Display Items (such as > pix/humans/players/barbarian) and the Client can render them as > appropriate (Fonts, XPM, Animation). Should sounds be separate, or part > of the "Image" of an Object? The later may lead to invisible objects to > provide environmental sounds. I think there should be a way for the client to download all the archetypes/XPM/etc, because game masters may create new ones for their own map upgrades... > I also think that the Server should give the Client ids for each > object, and these can be refered to during intercationn (so that each one > does not completely need to be redescribed). I.e. object77 moves north 1, > or object77 moves to 22,16. I think that you could get alot of > functionality with a minimum of bandwidth this way. Occasional I agree, but won't it use up a lot of memory, keeping all those handles ? --- Casino From crossfire-request Mon Dec 11 20:58:19 1995 Return-Path: Received: from noc.msc.edu (noc.msc.edu [137.66.12.254]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 20:58:18 +0100 Received: from ww.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA25977; Mon, 11 Dec 95 13:58:17 -0600 Received: from localhost (brett@localhost) by ww.msc.edu (8.7.1/8.6.6) with SMTP id NAA04225; Mon, 11 Dec 1995 13:58:16 -0600 (CST) Message-Id: <199512111958.NAA04225@ww.msc.edu> X-Authentication-Warning: ww.msc.edu: brett owned process doing -bs X-Authentication-Warning: ww.msc.edu: Host brett@localhost didn't use HELO protocol To: "Kristofer M. Bosland" Cc: "Michael B. Martin" , Tadah , crossfire@ifi.uio.no Subject: Re: Misc notes/thoughts. In-Reply-To: Your message of "Mon, 11 Dec 1995 11:06:44 PST." Date: Mon, 11 Dec 1995 13:58:15 -0600 From: Brett Rabe Status: RO > The Client should handle all X stuff, including all X type >Binaries (i.e. XPM, AU), Windows, and Events. The Client/Server >interaction should be moderately readable text, and asynchronous. The >Server Should reference Display Items (such as >pix/humans/players/barbarian) and the Client can render them as >appropriate (Fonts, XPM, Animation). Should sounds be separate, or part >of the "Image" of an Object? The later may lead to invisible objects to >provide environmental sounds. Why limit yourself to an X client only? Provided you set up a decent model for interaction between clients and the server, you should be able to design any number of clients for various platforms and graphical systems. ------ Brett Rabe Email: brett@msc.edu Network and System Administration Voice: 612/337-3443 Minnesota Supercomputer Center Inc. Pager: 612/538-8406 1200 South Washington Avenue, Minneapolis, MN 55415 FAX: 612/337-3400 From crossfire-request Mon Dec 11 20:43:43 1995 Return-Path: Received: from corpse.ecst.csuchico.edu (karim@corpse.ecst.csuchico.edu [132.241.5.10]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 20:43:40 +0100 Received: (from karim@localhost) by corpse.ecst.csuchico.edu (8.6.12/8.6.12) id LAA26309; Mon, 11 Dec 1995 11:42:17 -0800 From: karim Message-Id: <199512111942.LAA26309@corpse.ecst.csuchico.edu> Subject: Re: Misc notes/thoughts. To: mwedel@pyramid.com (Mark Wedel) Date: Mon, 11 Dec 1995 11:42:17 -0800 (PST) Cc: crossfire@ifi.uio.no In-Reply-To: <9512110809.AA13635@stealth.eng.pyramid.com> from "Mark Wedel" at Dec 11, 95 08:09:52 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1305 Status: RO > Third: Message output. A few days ago, I think I said I would probably > come up with something that would do paging. But what someone just mentioned > made a lot of sense - add a scrollbar. Originally, it was my opinion > that this is somethign that is better suited for the client (actually, > it is still my opinion, but the client is going anyplace right now.) I'll > have to look at the code, and see how generic some of the scrollbar code > is, and if it isn't very generic, make is so. I guess things will also be > a little funky between scroll vs wrap (wrap is still useful, because scrolling > can take a bit of time/bandwidth if you are getting a lot of messages, > while wrap takes very little, so there is reason to keep in place.) Any > suggestions/thoughts on this? > > Thats all. > > --Mark > I you haven't played netrek, I would suggest looking at the netrek client code (BRMH client) to check out the messaging system. It works very well, uses scrollbars, and has a good interface to it. Messages from teh server would work well and can be colorized, and messages between players and parties could also be done well using a netrek like messaging system. http://www.factoryx.com should give you a pointer to where UNIX clients are if you want to check it out. Karim From crossfire-request Mon Dec 11 20:37:59 1995 Return-Path: Received: from elvis.seattleu.edu (elvis.seattleu.edu [199.237.224.12]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 20:37:52 +0100 Received: from handel.seattleu.edu.seattleu.edu by elvis.seattleu.edu (4.1/SMI-4.1) id AA25915; Mon, 11 Dec 95 11:34:26 PST Received: by handel.seattleu.edu.seattleu.edu (4.1/SMI-4.1) id AA00770; Mon, 11 Dec 95 11:34:03 PST Date: Mon, 11 Dec 1995 11:06:44 -0800 (PST) From: "Kristofer M. Bosland" Subject: Re: Misc notes/thoughts. To: "Michael B. Martin" Cc: Tadah , crossfire@ifi.uio.no In-Reply-To: <199512111845.NAA04725@mbmartin.bevc.blacksburg.va.us> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 11 Dec 1995, Michael B. Martin wrote: > > I agree with this. I think the greatest feature of crossfire is its > multi-player ability, and adding clients for non-UN*X OS's could help > add a *lot* of new players (hopefully not appearing overnight, though, > so those people running servers would have a chance to upgrade the > memory on their machines ;). To this end it would seem to make sense > to have a well-defined client-server model (the server code being > maintained in C or C++, say) with the clients relatively easily > recodable in whatever language you want (having read the propaganda on > Sun's Web site, Java does indeed sound like a good option for a > crossfire client). > I was thinking of Tcl/Tk, which has also been recently ported to WinDoze, and the Mac. Does Java have a working interpreter on these platforms, or are they in the works? > Now, I admit to knowing practically nothing about how the current > client/server stuff works. However, IMHO, the client should handle > the game window(s), including keeping a list of the players inventory > and position. When there is an input event (key, mouse, etc.), the > event gets processed by the client and is forwarded to the server if > appropriate. The client should be in charge of managing map/item The Client should handle all X stuff, including all X type Binaries (i.e. XPM, AU), Windows, and Events. The Client/Server interaction should be moderately readable text, and asynchronous. The Server Should reference Display Items (such as pix/humans/players/barbarian) and the Client can render them as appropriate (Fonts, XPM, Animation). Should sounds be separate, or part of the "Image" of an Object? The later may lead to invisible objects to provide environmental sounds. I also think that the Server should give the Client ids for each object, and these can be refered to during intercationn (so that each one does not completely need to be redescribed). I.e. object77 moves north 1, or object77 moves to 22,16. I think that you could get alot of functionality with a minimum of bandwidth this way. Occasional resynchronization may be needed if things start to get lossy. I think that a scheme like this would be aided by a move to a more complete and hierarchical command line interface (i.e. run northeast, or step northeast). This may make some common commands longer, but this could be fixed by implementing aliases on the client end. [Big Snip] > > -Michael -Kris Bosland krisb@seattleu.edu From crossfire-request Mon Dec 11 18:43:46 1995 Return-Path: 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 ; Mon, 11 Dec 1995 18:43:44 +0100 Received: (from martinm@localhost) by mbmartin.bevc.blacksburg.va.us (8.6.12/8.6.9) id NAA04725; Mon, 11 Dec 1995 13:45:24 -0500 From: "Michael B. Martin" Message-Id: <199512111845.NAA04725@mbmartin.bevc.blacksburg.va.us> Subject: Re: Misc notes/thoughts. To: link@alpha.pulsar.net (Tadah) Date: Mon, 11 Dec 1995 13:45:24 -0500 (EST) Cc: crossfire@ifi.uio.no In-Reply-To: from "Tadah" at Dec 11, 95 10:54:18 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6090 Status: RO > Player interactivity I think is the biggest focus we should have on > crossfire. I love the fact we keep adding to it, it keeps the game > alive, but as fun as new features are for us, we need to start cleaning > up some stuff. Make crossfire easier to install/upgrade/addto. Make it > available, like you just stated, on other OSes like WIn95 (I think Java > is a superb idea!). Optimize the the game for smaller bandwidth so we > can get modem players, etc. Also lets put more into the party idea and > other player to player interaction. I agree with this. I think the greatest feature of crossfire is its multi-player ability, and adding clients for non-UN*X OS's could help add a *lot* of new players (hopefully not appearing overnight, though, so those people running servers would have a chance to upgrade the memory on their machines ;). To this end it would seem to make sense to have a well-defined client-server model (the server code being maintained in C or C++, say) with the clients relatively easily recodable in whatever language you want (having read the propaganda on Sun's Web site, Java does indeed sound like a good option for a crossfire client). Now, I admit to knowing practically nothing about how the current client/server stuff works. However, IMHO, the client should handle the game window(s), including keeping a list of the players inventory and position. When there is an input event (key, mouse, etc.), the event gets processed by the client and is forwarded to the server if appropriate. The client should be in charge of managing map/item graphics and any scrolling of windows (as recently suggested--I think just making the spell list pageable like shop inventories would be the best quick (?) option). Some people requested the ability to play over a modem. I don't think that is reasonable unless the client has its own copy of the bitmaps/pixmaps (and sounds, if desired), the way many games like Doom achieve great multi-player speed). Sending the pixmaps over the network is just too slow without Ethernet speeds (even with Ethernet it would make things faster). The only data that should have to pass between the client and server include updates on positions, item pickups/drops, etc, i.e. information that corresponds to an interaction between the player and the crossfire world. If a player resorts his inventory, for example, the server need not know this (have the client handle it). Then if the player wants to apply an "Enchant Weapon" scroll to the weapon he just moved to the top of this inventory, the client tells the server that player such-and-such is trying to apply the scroll, and that weapon X is the first item in his inventory. Does this sound feasible? Right now it seems to me that the server has so much to do that a good client could handle instead that the server would not be able to support a very large number of players (when in fact it could if the client took on a much larger share of the work). > Also, why make the player disappear when you save for the day? I > remember playing RPG type games on BBSes, some of you might remember > them.. "Land of Devestation (LOD)", "Operation OverKill", etc. They > were pretty fun, allowed teams, also allowed the build of forts which > would be a cool idea for crossfire. If a player saves in a inn, fine, > can't touch him. But allow for camping out. Be able to save anywhere, > but if your not in a well built inn (like in Scorn city, not like in port > joesph where you have to watch your back ), leave some chances to at > least get something stolen from the player if another player finds him in > a not well protected area. Also, allow fighting when the other player is > not on, assign some AI values to the otherwise inactive player. Sound > cruel? Not if its not made to penilize the player that is not on. Make > it so the active player can gain exp, etc from the player he killed, but > still maintain the players save file, changing little if at all. Well, for starters, crossfire is currently such that you must use a "bed to reality" to sleep/save your character. So at this time you can't save your guy just anywhere (anyone tried carrying a bed to reality around?). If people really want this feature, perhaps someone could create a "bedroll to reality" or something similar which you could easily carry. But when you use it your guy would "disappear" under the current code while sleeping, so you couldn't steal stuff or kill him. At any rate, I would not save *my* character in the woods if he could be attacked. Supposedly, you do get experience for killing other characters at this time, but not that much (and the risk may not be worth it--ever try to kill a 60+ level character? It's not easy!). Which brings up another thought I had. In AD&D, the experience required for higher levels was much larger than in crossfire (e.g. a 20+ level wizard had a *lot* of experience and was a *very* powerful character). Some people have recently suggested that experience for monsters might be too high, making it easy to get a 50+ level character "overnight". I would suggest instead raising the experience required for the levels. Right now the game experience table starts off exponentially, base 2, effectively (i.e. 1000, 2000, 4000, 8000, etc.). I think this is fine, but by around 10th level or so it starts leveling off dramatically (too much, I think). Keeping it close to roughly twice the previous level's experience for each new level would make 30+ characters much less common. This would also probably effect a greater "split" in the classes (my 77th level barbarian is now as powerful as any mage, with over 500 sp, but this could not have happened if he were currently only, say, 27th level instead--he would still be a powerful fighter but not that good with magic). This would also eliminate some of the concerns about enchanting mega-weapons (like my barbarian has), since the number of enchantments is proportial to the character's level. Does anyone else agree? -Michael From crossfire-request Mon Dec 11 18:56:13 1995 Return-Path: Received: from krusty.eecs.umich.edu (pkenny@krusty.eecs.umich.edu [141.212.36.18]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 18:56:09 +0100 Received: (from pkenny@localhost) by krusty.eecs.umich.edu (8.7.2/8.7.2) id MAA05520; Mon, 11 Dec 1995 12:55:59 -0500 (EST) Date: Mon, 11 Dec 1995 12:55:58 -0500 (EST) From: Patrick Kenny To: crossfire@ifi.uio.no Subject: unsubscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO unsubscribe From crossfire-request Mon Dec 11 17:11:45 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 17:11:42 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id LAA08098; Mon, 11 Dec 1995 11:11:22 -0500 Date: Mon, 11 Dec 1995 11:11:22 -0500 (EST) From: Tadah To: Raphael.Quinet@eed.ericsson.se cc: crossfire@ifi.uio.no Subject: Re: Sounds (was Re: Environment variables of client) In-Reply-To: <199512110847.JAA11251@chapelle.eed.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 11 Dec 1995 Raphael.Quinet@eed.ericsson.se wrote: > On Fri, 8 Dec 1995, Matt Cortes wrote: > > Forgive me for approaching this from a novice level . But I have > > notied some clues that this game has sound. Is there sound support > > compiled into it or are you refering to an addon such as the lightning > > code iv'e been reading about from here? > > > > If there is sound, I would love to get it enabled. :> > > > Sound is supported if you have the RPlay library. RPlay works with almost > all UN*X systems, so it shouldn't be a problem for you to use it. Rplay has > the great advantage of mixing sounds on the fly and working accross the > network (like X Window), which would not be possible if CrossFire was using > /dev/audio directly. You can get the rplay library from ftp.x.org or > ftp.sdsu.edu. The latest version comes with a "configure" script that should > automatically detect the configuration of your system. Ok, I never installed Rplay before. I will check it out. Thanks. > Once you have compiled the RPlay library, edit the CrossFire configuration > file and insert the directories for the library and its include files. Now where are the crossfire sounds located, or should be located? A sample crossfire config of the lines I need might be nice to see. :> > Note: I wrote the sounds code a long time ago, and I have lots of ideas for > improving it. But I thought that it would be better to wait until the > client/server split before adding these new features, because I didn't want > to have to do the job twice. Well, I'm still waiting... > > The first improvement would be to re-write the syntax of the "lib/sounds" > file which defines which sound has to be played when some event occurs. > Instead of relying on the entries to be in a fixed order, I would use symbolic > names for each type of event. For example, the new file could have lines > like these: > hit door = crush.au, 80 # = , > hit ennemy = tap2.au, 100 > small fireball = Whoosh.au, 70 > large fireball = Whoosh.au, 100 > It would then be easier to maintain this file, and it wouldn't be a problem > if the number of spells changes. Yes, if only the rest of the game followed such great structure. :P The best part is its also easier to stick in your own .au files if so desired. > Another improvement would be to use "environmental" sounds; that would add > a lot to the atmosphere. Those who have played games like Hexen know what I > mean. It should be possible to add some new "sound" archetypes that can be > placed on a map and play sounds from time to time. For example, a player > could hear the water dripping if he/she comes near a pit, owls crying in the > forest, bells ringing in the church, etc. The new proposal for "weather > effects" would also be a great way to add environmental sounds: a storm could > make a lot of noise. And of course, the monsters could be noisy too. Yes, I have played Hexen. Its a pretty cool game and I love the idea of atmosphere type sounds. What would be nice though is to also have some music perhaps? .MIDs are great but I have never seen a midi player for unix, so I don't know. Plus my AWE32 isn't supported, just the SB16 part, so wave table isn't there for me either. :( a collection of .au instruments might be a good idea, after all.. Thats all wavetable is. Then modulate, etc the .au files according to what the .MID file says, and wala. We have great wavetable music at the cost of some disk space. :> > I have several other ideas and I know how to add some of them to the code, > but I don't want to add this to the current code. It would be much easier > to write and to maintain the new sounds code if CrossFire was really split > between a client and a server, like this was discussed some time ago. Will > this ever be done? Your ideas sounds great, I'd love to see them actually implemented. The interesting thing is if everyone is sitting around waiting for the split, who's actually doing it? Am I right in assuming anyone can just take on this project and start doing it? If so.. Any of you programers, anyone at all.. Please.. Stop waiting and start programming. :P -Link From crossfire-request Mon Dec 11 16:54:14 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 16:54:12 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id KAA08076; Mon, 11 Dec 1995 10:54:18 -0500 Date: Mon, 11 Dec 1995 10:54:18 -0500 (EST) From: Tadah To: Jonathan Roy cc: crossfire@ifi.uio.no, mwedel@pyramid.com Subject: Re: Misc notes/thoughts. In-Reply-To: <199512110826.DAA10197@babbage.csee.usf.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 11 Dec 1995, Jonathan Roy wrote: > Well, I have a question. Why isn't the client going places? It seems to me > running the client would use far less bandwidth than a remote X terminal, > and a quality client could bring in a lot more player, with large central > servers (given the significant drop in bandwidth needed.) With a good protocol > designed up front, going back and adding clients in Win95 or Java or whatever > wouldn't be hard if that protocol was "standardized"... > > Just some thoughts. :) I'd love to see people able to play over a 28.8 modem > and connect to a server with hundreds of players! :D > Yes, that would be great. At least bring it up to netrek levels. 16 players is awesome. :> Of course 16 players on a small make makes it look like alot, but 100might make more since on crossfire being that the maps are pretty big. :> Player interactivity I think is the biggest focus we should have on crossfire. I love the fact we keep adding to it, it keeps the game alive, but as fun as new features are for us, we need to start cleaning up some stuff. Make crossfire easier to install/upgrade/addto. Make it available, like you just stated, on other OSes like WIn95 (I think Java is a superb idea!). Optimize the the game for smaller bandwidth so we can get modem players, etc. Also lets put more into the party idea and other player to player interaction. Also, why make the player disappear when you save for the day? I remember playing RPG type games on BBSes, some of you might remember them.. "Land of Devestation (LOD)", "Operation OverKill", etc. They were pretty fun, allowed teams, also allowed the build of forts which would be a cool idea for crossfire. If a player saves in a inn, fine, can't touch him. But allow for camping out. Be able to save anywhere, but if your not in a well built inn (like in Scorn city, not like in port joesph where you have to watch your back ), leave some chances to at least get something stolen from the player if another player finds him in a not well protected area. Also, allow fighting when the other player is not on, assign some AI values to the otherwise inactive player. Sound cruel? Not if its not made to penilize the player that is not on. Make it so the active player can gain exp, etc from the player he killed, but still maintain the players save file, changing little if at all. Just ideas anyway guys.. if the player is weak, chances are he's still saving his guy in Scorn City where attacking sleeping players should not be allowed. And if its a strong player that decides to sleep in the woods, well.. :> -Link From crossfire-request Mon Dec 11 16:35:33 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 16:35:31 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id KAA08055; Mon, 11 Dec 1995 10:35:00 -0500 Date: Mon, 11 Dec 1995 10:35:00 -0500 (EST) From: Tadah To: Matsuda Takashi cc: crossfire@ifi.uio.no Subject: Re: Environment variables of client In-Reply-To: <199512110645.PAA09170@arch.comp.kyutech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 11 Dec 1995, Matsuda Takashi wrote: > In article > link@acy.digex.net writes: > > >> Forgive me for approaching this from a novice level . But I have > >> notied some clues that this game has sound. Is there sound support > >> compiled into it or are you refering to an addon such as the lightning > >> code iv'e been reading about from here? > >> > >> If there is sound, I would love to get it enabled. :> > > Only 'rplay' library is supported by standard part of Crossfire. > If you want to use this feature, You must uncomment the definition > 'SoundEffects' and define relative directories in 'config/crosssite.def'. > Then you get sound files and put them into specified directory. > Sound files are in the ftp site which keeps old crossfire distributions. > > I don't know there are patchs for other sound system (direct output to > /dev/audio, network audio system, etc ). Ugh, sounds like alot to do . I'll check the source, etc and see if its something I can take on, if not.. I'll wait for the installation of crossfire to become alot better. Thanks for the info. -Link From crossfire-request Mon Dec 11 16:31:55 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 16:31:53 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id KAA08045; Mon, 11 Dec 1995 10:32:03 -0500 Date: Mon, 11 Dec 1995 10:32:03 -0500 (EST) From: Tadah To: Mark Wedel cc: srin9340@nova.gmi.edu, thomas@chaupher.gsfc.nasa.gov, crossfire@ifi.uio.no Subject: Re: summoning In-Reply-To: <9512110738.AA13550@stealth.eng.pyramid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 11 Dec 1995, Mark Wedel wrote: > It then might be a wise change to make it so you can't summon multi square > monsters. Noo!! Summoning large monsters is so fun!! :> Besides.. Is it so big a deal to be able to banish the monster you summoned? Then to call him later on? > What problem I see is that you summon a large multi square monster. You then > wander into a map that has a constricted size (say many of the shops.) Now > you can't get to the exit to leave the shop, because the monster is on top > of it, and you can't switch places with the monster. Spell of Bottlement for this one. Lets not scare the towns people, bottle the monster (genie in the lamp road here) for later use if banishment is such a big sin. Its the latest fad, all master summoners keep names of their favorite monsters, trap them and summon them when they want. :) > Thus could be true on other maps also, where the entrance is a small > room. (in these cases, nothign short of death of your pet monster will solve > the problem). Or maybe killing your pet isn't a big issue, but > is doesn't seem necessary. Killing a large creature would take some work, but in my opinion, 100% success on banishing it would be the best option. Your suppose to control the creature, so lets introduce a whole new set of spells for use during visits from the realm of the summoned. > In theory, exchange place with a small monster shouldn't necessarily be > a sure thing either. But in general, I am of the thought that the reason > you can't occupy the same space as the monster is because he doesn't want > you there, and because it woudl otherwise become more a problem of logistics > on how attacks would otherwise be determined. In theory, on some friendly > monsters, you should probably be able to occupy the same space as they do, > if they so desried it. Ugh. That sounds like a cool idea. I'm not too great a programmer yet, my first thought is that it would be a headache to program.. But the only real issue I see here is who gets attacked when a enemy attacks a square with two or more people in it. But since the AI is alot of randomness anyway, no biggie just to choose randomly who to start attacking, then the enemy sticks with that until say he gets attacked by someone stronger. Anyway, just my 2 cents. :> -Link From crossfire-request Mon Dec 11 16:18:07 1995 Return-Path: Received: from noc.msc.edu (noc.msc.edu [137.66.12.254]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 16:18:06 +0100 Received: from ww.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA06024; Mon, 11 Dec 95 09:17:59 -0600 Received: from localhost (brett@localhost) by ww.msc.edu (8.7.1/8.6.6) with SMTP id JAA03998; Mon, 11 Dec 1995 09:17:58 -0600 (CST) Message-Id: <199512111517.JAA03998@ww.msc.edu> X-Authentication-Warning: ww.msc.edu: brett owned process doing -bs X-Authentication-Warning: ww.msc.edu: Host brett@localhost didn't use HELO protocol To: mwedel@pyramid.com (Mark Wedel) Cc: srin9340@nova.gmi.edu, thomas@chaupher.gsfc.nasa.gov, crossfire@ifi.uio.no Subject: Re: summoning In-Reply-To: Your message of "Mon, 11 Dec 1995 07:38:40 GMT." <9512110738.AA13550@stealth.eng.pyramid.com> Date: Mon, 11 Dec 1995 09:17:57 -0600 From: Brett Rabe Status: RO > In theory, exchange place with a small monster shouldn't necessarily be >a sure thing either. But in general, I am of the thought that the reason >you can't occupy the same space as the monster is because he doesn't want >you there, and because it woudl otherwise become more a problem of logistics >on how attacks would otherwise be determined. In theory, on some friendly >monsters, you should probably be able to occupy the same space as they do, >if they so desried it. There quite frequently comes a time in game design when you must sacrifice reality in favor of playability. The point is to have fun, right? :) Perhaps that point has been reached, and it simply makes more sense to allow players to either occupy the same space as 'friendly' monsters, or allow them to switch. ------ Brett Rabe Email: brett@msc.edu Network and System Administration Voice: 612/337-3443 Minnesota Supercomputer Center Inc. Pager: 612/538-8406 1200 South Washington Avenue, Minneapolis, MN 55415 FAX: 612/337-3400 From crossfire-request Mon Dec 11 12:26:09 1995 Return-Path: Received: from tel1.tte.vtt.fi (tel1.tte.vtt.fi [130.188.12.3]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 12:26:09 +0100 Received: (from hat@localhost) by tel1.tte.vtt.fi (8.6.11/8.6.11) id NAA04045 for crossfire@ifi.uio.no; Mon, 11 Dec 1995 13:25:38 +0200 From: Tero Haatanen Message-Id: <199512111125.NAA04045@tel1.tte.vtt.fi> Subject: Re: I give up. How *do* I set up shop door mats? To: crossfire@ifi.uio.no Date: Mon, 11 Dec 1995 13:25:37 +0200 (EET) In-Reply-To: <199512111016.XAA25984@debretts.comp.vuw.ac.nz> from "Stephen Wray" at Dec 11, 95 11:16:59 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 689 Status: RO > Often, mats get me into a shop, but when standing on the > outgoing mats, nothing happens. > > I can't see anything in the standard maps which in *any way* > distinguishes incoming from outgoing mats. The shop mats are just a special cases of teleporters that don't have target defined. When player walks on a shop mat then code finds a random shop mat that is inside a specific square (7x7?) and teleports player there. If you have 3 mats near each other, player randomly teleports between those. There are no incoming and outgoings mats, only how the map layout makes some mats be inside a shop and others outside. Maybe it would time to implement the real doors. -Tero From crossfire-request Mon Dec 11 12:16:28 1995 Return-Path: Received: from tel1.tte.vtt.fi (tel1.tte.vtt.fi [130.188.12.3]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 12:16:28 +0100 Received: (from hat@localhost) by tel1.tte.vtt.fi (8.6.11/8.6.11) id NAA03917 for crossfire@ifi.uio.no; Mon, 11 Dec 1995 13:15:57 +0200 From: Tero Haatanen Message-Id: <199512111115.NAA03917@tel1.tte.vtt.fi> Subject: Re: Misc notes/thoughts. To: crossfire@ifi.uio.no Date: Mon, 11 Dec 1995 13:15:56 +0200 (EET) In-Reply-To: <9512110809.AA13635@stealth.eng.pyramid.com> from "Mark Wedel" at Dec 11, 95 08:09:52 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 4164 Status: RO From: mwedel@pyramid.com (Mark Wedel) > First, as with the recent discussion of conversion to c++, I just gave > a quick try, and the main issue looks like it will be the naming of > elements/structures that conflict with c++ (ie, class and protected are the > ones it immediately died on.) If the goal of the c++ version is that it will replace the current version then it really needs a major work. I think that it's not worth to make all changes only to able to compile it C++ compiler. And the current code assumes Ansi C, not C++ so there are probably some incompabilities. If it's a just separate work, then I think it can be a nice challange, but the code is probably outdated when conversion is done. > Second: Dm mode. How many people actually use this? I looked into this > after receiving a bug report, and noticed that the security for it is really > quite dismal. Yes, I wondered why the password was removed and changed to a name check. Generally I would like that dm would be like other players and using the player name and password. Of course there is a problem how to make those dm chacacters in a first place. > Any reason not to just go back to a global password for dm access? No, but I prefer the above method. > Or should dm protection be improved (also include authorized > hosts/displays to become dm from. Not before the true client/server. > Or may add passwords in addition to just names - at > least it would be 2 things that need to be guessed.) No, the name is too easy to find out (identd/email-address etc). > The other is, is there really any reason to restrict dm access from sockets? Probably not, but the client/server mode should offer the same security anyway. > Third: Message output. A few days ago, I think I said I would probably > come up with something that would do paging. But what someone just mentioned > made a lot of sense - add a scrollbar. The both makes sense, but is it worth start coding scrollbar code since all toolkits would offer one? The general paging routine would be useful on the client side. > Originally, it was my opinion > that this is somethign that is better suited for the client (actually, > it is still my opinion, but the client is going anyplace right now.) Of course it not going anywhere if all changes are made server and not a client :(. > Any suggestions/thoughts on this? I would say that forget all code on server side, which clearly belongs to client. And from Raphael.Quinet@eed.ericsson.se writes about sounds: [ Ideas removed ] I think that sounds don't need any special archetypes, but just build-in support in objects like faces are now. Only meaning for lib/sounds file should be make mapping between game sounds and actual sound files (like bmaps do now with the images). > It would be much easier to write and to maintain the new sounds code > if CrossFire was really split between a client and a server, like this > was discussed some time ago. Will this ever be done? Why everyone thinks that the current client is not enough to work with? Yes, it's still incompleted, but offers enough features to work with. I have compiled the current server without any X libraries, but it requires much more that just commenting out xio.c :). Generally I used #ifdef's to comment out code that was something to do user interface and in some cases I used the new client/server function instead of the old one. The new function calls the old one if X support is compiled in and used. This makes code little more clear, at least. I try to make some changes to get better item handling in the protocol and send changes to Mark before Christmas (or otherwise changes are kept in my machine so long that new version comes out and no one is interested patches to the old version ;) The true advantage comes when client side animations are implemented, but this requires more work. Basically all animated archetypes needs to be updated and all support programs. Also this kind of changes are very hard to make to keep compability to the old scheme. it probably requires rewriting some of the basic code on server side. -Tero From crossfire-request Mon Dec 11 11:17:11 1995 Return-Path: Received: from kaukau.comp.vuw.ac.nz (kaukau.comp.vuw.ac.nz [130.195.5.20]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 11:17:07 +0100 Received: from debretts.comp.vuw.ac.nz (debretts.comp.vuw.ac.nz [130.195.8.46]) by kaukau.comp.vuw.ac.nz (8.6.B/8.6.9-VUW) with ESMTP id XAA01931 for ; Mon, 11 Dec 1995 23:16:43 +1300 From: Stephen Wray Received: (stevew@localhost) by debretts.comp.vuw.ac.nz (8.6.10/8.6.6) id XAA25984; Mon, 11 Dec 1995 23:16:59 +1300 Date: Mon, 11 Dec 1995 23:16:59 +1300 Message-Id: <199512111016.XAA25984@debretts.comp.vuw.ac.nz> To: crossfire@ifi.uio.no Subject: I give up. How *do* I set up shop door mats? Reply-to: Steve.Wray@vuw.ac.nz Status: RO -----BEGIN PGP SIGNED MESSAGE----- I have tried to set up a shop. I tried every way I could think of to get the doormats set up. I have had intermittent success. Sometimes mats work, sometimes they don't. Often, mats get me into a shop, but when standing on the outgoing mats, nothing happens. I can't see anything in the standard maps which in *any way* distinguishes incoming from outgoing mats. There *seems* to be nothing in the docs about this -- if you want to respond "RTFM" please tell me where I can find the FM on this topic. Yours FRUSTRATEDLY :-| - --- **********************T***H***E***L***E***M***A********************** 44. For pure will, unassuaged of purpose, delivered from the lust of result, is every way perfect. -- LIBER AL vel LEGIS ******************************IN*LVX********************************* Stephen Wray -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQCVAgUBMMwFFSt7qh9JVcfZAQHZngQAtHsvT4tdhERuzDqSBi00Tc1pfMYdtV/G hG1QsspaR4rAdzGPDZyOIF1mQzLj2y6XF3XD8472wpKsoSlGT05tUZbpiiDAYQ+s BpznAZK8nCQ+m4EB6xtA/yfWceYdMOLAi30UUA/Y6bDWiFLejV8NS9h1FPxGEVHL S2SKhniHs0U= =UXtZ -----END PGP SIGNATURE----- From crossfire-request Mon Dec 11 09:21:38 1995 Return-Path: Received: from cedre.ft.net (cedre.ft.net [193.48.69.2]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 09:21:37 +0100 Received: from anahein.ft.net by cedre.ft.net (4.1/SMI-4.1) id AA24186; Mon, 11 Dec 95 09:26:01 GMT Received: by anahein.ft.net (4.1/SMI-4.1) id AA18297; Mon, 11 Dec 95 09:23:19 GMT Date: Mon, 11 Dec 95 09:23:19 GMT From: fred@ft.net (Supervision Transrel) Message-Id: <9512110923.AA18297@anahein.ft.net> To: crossfire@ifi.uio.no Subject: unsubscribe Status: RO From crossfire-request Mon Dec 11 14:56:59 1995 Return-Path: Received: from fire1b.math.utk.edu (srajput@FIRE1B.MATH.UTK.EDU [198.78.198.28]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 14:56:58 +0100 Received: by fire1b.math.utk.edu (cf v2.11c-UTK) id IAA01565; Mon, 11 Dec 1995 08:58:40 GMT Date: Mon, 11 Dec 1995 08:58:39 +0000 (GMT) From: "Sanjay Rajput (lab)" To: crossfire@ifi.uio.no Subject: unsubscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO ********************************************************************** Sanjay Rajput srajput@math.utk.edu "You refuse to let anybody love you..." "Love is for poets." #. @>ZZZZZZZZZZZZZZ@%@;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;/ #' "In the end, there can be only one." ********************************************************************** From crossfire-request Mon Dec 11 09:47:40 1995 Return-Path: Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 09:47:33 +0100 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.132.130]) by mailgate.ericsson.se (8.6.11/1.0) with ESMTP id JAA25696; Mon, 11 Dec 1995 09:47:18 +0100 Received: (from eedraq@localhost) by chapelle.eed.ericsson.se (8.7.1/8.7.1) id JAA11251; Mon, 11 Dec 1995 09:47:16 +0100 (MET) Date: Mon, 11 Dec 1995 09:47:15 +0100 (MET) Message-Id: <199512110847.JAA11251@chapelle.eed.ericsson.se> To: link@acy.digex.net Subject: Sounds (was Re: Environment variables of client) Cc: crossfire@ifi.uio.no From: Raphael.Quinet@eed.ericsson.se Status: RO On Fri, 8 Dec 1995, Matt Cortes wrote: > Forgive me for approaching this from a novice level . But I have > notied some clues that this game has sound. Is there sound support > compiled into it or are you refering to an addon such as the lightning > code iv'e been reading about from here? > > If there is sound, I would love to get it enabled. :> > Sound is supported if you have the RPlay library. RPlay works with almost all UN*X systems, so it shouldn't be a problem for you to use it. Rplay has the great advantage of mixing sounds on the fly and working accross the network (like X Window), which would not be possible if CrossFire was using /dev/audio directly. You can get the rplay library from ftp.x.org or ftp.sdsu.edu. The latest version comes with a "configure" script that should automatically detect the configuration of your system. Once you have compiled the RPlay library, edit the CrossFire configuration file and insert the directories for the library and its include files. Note: I wrote the sounds code a long time ago, and I have lots of ideas for improving it. But I thought that it would be better to wait until the client/server split before adding these new features, because I didn't want to have to do the job twice. Well, I'm still waiting... The first improvement would be to re-write the syntax of the "lib/sounds" file which defines which sound has to be played when some event occurs. Instead of relying on the entries to be in a fixed order, I would use symbolic names for each type of event. For example, the new file could have lines like these: hit door = crush.au, 80 # = , hit ennemy = tap2.au, 100 small fireball = Whoosh.au, 70 large fireball = Whoosh.au, 100 It would then be easier to maintain this file, and it wouldn't be a problem if the number of spells changes. Another improvement would be to use "environmental" sounds; that would add a lot to the atmosphere. Those who have played games like Hexen know what I mean. It should be possible to add some new "sound" archetypes that can be placed on a map and play sounds from time to time. For example, a player could hear the water dripping if he/she comes near a pit, owls crying in the forest, bells ringing in the church, etc. The new proposal for "weather effects" would also be a great way to add environmental sounds: a storm could make a lot of noise. And of course, the monsters could be noisy too. I have several other ideas and I know how to add some of them to the code, but I don't want to add this to the current code. It would be much easier to write and to maintain the new sounds code if CrossFire was really split between a client and a server, like this was discussed some time ago. Will this ever be done? -Raphael From crossfire-request Mon Dec 11 09:27:20 1995 Return-Path: Received: from babbage.csee.usf.edu (roy@[131.247.1.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 09:27:19 +0100 Received: (roy@localhost) by babbage.csee.usf.edu (8.6.12/8.6.5) id DAA10197; Mon, 11 Dec 1995 03:26:24 -0500 Date: Mon, 11 Dec 1995 03:26:24 -0500 From: Jonathan Roy (CS) Message-Id: <199512110826.DAA10197@babbage.csee.usf.edu> To: crossfire@ifi.uio.no, mwedel@pyramid.com Subject: Re: Misc notes/thoughts. Status: RO Well, I have a question. Why isn't the client going places? It seems to me running the client would use far less bandwidth than a remote X terminal, and a quality client could bring in a lot more player, with large central servers (given the significant drop in bandwidth needed.) With a good protocol designed up front, going back and adding clients in Win95 or Java or whatever wouldn't be hard if that protocol was "standardized"... Just some thoughts. :) I'd love to see people able to play over a 28.8 modem and connect to a server with hundreds of players! :D From crossfire-request Mon Dec 11 09:10:27 1995 Return-Path: Received: from bertha.pyramid.com (bertha.pyramid.com [129.214.1.100]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 09:10:26 +0100 Received: from stealth.eng.pyramid.com by bertha.pyramid.com (5.67/OSx5.1a Pyramid-Internet-Gateway) id AA10774; Mon, 11 Dec 95 08:09:54 GMT Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA13635; Mon, 11 Dec 95 08:09:52 GMT Date: Mon, 11 Dec 95 08:09:52 GMT From: mwedel@pyramid.com (Mark Wedel) Message-Id: <9512110809.AA13635@stealth.eng.pyramid.com> To: crossfire@ifi.uio.no Subject: Misc notes/thoughts. Status: RO This contains a few not esepcially related thoughts, that I might as well toss out. First, as with the recent discussion of conversion to c++, I just gave a quick try, and the main issue looks like it will be the naming of elements/structures that conflict with c++ (ie, class and protected are the ones it immediately died on.) I have a feeling that an initial conversion to c++ would not be all that hard, but would incorporate a lot of changes, since those structures/elements are used all over the place. Second: Dm mode. How many people actually use this? I looked into this after receiving a bug report, and noticed that the security for it is really quite dismal. Before, it was a global password, which probably wasn't all that great. But now, it just does a quick name check. Since you can set your name in the initial telnet command, this really just ammounts to a simple password. But even more the problem is that the name everyone iherits by default is that that the process runs under. This, if I set up a server and run it under an account called master, and also have master in the password file, then by default, any player can become dm without doing anything special except typing 'dm. This is probably worse than before. The other thing is that you can not become dm from a socket. I actually find that somewhat annoying when all you want to do is reset a map or something. So I have 2 questions: Any reason not to just go back to a global password for dm access? It gives just as good security as exists now. Or should dm protection be improved (also include authorized hosts/displays to become dm from. Or may add passwords in addition to just names - at least it would be 2 things that need to be guessed.) The other is, is there really any reason to restrict dm access from sockets? Ok. That is more than 2 questions. Third: Message output. A few days ago, I think I said I would probably come up with something that would do paging. But what someone just mentioned made a lot of sense - add a scrollbar. Originally, it was my opinion that this is somethign that is better suited for the client (actually, it is still my opinion, but the client is going anyplace right now.) I'll have to look at the code, and see how generic some of the scrollbar code is, and if it isn't very generic, make is so. I guess things will also be a little funky between scroll vs wrap (wrap is still useful, because scrolling can take a bit of time/bandwidth if you are getting a lot of messages, while wrap takes very little, so there is reason to keep in place.) Any suggestions/thoughts on this? Thats all. --Mark From crossfire-request Mon Dec 11 08:39:56 1995 Return-Path: Received: from bertha.pyramid.com (bertha.pyramid.com [129.214.1.100]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 08:39:54 +0100 Received: from stealth.eng.pyramid.com by bertha.pyramid.com (5.67/OSx5.1a Pyramid-Internet-Gateway) id AA09003; Mon, 11 Dec 95 07:38:42 GMT Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA13550; Mon, 11 Dec 95 07:38:40 GMT Date: Mon, 11 Dec 95 07:38:40 GMT From: mwedel@pyramid.com (Mark Wedel) Message-Id: <9512110738.AA13550@stealth.eng.pyramid.com> To: srin9340@nova.gmi.edu, thomas@chaupher.gsfc.nasa.gov Subject: Re: summoning Cc: crossfire@ifi.uio.no Status: RO It then might be a wise change to make it so you can't summon multi square monsters. What problem I see is that you summon a large multi square monster. You then wander into a map that has a constricted size (say many of the shops.) Now you can't get to the exit to leave the shop, because the monster is on top of it, and you can't switch places with the monster. Thus could be true on other maps also, where the entrance is a small room. (in these cases, nothign short of death of your pet monster will solve the problem). Or maybe killing your pet isn't a big issue, but is doesn't seem necessary. In theory, exchange place with a small monster shouldn't necessarily be a sure thing either. But in general, I am of the thought that the reason you can't occupy the same space as the monster is because he doesn't want you there, and because it woudl otherwise become more a problem of logistics on how attacks would otherwise be determined. In theory, on some friendly monsters, you should probably be able to occupy the same space as they do, if they so desried it. --Mark From crossfire-request Mon Dec 11 08:39:46 1995 Return-Path: Received: from arch.comp.kyutech.ac.jp (arch.comp.kyutech.ac.jp [150.69.62.21]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 08:39:38 +0100 Received: (from matsuda@localhost) by arch.comp.kyutech.ac.jp (8.7.1/3.4W3-951117) id PAA09170; Mon, 11 Dec 1995 15:45:06 +0900 (JST) Date: Mon, 11 Dec 1995 15:45:06 +0900 (JST) Message-Id: <199512110645.PAA09170@arch.comp.kyutech.ac.jp> To: link@acy.digex.net Cc: crossfire@ifi.uio.no Subject: Re: Environment variables of client In-Reply-To: Your message of Fri, 8 Dec 1995 18:39:41 -0500 (EST). From: matsuda@arch.comp.kyutech.ac.jp (Matsuda Takashi) X-Mailer: mnews [version 1.19] 1995-07/21(Fri) Status: RO In article link@acy.digex.net writes: >> Forgive me for approaching this from a novice level . But I have >> notied some clues that this game has sound. Is there sound support >> compiled into it or are you refering to an addon such as the lightning >> code iv'e been reading about from here? >> >> If there is sound, I would love to get it enabled. :> Only 'rplay' library is supported by standard part of Crossfire. If you want to use this feature, You must uncomment the definition 'SoundEffects' and define relative directories in 'config/crosssite.def'. Then you get sound files and put them into specified directory. Sound files are in the ftp site which keeps old crossfire distributions. I don't know there are patchs for other sound system (direct output to /dev/audio, network audio system, etc ). -Takashi Matsuda matsuda@arch.comp.kyutech.ac.jp From crossfire-request Mon Dec 11 06:32:28 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 06:32:24 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id AAA07344; Mon, 11 Dec 1995 00:32:12 -0500 Date: Mon, 11 Dec 1995 00:32:12 -0500 (EST) From: Tadah To: Colin cc: crossfire@ifi.uio.no Subject: Re: Experience In-Reply-To: <199512110452.PAA27303@zebedee.teaching.cs.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO > etc>HMm. I apologize then, I didn't know there was such a mode. How can I > etc>enter into that? And how can I save window position/size? > etc> > > I believe you start the client with the -split option > or use -w when running the server. > > savewinpos should save the window postion for > a particular character. I can't verify how well > it works since I use a single window.. Ok great. Thanks alot for the info then. :> -Link From crossfire-request Mon Dec 11 05:53:31 1995 Return-Path: Received: from zebedee.teaching.cs.adelaide.edu.au (celear@zebedee.teaching.cs.adelaide.edu.au [129.127.104.27]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 05:53:27 +0100 Received: from celear@zebedee.teaching.cs.adelaide.edu.au by zebedee.teaching.cs.adelaide.edu.au (8.6.12/AndrewR-MatthewD-950530-CS) id PAA27303; Mon, 11 Dec 1995 15:22:48 +1030 X-Authentic-Sender: celear@zebedee.teaching.cs.adelaide.edu.au From: Colin Message-Id: <199512110452.PAA27303@zebedee.teaching.cs.adelaide.edu.au> Subject: Re: Experience To: link@alpha.pulsar.net (Tadah) Date: Mon, 11 Dec 1995 15:22:47 +1030 (CST) Cc: crossfire@ifi.uio.no In-Reply-To: from "Tadah" at Dec 10, 95 11:46:44 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3183 Status: RO etc> etc> etc> etc>On Mon, 11 Dec 1995, Colin wrote: etc> etc>> etc> etc>> etc>Another thing that would be nice to work on is the window on the right, a etc>> etc>very annoying thing is having a spell list too big for that window. etc>> etc>Being able to resize the window would allow that to fit in. I would also etc>> etc>suggest a pause that is placed depending on how big ya make the window, etc>> etc>and also something like "spell protection*" Might be nice if ya want a etc>> etc>list of just protection spells for example. etc>> etc> etc>> etc>> play it in split window mode and you can resize that window etc>> and make it as big as you like. etc> etc>HMm. I apologize then, I didn't know there was such a mode. How can I etc>enter into that? And how can I save window position/size? etc> I believe you start the client with the -split option or use -w when running the server. savewinpos should save the window postion for a particular character. I can't verify how well it works since I use a single window.. etc>> scrollable history is what it really needs, but it's painful etc>> to program, the other way to go is paging all the output etc>> like shop inventories already do. which is a bit messy! etc> etc>Yes, scrollable history would be very nice. :> very nice indeed :) etc> etc> etc>Thanks, etc>Link etc> etc> -- ***************************************************************************** oooo$$$$$$$$$$$$oooo oo$$$$$$$$$$$$$$$$$$$$$$$$o oo$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$o o$ $$ o$ o $ oo o$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$o $$ $$ $$o$ oo $ $ "$ o$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$o $$$o$$o$ "$$$$$$o$ o$$$$$$$$$ $$$$$$$$$$$ $$$$$$$$$$o $$$$$$$$ $$$$$$$ $$$$$$$$$$$ $$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$$$$ """$$$ "$$$""""$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ "$$$ $$$ o$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ "$$$o o$$" $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$o $$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$" "$$$$$$ooooo$$$$o o$$$oooo$$$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ o$$$$$$$$$$$$$$$$$ $$$$$$$$"$$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$"""""""" """" $$$$ "$$$$$$$$$$$$$$$$$$$$$$$$$$$$" o$$$ "$$$o """$$$$$$$$$$$$$$$$$$"$$" $$$ $$$o "$$""$$$$$$"""" o$$$ $$$$o oo o$$$" "$$$$o o$$$$$$o"$$$$o o$$$$ "$$$$$oo ""$$$$o$$$$$o o$$$$"" ""$$$$$oooo "$$$o$$$$$$$$$""" ""$$$$$$$oo $$$$$$$$$$ """"$$$$$$$$$$$ $$$$$$$$$$$$ $$$$$$$$$$" "$$$"""" To you, from me, with Affection. **************************************************************************** From crossfire-request Mon Dec 11 05:47:14 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 05:47:12 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id XAA07180; Sun, 10 Dec 1995 23:46:45 -0500 Date: Sun, 10 Dec 1995 23:46:44 -0500 (EST) From: Tadah To: Colin cc: crossfire@ifi.uio.no Subject: Re: Experience In-Reply-To: <199512110442.PAA26914@zebedee.teaching.cs.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 11 Dec 1995, Colin wrote: > etc> > etc>Another thing that would be nice to work on is the window on the right, a > etc>very annoying thing is having a spell list too big for that window. > etc>Being able to resize the window would allow that to fit in. I would also > etc>suggest a pause that is placed depending on how big ya make the window, > etc>and also something like "spell protection*" Might be nice if ya want a > etc>list of just protection spells for example. > etc> > > play it in split window mode and you can resize that window > and make it as big as you like. HMm. I apologize then, I didn't know there was such a mode. How can I enter into that? And how can I save window position/size? > scrollable history is what it really needs, but it's painful > to program, the other way to go is paging all the output > like shop inventories already do. which is a bit messy! Yes, scrollable history would be very nice. :> Thanks, Link From crossfire-request Mon Dec 11 05:42:59 1995 Return-Path: Received: from zebedee.teaching.cs.adelaide.edu.au (celear@zebedee.teaching.cs.adelaide.edu.au [129.127.104.27]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 05:42:51 +0100 Received: from celear@zebedee.teaching.cs.adelaide.edu.au by zebedee.teaching.cs.adelaide.edu.au (8.6.12/AndrewR-MatthewD-950530-CS) id PAA26914; Mon, 11 Dec 1995 15:12:24 +1030 X-Authentic-Sender: celear@zebedee.teaching.cs.adelaide.edu.au From: Colin Message-Id: <199512110442.PAA26914@zebedee.teaching.cs.adelaide.edu.au> Subject: Re: Experience To: link@alpha.pulsar.net (Tadah) Date: Mon, 11 Dec 1995 15:12:23 +1030 (CST) Cc: crossfire@ifi.uio.no In-Reply-To: from "Tadah" at Dec 10, 95 11:38:32 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3711 Status: RO etc> etc> etc> etc>On Mon, 11 Dec 1995, Colin wrote: etc> etc>> etc>> Also would it be possible to change the dimensions of the display etc>> etc>> window so you can see which skill you are using at a etc>> etc>> particular moment. i.e. adding a permanent skill line under the etc>> etc>> Range one. etc>> etc>> etc>> etc>> Just some thoughts I had while playing the game. etc>> etc>> etc>> etc>> especially important if you plan to change the way hp etc>> etc>> are allocated with experience. etc>> etc> etc>> etc>I agree with that. What would be nice is to do something simular in the etc>> etc>IDsoftware games like DOOM.. ALlow resizing the windows, but clicking etc>> etc>maxmize, or by dragging the borders, whatever.. Only the bigger you make etc>> etc>it, the more infomation that can be contained in it. Might also be nice etc>> etc>to choose what fields to include first, whatever. etc>> etc> etc>> etc>> Only if lighting code is included, No point being able to see the whole map etc> etc>Well, no, I didn't mean the map. Leave the map alone. But be able to etc>change some of the informational fields around that. etc> etc>Another thing that would be nice to work on is the window on the right, a etc>very annoying thing is having a spell list too big for that window. etc>Being able to resize the window would allow that to fit in. I would also etc>suggest a pause that is placed depending on how big ya make the window, etc>and also something like "spell protection*" Might be nice if ya want a etc>list of just protection spells for example. etc> play it in split window mode and you can resize that window and make it as big as you like. scrollable history is what it really needs, but it's painful to program, the other way to go is paging all the output like shop inventories already do. which is a bit messy! etc>-Link etc> etc> -- ***************************************************************************** oooo$$$$$$$$$$$$oooo oo$$$$$$$$$$$$$$$$$$$$$$$$o oo$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$o o$ $$ o$ o $ oo o$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$o $$ $$ $$o$ oo $ $ "$ o$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$o $$$o$$o$ "$$$$$$o$ o$$$$$$$$$ $$$$$$$$$$$ $$$$$$$$$$o $$$$$$$$ $$$$$$$ $$$$$$$$$$$ $$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$$$$ """$$$ "$$$""""$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ "$$$ $$$ o$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ "$$$o o$$" $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$o $$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$" "$$$$$$ooooo$$$$o o$$$oooo$$$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ o$$$$$$$$$$$$$$$$$ $$$$$$$$"$$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$"""""""" """" $$$$ "$$$$$$$$$$$$$$$$$$$$$$$$$$$$" o$$$ "$$$o """$$$$$$$$$$$$$$$$$$"$$" $$$ $$$o "$$""$$$$$$"""" o$$$ $$$$o oo o$$$" "$$$$o o$$$$$$o"$$$$o o$$$$ "$$$$$oo ""$$$$o$$$$$o o$$$$"" ""$$$$$oooo "$$$o$$$$$$$$$""" ""$$$$$$$oo $$$$$$$$$$ """"$$$$$$$$$$$ $$$$$$$$$$$$ $$$$$$$$$$" "$$$"""" To you, from me, with Affection. **************************************************************************** From crossfire-request Mon Dec 11 05:38:39 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 05:38:37 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id XAA07141; Sun, 10 Dec 1995 23:38:32 -0500 Date: Sun, 10 Dec 1995 23:38:32 -0500 (EST) From: Tadah To: Colin cc: crossfire@ifi.uio.no Subject: Re: Experience In-Reply-To: <199512110432.PAA26623@zebedee.teaching.cs.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 11 Dec 1995, Colin wrote: > etc>> Also would it be possible to change the dimensions of the display > etc>> window so you can see which skill you are using at a > etc>> particular moment. i.e. adding a permanent skill line under the > etc>> Range one. > etc>> > etc>> Just some thoughts I had while playing the game. > etc>> > etc>> especially important if you plan to change the way hp > etc>> are allocated with experience. > etc> > etc>I agree with that. What would be nice is to do something simular in the > etc>IDsoftware games like DOOM.. ALlow resizing the windows, but clicking > etc>maxmize, or by dragging the borders, whatever.. Only the bigger you make > etc>it, the more infomation that can be contained in it. Might also be nice > etc>to choose what fields to include first, whatever. > etc> > > Only if lighting code is included, No point being able to see the whole map Well, no, I didn't mean the map. Leave the map alone. But be able to change some of the informational fields around that. Another thing that would be nice to work on is the window on the right, a very annoying thing is having a spell list too big for that window. Being able to resize the window would allow that to fit in. I would also suggest a pause that is placed depending on how big ya make the window, and also something like "spell protection*" Might be nice if ya want a list of just protection spells for example. -Link From crossfire-request Mon Dec 11 05:33:25 1995 Return-Path: Received: from zebedee.teaching.cs.adelaide.edu.au (celear@zebedee.teaching.cs.adelaide.edu.au [129.127.104.27]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 05:33:18 +0100 Received: from celear@zebedee.teaching.cs.adelaide.edu.au by zebedee.teaching.cs.adelaide.edu.au (8.6.12/AndrewR-MatthewD-950530-CS) id PAA26623; Mon, 11 Dec 1995 15:02:29 +1030 X-Authentic-Sender: celear@zebedee.teaching.cs.adelaide.edu.au From: Colin Message-Id: <199512110432.PAA26623@zebedee.teaching.cs.adelaide.edu.au> Subject: Re: Experience To: link@alpha.pulsar.net (Tadah) Date: Mon, 11 Dec 1995 15:02:28 +1030 (CST) Cc: crossfire@ifi.uio.no In-Reply-To: from "Tadah" at Dec 10, 95 11:29:21 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2880 Status: RO etc> etc> etc> etc>On Mon, 11 Dec 1995, Colin wrote: etc> etc>> etc>> I have inadvertantly discovered a very real problem with etc>> invoking spells. etc>> etc>** text cut ** etc>> etc>> Also would it be possible to change the dimensions of the display etc>> window so you can see which skill you are using at a etc>> particular moment. i.e. adding a permanent skill line under the etc>> Range one. etc>> etc>> Just some thoughts I had while playing the game. etc>> etc>> especially important if you plan to change the way hp etc>> are allocated with experience. etc> etc>I agree with that. What would be nice is to do something simular in the etc>IDsoftware games like DOOM.. ALlow resizing the windows, but clicking etc>maxmize, or by dragging the borders, whatever.. Only the bigger you make etc>it, the more infomation that can be contained in it. Might also be nice etc>to choose what fields to include first, whatever. etc> Only if lighting code is included, No point being able to see the whole map etc>-Link etc> etc> -- ***************************************************************************** oooo$$$$$$$$$$$$oooo oo$$$$$$$$$$$$$$$$$$$$$$$$o oo$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$o o$ $$ o$ o $ oo o$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$o $$ $$ $$o$ oo $ $ "$ o$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$o $$$o$$o$ "$$$$$$o$ o$$$$$$$$$ $$$$$$$$$$$ $$$$$$$$$$o $$$$$$$$ $$$$$$$ $$$$$$$$$$$ $$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$$$$ """$$$ "$$$""""$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ "$$$ $$$ o$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ "$$$o o$$" $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$o $$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$" "$$$$$$ooooo$$$$o o$$$oooo$$$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ o$$$$$$$$$$$$$$$$$ $$$$$$$$"$$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$"""""""" """" $$$$ "$$$$$$$$$$$$$$$$$$$$$$$$$$$$" o$$$ "$$$o """$$$$$$$$$$$$$$$$$$"$$" $$$ $$$o "$$""$$$$$$"""" o$$$ $$$$o oo o$$$" "$$$$o o$$$$$$o"$$$$o o$$$$ "$$$$$oo ""$$$$o$$$$$o o$$$$"" ""$$$$$oooo "$$$o$$$$$$$$$""" ""$$$$$$$oo $$$$$$$$$$ """"$$$$$$$$$$$ $$$$$$$$$$$$ $$$$$$$$$$" "$$$"""" To you, from me, with Affection. **************************************************************************** From crossfire-request Mon Dec 11 05:29:27 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 05:29:25 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id XAA07079; Sun, 10 Dec 1995 23:29:21 -0500 Date: Sun, 10 Dec 1995 23:29:21 -0500 (EST) From: Tadah To: Colin cc: cf Subject: Re: Experience In-Reply-To: <199512110331.OAA23998@zebedee.teaching.cs.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 11 Dec 1995, Colin wrote: > > I have inadvertantly discovered a very real problem with > invoking spells. > ** text cut ** > > Also would it be possible to change the dimensions of the display > window so you can see which skill you are using at a > particular moment. i.e. adding a permanent skill line under the > Range one. > > Just some thoughts I had while playing the game. > > especially important if you plan to change the way hp > are allocated with experience. I agree with that. What would be nice is to do something simular in the IDsoftware games like DOOM.. ALlow resizing the windows, but clicking maxmize, or by dragging the borders, whatever.. Only the bigger you make it, the more infomation that can be contained in it. Might also be nice to choose what fields to include first, whatever. -Link From crossfire-request Mon Dec 11 04:32:31 1995 Return-Path: Received: from zebedee.teaching.cs.adelaide.edu.au (celear@zebedee.teaching.cs.adelaide.edu.au [129.127.104.27]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 04:32:27 +0100 Received: from celear@zebedee.teaching.cs.adelaide.edu.au by zebedee.teaching.cs.adelaide.edu.au (8.6.12/AndrewR-MatthewD-950530-CS) id OAA23998 for crossfire@ifi.uio.no; Mon, 11 Dec 1995 14:01:57 +1030 X-Authentic-Sender: celear@zebedee.teaching.cs.adelaide.edu.au From: Colin Message-Id: <199512110331.OAA23998@zebedee.teaching.cs.adelaide.edu.au> Subject: Experience To: crossfire@ifi.uio.no (cf) Date: Mon, 11 Dec 1995 14:01:56 +1030 (CST) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3038 Status: RO I have inadvertantly discovered a very real problem with invoking spells. As a matter of habit from the days when I used to cheat I got used to invoking all my spells. Now with the new skills I can raise my level in any skill I wish merely by using invoke while my skill field is set to whatever skill I wish to improve in. This has caused my a great deal of pain because I didn't notice it for a fair while and my traps finding and fighting skills went up enormously while my mage skills went no where and I am a fireborn.. The reason I find this so objectionable is because I can use it to up my praying skill without using any clerical abilities. Can this be easily fixed or is it as I think something inherent in the game setting the skill flag when you invoke a spell doesn't stop you from barging off and fighting something thereby changing your skill flag. Also would it be possible to change the dimensions of the display window so you can see which skill you are using at a particular moment. i.e. adding a permanent skill line under the Range one. Just some thoughts I had while playing the game. especially important if you plan to change the way hp are allocated with experience. -- ***************************************************************************** oooo$$$$$$$$$$$$oooo oo$$$$$$$$$$$$$$$$$$$$$$$$o oo$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$o o$ $$ o$ o $ oo o$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$o $$ $$ $$o$ oo $ $ "$ o$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$o $$$o$$o$ "$$$$$$o$ o$$$$$$$$$ $$$$$$$$$$$ $$$$$$$$$$o $$$$$$$$ $$$$$$$ $$$$$$$$$$$ $$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$$$$ """$$$ "$$$""""$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ "$$$ $$$ o$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ "$$$o o$$" $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$o $$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$" "$$$$$$ooooo$$$$o o$$$oooo$$$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ o$$$$$$$$$$$$$$$$$ $$$$$$$$"$$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$"""""""" """" $$$$ "$$$$$$$$$$$$$$$$$$$$$$$$$$$$" o$$$ "$$$o """$$$$$$$$$$$$$$$$$$"$$" $$$ $$$o "$$""$$$$$$"""" o$$$ $$$$o oo o$$$" "$$$$o o$$$$$$o"$$$$o o$$$$ "$$$$$oo ""$$$$o$$$$$o o$$$$"" ""$$$$$oooo "$$$o$$$$$$$$$""" ""$$$$$$$oo $$$$$$$$$$ """"$$$$$$$$$$$ $$$$$$$$$$$$ $$$$$$$$$$" "$$$"""" To you, from me, with Affection. **************************************************************************** From crossfire-request Mon Dec 11 01:20:17 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Dec 1995 01:20:17 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id TAA29353; Sun, 10 Dec 1995 19:20:07 -0500 Date: Sun, 10 Dec 1995 19:20:07 -0500 From: Brian Thomas Message-Id: <199512110020.TAA29353@chaupher.gsfc.nasa.gov> To: srin9340@nova.gmi.edu Subject: Re: summoning Cc: crossfire@ifi.uio.no Status: RO > Akshay Srinivasan writes: > > I have noticed that summon cult monsters can summon monsters who are more than > 1 square in size and for some reason when you run against them they block you > instead of switching positions and getting out of the way. This is not a very > pleasant and it would be great if it were fixed. > I coded that spell; it is basically a hack on the older summon pet monsters spell. I have'nt checked the code to find the 'problem', but I imagine it lies somewhere within move_player() not allowing the player to displace friendly multi-square monsters. When I first saw this effect, I assumed it was intended. How likely is it that a player can make a huge monster get out of his way? Also, I forsee difficulties in making the player and multi-square creature trade places when the geometry of the room is bad (like the player is in a small space that the monster has to trade into). Since multi-square monsters can be quite powerfull (you summoned a troll, correct?) not being able to make it move out of your way seems like an appropriate limitation to me. b.t. > Thanks, > Akshay > From crossfire-request Sun Dec 10 23:09:58 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sun, 10 Dec 1995 23:09:57 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id RAA29297 for crossfire@ifi.uio.no; Sun, 10 Dec 1995 17:09:56 -0500 Date: Sun, 10 Dec 1995 17:09:56 -0500 From: Brian Thomas Message-Id: <199512102209.RAA29297@chaupher.gsfc.nasa.gov> To: crossfire@ifi.uio.no Subject: Lighting code readable now Status: RO Sorry, due to my haste last friday I forgot to make the lighting code in light1.tar.gz readable (!) So now, thanks to many alert parties, I am aware of my goof and have fixed it. b.t. ps let me head off more messages right now.. the code is on ftp.astro.psu.edu in pub/thomas. From crossfire-request Sun Dec 10 22:56:37 1995 Return-Path: Received: from acy1.digex.net (acy1.digex.net [198.180.35.3]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sun, 10 Dec 1995 22:56:36 +0100 Received: (from link@localhost) by acy1.digex.net (8.6.12/8.6.12) id QAA06833 ; for ; Sun, 10 Dec 1995 16:55:12 -0500 Date: Sun, 10 Dec 1995 16:55:11 -0500 (EST) From: Matt Cortes To: Brian Thomas cc: crossfire@ifi.uio.no, rennigeb@student.adelaide.edu.au Subject: Crossfire List In-Reply-To: <199512081529.KAA28393@chaupher.gsfc.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I'm not sure who manages this list or I guess it would have been more appropriate to send that person mail directly.. Anyway, I have changed address and will shortly no longer be at link@acy.digex.net, I was hopping I could get all crossfire lists sent to my new address, link@alpha.pulsar.net. Thank you. Oh, and of course if digex.net could be removed from it so I don't get contacted about it later in life. :> Also if anyone wants fast telnet accounts cheap, I'm now a internet provider. :) Thanks, Link From crossfire-request Sun Dec 10 09:37:55 1995 Return-Path: Received: from gmi.edu (nova.gmi.edu [192.138.137.2]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Sun, 10 Dec 1995 09:37:54 +0100 Received: from achieva.gmi.edu by gmi.edu (5.x/SMI-SVR4) id AA21871; Sun, 10 Dec 1995 03:20:16 -0500 Received: by achieva.gmi.edu (5.x/SMI-SVR4) id AA02990; Sun, 10 Dec 1995 03:19:01 -0500 Date: Sun, 10 Dec 1995 03:19:01 -0500 From: srin9340@nova.gmi.edu (Akshay Srinivasan) Message-Id: <9512100819.AA02990@achieva.gmi.edu> To: crossfire@ifi.uio.no Subject: summoning X-Sun-Charset: US-ASCII Status: RO I have noticed that summon cult monsters can summon monsters who are more than 1 square in size and for some reason when you run against them they block you instead of switching positions and getting out of the way. This is not a very pleasant and it would be great if it were fixed. Thanks, Akshay From crossfire-request Sat Dec 9 05:46:43 1995 Return-Path: Received: from acy1.digex.net (acy1.digex.net [198.180.35.3]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 9 Dec 1995 05:46:42 +0100 Received: (from link@localhost) by acy1.digex.net (8.6.12/8.6.12) id XAA02773 ; for ; Fri, 8 Dec 1995 23:43:59 -0500 Date: Fri, 8 Dec 1995 23:43:58 -0500 (EST) From: Matt Cortes To: Mark Wedel cc: Karl Hagen Geppert , crossfire@ifi.uio.no, matsuda@arch.comp.kyutech.ac.jp Subject: Re: Spell setting In-Reply-To: <9512081814.ZM9569@stealth.eng.pyramid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 8 Dec 1995, Mark Wedel wrote: > On Dec 8, 11:39am, Karl Hagen Geppert wrote: > > Subject: Re: Spell setting > > Jari Vanhala quite definitely said [typed] > > > Well, there are somewhere around 130 spells or so. But a good number of those > are not spells that can be learned (they are either 'monster' spells or things > that potions, rods, etc do.) > > So if we have 100 spells, that is still a lot of keys. But one issue I find > is that many of those spells aren't used very often (if you have major healing, > how often do you use minor healing?) > > I agree that you can start to run out of keybindings, but each key can be > bound with 3 different combinations.. > > I doubt command completiong will be done anytime soon. If you can't remember > commands, you can always type help and it will show you all the commands. (and > if you can't remember it, then how often do you end up using it?) > > Also, you can bind keys to leave them in command mode. Thus, you could bind a > key (with the -e flag) so that when you press the key it does 'cast rune of ', > and leaves off at that point for you to enter the last part of it (fire, frost, > shocking, blasting, etc.) > > I suppose if you were really creative, you could do the same thing with > minor/major, small/medium/large, protection from ..., etc. > > I will add in something so that it will match substrings or soemthing when it > prints a list. > > I also want to do more with output, so that it will actually do a page thing > for all output, if enough is spit out fast enough (right now, there are various > places that have paging specificly in place, that also makes the code messy.) > By doing it via generic buffering, it should add htings and clean up some of > the code. > > > -- > --Mark > I'm new to this list, and the game. But I'm a high-novice programmer, with a 14th level character already, so I have some idea of the stuff going on. I have an idea.. Multiple commands per bind would be great. For example, some people liek to run alot of the protection spells together, at least I do. It would be great to be able to have one key that runs a bunch of spells at once. Also thought about some of the larger enemies I've found in crossfire, how they cast all kinds of stuff at once. Be nice to match that. :> Thanks, Link From crossfire-request Sat Dec 9 03:19:08 1995 Return-Path: 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, 9 Dec 1995 03:19:07 +0100 Received: from stealth.eng.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA17547; Fri, 8 Dec 95 18:17:02 -0800 Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA09571; Sat, 9 Dec 95 02:14:28 GMT From: "Mark Wedel" Message-Id: <9512081814.ZM9569@stealth.eng.pyramid.com> Date: Fri, 8 Dec 1995 18:14:28 -0800 In-Reply-To: Karl Hagen Geppert "Re: Spell setting" (Dec 8, 11:39am) References: <199512082139.AA16693@kultarr.cit.gu.edu.au> X-Mailer: Z-Mail (3.2.0 06sep94) To: Karl Hagen Geppert , crossfire@ifi.uio.no Subject: Re: Spell setting Cc: matsuda@arch.comp.kyutech.ac.jp Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: RO On Dec 8, 11:39am, Karl Hagen Geppert wrote: > Subject: Re: Spell setting > Jari Vanhala quite definitely said [typed] > > >>I think that not only magic spell, but other commands > >>( save winpos etc. ) are difficult to remember. > >>And inputing commands is very bother. > > Yes, if you type those command.. You should bind those command to > >keys and just push a button.. > > There just are not enough keys for the number of spells you can learn. A > characacter that is good for both sides of magic can exceed several screensful > worth of spells. I have all my function keys, keypad, special keys && most of > the letters bound (not to forget the shift modified keys too), and still have > to type 'cast commands regularly. However when I forget what the second key > word of a spell is, the standard 'cast list gives me several screensfull of > possibilities. > > Karl > > >-- End of excerpt from Karl Hagen Geppert Well, there are somewhere around 130 spells or so. But a good number of those are not spells that can be learned (they are either 'monster' spells or things that potions, rods, etc do.) So if we have 100 spells, that is still a lot of keys. But one issue I find is that many of those spells aren't used very often (if you have major healing, how often do you use minor healing?) I agree that you can start to run out of keybindings, but each key can be bound with 3 different combinations.. I doubt command completiong will be done anytime soon. If you can't remember commands, you can always type help and it will show you all the commands. (and if you can't remember it, then how often do you end up using it?) Also, you can bind keys to leave them in command mode. Thus, you could bind a key (with the -e flag) so that when you press the key it does 'cast rune of ', and leaves off at that point for you to enter the last part of it (fire, frost, shocking, blasting, etc.) I suppose if you were really creative, you could do the same thing with minor/major, small/medium/large, protection from ..., etc. I will add in something so that it will match substrings or soemthing when it prints a list. I also want to do more with output, so that it will actually do a page thing for all output, if enough is spit out fast enough (right now, there are various places that have paging specificly in place, that also makes the code messy.) By doing it via generic buffering, it should add htings and clean up some of the code. -- --Mark From crossfire-request Sat Dec 9 02:36:27 1995 Return-Path: Received: from surt.ifi.uio.no (2102@surt.ifi.uio.no [129.240.76.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 9 Dec 1995 02:36:27 +0100 From: =?iso-8859-1?Q?H=E5vard_Lindheim?= MIME-Version: 1.0 Received: (from haavarl@localhost) by surt.ifi.uio.no ; Sat, 9 Dec 1995 02:36:26 +0100 Date: Sat, 9 Dec 1995 02:36:25 +0100 To: crossfire@ifi.uio.no Subject: unsubscribe Message-ID: Status: RO From crossfire-request Sat Dec 9 00:41:20 1995 Return-Path: Received: from acy1.digex.net (acy1.digex.net [198.180.35.3]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 9 Dec 1995 00:41:19 +0100 Received: (from link@localhost) by acy1.digex.net (8.6.12/8.6.12) id SAA23338 ; for ; Fri, 8 Dec 1995 18:39:42 -0500 Date: Fri, 8 Dec 1995 18:39:41 -0500 (EST) From: Matt Cortes To: Matsuda Takashi cc: crossfire@ifi.uio.no Subject: Re: Environment variables of client In-Reply-To: <199512080642.PAA02627@arch.comp.kyutech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 8 Dec 1995, Matsuda Takashi wrote: > Now, I'm modifying audio codes for supporting Network Audio System. > To achive this, I must get client's environment variable 'AUDIOSERVER' to > find where is audio server. > > Is there those mechanism? > > thanks. > > > > -Takashi Matsuda > matsuda@arch.comp.kyutech.ac.jp > Forgive me for approaching this from a novice level . But I have notied some clues that this game has sound. Is there sound support compiled into it or are you refering to an addon such as the lightning code iv'e been reading about from here? If there is sound, I would love to get it enabled. :> Thanks, Link link@acy.digex.net From crossfire-request Fri Dec 8 02:40:52 1995 Return-Path: Received: from kultarr.cit.gu.edu.au ([132.234.42.2]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 8 Dec 1995 02:40:46 +0100 Received: by kultarr.cit.gu.edu.au id AA16693 (5.67b/IDA-1.5 for crossfire@ifi.uio.no); Fri, 8 Dec 1995 11:39:49 -1000 From: Karl Hagen Geppert Message-Id: <199512082139.AA16693@kultarr.cit.gu.edu.au> Subject: Re: Spell setting To: crossfire@ifi.uio.no Date: Fri, 8 Dec 1995 11:39:49 -1000 (EST) Cc: matsuda@arch.comp.kyutech.ac.jp, K.Geppert@cit.gu.edu.au In-Reply-To: <199512080123.DAA04523@new.ton.tut.fi> from "Jari Vanhala" at Dec 8, 95 03:23:45 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 776 Status: RO Jari Vanhala quite definitely said [typed] >>I think that not only magic spell, but other commands >>( save winpos etc. ) are difficult to remember. >>And inputing commands is very bother. > Yes, if you type those command.. You should bind those command to >keys and just push a button.. There just are not enough keys for the number of spells you can learn. A characacter that is good for both sides of magic can exceed several screensful worth of spells. I have all my function keys, keypad, special keys && most of the letters bound (not to forget the shift modified keys too), and still have to type 'cast commands regularly. However when I forget what the second key word of a spell is, the standard 'cast list gives me several screensfull of possibilities. Karl From crossfire-request Fri Dec 8 20:42:26 1995 Return-Path: Received: from olympe.scinfo.u-nancy.fr (olympe.scinfo.u-nancy.fr [192.33.169.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 8 Dec 1995 20:42:24 +0100 Received: from cronos.scinfo.u-nancy.fr (cronos.scinfo.u-nancy.fr [192.33.169.10]) by olympe.scinfo.u-nancy.fr (8.7.1/8.7.1) with ESMTP id UAA04020 for ; Fri, 8 Dec 1995 20:39:43 +0100 (MET) Received: (from rougier@localhost) by cronos.scinfo.u-nancy.fr (8.6.12/8.6.12) id UAA07795 for crossfire@ifi.uio.no; Fri, 8 Dec 1995 20:39:47 +0100 From: Nicolas Rougier Message-Id: <199512081939.UAA07795@cronos.scinfo.u-nancy.fr> Subject: subscribe To: crossfire@ifi.uio.no Date: Fri, 8 Dec 1995 20:39:47 +0100 (MET) X-Mailer: ELM [version 2.4 PL24beta] Content-Type: text Status: RO From crossfire-request Fri Dec 8 20:38:34 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 8 Dec 1995 20:38:33 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id OAA28552; Fri, 8 Dec 1995 14:38:22 -0500 Date: Fri, 8 Dec 1995 14:38:22 -0500 From: Brian Thomas Message-Id: <199512081938.OAA28552@chaupher.gsfc.nasa.gov> To: srin9340@nova.gmi.edu, thomas@chaupher.gsfc.nasa.gov Subject: Re: Lighting Cc: crossfire@ifi.uio.no Status: RO Ok, I have put the patch, light1.tar.gz in pub/thomas/ on ftp.astro.psu.edu. Please keep in mind that this is beta code. I imagine its stable enough to make the next version, but, it still might contain bugs, or need tweeking for playbalance. Also, more most users, this code will make little difference in how the game plays, given that there are currently *no* dark maps in the game. b.t. From crossfire-request Fri Dec 8 20:17:24 1995 Return-Path: Received: from smarty.smart.net (smarty.smart.net [206.27.242.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 8 Dec 1995 20:17:23 +0100 Received: (stevenvr@localhost) by smarty.smart.net (8.6.9/8.6.9) id OAA19601; Fri, 8 Dec 1995 14:20:59 -0500 Date: Fri, 8 Dec 1995 14:20:55 -0500 (EST) From: "Steven C. Van Riper" To: crossfire@ifi.uio.no Subject: unsubscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO From crossfire-request Fri Dec 8 20:02:58 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 8 Dec 1995 20:02:57 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id OAA28521; Fri, 8 Dec 1995 14:02:48 -0500 Date: Fri, 8 Dec 1995 14:02:48 -0500 From: Brian Thomas Message-Id: <199512081902.OAA28521@chaupher.gsfc.nasa.gov> To: peterm@langmuir.EECS.Berkeley.EDU Subject: Re: Hit Points (dragon attack) Cc: crossfire@ifi.uio.no Status: RO Ok I just looked up the big_dragon (red dragon) stats: wc -20 and dam 10. Wc seems about right, but damage is low, for comparison "hill giants" have dam 20. b.t. From crossfire-request Fri Dec 8 20:00:11 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 8 Dec 1995 20:00:11 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id OAA28518; Fri, 8 Dec 1995 14:00:05 -0500 Date: Fri, 8 Dec 1995 14:00:05 -0500 From: Brian Thomas Message-Id: <199512081900.OAA28518@chaupher.gsfc.nasa.gov> To: peterm@langmuir.EECS.Berkeley.EDU Subject: Re: Hit Points Cc: crossfire@ifi.uio.no Status: RO Pardon the prior message, mailer cant compensate for user clumsiness :) > From: Peter Mardahl writes: > > > > Stephen John Harley writes: > > out fear of death. One case is where the player gets the "fire immunity > >" > > spell and steals from the red dragons. Perhaps the xp reward should be > > Don't those suckers claw??? They're pretty quick too! Yeah, but for some reason they dont appear to do much physical damage. I havent checked it, but mabye mon->stats.dam (or stats.wc) is set too low. Or, perhaps the attack code is screwy, but I doubt it. > > > Still, other scenarios for gaining hp from xp should be considered. > > I havent been able to construct one which is simple and sensible. > > Ideas anyone? > > How's it work now? Or is it documented? Did you go with a proposal > I think was floated about 10hp/fighter level, 4/others or something like > that? > Hp are now awarded by just summing all the player experience, then assigning an "overall level" based on this tally. The "overall level" determines HP. b.t. > Regards, > > PeterM > > From crossfire-request Fri Dec 8 19:56:36 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 8 Dec 1995 19:56:35 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id NAA28513; Fri, 8 Dec 1995 13:56:31 -0500 Date: Fri, 8 Dec 1995 13:56:31 -0500 From: Brian Thomas Message-Id: <199512081856.NAA28513@chaupher.gsfc.nasa.gov> To: thomas@chaupher.gsfc.nasa.gov, peterm@langmuir.EECS.Berkeley.EDU Subject: Re: Hit Points Cc: crossfire@ifi.uio.no Status: RO From crossfire-request Fri Dec 8 18:23:10 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 8 Dec 1995 18:23:07 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id MAA28459; Fri, 8 Dec 1995 12:22:53 -0500 Date: Fri, 8 Dec 1995 12:22:53 -0500 From: Brian Thomas Message-Id: <199512081722.MAA28459@chaupher.gsfc.nasa.gov> To: srin9340@nova.gmi.edu Subject: Re: Lighting Cc: crossfire@ifi.uio.no Status: RO > From: srin9340@nova.gmi.edu (Akshay Srinivasan) > > Sorry to bother Brian but I was wondering how soon the patch for the lighting > code will be available on ftp.astro.psu.edu and I hope there will be notice on > this mailing-list. This should reduce the number of hits astro has been taking > from me prowling around /pub/thomas eagerly awaiting it :) > Well I suppose its nice that someone else out there is enthusiatic about the code :). As it happens I am trying to check out if the Install script I made for it is working. I will have something out within the next few hours. Again, I dont expect to have much documentation for it. A brief summary, - fast calculation of lighting. For players los (line- of sight)is calculated from a linked list of nearby lights. For monsters, no los is calculated, rather a modified check_wakeup routine is used to see if they will follow/attack players. Monsters with can_see_in_dark act normally in dark areas. - New attacktype -AT_BLIND. This is a pretty severe penalty for monsters and players alike. Players cant see any square but thier own, monsters can only attack/follow players who are in an adjacent square. Need to make the monsters stumble around when no player is near, rather than the current way in which they stand around waiting to get "ace'd". Undead cannot be blinded, nor should be effected by darkness. For other monsters, if they have immunity to blindness or can see invisible, they are uneffected by AT_BLIND attacks. - New spells. Some magician, some clerical. They work, but may need to be adjusted for playbalance. Normal spells available include: "light", "darkness", "sunspear", "faery fire" and "dark vision". All spells (but darkvision) work (do something) whether the lighting code is used or not. - Modified archetypes and artifacts list to encompass changes to the code from lighting. Also, some new archs instroduced, namely "flint and steel" for lighting stuff on fire and "torch" a source of light. -b.t. > Have fun, > Akshay > From crossfire-request Fri Dec 8 17:34:09 1995 Return-Path: Received: from gmi.edu (nova.gmi.edu [192.138.137.2]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 8 Dec 1995 17:34:08 +0100 Received: from corvair.gmi.edu by gmi.edu (5.x/SMI-SVR4) id AA16832; Fri, 8 Dec 1995 11:34:06 -0500 Received: by corvair.gmi.edu (5.x/SMI-SVR4) id AA05438; Fri, 8 Dec 1995 11:22:31 -0500 Date: Fri, 8 Dec 1995 11:22:31 -0500 From: srin9340@nova.gmi.edu (Akshay Srinivasan) Message-Id: <9512081622.AA05438@corvair.gmi.edu> To: crossfire@ifi.uio.no Subject: Lighting X-Sun-Charset: US-ASCII Status: RO Sorry to bother Brian but I was wondering how soon the patch for the lighting code will be available on ftp.astro.psu.edu and I hope there will be notice on this mailing-list. This should reduce the number of hits astro has been taking from me prowling around /pub/thomas eagerly awaiting it :) Have fun, Akshay From crossfire-request Fri Dec 8 16:29:20 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 8 Dec 1995 16:29:18 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id KAA28393; Fri, 8 Dec 1995 10:29:16 -0500 Date: Fri, 8 Dec 1995 10:29:16 -0500 From: Brian Thomas Message-Id: <199512081529.KAA28393@chaupher.gsfc.nasa.gov> To: crossfire@ifi.uio.no, rennigeb@student.adelaide.edu.au Subject: Re: Hit Points Status: RO > Stephen John Harley writes: > > After playing the latest version I was surprised that I could increase my > hit points by using skills like search. The classical definition of HP's I am responsible for this code change. The points that you bring up are important ones, namely 1) gaining hit points based on non- combat skills seems silly and 2) if we only hand out hitpoints for fighter skills, the other classes (mages, priests, thieves,..) will not be very well balanced for play. So, basically I decided to take the "unrealistic" route of making the game playable. Are there other solutions? Should we change? I would like to point out that one gains little xp from the use of the "non-risk" skills (which are "find traps", the identifying skills like "smithery", and movement skills like "mountaineer). Skills like "picklocks" and "stealing" do have very real risk. In the case of the former, you automatically set off traps in the door (and I grant that this is not a huge "risk", but you dont gain much xp from using this skill either!). In the case of stealing, many times you have to stand, without attacking, next to some hostile creature to steal stuff. I have died more than once from deciding to "steal just one more thing" from a creature. But then again, a player at higher levels can engineer the situation to where they can steal from a creature with out fear of death. One case is where the player gets the "fire immunity" spell and steals from the red dragons. Perhaps the xp reward should be decreased in the case of stealing from hostile creatures (Or, immunity spells should be made much harder to obtain since they unbalance the game..) Still, other scenarios for gaining hp from xp should be considered. I havent been able to construct one which is simple and sensible. Ideas anyone? b.t. From crossfire-request Fri Dec 8 15:54:25 1995 Return-Path: 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 ; Fri, 8 Dec 1995 15:54:24 +0100 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by mne.ifi.uio.no ; Fri, 8 Dec 1995 15:54:23 +0100 Date: Fri, 8 Dec 1995 15:54:23 +0100 Message-Id: <199512081454.14522.mne.ifi.uio.no@ifi.uio.no> To: srajput@math.utk.edu CC: crossfire@ifi.uio.no In-reply-to: (srajput@math.utk.edu) Subject: Re: Spell setting Status: RO [Sanjay Rajput] | How does one get off this mailing list? You send a message to crossfire-request stating your desires, and I do my best to fullfil them. Remember that announcements of new versions are sent to a different list, but you need to tell me if you want to keep getting announcements. Kjetil T. From crossfire-request Fri Dec 8 14:57:57 1995 Return-Path: Received: from fire1b.math.utk.edu (srajput@FIRE1B.MATH.UTK.EDU [198.78.198.28]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 8 Dec 1995 14:57:56 +0100 Received: by fire1b.math.utk.edu (cf v2.11c-UTK) id IAA00264; Fri, 8 Dec 1995 08:56:54 GMT Date: Fri, 8 Dec 1995 08:56:53 +0000 (GMT) From: "Sanjay Rajput (lab)" To: Matsuda Takashi cc: K.Geppert@cit.gu.edu.au, crossfire@ifi.uio.no Subject: Re: Spell setting In-Reply-To: <199512080037.JAA29108@arch.comp.kyutech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO How does one get off this mailing list? :) ********************************************************************** Sanjay Rajput srajput@math.utk.edu "You refuse to let anybody love you..." "Love is for poets." #. @>ZZZZZZZZZZZZZZ@%@;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;/ #' "In the end, there can be only one." ********************************************************************** From crossfire-request Thu Dec 7 06:15:10 1995 Return-Path: Received: from kultarr.cit.gu.edu.au ([132.234.42.2]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Thu, 7 Dec 1995 06:15:06 +0100 Received: by kultarr.cit.gu.edu.au id AA00889 (5.67b/IDA-1.5 for crossfire@ifi.uio.no); Thu, 7 Dec 1995 15:14:08 -1000 From: Karl Hagen Geppert Message-Id: <199512080114.AA00889@kultarr.cit.gu.edu.au> Subject: Spell setting To: crossfire@ifi.uio.no Date: Thu, 7 Dec 1995 15:14:08 -1000 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 534 Status: RO G'day, Wondering if anyone thinks the following is a good enough idea to refine in crossfire. I can never remember the name of the spell when I need to cast it, what with create wall, build wall, and wall of thorns sort of ambiguities. Could it be arranged that when you type cast keyword, crossfire list all the spells that you know that begin with that keyword? For example cast summon would return summon water elemental, summon air elemental, summon fire elemental. Cheers Karl (aka airstrike the elf). karlg@cit.gu.edu.au From crossfire-request Tue Dec 19 21:01:36 1995 Return-Path: Received: from kaukau.comp.vuw.ac.nz (kaukau.comp.vuw.ac.nz [130.195.5.20]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 19 Dec 1995 21:01:33 +0100 Received: from debretts.comp.vuw.ac.nz (debretts.comp.vuw.ac.nz [130.195.8.46]) by kaukau.comp.vuw.ac.nz (8.6.B/8.6.9-VUW) with ESMTP id JAA18773 for ; Wed, 20 Dec 1995 09:01:03 +1300 From: Stephen Wray Received: (stevew@localhost) by debretts.comp.vuw.ac.nz (8.6.10/8.6.6) id JAA09842; Wed, 20 Dec 1995 09:01:19 +1300 Date: Wed, 20 Dec 1995 09:01:19 +1300 Message-Id: <199512192001.JAA09842@debretts.comp.vuw.ac.nz> To: crossfire@ifi.uio.no Subject: attack_movement fix Reply-to: Steve.Wray@vuw.ac.nz Status: RO -----BEGIN PGP SIGNED MESSAGE----- There is a bug in the attack movement code. I've fixed it but... I don't know how to produce a patch file and I don't know where to send the patch. So if some kind soul would tell me... Also, the hit-run attack mode appears not to work because there is such a long delay between hitting and running -- the monster gets 25 hits before running 25 moves, then comes back for more. I think this is too much, but then it really should be a variable. My child-thieves now rush up hit a few times and run away real fast. then they follow the character around, rush up again... 8-) One should be able to specify how much hitting and how much running a monster does in a map or archetypes. How should I handle this? Suggestions? These attack modes are so cool that I seriously wonder why they havn't been used in any archetypes or maps????? - -- - --- **********************T***H***E***L***E***M***A********************** 44. For pure will, unassuaged of purpose, delivered from the lust of result, is every way perfect. -- LIBER AL vel LEGIS ******************************IN*LVX********************************* Stephen Wray -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQCVAgUBMNcaCCt7qh9JVcfZAQEqywP+KXBnUC2cx+D3p8RY926RGrwKObo7D4dU XrtmRtYDAI8+l+efYvujtlS0fP633fnbVtWEenhMnBj6LH1aJ/IBj+5VoftHSGtD DMMl51KnWfQe71bN8jmpKfVGMUGf15m4AUpg7BBVTfktFU1SaBJwzwYxQ42Au5xB 4edjTyXUA6g= =qV6z -----END PGP SIGNATURE----- From crossfire-request Tue Dec 19 16:45:37 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id ; Tue, 19 Dec 1995 16:45:35 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id KAA20801; Tue, 19 Dec 1995 10:34:36 -0500 Date: Tue, 19 Dec 1995 10:34:36 -0500 (EST) From: Matt Cortes To: Mark Wedel cc: Mark Wedel , larso@ifi.uio.no, thomas@chaupher.gsfc.nasa.gov, crossfire@ifi.uio.no Subject: Re: Spoiler generation (was Re: reading books) In-Reply-To: <9512181614.ZM2384@stealth.eng.pyramid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 18 Dec 1995, Mark Wedel wrote: > However, web pages are something that each site keeps up to date. As of now, > there is no standard set of html documents that people can just set up a site > with - each site that has been set up has been a custom job (or the information > grabbed from other sites.) > > That said, it is up to each person who has such a site to keep it up to date. > Unfortunately, even the docs that come with crossfire are out of date, so how > up to date can you expect web pages (I was just looking through some of the > docs, and the PlayerStats file doesn't have Pow mentioned for any of the > classes). I understand that. But its something that I think needs to be done anyway. At least the dates can be changed. Maybe its just me, but it really does drive me nuts when I see old stuff. And, as fun as it is to just add new stuff to the game, we should (need) to document everything so far. Oh, and what the heck is "Pow"? > I am working on my own set of web pages that I will eventually put on a public > site someplace. These are mostly just html versions of existing docs. This sounds great, I look forward to seeing it. Are you doing the html conversion by hand or did ya find a text formatting program that does the job? -Matt From crossfire-request Tue Dec 19 16:05:06 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 19 Dec 1995 16:05:03 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id KAA20759; Tue, 19 Dec 1995 10:04:31 -0500 Date: Tue, 19 Dec 1995 10:04:30 -0500 (EST) From: Matt Cortes To: Petri Heinila cc: crossfire@ifi.uio.no Subject: Re: Sounds (various ideas - long) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 18 Dec 1995, Petri Heinila wrote: > > Huge .au files is not good at all. In my opinion, the reason must > > systems don't have MIDI support is because people aren't supporting it. > > If people would forge ahead and make whatever needs to be made, without > > worrying about how many systems support it, it would speed up the > > encouragement to get everyone to upgrade. What happens when all the new > > stuff comming out works fine on your old computer? No need to upgrade, > > technology stands still. Kinda drastic, but I feel strong about that > > matter. :> > > That is a kind of reality, I know people using still DOS :) You should come over the the states some time. I work as a COmputer Consultant, I see at least a different 8088 computer each time. I'm getting sick of it. We need to give those DOS users a push. Besides, I hate MicroSoft stuff. :> > > If you still want to make the whole game .au, perhaps we could do > > something I've seen done before with .wav files. The result would > > actully be better since *most people* don't have wavetable for midi. :> > > I don't know how flexable .au is compared to .wav, but what was done was > > a small .wav was recorded for each instrument, a instruction file (In > > this case, midi was used, but any form of instruction for music would > > work) was used to determine what kind of instrument was played at what > > note, pitch, volume, whatever. It would then take each .wav file, and > > play it with the distort instructions (I don't know about .au, but .wav > > can be changed on the fly to make the sound sound different in many > > ways), sounding like a wavetable card was playing midi files in the end. :> > > But like I said, it depends how much can be done with .au, and the sound > > port should be kept open for the entire song, it would sound poorly if > > the port was opened, then closed for each .au file. > > We do have not stick to the some format. If we separate the > call to play sequence, and method how it's played, something > like: > > Server -> Client: play("batmantheme") > resolving: > if wav_supported && wav_data_exist("batmantheme") > wav_play("batmantheme") > elseif au_supported && au_data_exist("batmantheme") > au_play("batmantheme") > else > /* no sound */ Ya, I had the same thought. But my question is do you think its worth adding? How big would say 128 (standard # of MIDI) Instrument files be? In my opinion, space, speed, whatever shouldn't matter. If alot of us want to give up the space, and the need for speed, then great, lets do it. People can always turn off the music part and not download the wavetable music collection. :> -Matt (Who is very anxious to see something like this done for background sound. :>) From crossfire-request Tue Dec 19 16:04:19 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 19 Dec 1995 16:04:14 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id JAA20749; Tue, 19 Dec 1995 09:59:22 -0500 Date: Tue, 19 Dec 1995 09:59:22 -0500 (EST) From: Matt Cortes To: Mark Wedel cc: crossfire@ifi.uio.no Subject: Re: Readable hack: In-Reply-To: <9512170747.AA26141@stealth.eng.pyramid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Sun, 17 Dec 1995, Mark Wedel wrote: > I seem to remember that ultima IV or ultima V did something like this - it > used its own character set for signs and stuff. Same coudl be done in > crossfire, just that if you know the language (Determined by skill level), > you get it in normal characters. Yes, this is an important point I think. We need to start really singling out each character in crossfire. They blend in too much in my opinion. Maybe some favortism from same-class shop owners, strength the advantages and disadvantages of using each class. ANd, like you said, allow for different languages, and skills for learning each one. Maybe in crossfire you can start off with two langauges, your native one, and the offical language of the land. If you travel to a village with nothing but elves, you might have to learn their language in order to get anywhere, or in my case.. Get some room and board since I always choose an Elf. :> > >I don't know if anyone has ever played it. But there was an old game on > >the Sega Genesis called Fatal Labrynth. It was a random RPG game, each > >time you go through it, it was different here and there.. its actually > >alot like crossfire in a few ways. Anyway, it had a feature I thought > >was pretty neat. Each time you killed a specific creature, say blue > >slime.. You would gain in knowledge on how that creature reacts, etc. > >I'm thinking maybe we could add the ability to have knowledge on each > >creature's moves, attacks, etc. The more knowledge you have on the > >creature, the better modifiers you get on Dex, Str, Int, etc for each > >move you do against that creature. These books you purpose could also > >increase the players knowledge the first time the book is read for each > >of the creatures in there, then the book could be refered to later on for > >things such as best protection spells/items to use, best spells, weaknesses, > >max HP, etc for each creature listed in that book. > > > > I know the moria did the same thing. I am not sure how it implemented it, > but I guess that it pretty much stored how many of each type of monster you > killed, and depending on that number, would tell you varying amounts of data > about it. I think thats the only way it can be done. > You actually didn't get to attack it any better, but you just knew what it > did. Well, what about if we did give alittle more for the well practiced dragon slayer for example. I think we should allow hit modifiers if ya fight one monster so much you can do it blind folded. :> > The problem I see with getting bonuses (to hit, etc) in crossfire is that > each time you attacked something, it would need to check and see if you have > extra informatin about this monster, and that you should then get some > benefit. HMm. Well maybe it would be nice if we did one-time information updates. Why look each time? Why not the server tell the players client whats what each time the game is entered and have the client remind the server when it comes time what should be done in each situation? Or is that of no benefit at all? > The other problem is where to store this information. Number of monsters > is hardly static (the way such a method should probably be done is invisible > objects in the players inventory that contain monster and how many killed.) There is an idea. But I think in general, we should start expanding to new fields to store stuff for each character. Can't go on stuffing his items list forever. It'd do for now though. :> > >Good points. And instead of having to write new books per server, why > >not make the books call upon the different variables set for each server? > >Example: > > The Dread's weaknesses are , his max hitpts is > >. > > > > Nice idea. I do see 2 problems: IT could get pretty time consuming. If > such a system was done, a standard naming convention would need to be done > (something like arch name:variable name). But this would add a bit of code. Would it load the system down to much ya think or is it just alot of programming for a small part of crossfire? > I don't really like adding that idea just for books - something like that > should probably also be added to message parsing them (ie, you talk to > someone, and he would respond in a similar fashion.) Yes, that is a good idea. And, weird as it may sound. It made me think of another idea I had in the back of my mind for sometime.. Alot of people on this list have been bring up the risk-factors in the game, if a player should be allowed to collect xp for non-risky things etc. I was thinking about when you do end up talking to someone, sometimes you might make them mad, weather you push them a few times or whatever. Why not allow for a whole background for each player to develop? Maybe a thief-class character becomes an outlaw in Scorn city. He killed to many people in there and stole their stuff . So whenever he enters the city, a bunch of Royal guards start comming after him. Anyway, just another idea. Course there is already SO MUCH else to work on. :> > Also, the other problem would be one of the following 2: 1) either those > values are filled in when the book is created, which means it could be out > of date if archetypes are changed, or 2) The content of the book actually > changes (read it once, and it says that dreads have 1500 hp. Save the game, > come back at some later time, and your book now says dreads have 2000 hp. > That would be a bit strange The second would be very strange. And I like the idea of having outdated books. I mean as programmers, we deal with that alot, no? We should then make sure the books have copyright dates on them. :> Thanks, Matt From crossfire-request Tue Dec 19 14:02:27 1995 Return-Path: Received: from hilja.it.lut.fi (hevi@hilja.it.lut.fi [157.24.11.72]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 19 Dec 1995 14:02:27 +0100 Received: from localhost (hevi@localhost) by hilja.it.lut.fi (8.6.5/8.6.5/1.12.kim) id PAA04371; Tue, 19 Dec 1995 15:02:19 +0200 Date: Tue, 19 Dec 1995 15:02:17 +0200 (EET) From: Petri Heinila X-Sender: hevi@hilja.it.lut.fi To: Richard Murray cc: Mailing-List Crossfire Subject: Re: Call me crazy but... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 18 Dec 1995, Richard Murray wrote: > (ignoring echoing 'you're crazy' cries) > > Playing around with making a unique and playable world on my machine > here, and was playing with the idea of having secret areas that are > totally inaccessible to anyone not holding a specially created unique > item... ie a wizard's room to store things, etc ... nothing fancy really. > > But this lead to a question: item types, etc... don't have cross loaded > up so I can't remember the specifics - anyways, is there ANY kind of > documentation of these seemingly mystical numbers for attributes? Or is > it all kinda a master/apprentice thing where I would have to study for > years to discover how? > > Another thing I was trying was to make it look like a tree, sound like a > tree, taste like a tree, but when applied it would work like a teleport. > Yes, I know an invis exit would work, but with just one object is what > I've been playing with. > > Ideas? Suggestions? checkout whatm is type of exit, then get a tree to the map, change the type of tree to the exit and there it is. as I know there is no documentation of types itself (but source code as always). Best use I have found is to check the type some existing object that behaves somewhat that I need, and the apply same type. Petri.Heinila@lut.fi From crossfire-request Tue Dec 19 06:37:19 1995 Return-Path: Received: from brain.supernet.ab.ca (root@[204.209.3.28]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 19 Dec 1995 06:37:15 +0100 Received: (from root@localhost) by brain.supernet.ab.ca (8.6.12/8.6.9) id XAA08046; Mon, 18 Dec 1995 23:36:33 -0700 Date: Mon, 18 Dec 1995 23:36:31 -0700 (MST) From: Richard Murray To: Mailing-List Crossfire Subject: Call me crazy but... Message-ID: X-HTTP: http://www.supernet.ab.ca/cgi-bin/freestuff MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO (ignoring echoing 'you're crazy' cries) Playing around with making a unique and playable world on my machine here, and was playing with the idea of having secret areas that are totally inaccessible to anyone not holding a specially created unique item... ie a wizard's room to store things, etc ... nothing fancy really. But this lead to a question: item types, etc... don't have cross loaded up so I can't remember the specifics - anyways, is there ANY kind of documentation of these seemingly mystical numbers for attributes? Or is it all kinda a master/apprentice thing where I would have to study for years to discover how? Another thing I was trying was to make it look like a tree, sound like a tree, taste like a tree, but when applied it would work like a teleport. Yes, I know an invis exit would work, but with just one object is what I've been playing with. Ideas? Suggestions? ----- Richard Murray alt.consumers.free-stuff - the next generation http://www.supernet.ab.ca/cgi-bin/freestuff So much to do, so litt(hang on a sec...) From crossfire-request Tue Dec 19 01:14:40 1995 Return-Path: Received: from bertha.pyramid.com (bertha.pyramid.com [129.214.1.100]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id ; Tue, 19 Dec 1995 01:14:37 +0100 Received: from stealth.eng.pyramid.com by bertha.pyramid.com (5.67/OSx5.1a Pyramid-Internet-Gateway) id AA08004; Tue, 19 Dec 95 00:14:05 GMT Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA02386; Tue, 19 Dec 95 00:14:03 GMT From: "Mark Wedel" Message-Id: <9512181614.ZM2384@stealth.eng.pyramid.com> Date: Mon, 18 Dec 1995 16:14:03 -0800 In-Reply-To: Matt Cortes "Re: Spoiler generation (was Re: reading books)" (Dec 18, 10:50am) References: X-Mailer: Z-Mail (3.2.0 06sep94) To: Matt Cortes , Mark Wedel Subject: Re: Spoiler generation (was Re: reading books) Cc: larso@ifi.uio.no, thomas@chaupher.gsfc.nasa.gov, crossfire@ifi.uio.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: RO On Dec 18, 10:50am, Matt Cortes wrote: > Speaking of which... The Crossfire web pages need some serious > updating. Alittle more meat in them and lets change the dates on it, > seeing "1992" as being the newest date I've seen on those web pages, I > actually thought no one was supporting crossfire anymore, and until I > found this list, I actually (blush), tried to ralley some people together > to once again support what in my opinion, should never die. COurse, now > I see it hasn't. But we should have a better presence on the web, alot > more information, docs, etc in HTML. > > -Matt >-- End of excerpt from Matt Cortes However, web pages are something that each site keeps up to date. As of now, there is no standard set of html documents that people can just set up a site with - each site that has been set up has been a custom job (or the information grabbed from other sites.) That said, it is up to each person who has such a site to keep it up to date. Unfortunately, even the docs that come with crossfire are out of date, so how up to date can you expect web pages (I was just looking through some of the docs, and the PlayerStats file doesn't have Pow mentioned for any of the classes). I am working on my own set of web pages that I will eventually put on a public site someplace. These are mostly just html versions of existing docs. -- --Mark From crossfire-request Mon Dec 18 19:26:29 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 18 Dec 1995 19:26:27 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id NAA07554 for crossfire@ifi.uio.no; Mon, 18 Dec 1995 13:26:19 -0500 Date: Mon, 18 Dec 1995 13:26:19 -0500 From: Brian Thomas Message-Id: <199512181826.NAA07554@chaupher.gsfc.nasa.gov> To: crossfire@ifi.uio.no Subject: disarm spell Status: RO I took out some time to look at this; I don't think it will be much of a problem to fix. First off, the spell calls disarm_trap() (though dispel_rune()) and *if ALLOW_SKILLS is not defined* then experience will be awarded for disarming the rune/trap via a the disarm spell. The spell function itself has spell_util.c: success = dispel_rune(op,dir,0); /* 0 means no risk of detonating rune */ a risk factor associated with it. Just change the risk factor to a positive number (1?) and there will be a possibility of the trap detonating even when you use the spell. OR, you can go the other route, which is to remove the chance to gain exp when the spell is used (and ALLOW_SKILLS *isnt* defined..) I include a patch for that case below... b.t. *** rune.c.orig Mon Dec 18 13:25:00 1995 --- rune.c Mon Dec 18 13:25:49 1995 *************** *** 308,318 **** free_object(trap); #ifdef ALLOW_SKILLS return trapworth; #else if(!trap->owner) add_exp(disarmer,trapworth); ! else if(trap->owner && trap->owner->type!=PLAYER) add_exp(disarmer,trapworth); return 1; #endif } else --- 308,318 ---- free_object(trap); #ifdef ALLOW_SKILLS return trapworth; #else if(!trap->owner) add_exp(disarmer,trapworth); ! else if(trap->owner && trap->owner->type!=PLAYER && risk) add_exp(disarmer,trapworth); return 1; #endif } else From crossfire-request Mon Dec 18 17:12:54 1995 Return-Path: Received: from hilja.it.lut.fi (hevi@hilja.it.lut.fi [157.24.11.72]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 18 Dec 1995 17:12:52 +0100 Received: from localhost (hevi@localhost) by hilja.it.lut.fi (8.6.5/8.6.5/1.12.kim) id SAA02770; Mon, 18 Dec 1995 18:12:50 +0200 Date: Mon, 18 Dec 1995 18:12:48 +0200 (EET) From: Petri Heinila X-Sender: hevi@hilja.it.lut.fi To: crossfire@ifi.uio.no Subject: Re: Sounds (various ideas - long) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 18 Dec 1995, Matt Cortes wrote: > > Sorry for replying to this old message. I'm just now getting to my huge > mail box. :> > > On Wed, 13 Dec 1995 Raphael.Quinet@eed.ericsson.se wrote: > > > I think it's better to put all replies to the messages about sounds in a > > single thread, so here we go... > > > > Yes, I have played Hexen. Its a pretty cool game and I love the idea of > > > atmosphere type sounds. What would be nice though is to also have some > > > music perhaps? .MIDs are great but I have never seen a midi player for > > > unix, so I don't know. [...] > > > > The easiest way to have background music would be to play a (long) .au > > file at a low level and mix it with other sound effects, because MIDI is > > not available on all systems. But the music files would of course take > > a few Mb... > > Huge .au files is not good at all. In my opinion, the reason must > systems don't have MIDI support is because people aren't supporting it. > If people would forge ahead and make whatever needs to be made, without > worrying about how many systems support it, it would speed up the > encouragement to get everyone to upgrade. What happens when all the new > stuff comming out works fine on your old computer? No need to upgrade, > technology stands still. Kinda drastic, but I feel strong about that > matter. :> That is a kind of reality, I know people using still DOS :) > If you still want to make the whole game .au, perhaps we could do > something I've seen done before with .wav files. The result would > actully be better since *most people* don't have wavetable for midi. :> > I don't know how flexable .au is compared to .wav, but what was done was > a small .wav was recorded for each instrument, a instruction file (In > this case, midi was used, but any form of instruction for music would > work) was used to determine what kind of instrument was played at what > note, pitch, volume, whatever. It would then take each .wav file, and > play it with the distort instructions (I don't know about .au, but .wav > can be changed on the fly to make the sound sound different in many > ways), sounding like a wavetable card was playing midi files in the end. :> > But like I said, it depends how much can be done with .au, and the sound > port should be kept open for the entire song, it would sound poorly if > the port was opened, then closed for each .au file. We do have not stick to the some format. If we separate the call to play sequence, and method how it's played, something like: Server -> Client: play("batmantheme") resolving: if wav_supported && wav_data_exist("batmantheme") wav_play("batmantheme") elseif au_supported && au_data_exist("batmantheme") au_play("batmantheme") else /* no sound */ Petri.Heinila@lut.fi From crossfire-request Mon Dec 18 16:51:30 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id ; Mon, 18 Dec 1995 16:51:28 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id KAA16630; Mon, 18 Dec 1995 10:50:27 -0500 Date: Mon, 18 Dec 1995 10:50:27 -0500 (EST) From: Matt Cortes To: Mark Wedel cc: larso@ifi.uio.no, thomas@chaupher.gsfc.nasa.gov, crossfire@ifi.uio.no Subject: Re: Spoiler generation (was Re: reading books) In-Reply-To: <9512170751.AA26146@stealth.eng.pyramid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Sun, 17 Dec 1995, Mark Wedel wrote: > > > One problem with the spoiler is that is requires several tools that are not > on most unix systems (Net Pbm and latex, and dvips) > > I guess Net Pbm proibably isn't totally uncommon, since a lot of web stuff > might use it. > > (also, I seem to recall that the latex stuff also needs a special layout > file that is normally not part of it) > > I wonder how hard it would be to convert output of the spoiler to html > format -- net browsers are pretty common out there, and most all of them > do have a html to postscript conversion in them..) Speaking of which... The Crossfire web pages need some serious updating. Alittle more meat in them and lets change the dates on it, seeing "1992" as being the newest date I've seen on those web pages, I actually thought no one was supporting crossfire anymore, and until I found this list, I actually (blush), tried to ralley some people together to once again support what in my opinion, should never die. COurse, now I see it hasn't. But we should have a better presence on the web, alot more information, docs, etc in HTML. -Matt From crossfire-request Mon Dec 18 16:35:57 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 18 Dec 1995 16:35:55 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id KAA16596; Mon, 18 Dec 1995 10:34:50 -0500 Date: Mon, 18 Dec 1995 10:34:50 -0500 (EST) From: Matt Cortes To: Mark Wedel cc: GESTIONNAIRE DU Casino , Brian Thomas , crossfire@ifi.uio.no Subject: Re: reading books, another idea I am working on In-Reply-To: <9512152337.ZM24609@stealth.eng.pyramid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 15 Dec 1995, Mark Wedel wrote: > On Dec 15, 6:43pm, GESTIONNAIRE DU Casino wrote: > > > What about those times one uses an archetype on a map, but override all > > the stats/hits/etc ? The information wouldn't be valid, but the player > > has no way of knowing that... > > > > It's a good idea, though... > > > > --- > > Casino > > > > This is a problem right now. You may (jsut from experience) know that certain > spells work good against monsters or whatever else. However, on some maps, > those monsters may have been changed so this is no longer the case. Well, I don't think that matters too much. Experienced players will always have some edge in Crossfire. Its the newbie players that would need to get ahold of these things. COurse then we should also think about taking that spoiler out of circulation. :> > Whether you got your information from a book or just from playing a bit, the > result is the same. > > The ideal solution is that when stats are changed, the monster name is also > changed, so that you know it is not the same thing. Here's an idea. Keep alot of the same monsters, with the same stats, etc. But also make random monsters. They would get a weird random name (I've seen a game actually doing what I'm describing here, so I haven't gone nuts ), random weakness/strength/spells/whatever, random face file. That should be a quickie solve for people that don't like swallowing the same stuff alot. -Matt From crossfire-request Mon Dec 18 16:23:51 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 18 Dec 1995 16:23:49 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id KAA16556; Mon, 18 Dec 1995 10:22:32 -0500 Date: Mon, 18 Dec 1995 10:22:32 -0500 (EST) From: Matt Cortes To: Raphael.Quinet@eed.ericsson.se cc: crossfire@ifi.uio.no Subject: Re: Sounds (various ideas - long) In-Reply-To: <199512131757.SAA22086@chapelle.eed.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Sorry for replying to this old message. I'm just now getting to my huge mail box. :> On Wed, 13 Dec 1995 Raphael.Quinet@eed.ericsson.se wrote: > I think it's better to put all replies to the messages about sounds in a > single thread, so here we go... > > Yes, I have played Hexen. Its a pretty cool game and I love the idea of > > atmosphere type sounds. What would be nice though is to also have some > > music perhaps? .MIDs are great but I have never seen a midi player for > > unix, so I don't know. [...] > > The easiest way to have background music would be to play a (long) .au > file at a low level and mix it with other sound effects, because MIDI is > not available on all systems. But the music files would of course take > a few Mb... Huge .au files is not good at all. In my opinion, the reason must systems don't have MIDI support is because people aren't supporting it. If people would forge ahead and make whatever needs to be made, without worrying about how many systems support it, it would speed up the encouragement to get everyone to upgrade. What happens when all the new stuff comming out works fine on your old computer? No need to upgrade, technology stands still. Kinda drastic, but I feel strong about that matter. :> If you still want to make the whole game .au, perhaps we could do something I've seen done before with .wav files. The result would actully be better since *most people* don't have wavetable for midi. :> I don't know how flexable .au is compared to .wav, but what was done was a small .wav was recorded for each instrument, a instruction file (In this case, midi was used, but any form of instruction for music would work) was used to determine what kind of instrument was played at what note, pitch, volume, whatever. It would then take each .wav file, and play it with the distort instructions (I don't know about .au, but .wav can be changed on the fly to make the sound sound different in many ways), sounding like a wavetable card was playing midi files in the end. :> But like I said, it depends how much can be done with .au, and the sound port should be kept open for the entire song, it would sound poorly if the port was opened, then closed for each .au file. -Matt From crossfire-request Mon Dec 18 09:41:04 1995 Return-Path: Received: from kaukau.comp.vuw.ac.nz (kaukau.comp.vuw.ac.nz [130.195.5.20]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 18 Dec 1995 09:41:02 +0100 Received: from debretts.comp.vuw.ac.nz (debretts.comp.vuw.ac.nz [130.195.8.46]) by kaukau.comp.vuw.ac.nz (8.6.B/8.6.9-VUW) with ESMTP id VAA29129 for ; Mon, 18 Dec 1995 21:40:37 +1300 From: Stephen Wray Received: (stevew@localhost) by debretts.comp.vuw.ac.nz (8.6.10/8.6.6) id VAA01213; Mon, 18 Dec 1995 21:40:53 +1300 Date: Mon, 18 Dec 1995 21:40:53 +1300 Message-Id: <199512180840.VAA01213@debretts.comp.vuw.ac.nz> To: crossfire@ifi.uio.no Subject: move_type etc??? Reply-to: Steve.Wray@vuw.ac.nz Status: RO -----BEGIN PGP SIGNED MESSAGE----- I tried getting bt's child thief archetype to perform the hit-and-run attack. I tried the following; attack_type 3 move_type 3 (which crossedit does not allow you to set) attack_movement 3 attacktype 3 I also tried setting these to 99 which from what I can make out from the crossfire.doc notes means random+hitrun. None of these made the slightest bit of difference to the behavior of the monster. Setting move_type caused the folowing error message to appear (with crossfire -d); Change object (young rogue) without other_arch error. This error begins being displayed when I enter the map with the child thief, and continues being displayed forever -- even when the map is long gone. The notes in crossfire.doc have proven useless to me on this, as have the comments in the code. Can anyone tell me how to enable these neat behavior modes. - -- - --- **********************T***H***E***L***E***M***A********************** 44. For pure will, unassuaged of purpose, delivered from the lust of result, is every way perfect. -- LIBER AL vel LEGIS ******************************IN*LVX********************************* Stephen Wray -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQCVAgUBMNUpDit7qh9JVcfZAQFtTgQApdSBQDPKU90gVUnrhMd9zGmmhwgWPxFV NoypOwzMa2xFwl66dbQhT1FOoGYTJd4mUT5jclpPUvrn9blKG8JOjoIBc2aBf8vo ZILR9o9FAXnmoofe1J+S2Lo/LWULt83atU0AIyjGQMsHRVzPLvtb0c9aw0tcmDjR m49XcctkGQE= =B7iZ -----END PGP SIGNATURE----- From crossfire-request Mon Dec 18 07:03:33 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.125.104]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 18 Dec 1995 07:03:32 +0100 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9504/950407.s1) id BAA07157; Mon, 18 Dec 1995 01:02:04 -0500 Date: Mon, 18 Dec 1995 01:02:04 -0500 From: Brian Thomas Message-Id: <199512180602.BAA07157@chaupher.gsfc.nasa.gov> To: peterm@langmuir.EECS.Berkeley.EDU, celear@teaching.cs.adelaide.edu.au Subject: Re: Runes and Disarm Cc: crossfire@ifi.uio.no Status: RO > From: Colin writes: > > >>> Peter writes: > etc>But a rune of death will happily kill anyone (even the owner) > etc>who steps on it, so far as I can remember. > etc> Hmm. Well yes, but I would like to interject a proviso to that. Its important to note that deathstrike(), the fctn handling the attack for the death rune, uses the *overall* level of the defender to determine success. So, under the skills system, the owner of the rune *casts* it at their magician level, which will *always* be equal to or less than their players *overall* level. Therefore, I wouldnt think it very likely that a player could kill themselves by casting rune of death (at least until things are changed...) > > If you actually use the skill the disarm spell isn't a skill > it's a cheap way to get crap loads of experience without any risk > whatsoever, basically it sucks. > Hmm, I havent tried this myself, but how much is "crap loads"? Please be more specific. I wasnt aware that this spell gave out xp. I think its appropriate, but this should be incorporated into the central exp scheme (at least when the skills are enabled, calc_skill_exp() should be called). > > However to the programmer of the spell of disarm it is a crock > [snip] Well, I am not the programmer of this spell, but I would like to request that you please be a bit less offensive and as well less ignorant. Understand that crossfire is *not* a polished product. Therefore it is not unusual that loopholes like this can still pop up from time to time. Perhaps the programmer of the spell is not the one at fault, recently, for example, I re-wrote a large chunk of the experience system, it just might be that *I* screwed it up. Until you understand the code, its hard to say what might be wrong, so please be a little kinder with your comments. Regards, b.t. > > > > From crossfire-request Mon Dec 18 06:00:13 1995 Return-Path: Received: from langmuir.EECS.Berkeley.EDU (langmuir.EECS.Berkeley.EDU [128.32.240.55]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 18 Dec 1995 06:00:12 +0100 Received: from landau.EECS.Berkeley.EDU (landau.EECS.Berkeley.EDU [128.32.240.94]) by langmuir.EECS.Berkeley.EDU (8.6.11/8.5) with SMTP id VAA17554; Sun, 17 Dec 1995 21:02:14 -0800 From: Peter Mardahl Received: from localhost by landau.EECS.Berkeley.EDU; (5.65/1.1.8.2/20Jun95-1153PM) id AA13174; Sun, 17 Dec 1995 21:02:20 -0800 Message-Id: <9512180502.AA13174@landau.EECS.Berkeley.EDU> To: Colin Cc: crossfire@ifi.uio.no (cf) Subject: Re: Runes and Disarm In-Reply-To: Your message of "Mon, 18 Dec 95 15:06:32 +1030." <199512180436.PAA25495@zebedee.teaching.cs.adelaide.edu.au> Date: Sun, 17 Dec 95 21:02:20 -0800 X-Mts: smtp Status: RO > > I know someone who tried the idea of giving a spellbook > of rune of death to an angel. > > It made it heaps easy to get to some outrageous level > and according to them it was perfectly safe since > detonating the runes didn't even do anything, steping > on them didn't seem to cause any harm to the player. If you're patient enough, you can get an infinite amount of experience with no risk in many ways. It sounds like this guy must have spent many hours doing this. At any rate, the amount of experience should depend on the relative level of the rune and the player. Runes inherit the level of the caster, and a Rune of Death won't hurt someone with a higher level than the rune. But a rune of death will happily kill anyone (even the owner) who steps on it, so far as I can remember. > This is one of the reasons I think the disarm spell > shouldn't give any experience for actually disarming > the rune. It should only give a little for actually casting > it. I disagree. The amount of experience granted should depend on the relative level of the rune and the player. For exercising a skill, you should get experience. You should get a trivial amount of experience from disarming a trivial trap, however. Regards, PeterM From crossfire-request Mon Dec 18 05:37:03 1995 Return-Path: Received: from zebedee.teaching.cs.adelaide.edu.au (celear@zebedee.teaching.cs.adelaide.edu.au [129.127.104.27]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 18 Dec 1995 05:36:49 +0100 Received: from celear@zebedee.teaching.cs.adelaide.edu.au by zebedee.teaching.cs.adelaide.edu.au (8.6.12/AndrewR-MatthewD-950530-CS) id PAA25495 for crossfire@ifi.uio.no; Mon, 18 Dec 1995 15:06:32 +1030 X-Authentic-Sender: celear@zebedee.teaching.cs.adelaide.edu.au From: Colin Message-Id: <199512180436.PAA25495@zebedee.teaching.cs.adelaide.edu.au> Subject: Runes and Disarm To: crossfire@ifi.uio.no (cf) Date: Mon, 18 Dec 1995 15:06:32 +1030 (CST) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2548 Status: RO I know someone who tried the idea of giving a spellbook of rune of death to an angel. It made it heaps easy to get to some outrageous level and according to them it was perfectly safe since detonating the runes didn't even do anything, steping on them didn't seem to cause any harm to the player. Is this the case, I haven't tested it, but they are using an older version anyway. Are the death runes unable to kill friendly objects if they have the right flag set. Is this to stop reckless players killing each other or is it just a bug. This is one of the reasons I think the disarm spell shouldn't give any experience for actually disarming the rune. It should only give a little for actually casting it. -- ***************************************************************************** oooo$$$$$$$$$$$$oooo oo$$$$$$$$$$$$$$$$$$$$$$$$o oo$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$o o$ $$ o$ o $ oo o$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$o $$ $$ $$o$ oo $ $ "$ o$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$o $$$o$$o$ "$$$$$$o$ o$$$$$$$$$ $$$$$$$$$$$ $$$$$$$$$$o $$$$$$$$ $$$$$$$ $$$$$$$$$$$ $$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$$$$ """$$$ "$$$""""$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ "$$$ $$$ o$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ "$$$o o$$" $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$o $$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$" "$$$$$$ooooo$$$$o o$$$oooo$$$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ o$$$$$$$$$$$$$$$$$ $$$$$$$$"$$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$"""""""" """" $$$$ "$$$$$$$$$$$$$$$$$$$$$$$$$$$$" o$$$ "$$$o """$$$$$$$$$$$$$$$$$$"$$" $$$ $$$o "$$""$$$$$$"""" o$$$ $$$$o oo o$$$" "$$$$o o$$$$$$o"$$$$o o$$$$ "$$$$$oo ""$$$$o$$$$$o o$$$$"" ""$$$$$oooo "$$$o$$$$$$$$$""" ""$$$$$$$oo $$$$$$$$$$ """"$$$$$$$$$$$ $$$$$$$$$$$$ $$$$$$$$$$" "$$$"""" To you, from me, with Affection. **************************************************************************** From crossfire-request Mon Jan 1 04:24:01 1996 Return-Path: Received: from hunter.cs.unr.edu (hunter.cs.unr.edu [134.197.40.62]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 1 Jan 1996 04:24:00 +0100 Received: (from bull@localhost) by hunter.cs.unr.edu (8.6.9/8.6.9) id TAA21898 for crossfire@ifi.uio.no; Sun, 31 Dec 1995 19:23:58 -0800 From: "W.E.B" Message-Id: <199601010323.TAA21898@hunter.cs.unr.edu> Subject: Java/C++ Port To: crossfire@ifi.uio.no Date: Sun, 31 Dec 95 19:23:57 PDT X-Mailer: ELM [version 2.2 PL16] Status: RO Hello All. After a few weeks of work we've decided that the work it would take to produce Crossfire in a language like Java would be close to the amount of energy to generating a newer, more expandable multi-user graphical gaming system. A Crossfire style game would be easy to generate and should be considered a plausible subset of our system. I wish you all the best of luck with Crossfire and hope we can accomplish something at least as entertaining. Oh yes, Happy New Year! :) w.e.b. ---------- william ephraim bull ---------- bull@ cs.unr.edu From crossfire-request Wed Dec 27 22:03:55 1995 Return-Path: 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, 27 Dec 1995 22:03:53 +0100 Received: from stealth.eng.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA06474; Wed, 27 Dec 95 13:03:16 -0800 Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA09252; Wed, 27 Dec 95 21:03:08 GMT From: "Mark Wedel" Message-Id: <9512271303.ZM9250@stealth.eng.pyramid.com> Date: Wed, 27 Dec 1995 13:03:07 -0800 In-Reply-To: "Michael B. Martin" "Re: Spoiler generation (was Re: reading books)" (Dec 26, 11:17pm) References: <199512270417.XAA03349@mbmartin.bevc.blacksburg.va.us> X-Mailer: Z-Mail (3.2.0 06sep94) To: crossfire@ifi.uio.no Subject: Re: Spoiler generation (was Re: reading books) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: RO On Dec 26, 11:17pm, Michael B. Martin wrote: > If you would like a suggestion, perhaps all (new) documentation should > be written in HTML. Converting to a plain text file would be fairly > simple (I believe many browsers, Netscape in particular, can do this). > Or, better yet, take a look at the Linux Documentation Project (LDP). > If I understand this right, they are writing the docs in SGML, which > can then be translated into HTML, plain text, UN*X man page > (troff/nroff) format, etc. Nicely flexible. > I often times find that the files just being in straight text format to be quite handy (I just want to quickly look something up, and being able to more the file is much nicer than bringing up a copy of netscape or whatever else.) Also, even in text format, the documentation is out of date. If any other format is used (which will likely be harder, and thus not as many people will know how to use it), the documentation will get even more out of date/won't be updated. If people supply documentation in some nice, standard, new format, I will probably take it. But I will hardly require that people use some new format. -- --Mark From crossfire-request Wed Dec 27 10:40:34 1995 Return-Path: Received: from hilja.it.lut.fi (hevi@hilja.it.lut.fi [157.24.11.72]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 27 Dec 1995 10:40:32 +0100 Received: from localhost (hevi@localhost) by hilja.it.lut.fi (8.6.5/8.6.5/1.12.kim) id LAA11807; Wed, 27 Dec 1995 11:40:24 +0200 Date: Wed, 27 Dec 1995 11:40:23 +0200 (EET) From: Petri Heinila X-Sender: hevi@hilja.it.lut.fi To: crossfire@ifi.uio.no Subject: Re: Spoiler generation (was Re: reading books) In-Reply-To: <199512270417.XAA03349@mbmartin.bevc.blacksburg.va.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Tue, 26 Dec 1995, Michael B. Martin wrote: > If you would like a suggestion, perhaps all (new) documentation should > be written in HTML. Converting to a plain text file would be fairly I a bit disagree with HTML, because converting from HTML to paged format is a hard (there exists no converters (GF (SGML -> HTML-DTD + text -> LaTex etc) indeed exists but is a bit hard to use). > simple (I believe many browsers, Netscape in particular, can do this). > Or, better yet, take a look at the Linux Documentation Project (LDP). > If I understand this right, they are writing the docs in SGML, which > can then be translated into HTML, plain text, UN*X man page > (troff/nroff) format, etc. Nicely flexible. LDP might be, I don't know, should examine can it handle images etc. I think using LaTeX with latex2html is fair sufficient, but also it would be on the one other hand good if the format could converted to other presentation forms as well (troff, rtf, ..). > For those of you pushing for "alternate" languages/character sets in > crossfire, someone could probably even write a converter for that, too > (e.g. HTML -> Elven :-). The reason the runic alphabet used in the > Ultima series of games was so cool is that your character's > proficiency was exactly *your* proficiency. Much more realistic than > having some sort of automatic translation if your character happens to > know the language. Maybe total language conversion would made understanding difficult, but eg. runic characters in spell/prayer names are defininetly fine. Petri.Heinila@lut.fi From crossfire-request Wed Dec 27 04:29:50 1995 Return-Path: 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 ; Wed, 27 Dec 1995 04:29:49 +0100 Received: (from martinm@localhost) by mbmartin.bevc.blacksburg.va.us (8.6.12/8.6.9) id XAA03362 for crossfire@ifi.uio.no; Tue, 26 Dec 1995 23:31:42 -0500 From: "Michael B. Martin" Message-Id: <199512270431.XAA03362@mbmartin.bevc.blacksburg.va.us> Subject: Re: Sounds (various ideas - long) To: crossfire@ifi.uio.no Date: Tue, 26 Dec 1995 23:31:42 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2870 Status: RO > > > If you still want to make the whole game .au, perhaps we could do > > > something I've seen done before with .wav files. The result would > > > actully be better since *most people* don't have wavetable for midi. :> > > > I don't know how flexable .au is compared to .wav, but what was done was > > > a small .wav was recorded for each instrument, a instruction file (In > > > this case, midi was used, but any form of instruction for music would > > > work) was used to determine what kind of instrument was played at what > > > note, pitch, volume, whatever. It would then take each .wav file, and > > > play it with the distort instructions (I don't know about .au, but .wav > > > can be changed on the fly to make the sound sound different in many > > > ways), sounding like a wavetable card was playing midi files in the end. :> > > > But like I said, it depends how much can be done with .au, and the sound > > > port should be kept open for the entire song, it would sound poorly if > > > the port was opened, then closed for each .au file. What this is describing has existed for many years (originally on the Amiga, I believe). There are music formats (the Pro-Tracker ".mod" format being the oldest and best known) which are designed to operate in exactly the manner listed above. A digitized sample is stored for each instrument and then played back at the appropriate sampling rate to set the pitch, with (typically) several other tricks, like volume/pitch slides, looping, etc. This music format has the advantage of being relatively compact while still giving good music quality (and as long as the player hardware is sufficient, the sounds are faithfully reproduced, unlike with, for example, MIDI files, whose sound depends on what synthesizer you use). Incidentally, this is also known as "wavetable synthesis" on the modern Intel-based PC sound cards. > Ya, I had the same thought. But my question is do you think its worth > adding? How big would say 128 (standard # of MIDI) Instrument files be? > In my opinion, space, speed, whatever shouldn't matter. If alot of us > want to give up the space, and the need for speed, then great, lets do > it. People can always turn off the music part and not download the > wavetable music collection. :> > > > -Matt (Who is very anxious to see something like this done for background > sound. :>) Well, the best (General MIDI) wavetable sound cards I know of use up to 4 MB of sample ROM (2 MB is generally considered inadequate for good instrument quality). But I don't know how many instruments that includes (some cards claim over 300 instruments, I think, but I don't know how much storage those require). I have a GUS, so on my system the instrument samples take up several MB (samples are stored on disk instead and loaded on demand into sound card RAM). -Michael From crossfire-request Wed Dec 27 04:15:43 1995 Return-Path: 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 ; Wed, 27 Dec 1995 04:15:42 +0100 Received: (from martinm@localhost) by mbmartin.bevc.blacksburg.va.us (8.6.12/8.6.9) id XAA03349 for crossfire@ifi.uio.no; Tue, 26 Dec 1995 23:17:34 -0500 From: "Michael B. Martin" Message-Id: <199512270417.XAA03349@mbmartin.bevc.blacksburg.va.us> Subject: Re: Spoiler generation (was Re: reading books) To: crossfire@ifi.uio.no Date: Tue, 26 Dec 1995 23:17:34 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1079 Status: RO > > I am working on my own set of web pages that I will eventually put on a public > site someplace. These are mostly just html versions of existing docs. > > > -- > --Mark > If you would like a suggestion, perhaps all (new) documentation should be written in HTML. Converting to a plain text file would be fairly simple (I believe many browsers, Netscape in particular, can do this). Or, better yet, take a look at the Linux Documentation Project (LDP). If I understand this right, they are writing the docs in SGML, which can then be translated into HTML, plain text, UN*X man page (troff/nroff) format, etc. Nicely flexible. For those of you pushing for "alternate" languages/character sets in crossfire, someone could probably even write a converter for that, too (e.g. HTML -> Elven :-). The reason the runic alphabet used in the Ultima series of games was so cool is that your character's proficiency was exactly *your* proficiency. Much more realistic than having some sort of automatic translation if your character happens to know the language. -Michael From crossfire-request Sun Dec 24 18:23:53 1995 Return-Path: Received: from usc.edu (usc.edu [128.125.253.136]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sun, 24 Dec 1995 18:23:52 +0100 Received: (from Urunner@localhost) by usc.edu (8.7.2/8.7.2/usc) id JAA18598 for ifi.uio.no!crossfire; Sun, 24 Dec 1995 09:23:48 -0800 (PST) X-Authentication-Warning: usc.edu: Urunner set sender to runner!richard using -f >Received: by runner.wds.disney.com (NX5.67e/NX3.0M-rr.4) id AA00413; Sun, 24 Dec 95 09:23:16 -0800 Date: Sun, 24 Dec 95 09:23:16 -0800 From: Richard Ruth Message-Id: <9512241723.AA00413@runner.wds.disney.com> Received: from runner by usc.edu.usc.edu; Sun, 24 Dec 1995 09:23 PST Received: by runner.wds.disney.com (NX5.67e/NX3.0M-rr.4) id AA00413; Sun, 24 Dec 95 09:23:16 -0800 Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Player starting skills Content-Type: text Status: RO Problems with skills... I am using Crossfire v0.92.0. In skills.doc it states: d. starting skills by player profession All players start with the skills "melee weapons", "find traps", "use magic item" and "disarm traps". However, when I type 'skills I receive an empty list. Also after I use the lock pics, and then type 'skills It lists lockpicking as a skill, however it does not list any level. Also would I find a 'skill scroll' I have #define ALLOW_SKILLS in include/config.h. Any help would be appreciated. --- Richard richard%runner.uucp@usc.edu (100K bytes max -- ok to send NeXTMail) From crossfire-request Fri Dec 22 21:26:35 1995 Return-Path: Received: from kaukau.comp.vuw.ac.nz (kaukau.comp.vuw.ac.nz [130.195.5.20]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 22 Dec 1995 21:26:33 +0100 Received: from debretts.comp.vuw.ac.nz (debretts.comp.vuw.ac.nz [130.195.8.46]) by kaukau.comp.vuw.ac.nz (8.6.B/8.6.9-VUW) with ESMTP id JAA18010; Sat, 23 Dec 1995 09:24:44 +1300 From: Stephen Wray Received: (stevew@localhost) by debretts.comp.vuw.ac.nz (8.6.10/8.6.6) id JAA21318; Sat, 23 Dec 1995 09:25:00 +1300 Date: Sat, 23 Dec 1995 09:25:00 +1300 Message-Id: <199512222025.JAA21318@debretts.comp.vuw.ac.nz> To: mwedel@pyramid.com, crossfire@ifi.uio.no In-reply-to: <9512221001.AA26402@stealth.eng.pyramid.com> (mwedel@pyramid.com) Subject: Re: crossfire Reply-to: Steve.Wray@vuw.ac.nz Status: RO >>>>> "Mark" == Mark Wedel writes: Mark> I suppose in pouches, if the object is active, the money should be deposited, Mark> as if it was picked up. Actually, that part looks like it should be pretty Mark> easy to modify. Mark> In terms of money or keys removed, as said, it is a feature. If you have Mark> your money in a pouch, and accidentally pick something up, and leave, do you Mark> really want it to pull out that money? Mark> In terms of keyrings, I asked this before, and it is considered a feature Mark> in that if you accidentally bump into a door, it won't be disolved (ie, key Mark> rings become more of a safety feature). In both these cases, I initially assumed that they worked the same as a quiver. If you have an active quiver, and use your bow, the arrows get used. I'd have thought that making a container active was sufficiently special to assume that it had been done deliberately, and hence that items in the container can be used automatically. --- **********************T***H***E***L***E***M***A********************** 44. For pure will, unassuaged of purpose, delivered from the lust of result, is every way perfect. -- LIBER AL vel LEGIS ******************************IN*LVX********************************* Stephen Wray From crossfire-request Fri Dec 22 11:02:39 1995 Return-Path: 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, 22 Dec 1995 11:02:38 +0100 Received: from stealth.eng.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA10785; Fri, 22 Dec 95 02:01:49 -0800 Received: by stealth.eng.pyramid.com (5.67/Pyramid_Internal_Configuration) id AA26402; Fri, 22 Dec 95 10:01:47 GMT Date: Fri, 22 Dec 95 10:01:47 GMT From: mwedel@pyramid.com (Mark Wedel) Message-Id: <9512221001.AA26402@stealth.eng.pyramid.com> To: paulh@euristix.ie Subject: Re: crossfire Cc: crossfire@ifi.uio.no Status: RO > I've just got crossfire-0.92.1, way cool. I thought that perhaps it's >time I provided my $0.02 since I've been playing for so long. > > pouches: money received in shops doesn't go straight in and shops don't > take money straight out when you're leaving. These would be > handy. > keyrings: Keys in keyrings don't get used automatically; I think that they > should. Both of these can be considered features. I suppose in pouches, if the object is active, the money should be deposited, as if it was picked up. Actually, that part looks like it should be pretty easy to modify. In terms of money or keys removed, as said, it is a feature. If you have your money in a pouch, and accidentally pick something up, and leave, do you really want it to pull out that money? In terms of keyrings, I asked this before, and it is considered a feature in that if you accidentally bump into a door, it won't be disolved (ie, key rings become more of a safety feature). I suppose both of these could be set up via some option, but that would require a bit of extra hacking, and I am not sure how big of a gain it would be. > lightning: There are (as far as I know) only two electricity spells, which > rather under-utilises my handy Ring of Storm. I was going to > send you some diffs for a new lightning storm spell, but then I > saw the code and thought that I should probably leave it in the > hands of the experts :) Basically, the idea is a random cone of > lighning. The regular cone would work, but I have another idea > which is neat (on paper, at least). It involves forking the > electricity randomly, giving potentially very long or very short > bolts, and allowing several (perhaps many) bolts to run over the > same square. I'm including a small curses program (not encoded) > below that uses the algorithm. All the configurable random > bits are currently #defines; if you like the idea then they would > probably be changed to some formula dependant on level, spell > paths, and all the rest of it. Electricity is limited, but is also very powerful. In terms of players, there is nothing out there that lets you become immune to electricity, there are things out there that let you become immune to fire and cold. But a quick look, there are 4 PATH_FROST spells (one is not normally available, but I think some quest has a spellbook for it.) There are also 4 PATH_ELEC spells (one is ball lightning - once again, no spell for it.) There are 10 PATH_FIRE spells (but a few are not player achievable) It should probably also be said that not all items are created equal. Some things are better than other - protection from fire/cold/electricity rings are certainly better than protectin from poison rings. The same can be said about the various ring of the elements (ring of storm, fire, etc.) Is that necessarily bad? PRobably not. It should probably also be said that getting a spell path just increases damage/duration/effective casting level of those spells. So in all spells, they aren't necessarily all that useful (An interesting idea might be to have some spells that you can only cast if you actually have that spell path) All that said and done, additional spells are necessarily bad (but right now, we certainly do have a lot of them). I guess my one thought is that lightning normally doesn't come in cones. I know that in AD&D, however, that the caster of lightning bolt can decide to make the bolt twice as wide but half the length. Something similar for crossfire could be done. (another interesting idea would be to have more varied spell effects as you are a higher level - a few spells do this (like create food). But something like at high levels, maybe the lightning bolt has 2 forks or something.. Don't know in how many cases this could be applied to most spells, however) >Paul Hicks. From crossfire-request Fri Dec 22 02:37:55 1995 Return-Path: Received: from mail04.mail.aol.com (mail04.mail.aol.com [152.163.172.53]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 22 Dec 1995 02:37:54 +0100 From: SideTrackd@aol.com Received: by mail04.mail.aol.com (8.6.12/8.6.12) id UAA15801 for crossfire@ifi.uio.no.; Thu, 21 Dec 1995 20:37:16 -0500 Date: Thu, 21 Dec 1995 20:37:16 -0500 Message-ID: <951221203705_96665004@mail04.mail.aol.com> To: crossfire@ifi.uio.no Subject: subscription request Status: RO I am contacting you about a subscription to the crossfire mailing list.. I am a game designer and producer... My company is working on game development and you offers seems like a very intresting mailing list... I hope to be welcome.. and thankyou.. John Whitson From crossfire-request Wed Dec 20 20:41:42 1995 Return-Path: Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 20 Dec 1995 20:41:24 +0100 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.132.130]) by mailgate.ericsson.se (8.6.11/1.0) with ESMTP id UAA07974 for ; Wed, 20 Dec 1995 20:40:44 +0100 Received: (from eedraq@localhost) by chapelle.eed.ericsson.se (8.7.1/8.7.1) id UAA08020 for crossfire@ifi.uio.no; Wed, 20 Dec 1995 20:40:34 +0100 (MET) Date: Wed, 20 Dec 1995 20:40:34 +0100 (MET) Message-Id: <199512201940.UAA08020@chapelle.eed.ericsson.se> To: crossfire@ifi.uio.no Subject: Sounds proposal (long!) From: Raphael.Quinet@eed.ericsson.se Status: RO Here is my new proposal for the sounds in Crossfire. I tried to take into account the various comments and suggestions that were posted on this list or e-mailed directly to me by Tero Haatanen and others. Note that I won't start implementing this now, but I will keep this proposal (and the other ideas sitting in my brain) for later, when the code will be split between an idependant client and a server and when the old "false client/server" code will not be supported anymore. :-) I'm not sure if it is interesting for you to reply to this message, because this proposal will not be implemented soon. But if you choose to reply to me or to the list, *PLEASE* do not quote the whole message: all members of the list will have seen it already. Select only the relevant parts and save some bandwidth... Disclaimer: I'm not claiming that I know the best way to handle sounds in the game. In fact, I could be totally wrong... :-) ---------- cut here ---------- cut here ---------- cut here ---------- PROPOSAL FOR A NEW SOUND SYSTEM IN CROSSFIRE ============================================ 1) Background information ------------------------- I assume that Crossfire will be split between a client (for the user) and a server (without any graphical output). A typical setup would have the client running on a "local host" and the server running somewhere else on the Internet. Furthermore, this client could display its windows and play the sounds on a remote display, although most of the time the display will be on the machine which runs the Crossfire client. Internet Local network Crossfire <---------------> Crossfire <---------------> X terminal server Crossfire c/s client X protocol protocol Rplay protocol If crossfire is going to have a rich audio environment, I expect that half of the c/s traffic could be used by the sound commands. Because of this, I tried to minimize the amount of information that is sent during the game. I always followed the rule: "if something can be done by the client, then the server should not do it" (unless it would give too much information to the client and allow the user to cheat). I hope that we will see some clients for MS-Windows or Macintosh one day or another. That's why I tried to avoid UNIX-specific features in the definition of the new sound system. Although I will use RPlay in the client because it is IMHO the best audio protocol under UNIX and the easiest to use, it should be possible for someone to replace RPlay by another protocol, such as NAS. Here is a short glossary of the words that I will use in the following paragraphs. This will hopefully prevent confusion and clarify some things: - "event type", "sound event", "sound type" or "sound": a symbolic name associated with an event (player or monster action, random event, ...). These names are used in the server code and in the maps, but are not actually used by the client. - "sound file": the name of the file which contains the sound samples. It will usually be a .au file, but some clients could use .wav or .voc files instead, or even .mod or .midi (if the client supports these formats). - "sound index" or "index number": a number which is associated with an event type. This number is generated by the server when it reads the config file and it is sent to the client during the game (see below). - "priority": a number which helps the client in choosing which sounds should be played when the maximum number of simulateous sounds is exceeded. - "maximum volume": the volume at which a sound file should be played if the source of the sound is at the same position as the player (if the relative position is (0, 0)). - "volume": the volume at which a sound is actually played, including the attenuation caused by the distance. 2) Contents of the lib/sounds file ---------------------------------- The config file "lib/sounds" is stored on the server. It contains the mapping between the various events (sound types) and the sound files that should be played. This will be transferred to the client at startup and it will be possible for the client to override some entries. This file will contain lines which look like this: [ ] [ ] ... Comments begin with a "#" and can be inserted anywhere in the file. Blank lines and lines containing only a comment are ignored. Several sound files can be listed on the same line in order to create a more complex sound effect (but this is still considered as a single sound effect). The following example shows what kind of information is included in this file, but the actual format may vary (i.e. by using different separators or swapping the parameters). # , = , ; , ; ... # player actions: player hits door, 200 = knock.au, 60 player hits locked door, 200 = knock.au, 60 # same as above player opens door, 220 = creak.au, 80 # monsters: dragon moves, 100 = rumble.au, 20 dragon attacks, 0 = # no sound goblin dies, 150 = splat.au, 30 # spells: firestorm, 210 = whoosh.au, 100 # usual dragon attack comet, 230 = whoosh.au, 70; bang.au, 100, whoosh.au, 40 # ambient sounds: ambient wind, 10 = wind.au, 10 ambient woods, 10 = whoohoo.au, 20 # owls ambient cave, 10 = rumble.au, 10 # rocks moving ambient cave 2, 10 = drip.au, 20 # water dripping ambient well, 20 = drip.au, 30 # music: music castle room, 0 = castlemusic.au, 10; ballad.au, 10 music cave, 0 = cavemen.au, 15 music silly example, 0 = Dsharp.au, 10, C.au, 10, Eflat.au, 15 # ... At startup, the server reads this config file and associates an index number with each line. This index number is the only information that will be sent to the client during the game. The config file could be sorted or indexed with a hash table in order to find the index numbers faster (since the server will only know the sound name and will have to send the index number to the client). Each time a new client connects, the whole config file is sent to it, with each sound prefixed by its index number. The example above would be sent as: 1: player hits door, 200 = knock.au, 60 2: player hits locked door, 200 = knock.au, 60 3: player opens door, 220 = creak.au, 80 ... 3) How sounds are used in the game ---------------------------------- There are several kinds of sounds; each one is handled by a specific routine and defined in a different way. It is important to understand the differences between these categories, because some of the suggestions that have been posted to the mailing list did not take all of them into account. * Sounds triggered by player actions: pushing a lever, opening or hitting a door, falling in a pit, ... All these sounds names are prefixed by "player" and are included directly in the server code: when a player falls into a pit, the routine which deals with this action will send the message "You fell into a pit" and will also tell the client to play a sound called "player falls" (for example). Average priority for these sounds: 200. * Sounds made by monsters: movement, attack, pain when hit, ... The name of the sound will be built from the name of the monster and the name of the action. For example, a giant will play the sounds "giant idle", "giant moves", "giant attacks", "giant pain" and "giant dies". Likewise, a wyvern will play "wyvern idle", "wyvern moves", etc. (Note: the probability of playing the "idle" sound should be defined in the archetypes file, but it should also be possible to modify this attribute on the map). All monsters which have the same name will play the same sounds. If you want to have a monster which plays different sounds, then you should change its name and define new entries for it in the lib/sounds file. (Note: the server should look first for the monster name in lib/sounds, then for the archetype name if there is no entry with the name of the monster). Average priority for these sounds: 100. * Spells: players or monsters can cast spells, but I don't think it is necessary to have different sounds depending on who cast it. The volume will already be different because player spells will always start from the relative position (0, 0). The names of these sound events will be identical to the spell names. Average priority for these sounds: 200. * Environmental sounds: these are played at random and their only purpose is to set the right athmosphere (games like Heretic and Hexen are good examples of this). They do not give much information to the player, but they add more realism. The sounds that are not associated with a well-defined object on the map are always played from the player's position and will have a constant volume (this should be the case for wind, owls in the woods, etc.). Unlike the other sounds, the names of these events are not hardcoded in the server: they are included in the attributes of some objects on the maps. The names of these events will always begin with "ambient". Fixed priority for these sounds: 10 for normal sounds, and 20 for the sounds that give a bit of information and are associated with an object (e.g. water dripping if there is a well nearby, rocks falling if the player is close to a pit). Sounds with a priority of 10 will always be played from the player's position. * Background music: long sequence of sounds which are played in a loop. The format of the sound files doesn't matter: it could be a single .au file, multiple .wav files, a .mod or .midi file, ... I don't think that we need background music if the environmental sounds are well done, but some people cannot live without this, so... All music effects are prefixed with "music". Fixed priority for music: 0. 4) How the client plays the sounds ---------------------------------- At startup, the client receives the config file from the server. Each sound will have an index number associated with it for faster reference (usually, this will be its line number in the config file). After having received the complete list, the client checks if the user wants to override some entries. This will be done by reading a local file which has the same format as the lib/sounds file sent by the server. The client parses this list of sounds and builds an array which associates each index number with the list of sound files that should be played. At this stage, it is not necessary to keep the event names in memory, because they will not be used any more. If the client sees any sound that is not available on the local disk, it could choose to prefetch them, or to let the RPlay server get them automatically later. It is recommended that the machines which have a Crossfire server running also have a RPlay server ready to transfer sounds using the RPTP sound transfer system. During the game, the server sends the index number of every sound that should be played by the client, as well as the relative position of the sound source. These three numbers (index and two coords) are the only information that is sent when a sound has to be played. Well, maybe they should be preceded by a "play" command... The client will then play the sound or list of sounds that are associated with this index number. The maximum volume of each sound will be lowered according to the distance. If the client supports stereo sound, the volume of the left and right channels will be modified as appropriate. An easy way to do that is to calculate two distances: one for the left ear and one for the right ear, like if they were one map unit away from the player in each direction. If there are already several sounds playing, and the maximum number of simultaneous sounds has been reached, the client will only play the sounds which have the highest priority. The maximum number of simultaneous sound effects is customizable by the user and should be between 2 and 8 (4 should be the default value). Mixing more than 8 sounds would give bad results. 5) Open issues -------------- Most of the sound events for the lesser monsters will have no sound file associated to them in the config file, otherwise the game would be too noisy. Would it be a good idea to send the commands to play them anyway? Although they will probably have no effect on most clients, some user could have defined a sound for these events (remember that the user can override all sound definitions). Note that in order to support this, the server would have to generate index numbers for the sounds that are not in its config file. I think it is simpler to ignore the sounds that have no entry for them in lib/sounds. What attributes should be used in the archetypes file for defining how often a monster should play its "idle" sound? Same question for the "pain" sound: what is the minimum damage that the monster should take before playing this sound? Other idea for the "pain" sound: define several levels of pain and use relative threshold that would be the same for all monsters. For example, there could be three levels: "minor pain" for less than 10% damage, "pain" for less than 20% damage and "major pain" for more. Hmmm... Maybe two levels would be enough. What attributes should be used for "environmental sounds" in the maps? There should be a way to define their name and how often they should be repeated. (Note: the repeat rate is a property of the object which plays the sound, not a property of the sound event like it was suggested on the mailing list). Is it really a good idea to look for monster names before looking for their archetype name? This allows people to customize the sounds made by a particular monster or group of monsters (as suggested by Tero), but it adds some overhead. It would be simpler to sacrifice the customization and use the same sounds for all monsters of a given kind. If the NPC's are improved, there should be a way to add custom sounds for them too. ---------- cut here ---------- cut here ---------- cut here ---------- That's all folks! Merry Christmas and happy new year to everyone out there! I'm not sure that I will have the time to read my mail before next year, so I'd better send my wishes now... Remember: if you really want to reply, save some electrons by quoting only the relevant parts of my message and dropping everything else. Thanks! :-) -Raphael From crossfire-request Wed Dec 20 17:29:09 1995 Return-Path: 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 ; Wed, 20 Dec 1995 17:29:06 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id LAA25193; Wed, 20 Dec 1995 11:29:37 -0500 Date: Wed, 20 Dec 1995 11:29:37 -0500 (EST) From: Matt Cortes To: Colin cc: thomas@chaupher.gsfc.nasa.gov, crossfire@ifi.uio.no Subject: Re: disarm spell In-Reply-To: <199512200530.QAA27885@zebedee.teaching.cs.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 20 Dec 1995, Colin wrote: > How hard would it be to give a connect vaule to a trap so that you > can trigger all sort of things with it and or trigger traps by pulling > levers and stuff. This is really evil with area affect traps. Or would > you do it like destruction where all traps within range are triggered. > This would mean that two spikes or blade traps right next to each > other would be pretty nasty though. I wouldn't think it would be that hard. And I'm mainly talking about the explosive kind. Spikes, blades, etc only hurt those right on top the square, right? And I would call them stable triggers, they won't be setoff by explosions. But things like fire, poison cloud, icestorm, etc is explosive and each trap it comes in contact with, we could have icestorm square for instance try to disarm the traps it flies over, some maybe successful (trap was destroyed without setting it off), or unsuccessful, in which case the trap does go off. And so forth. I'm thinking this can be done since fire or icestorm is able to destroy some items it crosses over, so why not? -Matt (I don't think its evil, just realistic. :P ) From crossfire-request Wed Dec 20 15:43:42 1995 Return-Path: Received: from hilja.it.lut.fi (hevi@hilja.it.lut.fi [157.24.11.72]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 20 Dec 1995 15:43:42 +0100 Received: from localhost (hevi@localhost) by hilja.it.lut.fi (8.6.5/8.6.5/1.12.kim) id QAA06043; Wed, 20 Dec 1995 16:43:36 +0200 Date: Wed, 20 Dec 1995 16:43:35 +0200 (EET) From: Petri Heinila X-Sender: hevi@hilja.it.lut.fi To: crossfire@ifi.uio.no Subject: Re: Call me crazy but... In-Reply-To: <199512200502.PAA27110@zebedee.teaching.cs.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 20 Dec 1995, Colin wrote: > On this subject is there a way to make a stone block that looks like > any type of wall that dissappears. My problem is that the block goes > down and changes image and then when it comes up again it has the > standard stoneblock image. I was hoping to make a maze that changes > as you move through it, but to do this it looks like I'll have to employ > holes or exits and change to a slightly different map. Problem here is that animation sequence exist in archetype structure, so if the image is changed, the starting image, and then the block image sequence goes down and up, then the image is set first image of the image sequence, not to the defined image. So, what you have to do, is create new archetype with wanted image sequnece (anim). Petri.Heinila@lut.fi From crossfire-request Wed Dec 20 06:51:46 1995 Return-Path: Received: from zebedee.teaching.cs.adelaide.edu.au (celear@zebedee.teaching.cs.adelaide.edu.au [129.127.104.27]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 20 Dec 1995 06:51:42 +0100 Received: from celear@zebedee.teaching.cs.adelaide.edu.au by zebedee.teaching.cs.adelaide.edu.au (8.6.12/AndrewR-MatthewD-950530-CS) id QAA28531 for crossfire@ifi.uio.no; Wed, 20 Dec 1995 16:21:21 +1030 X-Authentic-Sender: celear@zebedee.teaching.cs.adelaide.edu.au From: Colin Message-Id: <199512200551.QAA28531@zebedee.teaching.cs.adelaide.edu.au> Subject: Traps and cone spells To: crossfire@ifi.uio.no (cf) Date: Wed, 20 Dec 1995 16:21:20 +1030 (CST) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1731 Status: RO This is the spring trap routine, which I assume is by peterm (the rest of the rune stuff appears to be by him...) that great god of crossfire (I think we should add him to the god list as something a few evils beyond satan or something) void spring_trap(object *trap,object *victim) { int spell_in_rune; object *env; trap->stats.hp--; /*decrement detcount */ /* get the spell number from the name in the slaying field, and set that as the spell to be cast. */ if((spell_in_rune=look_up_spell_by_name(NULL,trap->slaying))!=-1) trap->stats. sp=spell_in_rune; if(victim) if(victim->type==PLAYER) new_draw_info(NDI_UNIQUE, 0,victim,trap->m sg); if(!trap->stats.sp) rune_attack(trap,victim); else { remove_ob(trap); /***************************************************************** THIS NEXT LINE appears to be the problem to my inexpert eyes The trap when reinserted should be probably be put directly under where it currently is and the the spell cast in the direction of the player. I could do it, but I'm an ugly coder and a horrible hacker. Could someone fix this properly, Does anyone else think it should be please email me with support I feel neglected? *****************************************************************/ trap->x=victim->x;trap->y=victim->y; insert_ob_in_map(trap,victim->map); cast_spell(trap,trap,trap->direction,trap->stats.sp,1,0,NULL); } for(env=trap;env!=NULL&&env->env!=NULL;env=env->env); trap_show(trap,env); if(!trap->stats.hp) { trap->type=98; /* make the trap impotent */ trap->stats.food=20; /* make it stick around until it's spells are gone */ SET_FLAG(trap,FLAG_IS_USED_UP); } } Sorry for existing... seriously I tell you. From crossfire-request Wed Dec 20 06:31:16 1995 Return-Path: Received: from zebedee.teaching.cs.adelaide.edu.au (celear@zebedee.teaching.cs.adelaide.edu.au [129.127.104.27]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 20 Dec 1995 06:31:13 +0100 Received: from celear@zebedee.teaching.cs.adelaide.edu.au by zebedee.teaching.cs.adelaide.edu.au (8.6.12/AndrewR-MatthewD-950530-CS) id QAA27885; Wed, 20 Dec 1995 16:00:02 +1030 X-Authentic-Sender: celear@zebedee.teaching.cs.adelaide.edu.au From: Colin Message-Id: <199512200530.QAA27885@zebedee.teaching.cs.adelaide.edu.au> Subject: Re: disarm spell To: link@alpha.pulsar.net (Matt Cortes) Date: Wed, 20 Dec 1995 16:00:00 +1030 (CST) Cc: thomas@chaupher.gsfc.nasa.gov, crossfire@ifi.uio.no In-Reply-To: from "Matt Cortes" at Dec 19, 95 10:08:32 am X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1514 Status: RO etc> etc>Yep. I would just like to say I totally agree with it. After all, in etc>real life, it is possible to set a bomb off when trying to disarm it. SO etc>why not have a chance of MAJOR failure? etc> etc>Also, I have an idea I would like to toss out in the open.. Chain etc>reaction effect (Man I'm in a evil mood today ). When a trap goes off etc>(or pretty much any major activity goes on near explosive type traps), etc>why not make it possible for traps, etc to setoff other things in the area? etc> How hard would it be to give a connect vaule to a trap so that you can trigger all sort of things with it and or trigger traps by pulling levers and stuff. This is really evil with area affect traps. Or would you do it like destruction where all traps within range are triggered. This would mean that two spikes or blade traps right next to each other would be pretty nasty though. Speaking of traps has anyone thought of a way to recentre traps like burning hands, it is just too easy to stand still and have them go all around you. At moment I think runes in doors work by creating another rune right under the player that detonated it and setting it off, rather than with cone spells just setting it off where it is so that the player catches it full in the face so to speak. If this is wrong please correct me. Perhaps also more traps should work like some paralysis traps which get duplicated after they are set off. Just some hopefully polite thoughts to enliven your days From crossfire-request Wed Dec 20 06:11:16 1995 Return-Path: Received: from zebedee.teaching.cs.adelaide.edu.au (celear@zebedee.teaching.cs.adelaide.edu.au [129.127.104.27]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 20 Dec 1995 06:11:10 +0100 Received: from celear@zebedee.teaching.cs.adelaide.edu.au by zebedee.teaching.cs.adelaide.edu.au (8.6.12/AndrewR-MatthewD-950530-CS) id PAA27313; Wed, 20 Dec 1995 15:40:56 +1030 X-Authentic-Sender: celear@zebedee.teaching.cs.adelaide.edu.au From: Colin Message-Id: <199512200510.PAA27313@zebedee.teaching.cs.adelaide.edu.au> Subject: Re: attack_movement fix To: Steve.Wray@vuw.ac.nz Date: Wed, 20 Dec 1995 15:40:55 +1030 (CST) Cc: crossfire@ifi.uio.no In-Reply-To: <199512192001.JAA09842@debretts.comp.vuw.ac.nz> from "Stephen Wray" at Dec 20, 95 09:01:19 am X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1446 Status: RO etc> etc>-----BEGIN PGP SIGNED MESSAGE----- etc> etc> etc>There is a bug in the attack movement code. etc> etc>I've fixed it but... etc> etc>I don't know how to produce a patch file and I don't know where to etc>send the patch. So if some kind soul would tell me... etc> etc>Also, the hit-run attack mode appears not to work because there is etc>such a long delay between hitting and running -- the monster gets etc>25 hits before running 25 moves, then comes back for more. etc> etc>I think this is too much, but then it really should be a variable. etc> etc>My child-thieves now rush up hit a few times and run away real fast. etc>then they follow the character around, rush up again... 8-) etc> etc>One should be able to specify how much hitting and how much running etc>a monster does in a map or archetypes. etc> etc>How should I handle this? Patch files are pretty easy. it is spelled out in the crossfire-0.9x/doc/ dir in the programming guide I believe. or else use diff -c 5 or some such:-| etc>Suggestions? etc> etc>These attack modes are so cool that I seriously wonder why they havn't etc>been used in any archetypes or maps????? I haven't really read much about them, do they work and where are they documented? As for improving the system find a var that isn't being used as yet there are a few of them I think assign it in an arch and then find where the behavior is coded and go from there. From crossfire-request Wed Dec 20 06:03:18 1995 Return-Path: Received: from zebedee.teaching.cs.adelaide.edu.au (celear@zebedee.teaching.cs.adelaide.edu.au [129.127.104.27]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 20 Dec 1995 06:03:15 +0100 Received: from celear@zebedee.teaching.cs.adelaide.edu.au by zebedee.teaching.cs.adelaide.edu.au (8.6.12/AndrewR-MatthewD-950530-CS) id PAA27110; Wed, 20 Dec 1995 15:32:41 +1030 X-Authentic-Sender: celear@zebedee.teaching.cs.adelaide.edu.au From: Colin Message-Id: <199512200502.PAA27110@zebedee.teaching.cs.adelaide.edu.au> Subject: Re: Call me crazy but... To: hevi@lut.fi (Petri Heinila) Date: Wed, 20 Dec 1995 15:32:40 +1030 (CST) Cc: root@brain.supernet.ab.ca, crossfire@ifi.uio.no In-Reply-To: from "Petri Heinila" at Dec 19, 95 03:02:17 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2194 Status: RO etc> etc>On Mon, 18 Dec 1995, Richard Murray wrote: etc> etc>> (ignoring echoing 'you're crazy' cries) etc>> etc>> Playing around with making a unique and playable world on my machine etc>> here, and was playing with the idea of having secret areas that are etc>> totally inaccessible to anyone not holding a specially created unique etc>> item... ie a wizard's room to store things, etc ... nothing fancy really. etc>> in the source dist there is a doc dir, the crossfire.doc playerStats and a few other files in there document what most of the arch variables do. etc>> But this lead to a question: item types, etc... don't have cross loaded etc>> up so I can't remember the specifics - anyways, is there ANY kind of etc>> documentation of these seemingly mystical numbers for attributes? Or is etc>> it all kinda a master/apprentice thing where I would have to study for etc>> years to discover how? etc>> Another thing I was trying was to make it look like a tree, sound like a etc>> tree, taste like a tree, but when applied it would work like a teleport. etc>> Yes, I know an invis exit would work, but with just one object is what etc>> I've been playing with. etc>> etc>> Ideas? Suggestions? etc> etc>checkout whatm is type of exit, then get a tree to the map, etc>change the type of tree to the exit and there it is. etc> etc>as I know there is no documentation of types itself (but source etc>code as always). Best use I have found is to check the type etc>some existing object that behaves somewhat that I need, and the etc>apply same type. etc> Better to just change the face of the object, I tried doing it this way as well and had some trouble with objects that produce things and do things and are linked to things. changing the face is much easier. On this subject is there a way to make a stone block that looks like any type of wall that dissappears. My problem is that the block goes down and changes image and then when it comes up again it has the standard stoneblock image. I was hoping to make a maze that changes as you move through it, but to do this it looks like I'll have to employ holes or exits and change to a slightly different map. adios From crossfire-request Tue Dec 19 16:09:06 1995 Return-Path: Received: from alpha.pulsar.net (link@[206.161.93.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 19 Dec 1995 16:09:04 +0100 Received: (from link@localhost) by alpha.pulsar.net (8.6.12/8.6.9) id KAA20769; Tue, 19 Dec 1995 10:08:32 -0500 Date: Tue, 19 Dec 1995 10:08:32 -0500 (EST) From: Matt Cortes To: Brian Thomas cc: crossfire@ifi.uio.no Subject: Re: disarm spell In-Reply-To: <199512181826.NAA07554@chaupher.gsfc.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 18 Dec 1995, Brian Thomas wrote: > > I took out some time to look at this; I don't think > it will be much of a problem to fix. First off, the > spell calls disarm_trap() (though dispel_rune()) > and *if ALLOW_SKILLS is not defined* then experience > will be awarded for disarming the rune/trap via > a the disarm spell. The spell function itself has > > spell_util.c: success = dispel_rune(op,dir,0); /* 0 means no risk of detonating rune */ > > a risk factor associated with it. Just change the > risk factor to a positive number (1?) and there will > be a possibility of the trap detonating even when > you use the spell. OR, you can go the other route, > which is to remove the chance to gain exp when the > spell is used (and ALLOW_SKILLS *isnt* defined..) > I include a patch for that case below... > > b.t. > > Yep. I would just like to say I totally agree with it. After all, in real life, it is possible to set a bomb off when trying to disarm it. SO why not have a chance of MAJOR failure? Also, I have an idea I would like to toss out in the open.. Chain reaction effect (Man I'm in a evil mood today ). When a trap goes off (or pretty much any major activity goes on near explosive type traps), why not make it possible for traps, etc to setoff other things in the area? -Matt