From crossfire-request Fri Jul 8 10:02:50 1994 Return-Path: Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 8 Jul 1994 10:02:43 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA28774 (5.67a8/IDA-1.5 for ); Fri, 8 Jul 1994 01:02:30 -0700 Received: by bolero.rahul.net id AA29978 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Fri, 8 Jul 1994 01:02:28 -0700 Date: Fri, 8 Jul 1994 01:02:28 -0700 From: Mark Wedel Message-Id: <199407080802.AA29978@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Client/server protocol Status: RO The client server discussion seems to have pretty much died. Since it needs to be done, I thought I would start working on the protcol. This is mostly Carl Edman's protocol, with some clarifications and implementation thoughts tossed in. Some of the thoughts were gleaned from the old mail log. The orignal proposal will have > prepended to the lines. Clarifcations will also be in this area. The document has also be re-organized to some extent. ============================================================================== >GENERALITIES >============ > >A bi-directional 8-bit wide clean error-free channel of some form >exists between the client and the server. Absolutely all communication >between them occurs on this channel and a client can receive everything >it needs to run through it. Typically this channel will be a TCP/IP >connection, but it may very well in some situations be a high speed >modem connection or a UN*X pipe or some completely different network >protocol. > >In practice the up channel (from client to server) and the down channel >(from server to client) function as two independent uni-directional >chutes. If one side has something to tell to the other it just drops a >packet into its send channel and forgets about it. Confirmations are >not given or expected. The sender just assumes that the receiver will >handle the packet or it will complain in another packet. At the same >time the two chutes may be communicating about two entirely different >subjects. > >Each packet consists out of one line of text terminated by a newline >(0x0a) character. Line lengths of up to 4096 characters (including the >terminating newline) are guaranteed to work. The receiver may >correctly interpret longer packets, silently drop them or send an error >message (see below) depending on what makes sense for the receiver. >All characters are case sensitive. > >Every packet begins with a word terminated either by a space (0x20) or >the end of the packet. The interpretation of the rest of the line >depends on the initial word. > I see no real problems in this area of the protocol. However, see notes on startup (below) about extensions. ============================================================================== STARTUP ======= >C->S:LOGIN >Typically this will be the first command sent by the client. If it is >sent during a session, the effect is the same as if the session had >been terminated and a new connection had been established with this >command. is a string created by the client at compile >time. The server is not encouraged to treat different clients >differently. This string is just there to be able to gather statistics >(and to correlate with ERROR packets). and are >self-explanatory. (both): PROTOCOL (revision) This is the protocol that both the client and server understands. In this way, new commands can be added without requiring all clients to be upgraded (the server recognizes it is an old client, and avoids the new commands). The server is required to be backward compatible with all revisions, so a client can never be outdated (exceptions may be made for very old and no longer needed commands). The client is not required to understand more than its current revision. If it is a newer revision than the server, than an error will result from the server. In general, changes to the protocol should not happen very often, but this gives a mechanism for making changes and not requiring every client to upgrade. C->S: There should be some mechanism for the client getting all the data it needs now instead of making REQUEST commands later. On a slow link, you may very wall want a slow startup time in exchange for minimal data transfer once the game begins (ie, you don't want to enter a room, and have the game freeze for a few ticks and the image of the monster is transmitted). Likewise, on fast links, you may very wall to transmit the data as you need to. C->S: STACKING (depth) This is how many images the client plans to display per space. If using fonts or bitmaps, then any value beyond 1 does not have any meaning. For pixmaps, this can have meaning up to a reasonably high number. However, how it is handled becomes a little more difficult. If a stacking of 2 is requested, I should only see 2 objects (perhaps floor + top object). If three objects, should I see both floors (DOUBLE_FLOOR_PATCH) + top object? one floor + the 2 top objects? The details of this needs to be worked out. The server is not required to do anything with this request. IT is just that, a request that will hopefully cut down on the amount of unnecessary data transmitted. ============================================================================== >VALID COMMANDS FROM THE SERVER TO THE CLIENT >============================================ >MAP ... >Using one of these commands the server may tell the client that it sees >the map at a series of location given by coordinate pairs. The name >refers to the image to use for the particular map location. If the >client doesn't know that particular name, it asks the server for it >(see REQUEST/TRANSMIT). Note that all (locx,locy) pairs are map relative, not center relative (in other words, the locx,locy values are the same as the (server) ob->x and ob->y values. > >UNMAP ... >This command tells the client that a certain series locations isn't any >longer in the LOS of the player. The client may respond to this by >erasing the squares in question, shading them to indicate to the user >that they aren't any longer directly visible or just by doing nothing. > >ITEM >Tells the client that the player seen an item with the tag at >the location ,. indicates the name of the image >file to use for the item and is the full name of the item. In >addition, may also be the string "IN". In that case is >the tag number of the item within which the item at hand is located or > is the string "VOID" which means that the item has disappeared. > >VIEW >After this command the client considers the item with the tag >to be the viewpoint item and will always try to center the map around >it. This is typically the item which is the player object. By followups, is a unique number of each item. A bunch of orcs may have numbers 500,501,505, 508, etc. should probably be the archetype name. In this way, the client will know about the animations, as well as the item name. However, image names in objects can be modified (ie, have a key look like a horn). Also, some objects could have their animations disabled. Also, it seems to me that sending the monsters along with all they are carrying is something not immediately needed. In general, I could care less what an orc is carrying, and would probably prefer for it to be inserted into the map when I kill him. But even then, I only care about the number items up to my STACKING depth. I also want to be able to use a local archetypes file if possible. Not the full information contained in the archetype file is necessary, but things like name and animations would be. But what this allows me to do is adjust things like animations. I may not want sea and grass animated, or things like the fire in fireballs, simply because I have a slow X-server, and these slow things down too much. By having a local archetypes file, these can be adjusted fairly easily to my tastes. I believe in some followup, both MAP and ITEM commands and (light_value) as part of their description (if/when light sources get added). These are not needed right now - the PROTOCOL revision can add this in later, and still have things work. Examples of how the above works (taken from another mail message by Carl): Server->Client: VIEW 123 (states that object 123 is the center object of the map, and calculates LOS accordingly). S->C: MAP 40 40 floor 41 40 wall 42 40 wall ... (sets what objects are where. IT is not clear in the present protocol about sending two different images with the same coordinate via the map command. I would think that this means that there are those two images there, and not that an overwrite should occur) S->C: ITEM 123 44 44 1 Carlsimage Carl ^ ^ ^ ^ ^ ^ Itemtag ---| | | | | | X coordinate ---| | | | | Y coordinate ------| | | | Quantity ------------| | | Name of image ----------| | Name of item ----------------------| (this is the player item. The view command centers the map around this object). S->C: ITEM 433 IN 123 1 helmetimage X ray Helmet (worn) Tells the client that this item is in the player item. It can keep track of this in the inventory window. Note that the (worn) is just part of the name. If the client recognizes this and then does something special, that is its perogative. More item commands like the above would happen as the players inventory is sent. Now that you could having something like: S->C: ITEM 600 IN 123 1 luggage The Luggage S->C: ITEM 605 IN 600 5 gems Gems The first states that the player is carrying the luggage, and the second is stating that he has 5 gems in the luggage. C->S: MOVE 123 44 45 A request by the client to move the player (object 123) south (from 44 to 45). Remember, that the maps make 0,0 as the upper left corner, not lower left as in standard geometry. The server then process this command. If the player can make this move (no wall), and when sufficient time has passed (slowdown factor), it sends: S->C: ITEM 123 44 45 Telling the client that object 123 is now at 44,45. IT does not need to send full data, since this object never left LOS. However, this does require that the server keep track of an object in LOS or if it leaves it. This because a bit of an implementation problem - you don't want to keep track of whether each object is in LOS for each player - this would chew up a lot of memory and would probably hard code some maximum number of players (if you use an int, you only have 32 bits for LOS for players). As I see it, an array of some sort will need to be kept in the player structure, with this array containing what objects/images were last drawn around the player. Then each tick, you go through and see what is around the player, and see if any new objects have appeared, and send ITEM/MAP commands for them. A linked list could be used to keep track of the items it has sent descriptions for. Another method would be to keep track of this information when the object changes/moves. Perhaps have a few fields of linked list of objects in the players - one for 'changed' and one for entered field of view. Then, when the object moves/does whatever, it checks to see if it is in any players field of view, and if so, puts itself on one of those lists (changed or entered field of view). Then, this data is processed, and it woudl be decided if it is sent down the line or not (determined via stacking). However, this would require all ITEM commands need to be sent, or you once again need to keep track someplace what items have been sent down the line (and also need to somehow keep track of what was sent down the line but is no longer visible. IF anyone has good ideas on how to handle this area, I would be interested. Back to the player moving (S->C: ITEM 123 44 45): When the client recieves this, it should scroll the map up one. It now sends a map command to fill the new bottom row up: S->C: MAP 40 50 wall 41 50 wall 42 50 wall ... S->C: UNMAP 40 40 41 40 ... removes the row that scrolled off. I personally don't think this is necessary - if a row scrolls off the edge of the display, it should be taken as an implicit unmap. LOS is updated (IMHO, this should be done before the MAP command), and new object that appear are sent: S->C: ITEM 642 45 50 1 orcimage Orc chieftain Orc wants to attack player, so it moves towards him: S->C: ITEM 642 45 49 S->C: ITEM 642 45 48 S->C: ITEM 642 45 47 Since the item tag number is unique, each item command effectively removes the previous location. Problem: This requires that for each ITEM command received by the client, the client needs to search through all the old ITEM objects it has stored to see if an item of that tag exists someplace else. The player decides to drop his helmet (has not moved any spaces): C->S: MOVE 433 44 45 This is a request by the client to drop the helmet. Effectively, it is a move out of inventory and onto the map. S->C: ITEM 433 44 45 Server process the command. Note that the client has to search through all the items it knows about and find the one with tag 433 and remove it. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ More SERVER->CLIENT commands: >TEXT ... >This commands instructs the client to display the remainder of the line >(after the space character terminating the TEXT command) verbatim in >some sort of text area. The client may word wrap the text. > >PLAY >Instructs the client to play the sound with the specified name. If the >client doesn't know the sound by that name it requests it from the >server (see REQUEST/TRANSMIT). At startup, their should also be a mechanism for the client to state it doesn't have sound, and thus, PLAY commands should not be sent (probably a minor bandwidth savings) >STAT [] >This tells the client that the value of the player statistic called > is . If given indicates the maximum value of >that stat. The client could simply print out this message in the text >area, but it is encouraged to recognize at least a few commonly used >stats like hp or sp or food and make up some cute graphical >representation for them which the player sees at all times. > >REQUEST >Ask the client to send the the binary file called of type >using the TRANSMIT command. It is unclear why the server would ever make a request. And in fact, this could be considered a security problem (server requests some file it has no business knowing about (ie, /etc/passwd). I suppose that an option in the client to ignore REQUEST's would solve this potential problem. > >TRANSMIT >This command is followed by binary data of the length bytes >which describes the binary object of name of type >(typically either IMG or SND). All other command interpretation is >suspended while the binary data streams in. After the binary data has >been received normal command interpretation resumes immediately. > > >ERROR <...> >This command is used to indicate that a real error has occured. The >remainder of the line is some free form text describing that error. >What the client does with that message is up to it. This command is >only used to indicate actual program errors which point to >bugs/incompatibilities between it and the server such as malformed >packets and the like. Player errors (like trying to take something >which isn't there) are handled by normal TEXT messages. > >QUERY <...> >Ask the user a question with the text <...>. Some clients may want to >pop up a requestor for this. Others may not. The answer is taken from >the next REPLY packet sent by the client. > This is a really a convenience command. It is not needed, and usage of the TEXT and SAY command (see below) could also be used. ============================================================================== VALID COMMANDS FROM THE CLIENT TO THE SERVER ============================================ >LOGIN >Typically this will be the first command sent by the client. If it is >sent during a session, the effect is the same as if the session had >been terminated and a new connection had been established with this >command. is a string created by the client at compile >time. The server is not encouraged to treat different clients >differently. This string is just there to be able to gather statistics >(and to correlate with ERROR packets). and are >self-explanatory. > >REQUEST >TRANSMIT >ERROR >These three commands are valid in this direction as well with the same >syntax and semantics. > >MOVE >This is probably the most frequently used command. In it the client >asks the server to move the item with tag to be moved to >location , . As with ITEM (see above) can also be >the string "IN" in which case is the tag of an item into which >the item at hand should be moved. A player would use this command to >pick up items, to drop them, to throw them, to steal them and most >importantly to move himself around the map (with == the tag >number which the client was told by the VIEW command). Clients may >want to take single steps or can ask to run as far as possible in one >direction by giving huge values for or . > >APPLY >The player tries to apply the item with tag . > >INVOKE >The player actually casts the spell with name at , >(as with MOVE, can be "IN" and an item tag number to cast >a spell at an item). > >SAY <...> >The player says whatever the free-form text which follows on the line >is. Other players would see this by means of some TEXT message. > >REPLY [YES|NO] >The response to the most recent QUERY command. > > COMMAND (command): This is a simple extension. Various servers may add commands that do not warrant extending the protocol. Right now, there are many commands that really do not need individual protocl requests (who, help, etc). An option in the client can exist to pass the command directly to the server. If the server does not understand the command, it can send the error back as TEXT message. Various thoughts are welcome. I am really worried about finding a good way to implement the MAP and ITEM commands in an efficient manner. Mark Wedel master@rahul.net From crossfire-request Thu Jul 7 21:01:51 1994 Return-Path: Received: from soda.berkeley.edu (soda.Berkeley.EDU [128.32.149.19]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 7 Jul 1994 21:01:50 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.9/PHILMAIL-1.10) id MAA29196 for crossfire@ifi.uio.no; Thu, 7 Jul 1994 12:01:47 -0700 From: Philip Brown Message-Id: <199407071901.MAA29196@soda.berkeley.edu> Subject: Re: Compiling crossfire-0.91.2 To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Thu, 7 Jul 1994 12:01:45 -0700 (PDT) In-Reply-To: <27983.773584851@mailhost.aber.ac.uk> from "Benjamin Thomas Ketteridge" at Jul 7, 94 01:40:51 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 604 Status: RO >>>>[From Benjamin Thomas Ketteridge] Hi folks, I've been having rather a lot of difficulty compiling crossfire-0.91.2 under Solaris 2.3 (SunOS 5.3). In fact it was so difficult, I gave up and I'm using SunOS 4.1.3 instead! The problems start right at the beginning where xmkmf produces this: imake -I/usr/openwin/lib/config Mmmm... Well, you do know that as usualy, Sun shipped a busted imake ? But that's not the problem. I have adjusted my openwin imake, and it starts with the above line, yet works just fine. You need to specify what exactly does not work. From crossfire-request Thu Jul 7 16:06:15 1994 Return-Path: Received: from idiom.berkeley.ca.us (idiom.berkeley.ca.us [140.174.82.4]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 7 Jul 1994 16:06:01 +0200 Received: from idiom.berkeley.ca.us (localhost [127.0.0.1]) by idiom.berkeley.ca.us (8.6.8/8.6.6) with ESMTP id HAA27653; Thu, 7 Jul 1994 07:05:07 -0700 Message-Id: <199407071405.HAA27653@idiom.berkeley.ca.us> To: Benjamin Thomas Ketteridge cc: crossfire@ifi.uio.no Subject: Re: Compiling crossfire-0.91.2 In-reply-to: Your message of "Thu, 07 Jul 1994 13:40:51 BST." <27983.773584851@mailhost.aber.ac.uk> Date: Thu, 07 Jul 1994 07:05:06 -0700 From: Jason Venner Status: RO xmkmf on the sun checks for the environment variable OPENWINHOME. If it is present, it is used as the base of the path to the config files. > From crossfire-request@ifi.uio.no Thu Jul 7 06:37:58 1994 > To: crossfire@ifi.uio.no > Subject: Compiling crossfire-0.91.2 > Date: Thu, 07 Jul 1994 13:40:51 +0100 > From: Benjamin Thomas Ketteridge > > Hi folks, I've been having rather a lot of difficulty compiling crossfire-0.91.2 > under Solaris 2.3 (SunOS 5.3). In fact it was so difficult, I gave up and I'm > using SunOS 4.1.3 instead! > > The problems start right at the beginning where xmkmf produces this: > > imake -I/usr/openwin/lib/config > > instead of this: > > imake -DUseInstalled -I/usr/local/X11R5/lib/X11/config > > !! And it gets worse from there on! :-( > The compilation on SunOS 4 is proceeding nicely (now that I've removed the > few object files the attempt under Solaris 2.3 produced) :-) > > Help?! Ben. > +--------------------------------------------------------------------------+ > | _|--|_ | Disclaimer: I've got a degree and maybe 1/2 of a PhD. | > | (\/) +--------------------------------+--------------------------+ > | vv | However, I still know nothing! | btk@aber.ac.uk | > +--------------+--------------------------------+--------------------------+ > From crossfire-request Thu Jul 7 15:25:52 1994 Return-Path: Received: from cc.lut.fi (hevi@cc.lut.fi [157.24.10.16]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 7 Jul 1994 15:25:50 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id QAA12508; Thu, 7 Jul 1994 16:25:34 +0300 Date: Thu, 7 Jul 1994 16:25:33 +0300 (EETDST) From: "Petri.Heinila" Subject: Re: Compiling crossfire-0.91.2 To: Benjamin Thomas Ketteridge cc: crossfire@ifi.uio.no In-Reply-To: <27983.773584851@mailhost.aber.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 7 Jul 1994, Benjamin Thomas Ketteridge wrote: > Hi folks, I've been having rather a lot of difficulty compiling crossfire-0.91.2 > under Solaris 2.3 (SunOS 5.3). In fact it was so difficult, I gave up and I'm > using SunOS 4.1.3 instead! I have always wondered why people don't like solaris :) > The problems start right at the beginning where xmkmf produces this: > > imake -I/usr/openwin/lib/config > > instead of this: > > imake -DUseInstalled -I/usr/local/X11R5/lib/X11/config The -DUseInstalled flag says you are using installed X11 and is *essential* when compiling X11 clients, so in your openwin settings has a bug, look out the xmkmf, it's a script. So you can also try: imake -DUseInstalled -I/usr/openwin/lib/config -- The Page -- From crossfire-request Thu Jul 7 14:41:33 1994 Return-Path: Received: from mailsun.aber.ac.uk (isode@mailsun.aber.ac.uk [144.124.16.7]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 7 Jul 1994 14:41:30 +0200 Received: from mailhost.aber.ac.uk (actually saturn.dcs.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (PP); Thu, 7 Jul 1994 13:40:57 +0100 To: crossfire@ifi.uio.no Subject: Compiling crossfire-0.91.2 Date: Thu, 07 Jul 1994 13:40:51 +0100 Message-ID: <27983.773584851@mailhost.aber.ac.uk> From: Benjamin Thomas Ketteridge Status: RO Hi folks, I've been having rather a lot of difficulty compiling crossfire-0.91.2 under Solaris 2.3 (SunOS 5.3). In fact it was so difficult, I gave up and I'm using SunOS 4.1.3 instead! The problems start right at the beginning where xmkmf produces this: imake -I/usr/openwin/lib/config instead of this: imake -DUseInstalled -I/usr/local/X11R5/lib/X11/config !! And it gets worse from there on! :-( The compilation on SunOS 4 is proceeding nicely (now that I've removed the few object files the attempt under Solaris 2.3 produced) :-) Help?! Ben. +--------------------------------------------------------------------------+ | _|--|_ | Disclaimer: I've got a degree and maybe 1/2 of a PhD. | | (\/) +--------------------------------+--------------------------+ | vv | However, I still know nothing! | btk@aber.ac.uk | +--------------+--------------------------------+--------------------------+ From owner-crossfire Fri Jul 1 20:01:34 1994 Return-Path: Received: from ns.ge.com (ns.ge.com [192.35.39.24]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 1 Jul 1994 20:01:26 +0200 Received: from [129.204.6.42] by ns.ge.com (5.65/GE Gateway 1.23) with SMTP id AA23134; Fri, 1 Jul 94 13:53:40 -0400 Received: from kauai.MOTOWN.GE.COM (kauai.MOTOWN.GE.COM [129.204.4.64]) by serling.MOTOWN.GE.COM (8.6.8.1/8.6.6) with ESMTP id OAA16770 for ; Fri, 1 Jul 1994 14:01:02 -0400 From: "Brett C. Helbig" Received: (bhelbig@localhost) by kauai.MOTOWN.GE.COM (8.6.8.1/8.6.6) id OAA02770 for crossfire-bugs@ifi.uio.no; Fri, 1 Jul 1994 14:01:01 -0400 Date: Fri, 1 Jul 1994 14:01:01 -0400 Message-Id: <199407011801.OAA02770@kauai.MOTOWN.GE.COM> To: crossfire-bugs@ifi.uio.no Subject: crossfire bug Status: RO I am having a problem with crossfire that is causing it to crash intermittently. I am running version 0.91.1 on a Sun running SunOS 4.1.3 and Openwindows. I compiled crossfire with gcc version 2.1 with the default flags in the makefile. The output of crossfire before the bug is the following: ld.so: warning: /usr/openwin/lib/libX11.so.4.3 has older revision than expected 10 Welcome to CrossFire, v0.91.1 Copyright (C) 1994 Mark Wedel. Copyright (C) 1992 Frank Tore Johansen. Error: get_map_ob called when mas was not in memory. Abort Here is the output of "crossfire -o": ld.so: warning: /usr/openwin/lib/libX11.so.4.3 has older revision than expected 10 Welcome to CrossFire, v0.91.1 Copyright (C) 1994 Mark Wedel. Copyright (C) 1992 Frank Tore Johansen. Non-standard include files: Secure: Logging: Libdir: /home/bhelbig/bin/crossfire-0.91.1/lib Perm file: /forbid Shutdown file: /shutdown Save player: Save mode: 0666 Playerdir: /players Save homedir: Lock player: Unique items: Itemsdir: /unique-items Lock items: Use checksum: Tmpdir: /tmp Fontdir: /home/bhelbig/bin/crossfire-0.91.1/fonts Compress: /local/bin/compress Uncompress: /local/bin/uncompress Map max timeout: 1000 Map reset: Max objects: 6000 Use_calloc: Speed_game: Use_los: CD los: CHRFONT: Use_swap_stats: Sound_effects: Server: Explore mode: Shop listings: Max_time: 120000 SunOS kauai 4.1.3 1 sun4m As I said, the problem is intermittent but causes the program to crash before I have played the game for too long. The time between starting the game and the crash varies but is not longer than about 2 minutes. Please let me know what I can do to fix this problem. Thanks. Brett Helbig From crossfire-request Sat Jul 23 04:56:56 1994 Return-Path: Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 23 Jul 1994 04:56:52 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA29724 (5.67a8/IDA-1.5 for ); Fri, 22 Jul 1994 19:56:37 -0700 Received: by bolero.rahul.net id AA26509 (5.67a8/IDA-1.5); Fri, 22 Jul 1994 19:56:35 -0700 Date: Fri, 22 Jul 1994 19:56:35 -0700 From: Mark Wedel Message-Id: <199407230256.AA26509@bolero.rahul.net> To: peterm@soda.berkeley.edu, rjf@acsu.buffalo.edu Subject: Re: newbie ?: crossclient? Cc: crossfire@ifi.uio.no Status: RO Correct - crossclient is nothing more than a simple front end program that sends the commands to start up crossfire on your screen - in fact, it probably sends the same commands. Using the font may not quicken things up much. IF the link is slow or overburdened (ie, 56 Kb link), nothing short of a faster network connection will solve the problem. From crossfire-request Fri Jul 22 17:07:22 1994 Return-Path: Received: from soda.Berkeley.EDU (soda.Berkeley.EDU [128.32.149.19]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 22 Jul 1994 17:07:17 +0200 Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by soda.Berkeley.EDU (8.6.9/PHILMAIL-1.10) with SMTP id IAA14769; Fri, 22 Jul 1994 08:07:06 -0700 Message-Id: <199407221507.IAA14769@soda.Berkeley.EDU> To: "Robert J. Feuerbach" cc: crossfire@ifi.uio.no Subject: Re: newbie ?: crossclient? In-reply-to: Your message of "Fri, 22 Jul 1994 08:40:13 EDT." <199407221240.IAA05572@lictor.acsu.buffalo.edu> Date: Fri, 22 Jul 1994 08:07:04 -0700 From: Peter Mardahl Status: RO In message <199407221240.IAA05572@lictor.acsu.buffalo.edu>, "Robert J. Feuerbac h" writes: > >Sorry guys, I'm yet another newbie... > >I've attempted to play crossfire using the telnet command, however it was >rather slow and unresponsive (as would be expected with that much network >dependence). In the WWW page at Cardiff (http://www.cm.cf.ac.uk/Crossfire/) >it mentions starting the game with a command like crossclient, but I haven't >seen any source for the client program. Does it exist and where might it >be found if it does? > >Thanks, >Rob >(aka Scorch) > The crossfire 'client' is no quicker than the telnet. Ask the server maintainers where you play to get you the font. PeterM From crossfire-request Fri Jul 22 14:40:29 1994 Return-Path: Received: from lictor.acsu.buffalo.edu (rjf@lictor.acsu.buffalo.edu [128.205.7.4]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 22 Jul 1994 14:40:25 +0200 Received: (rjf@localhost) by lictor.acsu.buffalo.edu (8.6.8/8.6.4) id IAA05572 for crossfire@ifi.uio.no; Fri, 22 Jul 1994 08:40:13 -0400 Date: Fri, 22 Jul 1994 08:40:13 -0400 From: "Robert J. Feuerbach" Message-Id: <199407221240.IAA05572@lictor.acsu.buffalo.edu> To: crossfire@ifi.uio.no Subject: newbie ?: crossclient? Status: RO Sorry guys, I'm yet another newbie... I've attempted to play crossfire using the telnet command, however it was rather slow and unresponsive (as would be expected with that much network dependence). In the WWW page at Cardiff (http://www.cm.cf.ac.uk/Crossfire/) it mentions starting the game with a command like crossclient, but I haven't seen any source for the client program. Does it exist and where might it be found if it does? Thanks, Rob (aka Scorch) From crossfire-request Fri Jul 22 14:15:39 1994 Return-Path: Received: from waldorf.informatik.uni-dortmund.de (waldorf.Informatik.Uni-Dortmund.DE [129.217.4.42]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 22 Jul 1994 14:15:36 +0200 Received: from marvin.informatik.uni-dortmund.de by waldorf.informatik.uni-dortmund.de with SMTP (Sendmail 8.6.9/UniDo 2.0.19) id OAA17881; Fri, 22 Jul 1994 14:15:28 +0200 From: Sven Neuhaus Message-Id: <9407221215.AA29596@marvin.informatik.uni-dortmund.de> Received: by marvin.informatik.uni-dortmund.de id AA29596; Fri, 22 Jul 94 14:15:27 +0200 Subject: Re: WWW Home Page for Crossfire? To: snead@cs.ucf.edu (Aphrodite) Date: Fri, 22 Jul 1994 14:15:26 +0200 (MET DST) Cc: crossfire@ifi.uio.no In-Reply-To: <199407220328.AA00366@longwood.cs.ucf.edu> from "Aphrodite" at Jul 21, 94 11:28:19 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: 520 Status: RO > I know there isn't a FAQ, but is there a WWW Home Page somewhere? Yeah. I don't know the URL right now, but my links page has a pointer to it: http://www.ping.de/~sven/links.html There are multiple (3?) webs for crossfire and they have pointers to each other as far as I remember. -Sven -- Sven Neuhaus, CS student at University of Dortmund, Germany""Internet for Netrek, Doom, Crossfire & Empire addict. PGP key available @@ the masses! terrorism pornography explosive KGB CIA FBI IRA RAF BND NSA\/info@ping.de From crossfire-request Fri Jul 22 14:04:24 1994 Return-Path: Received: from lictor.acsu.buffalo.edu (rjf@lictor.acsu.buffalo.edu [128.205.7.4]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 22 Jul 1994 14:04:21 +0200 Received: (rjf@localhost) by lictor.acsu.buffalo.edu (8.6.8/8.6.4) id IAA02453; Fri, 22 Jul 1994 08:04:02 -0400 From: "Robert J. Feuerbach" Message-Id: <199407221204.IAA02453@lictor.acsu.buffalo.edu> Subject: Re: WWW Home Page for Crossfire? To: snead@cs.ucf.edu (Aphrodite) Date: Fri, 22 Jul 1994 08:04:02 -0400 (EDT) Cc: crossfire@ifi.uio.no In-Reply-To: <199407220328.AA00366@longwood.cs.ucf.edu> from "Aphrodite" at Jul 21, 94 11:28:19 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: 335 Status: RO >From: "Aphrodite (Deborah L. Snead)" >I know there isn't a FAQ, but is there a WWW Home Page somewhere? There are a number of pages that I know of: the one I look at most often is http://www.cm.cf.ac.uk/Crossfire/ , known as Cardiff's Crossfire pages. There are some links from here to pages at other sites. Rob From crossfire-request Fri Jul 22 05:56:02 1994 Return-Path: Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 22 Jul 1994 05:55:58 +0200 Received: from crl.crl.com (crl.com) by mail.crl.com with SMTP id AA08491 (5.65c/IDA-1.5 for ); Thu, 21 Jul 1994 20:55:24 -0700 Received: from localhost.crl.com.0.0.127.IN-ADDR.ARPA by crl.crl.com with SMTP id AA28841 (5.65c/IDA-1.5); Thu, 21 Jul 1994 20:55:22 -0700 Message-Id: <199407220355.AA28841@crl.crl.com> To: Peter Mardahl Cc: "Aphrodite (Deborah L. Snead)" , crossfire@ifi.uio.no, mehlhaff@crl.com Subject: Re: Playing Crossfire In-Reply-To: Message from Peter Mardahl of Wed, 20 Jul 1994 16:01:56 -0700 <199407202301.QAA22132@soda.Berkeley.EDU> Date: Thu, 21 Jul 1994 20:55:21 -0700 From: "'Most Excellent' Eric Mehlhaff" Status: RO Peter Mardahl recently wrote: >In message <199407202239.AA08500@longwood.cs.ucf.edu>, "Aphrodite (Deborah L. >S >nead)" writes: > > When are we going to start maintaining a FAQ? > >Anyway, to play crossfire via telnet: >>xhost coke.csua.berkeley.edu >>xset +fp tcp/coke.csua.berkeley.edu:13325 (This will make loading qui >cker) >>telnet coke.csua.berkeley.edu 13326 >Trying 128.32.131.73 ... >Connected to coke.csua.berkeley.edu. >Escape character is '^]'. >set font >add alfven.eecs.berkeley.edu (you use YOUR machine here) If you ask me, perhaps we should have the crossfire server send the socket some kind of greeting message upon accepting the connection? This'd work sort of the same way smtp/nntp daemons send greeting messages. Eric Mehlhaff, mehlhaff@crl.com From crossfire-request Fri Jul 22 05:28:28 1994 Return-Path: Received: from longwood.cs.ucf.edu (longwood.cs.ucf.edu [132.170.108.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 22 Jul 1994 05:28:25 +0200 Received: by longwood.cs.ucf.edu id AA00366 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Thu, 21 Jul 1994 23:28:19 -0400 Date: Thu, 21 Jul 1994 23:28:19 -0400 From: "Aphrodite (Deborah L. Snead)" Message-Id: <199407220328.AA00366@longwood.cs.ucf.edu> To: crossfire@ifi.uio.no Subject: WWW Home Page for Crossfire? Status: RO I know there isn't a FAQ, but is there a WWW Home Page somewhere? From crossfire-request Thu Jul 21 18:49:27 1994 Return-Path: Received: from oasys.dt.navy.mil (oasys.dt.navy.mil [130.46.1.53]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 21 Jul 1994 18:49:24 +0200 Received: from thedude.dt.navy.mil by oasys.dt.navy.mil (5.61/oasys.dt.navy.mil) id AA22302; Thu, 21 Jul 94 12:49:17 EDT Received: by TheDude.dt.navy.mil. (4.1/SMI-4.1) id AA01450; Thu, 21 Jul 94 12:49:09 EDT Date: Thu, 21 Jul 94 12:49:09 EDT From: flitter@@.dt.navy.mil (Lance Flitter) Message-Id: <9407211649.AA01450@TheDude.dt.navy.mil.> To: crossfire@ifi.uio.no Subject: Can't save... Status: RO I recently installed crossfire 0.91.1. Every time I try to save a character I get the message "Can't open save file" or some such. What's my problem? I set the player dir in the config.h and it is writable. Lance Flitter flitter@oasys.dt.navy.mil From owner-crossfire Thu Jul 21 16:39:19 1994 Return-Path: Received: from mpef4.logica.co.uk. (mpef4.logica.co.uk [158.234.33.229]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 21 Jul 1994 16:39:10 +0200 Message-Id: <199407211439.6958.ifi@ifi.uio.no> Received: from mpefcp1.logica.co.uk. (mpefcp1.logica.co.uk) by mpef4.logica.co.uk with SMTP (1.37.109.10G/16.2) id AA179085257; Thu, 21 Jul 1994 16:40:57 +0100 Received: by mpefcp1.logica.co.uk (1.38.193.4/16.2) id AA04189; Thu, 21 Jul 1994 15:39:19 GMT Date: Thu, 21 Jul 1994 15:39:19 GMT From: Ian Randell To: crossfire-bugs@ifi.uio.no Subject: Makefile error in crossfire-0.91.2... Cc: randelli@mpef4.logica.co.uk Status: RO Hi, Im trying to compile crossfire-0.91.2 on a HP9000/700. Unfortunately a makefie error occurs: > {mpefcp3} % xmkmf > imake -DUseInstalled -I/usr/local/common/lib/imake > {mpefcp3} % make Makefiles > making Makefiles in ./common... > making Makefiles in ./doc... > making Makefiles in ./doc/spoiler... > Make: line 460: syntax error. Stop. > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. I have changed the crosssite.def file, but I dont see that it would produce this result. I havent changed any of the makefiles. Any ideas ??? Im not an expert on makefiles :) Cheers. Ian. From crossfire-request Thu Jul 21 03:59:32 1994 Return-Path: Received: from sol.UVic.CA (sol.UVic.CA [142.104.1.4]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 21 Jul 1994 03:59:28 +0200 Received: from sirius.UVic.CA by sol.UVic.CA (4.1/SMI-4.1.3-UVic-2.58MX) id AA21006; Wed, 20 Jul 94 19:00:20 PDT Received: from uglw.UVic.CA by sirius.UVic.CA (4.1/SMI-4.1-Engr.UVic.CA-H) id AA05624; Wed, 20 Jul 94 18:59:14 PDT From: jbaker@sirius.uvic.ca (Krenn) Message-Id: <9407210159.AA05624@sirius.UVic.CA> Subject: Re: Playing Crossfire To: crossfire@ifi.uio.no (crossfire) Date: Wed, 20 Jul 1994 18:59:13 -0700 (PDT) In-Reply-To: <199407202301.QAA22132@soda.Berkeley.EDU> from "Peter Mardahl" at Jul 20, 94 04:01:56 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1286 Status: RO > When are we going to start maintaining a FAQ? When you get excessively annoyed at newbies :-> > Anyway, to play crossfire via telnet: > >xhost coke.csua.berkeley.edu > >xset +fp tcp/coke.csua.berkeley.edu:13325 (This will make loading quicker) Wish I could get this part to work - xset keeps crashing here on a bad opcode, doesn't matter if I get the fonts via fstobdf or try your fontserver. *sigh* And it's not like I can ask the sysadmin here for help, seeing as there's no legitimate reason I'd need to change something with xset other than games :P > >telnet coke.csua.berkeley.edu 13326 > Trying 128.32.131.73 ... > Connected to coke.csua.berkeley.edu. > Escape character is '^]'. > set font And another question... what other types of "sets" are there? The online help (IE: 'help ) doesn't work on any command I've looked for indepth help on yet, including "'help set". -- Vlad_K-Fuchida - BT3056 MUSE, 321st ComGuard Grenadiers | PGP Public MagLev - Shadowrun MUSH, Constructor | key available Silver Samurai - UVic Oggsquad (Summer INL Team) | via finger Krenn - Shire of Ramsgaard, Kingdom of An Tir, SCA | and keyservers GE: d- -p+ c++++ l u+ e+ m---(++) s++/ n h* f+ g+ w+ t++ r++ y? From crossfire-request Thu Jul 21 01:02:32 1994 Return-Path: Received: from soda.Berkeley.EDU (soda.Berkeley.EDU [128.32.149.19]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 21 Jul 1994 01:02:24 +0200 Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by soda.Berkeley.EDU (8.6.9/PHILMAIL-1.10) with SMTP id QAA22132; Wed, 20 Jul 1994 16:01:58 -0700 Message-Id: <199407202301.QAA22132@soda.Berkeley.EDU> To: "Aphrodite (Deborah L. Snead)" cc: crossfire@ifi.uio.no Subject: Re: Playing Crossfire In-reply-to: Your message of "Wed, 20 Jul 1994 18:39:50 EDT." <199407202239.AA08500@longwood.cs.ucf.edu> Date: Wed, 20 Jul 1994 16:01:56 -0700 From: Peter Mardahl Status: RO In message <199407202239.AA08500@longwood.cs.ucf.edu>, "Aphrodite (Deborah L. S nead)" writes: When are we going to start maintaining a FAQ? Anyway, to play crossfire via telnet: >xhost coke.csua.berkeley.edu >xset +fp tcp/coke.csua.berkeley.edu:13325 (This will make loading quicker) >telnet coke.csua.berkeley.edu 13326 Trying 128.32.131.73 ... Connected to coke.csua.berkeley.edu. Escape character is '^]'. set font add alfven.eecs.berkeley.edu (you use YOUR machine here) Regards, PeterM From crossfire-request Thu Jul 21 00:40:20 1994 Return-Path: Received: from longwood.cs.ucf.edu (longwood.cs.ucf.edu [132.170.108.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 21 Jul 1994 00:40:15 +0200 Received: by longwood.cs.ucf.edu id AA08500 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Wed, 20 Jul 1994 18:39:50 -0400 Date: Wed, 20 Jul 1994 18:39:50 -0400 From: "Aphrodite (Deborah L. Snead)" Message-Id: <199407202239.AA08500@longwood.cs.ucf.edu> To: crossfire@ifi.uio.no Subject: Playing Crossfire Status: RO Okay I need BIG hint. When I do this command telnet sonja.math.virginia.edu 13326 I never SEE anything. Don't I need a client program? If not then what am doing wrong. Thank You. From crossfire-request Wed Jul 20 21:34:08 1994 Return-Path: Received: from virginia.edu (uvaarpa.Virginia.EDU [128.143.2.7]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 20 Jul 1994 21:34:03 +0200 Received: from sonja.math.virginia.edu by uvaarpa.virginia.edu id aa13961; 20 Jul 94 15:33 EDT Received: by sonja.math.Virginia.EDU (NX5.67c/NX3.0S) id AA05335; Wed, 20 Jul 94 15:34:00 -0400 From: "Kevin H. Weiss" Message-Id: <9407201934.AA05335@sonja.math.Virginia.EDU> Subject: Fontserver running on sonja To: crossfire@ifi.uio.no Date: Wed, 20 Jul 1994 15:33:59 -36803936 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 199 Status: RO Hi there! I finally have a font server running on sonja.math.virginia.edu port 13325 (Thank you, PeterM) Just type: xset +fp tcp/sonja.math.virginia.edu:13325 before running crossfire... -kevin From crossfire-request Wed Jul 20 01:10:57 1994 Return-Path: Received: from hep.uchicago.edu (hep.uchicago.edu [128.135.102.20]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 20 Jul 1994 01:10:54 +0200 Received: by hep.uchicago.edu (920330.SGI/920502.SGI.AUTO) for crossfire@ifi.uio.no id AA00803; Tue, 19 Jul 94 18:09:00 -0500 Date: Tue, 19 Jul 94 18:09:00 -0500 From: wahl@hep.uchicago.edu (John Wahl) Message-Id: <9407192309.AA00803@hep.uchicago.edu> Apparently-To: crossfire@ifi.uio.no Status: RO Hi, This something of a test to try out the mailing list but also a question. I am trying to compile crossfire on an SGI under IRIX4.0.5... Has anyone had any success with this platform? It was not listed in the known platforms that crossfire compiles on! I can not even get passed the make depend portion....it fails on /server/socket.c and I also know that the header file systeminfo.h is missing from my system(from client/client.c). Any thoughts? John From crossfire-request Tue Jul 19 21:02:31 1994 Return-Path: Received: from soda.berkeley.edu (soda.Berkeley.EDU [128.32.149.19]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Jul 1994 21:02:28 +0200 Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by soda.berkeley.edu (8.6.9/PHILMAIL-1.10) with SMTP id MAA01136; Tue, 19 Jul 1994 12:01:44 -0700 Message-Id: <199407191901.MAA01136@soda.berkeley.edu> To: "Kevin H. Weiss" cc: crossfire@ifi.uio.no, peterm@soda.berkeley.edu Subject: How to set up and use a fontserver In-reply-to: Your message of "Tue, 19 Jul 1994 11:15:08." <9407191515.AA04127@sonja.math.Virginia.EDU> Date: Tue, 19 Jul 1994 12:01:42 -0700 From: Peter Mardahl Status: RO In message <9407191515.AA04127@sonja.math.Virginia.EDU>, "Kevin H. Weiss" write >P.S. I got myself a copy of fs. So, somebody tell me how to set up a font >server, please... Thanks! Fontservers are only useful for non-xpm graphics. Here's how to start: you figure out where the crossfire fonts you'll be using are to reside. Go to that directory and type 'mkfontdir'. Also, it is helpful to have a configuration file for the fontserver around. Here's the one at coke.csua.berkeley.edu #****************************************************** # # simple fontserver config file. # # run fs as 'fs -config [this file] & ' # catalogue = /usr1/games/crossfire/c91/lib client-limit = 10 error-file = /tmp/fs.errors port = 13325 use-syslog = 0 #******************************************** You do not need to do anything to the fontserver if you change the font, the fontserver will automatically notice the change in the font. To use the fontserver to play: > xset +fp tcp/coke.csua.berkeley.edu:13325 (for example) > telnet coke.csua.berkeley.edu 13326 set font add Regards, PeterM From crossfire-request Tue Jul 19 14:59:46 1994 Return-Path: Received: from po6.andrew.cmu.edu (PO6.ANDREW.CMU.EDU [128.2.10.106]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Jul 1994 14:59:35 +0200 Received: (from postman@localhost) by po6.andrew.cmu.edu (8.6.7/8.6.6) id IAA03771 for crossfire@ifi.uio.no; Tue, 19 Jul 1994 08:58:11 -0400 Received: via switchmail; Tue, 19 Jul 1994 08:58:08 -0400 (EDT) Received: from freehold.andrew.cmu.edu via qmail ID ; Tue, 19 Jul 1994 08:58:01 -0400 (EDT) Received: from freehold.andrew.cmu.edu via qmail ID ; Tue, 19 Jul 1994 08:57:53 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.freehold.andrew.cmu.edu.sun4m.412 via MS.5.6.freehold.andrew.cmu.edu.sun4c_411; Tue, 19 Jul 1994 08:57:53 -0400 (EDT) Message-ID: Date: Tue, 19 Jul 1994 08:57:53 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: Playing Crossfire In-Reply-To: <199407170552.AA07585@bolero.rahul.net> References: <199407170552.AA07585@bolero.rahul.net> Status: RO Mark Wedel writes: > madhatter.ws.cc.cmu.edu > port: 13326 (default) > running version: 0.90.3 > access time: 24 hours a day > max players: ?? > other info: waiting to upgrade to 0.90.6 when released This is gone; permanantly. I've graduated from CMU, and will be at Berkeley in the fall, so my machine will be moving there. -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 Jul 19 17:15:25 1994 Return-Path: Received: from virginia.edu (uvaarpa.Virginia.EDU [128.143.2.7]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Jul 1994 17:15:23 +0200 Received: from sonja.math.virginia.edu by uvaarpa.virginia.edu id aa08208; 19 Jul 94 11:15 EDT Received: by sonja.math.Virginia.EDU (NX5.67c/NX3.0S) id AA04127; Tue, 19 Jul 94 11:15:10 -0400 From: "Kevin H. Weiss" Message-Id: <9407191515.AA04127@sonja.math.Virginia.EDU> To: crossfire@ifi.uio.no Date: Tue, 19 Jul 1994 11:15:08 -36803936 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 179 Status: RO sonja.math.virginia.edu is running crossfire v0.91.2 on port 13326 -kevin P.S. I got myself a copy of fs. So, somebody tell me how to set up a font server, please... Thanks! From crossfire-request Mon Jul 18 13:12:29 1994 Return-Path: Received: from tmpil001.tmp.allied.com (tmpil001.tmp.allied.com [198.80.19.2]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Jul 1994 13:11:50 +0200 Received: from caess1 (caess1.cae.aro.allied.com) by tmpil001.tmp.allied.com with SMTP id AA15079 (InterLock SMTP Gateway 1.1 for ); Mon, 18 Jul 1994 04:06:46 -0700 Received: by caess1 (4.1/SMI-4.1-DNI-7.0.1) id AA17202; Mon, 18 Jul 94 07:05:47 EDT Date: Mon, 18 Jul 94 07:05:47 EDT From: mls@caess1.cae.aro.allied.com (Michael L. Starliper) Message-Id: <9407181105.AA17202@caess1> To: crossfire@ifi.uio.no Subject: Unique Items Problems Status: RO Hi, I have crossfire.0.91.2, on a Sparc10 running SunOS 4.1.3. Crossfire is installed in /usr/local/games/crossfire, and the heirarchy is owned by games. The crossfire executable is setuid to games. I received no error messages when I compiled. But...I have not been able to get unique items in our games. The directory is there, mode 755 owned by games, but in the log file the following message appears: Can't open unique items file /usr/local/games/crossfire/lib/unique-items/city@city.v00 where city@city.v00 is any of the maps. The lock files are also not in that directory (when I check during a running game). Can you offer any advice? ----------------- Michael Starliper From crossfire-request Sun Jul 17 19:27:59 1994 Return-Path: Received: from soda.berkeley.edu (soda.Berkeley.EDU [128.32.149.19]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sun, 17 Jul 1994 19:27:56 +0200 Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by soda.berkeley.edu (8.6.9/PHILMAIL-1.10) with SMTP id KAA01318; Sun, 17 Jul 1994 10:27:41 -0700 Message-Id: <199407171727.KAA01318@soda.berkeley.edu> To: Mark Wedel cc: crossfire@ifi.uio.no Subject: Coke.csua.berkeley.edu 13326, not scotch In-reply-to: Your message of "Sat, 16 Jul 1994 22:52:39 PDT." <199407170552.AA07585@bolero.rahul.net> Date: Sun, 17 Jul 1994 10:27:39 -0700 From: Peter Mardahl Status: RO > >scotch.berkeley.edu > port: 13326 (default) > running version: 0.90.5 > access time: 24 hours a day > max players: no restriction, but more than 4 is slow > other info: X11R5 fontserver available on port 13325 This server is now coke.csua.berkeley.edu port: 13326 (default) running version: very latest with experimental mods thrown in access time: 24 hours a day max players: no restriction, but more than 4 is slow other info: X11R5 fontserver available on port 13325 non-local players please download the fonts using fstobdf Regards, PeterM From crossfire-request Sun Jul 17 07:52:54 1994 Return-Path: Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sun, 17 Jul 1994 07:52:50 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA09951 (5.67a8/IDA-1.5 for ); Sat, 16 Jul 1994 22:52:39 -0700 Received: by bolero.rahul.net id AA07585 (5.67a8/IDA-1.5); Sat, 16 Jul 1994 22:52:39 -0700 Date: Sat, 16 Jul 1994 22:52:39 -0700 From: Mark Wedel Message-Id: <199407170552.AA07585@bolero.rahul.net> To: crossfire@ifi.uio.no, snead@cs.ucf.edu Subject: Re: Playing Crossfire Status: RO You don't need the server to play - in fact, someone just gave directions a few days ago how to use telent to start up a session. Here is a list of servers that I have (probably out of date) Here is an up-to-date list of crossfire servers that you can connect to and join in the play! sonja.math.virginia.edu port: 13326 (default) running version: 0.90.5 access time: 24 hours a day max players: unlimited in theory other info: running on a NeXT with 20MB of RAM corpse.ecst.csuchico.edu port: 13326 (default) running version: 0.90.5 access time: 24 hours a day max players: no restriction, known to perform well with more than 8 other info: scotch.berkeley.edu port: 13326 (default) running version: 0.90.5 access time: 24 hours a day max players: no restriction, but more than 4 is slow other info: X11R5 fontserver available on port 13325 madhatter.ws.cc.cmu.edu port: 13326 (default) running version: 0.90.3 access time: 24 hours a day max players: ?? other info: waiting to upgrade to 0.90.6 when released fermat.dartmouth.edu port: 13326 (default) running version: 0.90.5 access time: 24 hours a day max players: ?? other info: ?? --Mark From crossfire-request Sat Jul 16 23:52:41 1994 Return-Path: Received: from longwood.cs.ucf.edu (longwood.cs.ucf.edu [132.170.108.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 16 Jul 1994 23:52:38 +0200 Received: by longwood.cs.ucf.edu id AA15414 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Sat, 16 Jul 1994 17:52:32 -0400 Date: Sat, 16 Jul 1994 17:52:32 -0400 From: "Aphrodite (Deborah L. Snead)" Message-Id: <199407162152.AA15414@longwood.cs.ucf.edu> To: crossfire@ifi.uio.no Subject: Playing Crossfire Status: RO I would like to play Crossfire. Is there a list of sites where I can play it and where I can get the client program? Thanx. From owner-crossfire Fri Jul 15 07:40:00 1994 Return-Path: Received: from aino.it.lut.fi (sonninen@aino.it.lut.fi [157.24.11.71]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Jul 1994 07:39:59 +0200 Received: from localhost (sonninen@localhost) by aino.it.lut.fi (8.6.5/8.6.5/1.12.kim) id IAA25387; Fri, 15 Jul 1994 08:39:52 +0300 Date: Fri, 15 Jul 1994 08:39:52 +0300 From: Jarkko Sonninen Message-Id: <199407150539.IAA25387@aino.it.lut.fi> To: crossfire-bugs@ifi.uio.no Subject: Re: CrossEdit In-Reply-To: <199407150138.SAA08949@soda.berkeley.edu> References: <199407150138.SAA08949@soda.berkeley.edu> Status: RO Jeffrey Whitehead writes: > The text box in crossedit cuts off the last character... I'm talking about > the attributes box where the text for magic mouthes and such is stored. > > Thought you'd might like to know. well, we do. The last character is automagically changed to linefeed, since there have to be a linefeed in the end of message, otherwise the 'endmsg' will be written just after text and not to line of its own. It could be smarter, and if someone urges to fix it, it can be found from crossedit/Attr.c:980 - Jarkko From owner-crossfire Fri Jul 15 03:38:58 1994 Return-Path: Received: from soda.berkeley.edu (soda.Berkeley.EDU [128.32.149.19]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Jul 1994 03:38:56 +0200 Received: (jeph@localhost) by soda.berkeley.edu (8.6.9/PHILMAIL-1.10) id SAA08949 for crossfire-bugs@ifi.uio.no; Thu, 14 Jul 1994 18:38:51 -0700 Date: Thu, 14 Jul 1994 18:38:51 -0700 From: Jeffrey Whitehead Message-Id: <199407150138.SAA08949@soda.berkeley.edu> To: crossfire-bugs@ifi.uio.no Subject: CrossEdit Status: RO Howdy -- I recently got involved with crossfire, and have found a bug. The text box in crossedit cuts off the last character... I'm talking about the attributes box where the text for magic mouthes and such is stored. Thought you'd might like to know. From crossfire-request Fri Jul 15 00:17:09 1994 Return-Path: Received: from soda.berkeley.edu (soda.Berkeley.EDU [128.32.149.19]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Jul 1994 00:17:07 +0200 Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by soda.berkeley.edu (8.6.9/PHILMAIL-1.10) with SMTP id PAA18936; Thu, 14 Jul 1994 15:16:58 -0700 Message-Id: <199407142216.PAA18936@soda.berkeley.edu> To: jbaker@sirius.uvic.ca (Krenn) cc: crossfire@ifi.uio.no (crossfire) Subject: Re: New user questions In-reply-to: Your message of "Thu, 14 Jul 1994 14:20:06 PDT." <9407142120.AA08341@sirius.UVic.CA> Date: Thu, 14 Jul 1994 15:16:56 -0700 From: Peter Mardahl Status: RO In message <9407142120.AA08341@sirius.UVic.CA>, Krenn writes: >with here - all we want is the client, we don't need a local server. If all you want is the client, and no server, you don't need any files at all. Here's an example: alfven [21] xhost coke.csua.berkeley.edu alfven [22] telnet coke.csua.berkeley.edu 13326 Trying 128.32.131.73 ... Connected to coke.csua.Berkeley.EDU. Escape character is '^]'. set font OK. add alfven.eecs.berkeley.edu OK. quit This will send a window over from the server machine to yours. You need nothing whatsoever other than an X display, and a server machine. Please don't play at coke.csua unless your net connection is pretty good. If you DO play at coke.csua, you might find it helpful to: download the fonts from coke.csua.berkeley.edu port 13325 by using fstobdf then sticking the crossfire.bdf file you should get into /tmp then cd /tmp mkfontdir xset +fp /tmp telnet .... set font add Regards, PeterM From crossfire-request Thu Jul 14 23:20:21 1994 Return-Path: Received: from sol.UVic.CA (sol.UVic.CA [142.104.1.4]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Jul 1994 23:20:18 +0200 Received: from sirius.UVic.CA by sol.UVic.CA (4.1/SMI-4.1.3-UVic-2.58MX) id AA23207; Thu, 14 Jul 94 14:21:12 PDT Received: from uglx.UVic.CA by sirius.UVic.CA (4.1/SMI-4.1-Engr.UVic.CA-H) id AA08341; Thu, 14 Jul 94 14:20:08 PDT From: jbaker@sirius.uvic.ca (Krenn) Message-Id: <9407142120.AA08341@sirius.UVic.CA> Subject: New user questions To: crossfire@ifi.uio.no (crossfire) Date: Thu, 14 Jul 1994 14:20:06 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1199 Status: RO -----BEGIN PGP SIGNED MESSAGE----- If you don't like seeing novice questions (this is file related, not game play related) delete this message now :-> Basically, I'm trying to figure out the smallest setup we can get away with here - all we want is the client, we don't need a local server. I checked the files that came with the source (may want to make separate client and server packages) and couldn't find any mention of what uses what, and I don't really want to start randomly deleting files. Thanks in advance, Jason - -- Vlad_K-Fuchida - BT3056 MUSE, 321st ComGuard Grenadiers | PGP Public MagLev - Shadowrun MUSH, Constructor | key available Silver Samurai - UVic Oggsquad (Summer INL Team) | via finger Krenn - Shire of Ramsgaard, Kingdom of An Tir, SCA | and keyservers GE: d- -p+ c++++ l u+ e+ m---(++) s++/ n h* f+ g+ w+ t++ r++ y? -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLiWrjT6wJThtp3DpAQFvOgP/W6M3UazmcMd6Lrn6HI5uecliSbT4HOL6 DbswWO9cthO+iFeNI4jYoAh8d2GWKPd1MbirTgsKL/LzkBjHkY0dPBU5KXyBztoB QGd4NoZCWYtcRHlmlwAuHSea81zhpOsY3RyKjk6c8TvBwglOvVoMyPBXCMbxtr4/ AGS9n5KLi/0= =K/rO -----END PGP SIGNATURE----- From crossfire-request Thu Jul 14 07:19:28 1994 Return-Path: Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Jul 1994 07:19:26 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA28261 (5.67a8/IDA-1.5 for ); Wed, 13 Jul 1994 22:19:19 -0700 Received: by bolero.rahul.net id AA21667 (5.67a8/IDA-1.5); Wed, 13 Jul 1994 22:19:18 -0700 Date: Wed, 13 Jul 1994 22:19:18 -0700 From: Mark Wedel Message-Id: <199407140519.AA21667@bolero.rahul.net> To: crossfire@ifi.uio.no, smurf@soda.berkeley.edu Subject: Re: Client/server protocol Status: RO >C->S: MOVE 123 44 45 >A request by the client to move the player (object 123) south (from >44 to 45). Remember, that the maps make 0,0 as the upper left corner, >not lower left as in standard geometry. This should be move object 123 to 44 (x), 45 (y). All map locations are in x y coordinate form, and not some form that is embeded in one number. As protocol definition, all X Y coordinate values are in that order, X first, then Y. As for removing X support in the server, this can also be done at some time via a configure option. People on a very fast network with a very fast server machine may not really care about client/server. The main benefits of client server is a little reduced load for the server, ability to play over slower links, and be able to have different client interfaces. On the last one, a good idea for the client would be to write a skeleton client that parses the protocol data (as well as init the link), store the data in the appropriate structures, but just pseudo code all the actul window calls. In this way, anyone that wants to develope a client with a different toolkit (Xaw, xview, motif) or system just needs to write the appropriate areas, and not start from scratch or make serious modifications to a version with the window calls already in palce. --Mark From crossfire-request Wed Jul 13 13:53:57 1994 Return-Path: Received: from soda.berkeley.edu (soda.Berkeley.EDU [128.32.149.19]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 13 Jul 1994 13:53:53 +0200 Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by soda.berkeley.edu (8.6.9/PHILMAIL-1.10) with SMTP id RAA09250 for ; Tue, 12 Jul 1994 17:46:09 -0700 Message-Id: <199407130046.RAA09250@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: Re: Client/server protocol In-reply-to: Your message of "Fri, 08 Jul 1994 01:02:28 PDT." <199407080802.AA29978@bolero.rahul.net> Date: Tue, 12 Jul 1994 17:46:07 -0700 From: Scott MacFiggen Status: RO In message <199407080802.AA29978@bolero.rahul.net>you write: >The client server discussion seems to have pretty much died. Since it needs >to be done, I thought I would start working on the protocol. This is mostly >Carl Edman's protocol, with some clarifications and implementation thoughts >tossed in. Some of the thoughts were gleaned from the old mail log. > >The original proposal will have > pretended to the lines. Clarifications >will also be in this area. The document has also be re-organized >to some extent. > >C->S: MOVE 123 44 45 >A request by the client to move the player (object 123) south (from >44 to 45). Remember, that the maps make 0,0 as the upper left corner, >not lower left as in standard geometry. Are you sure you worded that right? Do you mean the client tells the server to move object 123 to location (44,45) or from location 44 to location 45. What you said doesn't sense. >S->C: ITEM 123 44 45 >Telling the client that object 123 is now at 44,45. IT does not >need to send full data, since this object never left LOS. > <<<< STUFF DELETED >>>>> > > IF anyone has good ideas on how to handle this area, I would >be interested. I don't really like either of those ideas although I will have to think about it more before I can come up with something better. >Back to the player moving (S->C: ITEM 123 44 45): > >When the client receives this, it should scroll the map up one. >It now sends a map command to fill the new bottom row up: >S->C: MAP 40 50 wall 41 50 wall 42 50 wall ... Maybe you didn't make a mistake above. How does the client know the server is talking about y coordinates and not x coordinates or vice-versa? >Various thoughts are welcome. I am really worried about finding a good >way to implement the MAP and ITEM commands in an efficient manner. > >Mark Wedel >master@rahul.net I have sorta kinda agreed to do the client/server split however I can't start on it right away (soda is moving and is taking all my time). Here is what I sort of had envisioned for the client server. Take all the display code out of the server and put it into a "module". There is no reason for the server to be making X calls. I looked around the code a bit a month ago or so and didn't see all that much X stuff that wasn't already grouped in xio.c. The player struct will have to be cleansed and player.c but I think everything else is ok. Next, put in all the networking code. Since the X code is still there, people could still play by telneting but could also play using the client. I have no problem doing this part. Mehlhaff has a nice network library that will do the job. Did we ever decide if the client/server was going to be TCP only? I was thinking more along the lines of netrek which uses UDP but you can switch to TCP only if you want. Once the client/server is working and well tested, take the X code out of the server. This can be done at someone's convenience although it should be done before the net release. Mehlhaff also had a good idea about making up a player abstraction but I forgot what that was all about, I will ask him what his idea was when I get a chance. ############################################################################## # Scott MacFiggen -- 88 VTR250 -- EUVE Systems Administrator -- CEA # # # # smurf@soda.berkeley.edu CSUA Vice-President scottmm@cea.berkeley.edu # ############################################################################## From crossfire-request Mon Jul 11 17:16:32 1994 Return-Path: Received: from cc.lut.fi (hevi@cc.lut.fi [157.24.10.16]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 11 Jul 1994 17:16:28 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id SAA26913; Mon, 11 Jul 1994 18:16:13 +0300 Date: Mon, 11 Jul 1994 18:16:13 +0300 (EETDST) From: "Petri.Heinila" Subject: Re: compiling crossfire using acc To: eenmct@sun.leeds.ac.uk cc: crossfire@ifi.uio.no In-Reply-To: <13183.9407111027@eensun16.leeds.ac.uk.sun.leeds.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 11 Jul 1994 eenmct@sun.leeds.ac.uk wrote: > Hi, > I've been trying to compile crossfire-0.91.2 on my Sun (4.1.1) under OpenWindows and I've had a few problems > > It will not compile using gcc or gcc2, so I'm now trying acc. > This seems to compile OK up until crossedit/Cnv/test.c where it crashes. The > error message is that it cannot find the header files: > Panner.h, Repeater.h, Porthole.h, Tree.h in the X11/Xaw/ directory, > and the include path is pointing the /usr/include. These headers are > included through the header file crossedit/Cnv/include/Xaw.h. I have > checked my include files (in /usr/include and /usr/openwin/include/ ) > and cannot find a copy of these header files. Checkout the version on your openwin and X11 in it, the crossedit es made against X11R5. The files may be missing in earlier versions of X11. The test.c is only for test purposes (suprise :), not really needed. I write below a new Imakefile (not tested) for that dir, try apply it. > Are these files in a wierd place, or can I remove the #includes in > crossedit/Cnv/include/Xaw.h, or can someone send me a copy of the files. The Xaw.h is for convience to get the all Athena Widget Set header files, the romoving in #includes is not recommended. > Also, do I really need to use -Xc in the compile options for acc, as > the number of warning messages due to this is very large!! crossedit/Cnv/Imakefile: ---8<--- #include "../../config/crossfire.tmpl" /*** files ***/ SRCS = test.c CnvUtil.c CnvBrowse.c CnvNotify.c \ CnvMenu.c CnvFiles.c CnvPath.c CnvPrompt.c OBJS = CnvUtil.o CnvBrowse.o CnvNotify.o CnvMenu.o \ CnvFiles.o CnvPath.o CnvPrompt.o HDRS = Cnv.h config.h FILES = excloff.xbm exclon.xbm flagoff.xbm flagon.xbm \ notify.xbm prompt.xbm submenu.xbm Imakefile \ README /*** options ***/ INCLUDES = -I. -I../include -I../../include LOCAL_LIBRARIES = XawClientLibs $(DLSYM) NormalLibraryTarget(Cnv,$(OBJS)) DependTarget() /* these are just for testing */ NormalProgramTarget(test ,test.o $(OBJS) $(DLSYM),libCnv.a,XawClientLibs,/**/) NormalProgramTarget(menu2 ,menu2.o $(OBJS),libCnv.a,XawClientLibs,/**/) InsertArchive($(SRCS) $(HDRS) $(FILES),crossedit/Cnv) /*** end of Imakefile ***/ ---8<--- -- The Page -- From crossfire-request Mon Jul 11 14:40:21 1994 Return-Path: Received: from surt.ifi.uio.no (1232@surt.ifi.uio.no [129.240.76.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id ; Mon, 11 Jul 1994 14:40:21 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by surt.ifi.uio.no ; Mon, 11 Jul 1994 14:40:20 +0200 Date: Mon, 11 Jul 1994 14:40:20 +0200 Message-Id: <199407111240.9114.surt.ifi.uio.no@ifi.uio.no> To: master@rahul.net CC: crossfire@ifi.uio.no In-reply-to: Mark Wedel's message of Fri, 8 Jul 1994 20:13:09 -0700 <199407090313.AA17610@bolero.rahul.net> Subject: Re: compiling error (bug in apply.c) Status: RO +--- Mark Wedel: | It is a bug in the code. treasure is also a structure name. | | Apparantly, gcc gives precendence the the object *treasure, where | as your compiler gives precedence to the structure. Actually, this is one of the difference between C and C++. In C, the two name spaces are separate, so the code isn't actually buggy. Not that it matters much anyway -- you'll probably want to write portable code (which also entails no more "char *new"). Kjetil T. From crossfire-request Mon Jul 11 12:28:16 1994 Return-Path: <<@gps1.leeds.ac.uk:eenmct@sun.leeds.ac.uk>> Received: from pat.uio.no (pat.uio.no [129.240.2.50]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 11 Jul 1994 12:28:15 +0200 X400-Received: by mta pat.uio.no in /PRMD=uninett/ADMD= /C=no/; Relayed; Mon, 11 Jul 1994 12:27:54 +0200 X400-Received: by /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Mon, 11 Jul 1994 12:27:14 +0200 X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Mon, 11 Jul 1994 12:27:15 +0200 X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Mon, 11 Jul 1994 12:27:14 +0200 X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Mon, 11 Jul 1994 12:27:13 +0200 Date: Mon, 11 Jul 1994 12:27:13 +0200 X400-Originator: eenmct <@gps1.leeds.ac.uk:eenmct@sun.leeds.ac.uk> X400-Recipients: crossfire@ifi.uio.no X400-MTS-Identifier: [/PRMD=uk.ac/ADMD= /C=gb/;<13183.9407111027@eensun16.leeds] X400-Content-Type: P2-1984 (2) Content-Identifier: compiling cro... From: eenmct@sun.leeds.ac.uk Message-ID: <13183.9407111027@eensun16.leeds.ac.uk.sun.leeds.ac.uk> To: crossfire@ifi.uio.no Subject: compiling crossfire using acc Status: RO Hi, I've been trying to compile crossfire-0.91.2 on my Sun (4.1.1) under OpenWindows and I've had a few problems It will not compile using gcc or gcc2, so I'm now trying acc. This seems to compile OK up until crossedit/Cnv/test.c where it crashes. The error message is that it cannot find the header files: Panner.h, Repeater.h, Porthole.h, Tree.h in the X11/Xaw/ directory, and the include path is pointing the /usr/include. These headers are included through the header file crossedit/Cnv/include/Xaw.h. I have checked my include files (in /usr/include and /usr/openwin/include/ ) and cannot find a copy of these header files. Help! Are these files in a wierd place, or can I remove the #includes in crossedit/Cnv/include/Xaw.h, or can someone send me a copy of the files. Also, do I really need to use -Xc in the compile options for acc, as the number of warning messages due to this is very large!! Any help would be greatfully received. -Mark eenmct@leeds.ac.uk From crossfire-request Sat Jul 9 05:13:29 1994 Return-Path: Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 9 Jul 1994 05:13:27 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA22634 (5.67a8/IDA-1.5 for ); Fri, 8 Jul 1994 20:13:09 -0700 Received: by bolero.rahul.net id AA17610 (5.67a8/IDA-1.5); Fri, 8 Jul 1994 20:13:09 -0700 Date: Fri, 8 Jul 1994 20:13:09 -0700 From: Mark Wedel Message-Id: <199407090313.AA17610@bolero.rahul.net> To: crossfire@ifi.uio.no, khw2x@sonja.math.virginia.edu Subject: Re: compiling error (bug in apply.c) Status: RO It is a bug in the code. treasure is also a structure name. Apparantly, gcc gives precendence the the object *treasure, where as your compiler gives precedence to the structure. Here is a patch: *** 1.37 1994/07/04 08:21:13 --- apply.c 1994/07/09 03:07:59 *************** *** 912,918 **** return apply_container (op, tmp); case TREASURE: { ! object *treasure; if(QUERY_FLAG(tmp, FLAG_UNPAID)) { draw_info(op,"You should pay for it first."); break; --- 912,918 ---- return apply_container (op, tmp); case TREASURE: { ! object *treas; if(QUERY_FLAG(tmp, FLAG_UNPAID)) { draw_info(op,"You should pay for it first."); break; *************** *** 923,944 **** prevents people fromt moving chests to more difficult maps to get better treasure */ ! treasure = tmp->inv; ! if(treasure==NULL) { draw_info(op,"The chest was empty."); decrease_ob(tmp); return 1; } do { ! remove_ob(treasure); ! draw_find(op,treasure); ! treasure->x=op->x,treasure->y=op->y; /* Changed (0.91.2) - always drop treasure to floor (needed for * trap code */ ! insert_ob_in_map(treasure,op->map); ! } while ((treasure=tmp->inv)!=NULL); decrease_ob(tmp); /* Done to re-stack map with player on top? */ --- 923,944 ---- prevents people fromt moving chests to more difficult maps to get better treasure */ ! treas = tmp->inv; ! if(treas==NULL) { draw_info(op,"The chest was empty."); decrease_ob(tmp); return 1; } do { ! remove_ob(treas); ! draw_find(op,treas); ! treas->x=op->x,treas->y=op->y; /* Changed (0.91.2) - always drop treasure to floor (needed for * trap code */ ! insert_ob_in_map(treas,op->map); ! } while ((treas=tmp->inv)!=NULL); decrease_ob(tmp); /* Done to re-stack map with player on top? */ You will probably need to use patch -l on this. --Mark From crossfire-request Sat Jul 9 02:26:48 1994 Return-Path: Received: from virginia.edu (uvaarpa.Virginia.EDU [128.143.2.7]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 9 Jul 1994 02:26:48 +0200 Received: from sonja.math.virginia.edu by uvaarpa.virginia.edu id aa14010; 8 Jul 94 20:26 EDT Received: by sonja.math.Virginia.EDU (NX5.67c/NX3.0S) id AA03047; Fri, 8 Jul 94 20:26:49 -0400 Date: Fri, 8 Jul 94 20:26:49 -0400 From: "Kevin H. Weiss" Message-Id: <9407090026.AA03047@sonja.math.Virginia.EDU> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: crossfire@ifi.uio.no Subject: compiling error (bug in apply.c) Status: RO What needs to be fixed here? The error I get is: apply.c:941: illegal cast, missing `)' after `treasure' apply.c:941: illegal statement, missing `;' after `)' Everything else seems to compile okay... -kevin P.S. I really should sit down and learn C. P.P.S. I really should sit down and type up my dissertation... From crossfire-request Fri Jul 8 23:39:54 1994 Return-Path: Received: from soda.berkeley.edu (soda.Berkeley.EDU [128.32.149.19]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 8 Jul 1994 23:39:48 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.9/PHILMAIL-1.10) id OAA00343; Fri, 8 Jul 1994 14:39:37 -0700 From: Philip Brown Message-Id: <199407082139.OAA00343@soda.berkeley.edu> Subject: Re: Compiling crossfire-0.91.2 To: btk@aber.ac.uk (Benjamin Thomas Ketteridge) Date: Fri, 8 Jul 1994 14:39:36 -0700 (PDT) Cc: crossfire@ifi.uio.no In-Reply-To: <10805.773665455@mailhost.aber.ac.uk> from "Benjamin Thomas Ketteridge" at Jul 8, 94 12:04:15 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 853 Status: RO >>>>[From Benjamin Thomas Ketteridge] OK further info: I can fix earlier problems which arise (minor things) but this one has me stumped!: ---- Begin imported script ---- saturn:server:Ready:make gcc -DSYSV -DSVR4 -xF -Wa,-cg92 -I../include -I/usr/openwin/include -DSVR4 -DSYSV -DLONGJUMP -DXpm_Pix -DFONTDIR=\"/home/student/postgrad/part_a/btk/usr/lib/crossfire/fonts\" -DFONTNAME=\"crossfire\" -DLIBDIR=\"/home/student/postgrad/part_a/btk/ usr/lib/crossfire/lib\" -DCOMPRESS=\"/usr/local/gnu/bin/gzip\" -DUNCOMPRESS=\"/usr/local/gnu/bin/gunzip\" -DCOMPRESS_SUFFIX=\".gz\" -c socket.c gcc: language F not recognized That's an easy one. That nasty script, "-xF -Wa,-cg92", is because it expects the SunPro compiler. You need to #define HasGcc2 YES in site.def, before it includes anything else. From owner-crossfire Thu Jul 7 10:00:50 1994 Return-Path: Received: from gymir.ifi.uio.no (2037@gymir.ifi.uio.no [129.240.80.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 7 Jul 1994 10:00:50 +0200 Received: (from frankj@localhost) by gymir.ifi.uio.no ; Thu, 7 Jul 1994 10:00:48 +0200 Message-Id: <199407070800.27497.gymir.ifi.uio.no@ifi.uio.no> Subject: Crossfire 0.91.2 is released. To: crossfire-announce@ifi.uio.no Date: Thu, 7 Jul 1994 10:00:48 +0200 (MET DST) From: Mark Wedel X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1654 Status: RO There are three separate tar archives in the Crossfire 0.91.2 distribution: sums (bsd) filename 56290 623 crossfire-0.91.1-0.91.2.diff.gz 4354 593 crossfire-0.91.2.arch.tar.gz 16580 1146 crossfire-0.91.2.maps-alpha.tar.gz 18554 1096 crossfire-0.91.2.tar.gz crossfire-0.91.2.tar.gz contains the actual program code, as well as premade archetype, bitmaps, and xpm files. See the CHANGES file in this archive for everything that has changed. crossfire-0.91.2-maps-alpha.tar.gz contains all the maps. I mark this as alpha because many of the new maps I have put in have not been well tested (or at all). I do not recommend that sites running server with multiple players use this file. However, map developers or those who play solo may want to get it. crossfire-0.91.2-arch.tar.gz contains the unpacked archetype (arch) directory. This file is not needed if you just want to compile the games and play. The contents of this archive is used to create the archetypes, bmaps, font, and X PixMap (XPM) files. You only need it if you want to add new archetypes, or mess around with the existing ones. crossfier-0.91.1-0.91.2.patch.gz is a compressed patch file. It patches all files that are in the core distribution. AVAILABILITY: Crossfire is avaible on the following ftp sites ftp.ifi.uio.no:/pub/crossfire (129.240.82.2) ftp.world.net:/pub/crossfire (192.243.32.18) yoyo.cc.monash.edu.au:/pub/crossfire (130.194.9.1) ftp.cs.city.ac.uk:/pub/games/crossfire/ Note: there may be a short delay before the ftp.world.net, ftp.cs.city.ac.uk yoyo.cc.monash.edu.au sites get the newest version. Mark Wedel master@rahul.net