From crossfire-request Fri Feb 4 12:55:21 1994 Return-Path: Received: from plague.Berkeley.EDU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 4 Feb 1994 12:55:11 +0100 Received: from monsoon.Berkeley.EDU by plague.Berkeley.EDU (5.65c/CHAOS) id AA10922; Fri, 4 Feb 1994 03:46:48 -0800 Message-Id: <199402041146.AA10922@plague.Berkeley.EDU> To: "William W. Dyess" Cc: crossfire@ifi.uio.no, mehlhaff@plague.Berkeley.EDU Subject: Re: Client/server.. In-Reply-To: Message from "William W. Dyess" of Thu, 03 Feb 1994 07:23:17 -0600 Date: Fri, 04 Feb 1994 03:46:45 -0800 From: "'Evil' ERic Mehlhaff" Status: RO "William W. Dyess" recently wrote: >Several people have tried (and so far, failed) to integrate the netrek >server into just one process. I'm not sure of the details, but from >listening to those trying to do it I gather that there is some difficulty >with the network side of things. Something about having to rewrite lots >of the network interface code? > >I'll see if I can find one of them to comment on it. It's a matter of properly multiplexing the networking code between all the sockets involved. I've written a library of functions for doing this sort for thing, just haven't had the incentive to try and port it over to netrek (yet). It works wonders for my parallel Crack program, though... ERic mehlhaff, mehlhaff@ocf.Berkeley.EDU From crossfire-request Fri Feb 4 08:32:26 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 4 Feb 1994 08:32:20 +0100 Received: by bolero.rahul.net id AA11273 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 3 Feb 1994 23:32:17 -0800 Date: Thu, 3 Feb 1994 23:32:17 -0800 From: Mark Wedel Message-Id: <199402040732.AA11273@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Programming thoughts. Status: RO Been merging the crossfire 0.7 source in with the crossfire 0.90 source. ITs been coming along OK. One thing I noticed was in the define.h file. In that file, there are about 40 lines of bitmasks, with macros to apply them to the correct flag in the object structure. One problem I see with the present method is that many of the flags have the same value, it is the assign/unassign or test macros that make sure it is the correct bit. I was thinking of changing all those values to integers (from about 0 to 40, all unique). Then have generic functions (set_bitmask(obj *, bit), clear_bitamsk(obj*, bit) and test_bitmask(obj *, bit) that then tests the correct bit. For example, if the bit is from 0-31, it tests flags[0], if from 32-63, tests flags[1], and so on. It uses shift operations to test the appropriate bit in the specific integer.) This would seem to clean up the code a bit, and make the chances of things being applied to the incorrect bit virtually nil. If those functions are done as macros or inline functions, the cost over the present method should be virutally nothing, assuming the compiler does decent optimization. I say this because the bit position to change/look at would be a constant when the program is compiled, so I would think/hope that the compiler would evaluate the values at run time. For example, something like: #define SET_BIT(xyz, p) \ xyz->flags[p/32] = 1 << (p % 32) p would still be the defined value (like F_ALIVE). As such, something like SET_ALIVE(player) would become SET_BIT(player, F_ALIVE) Any thoughts and why this should not be done? It seems to me that this method would also make it easier to add additional bits (just increment the array value, and add a define for the position). Mark Wedel master@rahul.net From crossfire-request Fri Feb 4 08:29:11 1994 Return-Path: Received: from gjalp.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 4 Feb 1994 08:29:10 +0100 From: Frank Tore Johansen Received: from localhost by gjalp.ifi.uio.no ; Fri, 4 Feb 1994 08:29:09 +0100 Message-Id: <19940204072909.20334.gjalp.ifi.uio.no@ifi.uio.no> Subject: Re: coding question To: crossfire@ifi.uio.no Date: Fri, 4 Feb 1994 08:29:08 +0100 (MET) In-Reply-To: <199402040300.TAA01797@soda.berkeley.edu> from "Peter Mardahl" at Feb 3, 94 07:00:45 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1736 Status: RO Peter wrote: > [...] > This kind of upset me, so I rewrote the set_owner function in (object.c?) > to trace all the way back to the original owner object, so that > object 2 was very definitely owned by spell-caster. > > I think this may have had some funny side effects, but i really am > not sure that this is the cause. > > What if anything is this change likely to break? Changing set_owner() to that seems correct to me, and if it has any side-effects, they are caused by bugs. Only spells are likely to be affected by this, since lots of spell effects expand by duplicating themselves. Please try it out 8) > Also, what happens when the owner of an object dies and is removed > from a map? the "object *owner" field of the object with a defunct owner > is not zeroed is it? For cones, I've observed, the cone is removed when > the owner is removed. However, for certain other spells such as fireball, > this does NOT happen. > > How does this work? All objects have an unique id, object->count. Each time a new object is allocated, a global integer is increased and stored in this variable. Each time object->owner is set to point to the owner object, object->ownercount is set to object->owner->count, and in get_owner() this (and a couple of other sanity checks) is checked. This is a fast method, but its not failproof. One time in a million something "strange" can happen...So ideally a refcount system should be fully implemented (I started on it...). Thus an object wouldn't be freed until all its "children" has been freed (add a refcount each time another child is created, subtract one when one is deleted, and free parent when refcount reaches 0 (and parent is marked as "wanting to be freed"). -Frank. From crossfire-request Fri Feb 4 06:01:19 1994 Return-Path: Received: from boulder.Colorado.EDU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 4 Feb 1994 06:01:15 +0100 Received: from hollerith.Colorado.EDU by boulder.Colorado.EDU with SMTP id AA20630 (5.65c/IDA-1.4.4 for ); Thu, 3 Feb 1994 22:01:13 -0700 Received: by hollerith.colorado.edu (cu.generic.890828) From: "T. Alexander Popiel" Message-Id: <199402040501.WAA21570@hollerith.colorado.edu> To: crossfire@ifi.uio.no Subject: Re: UDP communications (was: Re: Crossfire client) In-Reply-To: Your message of "Thu, 03 Feb 94 20:14:20 CST." Date: Thu, 03 Feb 94 22:01:03 -0700 X-Mts: smtp Status: RO In message: "William W. Dyess" writes: >> Why not have the servers download the spell behaviors to the client >> upon connection? Seems simple to me, and sends the info once instead >> of _each_time_ a spell is used. > >Much of the info (bitmaps used and such) can be sent, but the actual >animation of a moving projectile should be sent by the server. This way, >if the server slows down, everything on the client slows down as well. > >--Bill Dyess -------- That's what the time re-syncs I mentioned are for. However, I was suggesting they be sent via UDP so they can be dropped on the floor w/o worry. Basically, my point is to put as little info through the TCP link as possible, while keeping info which (while useful) quickly gets out-dated on UDP. - Alex From crossfire-request Fri Feb 4 04:00:56 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 4 Feb 1994 04:00:53 +0100 Received: from localhost (peterm@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id TAA01797 for crossfire@ifi.uio.no; Thu, 3 Feb 1994 19:00:45 -0800 Date: Thu, 3 Feb 1994 19:00:45 -0800 From: Peter Mardahl Message-Id: <199402040300.TAA01797@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: coding question Status: RO I'm really glad to see that something is being done with the code. Thanks to all who are making the effort! Anyway, my question is this: Suppose a spellcaster creates an object which in turn creates another object. Spell-caster --> object 1 --> object 2 object 1 is owned by the spell-caster who owns object 2? spell-caster or object 1? object 1 calls cast-spell to create object 2. I wrote a spell once called meteor swarm. It created a 'swarm' object, an invsible object which would cast a 'meteor' spell every time it 'moved'. Now, every time one of the meteors would kill something the original spellcaster would not register a kill. I took this to mean that the swarm object was getting the kill.... and the experience! This kind of upset me, so I rewrote the set_owner function in (object.c?) to trace all the way back to the original owner object, so that object 2 was very definitely owned by spell-caster. I think this may have had some funny side effects, but i really am not sure that this is the cause. What if anything is this change likely to break? Also, what happens when the owner of an object dies and is removed from a map? the "object *owner" field of the object with a defunct owner is not zeroed is it? For cones, I've observed, the cone is removed when the owner is removed. However, for certain other spells such as fireball, this does NOT happen. How does this work? Regards, PeterM From crossfire-request Fri Feb 4 03:16:22 1994 Return-Path: Received: from edison.eng.auburn.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 4 Feb 1994 03:16:21 +0100 Received: from lab15.eng.auburn.edu (lab15.eng.auburn.edu [131.204.11.15]) by edison.eng.auburn.edu (8.6.4/8.6.4) with ESMTP id UAA16318 for ; Thu, 3 Feb 1994 20:16:18 -0600 Received: from localhost (dyessww@localhost) by lab15.eng.auburn.edu (8.6.4/8.6.4) id UAA05217; Thu, 3 Feb 1994 20:16:18 -0600 Date: Thu, 3 Feb 1994 20:14:20 -0600 (CST) From: "William W. Dyess" Subject: Re: UDP communications (was: Re: Crossfire client) To: crossfire@ifi.uio.no In-Reply-To: <199402040014.RAA20862@hollerith.colorado.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO > Why not have the servers download the spell behaviors to the client > upon connection? Seems simple to me, and sends the info once instead > of _each_time_ a spell is used. Much of the info (bitmaps used and such) can be sent, but the actual animation of a moving projectile should be sent by the server. This way, if the server slows down, everything on the client slows down as well. --Bill Dyess From crossfire-request Fri Feb 4 02:08:28 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 4 Feb 1994 02:08:23 +0100 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA19780; Fri, 4 Feb 1994 12:07:44 +1100 Date: Fri, 4 Feb 1994 12:07:44 +1100 From: "Rupert G. Goldie" Message-Id: <199402040107.AA19780@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no, master@rahul.net Subject: Re: Getting crossfire to work under solaris 2.3 Status: RO > From: Mark Wedel > > First off, crossfire 0.90.0 is not the version you should use if you > only want to play teh game. There are probably enough bugs and other > problems that only peopel who plan to develope the code should play. > > I would recommend getting crossedit 0.7 or crossfire 0.89.2 (0.89.3 if > you can find it) instead. These are 'stable' versions, with few bugs. > > Mark Wedel > master@rahul.net > Just how buggy are people finding 0.90.0 ?? I have only managed to get it to crash when I was using compressed maps (I'm looking into it now). I have played it for several hours now with one or two players and after a few small changes Purify hardly grumbles (I've even plugged several memory leaks). Rupert -- Rupert G. Goldie, rgg@aaii.oz.au From crossfire-request Fri Feb 4 01:14:43 1994 Return-Path: Received: from boulder.Colorado.EDU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 4 Feb 1994 01:14:41 +0100 Received: from hollerith.Colorado.EDU by boulder.Colorado.EDU with SMTP id AA20186 (5.65c/IDA-1.4.4 for ); Thu, 3 Feb 1994 17:14:39 -0700 Received: by hollerith.colorado.edu (cu.generic.890828) From: "T. Alexander Popiel" Message-Id: <199402040014.RAA20862@hollerith.colorado.edu> To: crossfire@ifi.uio.no Subject: Re: UDP communications (was: Re: Crossfire client) In-Reply-To: Your message of "Thu, 03 Feb 94 15:38:49 PST." <199402032338.AA16235@bolero.rahul.net> Date: Thu, 03 Feb 94 17:14:26 -0700 X-Mts: smtp Status: RO In message: <199402032338.AA16235@bolero.rahul.net> Mark Wedel writes: > There is no reason that a client could not know the various spell >effects. > > However, the problem with the method is, that it makes adding custom >spells to the various servers difficult. Now all the spells would need >to also reside in the client, so when ever a new spell is added to a server, >that change would also need to be made to all the clients. Why not have the servers download the spell behaviors to the client upon connection? Seems simple to me, and sends the info once instead of _each_time_ a spell is used. > Mark Wedel >master@rahul.net - Alex From crossfire-request Fri Feb 4 00:41:28 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 4 Feb 1994 00:41:20 +0100 Received: by bolero.rahul.net id AA16369 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 3 Feb 1994 15:40:35 -0800 Date: Thu, 3 Feb 1994 15:40:35 -0800 From: Mark Wedel Message-Id: <199402032340.AA16369@bolero.rahul.net> To: ENNSNR@brandonu.ca, crossfire@ifi.uio.no Subject: Re: Getting crossfire to work under solaris 2.3 Status: RO First off, crossfire 0.90.0 is not the version you should use if you only want to play teh game. There are probably enough bugs and other problems that only peopel who plan to develope the code should play. I would recommend getting crossedit 0.7 or crossfire 0.89.2 (0.89.3 if you can find it) instead. These are 'stable' versions, with few bugs. Mark Wedel master@rahul.net From crossfire-request Fri Feb 4 00:39:01 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 4 Feb 1994 00:38:55 +0100 Received: by bolero.rahul.net id AA16235 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 3 Feb 1994 15:38:49 -0800 Date: Thu, 3 Feb 1994 15:38:49 -0800 From: Mark Wedel Message-Id: <199402032338.AA16235@bolero.rahul.net> To: dyessww@eng.auburn.edu, popiel@hollerith.Colorado.EDU Subject: Re: UDP communications (was: Re: Crossfire client) Cc: crossfire@ifi.uio.no Status: RO There is no reason that a client could not know the various spell effects. However, the problem with the method is, that it makes adding custom spells to the various servers difficult. Now all the spells would need to also reside in the client, so when ever a new spell is added to a server, that change would also need to be made to all the clients. If the server sends messages to the client about the various effects (ie, draw fire, center 5x5, radius 10), then the client does not need to know what the spell actually is. This allows people running servers to add or change spells, and still let people with most any client play. Otherwise, you might very well have one client for each server. Mark Wedel master@rahul.net From crossfire-request Fri Feb 4 00:39:52 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 4 Feb 1994 00:39:13 +0100 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA18998; Fri, 4 Feb 1994 10:37:55 +1100 Date: Fri, 4 Feb 1994 10:37:55 +1100 From: "Rupert G. Goldie" Message-Id: <199402032337.AA18998@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no Subject: Re: Just some hints Status: RO Patrick asked me to forward this to the list also. ----- Begin Included Message ----- From crossfire-request Thu Feb 3 21:29:48 1994 Return-Path: Received: from stan.BrandonU.CA by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Thu, 3 Feb 1994 21:28:06 +0100 Received: from BrandonU.CA by BrandonU.CA (PMDF V4.2-11 #4267) id <01H8GA9IX4XW94DP49@BrandonU.CA>; Thu, 3 Feb 1994 14:27:41 CDT Date: Thu, 03 Feb 1994 14:27:40 -0500 (CDT) From: "Simple pleasures are the best." Subject: Getting crossfire to work under solaris 2.3 To: crossfire@ifi.uio.no Message-id: <01H8GA9IX4XY94DP49@BrandonU.CA> X-Envelope-to: crossfire@ifi.uio.no X-VMS-To: IN%"crossfire@ifi.uio.no" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Status: RO *sob* *grovel* *beg* I have crossfire completely compiled and installed in my home directory. But when i try and run it, i get the following: Welcome to CrossFire, v0.90.0, copyright (C) 1992 Frank Tore Johansen. Trying to fix fontpath for display pc00076.pcs.brandonu.ca:0.0. Error code BadValue (integer parameter out of range for operation) Failed, switching to pixmaps (this might take a while). Error code BadAlloc (insufficient resources for operation) Error code BadDrawable (invalid Pixmap or Window parameter) Error code BadDrawable (invalid Pixmap or Window parameter) Error code BadGC (invalid GC parameter) Error code BadAlloc (insufficient resources for operation) Error code BadDrawable (invalid Pixmap or Window parameter) Error code BadDrawable (invalid Pixmap or Window parameter) Error code BadGC (invalid GC parameter) Error code BadAlloc (insufficient resources for operation) Error code BadDrawable (invalid Pixmap or Window parameter) Error code BadDrawable (invalid Pixmap or Window parameter) Error code BadGC (invalid GC parameter) Error code BadAlloc (insufficient resources for operation) Error code BadDrawable (invalid Pixmap or Window parameter) Error code BadDrawable (invalid Pixmap or Window parameter) Error code BadGC (invalid GC parameter) Error code BadAlloc (insufficient resources for operation) Error code BadDrawable (invalid Pixmap or Window parameter) Error code BadDrawable (invalid Pixmap or Window parameter) Error code BadGC (invalid GC parameter) Error code BadAlloc (insufficient resources for operation) Error code BadDrawable (invalid Pixmap or Window parameter) Error code BadDrawable (invalid Pixmap or Window parameter) Emergency save: logon SIGSEGV received. Abort (core dumped) *sob* Can someone PULLLLEASE help me get this working? crossfire sounds like such a cool game..... Neil *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Neil Enns | ennsnr@BrandonU.CA (vax) | ennsnr@tau.brandonU.CA (Unix) 6 Elmdale Blvd. * Brandon, Manitoba | Shift to the left! Shift to the right! R7B 1B6 * Pop up, push down, byte, byte, byte! (204) 728-4252 or | - The computer programmers cheer (204) 726-1117 * | owuh (interj): From the Latin "owuhnus", meaning "what * the hell[q.v.] was _that_?" *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From crossfire-request Thu Feb 3 16:46:27 1994 Return-Path: Received: from boulder.Colorado.EDU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Thu, 3 Feb 1994 16:46:22 +0100 Received: from hollerith.Colorado.EDU by boulder.Colorado.EDU with SMTP id AA16478 (5.65c/IDA-1.4.4 for ); Thu, 3 Feb 1994 08:45:38 -0700 Received: by hollerith.colorado.edu (cu.generic.890828) From: "T. Alexander Popiel" Message-Id: <199402031545.IAA19708@hollerith.colorado.edu> To: "William W. Dyess" Cc: crossfire@ifi.uio.no Subject: Re: UDP communications (was: Re: Crossfire client) In-Reply-To: Your message of "Thu, 03 Feb 94 07:28:49 CST." Date: Thu, 03 Feb 94 08:45:27 -0700 X-Mts: smtp Status: RO In message: "William W. Dyess" writes: > >The animated sequences are probably best done with UDP. > >--Bill Dyess -------- I would suggest having both a TCP connection and a UDP connection to each client. The TCP connection would give information like "Medium fireball starts at map 17 x 3 y 12 at time 201" or "Small Shield 1 at map 17 x 6 y 12 begins burning at time 205" or "Mage at map 18 x 4 y 15 moved to map 18 x 5 y 16 at time 300" (in a more compact format, of course). The UDP connection would send out messages like "It is now time 297" to maintain reasonable server- client syncronization. The reason for the two separate connections is that you don't want to lose the info about events starting/stopping/ etc, but you don't really care if you miss a time re-sync (the client should be able to keep time going on its own, if need be). Note that I specified a spell start time and place, and nothing else. I see no reason why the client shouldn't know how various spells behave, and maintain its own idea of the universe without the server telling it "OK, now that fireball I told you about covers the squares map 17 x 3 y 12 map 17 x 4 y 12 map 17 x 2 y 12 map 17 x 3 y 11 map 17 x 3 y 13", followed one tick later by a similar message with a slightly larger area, etc. That level of hand-holding seems like a waste of bandwidth to me. - Alex From crossfire-request Thu Feb 3 14:34:20 1994 Return-Path: Received: from edison.eng.auburn.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Thu, 3 Feb 1994 14:34:17 +0100 Received: from lab15.eng.auburn.edu (lab15.eng.auburn.edu [131.204.11.15]) by edison.eng.auburn.edu (8.6.4/8.6.4) with ESMTP id HAA29233 for ; Thu, 3 Feb 1994 07:33:51 -0600 Received: from localhost (dyessww@localhost) by lab15.eng.auburn.edu (8.6.4/8.6.4) id HAA02880; Thu, 3 Feb 1994 07:33:51 -0600 Date: Thu, 3 Feb 1994 07:28:49 -0600 (CST) From: "William W. Dyess" Subject: Re: Crossfire client (and Re: Patches, ftp, new releases. ) To: crossfire@ifi.uio.no In-Reply-To: <199402030853.AAA01051@soda.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 3 Feb 1994, Philip Brown wrote: > >>>>[From William W. Dyess] > > Netrek manages to send the position info for 16+ ship as well as up > to 8 torps for each 10 times/sec. Sending position info for a fireball > shouldn't be too tough. > > In updating reality terms, netrek can only handle about 4 ships, and 20 > torpedos in one display space, before net lag becomes unbearable. Ok, that gives us two dozen moving objects to play with. Everything else should be client controlled. Can anybody think of a time when we would need to have more than 24 continuously moving objects? BTW, how many updates/sec do we want to achieve? The animated sequences are probably best done with UDP. --Bill Dyess From crossfire-request Thu Feb 3 14:28:40 1994 Return-Path: Received: from edison.eng.auburn.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Thu, 3 Feb 1994 14:28:37 +0100 Received: from lab15.eng.auburn.edu (lab15.eng.auburn.edu [131.204.11.15]) by edison.eng.auburn.edu (8.6.4/8.6.4) with ESMTP id HAA29180 for ; Thu, 3 Feb 1994 07:28:29 -0600 Received: from localhost (dyessww@localhost) by lab15.eng.auburn.edu (8.6.4/8.6.4) id HAA02860; Thu, 3 Feb 1994 07:28:29 -0600 Date: Thu, 3 Feb 1994 07:23:17 -0600 (CST) From: "William W. Dyess" Subject: Re: Client/server.. To: crossfire@ifi.uio.no In-Reply-To: <199402030712.AA22437@plague.Berkeley.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO > This particular discussion has been going on in the netrek arena for > years. Netrek was originally developed on a 14 processor sequent. When > you have a dozen (slow) 16 mhz 386's, you WANT to break intensive tasks up into > several processes. On single processor machines, however, all the context > switching and memory usage of having multiple processes really thrashes. > The only real argument for multiprocess is that it makes debugging a > little easier, as single processes can fail without taking out the whole > server. Several people have tried (and so far, failed) to integrate the netrek server into just one process. I'm not sure of the details, but from listening to those trying to do it I gather that there is some difficulty with the network side of things. Something about having to rewrite lots of the network interface code? I'll see if I can find one of them to comment on it. --Bill From v912152@duinkerken.si.hhs.nl Thu Feb 3 20:28:04 1994 From: v912152@duinkerken.si.hhs.nl Subject: Re: Just some hints To: rgg@aaii.oz.au (Rupert "G." Goldie) Date: Thu, 3 Feb 1994 09:25:18 +0000 (GMT) Status: RO > > - I've been busy for 2 days compiling crossfire (missing includes, > > link-libraries, etc), so it mighty be nice to ease the installing a bit. > > - Let it be possible to change the lib-dir on command-line > What are you trying to build it on ? I had no problems building it on a Sun > running SunOS (except for making spoiler.ps - item-extract is missing). I've compiled CF 0.90.a on a Sun SPARCstation LX, with Solaris. I had to include and change 2 lines in 'include/includes.h'. What beats me, is that after every change in the source/include-files, the whole source-tree is builded _again_! (why did we invent make-files??) But really, I think it might prove worthy, to allow changing of dir-names and other important constants on the command-line (hard-coding is BAAAAAD!) . > > BTW, is there any interest left for the amiga-port of crossfire ???? > > I've let the project rest for more than a year now, but maybe someone > > can help me??? > Are you the guy who modified the data structures to speed the game up for your > Amiga port ? If so, did those mods ever get folded into the main release, because > any speed ups will be useful as we get more players in a game. > Rupert Yes, but it never came to a real release. (I -did- send my sources to Frank..) Anyways, I made 2 seperate lists for the objects: 1) a list for static objects (weapons, potions, books, etc) 2) a list for all the living objects (monsters, wire-walls, waveing grass, etc) The 2nd list allows the game to parse all the living things in one run. (You don't have to check all the books etc, to find the anim/liv. things) I can make an archive with this code if you wish ? BTW, I've got a very nice mud running for 2 months now on campus, and I must admit that the code is crystal-clear, and has some really decent structs and routines. If you're interested to look at the code: it's called CirleMud. (ftp.cs.jhu.edu:/pub/CircleMUD) (ALERT: It might take over CF, so -PLEASE- do something quick!!) PS, I've been thinking to create a new game, much like CF, but with the (better) CM structs, and a new data-organisation (looks like CF). One idea I have, is to create a standard data-set (around 100Kb) for the game, so all maps have a base to build on. This std-set increases per version, so you've got to specify which game-version a map needs. Place each map in it's own dir, and make it possible to extend the data on-the-fly (so a map can have totally unique objects/monsters). Maybe a good idea for CF too??? Patrick ----- End Included Message ----- From crossfire-request Thu Feb 3 01:50:47 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Thu, 3 Feb 1994 01:50:43 +0100 Received: from localhost (philb@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id QAA10878 for crossfire@ifi.uio.no; Wed, 2 Feb 1994 16:50:39 -0800 From: Philip Brown Message-Id: <199402030050.QAA10878@soda.berkeley.edu> Subject: Re: Crossfire client (and Re: Patches, ftp, new releases. ) To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Wed, 2 Feb 1994 16:50:37 -0800 (PST) In-Reply-To: <199402030006.AA06631@bolero.rahul.net> from "Mark Wedel" at Feb 2, 94 04:06:08 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1294 Status: RO >>>>[From Mark Wedel] The other type is things like gates going up ball, fireballs expanding, with the flame burning down, etc. These are ones were they occur for a short amount of time, and then become static (or disappear). ... The second are a little more difficult, because you need to make sure that the server and client are synchronized in what they think should be displayed. Good point. Since they are one-time things (and usually not very bandwidth intensive, even), i think it should be just handled as standard updates. (server informs client that square hs changed to bitmap x-14) As for the fireball thing.... erm... those things can get really annoying, and bandwidth eating. Perhaps a better bethod of displaying area effect spells could be thought up, for a more intelligent client. Something along the lines of specifying a poligon? Oh: side note: some spells should overpower others. For instance, a medium fireball should overpower an ice storm, in the fireball's area of effect. On the other hand, a large icestorm should overpower a fireball, in the ice's area of effect. I THINK this would simplify the polygon issue, depending on how it's implemented. Rule #1: spells should not be able to go around corners, I think. From crossfire-request Thu Feb 3 01:06:14 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Thu, 3 Feb 1994 01:06:11 +0100 Received: by bolero.rahul.net id AA06631 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Wed, 2 Feb 1994 16:06:08 -0800 Date: Wed, 2 Feb 1994 16:06:08 -0800 From: Mark Wedel Message-Id: <199402030006.AA06631@bolero.rahul.net> To: crossfire@ifi.uio.no, mehlhaff@ocf.berkeley.edu Subject: Re: Crossfire client (and Re: Patches, ftp, new releases. ) Status: RO IT seems to me that there are really two types of animations that grouped into one cluster. One type of animation is repetive (grass blowing in wind, waves going up and down, and similar ones where the object just cycles through a series of pixmaps, and provided the object does nto change, this cycle always remains the same.) The other type is things like gates going up ball, fireballs expanding, with the flame burning down, etc. These are ones were they occur for a short amount of time, and then become static (or disappear). The first can easily be handled in the client (easily and safely.) The second are a little more difficult, because you need to make sure that the server and client are synchronized in what they think should be displayed. If the client is a few ticks ahead of what the server think is displayed, or a few ticks behind, this could cause trouble for players (and example might be a player sittign at the edge of a fire ball and moving in as it burns down, so that he is always at the edge. IF the client is ahead in the animations, the server will think this character is actually in the fireball.) I think the ideal client would handle as much of the routine stuff as possible, without letting the client gain super powers (if someone wants to right a robot to play for them, I think this is acceptable.) A big client may mean that a lot of common stuff is stored on both the server and client (an example may be inventory. The client could then send messages to the server of the type 'drop shortsword (id#)', or 'use wand of small fireballs (dir E)'. If the server can not find such an item on the player, it sends some sort of error code. Mark Wedel master@rahul.net From crossfire-request Thu Feb 3 00:10:50 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Thu, 3 Feb 1994 00:10:14 +0100 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA03304; Thu, 3 Feb 1994 10:09:26 +1100 Date: Thu, 3 Feb 1994 10:09:26 +1100 From: "Rupert G. Goldie" Message-Id: <199402022309.AA03304@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no, v912152@duinkerken.si.hhs.nl Subject: Re: Just some hints Status: RO > Hi! > Since you guys are so busy codeing on crossfire; I'd like to mention 2 points: > - I've been busy for 2 days compiling crossfire (missing includes, > link-libraries, etc), so it mighty be nice to ease the installing a bit. > - Let it be possible to change the lib-dir on command-line > > BTW, is there any interest left for the amiga-port of crossfire ???? > I've let the project rest for more than a year now, but maybe someone > can help me??? > > Thanx 4 U'r time: > Patrick van Logchem (v912152@si.hhs.nl) > What are you trying to build it on ? I had no problems building it on a Sun running SunOS (except for making spoiler.ps - item-extract is missing). Are you the guy who modified the data structures to speed the game up for your Amiga port ? If so, did those mods ever get folded into the main release, because any speed ups will be useful as we get more players in a game. Rupert -- Rupert G. Goldie, Research Scientist rgg@aaii.oz.au Australian Artificial Intelligence Institute /\/\|| 1 Grattan Street, Melbourne, Australia Buzzword for 1994 - Information Superhighway (just like CB radio only with more typing) From crossfire-request Wed Feb 2 14:10:22 1994 Return-Path: Received: from paaltjens.si.hhs.nl by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Wed, 2 Feb 1994 14:10:14 +0100 From: v912152@duinkerken.si.hhs.nl Received: from duinkerken.si.hhs.nl by paaltjens.si.hhs.nl id <27449-0@paaltjens.si.hhs.nl>; Wed, 2 Feb 1994 14:09:53 +0100 Received: by duinkerken.si.hhs.nl (5.0/2.0) id AA12099; Wed, 2 Feb 94 14:09:52 +0100 Date: Wed, 2 Feb 94 14:09:52 +0100 Message-Id: <9402021309.AA12099@duinkerken.si.hhs.nl> To: crossfire@ifi.uio.no Subject: Just some hints Content-Length: 500 Status: RO Hi! Since you guys are so busy codeing on crossfire; I'd like to mention 2 points: - I've been busy for 2 days compiling crossfire (missing includes, link-libraries, etc), so it mighty be nice to ease the installing a bit. - Let it be possible to change the lib-dir on command-line BTW, is there any interest left for the amiga-port of crossfire ???? I've let the project rest for more than a year now, but maybe someone can help me??? Thanx 4 U'r time: Patrick van Logchem (v912152@si.hhs.nl) From crossfire-request Wed Feb 2 11:10:15 1994 Return-Path: Received: from plague.Berkeley.EDU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Wed, 2 Feb 1994 11:10:05 +0100 Received: from tsunami.Berkeley.EDU by plague.Berkeley.EDU (5.65c/CHAOS) id AA21420; Wed, 2 Feb 1994 01:57:13 -0800 Message-Id: <199402020957.AA21420@plague.Berkeley.EDU> To: crossfire@ifi.uio.no Subject: Crossfire client (and Re: Patches, ftp, new releases. ) In-Reply-To: Message from Tero Haatanen of Mon, 31 Jan 94 12:11:57 +0200 <199401311011.MAA22999@cc.lut.fi> Date: Wed, 02 Feb 1994 01:57:08 -0800 From: "'Evil' ERic Mehlhaff" Status: RO Tero Haatanen recently wrote: >At least nobody can say that crossfire deveplopment is dead. I add some >of my thoughts in this discussion. Well, for us here at berkeley, it was for a while, as the machine we were using basically died. We're still trying to either fix it or find another. :-P First, you folks can work on a new merged release. Once that's out, we'll work on adding all the cool stuff we have in our own crossedit0.7 release based code. I had to do the merge from the .5 base, and it wasn't too bad. Just don't do any major code structure changing, and we should be happy. >After we have the stable version we can start doing the client/server >version. Like Kjetil descripted differences between crossedit 0.7 and >crossfire 0.90a, those don't affect client/server code. I'm currently working on crossfire server-client code. It shouldn't really be affected by those changes in the code. It's going to end up being very strongly based on netrek. TCP only (at first), and Xlib only, with the windowing system calls easily ported out (again, just like netrek). Once I get that stable, people can throw in whatever funky xwidgets for things they want. >Also we have time to discuss, what client does and what server does and >how they communicate with each other. I think that server should handle >everything, excluding maybe animation. So slow client could have option >no-animations, but this probably requires that where animation is used >something important (i.e. opening/closing gates), those have to be done >with changing objects. Well, my client code's going to do its own animations, except maybe for the monster animations. Really, it's just goint to be displaying things. >Client also could handle inventory, so that server only knows what item >is applied, dropped, etc. How that is applied is client trouble (i.e. >clicking with mouse or pressing 'a'). And when server sends info that >player has 10/105 hp's, client can draw status bar, print numbers or >play audiofile in /dev/audio :). My idea was the server handles the inventory, but also tells the client what the player is carrying, etc. The client can then nicely sort and display things, as well as provide a nice frontent to applying/droppgin, etc. >I think that possibility that there is ability cheat with 'superclient' >isn't important. Mainly because there is not very much to gain. It's >easier gain exp in the maps where you can kill trapped monster and gold >collecting all those 'free' treasures on maps. And there is always some >maps where this is possible. Only useful feature a can think is automatic >'read recall' when low hp's, but that probably cause more problem that >it helps. Mud-players have done this kind of things and it's normally >easy to detect. I'm not too worried about players making the 'superclient'. My idea for server-client protocol would make this extermely hard. To top it off, I propose we just plain plug in netrek's RSA code, should we need binary verification. Its portable, its debugged, it's done. We could do just as netrek has with it. It's availalbe freely from sites outside of the US. It's not a problem. >And binary distributions with RSA means much more work and many people >don't like idea installing binaries from net, especially when it the >network game. Well, any binary distribution is dangerous. I doubt we really need to worry about it. I can explain more about my client code protocol, if people want. I'm still busily hacking away on it, though. ERic mehlhaff, mehlhaff@ocf.Berkeley.EDU From crossfire-request Wed Feb 2 05:15:42 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Wed, 2 Feb 1994 05:15:14 +0100 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA18342; Wed, 2 Feb 1994 10:24:43 +1100 Date: Wed, 2 Feb 1994 10:24:43 +1100 From: "Rupert G. Goldie" Message-Id: <199402012324.AA18342@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no, dpapp@amisk.cs.ualberta.ca Subject: Re: Crossfire - hints Status: RO > How do you beat Reapers if you dont have invulnerable to drain? > Run away and blast them with magic (They're vulnerable to magic). Rupert From crossfire-request Tue Feb 1 02:49:38 1994 Return-Path: Received: from sognsvann.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id ; Tue, 1 Feb 1994 02:49:38 +0100 From: Kjetil Torgrim Homme Received: from localhost by sognsvann.ifi.uio.no ; Tue, 1 Feb 1994 02:49:37 +0100 Date: Tue, 1 Feb 1994 02:49:37 +0100 Message-Id: <19940201014937.8894.sognsvann.ifi.uio.no@ifi.uio.no> To: rgg@aaii.oz.au CC: crossfire@ifi.uio.no In-reply-to: "Rupert G. Goldie"'s message of Tue, 1 Feb 1994 11:39:39 +1100 <199402010039.AA03398@eden-valley.aaii.oz.AU> Subject: Re: Patches, ftp, new releases. Status: RO Rupert: > Looking at the 0.90a maps, it looks as though 0.90a has removed omaps also. Sorry for being unclear - Crossfire 0.90a still has omaps _internally_. This is quite a big overhead in large maps. Kjetil T. From crossfire-request Tue Feb 1 01:40:43 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id ; Tue, 1 Feb 1994 01:40:01 +0100 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA03398; Tue, 1 Feb 1994 11:39:39 +1100 Date: Tue, 1 Feb 1994 11:39:39 +1100 From: "Rupert G. Goldie" Message-Id: <199402010039.AA03398@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no, kjetilho@ifi.uio.no Subject: Re: Patches, ftp, new releases. Status: RO > From: Kjetil Torgrim Homme [...] > Some points in favour of each: > > Crossedit 0.7 has removed omaps, better system for archetypes and > named bitmaps, a special font file for speeding up reading pixmaps > and probably lots more. (technical things, you see) > > Crossfire 0.90a has randomly generated artifacts (ie. a sword can > become sword of Moria), encounters (randomly generated sub-maps), > cursed/damned items (you should identify), special magic item types > (rods (recharging wands), horns) > > So Crossfire 0.90a has many playability enhancing > additions. Unfortunately, Crossedit has changed the directory > structure of the code as well. What I am trying to say - it will be a > lot of work merging the two whatever you do. > [...] Looking at the 0.90a maps, it looks as though 0.90a has removed omaps also. (My God, there is 20 Meg of maps now !!) > Frank *has* tried to use Purify, but he couldn't get it to > link... Let's hope you guys have more luck with it. > > > Kjetil T. Well, I've got crossfire built with Purify and I'm investigating now. Rupert -- Rupert G. Goldie, rgg@aaii.oz.au From crossfire-request Thu Feb 17 10:46:03 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Thu, 17 Feb 1994 10:45:54 +0100 Received: by bolero.rahul.net id AA26035 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 17 Feb 1994 01:45:50 -0800 Date: Thu, 17 Feb 1994 01:45:50 -0800 From: Mark Wedel Message-Id: <199402170945.AA26035@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Further notes about 0.90.1. Status: RO If you notice any problems with the distribution, let me know. I am now willing to take feature patches for the source, since this version looks at least reasonably stable. A few notes on patches: Please try to make sure the context diffs are compared to this latest version. If you make a context diff from crossfir 0.90.0 or crossedit 0.7, it might be a really pain for me to put it in, because so many things have changed. Diffs from versions earlier than that would be even worse. Also, if your patche re-located portions of the code, see if the portions that have been relocated have been changed. A lot of stuff has changed. Crossfire 0.90.2 (which will probalby come out in a few weeks assuming I get enough patches to warrant a new version) will more likely be a feature versions. New spells, new monsters, etc. One note about crossfire 0.90.1: IT is likely that save files from crossedit 0.7 can be used unmodified with 0.90.1. There are a few changes I am thinking of making: Change how flags are handled for objects. Instead of bit masks, have bit offsets, with just generic SET_FLAG, CLEAR_FLAG, and QUERY_FLAG macros. For the few macros that actually check several flags, they can make thos multiple checks in the program. (Or the present macro can be re-written.) Change spell learning. Modify it by 5% for level difference of the spell level and character level. This way, high level characters with very low wisdom could learn low level spells, and thos with high wisdom would have a difficult time learning spells that are 8 levels higher. Any other features people woudl like to see added? Any comments on the ones listed above? Mark Wedel master@rahul.net From crossfire-request Thu Feb 17 10:35:38 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Thu, 17 Feb 1994 10:35:34 +0100 Received: by bolero.rahul.net id AA25681 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 17 Feb 1994 01:35:29 -0800 Date: Thu, 17 Feb 1994 01:35:29 -0800 From: Mark Wedel Message-Id: <199402170935.AA25681@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Crossfire 0.90.1 released. Status: RO crossfire 0.90.1 is as I type this, being uploaded to the ftp site. It is being put in the incoming directory. Perhaps someone with the right access can move it to the directory above it. Here is a copy from thecrossfire-0.90.1.README file: There are three separate tar archives in the Crossfire 0.90.1 distribution. crossfire-0.90.1.tar.Z contains the actual program code, as well as premade archetype, bitmaps, and xpm files. crossfire-0.90.1.maps.tar.Z contains all the maps. The maps from crossfire 0.90.0 will not work, but ones from crossedit 0.7 may work. This is because crossfire 0.90.1 uses map paths, like crossedit 0.7 does. crossfire-0.90.1.arch.tar.Z contains the unpacked archetype (arch) directory. This file is not needed if you just want to compile the games and play. The contents of this archive is used to create the archetypes, bmaps, font, and X PixMap (XPM) files. You only need it if you want to add new archetypes, or mess around with the existing ones. Checksums (SunOs): 64772 643 crossfire-0.90.1.arch.tar.Z 26931 3200 crossfire-0.90.1.maps.tar.Z 33711 1334 crossfire-0.90.1.tar.Z Checksums (System V): 33264 1285 crossfire-0.90.1.arch.tar.Z 9399 6399 crossfire-0.90.1.maps.tar.Z 48477 2668 crossfire-0.90.1.tar.Z Mark Wedel master@rahul.net From crossfire-request Tue Feb 15 04:41:46 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Tue, 15 Feb 1994 04:41:44 +0100 Received: by bolero.rahul.net id AA01096 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Mon, 14 Feb 1994 19:41:41 -0800 Date: Mon, 14 Feb 1994 19:41:41 -0800 From: Mark Wedel Message-Id: <199402150341.AA01096@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Re: Is there anybody there? Status: RO Crossfire 0.90.1 will likely be released Tuesday or Wednesday (PST). I've pretty much just take the crossedit directory from crossedit 0.7 as used it to replace the crossedit directory in crossfire 0.90.0. This looks to work fine. the XPM patches are in 0.90.1. There are just a few bugs/things I want to make sure work properly before I release 0.90.1. I'll post a message after I actually put it on the ftp site. From crossfire-request Tue Feb 15 03:05:59 1994 Return-Path: Received: from beli.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Tue, 15 Feb 1994 03:05:58 +0100 From: Kjetil Torgrim Homme Received: from localhost by beli.ifi.uio.no ; Tue, 15 Feb 1994 03:05:58 +0100 Date: Tue, 15 Feb 1994 03:05:58 +0100 Message-Id: <19940215020558.15029.beli.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no Reply-To: crossfire-request@ifi.uio.no In-reply-to: Tero Kivinen's message of Fri, 28 Jan 1994 16:48:22 +0200 Subject: Re: Is there anybody there? Status: RO I've been going through mail, and have cleaned up most of the backlog for the mailing list. IF YOU WANT TO BE TAKEN OFF THE LIST, PLEASE REPLY TO THIS MESSAGE! I think this list can be used as a forum for both developers and players in the future like it has in the past. There's always the crossfire-announce list (so far never used! :-) for those with a casual interest in Crossfire. +--- Tero Kivinen: | I will try to look that as soon as I can get the code with my on red | zone memory allocator library (redzal). It will detect all access | outside mallocated area, and almost all random memory access. I | even found two malloc bugs from gcc with it. If you can tell as how | to get that bug occur it will make the finding it faster. +------- I believe no one ever said how to do this. Well, it is simple: Just enter a shop (so that a random artifact is generated). If you connect a new player, the classname will have changed to "horn" (i.e., if you specify the X resource "horn.name: foobar" it will "work"!) Mark - will your pixmap-patches be in 0.90.0? You said you were finished except for the editor some time ago - maybe you could release a 0.90.0a2 so we could help hunt bugs in the game itself? Kjetil T. From crossfire-request Mon Feb 14 06:24:40 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Mon, 14 Feb 1994 06:24:39 +0100 Received: from localhost (peterm@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id VAA22873 for crossfire@ifi.uio.no; Sun, 13 Feb 1994 21:24:34 -0800 Date: Sun, 13 Feb 1994 21:24:34 -0800 From: Peter Mardahl Message-Id: <199402140524.VAA22873@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: how are things going? Status: RO Is the merge going okay? I find myself itching to get my hands on a new source.... PeterM From crossfire-request Fri Feb 11 19:14:58 1994 Return-Path: Received: from Princeton.EDU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 11 Feb 1994 19:14:55 +0100 Received: from ponyexpress.Princeton.EDU by Princeton.EDU (5.65b/2.105/princeton) id AA24875; Fri, 11 Feb 94 12:43:50 -0500 Received: from rogue.Princeton.EDU by ponyexpress.princeton.edu (5.65c/1.113/newPE) id AA06250; Fri, 11 Feb 1994 12:43:50 -0500 Received: by rogue.Princeton.EDU (4.1/CS_101_Cluster_Client) id AA17587; Fri, 11 Feb 94 12:43:49 EST Message-Id: <9402111743.AA17587@rogue.Princeton.EDU> From: grweiss@phoenix.Princeton.EDU (Gregory R. Weiss) Date: Fri, 11 Feb 1994 12:43:49 EST X-Mailer: Mail User's Shell (7.2.2 3/2/90) To: crossfire@ifi.uio.no Subject: Crossfire v0.89.2 Status: RO I'm having real problems installing this game. My setup: SunOS Release 4.1.3 gcc 2.3.3 I first got errors while compiling that it couldn't find stdarg.h. After making a symbolic link to in in the crosfire/include directory, the program compiled cleanly, with just one or two warnings. The files compiled with the following options: gcc -ansi -Wall -O -pipe -I../include -I/usr/princeton/include -DFONTDIR=\"/u/grweiss/pub/crossfire/fonts/misc\" -DFONTNAME=\"crossfire\" -DLIBDIR=\"/u/grweiss/pub/crossfire/lib\" -target sun4 -c logger.c For the curious, crossfire -o shows the following options Non-standard include files: Secure: Logging: Libdir: /u/grweiss/pub/crossfire/lib Perm file: /forbid Shutdown file: /shutdown Save player: Save mode: 0600 Playerdir: /players Save homedir: Lock player: Use checksum: Tmpdir: /tmp Fontdir: /u/grweiss/pub/crossfire/fonts/misc Compress: /usr/ucb/compress Uncompress: /usr/ucb/uncompress Map timeout: 80 Map reset: 7200 Max objects: 3000 Use_calloc: Speed_game: Use_los: CD los: CHRFONT: Use_swap_stats: DM mail: grweiss@phoenix.princeton.edu Editor: /local/X11R5/bin/xterm -geometry 80x24+0+0 -e /usr/ucb/vi Server: Port: 13326 Max_time: 120000 SunOS rogue 4.1.3 1 sun4m ****************************************************************************** I have a number of problems. Right now, I'm just trying to run it from my account, without any multi-player features yet. When I run crossfire without the -pix option, it receives a SIGSEGV right away, before opening the X window. I have the Fontdir set to my crossfire/fonts/misc directory, and it contains the two files: -rw-r--r-- 1 grweiss 223760 Feb 11 11:20 crossfire.pcf -rw-r--r-- 1 grweiss 26 Feb 11 11:20 fonts.dir ****************************************************************************** Well, I can bypass that problem by using the -pix command-line option. When I start the game this way (crossfire -b -pix), I get the X window looking fine and dandy, and then I run into a dead end when it asks me: What is your name? :Greg That name is already in use. What is your name? :anything That name is already in use. What is your name? ... No name is acceptable and I can't go on without answering this question. I've tried removing and adding the SAVE_HOMEDIR and LOCK_PLAYER variables in include/config.h with no success. I was able to #undef SAVE_PLAYER and run the game (yea!) without the save file ability, but I've had no success with it. My current definitions: #define SAVE_PLAYER #ifdef SAVE_PLAYER /* The following have no meaning without SAVE_PLAYER */ #undef SAVE_HOMEDIR #undef LOCK_PLAYER #define USE_CHECKSUM /* #define ENABLE_CHECKSUM */ /* Will be default in distant future versions */ #endif #ifndef PLAYERDIR #define PLAYERDIR "players" #endif I do have a players directory in my lib directory: crossfire/lib/players, as well as in my home directory. ******************************************************************************* So, I tried using the -d and -debug command line options, which led to further problems: % crossfire -b -d -pix Welcome to CrossFire, v0.89.2, copyright (C) 1992 Frank Tore Johansen. Maintained locally by: grweiss@phoenix.princeton.edu Questions and bugs should be mailed to the above address. arch-pass 1...done Setting up archetable...done loading treasure...done arch-pass 2...done Reading bmaps...done (got 265704/836) Building ximages...done Opening add user socket on 0 SIGSEGV received. Emergency save: 5?|6 (failed) Cleaning up... The sigsegv arrived several seconds after finishing opening the add user socket and prompting me for a name, whether or not I typed anything. If I did manage to type in a name, it still didn't accept it, and it gave me no error messages on stderr or stdout. ****************************************************************************** With all these problems, I've had the same behavior when trying to run crossfire using crossfire -server and crossclient. I tried compiling with the USE_CALLOC; still the same problems. (One other thing that often crashed my no-save games; bashing destructible walls led to the server getting a SIGSEGV.) ****************************************************************************** Any help or advice you could give me would be appreciated. I acutally tried version 0.90 first, but I had problems with it, and since it was marked as "ALPHA", I decided to try 0.89.2. Unfortunately, that version wasn't much better. --Greg Weiss grweiss@phoenix.princeton.edu From crossfire-request Tue Feb 8 17:37:26 1994 Return-Path: Received: from dartvax.dartmouth.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Tue, 8 Feb 1994 17:37:23 +0100 Received: from dancer.Dartmouth.EDU by dartvax.dartmouth.edu (8.6.5.Beta11+DND/4.5HUB) id LAA00566; Tue, 8 Feb 1994 11:37:20 -0500 Message-id: <978065@dancer.Dartmouth.EDU> Date: 08 Feb 94 11:37:16 EST From: David.M.Fisher@Dartmouth.EDU (David M. Fisher) Subject: programming To: crossfire@ifi.uio.no Status: RO Hi. I sent in a request to get added to this list a while ago, and haven't received any mail... is there something wrong with the request handler, or the list or something? Just curious. I currently have a friend who is on the list send me the interesting stuff, but I'd like to get on the list for myself someday... Anyway, I'm really interested in doing some of the development for this game. I have some ideas on guilds, homes, castles and a cool thought on remote data... if the current programming group wants me to help, let me know... -Dave From crossfire-request Tue Feb 8 11:09:01 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Tue, 8 Feb 1994 11:08:57 +0100 Received: by bolero.rahul.net id AA11929 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Tue, 8 Feb 1994 02:08:46 -0800 Date: Tue, 8 Feb 1994 02:08:46 -0800 From: Mark Wedel Message-Id: <199402081008.AA11929@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Crossfire update. Status: RO Been doing a bit of work on the integration. It looks like right now the only portion I have left to do is the crossedit directory. Unfortunately, it looks like crossedit 0.7 and crossfire 0.90.0 have many changes, and there are also a lot of changes from the crossfire 0.89.3 distribution. Hopefully I can work out some good method to integrate them. I still have to track down a lot of bugs in the merged version, as well apply many patches that I have recieved. Hopefully, I can get the 0.90.1 version out in about a week. Here is a short list of people who said specifically that they want to be on the developement team, and what they have worked on. Jari Vanhala - re-did input handling (1) Peter Mardahl runes, new spells, changing of spell parameters, new archetypes Note 1: Due to the fact that the patches he submitted appeared to have been made for crossfire 0.89.2, and the fact that the crossedit 0.7/ crossfire 0.90.0 merge changed lots of things, these are not likely to be seen in crossfire 0.90.1 I believe some other people have said more casually that they plan on working on things. The main point of the developers list is to try and prevent duplicate efforts. No reason to have 4 people working on changing input handling, for example. Also, to some extent, these could be seen as the people who are the experts on that area of the code. Mark Wedel master@rahul.net From crossfire-request Sat Feb 19 11:15:16 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sat, 19 Feb 1994 11:15:15 +0100 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Sat, 19 Feb 94 11:13:51 +0100 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA17943; Sat, 19 Feb 94 11:15:12 +0100 Date: Sat, 19 Feb 94 11:15:12 +0100 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9402191015.AA17943@montefiore.ulg.ac.be> To: crossfire@ifi.uio.no Subject: client/server once again Status: RO Thanks to Mark (thanks again (and again!)), we now have a working version of CrossFire. Time to talk about the client/server problem once again... Here is a summary of what has been said on this list, with some ideas of my own thrown in: * The server will be responsible for all interactions between players and between each player and the map, monsters, and so on. * The client will only handle display-oriented stuff. * The client sends all commands issued by the user directly to the server, with almost no preprocessing (i.e. "move north", "eat food", "apply ..."). * The server periodically sends the following information to every client: - the current player position - modifications to the map, other players positions, monster positions - each time a new area of the map is entered, the server sends a map chunk (say, 10x10 or 30x30) to the client, with all the objects in it - the modifications to the inventory or player status * The client may handle the Line Of Sight algorithm. If one wants to cheat (using a drone, for example), he could do this even if the server only sends the visible bits to the client. This would only require a slightly more complex algorithm, but won't prevent nasty guys from doing it. So, why not do the LOS on the client side? This would free more processing power on the server. * We can have several clients, using different display techniques. We could even have a 3D-client (if you have ever played DOOM on a PC, you know what I'm talking about). This may be silly, but why not? I could start working on that as soon as 0.90.2 is stable. Any comments? -Raphael From crossfire-request Sat Feb 19 08:40:39 1994 Return-Path: Received: from plague.Berkeley.EDU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sat, 19 Feb 1994 08:40:38 +0100 Received: from monsoon.Berkeley.EDU by plague.Berkeley.EDU (5.65c/CHAOS) id AA25124; Fri, 18 Feb 1994 23:25:46 -0800 Message-Id: <199402190725.AA25124@plague.Berkeley.EDU> To: Tero Haatanen Cc: crossfire@ifi.uio.no, mehlhaff@plague.Berkeley.EDU Subject: Re: Map ideas In-Reply-To: Message from Tero Haatanen of Fri, 18 Feb 1994 19:47:25 +0200 <199402181747.TAA23235@cc.lut.fi> Date: Fri, 18 Feb 1994 23:25:42 -0800 From: "'Evil' ERic Mehlhaff" Status: RO Tero Haatanen recently wrote: >From: "'Evil' ERic Mehlhaff" > >> In all of the crossfire map setups I've seen, there's a _lot_ of 'closed' >> buildings and so on. I think it'd be cool to have all the empty city >> buildings and houses connect to a generic city/house/building map. > >No. I strongly disagree. Since all those generic/whatever just are >copies and noboby doesn't want to play ten times same house when >there is so many new maps. I prefer that all those closed exit are >removed from maps. And new houses were created when there is actual >some map where it leads. Currently seems that people first design >large areas and after that make few maps and most areas are just >empty. This isn't meant to be a flame, just my personal opinion. Well, I think it'd add a hell of a lot to the 'virtual space' of the world of corssfire. If you're concerned about people not knowing it's really just another boring 'generic' map, it'd be simple to have all the generic maps have an entrance message saying something like "You have just entered yet another boring house." It'd easy enough to turn off the usage of the generic maps from the server, I think it's worth doing. >About "." and "..". If we leave out generic maps, "." would be >shortcut for current map name and easy implement. ".." is an interest >idea, but not sure if needed. When the new area is joined to game >area you need edit exit leading in that area anyway, so another way >isn't that hard with current editor. And you probably want check >that area anyway. Let me show a prime example of where the '..' exit path would be useful. Peter here made up a really cool dungeon where its entrance level basically was a tower in the middle of a field. Ideally, you'd like to have a ring of exits completely around the tower, so that once players leave the tower on the map, no matter which way they go, they'll exit the map instead of reaching the edge of the map. To do this, you'd need a every exit square pointing to where the map actually exits to. If you want to link this map into a difference place in your crossfire world, you have to change every single one of these exits with the map editor. But if the exits pointed to "..", not a thing would have to be changed in the map file. Of course, you kludge the same effect -- have all the exits around the edge point to "." x 0 y 0, and then have a single exit in that corner that points to the real exit. But that's a real kludge and still requires map editing to move the map. Oh, did I mention that the 'generic map' thing could be used for encounter maps nicely? ERic mehlhaff, mehlhaff@ocf.Berkeley.EDU From crossfire-request Sat Feb 19 08:08:19 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sat, 19 Feb 1994 08:08:14 +0100 Received: by bolero.rahul.net id AA00541 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Fri, 18 Feb 1994 23:08:11 -0800 Date: Fri, 18 Feb 1994 23:08:11 -0800 From: Mark Wedel Message-Id: <199402190708.AA00541@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Map Guide. Status: RO Here is a document I wrote about, to hopefully be used as a determining fact of whether maps should be added or not. I may just start with the chico map set (Assuming they are all good), and then add the old maps as I found they meet these requirements. Also, many towns might be eliminated. Those towns being ones which have just the shops and a few actually places to adventure. Those other open buildings might then be accessible from other towns. So instead of having 10 towns, each with only 2 or 3 accessible buildings, have 1 town, with 20 interesting buildings. Please post any comments or suggestions you have about the above, or the guidelines below. --Mark This is a guide on what is an acceptable map and what is unacceptable. Only acceptable maps will be put in the official Crossfire map distribution 1) Check that all exits lead where they are supposed to. Unless there is a specific reason an exit leads only one direction (like a trap door or perhaps a teleporter), players should be able to exit back from where they came from right when they enter the map. One way exits/entrances should only be used on objects in which it is obvious it is one way. A house is not an obvious one way entrance. Remember, players may not have the three hours of time it takes to find the exit after being trapped in a map. 2) Try to make sure the maps are multi player accessible. In towns, this means the road should be at least a couple squares wide, buildings should not be trapped in corners in which case one character standing in front blocks access, etc. Likewise, try to make corridors in dungeons or mazes a few squares wide - especially if there is only a single path. If it is a maze with several different paths, single width corridors are acceptable. 3) Don't put extremely valuable treasure right next to the entrance, or nearby. Players should need to work to get treasure. If the treasure is fairly worthless (food, or non magical items), this would be acceptable. But a character shoudl not be able to pop in, pick up a potion, spellbook, or a loot of diamonds, and then pop out again, without ever meeting a monster. 4) Try to keep the treasure in line with the difficulty. 5 potions should not be given out for defeating orcs or gnolls (even if there are a lot of them), but if you need to defeat several dragons to get to the potions, that is fine. Likewise, if it is likely a lot of spells will be needed to defeat the monster, and those spells have a chance of destroying the items, then perhaps a few extra items to take this into consideration is not a bad idea. 5) Any character class should be able to complete solve the map. The map should not require dimension door or other specific spells to get into hidden treasure areas 6) If a map require multiple players to simultaneous be on it to solve the map, put a sign or message so players know. Such maps would be those that require manipulation of levers or buttons in certain sequences in order to get through gates. 7) Try not to make the maps too many levels deep. To get to the goal, it should not require a 6 hour continous sitting, as the player works through each map to get to the next. Multi level maps are fine - just don't over do it. 8) Don't put super stores in any towns or villages you create. With the growing number of maps, players can already make a trip to all the different towns to try and find certain items. A one stop find all shop is not interesting. A good maximum size is about the same size of the shops in the starting village. Also, making six magic shops of that size and putting them in the same town is not any better than one large magic shop. If you want to have specialized shops, then make each shop smaller. If you just want one shop that sells every type of item (magic, armor, weapons, food, etc), then a large shop is permissable. 9) Make sure the entire interior the shop is covered with tiles. Likewise, don't put shops that lead areas without tiles without going over one of the 'magic doormats'. A player should never be able to get an unpaid item out of a shop, whether via exit that does not go over the magic doormat, or through spells. 10) Don't make maps which require high level characters that low level characters can wonder into without warning. Putting a warning sign nearby, or gates or doors so the player can see they are in over their head, instead of instantly getting toasted the second they enter the map. The following are various suggestions for making good or interesting maps. A map that does not need to follow all these hints to be accepted, but following these hints will make for more interesting or playable maps. 1) Try to create only small maps. If you have a large map in mind, try to see if you can possible split it up in several separate sections, and place those sections in different maps. Many small maps use much less memory than one large map, since crossfire doesn't yet support swapping of portions of maps. Also, with small maps, the time to load it from and store it to disc becomes so short that it's impossible to notice. In this context, small means about 32x32, though it's actually the number of objects in the map which count. Also, remember that if you make very large maps, all generators will be cranking out monsters whenever anyone is on it. This could mean that a lot of monsters have been generated before a player even gets to the area where they are being created. 2) Make a plot! A map withot a plot becomes just another mindless "Kill'em all". For instance, create a story which explains why there are npc's here and monsters there, fragment the story up and put bits and hints of it in various writables (books) and npc-conversations. If you are going to make a mindless kill them all map, at least put some reward in the map that can only be accessed after all the monsters have been killed. The only thing worse than a kill them all map is a kill them all map which you get nothing out of. 3) Make puzzles! Use all those different object types: buttons, handles, doors, altars, pedestals, triggers, timed gates, etc... Hide special "keys" needed to get further in special places, and use text-puzzles to describe where they are hidden and how they must be used. The possibilities are endless! Remember, you can also hide buttons under floors, making it more difficult for the character to find the trigger points. 4) Give the npc's information! An npc's knowledge about hidden treasure surelymakes it interesting to have a conversation with it. 5)Feel free to add some traps, but be careful to not make them too deadly without adequate warning. 6) Don't mix the monsters too badly. Let there be at least some logic behind why they are grouped in a single room. Undeads together with undeads, for instance, but not together with kobolds... Big dragons usually don't live together with mice... Fire immune creatures generally dislike ice immune creatures. Also, limit use of monsters that multiply rapidly (mice, slimes). A map that is easily overwhelmed with these creatures quickly becomes useless. From crossfire-request Sat Feb 19 01:05:20 1994 Return-Path: Received: from po.EECS.Berkeley.EDU by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 19 Feb 1994 01:05:18 +0100 Received: from localhost (peterm@localhost) by po.EECS.Berkeley.EDU (8.6.4/8.6.4) id QAA28232; Fri, 18 Feb 1994 16:05:19 -0800 Date: Fri, 18 Feb 1994 16:05:19 -0800 From: Peter Mardahl Message-Id: <199402190005.QAA28232@po.EECS.Berkeley.EDU> To: master@rahul.net, njw@cs.city.ac.uk Subject: Re: more on spells Cc: crossfire@ifi.uio.no, mehlhaff@plague.Berkeley.EDU Status: RO Regarding Nick's proposed change to the spell system: >It would be nice at some point if the spells were not hardcoded, >allowing people to create new spells on the fly: you could link with This is a very interesting idea, and suggests some very nice abstractions. The spell system "as is" is very inflexible--my addition of a spell_parameters file is perhaps a step in the right direction and perhaps not. Instead of everyting having to do with spells being in the archtypes and the code, it's in the archetypes, the code, and in the spell_parameters file. The spell_parameters file is more convenient to change, but adding new things becomes somewhat more cumbersome--but I wander. You're basically proposing the creation of a little language of magic which causes spell effects. That's not trivial, but we at berkeley have already made one step in that direction. We've made two spells which accept parameters: cast reincarnate < whomever>, and cast magic rune < whatever spell you fancy>. This allows a player to make a magic rune of any spell around, provided he knows it, and has the spellpoints to cast both that spell the magic rune spell. For example, I've often wished for an area effect cold spell similar to fireball. 'cast ball cold ', 'cast ball fire' , 'cast ball shock' .... That'd triple the number of possible spells at very moderate coding expense. bolt and cone commands would also be nice. >With such a "on-the-fly" spell idea, the learning of spells becomes more >interesting. You can have cantrips which are common spells known all We should postpone such a system to after server/client split. It has interesting aspects. The system should above all not be cumbersome to use. Having to type too many keystrokes to ready a spell is fatal. Regards, PeterM From crossfire-request Sat Feb 19 01:02:58 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sat, 19 Feb 1994 01:02:55 +0100 Received: by bolero.rahul.net id AA12544 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Fri, 18 Feb 1994 16:02:47 -0800 Date: Fri, 18 Feb 1994 16:02:47 -0800 From: Mark Wedel Message-Id: <199402190002.AA12544@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Re: Further notes about 0.90.1. Status: RO I think the actual complaint was in the .arc file and the field names. Not how the program handles it internally. There is certainly nothing preventing more useful field names in the archetypes structure. Crossfire could then know that something like 'charges' in a archetype descritpion actually goes into the food field in the structure. Unions of the object structure might be a good idea, but would require going over the code very closely, to make sure that for a sword object you are accessing the correct field names (or for wand arcehtype, that you are accessing the charges field, and not the food field.) A 'nicer' idea that exists in C++ is anonymous unions. But I don't think we want to require a C++ compiler just for anonymous unions. --Mark From crossfire-request Sat Feb 19 00:30:25 1994 Return-Path: Received: from po.EECS.Berkeley.EDU by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 19 Feb 1994 00:30:21 +0100 Received: from localhost (peterm@localhost) by po.EECS.Berkeley.EDU (8.6.4/8.6.4) id PAA24476 for crossfire@ifi.uio.no; Fri, 18 Feb 1994 15:30:13 -0800 Date: Fri, 18 Feb 1994 15:30:13 -0800 From: Peter Mardahl Message-Id: <199402182330.PAA24476@po.EECS.Berkeley.EDU> To: crossfire@ifi.uio.no Subject: Berkeley hacks Status: RO ERic gave a good description of the berkeley hacks and spells. Other things we've done include: more experience needed per level after level 10 and the addition of the ability to change spell parameters on the fly by reading a spell_parameters file. It's a file of the form: ... Spells not mentioned in this file use the compiled-in defaults. I've redone spells.c and some other sections of code so that the DM may redefine the following parameters on the fly, while the server is running, by the DM command 'spellreset'. This ability allows the server God to balance spells easily. level -- spell level sp -- spellpoints used by spell bdam -- base damage done by spell bdur -- base duration or range of spell ldam -- parameter defining the level dependency of the damage (basically used by a formula to compute a bonus to bdam) ldur -- like ldam except having to do with durations, or ranges. Unfortunately, there are hordes of special cases. For summoning spells, like summon elemental, bdur is how many hitpoints the summoned creature has, and bdam is how much damage that creature does when it attacks. However, I've documented all the special cases: that will come with the patches. bdur ==> base range for many spells. Regards, PeterM From crossfire-request Fri Feb 18 21:51:03 1994 Return-Path: Received: from dartvax.dartmouth.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 21:51:02 +0100 Received: from dancer.Dartmouth.EDU by dartvax.dartmouth.edu (8.6.5.Beta11+DND/4.5HUB) id PAA27999; Fri, 18 Feb 1994 15:51:01 -0500 Message-id: <1305556@dancer.Dartmouth.EDU> Date: 18 Feb 94 15:50:55 EST From: David.M.Fisher@Dartmouth.EDU (David M. Fisher) Subject: Re: various ideas... To: crossfire@ifi.uio.no Status: RO Okay, there seems to be enough interest and response to this particular question, so I am going to give it another day or so and then summarize the suggestions, give my reactions/rebuttals/etc, and send it to the list... -Dave From crossfire-request Fri Feb 18 21:32:56 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 21:32:54 +0100 Received: from localhost (philb@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id MAA02330; Fri, 18 Feb 1994 12:32:40 -0800 From: Philip Brown Message-Id: <199402182032.MAA02330@soda.berkeley.edu> Subject: Re: Further notes about 0.90.1. To: mehlhaff@ocf.berkeley.edu ('Evil' ERic Mehlhaff) Date: Fri, 18 Feb 1994 12:32:38 -0800 (PST) Cc: kivinen@joker.cs.hut.fi, mehlhaff@ocf.berkeley.edu, crossfire@ifi.uio.no, mehlhaff@plague.Berkeley.EDU In-Reply-To: <199402181532.AA02970@plague.Berkeley.EDU> from "'Evil' ERic Mehlhaff" at Feb 18, 94 07:32:10 am X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 658 Status: RO >>>>[From 'Evil' ERic Mehlhaff] I agree. I was always annoyed by the fact that certain fields in the object fields meant something totally weird in the actual game. I like the fact that the files were all in text. It shouldn't be hard to make things like 'exit_to' mean the same thing as 'slaying' to the parser, "unions GOOD" [And for those of you who aren't eric :-) that obviously (:->) translates to: objects should be stored as unions, thaT have different field names depending on what type they are. As long as the object type is defined first in a text block, there is no problem readingf in arbitrary type objects.] From crossfire-request Fri Feb 18 21:31:25 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id ; Fri, 18 Feb 1994 21:31:20 +0100 Received: from localhost (peterm@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id MAA02150; Fri, 18 Feb 1994 12:31:16 -0800 Date: Fri, 18 Feb 1994 12:31:16 -0800 From: Peter Mardahl Message-Id: <199402182031.MAA02150@soda.berkeley.edu> To: crossfire@ifi.uio.no, kjetilho@ifi.uio.no Subject: Re: active walls Status: RO Active walls can only use spells which use the 'fire arch' routine. I want to make it so that they can use any spell at all, not just spells like firball and bullet and lightning. (I mean cone spells.) PeterM From crossfire-request Fri Feb 18 18:47:30 1994 Return-Path: Received: from cc.lut.fi by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 18:47:27 +0100 Received: from localhost (haatanen@localhost) by cc.lut.fi (8.6.5/8.6.5/1.12.kim) id TAA23235; Fri, 18 Feb 1994 19:47:25 +0200 (for crossfire@ifi.uio.no) From: Tero Haatanen Message-Id: <199402181747.TAA23235@cc.lut.fi> Subject: Map ideas To: crossfire@ifi.uio.no Date: Fri, 18 Feb 1994 19:47:25 +0200 (EET) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2709 Status: RO From: David.M.Fisher@Dartmouth.EDU (David M. Fisher) > 1) Player information directories, not just a file. These can be saved in player file. Just add a few field in players struct. When players become normal archetypes, idea was that it easy to customize every class and it's not hard add this customization to individual level. Note that allowing players set their hometown during the game is a very nice idea indeed. Only problem is that you have to have some kind of control where you can change your home, so you don't teleport treasure chamber every time you read word of recall :) > 2) About the player's home: I have had similar thougth, but my idea was that there are different type maps. So maps could have no-reset flag, so in those maps would not reset between games and all items would be saved also. Rooms could be designed so that there are gate and button, and button is activated by players name. Players could buy theirs rooms dropping gold some altar like item, which would connect button to players name. So thiefs has their changes :). BTW. Currently buttons can be activated by players class. These maps could be saved in own directory. The only problem is multiple servers using same maps same time. I don't like idea that player could set his home everywhere, better use normal maps and forget all symlink hacks. From: "'Evil' ERic Mehlhaff" > In all of the crossfire map setups I've seen, there's a _lot_ of 'closed' > buildings and so on. I think it'd be cool to have all the empty city > buildings and houses connect to a generic city/house/building map. No. I strongly disagree. Since all those generic/whatever just are copies and noboby doesn't want to play ten times same house when there is so many new maps. I prefer that all those closed exit are removed from maps. And new houses were created when there is actual some map where it leads. Currently seems that people first design large areas and after that make few maps and most areas are just empty. This isn't meant to be a flame, just my personal opinion. About "." and "..". If we leave out generic maps, "." would be shortcut for current map name and easy implement. ".." is an interest idea, but not sure if needed. When the new area is joined to game area you need edit exit leading in that area anyway, so another way isn't that hard with current editor. And you probably want check that area anyway. Those encounter maps are interesting and I like them. Makes you little careful when moving outside world. But maybe there could be some flag in map which tells if map use encounter maps, so if you have small garden it would not expand the whole forest :). -Tero From crossfire-request Fri Feb 18 17:48:20 1994 Return-Path: Received: from gyda.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 17:48:19 +0100 Received: from modeemi.modeemi.cs.tut.fi by gyda.ifi.uio.no ; Fri, 18 Feb 1994 17:48:18 +0100 Received: from modeemi (jam@localhost [127.0.0.1]) by modeemi.modeemi.cs.tut.fi (8.6.4/8.6.4) with SMTP id SAA20460; Fri, 18 Feb 1994 18:42:31 +0200 Message-Id: <199402181642.SAA20460@modeemi.modeemi.cs.tut.fi> X-Authentication-Warning: modeemi.modeemi.cs.tut.fi: Host localhost claimed to be modeemi To: David.M.Fisher@Dartmouth.EDU (David M. Fisher) cc: crossfire@ifi.uio.no, master@rahul.net Subject: Re: various ideas... In-reply-to: Your message of "17 Feb 1994 22:10:19 EST." <1283533@dancer.Dartmouth.EDU> Date: Fri, 18 Feb 1994 18:42:29 +0200 From: Jari Vanhala Status: RO David M. Fisher writes: >I've had a few ideas about some aspects of crossfire, and I was wondering if >anyone has done work on them, or if perhaps the group decided they were >infeasible, etc. > >1) Player information directories, not just a file. In this directory would >be: [clip] How about this: - Every player have one 'family' (all characters under it have same surname, like Vanhala) - make directory with surname - in directory is savefiles for various characters (like Jam, Jari), general data (like keys, desc,...) and possible home-map - only one character of family can be in game - login asks fullname to resolve character >2) About the player's home: [clip] Make 'Portable home kit'-item and applying that makes house (exit that leads to home-map) at allow-home -place (home-plane -map?). ++Jam From crossfire-request Fri Feb 18 17:20:35 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 17:20:33 +0100 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Fri, 18 Feb 94 17:19:08 +0100 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA14648; Fri, 18 Feb 94 17:20:24 +0100 Date: Fri, 18 Feb 94 17:20:24 +0100 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9402181620.AA14648@montefiore.ulg.ac.be> To: David.M.Fisher@Dartmouth.EDU, crossfire@ifi.uio.no Subject: Re: various ideas... Status: RO > From: David.M.Fisher@Dartmouth.EDU (David M. Fisher) > > 1) Player information directories, not just a file. In this directory would > be: > - the normal player data file > - a link to what the player considers "home" (where he/she goes with the > word of recall spell, and possibly other things) Why do you want to create a directory? You can put all this stuff in a regular file (extra field(s) in the player data file). IMHO, this is safer to put the link to the map in field of the player file than to use a (symbolic) link. This is easier to check for errors, invalid relative paths and so on if the server can control the reference to the map. > - a description file, that is editable by the player. This would allow > life stories and interesting thoughts, promoting a little more > individualization. Sort of like a .sig/.plan./.project all rolled into > one... > Cool idea. There should be some commands in the client to allow for such editing. I don't like to have it in a separate file, for two reasons: - if one plays from a distant host using a crossfire client, he probably cannot access the file directly. - having a player edit the file directly could create some problems for security-conscious people :-) > > 2) About the player's home: > > For low-level players, this could just be a room at an inn or some such. > Improvements might be things like a room in your guild (if you have one), > your own house in town, a castle, etc. All you'd need in the player > directory would be a link to the appropriate spot, so that shouldn't be too > difficult. The rest of it would be normal map stuff. There might be some > issues regarding whether other players are allowed into that room or not, or > any costs the player might bear for having a room, etc. > > I'd be willing (even anxious!) to work on this stuff, but I don't want to get > started just to find out that it was considered not part of the game or some > such thing... > This is very interesting. But how will you prevent the thieves from sneaking in the other players' homes? -Raphael From crossfire-request Fri Feb 18 17:11:39 1994 Return-Path: Received: from thrall.cm.cf.ac.uk by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 17:11:34 +0100 Received: from cm.cf.ac.uk by thrall.cm.cf.ac.uk with SMTP (PP) id <27640-0@thrall.cm.cf.ac.uk>; Fri, 18 Feb 1994 16:12:49 +0000 Date: Fri, 18 Feb 94 16:12:45 GMT From: Simon McIntosh-Smith Message-Id: <9402181612.AA26161@garnet.cm.cf.ac.uk> To: crossfire@ifi.uio.no Subject: source for new spoilers? Status: RO > Compiling the game was *very* easy indeed. I still needed one patch > which I mentioned before. In common/tempnam.c it has in two places > an #if !defined(MACH) to decide to use sprintf() or snprintf(). > Well, my NeXT (black) is mach, but has no snprintf(), so I changed > this to I'll go along with this - compiled with ease, all I had to do was change each imakefile to tell them where our X11R5 is - we are still on X11R4! > Compiling crossedit flailed miserably. Lots of header file errors, > probably related to POSIX stuff. I'll be pouring over that stuff to > try to figure it out. If anyone else on a NeXT gets this to compile, > I would appreciate any hints on what they did to get it to work. Again, same here. I gave up seeing as crossfire itself was OK. The other thing I'd like to see is the installation actually doing itself: 1. create an empty highscore file if it doesn't exist 2. create a players subdirectory if it doesn't exist etc - I always have to go and do these things by hand, and I always forget to do them until I've tried to play the new version and then it messes up! On the source for the new spoilers (which look great by the way!), I want to make them available on the WWW by latex2html'ing them, but I've only got the postscript not the .tex files. Can whoever has these mail me a copy? You can already get to the postscript spoilers at the following URL: http://www.cm.cf.ac.uk:/Fun/ ta Sy From crossfire-request Fri Feb 18 17:01:38 1994 Return-Path: Received: from bera.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 17:01:37 +0100 From: Kjetil Torgrim Homme Received: from localhost by bera.ifi.uio.no ; Fri, 18 Feb 1994 17:01:37 +0100 Date: Fri, 18 Feb 1994 17:01:37 +0100 Message-Id: <19940218160137.19359.bera.ifi.uio.no@ifi.uio.no> To: crossfire Subject: Unsubscribing Status: RO I've gotten some unsubscriptions now that discussion is soaring to new levels :-). I just thought I'd remind you that you can drop out of this discussion list, but stay on the announcements list. If so, you must explicitly say you want to stay on the announcements list when you unsubscribe. Kjetil T. From crossfire-request Fri Feb 18 16:32:33 1994 Return-Path: Received: from cc.lut.fi by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 16:32:32 +0100 Received: from localhost (haatanen@localhost) by cc.lut.fi (8.6.5/8.6.5/1.12.kim) id RAA18997; Fri, 18 Feb 1994 17:32:31 +0200 (for crossfire@ifi.uio.no) From: Tero Haatanen Message-Id: <199402181532.RAA18997@cc.lut.fi> Subject: Re: active walls To: crossfire@ifi.uio.no Date: Fri, 18 Feb 1994 17:32:31 +0200 (EET) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 995 Status: RO From: Kjetil Torgrim Homme > I think the code is already there. Active walls are called FIREWALL in > define.h. Just edit the "other_arch" and "face" variables with > Crossedit. To make it easy to use, make a new pick-map. You can do > amazing things by changing the variables on each object :-) Yes, that true. look archetype lightningwall_t which can be used with triggers. You really need only one archetype for different wall type and could set direction with the crossedit. The animation handles the correct face. The reason why those were left in game was the backward compability and it is easier for mapmakers (atleast a little bit ;). It's still a good idea to reduce unneedeed acrhetypes. One place where I have used modified firewall is /th/island map, where volcano 'casts' firewalls :). If someone wants to look at it, entrance is in Sodoma called something like 'New Isle Voyage'. BTW. return map should be '/sodoma/sodoma' instead of '../sodoma' -Tero From crossfire-request Fri Feb 18 16:40:49 1994 Return-Path: Received: from plague.Berkeley.EDU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 16:40:44 +0100 Received: from bigbang.Berkeley.EDU by plague.Berkeley.EDU (5.65c/CHAOS) id AA02970; Fri, 18 Feb 1994 07:32:16 -0800 Message-Id: <199402181532.AA02970@plague.Berkeley.EDU> To: Tero Kivinen Cc: "'Evil' ERic Mehlhaff" , crossfire@ifi.uio.no, mehlhaff@plague.Berkeley.EDU Subject: Re: Further notes about 0.90.1. In-Reply-To: Message from Tero Kivinen of Fri, 18 Feb 1994 14:39:48 +0200 <199402181239.AA29028@cardhu.cs.hut.fi> Date: Fri, 18 Feb 1994 07:32:10 -0800 From: "'Evil' ERic Mehlhaff" Status: RO Tero Kivinen recently wrote: >"'Evil' ERic Mehlhaff" writes: >> I see this working is that in the archetypes, you can specify something in >> their entrance (slaying) field for whatever, say /generic/house. If, in > >When I tried to create some items it was very annoying because every >field is used for so many different things. It would be quite easy to >add some more keywords to archtypefile parser so it could contain >different keywords for all different things and parser would then put >the stuff after keyword to some field in archtype-structure. Parser >could also check that any of the fields is'nt set twice etc. There >should at least be some kind of document of all those different >settings you can set for different kind of objects. Perhaps there >should be better "language" to define archtypes, maps etc. I agree. I was always annoyed by the fact that certain fields in the object fields meant something totally weird in the actual game. I like the fact that the files were all in text. It shouldn't be hard to make things like 'exit_to' mean the same thing as 'slaying' to the parser, and we'd have the added benefit of not needing to translate the maps and archetypes if an exit_to field in the actual object structs gets made later on. And, values like 'last_sp' have totally nonintuitive meanings in things like weapons and armour. Documentation on what they mean would be really nice. I've added a few in our local crossire.doc -- I'll post it if people want it -- unless someone's got a real complete version floating around somewhere... ERic mehlhaff, mehlhaff@ocf.Berkeley.EDU From crossfire-request Fri Feb 18 16:20:55 1994 Return-Path: Received: from dartvax.dartmouth.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 16:20:50 +0100 Received: from fermat.dartmouth.edu by dartvax.dartmouth.edu (8.6.5.Beta11+DND/4.5HUB) id KAA19116; Fri, 18 Feb 1994 10:20:29 -0500 Received: by fermat.dartmouth.edu (NX5.67d/NX3.0S) id AA03592; Fri, 18 Feb 94 10:21:36 -0500 Date: Fri, 18 Feb 94 10:21:36 -0500 From: Michael Glenn Message-Id: <9402181521.AA03592@fermat.dartmouth.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: HELLO!@ Status: RO > First off! MARK! you did a GREAT job with the merge......I > have never had it compile so easily! :> Glad to see the > build World is fixed again :> I'll reiterate this. :) Great job. Very happy to see things moving along again at a good pace. Compiling the game was *very* easy indeed. I still needed one patch which I mentioned before. In common/tempnam.c it has in two places an #if !defined(MACH) to decide to use sprintf() or snprintf(). Well, my NeXT (black) is mach, but has no snprintf(), so I changed this to #if !defined(MACH) || defined(NeXT) What did other NeXT people do for this? Or did they undefine MACH? The only other problem I encountered was with libXpm. The one on my machine has no XpmCreatePixmapFromBuffer() function in it, so I couldn't use the XPM_PIX. I guess I'll have to get the Xpm stuff from the ftp sites... Compiling crossedit flailed miserably. Lots of header file errors, probably related to POSIX stuff. I'll be pouring over that stuff to try to figure it out. If anyone else on a NeXT gets this to compile, I would appreciate any hints on what they did to get it to work. Happy crossfiring! Michael (admin of server at fermat.dartmouth.edu) From crossfire-request Fri Feb 18 15:58:13 1994 Return-Path: Received: from cc.lut.fi by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 15:58:10 +0100 Received: from localhost (haatanen@localhost) by cc.lut.fi (8.6.5/8.6.5/1.12.kim) id QAA17432; Fri, 18 Feb 1994 16:58:09 +0200 (for crossfire@ifi.uio.no) From: Tero Haatanen Message-Id: <199402181458.QAA17432@cc.lut.fi> Subject: Buttons and triggers To: crossfire@ifi.uio.no Date: Fri, 18 Feb 1994 16:58:09 +0200 (EET) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1194 Status: RO From: Tyler Van Gorder > (also a small note: It seems kinda silly to have a "trigger button" and a > regular button. As it was in crossfire.89.3, a trigger button connected to a > non-trigger door would not open that door...maybe we should make this more > generic.....so you dont have to worry if your using the right type of button. > ) Yes, that's my fault :). Reason was that 'normal' buttons, gates and handles were very state specific. So that when player turns handle it also pushes button down and that was effect that I didn't want to triggers have. I thougth fixing buttons so that they could work together, but it would cause some maps stop working, so I leave them alone. And mixing normal button and triggers can cause strange effects (OK. It's mapmaker resbonsibility check those maps.) If someone fix those, please make it so that gate has count how many buttons/handles must be turned before gate opens, so that you don't need use 'firewall burns scroll above button' hacks :). And gate's animation probably needs to be changed in client/server so that could be done also now :). I could do it myself, but I don't probably have time :( -Tero From crossfire-request Fri Feb 18 14:50:19 1994 Return-Path: Received: from barney.cs.city.ac.uk by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 14:50:16 +0100 Received: from wilma.cs.city.ac.uk by barney.cs.city.ac.uk; Fri, 18 Feb 1994 13:53:15 GMT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.wilma.cs.city.ac.uk.sun4.41 via MS.5.6.wilma.cs.city.ac.uk.sun4_41; Fri, 18 Feb 1994 13:48:54 +0000 (GMT) Message-Id: Date: Fri, 18 Feb 1994 13:48:54 +0000 (GMT) From: Nick Williams Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: David.M.Fisher@Dartmouth.EDU (David M. Fisher), "'Evil' ERic Mehlhaff" Subject: Re: various ideas... Cc: crossfire@ifi.uio.no, master@rahul.net, mehlhaff@plague.Berkeley.EDU In-Reply-To: <199402181138.AA29129@plague.Berkeley.EDU> References: <199402181138.AA29129@plague.Berkeley.EDU> Status: RO Excerpts from games.Crossfire: 18-Feb-94 Re: various ideas... 'Evil' E. Mehlhaff@ocf.b (2688) > I'd also like to see the starting position different from recall position, > or even let people choose from a list of starting positions. > Then you could start new players, say, in the 'beginners' map, to cut back > on new player confusion. I tried this a bit on our server on scotch (now > defunct :-( ). I have patches to do this based on character class: different classes of character start in different places (defined by the slaying field in the character's archetype). Very trivial patch which worked rather well, methinks. I had the mages and wizards starting in the Wizards Guild, the priests and clerics starting off in a church, etc. I'll dig out my patch, work it out w.r.t 0.90.* and send it in... Nick Williams E-mail: njw@cs.city.ac.uk (MIME and ATK) Systems Architecture Research Centre, Tel: +44 71 477 8551 London, EC1V 0HB Fax: +44 71 477 8587 From crossfire-request Fri Feb 18 14:47:05 1994 Return-Path: Received: from barney.cs.city.ac.uk by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 14:47:03 +0100 Received: from wilma.cs.city.ac.uk by barney.cs.city.ac.uk; Fri, 18 Feb 1994 13:50:32 GMT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.wilma.cs.city.ac.uk.sun4.41 via MS.5.6.wilma.cs.city.ac.uk.sun4_41; Fri, 18 Feb 1994 13:46:10 +0000 (GMT) Message-Id: Date: Fri, 18 Feb 1994 13:46:10 +0000 (GMT) From: Nick Williams Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Mark Wedel , "'Evil' ERic Mehlhaff" Subject: more on spells Cc: crossfire@ifi.uio.no, mehlhaff@plague.Berkeley.EDU In-Reply-To: <199402181129.AA29014@plague.Berkeley.EDU> References: <199402181129.AA29014@plague.Berkeley.EDU> Status: RO It would be nice at some point if the spells were not hardcoded, allowing people to create new spells on the fly: you could link with tcl or somesuch and define a language for spell effects and then allow users to create spells of their own, or to learn new spells by reading them from one-off books (which could be accidentally destroyed). With such a "on-the-fly" spell idea, the learning of spells becomes more interesting. You can have cantrips which are common spells known all over the place: things you may find in spell scrolls for instance. And then more interesting spells would be on specific magic books which are guarded or hidden. You could also teach spells to other players, or enscribe a scroll or book with a spell to give to other people. Perhaps wizards/mages could keep spellbooks in which they transcribe all of the spells/cantrips they learn and on death, other people might find the spellbooks with all the different spells in. This would require spellbooks to contain a list of spells in contrast to scrolls which contain a single spell (much more realistic methinks). Then spellbooks would become rare artifacts, which should also have some sort of protection (using the berkeley rune code) attached to them. Attempting to read a spellbook where the rune has not been deactivated in the correct way would trigger the rune's effects (typically fireball or somesuch). example: book of fire spells: containing all sizes of fireball, firewall generation, protection from fire, etc. Book of Iff: contains all the spells known by Iff. This sounds like a pretty excellent idea to me, with not too much modification to be done as it relies on simple enhancements to current code: allowing runes to being applied to objects; providing different mechanisms for deactivating runes; ability to transcribe a spell is a simple patch onto an object, "teaching" spells would work in an identical manner; enhancing spellbooks to have multiple spells. The runtime addition of new spells could be done at a later point, when the distributed stuff was built in, as it would need to be there anyhow (e.g. client connects to server which knows a spell you've never heard of...). Comments? Nick Williams E-mail: njw@cs.city.ac.uk (MIME and ATK) Systems Architecture Research Centre, Tel: +44 71 477 8551 London, EC1V 0HB Fax: +44 71 477 8587 From crossfire-request Fri Feb 18 13:40:11 1994 Return-Path: Received: from cardhu.cs.hut.fi by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 13:40:09 +0100 Received: by cardhu.cs.hut.fi id AA29028 (5.65c8/HUTCS-C 1.3 for crossfire@ifi.uio.no); Fri, 18 Feb 1994 14:39:48 +0200 Date: Fri, 18 Feb 1994 14:39:48 +0200 Message-Id: <199402181239.AA29028@cardhu.cs.hut.fi> From: Tero Kivinen To: "'Evil' ERic Mehlhaff" Cc: crossfire@ifi.uio.no Subject: Re: Further notes about 0.90.1. In-Reply-To: <199402181129.AA29014@plague.Berkeley.EDU> References: <199402170945.AA26035@bolero.rahul.net> <199402181129.AA29014@plague.Berkeley.EDU> Organization: Helsinki University of Technology/Lifelong Learning Institute Dipoli Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Status: RO "'Evil' ERic Mehlhaff" writes: > I see this working is that in the archetypes, you can specify something in > their entrance (slaying) field for whatever, say /generic/house. If, in When I tried to create some items it was very annoying because every field is used for so many different things. It would be quite easy to add some more keywords to archtypefile parser so it could contain different keywords for all different things and parser would then put the stuff after keyword to some field in archtype-structure. Parser could also check that any of the fields is'nt set twice etc. There should at least be some kind of document of all those different settings you can set for different kind of objects. Perhaps there should be better "language" to define archtypes, maps etc. -- Tero_Kivinen@hut.FI Work : +358-0-451 4032 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-0-502 1573 From crossfire-request Fri Feb 18 12:46:40 1994 Return-Path: Received: from joyce.cs.su.OZ.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 12:46:36 +0100 Message-Id: <19940218114636.14157.ifi@ifi.uio.no> Received: from orthanc.cs.su.OZ.AU by joyce.cs.su.OZ.AU (mail from ftww for crossfire@ifi.uio.no) with MHSnet (insertion MHSnet site: basser.cs.su.oz.au); Fri, 18 Feb 1994 22:46:13 +1100 Subject: Re: plural archetype names. To: crossfire@ifi.uio.no Date: Fri, 18 Feb 1994 22:46:06 +1100 (EST) From: "Fred the Wonder Worm" 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: 1470 Status: RO > "Fred the Wonder Worm" writes: > >OK, that works. But when do you need to say "No gauntlets of cherry picking" > >or whatever? > > >wear gauntlets of cherry picking > You have no gauntlets of cherry picking. > Instead of > You don't have that. > > Gauntlets is a terrible example, as it is plural already. > > >wield sword > You have no swords. > Instead of > What? But in that case, there is no object to look up the plural_name field for. All that's happening is some attempt at pluralising an abitrary noun phrase. The query_name function takes an object, and returns the object's name prefixed with the appropriate count. When the count is 0, the suggestion is that it should return "No ". e.g. "No gauntlets of cherry picking". What I'm trying to figure out is what sort of situation would be needed to have that use of query_name make sense. As a side-issue, I thought objects which had a nrof field of 0 were 'non-grouping' objects; that is, two of them would still occupy separate inventory slots. In that case, the issue can never arise, as a 0 would really mean that there was 1 of them there after all. Cheers, Geoff. ------------------------------------------------------------------------------- Geoff Bailey (Fred the Wonder Worm) | Programmer by trade -- ftww@cs.su.oz.au | Gameplayer by vocation. ------------------------------------------------------------------------------- From crossfire-request Fri Feb 18 12:42:07 1994 Return-Path: Received: from plague.Berkeley.EDU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 12:40:57 +0100 Received: from bigbang.Berkeley.EDU by plague.Berkeley.EDU (5.65c/CHAOS) id AA29129; Fri, 18 Feb 1994 03:38:39 -0800 Message-Id: <199402181138.AA29129@plague.Berkeley.EDU> To: David.M.Fisher@Dartmouth.EDU (David M. Fisher) Cc: crossfire@ifi.uio.no, master@rahul.net, mehlhaff@plague.Berkeley.EDU Subject: Re: various ideas... In-Reply-To: Message from David.M.Fisher@Dartmouth.EDU (David M. Fisher) of 17 Feb 1994 22:10:19 -0500 <1283533@dancer.Dartmouth.EDU> Date: Fri, 18 Feb 1994 03:38:37 -0800 From: "'Evil' ERic Mehlhaff" Status: RO David.M.Fisher@Dartmouth.EDU (David M. Fisher) recently wrote: >I've had a few ideas about some aspects of crossfire, and I was wondering if >anyone has done work on them, or if perhaps the group decided they were >infeasible, etc. > >1) Player information directories, not just a file. In this directory would >be: > - the normal player data file > - a link to what the player considers "home" (where he/she goes with the >word of recall spell, and possibly other things) Altering where 'word of recall' goes is a neat idea. I hadn't exactly considered letting players customize it to that point, but sure, why not. I'd also like to see the starting position different from recall position, or even let people choose from a list of starting positions. Then you could start new players, say, in the 'beginners' map, to cut back on new player confusion. I tried this a bit on our server on scotch (now defunct :-( ). > - if the player's home is owned only by the player (more on that in a >second) then the player could leave items there that would survive game >reset. As it is right now, everyone who finds items that they want to keep, >yet not carry around makes a "holder" character and dumps everything there. >This would make things a little easier, is all. And how do you keep other players from sneaking in and burgling them? I hope you at least make it possible to do so, yet not impossible. Then there _would_ be a place for thieves in crossfire. :-) > - a description file, that is editable by the player. This would allow >life stories and interesting thoughts, promoting a little more >individualization. Sort of like a .sig/.plan./.project all rolled into >one... Nice idea, but how would the character edit this? >2) About the player's home: > >For low-level players, this could just be a room at an inn or some such. >Improvements might be things like a room in your guild (if you have one), >your own house in town, a castle, etc. All you'd need in the player >directory would be a link to the appropriate spot, so that shouldn't be too >difficult. The rest of it would be normal map stuff. There might be some >issues regarding whether other players are allowed into that room or not, or >any costs the player might bear for having a room, etc. Would work well with my generic maps ideas, too (covered in a separte mailing) >I'd be willing (even anxious!) to work on this stuff, but I don't want to get >started just to find out that it was considered not part of the game or some >one else had already done it. I beleive someone here was maintaining a list of who was working on what. ERic mehlhaff, mehlhaff@ocf.Berkeley.EDU From crossfire-request Fri Feb 18 12:40:30 1994 Return-Path: Received: from plague.Berkeley.EDU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 12:40:20 +0100 Received: from bigbang.Berkeley.EDU by plague.Berkeley.EDU (5.65c/CHAOS) id AA29014; Fri, 18 Feb 1994 03:29:22 -0800 Message-Id: <199402181129.AA29014@plague.Berkeley.EDU> To: Mark Wedel Cc: crossfire@ifi.uio.no, mehlhaff@plague.Berkeley.EDU Subject: Re: Further notes about 0.90.1. In-Reply-To: Message from Mark Wedel of Thu, 17 Feb 1994 01:45:50 -0800 <199402170945.AA26035@bolero.rahul.net> Date: Fri, 18 Feb 1994 03:29:16 -0800 From: "'Evil' ERic Mehlhaff" Status: RO Mark Wedel recently wrote: > > There are a few changes I am thinking of making: > > Change spell learning. Modify it by 5% for level difference of the spell >level and character level. This way, high level characters with very >low wisdom could learn low level spells, and thos with high wisdom would >have a difficult time learning spells that are 8 levels higher. Here's one of my major complaints of crossfire. I'd like to see stuff having to do with the game mechanics moved into a separte part of the code. Many people may not like how the spell learning system works, or how combat and damage chances are arranged, and want to change them. This can be a pain if the code for this is all over the place. Separating out the game rules from the code necessary to just run the rest of the game program would be a good thing to do, IMHO. > Any other features people woudl like to see added? Any comments on the >ones listed above? Hoo, boy, we've got a long TODO file here with lots of cool ideas. I'll just give one here that I think would be a relatively small hack but still be a major improvement. In all of the crossfire map setups I've seen, there's a _lot_ of 'closed' buildings and so on. I think it'd be cool to have all the empty city buildings and houses connect to a generic city/house/building map. The way I see this working is that in the archetypes, you can specify something in their entrance (slaying) field for whatever, say /generic/house. If, in the map, that house actually went somewhere special, the slaying field from the map supercedes, of course. Now, on the generic maps, we have to do something special for their exits. They have to return to wherever they entered from! I suggest that we deal with this by having exits pointing to "." exit to specified position on the current map, and exits of ".." pointing to wherever this map was entered from. I think best way to implement this is when a map is loaded by someone entering it, look for exits pointing to "." and ".." and make them point to the right place -- ".." being [lastmap]. "." is a bit tricky. I guess you'd put in [lastmap]/generic.x.y -- this so that it gets saved in the tempdir in a unique place, and so ti can be returned to properly, as well as going to it would work right for others. Additionally, using this scheme would make new maps a LOT more portable -- you could design a multiple-map quest or mini-campaign area, and have its return exits point to ".." and then people could have it plug into their world with a simple 'cp'. no pesky map editing and exit fixing required! The biggest drawback I can think of at the moment are cases where the game isn't sure what path ".." should point to -- i.e. players recovering from a save in the /generic/inn (actually, if their map path is saved as [lastmap]/generic.x.y, you have all you need right there), or (worse case) the map with the ".." was the multi-map quest, and the entrance map reset while you were one the deeper maps. (rare case) I supposed we'd need to co-opt a field in the map archetype to let maps know that they are 'generic' and thus need their name appropriately translated. I don't see this as a terribly difficult change, and I think I've covered most of the pitfalls. I'd be real happy if someone did this for me, as, (I've mentioned before) I'm busy trying to fix _machines_ here so I can do some real crossfire work! ERic mehlhaff, mehlhaff@ocf.Berkeley.EDU From crossfire-request Fri Feb 18 12:28:47 1994 Return-Path: Received: from lassie.eunet.fi by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 12:28:34 +0100 Received: from fireball.magic.fi (magic.fi) by lassie.eunet.fi with SMTP id AA27764 (5.67a/IDA-1.5 for ); Fri, 18 Feb 1994 13:28:12 +0200 Received: from wizard.magic.fi by fireball.magic.fi (5.0/SMI-SVR4) id AA07974; Fri, 18 Feb 1994 13:24:39 --200 Message-Id: <9402181124.AA07974@fireball.magic.fi> To: ftww@cs.su.oz.au Cc: crossfire@ifi.uio.no Subject: Re: plural archetype names. In-Reply-To: Your message of "Fri, 18 Feb 1994 19:20:17 +1100." <19940218082044.1059.ifi@ifi.uio.no> Date: Fri, 18 Feb 1994 13:28:59 +0200 From: Niilo Neuvo Content-Length: 357 Status: RO "Fred the Wonder Worm" writes: >OK, that works. But when do you need to say "No gauntlets of cherry picking" >or whatever? >wear gauntlets of cherry picking You have no gauntlets of cherry picking. Instead of You don't have that. Gauntlets is a terrible example, as it is plural already. >wield sword You have no swords. Instead of What? ++Anipa From crossfire-request Fri Feb 18 12:11:45 1994 Return-Path: Received: from plague.Berkeley.EDU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 12:11:41 +0100 Received: from bigbang.Berkeley.EDU by plague.Berkeley.EDU (5.65c/CHAOS) id AA28718; Fri, 18 Feb 1994 02:59:09 -0800 Message-Id: <199402181059.AA28718@plague.Berkeley.EDU> To: "Rupert G. Goldie" Cc: tvangod@ecst.csuchico.edu, crossfire@ifi.uio.no, mehlhaff@plague.Berkeley.EDU Subject: Re: Further notes about 0.90.1. In-Reply-To: Message from "Rupert G. Goldie" of Fri, 18 Feb 1994 15:18:08 +1100 <199402180418.AA04931@eden-valley.aaii.oz.AU> Date: Fri, 18 Feb 1994 02:59:04 -0800 From: "'Evil' ERic Mehlhaff" Status: RO "Rupert G. Goldie" recently wrote: >> From: Tyler Van Gorder > >> plus the guys at berkeley has radically changed the spell stuff....added lik >e >> 50 new spells, made spell dependencies based on the level of the caster...it >s >> VERY COOL. >> > >Can you or someone from berkeley tell us a bit about the new spells and how mu >ch the code has changed ? We've added a good 50 odd spells. Let me see if I can give a quick description: shockwave -- it's a cone spell, but does physical damage color spray -- a cone spell that does damage of a number of random types. face of death -- a blast of skulls that does a special 'death' attack on things. It's an all or nothing kill. haste -- speeds up its target ball lightning -- makes htis little electivied ball that moves around and zaps things. comet -- perhaps one of our most visually impressive spells. Shoots a rock out at the target, leaving a fire trail behind it. The rock hits the target for physical damage, and then bursts into a small fireball. Definitely a cool spell. meteor swarm -- a blast of several comets. They originate from squares around the caster (but not behind!) and fly in the target direction. Our 'swarm' code could be used elsewhere, too. like a 'bullet swarm'! mystic fist -- basically a golem that looks like a hand. raise dead resurrection reincarnation -- we hacked the player death code to keep the 'spirit' of deceased players, so that thy might be resurrected later. Not useful if you have NOT_PERMADEATH (does anyone else thing that's a stupid define name?) compiled in. immunity to [damage type] -- several spells that individually make the target temporarily immunet to that damage type. invulnerability -- immune to everything defense -- protected from everything rune spells: (most of this is peter's work) The rune spells make these magic 'runes' that are partially invisible. When a being steps on them, they trigger some effect. we coded runes for fire, frost, shocking, death, marking, magic (sets of another spell). spells to build active walls -- create bulletwall,s, firewalls, etc. experience for things killed by these walls goes to its creator. transferrence spell -- give your friends some of your spell points counterspell -- a cone spell that suppresses hostile magic effects, such as dragonbreaths, etc. erase rune -- get rid of them annoying runes. cure confusion -- very useful! restoration -- fixes things like depletion, does a nice general heal. a few fixes to summoning rules. Additional structural changes to the way spells are done -- i.e. the level dependency code. spells' damage, duration, extent of effect, etc vary with the level of the caster. This wasn't hardcoded either -- there was a separate config file that describes them, for easy customization by the crossfire administrator(s). Much of our new spell code we put into a separate .c file, so it should be relatively easy to merge in (unless game structures have changed radically). We have lots of cool ideas for more things to put in. For example, we didn't want the runes to be invisible, but rather 'concealed'. Our current hack is non-optimal. Unfortunately, most of my time is spent right now trying to get us a functional machine to do crossfire development and testing running on -- our old server machine is currently down. :-( ERic mehlhaff, mehlhaff@soda.Berkeley.EDU From crossfire-request Fri Feb 18 09:57:55 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 09:57:47 +0100 Received: by bolero.rahul.net id AA22877 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Fri, 18 Feb 1994 00:57:35 -0800 Date: Fri, 18 Feb 1994 00:57:35 -0800 From: Mark Wedel Message-Id: <199402180857.AA22877@bolero.rahul.net> To: crossfire@ifi.uio.no, ftww@cs.su.oz.au Subject: Re: plural archetype names. Status: RO I don't know. But if you ever do have zero count objects, the method to do so is not difficult. --Mark From crossfire-request Fri Feb 18 09:20:48 1994 Return-Path: Received: from joyce.cs.su.OZ.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 09:20:44 +0100 Message-Id: <19940218082044.1059.ifi@ifi.uio.no> Received: from orthanc.cs.su.OZ.AU by joyce.cs.su.OZ.AU (mail from ftww for crossfire@ifi.uio.no) with MHSnet (insertion MHSnet site: basser.cs.su.oz.au); Fri, 18 Feb 1994 19:20:24 +1100 Subject: Re: plural archetype names. To: crossfire@ifi.uio.no Date: Fri, 18 Feb 1994 19:20:17 +1100 (EST) From: "Fred the Wonder Worm" In-Reply-To: <199402180728.AA18199@bolero.rahul.net> from "Mark Wedel" at Feb 17, 94 11:28:43 pm 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: 497 Status: RO > For zero, use the plural, but prefix an 'No' instead of 'Two' or 'Three' > or whatever. OK, that works. But when do you need to say "No gauntlets of cherry picking" or whatever? Cheers, Geoff. ------------------------------------------------------------------------------- Geoff Bailey (Fred the Wonder Worm) | Programmer by trade -- ftww@cs.su.oz.au | Gameplayer by vocation. ------------------------------------------------------------------------------- From crossfire-request Fri Feb 18 09:14:53 1994 Return-Path: Received: from corpse.ecst.csuchico.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 09:14:50 +0100 Received: from localhost (tvangod@localhost) by corpse.ecst.csuchico.edu (8.6.4/8.6.4) id AAA27759 for crossfire@ifi.uio.no; Fri, 18 Feb 1994 00:14:43 -0800 From: Tyler Van Gorder Message-Id: <199402180814.AAA27759@corpse.ecst.csuchico.edu> Subject: HELLO!@ To: crossfire@ifi.uio.no Date: Fri, 18 Feb 1994 00:14:43 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 730 Status: RO First off! MARK! you did a GREAT job with the merge......I have never had it compile so easily! :> Glad to see the build World is fixed again :> ok. I have taken a very very brief look over of the new server....IT LOOKS good........ The only thing I have noticed as a "bug/feature" is in button.c......a regular button does not open a trigger_gate...and a trigger_button doesnot open a regular gate....very minor.....can fix that in about 10 mins :> So just wanted to mention that the Chico maps i put up on ftp will seem to have a lot of their buttons/altars/gates broken.....that is due to the feature above :> Again Cudos to mark for taking the inititive on this....he has done a really really good job :> Tyler. From crossfire-request Fri Feb 18 08:55:59 1994 Return-Path: Received: from amisk.cs.ualberta.ca by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 08:55:53 +0100 Received: from gsb011.cs.ualberta.ca by amisk.cs.ualberta.ca id <138906>; Fri, 18 Feb 1994 00:55:40 -0700 Subject: Re: using gzip ? From: Papp Denis Richard To: rgg@aaii.oz.au Date: Fri, 18 Feb 1994 00:55:19 -0700 Cc: crossfire@ifi.uio.no In-Reply-To: <199402180650.AA05544@eden-valley.aaii.oz.AU> from "rgg@aaii.oz.au" at Feb 17, 94 11:50:15 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1956 Message-Id: <94Feb18.005540-0700.138906@amisk.cs.ualberta.ca> Status: RO > > gzip is newer (non patented) technology. gzip -9 takes longer than compress, > but gets much better compression. Text files will usually compress better than > binary files because they will have more common bit strings than binary files. > This should be a common feature across all compression algorithms. (I will > resist the temptation to discuss models, dictionaries, and arithmetic coding...) > Well, might as well ask. but how is gzip -9 compared to the formats I am used to on dos: (I wont mention a few since they are not as good) pkzip -eX pkzip (same as unix unzip of course) arj lha (same as unix lha of course) pak (actually this one isnt very good) and I also recently tried Ultra Compressor, and was impressed. It was a bit smaller (though it didnt make my ZIP files any smaller :) - just a test to see if it used a lot of overhead and/or a similar algorithm to zip) Zoo ha! Tried compresing some GIFs - made them bigger. Ignoring JPG, ICE is also worth mentioning, it didnt do well on text etc but overall I thought it did better than the others on GIFs. Of course using anything other than JPG doesnt really help. Anyways, top text compression I found was with pkzip 2.04g with maximal compression. BUT when I compared it vs Ultra Compressor recently, Ultra Compressor did better. Overall PKZIP usually did better than the others, other than a bunch of audio files where Lha seemed to do a bit better. But I dont think I waas using the latest ARJ/LHA at the time (a while ago). If gzip -9 is better than pkzip -eX then if theres an ibm binary I will strongly consider switching. Even if its only better for text. I will also have to try out ultra compressor more to see if it really is better. -- Denis Papp dpapp@amisk.cs.ualberta.ca "So, uh, let me uh get this straight. You want to kidnap me and put me in some intuhguhlactic zoo?"-- Elvis Presley From crossfire-request Fri Feb 18 08:28:51 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 08:28:48 +0100 Received: by bolero.rahul.net id AA18199 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 17 Feb 1994 23:28:43 -0800 Date: Thu, 17 Feb 1994 23:28:43 -0800 From: Mark Wedel Message-Id: <199402180728.AA18199@bolero.rahul.net> To: ftww@cs.su.oz.au Subject: Re: plural archetype names. Cc: crossfire@ifi.uio.no Status: RO For zero, use the plural, but prefix an 'No' instead of 'Two' or 'Three' or whatever. --Mark From crossfire-request Fri Feb 18 08:25:04 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 08:24:55 +0100 Received: by bolero.rahul.net id AA17914 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 17 Feb 1994 23:24:45 -0800 Date: Thu, 17 Feb 1994 23:24:45 -0800 From: Mark Wedel Message-Id: <199402180724.AA17914@bolero.rahul.net> To: dpapp@amisk.cs.ualberta.ca, rgg@aaii.oz.au Subject: Re: using gzip ? Cc: crossfire@ifi.uio.no Status: RO It should also be mentioned that in almost all the crossfire tar files, everything is text files. From crossfire-request Fri Feb 18 07:51:08 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 07:51:01 +0100 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA05544; Fri, 18 Feb 1994 17:50:15 +1100 Date: Fri, 18 Feb 1994 17:50:15 +1100 From: "Rupert G. Goldie" Message-Id: <199402180650.AA05544@eden-valley.aaii.oz.AU> To: dpapp@amisk.cs.ualberta.ca Subject: Re: using gzip ? Cc: crossfire@ifi.uio.no Status: RO > > I've always wondered but never checked, isnt compress mostly for > text files, and doesnt really compress binary files as well as could > be...? > > > -- > Denis Papp dpapp@amisk.cs.ualberta.ca gzip is newer (non patented) technology. gzip -9 takes longer than compress, but gets much better compression. Text files will usually compress better than binary files because they will have more common bit strings than binary files. This should be a common feature across all compression algorithms. (I will resist the temptation to discuss models, dictionaries, and arithmetic coding...) Rupert From crossfire-request Fri Feb 18 07:47:42 1994 Return-Path: Received: from corpse.ecst.csuchico.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 07:47:40 +0100 Received: from localhost (tvangod@localhost) by corpse.ecst.csuchico.edu (8.6.4/8.6.4) id WAA24429 for crossfire@ifi.uio.no; Thu, 17 Feb 1994 22:47:39 -0800 From: Tyler Van Gorder Message-Id: <199402180647.WAA24429@corpse.ecst.csuchico.edu> Subject: Chico maps and stuff. To: crossfire@ifi.uio.no Date: Thu, 17 Feb 1994 22:47:38 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 357 Status: RO I have tared up all the chico maps.....and all the archetypes. they are at anonymous ftp hairball.ecst.csuchico.edu in the dir /pub/crossfire note that there are also a lot of stuff from the berkeley folks...to..... rune, fireborn, and quazicatl archetypes will not be useful till the berkeley code is merged...into the the next release. :> Tyler. From crossfire-request Fri Feb 18 07:41:55 1994 Return-Path: Received: from corpse.ecst.csuchico.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 07:41:53 +0100 Received: from localhost (tvangod@localhost) by corpse.ecst.csuchico.edu (8.6.4/8.6.4) id WAA24349; Thu, 17 Feb 1994 22:41:25 -0800 From: Tyler Van Gorder Message-Id: <199402180641.WAA24349@corpse.ecst.csuchico.edu> Subject: Re: Further notes about 0.90.1. To: rgg@aaii.oz.au (Rupert G. Goldie) Date: Thu, 17 Feb 1994 22:41:25 -0800 (PST) Cc: tvangod@ecst.csuchico.edu, crossfire@ifi.uio.no In-Reply-To: <199402180418.AA04931@eden-valley.aaii.oz.AU> from "Rupert G. Goldie" at Feb 18, 94 03:18:08 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 471 Status: RO > > > From: Tyler Van Gorder > > > plus the guys at berkeley has radically changed the spell stuff....added like > > 50 new spells, made spell dependencies based on the level of the caster...its > > VERY COOL. > > > > Can you or someone from berkeley tell us a bit about the new spells and how much > the code has changed ? > > > Rupert > Peter would be the best one to explain...since he is the one that coded them :> Peter? From crossfire-request Fri Feb 18 07:17:46 1994 Return-Path: Received: from amisk.cs.ualberta.ca by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 07:17:43 +0100 Received: from gsb011.cs.ualberta.ca by amisk.cs.ualberta.ca id <138896>; Thu, 17 Feb 1994 23:17:16 -0700 Subject: Re: using gzip ? From: Papp Denis Richard To: rgg@aaii.oz.au (Rupert G. Goldie) Date: Thu, 17 Feb 1994 23:17:03 -0700 Cc: crossfire@ifi.uio.no In-Reply-To: <199402180020.AA03593@eden-valley.aaii.oz.AU> from "Rupert G. Goldie" at Feb 17, 94 05:20:30 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 583 Message-Id: <94Feb17.231716-0700.138896@amisk.cs.ualberta.ca> Status: RO > > What do people think about using gzip rather than compress for compressing > the files on the ftp site ? I have found gzip -9 gets _much_ better compression > (eg crossfire-0.90.1.arch.tar.Z = 657787 bytes > crossfire-0.90.1.arch.tar.gz = 397620 bytes) I've always wondered but never checked, isnt compress mostly for text files, and doesnt really compress binary files as well as could be...? -- Denis Papp dpapp@amisk.cs.ualberta.ca --- This message contained hidden codes and you have just been infected with the ASCII virus! Reboot before it spreads too far! From crossfire-request Fri Feb 18 05:20:09 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 05:19:31 +0100 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA04931; Fri, 18 Feb 1994 15:18:08 +1100 Date: Fri, 18 Feb 1994 15:18:08 +1100 From: "Rupert G. Goldie" Message-Id: <199402180418.AA04931@eden-valley.aaii.oz.AU> To: tvangod@ecst.csuchico.edu Subject: Re: Further notes about 0.90.1. Cc: crossfire@ifi.uio.no Status: RO > From: Tyler Van Gorder > plus the guys at berkeley has radically changed the spell stuff....added like > 50 new spells, made spell dependencies based on the level of the caster...its > VERY COOL. > Can you or someone from berkeley tell us a bit about the new spells and how much the code has changed ? Rupert From crossfire-request Fri Feb 18 04:10:31 1994 Return-Path: Received: from dartvax.dartmouth.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 04:10:29 +0100 Received: from dancer.Dartmouth.EDU by dartvax.dartmouth.edu (8.6.5.Beta11+DND/4.5HUB) id WAA02286; Thu, 17 Feb 1994 22:10:27 -0500 Message-id: <1283533@dancer.Dartmouth.EDU> Date: 17 Feb 94 22:10:19 EST From: David.M.Fisher@Dartmouth.EDU (David M. Fisher) Subject: various ideas... To: crossfire@ifi.uio.no Cc: master@rahul.net Status: RO I've had a few ideas about some aspects of crossfire, and I was wondering if anyone has done work on them, or if perhaps the group decided they were infeasible, etc. 1) Player information directories, not just a file. In this directory would be: - the normal player data file - a link to what the player considers "home" (where he/she goes with the word of recall spell, and possibly other things) - if the player's home is owned only by the player (more on that in a second) then the player could leave items there that would survive game reset. As it is right now, everyone who finds items that they want to keep, yet not carry around makes a "holder" character and dumps everything there. This would make things a little easier, is all. - a description file, that is editable by the player. This would allow life stories and interesting thoughts, promoting a little more individualization. Sort of like a .sig/.plan./.project all rolled into one... 2) About the player's home: For low-level players, this could just be a room at an inn or some such. Improvements might be things like a room in your guild (if you have one), your own house in town, a castle, etc. All you'd need in the player directory would be a link to the appropriate spot, so that shouldn't be too difficult. The rest of it would be normal map stuff. There might be some issues regarding whether other players are allowed into that room or not, or any costs the player might bear for having a room, etc. I'd be willing (even anxious!) to work on this stuff, but I don't want to get started just to find out that it was considered not part of the game or some such thing... -Dave From crossfire-request Fri Feb 18 03:21:05 1994 Return-Path: Received: from joyce.cs.su.OZ.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 03:21:00 +0100 Message-Id: <19940218022100.15763.ifi@ifi.uio.no> Received: from orthanc.cs.su.OZ.AU by joyce.cs.su.OZ.AU (mail from ftww for crossfire@ifi.uio.no) with MHSnet (insertion MHSnet site: basser.cs.su.oz.au); Fri, 18 Feb 1994 13:20:54 +1100 Subject: Re: plural archetype names. To: crossfire@ifi.uio.no Date: Fri, 18 Feb 1994 13:20:47 +1100 (EST) From: "Fred the Wonder Worm" In-Reply-To: <19940218011215.13116.bera.ifi.uio.no@ifi.uio.no> from "Kjetil Torgrim Homme" at Feb 18, 94 02:12:15 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: 967 Status: RO > +--- Mark Wedel: > | Why do this? It would get rid if the need_ie field, as well as > | need_an field (singular object coudl be called an amulet, and plural > | would be amulets.) > +--- > > I think you were typing faster than you were thinking here :-) You'd > still need the "need_an", but "plural_name" is fine. A little faster, > more correct, and 4 more bytes in every object... ;-) Well, if query_name() were modified to return name if count is 1, or count + plural_name if count > 1, then you can get rid of need_an. What you do if count is 0 is problematical, but I've never really understood what to do with an object with count 0 anyway. Cheers, Geoff. ------------------------------------------------------------------------------- Geoff Bailey (Fred the Wonder Worm) | Programmer by trade -- ftww@cs.su.oz.au | Gameplayer by vocation. ------------------------------------------------------------------------------- From crossfire-request Fri Feb 18 02:58:46 1994 Return-Path: Received: from bera.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 02:58:45 +0100 From: Kjetil Torgrim Homme Received: from localhost by bera.ifi.uio.no ; Fri, 18 Feb 1994 02:58:44 +0100 Date: Fri, 18 Feb 1994 02:58:44 +0100 Message-Id: <19940218015844.13149.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: Mark Wedel's message of Thu, 17 Feb 1994 16:31:19 -0800 <199402180031.AA17017@bolero.rahul.net> Subject: Re: Further notes about 0.90.1. Status: RO +--- Mark Wedel: | Actually, old characters will have a disadvantage, as all their | items will be marked as unidentified. The default for items is for | them to be considered unidentified unless the identified 1 flag is | in the item description (save file or archetypes file.) +------- You're right, of course - all their items will be nearly worthless (in the shop, that is) unless they identify them. Well, at least none of their objects will be cursed or damned ;-) Kjetil T. From crossfire-request Fri Feb 18 02:12:17 1994 Return-Path: Received: from bera.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id ; Fri, 18 Feb 1994 02:12:16 +0100 From: Kjetil Torgrim Homme Received: from localhost by bera.ifi.uio.no ; Fri, 18 Feb 1994 02:12:15 +0100 Date: Fri, 18 Feb 1994 02:12:15 +0100 Message-Id: <19940218011215.13116.bera.ifi.uio.no@ifi.uio.no> To: master@rahul.net CC: crossfire@ifi.uio.no In-reply-to: Mark Wedel's message of Thu, 17 Feb 1994 16:58:05 -0800 <199402180058.AA18682@bolero.rahul.net> Subject: Re: plural archetype names. Status: RO +--- Mark Wedel: | Why do this? It would get rid if the need_ie field, as well as | need_an field (singular object coudl be called an amulet, and plural | would be amulets.) +--- I think you were typing faster than you were thinking here :-) You'd still need the "need_an", but "plural_name" is fine. A little faster, more correct, and 4 more bytes in every object... ;-) +--- | Another thing that would be nice to add is to let players name their | objects. This would be especially handy for rings and amulets, to | name it ring of cha+1 or something. Although, in the defines, you | could also turn on FULL_RING_DESCRIPTION. +------- Actually, we should do away with ring of cha +1 and make them all into artifacts (the new type defined in lib/artifacts). That was the intention, anyway. +--- Rupert G. Goldie: | I would also like to see a way of limiting the number of child spell | effects active at one time (ie I want to limit the number of bullets | flying around from one wall to, say, 10 to stop the game from | crawling because there are 200 bullets bouncing around reflectors) +------- Actually, I'd prefer to see a lifetime limit for every spell - ie. a bullet can't go more than 100 squares - the time span could be dependent on the player's wisdom if the caster is a player. I might as well mentioned the old idea that _every_ generator could have a limit of how many children it can generate. If keeping refcounts is added (remember the problems with objects that have lost their owner?), this can be implemented almost for free. Kjetil T. From crossfire-request Fri Feb 18 01:58:27 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 01:58:13 +0100 Received: by bolero.rahul.net id AA18682 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 17 Feb 1994 16:58:05 -0800 Date: Thu, 17 Feb 1994 16:58:05 -0800 From: Mark Wedel Message-Id: <199402180058.AA18682@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: plural archetype names. Status: RO One thought I have is adding another field to archetypes called plural_name. This would be the name to use for more than one archetypes. Why do this? It would get rid if the need_ie field, as well as need_an field (singular object coudl be called an amulet, and plural would be amulets.) It would also eliminate some special cases, and make plurals actually work properly. Cases where is does not work correctly now is potions. a 'potion of intelligence' is fine, but 'two potion of intelligences' is not correct. If the archetype lacks a plural name field, then it is assumed taht the plural is created by just adding 1 s to the name. This is really a cosmetic change. It shouldn't slow the game down any, and only take a little more memory (for the plural name elements.) Another thing that would be nice to add is to let players name their objects. This would be especially handy for rings and amulets, to name it ring of cha+1 or something. Although, in the defines, you could also turn on FULL_RING_DESCRIPTION. --Mark From crossfire-request Fri Feb 18 01:57:51 1994 Return-Path: Received: from bera.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 01:57:50 +0100 From: Kjetil Torgrim Homme Received: from localhost by bera.ifi.uio.no ; Fri, 18 Feb 1994 01:57:50 +0100 Date: Fri, 18 Feb 1994 01:57:50 +0100 Message-Id: <19940218005750.13098.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: Mark Wedel's message of Thu, 17 Feb 1994 16:44:13 -0800 <199402180044.AA17651@bolero.rahul.net> Subject: Re: active walls Status: RO I think the code is already there. Active walls are called FIREWALL in define.h. Just edit the "other_arch" and "face" variables with Crossedit. To make it easy to use, make a new pick-map. You can do amazing things by changing the variables on each object :-) Kjetil T. From crossfire-request Fri Feb 18 01:52:07 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 01:51:57 +0100 Received: by bolero.rahul.net id AA18255 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 17 Feb 1994 16:51:49 -0800 Date: Thu, 17 Feb 1994 16:51:49 -0800 From: Mark Wedel Message-Id: <199402180051.AA18255@bolero.rahul.net> To: crossfire@ifi.uio.no, rgg@aaii.oz.au Subject: Re: using gzip ? Status: RO One reason that standard compress was used was that was the program that make archive used. It wouldn't be hard to use gzip. The only problem would really be if a bunch of people don't have it installed. --Mark From crossfire-request Fri Feb 18 01:44:31 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 01:44:21 +0100 Received: by bolero.rahul.net id AA17651 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 17 Feb 1994 16:44:13 -0800 Date: Thu, 17 Feb 1994 16:44:13 -0800 From: Mark Wedel Message-Id: <199402180044.AA17651@bolero.rahul.net> To: crossfire@ifi.uio.no, peterm@soda.berkeley.edu Subject: Re: active walls Status: RO I like the idea of generic active walls. Using animation fields would work ok for the wall type (potions of restoration use somethign similar). --Mark From crossfire-request Fri Feb 18 01:41:33 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 01:41:27 +0100 Received: by bolero.rahul.net id AA17489 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 17 Feb 1994 16:41:20 -0800 Date: Thu, 17 Feb 1994 16:41:20 -0800 From: Mark Wedel Message-Id: <199402180041.AA17489@bolero.rahul.net> To: crossfire@ifi.uio.no, master@rahul.net, peterm@soda.berkeley.edu Subject: Re: Further notes about 0.90.1. Status: RO True. But it could be modified so that each level you are lower than the spell, the chance of learning it is much more difficult. so if you are one level lower, maybe 5%, 2 levels lower, 15%, 3 levels lower, 25%, 4 levels lower, 40%, or whatever. This would make it very difficult to learn a spell much higher than your level. I like the idea that your level as related to the spell level determines casting efficiency. --Mark From crossfire-request Fri Feb 18 01:31:28 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id ; Fri, 18 Feb 1994 01:31:22 +0100 Received: by bolero.rahul.net id AA17017 (5.67a8/IDA-1.5); Thu, 17 Feb 1994 16:31:19 -0800 Date: Thu, 17 Feb 1994 16:31:19 -0800 From: Mark Wedel Message-Id: <199402180031.AA17017@bolero.rahul.net> To: kjetilho@ifi.uio.no, master@rahul.net Subject: Re: Further notes about 0.90.1. Cc: crossfire@ifi.uio.no Status: RO Actually, old characters will have a disadvantage, as all their items will be marked as unidentified. The default for items is for them to be considered unidentified unless the identified 1 flag is in the item description (save file or archetypes file.) --Mark From crossfire-request Fri Feb 18 01:21:52 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 01:21:07 +0100 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA03593; Fri, 18 Feb 1994 11:20:30 +1100 Date: Fri, 18 Feb 1994 11:20:30 +1100 From: "Rupert G. Goldie" Message-Id: <199402180020.AA03593@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no Subject: using gzip ? Status: RO What do people think about using gzip rather than compress for compressing the files on the ftp site ? I have found gzip -9 gets _much_ better compression (eg crossfire-0.90.1.arch.tar.Z = 657787 bytes crossfire-0.90.1.arch.tar.gz = 397620 bytes) Rupert From crossfire-request Fri Feb 18 01:15:10 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 01:14:48 +0100 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA03568; Fri, 18 Feb 1994 11:14:31 +1100 Date: Fri, 18 Feb 1994 11:14:31 +1100 From: "Rupert G. Goldie" Message-Id: <199402180014.AA03568@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no, peterm@soda.berkeley.edu Subject: Re: active walls Status: RO > bulletwalls, firewalls, lightningwalls. > > Those are the only three walls available right now. > > I think we'd gain a lot in crossfire if we generalized the idea-- > I call them 'active walls'. > > Cool idea. It wasn't very hard to hack bullet walls to make lightning walls, but it would be much better if there was a general method. (The time consuming part of adding lightning walls was doing all the bitmaps ;-) > Sometime soon, I'd like to re-do this wall code so that you > could stick any 'game effect' (spell) in it that caught your > fancy. This would give some more flexibility to the map designer. Mmmm, wall of paralysis, that could be nasty 8-). [...] > The walls would use the cast-spell set of routines to produce > their effects. When I put in the level dependencies on spells, > this means you could make a mild wall of lighting or a very very deadly > wall of lightning, by changing the level of the wall! > > Other things about active walls should be made more flexible if they're > not already, such as frequency of fire, and whether or not they > can be torn down. (This may have already been done.) > I think you can already do this with the 'speed' attribute. It may be possible to set 'tear_down' at the moment, but the animations won't have the steps of being torn down so it might look crappy/strange. I would also like to see a way of limiting the number of child spell effects active at one time (ie I want to limit the number of bullets flying around from one wall to, say, 10 to stop the game from crawling because there are 200 bullets bouncing around reflectors) > My proposal boils down to: > > modify the archetypes so there is one active wall archetype. > modify the code to support this > make a pick map of popular active wall types > [...] > Regards, > > PeterM > Rupert From crossfire-request Fri Feb 18 00:44:28 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 00:43:57 +0100 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA03446; Fri, 18 Feb 1994 10:41:51 +1100 Date: Fri, 18 Feb 1994 10:41:51 +1100 From: "Rupert G. Goldie" Message-Id: <199402172341.AA03446@eden-valley.aaii.oz.AU> To: tvangod@ecst.csuchico.edu Subject: Re: Further notes about 0.90.1. Cc: crossfire@ifi.uio.no Status: RO > > About 50-60 new archs have been made......quest items... > > plus the guys at berkeley has radically changed the spell stuff....added like > 50 new spells, made spell dependencies based on the level of the caster...its > VERY COOL. > > Anyway....if you long for some better quality maps/lots of new archs....I can > make the chico stuff available.....I imagine there is some interest? > I think it would be a good idea to fold all this stuff into the main distribution as soon as possible. Rupert From crossfire-request Fri Feb 18 00:27:15 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 00:27:12 +0100 Received: from localhost (peterm@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id PAA16095 for crossfire@ifi.uio.no; Thu, 17 Feb 1994 15:27:07 -0800 Date: Thu, 17 Feb 1994 15:27:07 -0800 From: Peter Mardahl Message-Id: <199402172327.PAA16095@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: active walls Status: RO bulletwalls, firewalls, lightningwalls. Those are the only three walls available right now. I think we'd gain a lot in crossfire if we generalized the idea-- I call them 'active walls'. Sometime soon, I'd like to re-do this wall code so that you could stick any 'game effect' (spell) in it that caught your fancy. This would give some more flexibility to the map designer. You could have fireball wallls, cone of frost walls, small and large lightning walls, walls of cancellation, whatever. The idea would be that you could use the map editor to make them what you want. It would be trivial to make a pick map of several popular types of active walls. The walls would use the cast-spell set of routines to produce their effects. When I put in the level dependencies on spells, this means you could make a mild wall of lighting or a very very deadly wall of lightning, by changing the level of the wall! Other things about active walls should be made more flexible if they're not already, such as frequency of fire, and whether or not they can be torn down. (This may have already been done.) My proposal boils down to: modify the archetypes so there is one active wall archetype. modify the code to support this make a pick map of popular active wall types Problems: It becomes harder to have customized faces for each type of active wall. My plan is to store the various faces in the anim fields--0 is a default, 1= lightnig, 2 = fire, 3 = speedball, 4=bullet. doing the faces in the map editor would be a big mistake under the current system. Regards, PeterM From crossfire-request Fri Feb 18 00:06:55 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 18 Feb 1994 00:06:52 +0100 Received: from localhost (peterm@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id PAA14022; Thu, 17 Feb 1994 15:06:27 -0800 Date: Thu, 17 Feb 1994 15:06:27 -0800 From: Peter Mardahl Message-Id: <199402172306.PAA14022@soda.berkeley.edu> To: crossfire@ifi.uio.no, master@rahul.net Subject: Re: Further notes about 0.90.1. Status: RO Regarding some of your changes: Change spell learning. Modify it by 5% for level difference of the spell level and character level. This way, high level characters with very low wisdom could learn low level spells, and thos with high wisdom would have a difficult time learning spells that are 8 levels higher. I like the idea of allowing very high level characters to learn low level spells even if their wisdom isn't up to it. However, the idea of letting low level characters learn higher level spells seems dubious to me. You could have situations where some fifth level character knows the twelfth level spell of < whatever >, clearly undeserved power. I like the 5% per level difference going down, but no one should be able to learn spells that are more than say, 2 levels above him, no matter what. I think it's sort of silly, though, to have spell "levels". It seems somewhat artificial. Another way to look at things is like this: high wisdom + high level ==> ease in learning spells your level compared to spell 'level' ==> your effectiveness with that spell spell level is then a measure of the sophistication of character needed to cast it. Anyone can learn any spell, but if the character isn't strong enough to cast the spell well, then he either fails entirely, or casts it weakly, with the strength of his casting falling off very rapidly (like in 2 levels) if he's below the level of the spell. I can implement that if there's support for it. Regards, PeterM From crossfire-request Thu Feb 17 23:18:01 1994 Return-Path: Received: from corpse.ecst.csuchico.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id ; Thu, 17 Feb 1994 23:17:57 +0100 Received: from localhost (tvangod@localhost) by corpse.ecst.csuchico.edu (8.6.4/8.6.4) id OAA14629; Thu, 17 Feb 1994 14:17:31 -0800 From: Tyler Van Gorder Message-Id: <199402172217.OAA14629@corpse.ecst.csuchico.edu> Subject: Re: Further notes about 0.90.1. To: kjetilho@ifi.uio.no (Kjetil Torgrim Homme) Date: Thu, 17 Feb 1994 14:17:30 -0800 (PST) Cc: master@rahul.net, crossfire@ifi.uio.no In-Reply-To: <19940217192138.12342.bera.ifi.uio.no@ifi.uio.no> from "Kjetil Torgrim Homme" at Feb 17, 94 08:21:38 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1461 Status: RO Note: The Chico server is running off ALL new maps....I chose to trash all of the old ones...except for Santo Domingo. (thinking of dropping those maps too.) Currently the Chico server has a "world" map which is actually 9 smaller maps. made to appear as one...it took lots and lots of work to get it to look as if you never leave one map to the next :> overlapping 5 squares on each map look identical.....to the map next to it. :> The chico server has a new starting CITY....not just a town.....lots of things are open in it. And there is an old city, underneath the city, in which a quest has been implemented. (old city has 15 maps to it alone.) I believe there are currently 3 quests implemented throughout the chico server lots of talking monsters etc..... About 50-60 new archs have been made......quest items... plus the guys at berkeley has radically changed the spell stuff....added like 50 new spells, made spell dependencies based on the level of the caster...its VERY COOL. Anyway....if you long for some better quality maps/lots of new archs....I can make the chico stuff available.....I imagine there is some interest? (also a small note: It seems kinda silly to have a "trigger button" and a regular button. As it was in crossfire.89.3, a trigger button connected to a non-trigger door would not open that door...maybe we should make this more generic.....so you dont have to worry if your using the right type of button. ) Tyler. From crossfire-request Thu Feb 17 20:21:40 1994 Return-Path: Received: from bera.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id ; Thu, 17 Feb 1994 20:21:39 +0100 From: Kjetil Torgrim Homme Received: from localhost by bera.ifi.uio.no ; Thu, 17 Feb 1994 20:21:38 +0100 Date: Thu, 17 Feb 1994 20:21:38 +0100 Message-Id: <19940217192138.12342.bera.ifi.uio.no@ifi.uio.no> To: master@rahul.net CC: crossfire@ifi.uio.no In-reply-to: Mark Wedel's message of Thu, 17 Feb 1994 01:45:50 -0800 <199402170945.AA26035@bolero.rahul.net> Subject: Re: Further notes about 0.90.1. Status: RO First of all, three cheers for Mark! :-) +--- Mark Wedel: | One note about crossfire 0.90.1: IT is likely that save files from | crossedit 0.7 can be used unmodified with 0.90.1. +--- Probably, yes, but the old characters will have an advantage since they will have lots of equipment which is identified :-) +--- | Any other features people would like to see added? Any comments on | the ones listed above? +------- More features? Just now, I think we need more _items_ and types of terrain, more encounter maps, and like always, better maps and more quests :-) I think we should spend a month or so making it a really good _game_ (on a LAN) before tearing down all stability as it is split into client/server. As for the changes you mentioned - I say go ahead. (I'm currently compiling it with acc on a SPARC, there _are_ errors, but I'll probably mail you a patch to tidy it up, Mark) Kjetil T. From crossfire-request Tue Feb 22 12:23:41 1994 Return-Path: Received: from aino.it.lut.fi by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Tue, 22 Feb 1994 12:23:40 +0100 Received: from localhost (hevi@localhost) by aino.it.lut.fi (8.6.5/8.6.5/1.12.kim) id NAA09855; Tue, 22 Feb 1994 13:23:34 +0200 Date: Tue, 22 Feb 1994 13:23:33 +0200 (EET) From: Petri Heinil{ Subject: Re: er...xbmtoxpm??? To: crossfire@ifi.uio.no In-Reply-To: <9402221027.AA11767@alamein> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Some thoughs about pixmaps: - should the working xpm-library be includes into release ? - this is against modularity of programming but helps compiling and installing to not-so-net-users - this increases the release size - should there migrate to use only pixmaps ? + this makes more constent the use of images - more space/less space + the are no duplicate font/bw-pix/pix - pixmaps use more space themselves - the converting jop; most images should enchant by hand to look good - the font-feature are not available any more (does anyone need it ?) ///////////////////////// Petri Heinila ///////////////////////// email: Petri.Heinila@lut.fi www: Homepage mail: Ainonkatu 2A 53100 Lappeenranta Finland, Europe tel: 3624 (in. LUT) From crossfire-request Tue Feb 22 11:29:17 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Tue, 22 Feb 1994 11:29:10 +0100 Received: from alamein (alamein.aaii.oz.AU) by eden-valley.aaii.oz.AU with SMTP (5.65c/SMI-4.0/AAII) id AA04203; Tue, 22 Feb 1994 21:28:50 +1100 Received: by alamein; id AA11767; Tue, 22 Feb 1994 21:27:09 +1100 Message-Id: <9402221027.AA11767@alamein> To: Mark Wedel Cc: tvangod@ecst.csuchico.edu, crossfire@ifi.uio.no From: anthony baxter Reply-To: anthony.baxter@aaii.oz.au Subject: Re: er...xbmtoxpm??? In-Reply-To: Message from Mark Wedel of 1994-Feb-21 19:19:14, <199402220319.AA18252@bolero.rahul.net> Date: Tue, 22 Feb 1994 21:27:07 +1100 Sender: anthony@aaii.oz.au Status: RO Mark Wedel wrote: > The PbmPlus package has programs taht are called xpmtoppm and ppmtoxpm, > but these are apparantly meant for a different type of XPM file (maybe > real old version or something.) Yeah, they write version 1 files. You need the files from xpm-3.2 or later to convert them to version 3 types. > Also, some people sent me bugs saying that their version of libXpm did > not have XCreatePixmapFromBuffer. If any of those people were able Hmm, according to the CHANGES file with xpm, XpmCreatePixmapFromBuffer was added in version 3.2f, dated 93/03/17. Version 3.2g or 3.3 should both also work. (3.3 is the most recent version, available from ftp.x.org:/contrib, or one of its mirrors, as xpm-3.3.tar.gz) Anthony From crossfire-request Tue Feb 22 06:40:47 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Tue, 22 Feb 1994 06:40:42 +0100 Received: by bolero.rahul.net id AA25329 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Mon, 21 Feb 1994 21:40:37 -0800 Date: Mon, 21 Feb 1994 21:40:37 -0800 From: Mark Wedel Message-Id: <199402220540.AA25329@bolero.rahul.net> To: tvangod@ecst.csuchico.edu Subject: Re: er...xbmtoxpm??? Cc: crossfire@ifi.uio.no Status: RO I had already changed some of the XPM defines in crosssite.def. I believe the problem was simply solved by changing the location commands to just straight to the following: #define XPM_PIX XPM_LIBDIR = /usr/local/lib/ /* If your include files are someplace odd XPM_INCLUDE = */ in the crosssite.def file. This seems to fix the problem. But it seems taht for at least some people, getting a newer version of the library was also needed. --Mark From crossfire-request Tue Feb 22 05:43:30 1994 Return-Path: Received: from corpse.ecst.csuchico.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Tue, 22 Feb 1994 05:43:28 +0100 Received: from localhost (tvangod@localhost) by corpse.ecst.csuchico.edu (8.6.4/8.6.4) id UAA27108; Mon, 21 Feb 1994 20:43:22 -0800 From: Tyler Van Gorder Message-Id: <199402220443.UAA27108@corpse.ecst.csuchico.edu> Subject: Re: er...xbmtoxpm??? To: master@rahul.net (Mark Wedel) Date: Mon, 21 Feb 1994 20:43:22 -0800 (PST) Cc: tvangod@ecst.csuchico.edu, crossfire@ifi.uio.no In-Reply-To: <199402220319.AA18252@bolero.rahul.net> from "Mark Wedel" at Feb 21, 94 07:19:14 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1611 Status: RO > > AS part of the XPM library, I believe there is a ppmtoxpm program, and > a reverse program as well (xpmtoppm). These require parts of the > PbmPlus package to compile. > > The PbmPlus package has programs taht are called xpmtoppm and ppmtoxpm, > but these are apparantly meant for a different type of XPM file (maybe > real old version or something.) > > In any case, with the ppmtoxpm program, I do something like: > > xbmtopbm (bitmap file) | ppmtoxpm > (bitmap file).xpm > > Also, some people sent me bugs saying that their version of libXpm did > not have XCreatePixmapFromBuffer. If any of those people were able > to solve the problem via upgrading to the newest version of the XPM > library, could you send me mail and tell me what your old version was? > This way, I can put some note about it in the config.h file, so people > will know what the problem is (or what version of XPM they need.) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I ran into the same bug, the problem I believe is it was not linking in the xpm library when compiling crossfire. The problem is the defines are in in crosssite.def, which don't ever get seen by the Makefile. What did was the following : in crosssite.def : Changed the existing defines in this file to: #define XPM_PIX #define Xpm_Lib_Dir #define Xpm_Include Then in crossfire.cf added #ifdef XPM_PIX XPM_DEFINES = -DXpm_Pix XPM_LIBDIR = Xpm_Lib_Dir XPM_INCLUDE = Xpm_Include #endif Note: the XPM_INCLUDE is used when you put xpm in some strange place like we did here :> Tyler. From crossfire-request Tue Feb 22 04:19:20 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Tue, 22 Feb 1994 04:19:18 +0100 Received: by bolero.rahul.net id AA18252 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Mon, 21 Feb 1994 19:19:14 -0800 Date: Mon, 21 Feb 1994 19:19:14 -0800 From: Mark Wedel Message-Id: <199402220319.AA18252@bolero.rahul.net> To: tvangod@ecst.csuchico.edu Subject: Re: er...xbmtoxpm??? Cc: crossfire@ifi.uio.no Status: RO AS part of the XPM library, I believe there is a ppmtoxpm program, and a reverse program as well (xpmtoppm). These require parts of the PbmPlus package to compile. The PbmPlus package has programs taht are called xpmtoppm and ppmtoxpm, but these are apparantly meant for a different type of XPM file (maybe real old version or something.) In any case, with the ppmtoxpm program, I do something like: xbmtopbm (bitmap file) | ppmtoxpm > (bitmap file).xpm Also, some people sent me bugs saying that their version of libXpm did not have XCreatePixmapFromBuffer. If any of those people were able to solve the problem via upgrading to the newest version of the XPM library, could you send me mail and tell me what your old version was? This way, I can put some note about it in the config.h file, so people will know what the problem is (or what version of XPM they need.) --Mark From crossfire-request Tue Feb 22 01:56:44 1994 Return-Path: Received: from corpse.ecst.csuchico.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Tue, 22 Feb 1994 01:56:43 +0100 Received: from localhost (tvangod@localhost) by corpse.ecst.csuchico.edu (8.6.4/8.6.4) id QAA21319 for crossfire@ifi.uio.no; Mon, 21 Feb 1994 16:56:40 -0800 From: Tyler Van Gorder Message-Id: <199402220056.QAA21319@corpse.ecst.csuchico.edu> Subject: er...xbmtoxpm??? To: crossfire@ifi.uio.no Date: Mon, 21 Feb 1994 16:56:40 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 64 Status: RO Mark, how did you convert the xbms to xpms???? thanks. Tyler. From crossfire-request Mon Feb 21 11:16:49 1994 Return-Path: Received: from salmon.maths.tcd.ie by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Mon, 21 Feb 1994 11:16:48 +0100 Received: from salmon.maths.tcd.ie by salmon.maths.tcd.ie Local Delivery (salmon) id aa20892; 21 Feb 94 10:16 GMT To: crossfire@ifi.uio.no Subject: Re: Map ideas In-reply-to: <199402190755.AA04534@bolero.rahul.net> Date: Mon, 21 Feb 94 10:16:42 GMT From: Justin Mason Message-ID: <9402211016.aa20892@salmon.maths.tcd.ie> Status: RO In Mark's message of Fri, 18 Feb 94 23:55:38 PST, he sez: > or you could more easily change the exits by editing the map in your >favorite editor, and do a search/replace with the new map name. You >could even use sed if you wanted to. How's about using a preprocessor, like CPP, on the map files during loading? This would allow map admins to move things around easily, without requiring hacking on the source. eg., #define ENTERED_FROM "/blah/house" or whatever. It'd also allow repetitive patterns to be easily simplified, and #ifdefs would become possible. We (TrinityMOO) used to use it lots for our MOO source code when TMOO was up. ObCrossfire: haven't compiled the new one yet -- real work's getting in the way -- but I will, don't worry about that! ;) -- Justin Mason (Iona Technologies' unix caretaker, fixer-upper and disk-filler) with W3 hyplan at: http://www.iona.ie/www/hyplan/jmason.html I do not speak for Iona. "I was an infinitely hot and dense dot." Mark Leyner From crossfire-request Mon Feb 21 07:26:10 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Mon, 21 Feb 1994 07:25:41 +0100 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA19605; Mon, 21 Feb 1994 17:25:11 +1100 Date: Mon, 21 Feb 1994 17:25:11 +1100 From: "Rupert G. Goldie" Message-Id: <199402210625.AA19605@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no Subject: Generic maps Status: RO While I agree with Mark that it would be best to have man-made maps behind each house in a town I think there is some justification for having generic houses. Firstly, for 'realism' there should be a fair number of houses in a town, so that leaves us with lots of houses to fill out. Secondly, I find it kinda stoopid when you go into supposedly residential houses and find that they are now the lairs of all sorts of monsters. Maybe it's better just to leave 'boring' houses closed and have them just as decoration for town maps, but I think there is a place for generic houses. They would also be a lot less irritating than the random encounter maps. I find that the random maps just take up more time when I'm trying to go somewhere. One time when I was wandering around the outside of a castle to see if there where any other entrances I must have entered more than a dozen random maps and I was totally pissed off by the end. At least with generic houses you can choose to enter them and leave them again quickly. Rupert From crossfire-request Sun Feb 20 19:14:29 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be by ifi.uio.no with SMTP (8.6.4/ifi2.4) id ; Sun, 20 Feb 1994 19:14:26 +0100 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Sun, 20 Feb 94 19:13:03 +0100 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA25348; Sun, 20 Feb 94 19:14:24 +0100 Date: Sun, 20 Feb 94 19:14:24 +0100 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9402201814.AA25348@montefiore.ulg.ac.be> To: crossfire@ifi.uio.no, kjetilho@ifi.uio.no, quinet@montefiore.ulg.ac.be Subject: Re: client/server once again Status: RO > From: Kjetil Torgrim Homme > > ++---- Raphael Quinet: > || The client sends all commands issued by the user directly to the server, > || with almost no preprocessing (i.e. "move north", "eat food", "apply ..."). > ++--- Mark Wendel: > | It does have to be decided how the server responds to these commands. > | Does it send like an OK command, in which the client then updates the > | proper information (food, hp, inventory, etc), or instead, does it > | just send what information changes) > +--- > > The latter should be sufficient. [...] Yes. If the server keeps on sending information to the client, there's no need to acknowledge every command. If the client (in fine, the user) wants to see if a particular request has been executed, he will see it in the next data stream. Remember the debate about TCP vs UDP? Once again, here is the problem of ACK vs no ACK. Whichever of the two protocols is used (even a combination of the two is possible), I think we don't need any kind of "OK command". If a packet is lost (low probability), the user will try his command again, that's all. Notice: this is only true for the "client to server" side of the protocol. Imagine a packet loss when the server sends a "map update packet" to the client... We probably need TCP or acknowledged UDP in this case. > You _can_ get synchronization > problems, though. Ie. the player can do > > > > It glows briefly. > > The scroll turns to dust, nothing happened. > Your weapon is already enchanted. > > You get my drift? I don't think this is a real problem for the > players, though. > If the client has two separate windows, one for the command input and the other for all output, most users won't see the drift... ;-) Now I have one suggestion, that could be implemented in the current version of CrossFire: if a scroll has been identified, the user should receive the message "The scroll of turns to dust". This won't solve the drift problem, but this could help anyway, even in the current version. > +--- > | Map buffering may or may not be useful. IT really depends on how > | much the map changes. If XPM is being used, sending it the floor is > | probably a good idea, since that won't change. > | > | But if you have lots of monsters moving around, or a lot of things > | dieing and leaving items, buffering a portion of the map may have no > | use. > +--- > > Obviously, if you just send whatever the player should be able to see > (ie. do the LOS in the server), you will never send more data if you > allow the client to buffer data. OK, this is not totally true - the > protocol will be more complicated. > Map buffering is a must if a server is going to handle dozens (hundreds?) of clients accross the Internet. If something can be done that will reduce the bandwidth needed without creating security holes in the game (read: ways of cheating), then do it! > Rough idea for protocol: > [... edited out - read Kjetil's message for more info.] If a player is moving through a sparse map, most of the information sent by the server will be position updates. If he is moving along a diagonal line, two packets will be needed for each movement (update X, update Y). I see three ways of dealing with this: - Use Ketjil's character update packet, but with a bit mask for the stats instead of a number. The server could the send several stats updates in a single packet. - Use "block transfer" techniques: several map/stats/animations updates may be chained in a single block, together with the "go ahead" signal, which will be sent in a single "send" or "write" call. - Use a special packet for position updates (both X and Y). My preference goes to the second technique: this will be more efficient in terms of network traffic. There should also be some packets to give special information to the client, like the current map size, the number of known objects/archetypes (depends on what kind of information is sent to the client), etc. Another thing: the object name and other info should be sent as soon as the object comes into view, because you can examine an object that is not close to the player. Here, I make the assumption that the client handles the "examine" command by itself. If this is not the case (i.e. the client sends the request to the server, which responds with all the info), then forget this remark. > +--- > | Depending on map buffering, line of sight may or may not be done on > | the client side. > +--- > > I vote _no_ - I do not want precompiled clients, and I do not want > clients to effectively give players helmets of X-ray vision just like > that. > Well, maybe you're right. But computing the LOS eats a fair amount of processing power in the server. This is not a problem if there are only a few clients on one server, but what will happen if there are 50 players in the same game? But I don't like precompiled clients either... -Raphael From crossfire-request Sun Feb 20 14:42:05 1994 Return-Path: Received: from bera.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sun, 20 Feb 1994 14:42:05 +0100 From: Kjetil Torgrim Homme Received: from localhost by bera.ifi.uio.no ; Sun, 20 Feb 1994 14:42:04 +0100 Date: Sun, 20 Feb 1994 14:42:04 +0100 Message-Id: <19940220134204.26336.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: Mark Wedel's message of Sun, 20 Feb 1994 01:37:53 -0800 <199402200937.AA01260@bolero.rahul.net> Subject: Re: client/server once again Status: RO ++---- Raphael Quinet: || The client sends all commands issued by the user directly to the server, || with almost no preprocessing (i.e. "move north", "eat food", "apply ..."). ++--- Mark Wendel: | It does have to be decided how the server responds to these commands. | Does it send like an OK command, in which the client then updates the | proper information (food, hp, inventory, etc), or instead, does it | just send what information changes) +--- The latter should be sufficient. You _can_ get synchronization problems, though. Ie. the player can do It glows briefly. The scroll turns to dust, nothing happened. Your weapon is already enchanted. You get my drift? I don't think this is a real problem for the players, though. +--- | Map buffering may or may not be useful. IT really depends on how | much the map changes. If XPM is being used, sending it the floor is | probably a good idea, since that won't change. | | But if you have lots of monsters moving around, or a lot of things | dieing and leaving items, buffering a portion of the map may have no | use. +--- Obviously, if you just send whatever the player should be able to see (ie. do the LOS in the server), you will never send more data if you allow the client to buffer data. OK, this is not totally true - the protocol will be more complicated. Rough idea for protocol: OP CODE 0XXX - map update ======================= First byte: 0000YYYY - update line YYYY (relative to viewport) (limits display to 15 lines...) Second byte: XXXXLLLL - update begins at position XXXX and continues LLLL positions LLLL sequences: 0XXXXXXX XXXXXXXX - bottommost object is XXXXXXXXXXXXXXX (max 32768 object, hmm) zero or more of these: 1XXXXXXX XXXXXXXX - XXXXXXXXXXXXXXX is on top of previous object OP CODE 1XXX - character update ============================= First byte: 0001XXXX - change stat XXXX 0000 - X 0001 - Y 0010 - speed 0011 - weapon speed etc. Second byte: YYYYYYYY - relative (-128 to 127) for coordinates, some other scheme for speed. Might put Str Con etc. here. OP CODE 2000 - object name (sent when the player steps onto the object or similar, ========================== not when it comes into view!) First byte: 0002000 - update object names Second byte: XXXXXXX - update so many objects XXXXXXXX sequences: 0XXXXXXX XXXXXXXX - object number XXXXXXXXXXXXXXX NUL-terminated string - if necessary with a double NUL OR 1XXXXXXX XXXXXXXX - object number XXXXXXXXXXXXXXX 0YYYYYYY YYYYYYYY - same string as object YYYYYYYYYYYYYYY OP CODE 2001 - object animations ================================ [similar to 2000] OP CODE 20FF - forget object ============================ [...] OP CODE FFFF - go ahead ======================= The client should not update its display until it receives a go ahead. This way, the server can theoretically send several "change stat X" - may be needed for teleports etc. I'd better stop, this is just off the top of my head. I believe someone mentioned he was working on a draft for a protocol? | IT also goes back to up above. IF you actually send what objects | are on the map, then you also need the client to know about all the | archetypes. Well, with my above approach, the client is told that object 323 and 432 have the same animation sequence or name. I gather that is close enough. +--- | You could just send the entire map area where the person is (which I | think is 49 (7x7) squares?). [...] Then for each scroll. a command | could be sent like [...] where the map faces is the new row or | column to actually draw. [...] Likewise, you could have a map | update command, that just updates a specfic square. +--- That's a lot of special cases. (it's currently 11x11, btw - Frank was going to change that to 13x13) +--- | Depending on map buffering, line of sight may or may not be done on | the client side. +--- I vote _no_ - I do not want precompiled clients, and I do not want clients to effectively give players helmets of X-ray vision just like that. Kjetil T. From crossfire-request Sun Feb 20 10:38:00 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sun, 20 Feb 1994 10:37:57 +0100 Received: by bolero.rahul.net id AA01260 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Sun, 20 Feb 1994 01:37:53 -0800 Date: Sun, 20 Feb 1994 01:37:53 -0800 From: Mark Wedel Message-Id: <199402200937.AA01260@bolero.rahul.net> To: crossfire@ifi.uio.no, quinet@montefiore.ulg.ac.be Subject: Re: client/server once again Status: RO quinet@montefiore.ulg.ac.be (Raphael Quinet) writes (portions removed) >* The client sends all commands issued by the user directly to the server, > with almost no preprocessing (i.e. "move north", "eat food", "apply ..."). > It does have to be decided how the server responds to these commands. Does it send like an OK command, in which the client then updates the proper information (food, hp, inventory, etc), or instead, does it just send what information changes) The first has the advantage that the client needs to know about all the effects (how much food an item is worth, and what it does). But it also means less information needs to be trasmitted. (note, since the server still keeps track of information, the worst a rogue client can do is just display inaccurate information.) >* The server periodically sends the following information to every client: > - the current player position > - modifications to the map, other players positions, monster positions > - each time a new area of the map is entered, the server sends a map chunk > (say, 10x10 or 30x30) to the client, with all the objects in it > - the modifications to the inventory or player status > Map buffering may or may not be useful. IT really depends on how much the map changes. If XPM is being used, sending it the floor is probably a good idea, since that won't change. But if you have lots of monsters moving around, or a lot of things dieing and leaving items, buffering a portion of the map may have no use. IT also goes back to up above. IF you actually send what objects are on the map, then you also need the client to know about all the archetypes. You could just send the entire map area where the person is (which I think is 49 (7x7) squares?). If you figure two bytes per square (either using font position, or some number scheme that gets handshaked at start time), this is not very much. Then for each scroll. a command could be sent like: Scroll map right; map faces (series of numbers) where the map faces is the new row or column to actually draw. Obviosly, more compact commands would need to be used. (perhaps all commands/ identifiers are just two byte sequences or something.) Likewise, you could have a map update command, that just updates a specfic square. >* The client may handle the Line Of Sight algorithm. If one wants to cheat > (using a drone, for example), he could do this even if the server only > sends the visible bits to the client. This would only require a slightly > more complex algorithm, but won't prevent nasty guys from doing it. So, > why not do the LOS on the client side? This would free more processing > power on the server. > Depending on map buffering, line of sight may or may not be done on the client side. >* We can have several clients, using different display techniques. We could > even have a 3D-client (if you have ever played DOOM on a PC, you know what > I'm talking about). This may be silly, but why not? > As said, there is certainly nothing preventing multiple clients. Could use different toolkits or layouts, and different graphics or whatever, depending on each persons taste. There is certainly no reason that there can only be one client program. And if the client runs so that it does not have extra knowledge (which I think is really desirable), then this makes life easier (compared to if official binaries with RSA keys are needed for each client and OS/archictecture. >I could start working on that as soon as 0.90.2 is stable. Any comments? > > I think client server will be a great addition. All comments above are just thoughts and comments. In no way am I saying that this needs to be the official way the clients act. --Mark From crossfire-request Sat Feb 19 20:19:05 1994 Return-Path: Received: from hilja.it.lut.fi by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 19 Feb 1994 20:19:04 +0100 Received: from localhost (sonninen@localhost) by hilja.it.lut.fi (8.6.5/8.6.5/1.12.kim) id VAA13642; Sat, 19 Feb 1994 21:19:02 +0200 Date: Sat, 19 Feb 1994 21:19:02 +0200 From: Jarkko Sonninen Message-Id: <199402191919.VAA13642@hilja.it.lut.fi> To: crossfire@ifi.uio.no Subject: editable flag Status: RO Hi following short document seems to be missing from the distribution. (numbers means powers of 2, and they can be combined, of course (try arch-menu in crossedit (some new archetypes appears as monsters))) - Jarkko 8<--editable.README--8<--------8<--------8<--------8<--------8<--------8<----- Editable groups: One item can belong zero or more groups. Editable doesn't really mean that item is meant to use in the maps, but rather that is possibly use it in the special circumstance. It's preferred to use random items as treasures in the maps. Asterisk(*) marks groups that are really editable. 0. None - Internal archetypes (spells, abilities, map, etc.) *1. Monsters - all monsters, generators and NPC's *2. Exits - all buildings, towns, teleprorts and other exits *3. Treasures - Normally used maps as treasures *4. Backgrounds - different backgrounds (floors, woods, etc.) *5. Gates and door - everything that can be opened or closed *6. Special - directors, spinners, firewalls *7. Shop - All items needed in shops. *8. Normal objects - sacks, signs, gravestone, furnitures etc. *9. False walls - sacks, signs, gravestone, furnitures etc. 10. Walls - different walls, caves, dungeons etc. 11. Equipments - mainly weapons and armours 12. Rest treasures - foods, scrolls, potions, jewels, etc 13. Artifacts - Named weapons, special armors, etc From crossfire-request Thu Feb 24 08:51:26 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Thu, 24 Feb 1994 08:51:20 +0100 Received: by bolero.rahul.net id AA27247 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Wed, 23 Feb 1994 23:51:17 -0800 Date: Wed, 23 Feb 1994 23:51:17 -0800 From: Mark Wedel Message-Id: <199402240751.AA27247@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Next crossfire release. Status: RO I will probably make the next release in a week or so. There are several bug fixes, plus new archetypes. I will also use the 'chico' maps as the standard distribution. They seem to have done a first rate job on them. As time passes, old maps that meet the requirements will be added in. In any case, if you are working on patches or additions, I would probably say try to get them in by the end of the weekend if you want them in the Crossfire 0.90.2 release. However, if you are providing major changes or support, I may grant a few extra days. Mainly because this is not a real major release or upgrade. Here are the changes so far: Changes from Crossfire 0.90.1 to 0.90.2: New maps and archetypes added. Crossedit can now load maps that are compressed. Add Solaris 2.x compile support. Now prints out what the scroll name was that turned to dust. Minor artifact changes (ring of ice is blue, ring of fire is red) Horn range weapon now works properly, via using the + and - keys. New input method (From Jari Vanhala ). Looks like it should now be possible to define keys to do most every command. Made a few minor changes to default key file to make the present set up act like the previous one. Fixed triggers and magic mouth. These devices will now open gates as would be expected. The problem was that the opening routine expects to see the op->value of these to be one, in order to open the gate or whatever. Changed routines to toggle value between 0 and 1. Note: As I understand, trigger handles return to their original state, but keep the same value. That is, you pull the trigger handle, the handle returns to its original position, but gate opens. Pull handle again, handle returns to same position, but gate now closes. Or at least that is how I implemented the devices. Make some more changes to the is_magical routine. Hopefully, it will now detect all rings and amulets that are magical. --Mark From crossfire-request Thu Feb 24 08:45:23 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id ; Thu, 24 Feb 1994 08:45:11 +0100 Received: by bolero.rahul.net id AA26874 (5.67a8/IDA-1.5); Wed, 23 Feb 1994 23:45:04 -0800 Date: Wed, 23 Feb 1994 23:45:04 -0800 From: Mark Wedel Message-Id: <199402240745.AA26874@bolero.rahul.net> To: crossfire@ifi.uio.no, kjetilho@ifi.uio.no Subject: Re: XPMs in crossfire (Was Re: er...xbmtoxpm???) Status: RO I thank Kjetil for the color base XPM file. I was going to make one up myself, but he beat me too it. Getting rid of multiple archetypes for large objects has some other advantages also: Fewer archetypes Fewer objects Both of these are likely to increase speed of the game some. What can be done for large archetypes is for have a width & height element in each object, so say how many squares wide and high the object is. With non font drawing, it may actually be quicker. This is because instead of setting the clipmask for 4 or however many images, and then drawing them, just one image is drawn (and just one pixmaps needs to be set.) But there is also the problem in that different portions of the larger archetype may have different properties. For example, you can't walk through the roof of a shop, but can walk in the area below the roof. If say the magic shop just becomes one archetype, then it becomes extremely difficult to do this. Many areas do become mroe complicated. For that dragon, if someone tries to move into any of the squares he occupies, you need to get taht dragon's object. If at load time, you jsut clone 4 of him, then you are not gaining any space savings by having fewer objects. So you then need to have some link or something similar for all the spaces the dragon is on. I think at some time, the font and bitmap support will probably disappear. With client server, even relatively slow machines that are not running the server will probably be able to handle displaying the XPM images. I think for the time being, the present display method should be kept. While it will be a pain to move to a differing display method after the client split, I think more problems will be caused trying to force what would amount to be fairly major changes in quickly, so the client/server know what method to use. --Mark From crossfire-request Thu Feb 24 06:29:53 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Thu, 24 Feb 1994 06:29:21 +0100 Received: from alamein (alamein.aaii.oz.AU) by eden-valley.aaii.oz.AU with SMTP (5.65c/SMI-4.0/AAII) id AA27444; Thu, 24 Feb 1994 16:29:00 +1100 Received: by alamein; id AA18371; Thu, 24 Feb 1994 16:26:59 +1100 Message-Id: <9402240526.AA18371@alamein> To: "Rupert G. Goldie" Cc: crossfire@ifi.uio.no From: anthony baxter Reply-To: anthony.baxter@aaii.oz.au Subject: Re: client/server once again In-Reply-To: Message from "Rupert G. Goldie" of 1994-Feb-24 11:25:54, <199402240025.AA24383@eden-valley.aaii.oz.AU> Date: Thu, 24 Feb 1994 16:26:55 +1100 Sender: anthony@aaii.oz.au Status: RO "Rupert G. Goldie" wrote: > I suspect there are plenty of optimisations we can make to Crossfire > to speed it up. At some stage someone has to sit down with a profiler > (anyone have Quantify ?) and see where the slow bits are. This is a totally wild guess, but maybe in X11? :-) Anthony From crossfire-request Thu Feb 24 01:50:01 1994 Return-Path: Received: from bera.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Thu, 24 Feb 1994 01:50:00 +0100 From: Kjetil Torgrim Homme Received: from localhost by bera.ifi.uio.no ; Thu, 24 Feb 1994 01:49:59 +0100 Date: Thu, 24 Feb 1994 01:49:59 +0100 Message-Id: <19940224004959.14397.bera.ifi.uio.no@ifi.uio.no> To: crossfire Subject: Spoilers Status: RO Hi, Lars and I sat down to fix the automatic spoiler generation, and it was easier than I thought. I put these files on ftp.ifi.uio.no: # a spoiler which goes with 0.90.1 - the one included is for the # unreleased ALPHA-version 0.90.0 152 /pub/crossfire/crossfire-0.90.1.spoiler.ps.gz # sources to replace doc/spoiler in 0.90.1 17 /pub/crossfire/crossfire-0.90.1.spoilgen.tar.Z Be warned that the spoiler.ps is now in colour PostScript. Many old printers have a problem with this. Kjetil T. From crossfire-request Thu Feb 24 01:27:14 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Thu, 24 Feb 1994 01:26:31 +0100 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA24383; Thu, 24 Feb 1994 11:25:54 +1100 Date: Thu, 24 Feb 1994 11:25:54 +1100 From: "Rupert G. Goldie" Message-Id: <199402240025.AA24383@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no Subject: Re: client/server once again Status: RO > I see three ways of dealing with this: > - Use Ketjil's character update packet, but with a bit mask for the stats > instead of a number. The server could the send several stats updates in a > single packet. > - Use "block transfer" techniques: several map/stats/animations updates may > be chained in a single block, together with the "go ahead" signal, which > will be sent in a single "send" or "write" call. > - Use a special packet for position updates (both X and Y). > > My preference goes to the second technique: this will be more efficient in > terms of network traffic. Given the overhead of the underlying network protocols, and the need for rapid interactive response, I think we have no alternative but to send updates as blocks. With TCP/IP you're looking at a 40 byte overhead _per_packet_ (see "Internetworking with TCP/IP" p 141) so you might as well throw in plenty of data bytes as well. To get the interactive repsonse you have to tell the OS not to packetize the data itself with setsockopt and TCP_NODELAY. One other thing to consider is the time it takes to assemble and disassemble a packet. If we use fixed size packets with a set structure it can be much faster than variable length with a free-form structure, but the difference in cost may just be noise compared to other things. > Well, maybe you're right. But computing the LOS eats a fair amount of > processing power in the server. This is not a problem if there are only a few > clients on one server, but what will happen if there are 50 players in the > same game? But I don't like precompiled clients either... > > -Raphael > I suspect there are plenty of optimisations we can make to Crossfire to speed it up. At some stage someone has to sit down with a profiler (anyone have Quantify ?) and see where the slow bits are. Rupert From crossfire-request Thu Feb 24 00:19:19 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Thu, 24 Feb 1994 00:19:12 +0100 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA23771; Thu, 24 Feb 1994 10:18:31 +1100 Date: Thu, 24 Feb 1994 10:18:31 +1100 From: "Rupert G. Goldie" Message-Id: <199402232318.AA23771@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no Subject: Re: source for new spoilers? Status: RO > > Compiling crossedit flailed miserably. Lots of header file errors, > > probably related to POSIX stuff. I'll be pouring over that stuff to > > try to figure it out. If anyone else on a NeXT gets this to compile, > > I would appreciate any hints on what they did to get it to work. > > Again, same here. I gave up seeing as crossfire itself was OK. Under SunOS 4.1.3, X11R5 crossedit compiled right off. Under Ultrix 4.2, X11R5 I had to edit crossedit/include/Posix.h to define __POSIX and to include before > On the source for the new spoilers (which look great by the way!), I want > to make them available on the WWW by latex2html'ing them, but I've only > got the postscript not the .tex files. Can whoever has these mail me a copy? > You can already get to the postscript spoilers at the following URL: > > http://www.cm.cf.ac.uk:/Fun/ > The current Imakefile for making the spoilers is totally broken now that the bitmaps are broken into subdirectories. Mark is looking at it. The TeX files are generated by the Makefile. (The spoilers are definitely way cool now !) Rupert From crossfire-request Wed Feb 23 23:46:38 1994 Return-Path: Received: from bera.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Wed, 23 Feb 1994 23:46:37 +0100 From: Kjetil Torgrim Homme Received: from localhost by bera.ifi.uio.no ; Wed, 23 Feb 1994 23:46:36 +0100 Date: Wed, 23 Feb 1994 23:46:36 +0100 Message-Id: <19940223224636.14343.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: Nick Williams's message of Wed, 23 Feb 1994 12:10:52 +0000 (GMT) Subject: Re: XPMs in crossfire (Was Re: er...xbmtoxpm???) Status: RO +--- Nick Williams: | You'll find that the most basic editor supports symbolic names: pixmap. | This is the XPM version of bitmap. Crude, but it works. +--- Great tip, Nick! We actually had a copy here already, and I never knew. On the other hand, that was version _1.1_ - and it was extremely buggy. The newest version is 2.3, and it is quite nice! (I compiled it with Motif support.) Much nicer than bitmap, at least, but not as versatile as xpaint. In any case, I thought I'd save you some hassle with this xpm-file, I call it "template". It's an empty 24x24 pixmap with all the colours Mark listed defined in it: (I hope it will not be MIME-encoded ;-) ----- 8-< ----- cut here ----- 8-< ----- cut here ----- 8-< ----- /* XPM */ static char *template[] = { "24 24 29 1", " c None s Transparent", ". c Black", "X s Dark gray c Grey25", "o s Gray c Grey50", "O s Light gray c Grey75", "+ c White", "@ s Dark red c Firebrick", "# c Red", "$ s Light red c Salmon", "% s Dark green c SeaGreen", "a c Green", "b s Light green c PaleGreen", "c s Dark blue c Navy", "d c Blue", "e s Light blue c DodgerBlue", "f c Goldenrod s Dark yellow", "g s Yellow c Gold", "h s Light yellow c Yellow", "i s Dark magenta c Maroon", "j c Magenta", "k s Light magenta c Pink", "l s Dark cyan c Cyan4", "m s Cyan c Cyan2", "n s Light Cyan c Cyan", "o s Dark orange c Chocolate", "p c Orange", "q s Dark brown c Peru", "r s Brown c Sienna", "s s Light brown c SaddleBrown", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " "}; ----- 8-< ----- cut here ----- 8-< ----- cut here ----- 8-< ----- +--- | (e.g. a house is four characters, a dragon is about 9 characters. | Why not just make them one image?) +------- This question must be settled before the client/server protocol is decided upon. + simplifies /arch-directory and maintenance - requires rewriting a fair bit of the display code - necessitates break with fonts (fonts are a _lot_ faster on old displays) - animations can't be optimised (you can't get the effect I have on my castle with the flags which flutter in the wind asynchronously :-) (The castle with the moat) - similarily, you can't have monsters which are immune lightning except in their faces etc. The last two objections do not necessarily follow, but if you want to keep the linked "sub"-archetypes, much of the maintenance advantage goes away. Kjetil T. From crossfire-request Wed Feb 23 13:11:50 1994 Return-Path: Received: from barney.cs.city.ac.uk by ifi.uio.no with SMTP (8.6.4/ifi2.4) id ; Wed, 23 Feb 1994 13:11:47 +0100 Received: from wilma.cs.city.ac.uk by barney.cs.city.ac.uk; Wed, 23 Feb 1994 12:15:22 GMT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.wilma.cs.city.ac.uk.sun4.41 via MS.5.6.wilma.cs.city.ac.uk.sun4_41; Wed, 23 Feb 1994 12:10:52 +0000 (GMT) Message-Id: Date: Wed, 23 Feb 1994 12:10:52 +0000 (GMT) From: Nick Williams Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: kjetilho@ifi.uio.no, quinet@montefiore.ulg.ac.be (Raphael Quinet) Subject: XPMs in crossfire (Was Re: er...xbmtoxpm???) Cc: crossfire@ifi.uio.no, master@rahul.net In-Reply-To: <9402230926.AA14590@montefiore.ulg.ac.be> References: <9402230926.AA14590@montefiore.ulg.ac.be> Status: RO Excerpts from games.Crossfire: 23-Feb-94 Re: er...xbmtoxpm??? Raphael Quinet@montefior (808) > I have yet to find a pixmap editor that supports symbolic names. For now, > I use manual or semi-automatic editing of XPM files when I want to use the > advanced features of the XPM library. :-( But I've been told that some > editors do support those things. Maybe someone could tell me where I can > find these programs? You'll find that the most basic editor supports symbolic names: pixmap. This is the XPM version of bitmap. Crude, but it works. For small images such as that used in crossfire, it's probably got all the features required. You can get it from the X contrib site (ftp.x.org or src.doc.ic.ac.uk or.... ) BTW: if there will be a move to xpm's opposed to fonts in the future, would it be possible to switch to single images at the same time, rather than the strangeness of images constructed from a set of fixed size images (e.g. a house is four characters, a dragon is about 9 characters. Why not just make them one image?). This would make construction of new archetypes and other related things much easier. Nick Williams E-mail: njw@cs.city.ac.uk (MIME and ATK) Systems Architecture Research Centre, Tel: +44 71 477 8551 London, EC1V 0HB Fax: +44 71 477 8587 From crossfire-request Wed Feb 23 10:26:15 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be by ifi.uio.no with SMTP (8.6.4/ifi2.4) id ; Wed, 23 Feb 1994 10:26:12 +0100 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Wed, 23 Feb 94 10:24:49 +0100 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA14590; Wed, 23 Feb 94 10:26:10 +0100 Date: Wed, 23 Feb 94 10:26:10 +0100 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9402230926.AA14590@montefiore.ulg.ac.be> To: kjetilho@ifi.uio.no Subject: Re: er...xbmtoxpm??? Cc: crossfire@ifi.uio.no, master@rahul.net Status: RO > From: Kjetil Torgrim Homme > Symbolic colour names sound very nice, of course, BUT! Is there any > graphic editor which supports them? xpaint saves files with absolute > RGB values. I have yet to find a pixmap editor that supports symbolic names. For now, I use manual or semi-automatic editing of XPM files when I want to use the advanced features of the XPM library. :-( But I've been told that some editors do support those things. Maybe someone could tell me where I can find these programs? > I don't even have the faintest idea how the format of *.pix works (can > it really support all the fetures Raphael talks of?), so I'd better > shut up :-) In the XPM package, you will find a doc file in PostScript format ("xpm.ps") that describes all these features. -Raphael From crossfire-request Wed Feb 23 10:17:19 1994 Return-Path: Received: from beli.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id ; Wed, 23 Feb 1994 10:17:18 +0100 From: Kjetil Torgrim Homme Received: from localhost by beli.ifi.uio.no ; Wed, 23 Feb 1994 10:17:18 +0100 Date: Wed, 23 Feb 1994 10:17:18 +0100 Message-Id: <19940223091718.11630.beli.ifi.uio.no@ifi.uio.no> To: quinet@montefiore.ulg.ac.be CC: crossfire@ifi.uio.no, master@rahul.net, quinet@montefiore.ulg.ac.be In-reply-to: Raphael Quinet's message of Wed, 23 Feb 94 10:02:31 +0100 <9402230902.AA14479@montefiore.ulg.ac.be> Subject: Re: er...xbmtoxpm??? Status: RO Symbolic colour names sound very nice, of course, BUT! Is there any graphic editor which supports them? xpaint saves files with absolute RGB values. Hmm, come to think of it, there's an easy solution to this. We only need a script to change RGB values to symbolic names after the editing is finished. If we have a small list containing the "valid" colours, it would be easy to spot pixmaps with "illegal" colours, too. +--- Mark Wedel: | Are you saying that the actual RGB color values should be put into | the XPM files (ie, instead of 'red', have it ff0000). +------- To clarify - if two pixmap _designers_ have different rgb.txt, Crossfire would use more colours than planned. I don't even have the faintest idea how the format of *.pix works (can it really support all the fetures Raphael talks of?), so I'd better shut up :-) Kjetil T. From crossfire-request Wed Feb 23 10:02:37 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Wed, 23 Feb 1994 10:02:34 +0100 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Wed, 23 Feb 94 10:01:11 +0100 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA14479; Wed, 23 Feb 94 10:02:31 +0100 Date: Wed, 23 Feb 94 10:02:31 +0100 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9402230902.AA14479@montefiore.ulg.ac.be> To: crossfire@ifi.uio.no, master@rahul.net, quinet@montefiore.ulg.ac.be Subject: Re: er...xbmtoxpm??? Status: RO > From master@rahul.net Wed Feb 23 09:27:27 1994 > > In terms of black and white, whether a color should be marked as black > or white can depend on the item. In some cases, certain colors might > be meant as foreground (and thus black), and in other cases, that same > color might be part of the background (and thus white.) > > For greycale machines, I would first be interested in seeing how > the XPM library handled colors that are loaded (does it turn them into > an approximate grey?) But in any case, what shade of grey it should be > should probably be determined on whether the object is in the foreground > or background. > You have two alternatives if you want to display a color on a greyscale or black and white monitor: - Use the color as is, and let the X server do the necessary conversion. This is the easiest way, but you may not be able to distinguish colors that are close in brightness, like dark green and dark blue, or light yellow and white. - Use the nice features in the XPM library and provide different conversions for the same color. For each "color", you may give a color name for color displays, but also a (possibly different) color name for grayscale displays and a (possibly different) color name for black and white displays. Using this feature, you may for example convert the dark green pixels in a picture to white (on black and white displays), and convert the dark blue pixels to black. You will then be able to see the differences between the two colors. This will require a clever design for each face, but will lead to better results. [about the symbolic names for foreground and background] > > I suppose (what maybe Raphael was talking about) is have the same face > for numerous archetypes, but just keep one copy on disk. As you laod them, > then color them for the different archetypes. > That's more or less what I meant. > This saves a little disk space, but makes the program more complicated. > And since the crossfire.pix file can be gzip'd, the size savings is > very small. > Ok. Let's keep the program simple (Simple? Only joking...). -Raphael From crossfire-request Wed Feb 23 09:27:17 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Wed, 23 Feb 1994 09:27:12 +0100 Received: by bolero.rahul.net id AA17470 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Wed, 23 Feb 1994 00:27:09 -0800 Date: Wed, 23 Feb 1994 00:27:09 -0800 From: Mark Wedel Message-Id: <199402230827.AA17470@bolero.rahul.net> To: crossfire@ifi.uio.no, master@rahul.net, quinet@montefiore.ulg.ac.be Subject: Re: er...xbmtoxpm??? Status: RO Kjetil Torgrim Homme writes: > >Actually, no - the RGB values should be compensated for. Let me >rephrase that: "gold" should always look the same, but the RGB values >can differ wildly from machine to machine. OK, this is theory - most >sites have one rgb.txt for all of their differing monitors... > >How does this affect us? Well - we'll need to choose the real RGB >values, not the names, or else we may risk having lots of pixmaps with >_similar_ colours. Mark, I guess your rgb.txt file is as good as any. > >BTW, you chose the same selection of colours I was going to suggest :-) Are you saying that the actual RGB color values should be put into the XPM files (ie, instead of 'red', have it ff0000). I really don't know what this will gain. The XPM library can either look it up at load time, or it is defined as that value. The only time this would matter is if the rgb.txt files have different definitions for the colors. And if this is so, assumably it is so that the colors look close to the standard on differing monitors. Embedding the RGB values will not make any difference. But as an example, I have 2 color sun 3/60's. The color between the two monitors is slightly different. Whether the RGB color is embedded in the XPM file, or the name is used, the two objects will look slightly different on the two monitors. The best way I could fix that would be to to have one rgb.txt file per machine, and tweak the color values until they match. anthony@aaii.oz.au wrote: >Has anyone thought about non-colour machines, and picking equivalents >for each of the colours? There are two non color machines - black and white (in which case, equivalants are not necessary), and greyscale machines. In terms of black and white, whether a color should be marked as black or white can depend on the item. In some cases, certain colors might be meant as foreground (and thus black), and in other cases, that same color might be part of the background (and thus white.) For greycale machines, I would first be interested in seeing how the XPM library handled colors that are loaded (does it turn them into an approximate grey?) But in any case, what shade of grey it should be should probably be determined on whether the object is in the foreground or background. quinet@montefiore.ulg.ac.be (Raphael Quinet) wrote: > >There's no problem, because you can use symbolic names in XPM files. >Why not use the symbolic names "foreground" and "background" (or >"face_foreground" and "face_background") in every image? You can then >bind a value to the symbolic name at load time, by putting the desired >values in the XpmColorSymbol structure. > > > I looked into the symbolic names. The way I read it, you can get the pixel value of that symbolic color, and this change the color of that pixel. However, as I understand it, it would change the color for all objects using that shape. In other words, you could not make foreground of some face blue, and also red, and display it at the same time. And this also makes the code a bit more complicated. Because objects may use several shades of a color to make the pixmap look better. You then need to change all the color elements to the new color. I suppose (what maybe Raphael was talking about) is have the same face for numerous archetypes, but just keep one copy on disk. As you laod them, then color them for the different archetypes. This saves a little disk space, but makes the program more complicated. And since the crossfire.pix file can be gzip'd, the size savings is very small. --Mark From crossfire-request Wed Feb 23 08:59:13 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Wed, 23 Feb 1994 08:59:11 +0100 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Wed, 23 Feb 94 08:57:48 +0100 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA14102; Wed, 23 Feb 94 08:59:06 +0100 Date: Wed, 23 Feb 94 08:59:05 +0100 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9402230759.AA14102@montefiore.ulg.ac.be> To: crossfire@ifi.uio.no, master@rahul.net Subject: Re: er...xbmtoxpm??? Status: RO > From: Mark Wedel > > XPM files should be convereted by hand for best look. However, this > does create some problems: > > 1) Several archetypes may use the same face, and color it differently > 2) This means that a unique face for each archetype that wants to color > it differently is needed. > 3) the color foregroudn and background elements in each object description > now only become useful for magic mapping. > > None of these are great problems, but it will increase the number of > XPM files. > There's no problem, because you can use symbolic names in XPM files. Why not use the symbolic names "foreground" and "background" (or "face_foreground" and "face_background") in every image? You can then bind a value to the symbolic name at load time, by putting the desired values in the XpmColorSymbol structure. -Raphael From crossfire-request Wed Feb 23 02:57:14 1994 Return-Path: Received: from beli.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Wed, 23 Feb 1994 02:57:13 +0100 From: Kjetil Torgrim Homme Received: from localhost by beli.ifi.uio.no ; Wed, 23 Feb 1994 02:57:12 +0100 Date: Wed, 23 Feb 1994 02:57:12 +0100 Message-Id: <19940223015712.9004.beli.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: Mark Wedel's message of Tue, 22 Feb 1994 17:19:15 -0800 <199402230119.AA23422@bolero.rahul.net> Subject: Re: XPM & Colors Status: RO +--- Mark Wedel: | So I tried to choose colors that were different, covered a broad | spectrum, and looked good. From monitor to monitor, the look will | change, but I don't think my monitor is that far out of whack | compared to most. +------- Actually, no - the RGB values should be compensated for. Let me rephrase that: "gold" should always look the same, but the RGB values can differ wildly from machine to machine. OK, this is theory - most sites have one rgb.txt for all of their differing monitors... How does this affect us? Well - we'll need to choose the real RGB values, not the names, or else we may risk having lots of pixmaps with _similar_ colours. Mark, I guess your rgb.txt file is as good as any. BTW, you chose the same selection of colours I was going to suggest :-) Kjetil T. From crossfire-request Wed Feb 23 02:19:22 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Wed, 23 Feb 1994 02:19:18 +0100 Received: by bolero.rahul.net id AA23422 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Tue, 22 Feb 1994 17:19:15 -0800 Date: Tue, 22 Feb 1994 17:19:15 -0800 From: Mark Wedel Message-Id: <199402230119.AA23422@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: XPM & Colors Status: RO Here are the colors that I think work well: (Note: The color in parantheses is the color that should be used. The color before the parentheses is the approximate color that is being matched. If an entry has no parentheses, then that is the color that should be used.) All of the colors existed in my /usr/lib/X11/rgb.txt file. 00 - transparent 01 - black 02 - dark grey (grey25) 03 - grey (grey50) 04 - light grey (grey75) 05 - white 06 - dark red (firebrick) 07 - red 09 - light red (salmon) 09 - dark green (sea green) 10 - green 11 - light green (pale green) 12 - dark blue (navy) 13 - blue 14 - light blue (dodger blue) 15 - light yellow (yellow) 16 - yellow (gold) 17 - dark yellow (goldenrod) 18 - dark magneta (maroon) 19 - magneta 20 - light magenta (pink) 21 - dark cyan (cyan4) 22 - cyan2 23 - light cyan (cyan) 24 - dark orange (chocolate) 25 - orange 26 - light brown (peru) 27 - brown (sienna) 28 - dark brown (saddle brown) I used the xco program to look through the various colors. I found that in general, many of the 'light' colors (light cyan, light blue, etc), where either white with just a tint of color, or did not even exist. Likewise, most of the 'dark' colors were quite dark. So I tried to choose colors that were different, covered a broad spectrum, and looked good. From monitor to monitor, the look will change, but I don't think my monitor is that far out of whack compared to most. Any suggestions or additions are welcome. --Mark From crossfire-request Wed Feb 23 00:39:43 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Wed, 23 Feb 1994 00:39:34 +0100 Received: by bolero.rahul.net id AA15637 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Tue, 22 Feb 1994 15:39:30 -0800 Date: Tue, 22 Feb 1994 15:39:30 -0800 From: Mark Wedel Message-Id: <199402222339.AA15637@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Re: er...xbmtoxpm??? Status: RO Should XPM library be included: PRobably not, since it is not required to compile crossfire (you can just turn the XPM option off.) Migrating to only XPM files should be done eventually. Almost certainly not before we move to client/server (this way, the client can hold a local copy of the XPM files on disk instead of downloading them from teh server at each startup.) When using just bitmaps, the time it takes to download (if you have a slow connection) is measurable. While XPM files are inefficent on disk, I don't think they are that bad in memory. Also, the crossfire.pix file can be compressed for great savings (knock it down from over 1 megabyte to about 120K I believe.) XPM files should be convereted by hand for best look. However, this does create some problems: 1) Several archetypes may use the same face, and color it differently 2) This means that a unique face for each archetype that wants to color it differently is needed. 3) the color foregroudn and background elements in each object description now only become useful for magic mapping. None of these are great problems, but it will increase the number of XPM files. Other notes: Location of XPM_LIBDIR in crosssite.def: Like motions options in that file, many only need to be set if you want to do someting unusual. If the XPM library is in the standard place, XPM_LIBDIR should not be needed for the linker to find it. Colors: The set Petri posted looks good. But there is no real reasy (easy) solution. IF you just use the base 16 (or is it 12) that is used right now, pixmaps will not look a lot better except for the outlines. However, people obviously can't just choose whatever they want, or the set of colors may become above 256. but I do believe that the routines in the XPM library that creates the pixmaps will do color matchin, if it can not allocate the color requested. There are also other ideas for allocating colors. 216 colors could be used, which each R,G, and B element having 6 possible values. 125 could be done in the same way, but with each RGB element having 5 possible values (0, 64, 128, 192, 255). This gives a wide color selection, but colors are not necessarily close together. However, for now, I think we should restrict ourselves to the Petri posted, with a few additions. Here is the list: 00 - transparent 01 - black 02 - dark gray 03 - grey 04 - light gray 05 - white 06 - dark red 07 - red 08 - light red 09 - dark green 10 - green 11 - light green 12 - dark blue 13 - blue 14 - light blue 15 - dark yellow 16 - yellow 17 - light yellow 18 - dark magneta 19 - magneta 20 - light magneta 21 - dark syan 22 - syan 23 - light syan Additions from me floow: From crossfire-request Tue Feb 22 20:18:02 1994 Return-Path: Received: from alaska.et.byu.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Tue, 22 Feb 1994 20:18:00 +0100 Received: by alaska.et.byu.edu; Tue, 22 Feb 1994 12:17:48 -0700 From: iversons@alaska.et.byu.edu (Scott Iverson) Message-Id: <199402221917.MAA07562@alaska.et.byu.edu> Subject: Re: To: ftww@cs.su.oz.au Date: Tue, 22 Feb 94 12:17:48 MST Cc: crossfire@ifi.uio.no In-Reply-To: <19940218022100.15763.ifi@ifi.uio.no>; from "Fred the Wonder Worm" at Feb 18, 94 1:20 pm Mailer: Elm [revision: 72.14] Status: RO > > Well, if query_name() were modified to return name if count is 1, or > count + plural_name if count > 1, then you can get rid of need_an. > What you do if count is 0 is problematical, but I've never really > understood what to do with an object with count 0 anyway. > For count 0, we could call it a broken item (example, broken chainmail +1) From crossfire-request Tue Feb 22 19:48:18 1994 Return-Path: Received: from po5.andrew.cmu.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Tue, 22 Feb 1994 19:48:17 +0100 Received: from localhost (postman@localhost) by po5.andrew.cmu.edu (8.6.4/8.6.4) id NAA23313 for crossfire@ifi.uio.no; Tue, 22 Feb 1994 13:48:10 -0500 Received: via switchmail; Tue, 22 Feb 1994 13:48:07 -0500 (EST) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Tue, 22 Feb 1994 13:36:04 -0500 (EST) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Tue, 22 Feb 1994 13:36:03 -0500 (EST) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.madhatter.ws.cc.cmu.edu.sun4c.411 via MS.5.6.madhatter.ws.cc.cmu.edu.sun4c_411; Tue, 22 Feb 1994 13:36:03 -0500 (EST) Message-ID: Date: Tue, 22 Feb 1994 13:36:03 -0500 (EST) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: er...xbmtoxpm??? In-Reply-To: <19940222122219.7522.bera.ifi.uio.no@ifi.uio.no> References: <19940222122219.7522.bera.ifi.uio.no@ifi.uio.no> Status: RO Kjetil Torgrim Homme writes: > I'll redraw my own bitmaps (~100), but was there a consensus on which > colours should be used? I think we should restrict ourselves to a set > of 40 or so colours. This is a very good idea. Does anyone have the list that Apple uses to draw their color icons? Apple's colors seem to work well. -Eric ********************************************************* "It seemed like a good idea at the time" -The Mad Hatter "Yes, you're very smart. Shut up." -In "The Princess Bride" ********************************************************* From crossfire-request Tue Feb 22 16:31:58 1994 Return-Path: Received: from eero.it.lut.fi by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Tue, 22 Feb 1994 16:31:57 +0100 Received: from localhost (hevi@localhost) by eero.it.lut.fi (8.6.5/8.6.5/1.12.kim) id RAA18040; Tue, 22 Feb 1994 17:31:54 +0200 Date: Tue, 22 Feb 1994 17:31:52 +0200 (EET) From: Petri Heinil{ Subject: Re: er...xbmtoxpm??? To: crossfire@ifi.uio.no In-Reply-To: <19940222122219.7522.bera.ifi.uio.no@ifi.uio.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Tue, 22 Feb 1994, Kjetil Torgrim Homme wrote: > I'll redraw my own bitmaps (~100), but was there a consensus on which > colours should be used? I think we should restrict ourselves to a set > of 40 or so colours. Well, the number of colors ? 16 is nice, if there are some day made a own file format for pixmaps. The xpm format comsumes quite a amount of space due to it`s design-direction that it`s visible in file-level. But a see that later the image need to be packed into one file as a binary format. By 16 colors there can be packed two pixels into one byte. so image takes 288 bytes. If the 16 isn`t enough at all, then the next size is 256 thinking as size. There could use some kind of compression (RLE,..) to image, but I think the benefit for 24x24 size if quite small. So if compressed, the file as itself should compressed by gzip or compress to get benefit. 256 colors is naturally too much because most of us use 8-bits X-servers. So colors should be saved for other programs as well. Here is just a another set of colors (haven`t this discussed before ? :) : 00 - transparent 01 - black 02 - dark gray 03 - grey 04 - light gray 05 - white 06 - dark red 07 - red 08 - light red 09 - dark green 10 - green 11 - light green 12 - dark blue 13 - blue 14 - light blue 15 - dark yellow 16 - yellow 17 - light yellow 18 - dark magneta 19 - magneta 20 - light magneta 21 - dark syan 22 - syan 23 - light syan - here is color-circle gone round (not in order). Well there are 23 colors now :) - the coding should be systematic if possible - The RGB-coding isn`t good here because we have allocate colormap anyway. ///////////////////////// Petri Heinila ///////////////////////// email: Petri.Heinila@lut.fi www: Homepage mail: Ainonkatu 2A 53100 Lappeenranta Finland, Europe tel: 3624 (in. LUT) From crossfire-request Tue Feb 22 13:22:20 1994 Return-Path: Received: from bera.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id ; Tue, 22 Feb 1994 13:22:19 +0100 From: Kjetil Torgrim Homme Received: from localhost by bera.ifi.uio.no ; Tue, 22 Feb 1994 13:22:19 +0100 Date: Tue, 22 Feb 1994 13:22:19 +0100 Message-Id: <19940222122219.7522.bera.ifi.uio.no@ifi.uio.no> To: master@rahul.net CC: tvangod@ecst.csuchico.edu, crossfire@ifi.uio.no In-reply-to: Mark Wedel's message of Mon, 21 Feb 1994 21:40:37 -0800 <199402220540.AA25329@bolero.rahul.net> Subject: Re: er...xbmtoxpm??? Status: RO +--- Mark Wedel: | I believe the problem was simply solved by changing the location | commands to just straight to the following: | #define XPM_PIX | XPM_LIBDIR = /usr/local/lib/ I believe the default should be LIBDIR. More and more installations come with XPM as part of the general X11R5 release. Does anyone know whether X11R6 will include XPM? It sounds likely to me... +--- Petri Heinil{: | - should the working xpm-library be includes into release ? I'd say no (obviously :-) | - should there migrate to use only pixmaps ? Yes, eventually. If supporting fonts is troublesome, it should go away. (Ie. don't remove it just for the sake of removing it) | - the converting jop; most images should enchant | by hand to look good I'll redraw my own bitmaps (~100), but was there a consensus on which colours should be used? I think we should restrict ourselves to a set of 40 or so colours. Kjetil T. From crossfire-request Sat Feb 19 08:56:02 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sat, 19 Feb 1994 08:55:56 +0100 Received: by bolero.rahul.net id AA04534 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Fri, 18 Feb 1994 23:55:38 -0800 Date: Fri, 18 Feb 1994 23:55:38 -0800 From: Mark Wedel Message-Id: <199402190755.AA04534@bolero.rahul.net> To: Tero.Haatanen@lut.fi, mehlhaff@ocf.berkeley.edu Subject: Re: Map ideas Cc: crossfire@ifi.uio.no, mehlhaff@plague.Berkeley.EDU Status: RO or you could more easily change the exits by editing the map in your favorite editor, and do a search/replace with the new map name. You could even use sed if you wanted to. I think a better solution to the empty building problem is to actually fill those buildings up. Consolidate some of the towns (like I posted in the map guideline message). --Mark From crossfire-request Fri Feb 25 07:20:25 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 25 Feb 1994 07:20:21 +0100 Received: by bolero.rahul.net id AA04046 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 24 Feb 1994 22:20:16 -0800 Date: Thu, 24 Feb 1994 22:20:16 -0800 From: Mark Wedel Message-Id: <199402250620.AA04046@bolero.rahul.net> To: crossfire@ifi.uio.no, peterm@soda.berkeley.edu Subject: Re: xpm question Status: RO If people submit archetypes and the corresponding images in non xpm format, but bitmap format only, I will convert them to xpm files. I'll probably also run the auto-color script on them also. --Mark From crossfire-request Fri Feb 25 07:17:07 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 25 Feb 1994 07:17:04 +0100 Received: by bolero.rahul.net id AA03809 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 24 Feb 1994 22:16:19 -0800 Date: Thu, 24 Feb 1994 22:16:19 -0800 From: Mark Wedel Message-Id: <199402250616.AA03809@bolero.rahul.net> To: anthony.baxter@aaii.oz.au, drew@kinglear.cs.Colorado.EDU Subject: Re: client/server once again Cc: crossfire@ifi.uio.no Status: RO It can also depend on the floating point performance of the machines. If your on a 386 without and fpu, I can see performance being real bad with the floatin point operations. Converting all floats to ints, and just knowing that they are 1000 (or 1,000,000) above their true value would be doable. However, either archetypes/objects need to be converted at load time (no big deal, but could create confusion when someone looks at both the code and the archetype), or all archetypes need to be converted. After I hopefully get most of the feature patches for this version, I will look at speeding things up. From the Amiga port, I heard that keeping a seperate list for living/animated objects is also a big performance gain. However, after converting to client/server, this may be lessened to some extent. --Mark From crossfire-request Fri Feb 25 05:51:12 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 25 Feb 1994 05:51:10 +0100 Received: from localhost (peterm@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id UAA29998 for crossfire@ifi.uio.no; Thu, 24 Feb 1994 20:51:06 -0800 Date: Thu, 24 Feb 1994 20:51:06 -0800 From: Peter Mardahl Message-Id: <199402250451.UAA29998@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: xpm question Status: RO I don't have any tools for converting xbm to xpm files. Could some kind soul either supply me with a DEC binary of such a thing, or convert some archetypes for me? We at soda have a lot of new archetypes that should get included in the next release, and indeed must get included if things are to work properly. We only have them in xbm format. Regards, PeterM From crossfire-request Fri Feb 25 05:19:33 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 25 Feb 1994 05:19:19 +0100 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA09213; Fri, 25 Feb 1994 15:18:50 +1100 Date: Fri, 25 Feb 1994 15:18:50 +1100 From: "Rupert G. Goldie" Message-Id: <199402250418.AA09213@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no, beilby@latcs1.lat.oz.au Subject: Re: Crossfire maps. Status: RO > Hi all, > I've just compiled crossfire.90.1, and that seems to have worked, but I > have been unable to run it because of the following run-time error: > > Fatal: Failed repeatedly to load maps > > I've unable to find out if the problem is the path to the maps dir (it > appears to be ok in the crosssite.def file), or the fact that due to the > size of the maps (20MB!!!) when uncompressed I've had to compress them all. > > Any hints on what I might be doing wrong will be much appreciated. Also > the name/path of the first map xfire reads would be a help. Is the map directory readable ? What did you use to compress the maps. If you used gzip and didn't define the COMPRESS variable in the Imakefile/config.h there is a bug which makes crossfire look for foo.Z.gz instead of foo.gz (I've sent the fix to Mark) village/village is the default start map (The chico maps start in city/city) Try using trace to see what files crossfire is opening. Hope this helps Rupert From crossfire-request Fri Feb 25 05:06:04 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 25 Feb 1994 05:06:02 +0100 Received: from localhost (peterm@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id UAA25118; Thu, 24 Feb 1994 20:05:37 -0800 Date: Thu, 24 Feb 1994 20:05:37 -0800 From: Peter Mardahl Message-Id: <199402250405.UAA25118@soda.berkeley.edu> To: beilby@latcs1.lat.oz.au, crossfire@ifi.uio.no Subject: Re: Crossfire maps. Status: RO Fatal: Failed repeatedly to load maps The problem is in the archetypes, of all obscure places. What you need to do is edit the archetypes file, find the archetype 'map' (there should be only one) you can search for Object map I think, or just "map", and change the 'slaying xxxxxxx' line just afterward to be 'slaying ' All new players will appear in that map. PeterM From crossfire-request Fri Feb 25 04:50:21 1994 Return-Path: Received: from latcs1.lat.oz.au by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 25 Feb 1994 04:50:17 +0100 From: beilby@latcs1.lat.oz.au Received: from ipc6.lat.OZ.AU by latcs1.lat.oz.au (5.67b/1.34) id AA04830; Fri, 25 Feb 1994 14:48:07 +1100 Message-Id: <199402250348.AA16690@ipc6.lat.oz.au> Subject: Crossfire maps. To: crossfire@ifi.uio.no Date: Fri, 25 Feb 1994 14:48:11 +1100 (EST) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 885 Status: RO Hi all, I've just compiled crossfire.90.1, and that seems to have worked, but I have been unable to run it because of the following run-time error: Fatal: Failed repeatedly to load maps I've unable to find out if the problem is the path to the maps dir (it appears to be ok in the crosssite.def file), or the fact that due to the size of the maps (20MB!!!) when uncompressed I've had to compress them all. Any hints on what I might be doing wrong will be much appreciated. Also the name/path of the first map xfire reads would be a help. / / / / __ And how can this be? )--/+-+-+-+--- ' \ - Because HE IS THE KWISATZ HADERACH!!! (8| Scorpius>\___/ // )--\+-+-+-+--- \\ // \ \ \ \ Dougal Beilby (beilby@latcs1.lat.oz.au) \X/ A4000/030 From crossfire-request Fri Feb 25 03:26:25 1994 Return-Path: Received: from kinglear.cs.Colorado.EDU by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 25 Feb 1994 03:26:23 +0100 Received: from localhost (localhost [127.0.0.1]) by kinglear.cs.Colorado.EDU (8.6.4/8.6.4) with SMTP id TAA19698; Thu, 24 Feb 1994 19:24:27 -0700 Message-Id: <199402250224.TAA19698@kinglear.cs.Colorado.EDU> X-Authentication-Warning: kinglear.cs.Colorado.EDU: Host localhost didn't use HELO protocol To: anthony.baxter@aaii.oz.au cc: crossfire@ifi.uio.no Subject: Re: client/server once again In-reply-to: Your message of "Thu, 24 Feb 1994 16:26:55 +1100." <9402240526.AA18371@alamein> Date: Thu, 24 Feb 1994 19:24:26 -0700 From: Drew Eckhardt Status: RO -------- "Rupert G. Goldie" wrote: > I suspect there are plenty of optimisations we can make to Crossfire > to speed it up. At some stage someone has to sit down with a profiler > (anyone have Quantify ?) and see where the slow bits are. Been there, done that, allthough I used gprof. This is a totally wild guess, but maybe in X11? :-) Nope. When I attempted to run crossfire on my 386-33 Linux box, it was unplayable, not because of time spent in the X server, but because of time spent doing floating point arithmatic since all of the timing variables were floats. Converting the floats to fixed point arithmatic speeded things up by an order of magnitude, but unfortunately I introduced a bug someplace (core dump) and lost the changes in a disk crash before I got a chance to make them stable. I use a 486-66 now, and it's fast enough without any changes. From crossfire-request Sat Feb 26 20:49:38 1994 Return-Path: Received: from surt.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id ; Sat, 26 Feb 1994 20:49:38 +0100 From: Kjetil Torgrim Homme Received: from localhost by surt.ifi.uio.no ; Sat, 26 Feb 1994 20:49:39 +0100 Date: Sat, 26 Feb 1994 20:49:39 +0100 Message-Id: <19940226194939.328.surt.ifi.uio.no@ifi.uio.no> To: elsbernd@dfki.uni-kl.de CC: master@rahul.net, crossfire@ifi.uio.no In-reply-to: Klaus Elsbernd's message of Sat, 26 Feb 1994 10:17:59 +0100 <9402260918.aa22197@serv-301.dfki.uni-kl.de> Subject: Re: Arch not found... Status: RO Klaus Elbernd: > Perhaps you might consider making a realclean or distclean target. That would still not solve the problem, because the archetypes and crossfire.cfb etc. *are* a part of the distribution. One way of solving this though, is to put a lib/Imakefile with a new distclean rule into the arch.tar.gz package. The Imakefiles should generally not be modified by the user, so this may not be so bad, it's mainly a problem to write the rules in the "make package" :-) A realclean can delete anything, but they tend to be unpopular because people tend to think that they have everything necessary to rebuild. E.g. - do you have perl? Do you have netpbm? Scott Iverson: > I don't see the problem if you remove those files from the source's > lib dir and not the crossfire binary's lib dir. Here the two lib dirs are the same, with the help of a symbolic link. Keeping to copies would be a large waste of disc space for developers. Kjetil T. From crossfire-request Sat Feb 26 17:36:39 1994 Return-Path: Received: from cc.lut.fi by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 26 Feb 1994 17:36:38 +0100 Received: from localhost (haatanen@localhost) by cc.lut.fi (8.6.5/8.6.5/1.12.kim) id SAA14145; Sat, 26 Feb 1994 18:36:37 +0200 (for crossfire@ifi.uio.no) From: Tero Haatanen Message-Id: <199402261636.SAA14145@cc.lut.fi> Subject: Re: maps and creativity To: crossfire@ifi.uio.no Date: Sat, 26 Feb 1994 18:36:36 +0200 (EET) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2641 Status: RO From: Peter Mardahl > What I'm basically saying is that I'd really hate it if every server > had the exact same set of maps! Me too, if I just could find servers to play :(. But I also hate if all best maps are just in the servers running somewhere US. :) > I think it'd be ideal if everyone had their own high-level maps, > and took a little time to integrate other maps into a larger picture. Of course, but you clearly speak those who admins public servers. But (most?) play local server and they haven't time, skill, etc. create their own maps. And only thing what players directly see is the maps, so they deside how good crossfire is based on maps, and that is very important that standard map set is good. Client/server makes things little better but it doesn't remove the problem. > I propose this: a central location to get smaller maps of various levels > for plugging into your own customized server-world, and archive these > by level of difficulty. Good idea. Note that every map author has his/her rights to decide, if (s)he makes them available all or only some server. And still standard distribution should have large enough to get feel large world. This of course doesn't mean that every map should go in the standard distribution. [directory heirarchy and an example abstract deleted] In archive it probably is the best that there is only one tar packet and abstract file per area/building/quest. And index file contains one line description all areas in archive. quick example: demons.tar.Z The demonlord challange (5 maps) 10+ level In tar file has all maps needed and those maps should use the relative path names so it can be put anywhere in maps directory. All exits leaving/coming to area should documented in abstract. Also abstract can mention in which version of crossfire they work and if non standard archetypes/code is needed. Although I wish that all code/archetypes which are generally useful go directly standard distribution. Also it's best to check that every map has message which tells map name and author at least. > This idea is only half-baked, so I'd welcome comments. Anyone willing > to maintain a map archive? I'd do it, except I prefer to code. This is > a perfect project for a non-coder. Probably to start someone should > just collect and write (where necessary) abstracts. I think everyone who wants include his/her maps to archive, has best write his own description files and offer the maps in archive. Nothing prevent standard distribution maps being available in map archieve in area basis if authors wish that. -Tero From crossfire-request Sat Feb 26 11:53:08 1994 Return-Path: Received: from alaska.et.byu.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 26 Feb 1994 11:53:06 +0100 Received: by alaska.et.byu.edu; Sat, 26 Feb 1994 03:52:59 -0700 Date: Sat, 26 Feb 1994 03:52:59 -0700 From: iversons@alaska.et.byu.edu (Scott Iverson) Message-Id: <199402261052.DAA03473@alaska.et.byu.edu> To: crossfire@ifi.uio.no Reply-to: iversons@byu.edu Status: RO > Scott Iverson writes: > >I want to suggest that make clean will remove: > >.collect-stamp, archetypes, bmaps, bmaps.paths, crossfire.bdf, > >crossfire.cfb, crossfire.pcf, and crossfire.pix. > > > Mark Wedel writes: > > I dislike the idea of clean removing all those lib files. I really do not > >want to make the arch directory a required part of the distribution - it > >should only be needed by those adding new archetypes or doing more > >esoteric functions (like making the spoiler file. Which, btw, I will > >pre-make one before I tar up each version.) > > Perhaps you might consider making a realclean or distclean target. > MfG > Klaus > I don't see the problem if you remove those files from the source's lib dir and not the crossfire binary's lib dir. I hope you see what I mean. Now that I have compiled the program, why would I want a copy in /usr/local/src/crossfire-0.90.1/lib when I have a copy that is beeing used in /usr/local/games/lib/crossfire? I think that if you have a destination lib dir, then having clean remove the files that 'make all' in the source lib dir is a good idea. ---Scott From crossfire-request Sat Feb 26 10:51:28 1994 Return-Path: Received: from alaska.et.byu.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 26 Feb 1994 10:51:27 +0100 Received: by alaska.et.byu.edu; Sat, 26 Feb 1994 02:51:21 -0700 Date: Sat, 26 Feb 1994 02:51:21 -0700 From: iversons@alaska.et.byu.edu (Scott Iverson) Message-Id: <199402260951.CAA03372@alaska.et.byu.edu> To: crossfire@ifi.uio.no Subject: Map Spelling errors Reply-to: iversons@byu.edu Status: RO In the 'Old shop' the help sign has spelling errors: ... To find the prise[price] of ... In the 'old house' the help sign has spelling errors: Mous[Mouse] bites, and the[they] have a rather frequent sex life ... In the Gatehouse the help says: ... To get back to the town, stand on the door an[and] press the kay[key] named 'A'. I am only posting this in case someone feels these kinds of notices are helpfull. ---Scott PS. This does mean that I got 90.1 to compile. From crossfire-request Sat Feb 26 11:43:11 1994 Return-Path: Received: from liero.cc.lut.fi by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 26 Feb 1994 11:43:10 +0100 Received: from localhost (hevi@localhost) by liero.cc.lut.fi (8.6.5/8.6.5/1.12.kim) id MAA22131; Sat, 26 Feb 1994 12:43:09 +0200 Date: Sat, 26 Feb 1994 12:43:09 +0300 (EETDST) From: Petri Heinil{ Subject: Re: Compiling To: crossfire@ifi.uio.no In-Reply-To: <199402260131.SAA22800@alaska.et.byu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 25 Feb 1994, Scott Iverson wrote: > When I compile I get this error: > cc -o crossfire apply.o attack.o daemon.o encounter.o hiscore.o > init.o input.o login.o main.o monster.o move.o obwin.o pets.o > player.o shop.o socket.o sounds.o spells.o swamp.o swap.o > time.o xio.o -O -Aa -D_HPUX_SOURCE +O3 +OS -L/usr/lib/X11R5 > -L/usr/local/X11R5/lib -L../common -lcross -lX11 -L/usr/local/lib/ > -lXpm -L/usr/local/X11R5 The order of libraries declared is wrong; the Xpm depends from X11, so the X11 have to come after Xpm. The order should be: -lcross -lXpm -lX11 . I think the order of -L -flags is not important, but this might be also compiler depend issue. > /bin/ld: Unsatisfied symbols: > XCreateImage (code) > XGrabServer (code) > XPutImage (code) > XCreatePixmap (code) > XQueryColors (code) > XUngrabServer (code) > XParseColor (code) Yes these are really functions used Xpm. > I Found that libcross.a calls these fucntions. What library needs to > be included? I am compiling on hp-ux(9000). The including should be OK. The compiler murmurs if it can't find the -l -library. ///////////////////////// Petri Heinila ///////////////////////// email: Petri.Heinila@lut.fi www: Homepage mail: Ainonkatu 2A 53100 Lappeenranta Finland, Europe tel: 3624 (in. LUT) From crossfire-request Sat Feb 26 11:34:59 1994 Return-Path: Received: from liero.cc.lut.fi by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 26 Feb 1994 11:34:59 +0100 Received: from localhost (hevi@localhost) by liero.cc.lut.fi (8.6.5/8.6.5/1.12.kim) id MAA22099; Sat, 26 Feb 1994 12:34:57 +0200 Date: Sat, 26 Feb 1994 12:34:57 +0300 (EETDST) From: Petri Heinil{ Subject: Re: Arch not found... To: crossfire@ifi.uio.no In-Reply-To: <9402260918.aa22197@serv-301.dfki.uni-kl.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Sat, 26 Feb 1994, Klaus Elsbernd wrote: > > Scott Iverson writes: > >I want to suggest that make clean will remove: > >.collect-stamp, archetypes, bmaps, bmaps.paths, crossfire.bdf, > >crossfire.cfb, crossfire.pcf, and crossfire.pix. > > > Mark Wedel writes: > > I dislike the idea of clean removing all those lib files. I really do not > >want to make the arch directory a required part of the distribution - it > >should only be needed by those adding new archetypes or doing more > >esoteric functions (like making the spoiler file. Which, btw, I will > >pre-make one before I tar up each version.) > > Perhaps you might consider making a realclean or distclean target. In lib Imakefile exists: real-clean:: $(RM) $(FONTNAME).bdf $(FONTNAME).cfb crossfire.pix $(RM) archetypes bmaps .collect-stamp ///////////////////////// Petri Heinila ///////////////////////// email: Petri.Heinila@lut.fi www: Homepage mail: Ainonkatu 2A 53100 Lappeenranta Finland, Europe tel: 3624 (in. LUT) From crossfire-request Sat Feb 26 10:18:10 1994 Return-Path: <<@serv-200.dfki.uni-kl.de:elsbernd@dfki.uni-kl.de>> Received: from uni-kl.de by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sat, 26 Feb 1994 10:18:09 +0100 Received: from serv-200.dfki.uni-kl.de by stepsun.uni-kl.de id aa25694; 26 Feb 94 10:18 MET Received: from serv-301.dfki.uni-kl.de by serv-200.dfki.uni-kl.de id aa04359; 26 Feb 94 9:18 GMT Received: from serv-301.dfki.uni-kl.de by serv-301.dfki.uni-kl.de id aa22197; 26 Feb 94 9:18 GMT To: Mark Wedel cc: crossfire@ifi.uio.no Subject: Re: Arch not found... In-reply-to: Your message of "Sat, 26 Feb 1994 01:08:26 PST." <199402260908.AA15953@bolero.rahul.net> Date: Sat, 26 Feb 1994 10:17:59 +0100 From: Klaus Elsbernd Message-ID: <9402260918.aa22197@serv-301.dfki.uni-kl.de> Status: RO Scott Iverson writes: >I want to suggest that make clean will remove: >.collect-stamp, archetypes, bmaps, bmaps.paths, crossfire.bdf, >crossfire.cfb, crossfire.pcf, and crossfire.pix. Mark Wedel writes: > I dislike the idea of clean removing all those lib files. I really do not >want to make the arch directory a required part of the distribution - it >should only be needed by those adding new archetypes or doing more >esoteric functions (like making the spoiler file. Which, btw, I will >pre-make one before I tar up each version.) Perhaps you might consider making a realclean or distclean target. MfG Klaus From crossfire-request Sat Feb 26 10:08:38 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sat, 26 Feb 1994 10:08:32 +0100 Received: by bolero.rahul.net id AA15953 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Sat, 26 Feb 1994 01:08:26 -0800 Date: Sat, 26 Feb 1994 01:08:26 -0800 From: Mark Wedel Message-Id: <199402260908.AA15953@bolero.rahul.net> To: iversons@alaska.et.byu.edu, master@rahul.net Subject: Re: Arch not found... Cc: crossfire@ifi.uio.no Status: RO I dislike the idea of clean removing all those lib files. I really do not want to make the arch directory a required part of the distribution - it should only be needed by those adding new archetypes or doing more esoteric functions (like making the spoiler file. Which, btw, I will pre-make one before I tar up each version.) As such, make clean should not remove files that are not re-creatable from the standard distribution. In fact, for a great many people, the archetypes bmaps, and crossfire.* files will never need to be altered. To force a rebuild of those, I jsut remove the archetypes file. Many users might do 'make clean' to clear out all the binaries and other files not necessary to running the game. IF it cleared out the lib directory, this might create major headaches for those who are just interested in playing, and not hacking. --Mark From crossfire-request Sat Feb 26 09:39:43 1994 Return-Path: Received: from alaska.et.byu.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 26 Feb 1994 09:39:42 +0100 Received: by alaska.et.byu.edu; Sat, 26 Feb 1994 01:39:33 -0700 From: iversons@alaska.et.byu.edu (Scott Iverson) Message-Id: <199402260839.BAA03318@alaska.et.byu.edu> Subject: Re: Arch not found... To: master@rahul.net (Mark Wedel) Date: Sat, 26 Feb 94 1:39:32 MST Cc: crossfire@ifi.uio.no In-Reply-To: from "Mark Wedel" at Feb 25, 94 11:56 pm Mailer: Elm [revision: 72.14] Status: RO > > Make sure the archetypes file is located in the correct place, and that > it is not an empty file. The archetypes file should be about 200 K. > > --Mark > That was the problem. When I was trying to recover from another bug, I had made partial files for most of the files in the lib dir. I did make clean, however it didn't remove the right files. I want to suggest that make clean will remove: .collect-stamp, archetypes, bmaps, bmaps.paths, crossfire.bdf, crossfire.cfb, crossfire.pcf, and crossfire.pix. ---Scott From crossfire-request Sat Feb 26 08:56:20 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sat, 26 Feb 1994 08:56:15 +0100 Received: by bolero.rahul.net id AA12996 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Fri, 25 Feb 1994 23:56:08 -0800 Date: Fri, 25 Feb 1994 23:56:08 -0800 From: Mark Wedel Message-Id: <199402260756.AA12996@bolero.rahul.net> To: crossfire@ifi.uio.no, iversons@byu.edu Subject: Re: Arch not found... Status: RO Make sure the archetypes file is located in the correct place, and that it is not an empty file. The archetypes file should be about 200 K. --Mark From crossfire-request Sat Feb 26 08:39:51 1994 Return-Path: Received: from alaska.et.byu.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 26 Feb 1994 08:39:50 +0100 Received: by alaska.et.byu.edu; Sat, 26 Feb 1994 00:39:44 -0700 Date: Sat, 26 Feb 1994 00:39:44 -0700 From: iversons@alaska.et.byu.edu (Scott Iverson) Message-Id: <199402260739.AAA26858@alaska.et.byu.edu> To: crossfire@ifi.uio.no Subject: Arch not found... Reply-to: iversons@byu.edu Status: RO Ok. I got crossfire 90.1 installed, I installed the maps and the archtypes in the lib dir. However, Crossfire and Crossedit both choke trying to startup because they can't find some archetypes. Was I supposed to create a listing or something? Couldn't find archetype bow Treasure lacks archetype: bow Couldn't find archetype arrow Treasure lacks archetype: arrow Couldn't find archetype sword_3 Treasure lacks archetype: sword_3 Couldn't find archetype shortsword Treasure lacks archetype: shortsword Couldn't find archetype dagger Treasure lacks archetype: dagger Couldn't find archetype stoneaxe Treasure lacks archetype: stoneaxe Couldn't find archetype club Treasure lacks archetype: club Couldn't find archetype small_shield Treasure lacks archetype: small_shield Couldn't find archetype silvercoin Treasure lacks archetype: silvercoin Couldn't find archetype bow Treasure lacks archetype: bow Couldn't find archetype arrow Treasure lacks archetype: arrow Couldn't find archetype crossbow Treasure lacks archetype: crossbow Couldn't find archetype bolt Treasure lacks archetype: bolt Fatal: Too many errors Exiting... ---Scott From crossfire-request Sat Feb 26 08:39:49 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id ; Sat, 26 Feb 1994 08:39:46 +0100 Received: by bolero.rahul.net id AA12378 (5.67a8/IDA-1.5); Fri, 25 Feb 1994 23:39:41 -0800 Date: Fri, 25 Feb 1994 23:39:41 -0800 From: Mark Wedel Message-Id: <199402260739.AA12378@bolero.rahul.net> To: crossfire@ifi.uio.no, kjetilho@ifi.uio.no, peterm@soda.berkeley.edu Subject: Re: TODO list Status: RO However, detect magic will discover magical items not on the character. So a mode to only pick up magical items. Because, right now, I believe identify spell will identify all unidentified items. You might very wall (well) only want to identify magical items. In terms of saving scrolls or spellpoints.. The problem with fixing identify to do this, is there is really know way to know if a non magical item has had detect magic cast on it. --Mark From crossfire-request Sat Feb 26 08:06:02 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id ; Sat, 26 Feb 1994 08:05:59 +0100 Received: from localhost (peterm@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id XAA13266; Fri, 25 Feb 1994 23:05:55 -0800 Date: Fri, 25 Feb 1994 23:05:55 -0800 From: Peter Mardahl Message-Id: <199402260705.XAA13266@soda.berkeley.edu> To: crossfire@ifi.uio.no, kjetilho@ifi.uio.no Subject: Re: TODO list Status: RO Just make sure that the pickup-mode doesn't know more than the player - ie. check if the objects are identified first :-) That's exactly why I proposed allowing identify to identify stuff below the character if his inventory is known. :-> I intend to make that happen soon. (Though probably not for the next release.) My idea is to automatically pick up items that are 'worth' carrying around, things that are both light and valuable, and the measure is value/weight. I will make it so that all things below the player of a certain value/weight or greater (determined by the player's preference) are picked up without the player having to mess with it. Unidentified things are generally pretty worthless, so I won't have to do much thinking. I will, however, be careful. I most likely won't do these by this weekend, so if anyone wants to take these up and do them by Sunday, then feel free! That's when master@rahul.net said he wanted patches by.... Regards, PeterM From crossfire-request Sat Feb 26 06:00:37 1994 Return-Path: Received: from sognsvann.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 26 Feb 1994 06:00:37 +0100 From: Kjetil Torgrim Homme Received: from localhost by sognsvann.ifi.uio.no ; Sat, 26 Feb 1994 06:00:36 +0100 Date: Sat, 26 Feb 1994 06:00:36 +0100 Message-Id: <19940226050036.29672.sognsvann.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: Mark Wedel's message of Fri, 25 Feb 1994 20:53:28 -0800 <199402260453.AA06585@bolero.rahul.net> Subject: Re: TODO list Status: RO +--- Mark Wedel: | I've gotten a request from a friend to allow pickup mode for only | magical objects. However, if it is very much smarter, then what you | have should allow what he needs. +--- Just make sure that the pickup-mode doesn't know more than the player - ie. check if the objects are identified first :-) Stating the obvious, I know. I've often wanted a smart pickup-mode myself. Actually, fixing the bug so that "search +" works would be a start... Kjetil T. From crossfire-request Sat Feb 26 05:53:36 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sat, 26 Feb 1994 05:53:31 +0100 Received: by bolero.rahul.net id AA06585 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Fri, 25 Feb 1994 20:53:28 -0800 Date: Fri, 25 Feb 1994 20:53:28 -0800 From: Mark Wedel Message-Id: <199402260453.AA06585@bolero.rahul.net> To: crossfire@ifi.uio.no, peterm@soda.berkeley.edu Subject: Re: TODO list Status: RO That lists looks great to me. I've gotten a request from a friend to allow pickup mode for only magical objects. However, if it is very much smarter, then what you have should allow what he needs. --Mark From crossfire-request Sat Feb 26 04:52:56 1994 Return-Path: Received: from sognsvann.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id ; Sat, 26 Feb 1994 04:52:55 +0100 From: Kjetil Torgrim Homme Received: from localhost by sognsvann.ifi.uio.no ; Sat, 26 Feb 1994 04:52:55 +0100 Date: Sat, 26 Feb 1994 04:52:55 +0100 Message-Id: <19940226035255.29633.sognsvann.ifi.uio.no@ifi.uio.no> To: iversons@alaska.et.byu.edu CC: crossfire@ifi.uio.no In-reply-to: Scott Iverson's message of Fri, 25 Feb 94 18:57:08 MST <199402260157.SAA23062@alaska.et.byu.edu> Subject: Re: Compiling Status: RO > True these routines are called from within the Xpm library. The > Xpm library is in my path. It is in /usr/local/lib. The ordering is important. Put -lXpm before -lX11, and it should work. Kjetil T. From crossfire-request Sat Feb 26 02:57:21 1994 Return-Path: Received: from alaska.et.byu.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 26 Feb 1994 02:57:20 +0100 Received: by alaska.et.byu.edu; Fri, 25 Feb 1994 18:57:08 -0700 From: iversons@alaska.et.byu.edu (Scott Iverson) Message-Id: <199402260157.SAA23062@alaska.et.byu.edu> Subject: Re: Compiling To: crossfire@ifi.uio.no Date: Fri, 25 Feb 94 18:57:08 MST Mailer: Elm [revision: 72.14] Status: RO > All those routies are from the Xpm library, which is either > not in your library path, or not on your system at all. > I fixed this by going to crosssite.def in config dir and > undefining XPM. > Recompile your server without the XPM stuff, or find xpm, > install the libraries, and THEN compile crossfire again. > PeterM True these routines are called from within the Xpm library. The Xpm library is in my path. It is in /usr/local/lib. If it wasn't in the path I would have gotten: /bin/ld: Can't find library for -lXpm So, I am including -lX11 and even -lXt. Apparently they don't contain the functions that I am missing. Anyone know what library has these functions in them? XCreateImage (code) XGrabServer (code) XPutImage (code) XCreatePixmap (code) XQueryColors (code) XUngrabServer (code) XParseColor (code) ---Scott From crossfire-request Sat Feb 26 02:46:57 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 26 Feb 1994 02:46:55 +0100 Received: from localhost (peterm@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id RAA21347; Fri, 25 Feb 1994 17:46:44 -0800 Date: Fri, 25 Feb 1994 17:46:44 -0800 From: Peter Mardahl Message-Id: <199402260146.RAA21347@soda.berkeley.edu> To: iversons@alaska.et.byu.edu Subject: Re: Compiling Cc: c@soda.berkeley.edu, crossfire@ifi.uio.no Status: RO All those routies are from the Xpm library, which is either not in your library path, or not on your system at all. I fixed this by going to crosssite.def in config dir and undefining XPM. Recompile your server without the XPM stuff, or find xpm, install the libraries, and THEN compile crossfire again. PeterM From crossfire-request Sat Feb 26 02:31:30 1994 Return-Path: Received: from alaska.et.byu.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 26 Feb 1994 02:31:28 +0100 Received: by alaska.et.byu.edu; Fri, 25 Feb 1994 18:31:21 -0700 Date: Fri, 25 Feb 1994 18:31:21 -0700 From: iversons@alaska.et.byu.edu (Scott Iverson) Message-Id: <199402260131.SAA22800@alaska.et.byu.edu> To: crossfire@ifi.uio.no Subject: Compiling Reply-to: iversons@byu.edu Status: RO When I compile I get this error: cc -o crossfire apply.o attack.o daemon.o encounter.o hiscore.o init.o input.o login.o main.o monster.o move.o obwin.o pets.o player.o shop.o socket.o sounds.o spells.o swamp.o swap.o time.o xio.o -O -Aa -D_HPUX_SOURCE +O3 +OS -L/usr/lib/X11R5 -L/usr/local/X11R5/lib -L../common -lcross -lX11 -L/usr/local/lib/ -lXpm -L/usr/local/X11R5 /bin/ld: Unsatisfied symbols: XCreateImage (code) XGrabServer (code) XPutImage (code) XCreatePixmap (code) XQueryColors (code) XUngrabServer (code) XParseColor (code) I Found that libcross.a calls these fucntions. What library needs to be included? I am compiling on hp-ux(9000). ---Scott From crossfire-request Sat Feb 26 01:32:27 1994 Return-Path: Received: from alaska.et.byu.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 26 Feb 1994 01:32:26 +0100 Received: by alaska.et.byu.edu; Fri, 25 Feb 1994 17:32:09 -0700 Date: Fri, 25 Feb 1994 17:32:09 -0700 From: iversons@alaska.et.byu.edu (Scott Iverson) Message-Id: <199402260032.RAA21871@alaska.et.byu.edu> Apparently-To: crossfire@ifi.uio.no Status: RO While compiling on a hp-ux (9000), I get the error: Make: Must be a separator on rules line XXX. Stop. It appears that make doesnot understand '+=' so would it be possible for future versions to not produce code with '+=' ? Here is the line causing the trouble: DEFINES += -DXpm_Pix ---Scott From crossfire-request Sat Feb 26 00:40:41 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 26 Feb 1994 00:40:39 +0100 Received: from localhost (peterm@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id PAA07982 for crossfire@ifi.uio.no; Fri, 25 Feb 1994 15:40:33 -0800 Date: Fri, 25 Feb 1994 15:40:33 -0800 From: Peter Mardahl Message-Id: <199402252340.PAA07982@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: TODO list Status: RO Here is my todo list of projects I'd like to undertake: (meaning I'm going to do these myself unless someone tells me they're doing it, will do it, or have done it) Identify spell: It should identify things on the ground beneath the player if he has nothing unidentified--probably an easy hack. Attacktypes: Two new ones: a random attacktype which changes every turn, fire->cold->whatever, that also forces a change in the face and color of the attacking object. (Have you seen color spray? It's a neat effect.) Also, an attacktype which only effects magic spells. If it sees an object associated with a magic spell, such as a firebreath or bullet, it destroyes it, if it's level is higher than the level of its victim. Pickup: I want to make pickup very much smarter. I want to be able to tell the server "I automatically want to pick up everything which has a value greater than X gold/weight." And have it automatically pick up stuff like gold, gems, +2, +3 stuff, artifacts spellbooks, and ignore +0, +1 stuff, and other things which have such a low value-density that they're not worth carrying. Alchemy helps, but it nukes items. Regards, PeterM peterm@soda.berkeley.edu From crossfire-request Sat Feb 26 00:13:57 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 26 Feb 1994 00:13:56 +0100 Received: from localhost (peterm@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id PAA05432 for crossfire@ifi.uio.no; Fri, 25 Feb 1994 15:13:51 -0800 Date: Fri, 25 Feb 1994 15:13:51 -0800 From: Peter Mardahl Message-Id: <199402252313.PAA05432@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: maps and creativity Status: RO I'm wondering if it is a good idea to have a 'standard' distribution of maps. tvangod's world is really cool, and it gives his server a unique flavor--he and his crew have done an extremely good job with their maps, they're mostly balanced and well-integrated. What I'm basically saying is that I'd really hate it if every server had the exact same set of maps! I think it'd be ideal if everyone had their own high-level maps, and took a little time to integrate other maps into a larger picture. I propose this: a central location to get smaller maps of various levels for plugging into your own customized server-world, and archive these by level of difficulty. Here's a directory heirarchy I might envision: level1-3maps/ level4-6maps/ level7-9maps/ level10-12maps/ ..... towns/ worlds/ where if you cd level7-9maps/ you'd see: something like: CTower/ firequest/ runedeath/ CTower.abstract firequest.abstract runedath.abstract CTower/ contains the .tgz maps, and CTower.abstract is something by the author describing the map. Here's an example abstract: -------------------- top level map: CTower/CTower rating: 7-9 CTower -- the Tower of the Stars by Peter Mardahl (peterm@soda.berkeley.edu) A quest for the comet spell. Players must question monsters to obtain passwords to the higher levels of the Tower, and destroy progressively more difficult monsters. At the top of the tower is a weak lich, a spellbook of comet, the Luggage, and miscellanous stuff. I rate the quest at level 7-9, though single players might have problems with that lich. ------------------------- Dividing up the maps into levels like that might not be practical, but every map should have an abstract. Right now the maps are chaos, and someone would have to examine a map to know if was what he wanted or not. This idea is only half-baked, so I'd welcome comments. Anyone willing to maintain a map archive? I'd do it, except I prefer to code. This is a perfect project for a non-coder. Probably to start someone should just collect and write (where necessary) abstracts. Regards, PeterM From crossfire-request Fri Feb 25 15:45:03 1994 Return-Path: Received: from cc.lut.fi by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 25 Feb 1994 15:44:59 +0100 Received: from localhost (haatanen@localhost) by cc.lut.fi (8.6.5/8.6.5/1.12.kim) id QAA15464; Fri, 25 Feb 1994 16:44:54 +0200 (for crossfire@ifi.uio.no) From: Tero Haatanen Message-Id: <199402251444.QAA15464@cc.lut.fi> Subject: Map tester To: crossfire@ifi.uio.no Date: Fri, 25 Feb 1994 16:44:53 +0200 (EET) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 7559 Status: RO This is a small perl-script which I made checking my maps after they were converted from one format to another :). I find it so useful, so I post it to this mailing-list. It wanderers through maps in given directories (in maps dir only), so dot (.) means all maps in maps dir. It print general mapinfo and problems what it founds. Some checks doesn't seem to be problems any more (like player archetypes in maps). It's not very 'polished', so feel free edit your needs. BTW: It also generates list used objects, and according that floors are most common objects, so not trying animate them should certainly speed up the server. Following could be added to mapguide (any opinions, Mark?). Give all maps some meaningful name instead of default (map), so that name can be used in every place where mapname is needed (highscore, etc). Players don't need to see those paths, since they are just implementetion details :). And note mapinfo command in game, which gives additional info about map. -Tero PS. In first look (just installed) those 'chico' maps seems to be very good. Congratulations all authors! ---8<------8<------8<------8<------8<------8<------8<------8<------8<--- #!/usr/local/bin/perl # # This program is meant to use check crossfire (version 0.90.?) maps. # Program wanderers through mapfiles and reports all objects that # can't be found in the archetypes, all exit that doesn't lead to # anywhere and all corrupted mapfiles. # # Usage: wanderer.pl directory $LIB = "/net/contrib/crossfire/lib"; $ARCH = "$LIB/archetypes"; $MAPS = "$LIB/maps"; if (! $ARGV[0]) { print "Usage: wanderer.pl map-directory ... > output.log\n"; exit; } # read filenames to @maps chdir ($MAPS); while ($area = shift) { &maplist ($area); } $* = 1; # use multiline matches # read archetypes &archetypes; %ex = &collect ("^type 66$"); # type 66 == exit %tele = &collect ("^type 41$"); # type 41 == teleport %conn = &collect ("^type (17|18|26|27|29|30|31|32|91|92|93|94)$"); delete $conn{"spikes_moving"}; %players = &collect ("^type 1$"); # type 1 == player # check exits from archetypes foreach $a (keys (%ex), keys (%tele)) { if ($arches {$a} =~ /^food -?\d+$/) { print "Warning: Archetype $a has food field.\n"; } } # some general info print "=" x 70, "\n"; print "Number of mapfiles = " , @maps + 0, "\n"; print "Number of archetypes = " , values(%arches)+0, ":\n"; print " - Exits (" , values(%ex)+0, ")\n"; print " - Teleports (" , values(%tele)+0, ")\n"; print " - Connected objects (", values(%conn)+0, ")\n"; print " - Players (" , values(%players)+0, ")\n"; print "=" x 70, "\n"; # check maps while ($file = shift (@maps)) { &readmap; } # summary of missing archetypes if (%missing) { print "=" x 70, "\n"; print "Missing archetypes: ", join (", ", sort keys (%missing)), "\n"; } # if you don't want list of used objects, uncomment next line # and you can comment also last line check_obj # (This isn't very useful, but maybe tells something) # exit; print "=" x 70, "\nArchetype count\n"; $total = 0; foreach $a (sort by (keys (%objects))) { printf ("%-24s%d\n", $a, $objects{$a}); $total += $objects{$a}; } print '-' x 30, "\nTotal objects $total\n"; exit; # return table containing all objects in the map sub readmap { local ($m); $last = ""; $/ = "\nend\n"; if (! open (IN, $file)) { print "Can't open map file $file\n"; return; } $_ = ; if (! /^arch map$/) { print "Error: file $file isn't mapfile.\n"; return; } print "Testing $file, "; print /^name (.+)$/ ? $1 : "No mapname"; print ", size [", /^x (\d+)$/ ? $1 : 16; print ",", /^y (\d+)/ ? $1 : 16, "]"; if (! /^msg$/) { print ", No message\n"; } elsif (/(\w+@\S+)/) { print ", $1\n"; } else { print ", Unknown\n"; } while () { if (($m = (@_ = /^arch \S+$/g)) > 1) { # object has inventory local ($inv) = $_; while () { if (/((.|\n)*end\n)(arch (.|\n)*\nend\n)/) { &check_obj ("$inv$1"); &check_obj ($3); last; } elsif (/^arch (.|\n)*\nend$/) { &check_obj ($_); } elsif (/^end$/) { &check_obj ("$inv$_"); } else { print " Error: Corrupted map file $file.\nSegment:\n$_"; } } } elsif (/^More$/ || $m == 1) { &check_obj ($_); } else { print " Error: Corrupted map file $file.\nSegment:\n$_"; } } close (IN); } sub check_obj { $_ = shift @_; /^arch (\S+)$/; if (! $arches{$1} && $last ne $1) { $last = $1; print " Error: Object $last is not defined in archetypes file.\n"; $missing{$last}++; } elsif ($ex{$1}) { &examine_exit ($_); } elsif ($tele{$1} && /^food -?\d+$/) { print " Error: Teleport $1 has food field.\n"; } elsif ($conn{$1} && ! /^connected -?\d+$/ && $last ne $1) { $last = $1; print " Warning: Object $last has not been connected.\n"; } elsif ($players{$1} && $last ne $1) { $last = $1; print " Error: Player $last found in the map.\n"; } elsif ($1 eq "scroll" && ! /^msg$/ && $last ne $1) { $last = $1; print " Warning: scroll without message, should be random_scroll?\n"; } elsif ($1 eq "potion" && $last ne $1) { $last = $1; print " Warning: potion found, should be random_potion or random_food?\n"; } # $objects{$1}++; } sub by { $_ = $objects{$b} <=> $objects{$a}; $_ ? $_ : $a cmp $b; } sub obj_name { $_ = shift(@_); local ($name) = /^name (.+)$/; # object's name local ($arch) = /^arch (\S+)$/; if (!defined ($name) && $arches{$arch} =~ /^name (.+)$/) { $name = $1; # archetype's name } return defined ($name) ? $name : $arch; # archetype or name } sub examine_exit { $_ = shift(@_); local ($x) = $1+0, /^hp (\d+)$/; local ($y) = $1+0, /^sp (\d+)$/; local ($x1) = $1+0, /^x (\d+)$/; local ($y1) = $1+0, /^y (\d+)$/; local ($to) = /^slaying (\S+)$/; if (/^food (-?\d+)$/) { # old style exits, doesn't work with crossfire 0.90-1 print " Error: ", &obj_name($_), " ($x1,$y1) -> ", "Old style level [$1] ($x,$y)\n"; } elsif (! defined ($to)) { print " Closed: ", &obj_name($_), " ($x1,$y1)\n"; } else { # These are currently used be crossfire if ($to =~ m!^/!) { $cdir = "$MAPS"; } else { ($cdir) = $file =~ m!(.*/)!; } if (! -f "$cdir$to") { print " Missing: ", &obj_name($_), " ($x1,$y1) -> $to ($x,$y)\n"; } else { # print " OK: ", &obj_name($_), " ($x1,$y1) -> $to ($x,$y)\n"; } } } # @maps contains all filenames sub maplist { local ($dir, $file, @dirs) = shift; opendir (DIR , $dir) || die "Can't open directory : $dir\n"; while ($file = readdir (DIR)) { next if ($file eq "." || $file eq ".."); $file = "$dir/$file"; push (@dirs, $file) if (-d $file); push (@maps, $file) if (-f $file); } closedir (DIR); # recurcive handle sub-dirs too while ($_ = shift @dirs) { &maplist ($_); } } # collect all objects matching with reg.expr. sub collect { local ($expr,$a, %col) = shift; foreach $a (keys %arches) { $_ = $arches{$a}; if (/$expr/) { $col{$a}++; } } return %col; } # collect all archetypes into associative array %arches sub archetypes { open (IN, $ARCH) || die "Can't open achetype file $ARCH.\n"; $/ = "\nend\n"; while () { if (/^Object (\S+)$/) { $arches{$1} = $_; } } close (IN); } ---8<------8<------8<------8<------8<------8<------8<------8<------8<--- From crossfire-request Thu Feb 24 08:46:52 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Thu, 24 Feb 1994 08:46:46 +0100 Received: by bolero.rahul.net id AA26940 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Wed, 23 Feb 1994 23:46:41 -0800 Date: Wed, 23 Feb 1994 23:46:41 -0800 From: Mark Wedel Message-Id: <199402240746.AA26940@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Developers. Status: RO Here is a short list of people who said specifically that they want to be on the developement team, and what they have worked on. Jari Vanhala - re-did input handling (1) Peter Mardahl runes, new spells, changing of spell parameters, new archetypes Tyler Van Gorder added color stuff, interested in working on client side (user interface) David.M.Fisher@Dartmouth.EDU (David M. Fisher) quinet@montefiore.ulg.ac.be (Raphael Quinet) Rupert G. Goldie testing under Purify, new spells, spell paths, and gifts. 'Evil' ERic Mehlhaff Client server, also works with Peter Mardahl Note 1: His patches will be in Crossfire 0.90.2 This just the semi standard bi-weekly posting of this. From crossfire-request Tue Mar 1 03:04:45 1994 Return-Path: Received: from dartvax.dartmouth.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Tue, 1 Mar 1994 03:04:44 +0100 Received: from fermat.dartmouth.edu by dartvax.dartmouth.edu (8.6.5.Beta11+DND/4.5HUB) id VAA27425; Mon, 28 Feb 1994 21:04:36 -0500 Received: by fermat.dartmouth.edu (NX5.67d/NX3.0S) id AA11925; Mon, 28 Feb 94 21:03:58 -0500 Date: Mon, 28 Feb 94 21:03:58 -0500 From: Michael Glenn Message-Id: <9403010203.AA11925@fermat.dartmouth.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: I Need NeXT help Status: RO > P.S. The Sonja.math.virginia.edu server will be back up > as soon as I get the latest version going... I'll post > again when it's ready. I might think about holding off on installing 0.90.1 and stay with 0.90.0 until the next one is released. 0.90.0 is much much more stable than 0.90.1 (at least on a NeXT), and has some features removed that were cool in 0.90.0. (search, random encounters) The crossedit in 0.90.1 won't compile at all on a NeXT. The crossedit with 0.90.0 was very unstable, but at least if you saved often you could eventually come up with a map. Michael From crossfire-request Mon Feb 28 22:12:33 1994 Return-Path: Received: from virginia.edu by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Mon, 28 Feb 1994 22:12:32 +0100 Received: from sonja.math.virginia.edu by uvaarpa.virginia.edu id aa17504; 28 Feb 94 16:12 EST Received: by sonja.math.Virginia.EDU (NX5.67c/NX3.0S) id AA10683; Mon, 28 Feb 94 16:12:18 -0500 From: "Kevin H. Weiss" Message-Id: <9402282112.AA10683@sonja.math.Virginia.EDU> Subject: I Need NeXT help To: crossfire@ifi.uio.no Date: Mon, 28 Feb 1994 16:12:15 -36803936 (EST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 300 Status: RO I'm still having trouble with xmkmf on a NeXT running X11R5 Cub'X. So, if any NeXT users would be kind enough to send a Makefile, I'd be grateful. Thanks, kevin P.S. The Sonja.math.virginia.edu server will be back up as soon as I get the latest version going... I'll post again when it's ready. From crossfire-request Mon Feb 28 08:51:08 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Mon, 28 Feb 1994 08:51:03 +0100 Received: by bolero.rahul.net id AA04532 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Sun, 27 Feb 1994 23:50:58 -0800 Date: Sun, 27 Feb 1994 23:50:58 -0800 From: Mark Wedel Message-Id: <199402280750.AA04532@bolero.rahul.net> To: crossfire@ifi.uio.no, roy@eckerd.edu Subject: Re: BUg/// Status: RO It might be because they are no longer friendly towards you after you hit them. Peacful, i believe, only affects friendly monsters/players. --Mark From crossfire-request Mon Feb 28 08:50:38 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Mon, 28 Feb 1994 08:50:33 +0100 Received: by bolero.rahul.net id AA04477 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Sun, 27 Feb 1994 23:50:02 -0800 Date: Sun, 27 Feb 1994 23:50:02 -0800 From: Mark Wedel Message-Id: <199402280750.AA04477@bolero.rahul.net> To: anthony.baxter@aaii.oz.au, mdjenkin@barney.teaching.cs.adelaide.edu.au Subject: Re: Xpm compile error, help please? Cc: crossfire@ifi.uio.no Status: RO The only real danger I know of with multiple -L arguements, is that you may pull in a library from a non desired location. For example, you might have your X11R5 stuff in /usr/lib, and X11R4 is /usr/lib.old. Now if the XPM library is also in lib.old, and a -L/usr/lib.old is done, it means taht the you will get your X11R4 libraries linked in. --Mark From crossfire-request Mon Feb 28 07:43:19 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Mon, 28 Feb 1994 07:43:14 +0100 Received: from alamein (alamein.aaii.oz.AU) by eden-valley.aaii.oz.AU with SMTP (5.65c/SMI-4.0/AAII) id AA14360; Mon, 28 Feb 1994 17:42:37 +1100 Received: by alamein; id AA21573; Mon, 28 Feb 1994 17:40:54 +1100 Message-Id: <9402280640.AA21573@alamein> To: Mike D Jenkins Cc: crossfire@ifi.uio.no From: anthony baxter Reply-To: anthony.baxter@aaii.oz.au Subject: Re: Xpm compile error, help please? In-Reply-To: Message from Mike D Jenkins of 1994-Feb-28 11:28:32, <9402280058.AA10177@barney.teaching.cs.adelaide.edu.au> Date: Mon, 28 Feb 1994 17:40:53 +1100 Sender: anthony@aaii.oz.au Status: RO Mike D Jenkins wrote: > When compiling crossfire 0.90.1 on a Sun10 running SunOS 4.1.x, X11R5, > make gave the error: > > ld: Undefined symbol > _XpmCreatePixmapFromBuffer Get a newer version of xpm, from any X archive site. XPM 3.2g or 3.3 will do. (is this in the install docs? maybe the install could be smart and check what version it is?) Petri Heinil{ wrote: > The order of libraries declared is wrong; the Xpm depends from X11, > so the X11 have to come after Xpm. The order should be: > -lcross -lXpm -lX11 . > I think the order of -L -flags is not important, but this might > be also compiler depend issue. On every compiler I've seen, the order _is_ important. -L only takes effect for libraries later on the command line, and multiple -L's are only processed as they are found in the command line. Anthony From crossfire-request Mon Feb 28 01:58:43 1994 Return-Path: Received: from tigger.cs.adelaide.edu.au by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Mon, 28 Feb 1994 01:58:39 +0100 Received: from barney.teaching.cs.adelaide.edu.au (via delivery) by tigger.cs.adelaide.edu.au with SMTP (5.65/UA-5.20) id AA09424; Mon, 28 Feb 94 11:28:35 +1030 Received: from localhost.adelaide.edu.au by barney.teaching.cs.adelaide.edu.au (5.65/SMI-4.1)id AA10177; Mon, 28 Feb 94 11:28:33 +1030 Message-Id: <9402280058.AA10177@barney.teaching.cs.adelaide.edu.au> To: crossfire@ifi.uio.no Subject: Xpm compile error, help please? Date: Mon, 28 Feb 1994 11:28:32 +1030 From: Mike D Jenkins Status: RO When compiling crossfire 0.90.1 on a Sun10 running SunOS 4.1.x, X11R5, make gave the error: gcc -ansi -Wall -o crossfire apply.o attack.o daemon.o encounter.o hiscore.o init.o input.o login.o main.o monster.o move.o obwin.o pets.o player.o shop.o socket.o sounds.o spells.o swamp.o swap.o time.o xio.o -O -pipe -L/usr/local/X11R5/lib -L../common -lcross -lXpm -lX11 ld: Undefined symbol _XpmCreatePixmapFromBuffer The file /usr/local/X11R5/lib/libXpm.a exists. Any ideas? /----------------------------------\ /-------------------------------\ | Michael D Jenkins | "We attack tomorrow under the | | mike@smug.student.adelaide.edu.au | cover of daylight. They'll | | mdjenkin@cs.adelaide.edu.au | never expect a morning charge | | Committee Member of the Adelaide | across the minefield." | | Uni Computing Students Club. | Rimmer, Red Dwarf | \----------------------------------/ \-------------------------------/ From crossfire-request Mon Feb 28 00:07:58 1994 Return-Path: Received: from acasun.eckerd.edu by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Mon, 28 Feb 1994 00:07:57 +0100 Received: by acasun.eckerd.edu (5.0/SMI-SVR4) id AA28597; Sun, 27 Feb 1994 18:04:50 +0500 Date: Sun, 27 Feb 1994 18:04:50 +0500 From: roy@eckerd.edu (Jonathan Roy) Message-Id: <9402272304.AA28597@acasun.eckerd.edu> To: crossfire@ifi.uio.no Subject: BUg/// Content-Length: 130 Status: RO If you turn off peaceful, attack someone, and turn peaceful back on, you still hit them. (This is a holdover bug back from .89) From crossfire-request Sun Feb 27 21:43:24 1994 Return-Path: Received: from acasun.eckerd.edu by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sun, 27 Feb 1994 21:43:23 +0100 Received: by acasun.eckerd.edu (5.0/SMI-SVR4) id AA25678; Sun, 27 Feb 1994 15:40:26 +0500 Date: Sun, 27 Feb 1994 15:40:26 +0500 From: roy@eckerd.edu (Jonathan Roy) Message-Id: <9402272040.AA25678@acasun.eckerd.edu> To: crossfire@ifi.uio.no Content-Length: 173 Status: RO Can someone give me a list of national crossfire sites? I'd like to try and see if I can play there with term. :) (Please be sure to reply driectly, I'm off the list...)