From crossfire-request Fri Apr 15 23:55: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, 15 Apr 1994 23:55:51 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id OAA14325 for crossfire@ifi.uio.no; Fri, 15 Apr 1994 14:55:48 -0700 From: Philip Brown Message-Id: <199404152155.OAA14325@soda.berkeley.edu> Subject: Re: cheating & LOS To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Fri, 15 Apr 1994 14:55:46 -0700 (PDT) In-Reply-To: <9404151732.AA09642@capitalist.princeton.edu> from "Carl Edman" at Apr 15, 94 01:32:07 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1657 Status: RO >>>>[From Carl Edman] The client/server protocol does not have "rounds". Yes it does. See below Yes, the server has to keep LOS maps, both for computational efficiency and for the sake of the protocol. Whenever an item moves or changes, the server goes through the list of the LOS maps for all players and immediately sends ITEM commands to all the players for whom the item is in the LOS. Absolutely positively not. The protocol itself does not have an explicit notion of rounds, but that's because it's underlying purpose is to best handle rounds. The whole model for crossfire REQUIRES syncroynous rounds, across player/monster movement. At each round, the server goes through each player's 11x11 map, and sends everything relevant. A player move takes (usually) one or more number of rounds. But so does standing still for some amount of time. The only reason the protocol has support for partial uploading of a 11x11 map to a client, is simply because it's more efficient that way, not because we want asynchronous updates. When a player moves (or an item with effect on LOS is destroyed or created inside the players LOS) a new LOS map is created for the player. Then the server compares the old and the new LOS maps and sends a single MAP command for all the squares in the new LOS and not in the old and a single UNMAP for all the squares in the old LOS but not in the new. Then the old LOS map is discarded. True enough. That is the entire display code in a nutshell. There are no "updates". There are no "rounds". Everything happens instantly. Not true. From crossfire-request Fri Apr 15 22:50:18 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, 15 Apr 1994 22:50:06 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA29909 (5.67a8/IDA-1.5 for ); Fri, 15 Apr 1994 13:49:59 -0700 Received: by bolero.rahul.net id AA00607 (5.67a8/IDA-1.5); Fri, 15 Apr 1994 13:49:58 -0700 Date: Fri, 15 Apr 1994 13:49:58 -0700 From: Mark Wedel Message-Id: <199404152049.AA00607@bolero.rahul.net> To: Petri.Heinila@lut.fi, crossfire@ifi.uio.no Subject: Re: Binary standards for images and sounds Status: RO XPM images: Converting the color names to RGB values would be the only challenging part of the interperter, and even that would not be difficult. The only difficult part is having the client know that the RGB values for a color are (since, if it is not running X, probably does not have an rgb.txt database). There are at least a couple solutions to this problem: 1) Have the server convert the color names to RGB values (probably not good for those systems that can do color lookup) 2) HAve the client have a file (or internally) of the colors that the XPM images use. Have a mechanism for the client to request RGB information on a color that it does not know about (so if new colors get added to the XPM images, the client can get RGB values for them). The client then could probably store this information, so it only needs to be requested once for each color. This method also has the advantage the unix clients that have access to an rgb.txt file, but happen to be missing a color can request the color. This could be added to the protocol as something like COLOR (name) (client->server request for RGB values for color name) COLOR (name) (rgb values) (server->client filling the information) This assumes that the server has access to a color file. I don't think that this is a very big assumption. The entire rgb.txt file is around 16K, and in worse case, a person running a server without X installed could just grab this file off some site. I think my real point about XPM images is that they will not really be any more difficult to convert to client display format than any other method. We could use ppm, but then the ppm has to be converted, and so on. Also, most 'standard' formats don't have masking, or at least I don't think they do. So, in quick summary, XPM conversion on the client server should be quite easy to do, as long as the client can get the RGB color values for some color. --Mark From crossfire-request Fri Apr 15 21:33:33 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 Apr 1994 21:33:30 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id MAA27125 for crossfire@ifi.uio.no; Fri, 15 Apr 1994 12:33:24 -0700 Date: Fri, 15 Apr 1994 12:33:24 -0700 From: Peter Mardahl Message-Id: <199404151933.MAA27125@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: crossedit whines Status: RO Crossedit is dangerous to use right now! I was using the program, and unexpectedly, stacking actually *means* something. If stacking is zero, it will remove all but the top object on a map, it seems. I've seen exits disappear. It seems that it doesn't actually delete things that are out of view, but it's very disconcerting for the map designer. Regards, PeterM From crossfire-request Fri Apr 15 20:33:58 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 20:33:52 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA19884; Fri, 15 Apr 94 14:33:45 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA09733; Fri, 15 Apr 94 14:29:58 -0400 Date: Fri, 15 Apr 94 14:29:58 -0400 From: "Carl Edman" Message-Id: <9404151829.AA09733@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Example of the use of the proposed protocol Reply-To: cedman@Princeton.EDU Status: RO From: Jason Fosback > "Carl Edman" : > > The server does not tell the client what to draw when and where. > > It tells the client what it sees. Where it sees nothing because > > it is behind walls, it does not send map commands. The client > > knows for what areas it has received map commands and it only > > displays those. Those areas which are not mapped in, it can > > display whatever it wants and it doesn't need any instructions > > for it. > > Okay, so the server gives the client exactly what it sees. Hmmm. > So, does the client do an automatic SHIFT of the map? Let's forget > LOS for the moment, and focus on what you're proposing. In a > large, open area (such as Scorn), would you be transmitting the MAP > command for all squares, or does the client do this implicit SHIFT? > Okay, so now when we head north from the starting area toward the > wall, the top area of the sreen in not visible; when the client > does the implicit SHIFT, does it automatically assume the new area is > *outside* the LOS, consequently leaving the area black? OK, let me describe this particular example in a little more detail. [ Carl wants to play crossfire so he fires up his NeXTstep crossfire client ] [ The client automatically logs him in ] Client->Server: LOGIN NEXTSTEP-CLIENT Carl Carlssupersecretpassword [ The server checks the password and it matches, then it puts carl on the map. It turns out that the tag of the item which represents Carls character on the server is 123. The server also sets Carls LOS set (more on that later) to the empty set. ] Server->Client: VIEW 123 [ The client sees and remembers this number from now until the next VIEW command which probably will not be in this session ] [ The server calculates a new LOS set i.e. the set of all map squares which are in the LOS of Carl. Then it compares that new set with the old set. It sends one MAP command for all the squares in the new set which weren't in the old set. As the old LOS set was empty that first map is pretty big. ] S->C: MAP 40 40 floor 41 40 wall 42 40 wall ... [ Now the server checks if there are any squares in the old LOS set which aren't in the new. There aren't any so it needn't send any UNMAP command ] [ Next the server sends an ITEM command for every item inside the new LOS set which is not inside the old (but as in the beginning the old LOS set is empty), it sends a list of all visible items ] S->C: ITEM 123 44 44 1 Carlsimage Carl ^ ^ ^ ^ ^ ^ Itemtag ---| | | | | | X coordinate ---| | | | | Y coordinate ------| | | | Quantity ------------| | | Name of image ----------| | Name of item ----------------------| [ In particular the client also receives an ITEM command for the viewpoint item (see above). Now the client knows where the player is and uses the MAP information above to draw the background map around the player ] S->C: ITEM 433 IN 123 1 helmetimage X ray Helmet (worn) [ The client also receives the list of items inside other open items. This includes items inside the viewpoint item i.e. the players inventory. That last command indicates that the player carries an helmet of X ray vision (worn). The client can use this information to draw the inventory window ] S->C: ITEM ... .... [ More item commands for what else is in view ] [ Now assume the player wants to move north by a step ] C->S: MOVE 123 44 45 [ That is just a request by the client. It does not change the display at all ] [ The server receives the request, decides that the client can move north (i.e. no wall, not overburdened) ] S->C: ITEM 123 44 45 [ Note that the server doesn't have to send all the item data. Only the first three fields are mandatory. The rest need only be sent for items which enter the field of view or which change ] [ When the client receives this description, likely it will shift the entire view which may create a black row on top and may shift the bottom view out of the image (or it may not if the client is an automapping client) ] [ As soon as the server processed the MOVE command, it also noticed that the LOS may have changed. So it calculates a new LOS set. It compares it with the old LOS set (which this time around is pretty big). If there are any new squares in the new LOS which weren't in the old it will send a single MAP command for all of them. That will be pretty small. The maximum average is 11 (with a 5 square range of view). If there is any obscuration, it will be less.] S->C: MAP 40 50 wall 41 50 wall 42 50 wall ... [ As the client receives these commands it updates that black strip on top of the screen which it may have. ] [ Now the same for the squares in the old set which aren't in the new. Again this will be pretty small ] S->C: UNMAP 40 40 41 40 ... [ Finally when the server changes the LOS set it checks whether there are any visible items in the new set which weren't in the old (no reason to worry about disappearing items -- UNMAP is all the information client needs on those). There may be a small number of ITEM commands. ] S->C: ITEM 642 45 50 1 orcimage Orc chieftain ... [ The client displays those items as it receives information about them. ] [ Now assume that orc chieftain wants to attack the player. It moves towards the player ] S->C: ITEM 642 45 49 [ Later ] S->C: ITEM 642 45 48 [ Later ] S->C: ITEM 642 45 47 [ That's all. No maps or unmaps or long items for monster movement. Just a single short command every time it happens, That command is generated by the same routine which makes the Orc itself move. Zilch overhead. ] [ At some later time after the player has dealt with the Orc. The player wants to drop the helmet. The player is still in square (44/45). ] C->S: MOVE 433 44 45 [ When the server process all that returns is: ] S->C: ITEM 433 44 45 I hope it is now clearer what the server/client sent when under the proposed protocol. Carl Edman From crossfire-request Fri Apr 15 18:44:15 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 Apr 1994 18:44:14 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id JAA05316 for crossfire@ifi.uio.no; Fri, 15 Apr 1994 09:44:05 -0700 From: Philip Brown Message-Id: <199404151644.JAA05316@soda.berkeley.edu> Subject: Re: Binary standards for images and sounds To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Fri, 15 Apr 1994 09:44:04 -0700 (PDT) In-Reply-To: <9404151243.AA08891@capitalist.princeton.edu> from "Carl Edman" at Apr 15, 94 08:43:55 am X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 735 Status: RO >>>>[From Carl Edman] You wrote the code, so I take your word for it. But did you have to use the Xpm library to do the parsing for you, or did you find it possible to do it correctly by hand ? Would you be willing to write an XPM parser skeleton which does not use any extra libraries or X or UN*X specific system facilities for use in all the clients ? I'd like to point out there I believe here already exist utilities to convert xpm to other formats. They do not use X calls, methinks. PS: "source tree is too large"? Come on Carl, you're grasping at straws. We're talking about clients here. clients are binary distribution, for macs and pee-cees. It only takes one major site to compile it. From crossfire-request Fri Apr 15 18:34:58 1994 Return-Path: Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 18:34:57 +0200 Received: (from postman@localhost) by andrew.cmu.edu (8.6.7/8.6.6) id MAA06486 for crossfire@ifi.uio.no; Fri, 15 Apr 1994 12:34:53 -0400 Received: via switchmail; Fri, 15 Apr 1994 12:34:52 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 15 Apr 1994 12:33:58 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 15 Apr 1994 12:33:55 -0400 (EDT) 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; Fri, 15 Apr 1994 12:33:55 -0400 (EDT) Message-ID: Date: Fri, 15 Apr 1994 12:33:55 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: Binary standards for images and sounds In-Reply-To: <199404150732.AA16377@bolero.rahul.net> References: <199404150732.AA16377@bolero.rahul.net> Status: RO Mark Wedel writes: > And while the data is not compact for XPM files, it is very compressible. > You (Carl) have been talking about how the links wil be compressing the > text information. The XPM data will be compressed just as nicely. Can I ask that you please don't do this. There are many links which do not compress -- for example all the backbone links. Shoving a 2 meg file out of my machine every time someone starts up will take a minute at best @ 40k/second. This is not a particularily good startup time -- actually it's really obnoxious. In comparison, after compression by gzip, the file is 143k long, which would take ~4 seconds to transfer. This is a much more palatable startup time. -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 Fri Apr 15 16:55:09 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 16:55:07 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA07072; Fri, 15 Apr 94 10:46:35 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA09316; Fri, 15 Apr 94 10:42:48 -0400 Date: Fri, 15 Apr 94 10:42:48 -0400 From: "Carl Edman" Message-Id: <9404151442.AA09316@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: Binary standards for images and sounds Reply-To: cedman@Princeton.EDU Status: RO From: Scott MacFiggen : > In message <9404151243.AA08891@capitalist.princeton.edu>you write: > >But for example the fact that Xpm uses named colors (rather than RGB > >values) alone causes a lot of problems. Sure, X systems have the > >same standard list of colors (with some local extensions) and the > >library calls to handle it, so it is nothing to worry about. But > >what about other systems ? When I ported Emacs 19 to NeXTstep > >this fact added some 25 kBytes to the installation and that was > >just because NS already had a system of color naming and I just > >needed to convert from the X to the NS color table format. But > >what about systems which don't having any naming system at all ? > >Are you going to write the source the code for them ? > > Before you start putting the XPM format down anymore I suggest you > download the libary and read throught the docs, it should take about > 1/2 hour. XPM format can take both named colors AND rgb colors. The > fact that it can take named colors is a big bonus. X is pretty smart > when it comes to color maps, if it is given a named color but can't > allocate it then it can find a pretty good match. If its given a rgb > value, it will have a harder time of doing this. Dont ask me why but > its true. I was planning on using the XPM format for another game > that i am/was/maybe going to write and did a bit of research on this. Please. I've said it several times and I'm willing to say it again: I'm not an expert on X. I've done more than my share of network programming, UN*X kernel drivers, compilers, games and even graphics programming under Display Postscript. I've never written an X program more complicated than hello-world and unless someone forces me to I won't in the future. That is why I ask questions about X and don't make judgements. I do not think Xpm is a bad protocol. Quite to the contrary it looks like it was quite clever and cute from what I know about it (I've also said that before). I just wonder if it is a good format to use for transmission of images between systems which are not X systems. To answer your particular point: Yes, XPM can use straight RGB values or named colors. Many of the current XPMs use named colors. Are we going to require in the protocol that the server translates them to RGB values ? If there is a consensus to do that then the problem I raised above is solved. Is there such a consensus ? If there is not, clients will still be required to deal with named colors and the problem I raised above remains. > I'm starting to lose confidence in what you are saying since you keep > telling us how bad XPM is but have no experience with it. Please try not to make personal attacks. There is enough heat in this debate from the issues alone. There is no need to add mutual ego bashing. Carl Edman From crossfire-request Fri Apr 15 15:12:28 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 Apr 1994 15:12:25 +0200 Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) with SMTP id GAA22661 for ; Fri, 15 Apr 1994 06:12:20 -0700 Message-Id: <199404151312.GAA22661@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: Re: Binary standards for images and sounds In-reply-to: Your message of "Fri, 15 Apr 1994 08:43:55 EDT." <9404151243.AA08891@capitalist.princeton.edu> Date: Fri, 15 Apr 1994 06:12:17 -0700 From: Scott MacFiggen Status: RO In message <9404151243.AA08891@capitalist.princeton.edu>you write: >But for example the fact that Xpm uses named colors (rather than RGB >values) alone causes a lot of problems. Sure, X systems have the same >standard list of colors (with some local extensions) and the library >calls to handle it, so it is nothing to worry about. But what about >other systems ? When I ported Emacs 19 to NeXTstep this fact added >some 25 kBytes to the installation and that was just because NS already >had a system of color naming and I just needed to convert from the X to >the NS color table format. But what about systems which don't having >any naming system at all ? Are you going to write the source the code >for them ? > Carl Edman Before you start putting the XPM format down anymore I suggest you download the libary and read throught the docs, it should take about 1/2 hour. XPM format can take both named colors AND rgb colors. The fact that it can take named colors is a big bonus. X is pretty smart when it comes to color maps, if it is given a named color but can't allocate it then it can find a pretty good match. If its given a rgb value, it will have a harder time of doing this. Dont ask me why but its true. I was planning on using the XPM format for another game that i am/was/maybe going to write and did a bit of research on this. I'm starting to lose confidence in what you are saying since you keep telling us how bad XPM is but have no experience with it. -Scott From crossfire-request Fri Apr 15 09:32: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 ; Fri, 15 Apr 1994 09:32:52 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA02690 (5.67a8/IDA-1.5 for ); Fri, 15 Apr 1994 00:32:37 -0700 Received: by bolero.rahul.net id AA16377 (5.67a8/IDA-1.5); Fri, 15 Apr 1994 00:32:35 -0700 Date: Fri, 15 Apr 1994 00:32:35 -0700 From: Mark Wedel Message-Id: <199404150732.AA16377@bolero.rahul.net> To: crossfire@ifi.uio.no, philb@soda.berkeley.edu Subject: Re: Binary standards for images and sounds Status: RO I have this further to say about the XPM image data: Even without the XPM library, it probably would not be difficult to write code to interpert and XPM library. The file I wrote to convert many small programs to montage images (ie, a large XPM image) was not that difficult, and handles the color information properly (ie, it does not drop monochrome information). The only thing that the xpmtopix program lacks is multiple character depth on input or output. That could probably be added in without a lot of effort. And while the data is not compact for XPM files, it is very compressible. You (Carl) have been talking about how the links wil be compressing the text information. The XPM data will be compressed just as nicely. Also, clients probably should not be requesting new image files all that often. On the client side, after receiving the image in XPM format, the client could write it out in whatever form suits its best (which would mostly likely be its native format for that system type (on PC/mac systems at least)). In any proposed format for image data, this would likely be done. Also, unless you have several image transmission formats (ie, different depending on the depth of the image), you may not save much with a different method. XPM uses 8 bits per pixel, and that would probably be the same for most any transmission method for color or greyscale systems. Also, the images need to be in an editable format at least at some stage. If you send them down the line in some other format, that conversion from XPM needs to be done someplace, and then the client converts the transmitted format to something yet again. Why not just let the client convert the XPM image. The XPM library source is quite small (less than a 100K tar gzipped file). And for clients, much of that code would not be needed (ie, reading from certain specific things or writing would not be needed.) I think you (Carl) are greatly over estimating how difficult it would be to write a program that converts from XPM format. --Mark From crossfire-request Fri Apr 15 09:22:00 1994 Return-Path: Received: from eden-valley.aaii.oz.AU (eden-valley.aaii.oz.AU [192.35.59.254]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 09:21:29 +0200 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA28101; Fri, 15 Apr 1994 17:20:44 +1000 Date: Fri, 15 Apr 1994 17:20:44 +1000 From: "Rupert G. Goldie" Message-Id: <199404150720.AA28101@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no Subject: Re: CPU -- Ultima 8 Status: RO > I would guess that it is due to a lot of floating point being used > (all speeds, which need to be changed), and your machine lackign floating > point hardware. > I wondered about it being the floating point. I guess the only way to find out is to remove the floating point stuff... > I wonder if the problem might be related to the devices, and the system > having trouble sending all the information to the screen fast enough? > Or maybe swapping. Otherwise, it really shouldn't be system time. > > --Mark > I don't think it is the X server. It doesn't consume much CPU and running crossfire from another machine to mine seems ok. Definitely not swapping. Now that I have 16 Meg the machine almost never swaps 8) Rupert From crossfire-request Fri Apr 15 09:16:44 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, 15 Apr 1994 09:16:36 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA02024 (5.67a8/IDA-1.5 for ); Fri, 15 Apr 1994 00:13:23 -0700 Received: by bolero.rahul.net id AA15260 (5.67a8/IDA-1.5); Fri, 15 Apr 1994 00:13:22 -0700 Date: Fri, 15 Apr 1994 00:13:22 -0700 From: Mark Wedel Message-Id: <199404150713.AA15260@bolero.rahul.net> To: crossfire@ifi.uio.no, rgg@aaii.oz.au Subject: Re: CPU -- Ultima 8 Status: RO I would guess that it is due to a lot of floating point being used (all speeds, which need to be changed), and your machine lackign floating point hardware. On my system (sun 3/60, 20 mhz 68020 + 68881 fpu), standing in the starting maps consumes about 30% of the cpu time, about 20% of the is crossfire, and 10% the XSun server (this is with XPM mode), most of which is user time. I wonder if the problem might be related to the devices, and the system having trouble sending all the information to the screen fast enough? Or maybe swapping. Otherwise, it really shouldn't be system time. --Mark From crossfire-request Fri Apr 15 11:01:19 1994 Return-Path: <<@isg-200.dfki.uni-kl.de:elsbernd@dfki.uni-kl.de>> Received: from uni-kl.de (mmdf@stepsun.uni-kl.de [131.246.136.50]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 11:01:17 +0200 Received: from isg-200.dfki.uni-kl.de by stepsun.uni-kl.de id aa01817; 15 Apr 94 11:01 MET DST Received: from dfki.uni-kl.de (isg-201 [131.246.241.71]) by dfki.uni-kl.de (8.6.5/8.6.5) with ESMTP id JAA25111; Fri, 15 Apr 1994 09:03:16 +0200 Message-Id: <199404150703.JAA25111@dfki.uni-kl.de> To: Mark Wedel cc: crossfire@ifi.uio.no, peterm@soda.berkeley.edu, elsbernd@dfki.uni-kl.de Subject: Re: bug report: nasty inventory destruction bug In-reply-to: Your message of "Thu, 14 Apr 1994 16:45:35 MET DST." <199404142345.AA20180@bolero.rahul.net> Date: Fri, 15 Apr 1994 09:03:13 +0200 From: Klaus Elsbernd Status: RO From: Peter Mardahl >Every so often, a player's inventory will get totally hozed. >Completely vanish..... Anyone got a clue why this might >happen? It usually happens like this: the server crashes, >the player re-enters to find his inventory missing. >This is really very devastating for a player. From: Mark Wedel > That bug is caused because when the server dies, it tries to do an >emergency save. > What ever caused the server to die (memory error of some type, typicall), >also messes up the object links, so when it tries to read the object >information to save, it gets another error, and gives up at that point, >with no inventory on the player. Perhaps the server could make a backup of the file in case of an emergency save. This is easily done. Then the crossfire admin could recover at least most of the data. MfG Klaus From crossfire-request Fri Apr 15 08:42: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 ; Fri, 15 Apr 1994 08:42:49 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id XAA22356 for crossfire@ifi.uio.no; Thu, 14 Apr 1994 23:42:46 -0700 From: Philip Brown Message-Id: <199404150642.XAA22356@soda.berkeley.edu> Subject: Re: Binary standards for images and sounds To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Thu, 14 Apr 1994 23:42:42 -0700 (PDT) In-Reply-To: <9404150138.AA08072@capitalist.princeton.edu> from "Carl Edman" at Apr 14, 94 09:38:00 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1426 Status: RO >>>>[From Carl Edman] >From Mark Wedel : > This is not a direct reply to the image format posted by Carl, but a > few notes. Well, that is well met because this not a direct reply to your proposal. Rather I'd to express the opinion that Xpm seems to be a very unsuited format for general distribution. While it does look clever and cute it seems to be very far from being compact. That may be a forgiveable failing, but it also looks like a pretty heavy format to interpret properly in all cases. Clients would have to write tons of code to handle it well. And before someone suggests libXpm, using it would foreclose the opportunity to run clients on anything but X systems which I thought was one of the main reasons for the switch to client/server. The code for Xpm is public! it's not like it's a commercial library... the souce is all open!!! Porters would just hav to replace a few X calls with their own windowing software stuff. I don't think there are actually that many X calls in the library! It's not supposed to be "compact". It's supposed to be "thorough". And it's pretty good in that respect. And to the point, it's better than any other format. It's built for the purpose of taking color pixmap data, and making it fit onto just about any color hardware setup. That is, after all, what we want. From crossfire-request Fri Apr 15 06:32:05 1994 Return-Path: Received: from po5.andrew.cmu.edu (PO5.ANDREW.CMU.EDU [128.2.10.105]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 06:32:04 +0200 Received: (from postman@localhost) by po5.andrew.cmu.edu (8.6.7/8.6.6) id AAA14507 for crossfire@ifi.uio.no; Fri, 15 Apr 1994 00:31:56 -0400 Received: via switchmail; Fri, 15 Apr 1994 00:31:55 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 15 Apr 1994 00:30:16 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 15 Apr 1994 00:30:05 -0400 (EDT) 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; Fri, 15 Apr 1994 00:30:04 -0400 (EDT) Message-ID: Date: Fri, 15 Apr 1994 00:30:04 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol In-Reply-To: <9404142107.AA07649@capitalist.princeton.edu> References: <9404142107.AA07649@capitalist.princeton.edu> Status: RO "Carl Edman" writes: > Yes, and how do you get a useable black and white from a true color > image ? Kjetil claims that it is almost impossible and I believe him > on this point. Depends on how much intelligence you put into your image format. I wrote a program to convert from xpm to xbm which would do the color conversions the way I wanted them. You draw the xpm and then you specify conversions like this: -- white gray50 None white dodger blue white blue black firebrick black goldenrod black yellow gray75 sienna black pale green black chocolate white -- The conversions then get taken through the ppmtopgm | pgmtopbm | pbmtoxbm pipeline which produces quite usable pictures. The program is available from madhatter.ws.cc.cmu.edu:pub/xpmtoxbm.pl, and the stuff I drew as KhoiKhoi.tar.gz -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 Fri Apr 15 05:56:38 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 05:56:32 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA07221; Thu, 14 Apr 94 23:56:28 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA08384; Thu, 14 Apr 94 23:52:41 -0400 Date: Thu, 14 Apr 94 23:52:41 -0400 From: "Carl Edman" Message-Id: <9404150352.AA08384@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: cheating & LOS Reply-To: cedman@Princeton.EDU Status: RO From: philb@cats.ucsc.edu > I think you're missing something here, Carl. You're claiming LOS is > BETTER than full transmission, in this case??? But you're forgetting > the new right side of the corridor in yours, I think. > > You cannot do better than full transmission of maps (with scrolling > extension) because under current rules, "blank" is just another face, > or "MAP". > > Either method HAS to transmit a 11x11 grid, PLUS 11 "new" faces for > each step east after that. blank, or not blank, you still transmit > them the same way. No, absolutely positively not. How often do I have to repeat that the protocol I proposed is _NOT_ *NOT* _NOT_ a series of graphical instructions to a dumb terminal which can display graphical characters. A majority of the criticisms of the protocol labour under that miscomprehension. The server does not tell the client what to draw when and where. It tells the client what it sees. Where it sees nothing because it is behind walls, it does not send map commands. The client knows for what areas it has received map commands and it only displays those. Those areas which are not mapped in, it can display whatever it wants and it doesn't need any instructions for it. BTW, you are a very strange person. Less than an hour ago you attacked the proposal in email for telling the client what items are in plain view. You claimed that obviously I was just trying to make it "easy" for players. Now you criticize the protocol for not telling the client what is located behind solid walls. Is there any consistency to this ? > The "typeahead" movement thing, should be chucked, IMHO. The client > checking for key down is fine. But otherwise, it's too much like > making the player a robot. And that is dangerous to do in the server. > The client should be able to overide any time, but this might not > happen, netlag being what it is. The client can override at any time by sending a new MOVE command. However if your client prefers not to send any commands unless there is a clear line, it should certainly feel free to. Just don't write to the crossfire list complaining that first your connection was frozen and then you were frozen by a chinese dragon. > The client could implement the "typeahead" completely in itself with > no problems. Sure. If you don't mind another multiplication of the latency. Carl Edman From crossfire-request Fri Apr 15 04:46:05 1994 Return-Path: Received: from cats.ucsc.edu (cats-po-1.UCSC.EDU [128.114.129.22]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 04:46:02 +0200 From: philb@cats.ucsc.edu Received: from am.ucsc.edu by cats.ucsc.edu with SMTP id TAA29350; Thu, 14 Apr 1994 19:45:46 -0700 Received: by am.ucsc.edu (8.6.8/4.7) id TAA21171; Thu, 14 Apr 1994 19:45:42 -0700 Message-Id: <199404150245.TAA21171@am.ucsc.edu> Subject: Re: cheating & LOS To: crossfire@ifi.uio.no Date: Thu, 14 Apr 1994 19:45:31 -0700 (PDT) In-Reply-To: <9404142345.AA07962@capitalist.princeton.edu> from "Carl Edman" at Apr 14, 94 07:45:42 pm Reply-To: philb@cats.ucsc.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2773 Status: RO > > Cost under your scheme: 9 step * 11 MAPs/step = 99 MAPS > > Cost under my scheme: The entire cross-corridor is mapped in (once) for > a cost of 3x11 MAPs. For the remaining 6 steps only the 3 new squares > in the narrow corridor need to be mapped in for a cost of 6x3 MAPs. > Total cost: 51 MAPs. > > So even in your worst case, the proposed protocol uses almost half the > number of MAPs which your proposed protocol requires ! > I think you're missing something here, Carl. You're claiming LOS is BETTER than full transmission, in this case??? But you're forgetting the new right side of the corridor in yours, I think. You cannot do better than full transmission of maps (with scrolling extension) because under current rules, "blank" is just another face, or "MAP". Either method HAS to transmit a 11x11 grid, PLUS 11 "new" faces for each step east after that. blank, or not blank, you still transmit them the same way. But the LOS method also has to blank approximately 5x9 image faces on the right, and unblank 5x9 on the left. Areas a + c (below) add to roughly 5x5, and so do b+d. \_ a || b _/ \_ || _/ \ || / -------- -------- A B -------- -------- _ /||\ _ _ / || \ _ / c || d \ So for 9 steps, [ignoring protocol info] LOS on server: 11x11 + 9x11 + 5x5 + 5x5 = 270 image faces no LOS : 11x11 + 9x11 = 220 image faces ******************************************************************* I think I picked up the rest of Jason's post, about using a "mask" He proposes , instead of sending new faces, sending 11-word binary viewing mask (?), that would change when neccessary. Each "word" would be 11 bits long , or whatever the width of the screen. So for instance, if you were travelling down an unmarked corridor, the mask would be (more zeros here) 00000000000 00000000000 00000000000 11111111111 00000000000 00000000000 00000000000 (more zeros here) The advantage to the mask idea being that, in "sparse" maps, where not much is visible, you can compress 11 squares of darkness into a single number. I think this is getting too complicated, personally, and it's not _that_ much of a win, if at all. (the trouble being that you HAVE to transmit 11 11-bit numbers when you want to change the mask) ************************************************************ The "typeahead" movement thing, should be chucked, IMHO. The client checking for key down is fine. But otherwise, it's too much like making the player a robot. And that is dangerous to do in the server. The client should be able to overide any time, but this might not happen, netlag being what it is. The client could implement the "typeahead" completely in itself with no problems. From crossfire-request Fri Apr 15 04:47:06 1994 Return-Path: Received: from eden-valley.aaii.oz.AU (eden-valley.aaii.oz.AU [192.35.59.254]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 04:45:22 +0200 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA26038; Fri, 15 Apr 1994 12:42:36 +1000 Date: Fri, 15 Apr 1994 12:42:36 +1000 From: "Rupert G. Goldie" Message-Id: <199404150242.AA26038@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no Subject: Re: cheating Status: RO "Carl Edman" : > > In general, for most maps, not a lot of objects move in the game > > window at the same time, so the updates shouldn't be that bad. > > Absolutely. And objects which don't move only get a single ITEM > command when they come into view and then never again. They are > essentially free. > > > However, what gets more complicated is smart updates. IF you are > > fighting 20 gnolls, and kill the one in front, and another one > > quickly steps up (and thus, lots of gnolls change position), do you > > necessarily want to re-send the position of all 20 gnolls? It might > > be much better just to remove one gnoll from the mass.0 However, > > under the current protocol, this would not be possible, as all > > objects are tagged with an ID number, and if this method was used, > > all the ID numbers would be off. But I am not sure how much the ID > > numbers are used for monsters. > > This is really not a case worth worrying about for three reasons: > > (1) Even sending ITEM commands for all twenty gnolls in the ASCII > format takes only 580 bytes. That is compressed down to 137 bytes by > gzip. While V.42bis is slightly less effective, it'd have more context > to work with so you can expect similar results there. Sending 137 > bytes even over the slowest acceptable link takes 70-140 ms. That's > certainly acceptable. And on an ethernet it'd take merely a fraction > of a millisecond. > > (3) Because of LOS considerations, you wouldn't see all twenty gnolls > which are in a line anyway further shortening display time. If the > gnolls are not all in a line, not all will make a step when you kill > one. > > (3) Due to the bidirectional nature of the proposed protocol even > during those milliseconds that you get the gnoll updates, you can still > move and fight. You want to run away ? No problem. You continue > hacking&slashing ? It is as if the delay hadn't happend. > > Carl Edman > It is worth worrying about for several reasons: 1) You can easily get way more than 20 monsters. Worst case is 120 in an empty area full of monsters. 40-50 wouldn't be an unreasonable number to expect. 2) LOS isn't relevant in a mostly open area. The gnolls don't have to be in a line. If they are in a mass and you kill one lots will move. 3) Without synchronisation people will scream, so your bi-directional pipe doesn't buy you much. If you can make 3 moves while only one screen update occurs you are going to find yourself in big trouble, usually when you can least handle it. 4) When there are lots of monsters there will probably also be lots of spells flying about. As a cone move across the screen do you want to update every object each time ? 5) With all those spells monsters will be dying and dropping items. 6) This situation (confronting a horde of monsters) is the time you least want to be hit by latency. I would much rather have latency when I examine an object then when I'm fighting a large number of spell casting monsters. Rupert (Despite flooding my mailbox Carl, you have generated a valuable discussion on the client/server issues) From crossfire-request Fri Apr 15 04:40:36 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 04:40:10 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA22246; Thu, 14 Apr 94 22:40:04 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA08206; Thu, 14 Apr 94 22:36:18 -0400 Date: Thu, 14 Apr 94 22:36:18 -0400 From: "Carl Edman" Message-Id: <9404150236.AA08206@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: Binary standards for images and sounds Reply-To: cedman@Princeton.EDU Status: RO Kjetil Torgrim Homme : > It is far more likely (and by far more easy to implement) that better > quality audio will be transmitted than anyone will change the size of > the images *and* handle variable sized images. (if the images aren't > variable in size, there's no need to transmit this data every time.) You will need variable sized images for 'big' monsters. I think they should be just one ITEM but have a large image. > Anyway - skipping a header for the audio data will save you _nothing_ > - audio files tend to be fairly large... That was not to save bandwidth. The reason for that suggestion was simplicity. > Clients that want them, should get true XPM-files - that way if they > want a persistent image cache, they don't need to keep one for each > different screen type. I thought *you* were the guy who said that you need different independent representation for black&white and color screens in _any_ case. > Indexed colours makes it more straightforward to represent > transparancy. An alpha channel is overkill, IMHO. If you want just simple transparency, require a 1-bit alpha channel. That is hardly overkill. Carl Edman From crossfire-request Fri Apr 15 04:10:00 1994 Return-Path: Received: from eden-valley.aaii.oz.AU (eden-valley.aaii.oz.AU [192.35.59.254]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 04:09:43 +0200 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA25752; Fri, 15 Apr 1994 12:08:47 +1000 Date: Fri, 15 Apr 1994 12:08:47 +1000 From: "Rupert G. Goldie" Message-Id: <199404150208.AA25752@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no Subject: Re: CPU -- Ultima 8 Status: RO > Well, last time I checked a 486 wasn't the lowest machine out there, > and thats whats recommened to run Ultima 8 on... On a 386 heard its > REALLY slow... *shrug* > > Ben I run 0.90.4 on my 486SX/25 under Linux. I noticed that when I run it the idle time drops to 0% and system time climbs to 91%. This is on the starting map with nothing moving about. top says it is crossfire using the system time, not X. I tried changing the speed, here's what I found: speed system % 100000 91 (The remaining is user time) 200000 91 300000 72 500000 46 1000000 17 So crossfire is quite a burden even on a (ok fairly lowly) 486. Rupert From crossfire-request Fri Apr 15 03:42:00 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 03:41:52 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA12765; Thu, 14 Apr 94 21:41:46 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA08072; Thu, 14 Apr 94 21:38:00 -0400 Date: Thu, 14 Apr 94 21:38:00 -0400 From: "Carl Edman" Message-Id: <9404150138.AA08072@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: Binary standards for images and sounds Reply-To: cedman@Princeton.EDU Status: RO From Mark Wedel : > This is not a direct reply to the image format posted by Carl, but a > few notes. Well, that is well met because this not a direct reply to your proposal. Rather I'd to express the opinion that Xpm seems to be a very unsuited format for general distribution. While it does look clever and cute it seems to be very far from being compact. That may be a forgiveable failing, but it also looks like a pretty heavy format to interpret properly in all cases. Clients would have to write tons of code to handle it well. And before someone suggests libXpm, using it would foreclose the opportunity to run clients on anything but X systems which I thought was one of the main reasons for the switch to client/server. Personally, I'd think that the ideal format for images would be EPS because it is so flexible and device independent. The ability to scale and rotate the image arbitarily would make for a beautiful client. However there are just too many systems without postscript and for which it would be to demand to much that PS is installed (the free availability of ghostscript notwithstanding), so that I won't even suggest it. Let's go with something simple and easy to interpret (and compact, if possible). The format I suggested would probably fit the bill, but if someone comes up with something better, I'd be happy to take that instead. Carl Edman From crossfire-request Fri Apr 15 03:36:59 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 03:36:58 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Fri, 15 Apr 1994 03:36:57 +0200 Date: Fri, 15 Apr 1994 03:36:57 +0200 Message-Id: <199404150136.5037.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: "Carl Edman"'s message of Thu, 14 Apr 94 18:52:36 -0400 <9404142252.AA07877@capitalist.princeton.edu> Subject: Re: Binary standards for images and sounds Status: RO +--- Carl Edman: | Byte Meaning | 00 Unsigned char for the number of pixels in X direction | 01 Unsigned char for the number of pixels in Y direction | [...] | Would there be much of an outcry if we just chose a headerless stream | of signed 8-bit mono samples to be played at 8 kHz ? It is far more likely (and by far more easy to implement) that better quality audio will be transmitted than anyone will change the size of the images *and* handle variable sized images. (if the images aren't variable in size, there's no need to transmit this data every time.) Anyway - skipping a header for the audio data will save you _nothing_ - audio files tend to be fairly large... Clients that want them, should get true XPM-files - that way if they want a persistent image cache, they don't need to keep one for each different screen type. Indexed colours makes it more straightforward to represent transparancy. An alpha channel is overkill, IMHO. Kjetil T. From crossfire-request Fri Apr 15 01:49:38 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 01:49:34 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA23509; Thu, 14 Apr 94 19:49:28 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA07962; Thu, 14 Apr 94 19:45:42 -0400 Date: Thu, 14 Apr 94 19:45:42 -0400 From: "Carl Edman" Message-Id: <9404142345.AA07962@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: cheating & LOS Reply-To: cedman@Princeton.EDU Status: RO From: Jason Fosback > > But the protocol I proposed does not require you send every single > > visible square every time you move. It requires the server to > > send every square once when it _becomes_ visible. After that the > > server doesn't need to concern itself with that square at all > > until it becomes invisible again. And by invisible I mean outside > > the LOS -- just having items (like monsters or more common > > objects) on the square does not make it invisible. > > Right, but squares outside your line of sight come and go > continuously, every time you move. That's for sure. So do the number of squares within the 11x11 square centered around the player. It is that which you propose should always be sent to the client requiring the update of 11 squares in every single move ? It is doubtful that my proposed protocol will do worse than that. > Take this ASCII (!) example: Yes, lets take your worst case scenario and calculate the cost. I believe what you suggest is this with the player moving from A to B. | | | | | | | | ----+ +------------ A B ----+ +------------ | | | | | | | | Cost under your scheme: 9 step * 11 MAPs/step = 99 MAPS Cost under my scheme: The entire cross-corridor is mapped in (once) for a cost of 3x11 MAPs. For the remaining 6 steps only the 3 new squares in the narrow corridor need to be mapped in for a cost of 6x3 MAPs. Total cost: 51 MAPs. So even in your worst case, the proposed protocol uses almost half the number of MAPs which your proposed protocol requires ! > Alternatively, since this is a little redundant, you could make the > move command a little more restrictive (since you're always in the > middle of the screen: > > C: MOVE [N,NE,E,SE,S,SW,W,NW] The move command needs to have more arguments, because it is used not only to move yourself but also all items i.e. dropping/pick up is done by the MOVE command. The reason the proposed MOVE allows you to give an arbitrary location is that this allows clients to request long moves without being limited by a round-trip delay for every step. I would expect the server to internally convert a MOVE to a distant location to a straight-line approximation by single steps. In particular a client would express a run command (currently trigged by the control key in crossfire) by sending a command like this: MOVE This command would make the player character run as far south as possible as quickly as possible. Carl Edman From crossfire-request Fri Apr 15 01:46:42 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, 15 Apr 1994 01:46:15 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA08205 (5.67a8/IDA-1.5 for ); Thu, 14 Apr 1994 16:45:36 -0700 Received: by bolero.rahul.net id AA20180 (5.67a8/IDA-1.5); Thu, 14 Apr 1994 16:45:35 -0700 Date: Thu, 14 Apr 1994 16:45:35 -0700 From: Mark Wedel Message-Id: <199404142345.AA20180@bolero.rahul.net> To: crossfire@ifi.uio.no, peterm@soda.berkeley.edu Subject: Re: bug report: nasty inventory destruction bug Status: RO That bug is caused because when the server dies, it tries to do an emergency save. What ever caused the server to die (memory error of some type, typicall), also messes up the object links, so when it tries to read the object information to save, it gets another error, and gives up at that point, with no inventory on the player. The new version of crossfire (which will probably go out tomorrow, but maybe today, depending what time I finish at how fast the links are) have the AUTOSAVE fixed (both for dropping, and the one that saves ever XXX ticks. Also, NO_EMERGENCY_SAVE is also fixed.) The only true fix for that problem is to never have the server crash. But the above should make the player data pretty safe. --Mark From crossfire-request Fri Apr 15 01:41:10 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, 15 Apr 1994 01:41:07 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA07869 (5.67a8/IDA-1.5 for ); Thu, 14 Apr 1994 16:41:04 -0700 Received: by bolero.rahul.net id AA19712 (5.67a8/IDA-1.5); Thu, 14 Apr 1994 16:41:03 -0700 Date: Thu, 14 Apr 1994 16:41:03 -0700 From: Mark Wedel Message-Id: <199404142341.AA19712@bolero.rahul.net> To: cedman@Princeton.EDU, crossfire@ifi.uio.no Subject: Re: Binary standards for images and sounds Status: RO This is not a direct reply to the image format posted by Carl, but a few notes. XPM files can handle up to 24 bit colors (I believe) per image. It can change the number of characters for each each pixel. By default, it uses 1 character per pixel (About 96 colors I think). But 2 charcter/ pixel, 3, etc, are all allows. Also, the XPM image format is somethign like this for colors: (charcter) c (color name) m (monochrome name) g4 (4 bit greyscale) g (normal greycale) So an example might be something like: A c blue m black g4 grey30 g grey 50 B c blue m white g4 grey90 g grey 90 So on color, both the A and B pixels woudl be blue. On monochrome, the A pixels would be black, B pixels white. And so on fro the greyscale. While this does not really allow color to monochrome conversion, it allows the drawers of the images to set the monochrome names to be used on those systems. Very few of hte XPM images in crossfire have been set so, but I have done (and checked) that all the potions work as expected. By default, XPM will, if monochrome or greyscale is not specified, convert the color name into the closest equivalant (such that browns would be turned into blacks, but yellows and oranges will be turned into whites on greyscale. And I would imagine that the approximate grey levels would be done.) The real point is that more the one image format really does not need to be stored on the server to handle different display depths. It would be (I suppose) up the client to convert the XPM data it gets into whatever format it uses (and even for the same client, it could be different depths (ie, on unix, some people have color, others monochrome. A client installed on the same site may be supporint different display types). 24 bit color: While XPM will support this (even in one image), there is not 24 bit color field in the XPM images. 1 color field for all color types (8 bit, 24 bit, and any other ones that may be out there). The reason the about 30 colors was chosen for XPM images as it is now it to not overflow the colormap on 8 bit images. The XPM library does have some facilities for close color matching if the color table is filled up, but with default loading this could have problems, like the first image using a lot of the same general colors (for example, and woods or grass area, using ltos of greens). Depending on the loading, this could mean that the colors allocated are not a broad sample (maybe you ahve 120 greens, 80 blues, and just a handful of the rest of the colors). The solution for 24 bit bit could be for the client to allocate a color table (possibly private) with a broad array of colors, and have the loader use this color table, with color closeness. However, I don't think 24 bit will happen in the immediate future. It is takign a little while just to convert the images to '5 bit' (30 colors or so) images. Conversion of 24 bit would certainly take a lot longer, and I am not sure how much of a gain there would be. Also, for client/server, the XPM images will be stored in non montage format for sending to the client. So if the client just wants the picture of the ogre, just those 24x24 XPM files get sent, not he entire montage. This has the advantage that new pixmaps can be added and sent down the wire quickly - you don't need to send the entire montage. As I stated before, the client coudl store these however it wants (perhaps making a montage if it speeds up loading). --Mark From crossfire-request Fri Apr 15 01:21:25 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 Apr 1994 01:21:24 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id QAA28622 for crossfire@ifi.uio.no; Thu, 14 Apr 1994 16:21:19 -0700 Date: Thu, 14 Apr 1994 16:21:19 -0700 From: Peter Mardahl Message-Id: <199404142321.QAA28622@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: bug report: nasty inventory destruction bug Status: RO Every so often, a player's inventory will get totally hozed. Completely vanish..... Anyone got a clue why this might happen? It usually happens like this: the server crashes, the player re-enters to find his inventory missing. This is really very devastating for a player. I don't really know those sections of the code very well, I'm hoping someone else will have insight into it, and better yet, will fix it! Regards, PeterM From crossfire-request Fri Apr 15 01:17:01 1994 Return-Path: Received: from mccaw.com (wombat.mccaw.com [192.135.191.118]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 01:16:55 +0200 Received: from nwestmail.entp.mccaw.com ([155.176.15.34]) by mccaw.com (4.1/SMI-4.1) id AA20327; Thu, 14 Apr 94 16:16:48 PDT Received: from axys69.nwest.mccaw.com by nwestmail.entp.mccaw.com (4.1/McCaw SUN-RMR Mailer, SMI-4.1) id AA07924; Thu, 14 Apr 94 16:16:47 PDT Received: from divac by axys69.nwest.mccaw.com (NX5.67d/NX3.0M, dpg hack 15oct93) id AA21935; Thu, 14 Apr 94 16:19:14 -0700 From: Jason Fosback Message-Id: <9404142319.AA21935@axys69.nwest.mccaw.com> Received: by divac.nwest.mccaw.com (NX5.67d/NX3.0X, dpg hack 20mar93) id AA05703; Thu, 14 Apr 94 16:19:40 -0700 Date: Thu, 14 Apr 94 16:19:40 -0700 Received: by NeXT.Mailer (1.100.RR) Received: by NeXT Mailer (1.100.RR) To: cedman@Princeton.EDU Subject: Re: cheating & LOS Cc: crossfire@ifi.uio.no Status: RO > But the protocol I proposed does not require you send > every single visible square every time you move. It > requires the server to send every square once when it > _becomes_ visible. After that the server doesn't need > to concern itself with that square at all until it becomes > invisible again. And by invisible I mean outside the > LOS -- just having items (like monsters or more common > objects) on the square does not make it invisible. Right, but squares outside your line of sight come and go continuously, every time you move. Take this ASCII (!) example: / / | XXXXXXXXXXXXXXXXXX/ XXXXXXXXXXXXXXXXXX M XXXXXXXXXXXXXXXXXX\ XXXXXXXXXXXXXXXXXX \ | \ | / | / XXXXXXXXXXXXXXXXXX/ XXXXXXXXXXXXXXXXXX M XXXXXXXXXXXXXXXXXX\ XXXXXXXXXXXXXXXXXX | \ | \ \ / \ / XXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX M XXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX / \ / \ \ | \ | XXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX M XXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX / | / | A lot easier to understand than binary, hunh? ;) Anyway, every time you move, you're transmitting the new squares becoming visible on the right hand side -----> of the screen. You're also re-sending ALL the squares that are becoming visible/invisible. If you had a mask that did this for you, you're transmitting a very small value, and you don't have to re-transmit the same stuff over and over again. This is just a simple example. In a more complex room, you could be sending butt-loads of MAP commands every time you move. With a constant number of squares becoming visible each movement, you're better off in terms of optimization and such. If you had a NEWMAP object1 object2 ... object 11 mask command each time you moved, it would be in ONE IP packet (not MULTIPLE packets, each of which has 64 bytes MINIMUM of header, with X bytes following). AND, it wouldn't have to be limited to 11 map squares. You could exchange client visibility with the server at start up, and the command could be: C: SET VIEWSIZE n m . . C: MOVE x y S: NEWMAP object1 object2 ... objectn mask If you move diagonally, it could be: S: NEWMAP object1 object2 ... objectn mask S: NEWMAP object1 object2 ... objectm mask Alternatively, since this is a little redundant, you could make the move command a little more restrictive (since you're always in the middle of the screen: C: MOVE [N,NE,E,SE,S,SW,W,NW] In which case the server could send a different packet for NEWMAP: S: NEWMAP object1 object2 ... objectn object1 object2 ... objectm mask -jason ____________________________________________________________ Jason Fosback, Systems Engineer | No sir, I didn't like it --- Paradigm Systems Corp --- | -R&S Internet: jason_fosback@psca.com | Star Trek: NeXT mail: jason_fosback@psca.com | The NeXT Generation... From crossfire-request Fri Apr 15 01:18:36 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 Apr 1994 01:18:33 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id QAA28103; Thu, 14 Apr 1994 16:18:26 -0700 Date: Thu, 14 Apr 1994 16:18:26 -0700 From: Peter Mardahl Message-Id: <199404142318.QAA28103@soda.berkeley.edu> To: tvangod@ecst.csuchico.edu Subject: inventory bug Cc: crossfire@ifi.uio.no Status: RO The inventory bug is still haunting the server. Actually, Rumoko.pl is totally hozed, looks like he's corrupted. Take a look at him, would you? If he's totally hozed, mail me the wreckage and I'll fix him and mail him back.... Sigh. This really makes me wonder. Maybe server admins should back up everyone once per day. regards, PeterM From crossfire-request Fri Apr 15 00:56:34 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 00:56:32 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA13916; Thu, 14 Apr 94 18:56:24 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA07877; Thu, 14 Apr 94 18:52:36 -0400 Date: Thu, 14 Apr 94 18:52:36 -0400 From: "Carl Edman" Message-Id: <9404142252.AA07877@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Binary standards for images and sounds Reply-To: cedman@Princeton.EDU Status: RO None which are easily implemented on a wide variety of architectures have been suggested yet, so please let me do so here. These are just quick suggestions, so please do criticize (as if I had to ask) if you disapprove of them. IMAGES ====== I believe the following format is fairly close to being as compact as it gets with small images. Furthermore it should be easy to parse on virtually any architecture. Finally, it is fair as I don't think _any_ system uses it as its native format. Byte Meaning 00 Unsigned char for the number of pixels in X direction 01 Unsigned char for the number of pixels in Y direction 02 Unsigned char indicating the number of components the image has 01 = greyscale image with complete covering 02 = greyscale image with alpha channel 03 = color image with complete covering 04 = color image with alpha channel 00 or 05... error 03.. 03+number of components Number of bit planes for the components (if they exist) in order: B/W, R, G, B, Alpha 03+number of components+1 .. 03+number of components+1+((tot number of bitplanes*xsize*ysize+7)/8) An array of bits which indicates the values for the above components (in the above order) in the pixel order (x,y) = (0,0),(1,0)..(xsize-1,0),(0,1),...,...(xsize-1,ysize-1) SOUND ===== Would there be much of an outcry if we just chose a headerless stream of signed 8-bit mono samples to be played at 8 kHz ? Virtually all sound hardware can play this easily and you can't get much simpler. Or will the people with 44.1 kHz 16 bit stereo hardware feel cheated and demand multiple sound qualities ? :-) Carl Edman From crossfire-request Fri Apr 15 00:08:29 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 00:07:50 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA05046; Thu, 14 Apr 94 18:07:40 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA07728; Thu, 14 Apr 94 18:03:54 -0400 Date: Thu, 14 Apr 94 18:03:54 -0400 From: "Carl Edman" Message-Id: <9404142203.AA07728@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: cheating & LOS Reply-To: cedman@Princeton.EDU Status: RO From Jason Fosback : > Okay, I've been converted to LOS on the server, but NOT because of > the cheating issue. LOS on the server allows for updates in ONE > place, rather than bazillions of places. Also, it allows for cool > effects like torchlight and stuff like that. *I* wouldn't want to > write those algorithms. Sure, we could take the sources from one > client and port them to another, but it's much easier to do it in > one place. That is also a very good point, not entirely unrelated to one I once made about how client side LOS would handle cool effects like helmets of x-ray vision, infravision, different vision ranges for different character races a.s.o. > If I understand correctly, you'd have to transmit every VISIBLE > square every time you moved? Is this correct? Please, DON'T FLAME > ME; Please forgive me if sound slightly tense at times. I'm not (quite) as terrible as I sound, I promise. :-) But the protocol I proposed does not require you send every single visible square every time you move. It requires the server to send every square once when it _becomes_ visible. After that the server doesn't need to concern itself with that square at all until it becomes invisible again. And by invisible I mean outside the LOS -- just having items (like monsters or more common objects) on the square does not make it invisible. Carl Edman From crossfire-request Thu Apr 14 23:34:12 1994 Return-Path: Received: from mccaw.com (wombat.mccaw.com [192.135.191.118]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 23:34:02 +0200 Received: from nwestmail.entp.mccaw.com ([155.176.15.34]) by mccaw.com (4.1/SMI-4.1) id AA19887; Thu, 14 Apr 94 14:33:51 PDT Received: from axys69.nwest.mccaw.com by nwestmail.entp.mccaw.com (4.1/McCaw SUN-RMR Mailer, SMI-4.1) id AA06796; Thu, 14 Apr 94 14:33:50 PDT Received: from divac by axys69.nwest.mccaw.com (NX5.67d/NX3.0M, dpg hack 15oct93) id AA19791; Thu, 14 Apr 94 14:36:17 -0700 From: Jason Fosback Message-Id: <9404142136.AA19791@axys69.nwest.mccaw.com> Received: by divac.nwest.mccaw.com (NX5.67d/NX3.0X, dpg hack 20mar93) id AA05594; Thu, 14 Apr 94 14:36:40 -0700 Date: Thu, 14 Apr 94 14:36:40 -0700 Received: by NeXT.Mailer (1.100.RR) Received: by NeXT Mailer (1.100.RR) To: crossfire@ifi.uio.no Subject: Re: cheating & LOS Status: RO > But that is just part of the perniciousness of client > omniscience cheating. It is completely and 100% > undetectable from the server side. Unless you look over > the shoulder of every player all the time, you are never > going to find out whom to lock out. And as that is so, > every cheating player gets a free advantage. Honest > players have no way of knowing if they are the only ones > who labour under that disadvantage and so can rationally > only decide to become cheaters as well. You'll end up > with a system without LOS. As I've said before, if that > is what you want, lets debate it before we go to all the > trouble of implementing LOS algorithms which nobody will > use in the end anyway. Okay, I've been converted to LOS on the server, but NOT because of the cheating issue. LOS on the server allows for updates in ONE place, rather than bazillions of places. Also, it allows for cool effects like torchlight and stuff like that. *I* wouldn't want to write those algorithms. Sure, we could take the sources from one client and port them to another, but it's much easier to do it in one place. I don't buy the whole idea of LOS on the server reducing bandwidth. You still have to say, "Here are all of the changes." This can encompass squares all around you, not just in front of you. Take a look at the Friendly Giant's Tower. The first floor with all of the Kobolds would force updates in front of you as well as all around. The updates could happen to about 3-4 lines behind you, including squares to your sides. If I understand correctly, you'd have to transmit every VISIBLE square every time you moved? Is this correct? Please, DON'T FLAME ME; there have been so many suggestions and alternatives posted in the last few days, it would be impossible for anyone to keep them all straight. I think we each know how we would want it, and have a vague idea of how it would be in everyone else's way. Anyway :), it seems like you have a tradeoff: you could transmit some unknown number of squares everytime you move, indicating the map section to be displayed at a given coodinate, and hope that that number is usually small; or you could transmit a fixed number of maps sections to be displayed every time you move, along with a LOS mask. This way, you're transmitting exactly 11 squares every time you move, and a coulple of bytes which would represent the visibility mask. This seems like a good solution to me. Of course, it doesn't get rid of clients that would simply ignore the visibility mask, but if you want to talk about tranmission and optimization, it seems to make a lot more sense to work with constants. It would be easy to optimize the above method, since you know exactly how much map information you would receive every time you moved. -jason ____________________________________________________________ Jason Fosback, Systems Engineer | No sir, I didn't like it --- Paradigm Systems Corp --- | -R&S Internet: jason_fosback@psca.com | Star Trek: NeXT mail: jason_fosback@psca.com | The NeXT Generation... From crossfire-request Thu Apr 14 23:22:00 1994 Return-Path: Received: from cc.lut.fi (hevi@cc.lut.fi [157.24.15.37]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 23:21:56 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id AAA24356; Fri, 15 Apr 1994 00:21:49 +0300 Date: Fri, 15 Apr 1994 00:21:49 +0300 (EETDST) From: Petri Heinil{ Subject: Re: LOS-- the final answer To: Crossfire Mailing List In-Reply-To: <199404142018.NAA16919@soda.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 14 Apr 1994, Philip Brown wrote: > I proposed an answer for this in one of my messages, but I'm sure most > people overlooked it in the flood. > > Can we agree to have client Line-of-sight as an option? I think the in the server side the world creator should be able to change the LOS to another kind LOS if it's fits the world better. And in the server should also be able show other visiual effects, hmm, I think the animation is is indeed visual effect and it should be dynamic changeable by server as well as. And if the LOS is optional for player, then who use it ? btw. It seems not to be noticed, but it think when the clent/server appears then the server will be modified to different worlds in different hosts. The server code will be saparated. So the client code sould be as much possible independend from the server side. The protocol is the only interface between. -- The Page -- From crossfire-request Thu Apr 14 23:11:49 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 23:11:48 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA25559; Thu, 14 Apr 94 17:11:44 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA07649; Thu, 14 Apr 94 17:07:57 -0400 Date: Thu, 14 Apr 94 17:07:57 -0400 From: "Carl Edman" Message-Id: <9404142107.AA07649@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol Reply-To: cedman@Princeton.EDU Status: RO From: Philip Brown : >>>>[From Carl Edman] > OK, let me propose a compromise. The server will not know or > care what kind of color hardware the client has. However the > client can REQUEST not just PIX and SND types, but can request > the types BW1, BW2, BW3, .. BW8 to receive black and white XPMs > of one to eight bit planes and CO1 to CO8 to receive color XPMs > of one to eight bit planes per color. > > To use one of your arguments back at you.. do you _really_ want to > "support" 8 different kinds of display for each and every item face? > that's a lot of (anoying and unneccessary) work. No, as you may have read in the next sentence (which you so judiciously cut) the server can have as many or as few actual representations stored as it wants. When images are requested in a color resolution which is not available on store the server will reduce the color resolution from the next better resolution available. That is trivial. My argument was about supporting different IMAGE FORMATS (which I still oppose), not COLOR RESOLUTIONS. > 8-bit greyscale systems have default dithering from color to what > they have got. less capable systems will have to deal with > black-and-white. It's their fault for buying inadequate hardware. Yes, and how do you get a useable black and white from a true color image ? Kjetil claims that it is almost impossible and I believe him on this point. Carl Edman From crossfire-request Thu Apr 14 22:18: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 ; Thu, 14 Apr 1994 22:18:03 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id NAA16919 for crossfire@ifi.uio.no; Thu, 14 Apr 1994 13:18:00 -0700 From: Philip Brown Message-Id: <199404142018.NAA16919@soda.berkeley.edu> Subject: LOS-- the final answer To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Thu, 14 Apr 1994 13:17:56 -0700 (PDT) X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 676 Status: RO I proposed an answer for this in one of my messages, but I'm sure most people overlooked it in the flood. Can we agree to have client Line-of-sight as an option? For the paranoid, you can have #defines (or an -option) to have the server do LOS calculation, and not send info o the client about anything out of sight. Note that this method will not break either a normal, or a cheating client. It will simply enforce non-cheating of that sense, at the cost of server cycles. Keeping the unrestricted update is a much simpler, cleaner way of programming it. I suggest we use it to get things started. Then the net.cops amoung us can add the LOS in the server, in #defines. From crossfire-request Thu Apr 14 21:47:27 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 21:47:25 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA09081; Thu, 14 Apr 94 15:47:03 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA07552; Thu, 14 Apr 94 15:43:15 -0400 Date: Thu, 14 Apr 94 15:43:15 -0400 From: "Carl Edman" Message-Id: <9404141943.AA07552@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: cheating Reply-To: cedman@Princeton.EDU Status: RO lemke@ncd.com writes: > i'm one of those who think cheating is unimportant -- people who > really want to do it will probably find away around any safeguards, > if only for the challenge (as most crackers will tell you). I'd sure hate to use a rlogind written by you. "Why bother requiring or verifying a password to get root access ? True hackers will figure out a way around that anyway." > if you're really worried about it, then perhaps some form of server > access control is the simplest solution. just disallow connections > from users/sites/playernames that are caught cheating, and as as many > of the security checks out of things like rshd that you need. But that is just part of the perniciousness of client omniscience cheating. It is completely and 100% undetectable from the server side. Unless you look over the shoulder of every player all the time, you are never going to find out whom to lock out. And as that is so, every cheating player gets a free advantage. Honest players have no way of knowing if they are the only ones who labour under that disadvantage and so can rationally only decide to become cheaters as well. You'll end up with a system without LOS. As I've said before, if that is what you want, lets debate it before we go to all the trouble of implementing LOS algorithms which nobody will use in the end anyway. Carl Edman From crossfire-request Thu Apr 14 21:39:23 1994 Return-Path: Received: from corpse.ecst.csuchico.edu (corpse.ecst.csuchico.edu [132.241.5.10]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 21:39:20 +0200 Received: (from tvangod@localhost) by corpse.ecst.csuchico.edu (8.6.8/8.6.6) id MAA08872; Thu, 14 Apr 1994 12:39:08 -0700 From: Tyler Van Gorder Message-Id: <199404141939.MAA08872@corpse.ecst.csuchico.edu> Subject: Re: Line-of-sight, still To: philb@soda.berkeley.edu (Philip Brown) Date: Thu, 14 Apr 1994 12:39:08 -0700 (PDT) Cc: crossfire@ifi.uio.no In-Reply-To: <199404141745.KAA15370@soda.berkeley.edu> from "Philip Brown" at Apr 14, 94 10:45:20 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2847 Status: RO > > [Note: I actualy changed the Subject: line to keep it relevant! > Ooooooo.... AAaahhhh......] > > > >>>>[From Carl Edman] > > Again, I disagree. We have been over this terrain three or four times > already in the last few days, but I guess I'm the only one who actually > reads all the articles (it helps in replying). Having LOS done on the > client side both costs you huge latency every time you enter or leave a > map even if you only move a few squares in it and requires the constant > transmission to the client the location of every single moving monster > in the entire map even if the player is standing still. > > > Where did you get this??? You only have to transmit things that chnge in > the 11x11 part of the map. > > People who have chhacked their client to "see a larger area" wil be able > to see where they are relative to other things (which I think is a > wonderful idea). However, their actual character can only physically see > 5 squares ahead, so that's what they get updates for. ^^^^^^^^^^^^^^^^^^^ yes, I think it would be a good idea for the server to keep a frame of reference for each client...5x5..or NxN where N is defined by the server god. Then, if changes occur on that NxN section, server sends them to the client. Of course, if the client is configured to show only a 5x5 and the server has a 7x7 frame of reference, then the server would be sending data that the client cant see..... likewise though...if a "cheating" client has an 11x11 viewing area..but the server only has a 5x5 frame of reference well the client just doesnt get any data from the server outside of 5x5. Let the client do LOS for its whole viewing area...if your only allowing it to see 5x5...it can calculate outside that all it wants...the user still wont see much. Something on pixmaps: (kinda a different topic) I still think the best way would be to ask the user if they wish to download two different set of pixmaps when they first login: FIRST is a standard library that is common to all servers and the second is a specific set of pixmaps for that server. The user would also be notified of what date the standard and specific pixmap librarys were last updated. So if a user has downloaded the "standard library" from any server...it should be exactly the same...as long as it has the same date as the one the server reports. For server gods, the standard library would be "off limits" for modifying. What this does is put all pixmap info on the client side..thus after the initial time of downloading and saving the pixmap library to a local directory, all display data can be pulled out of that library and not transmitted across. Tyler. ps. Sorry if I have rehashed anything.....I am guilty of not reading ALL messages....but I have read many :> ` From crossfire-request Thu Apr 14 20:29:24 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 20:29:18 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA22894; Thu, 14 Apr 94 14:29:07 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA07419; Thu, 14 Apr 94 14:25:20 -0400 Date: Thu, 14 Apr 94 14:25:20 -0400 From: "Carl Edman" Message-Id: <9404141825.AA07419@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol Reply-To: cedman@Princeton.EDU Status: RO Kjetil Torgrim Homme writes: > Next time, Carl, please READ my posts before replying. I try to -- really. But after reading the same argument for half a dozen times in a few days, one tends to overlook subtle differences when one reads something similar one more time. :-) > First - BITMAPS won't be rotated for the player, so the roof of the > shop would appear beneath the door. Well, now that would be a little peculiar, wouldn't it ? > But even a client which keeps old mapping information is allowed to > throw it away if there is a real memory crunch. The point was that the client could tell the server that it wouldn't do that in order to save bandwidth. > > Here I disagree. What you are proposing is just a variation of the > > client-side LOS scheme with all (or at least most) the attendant > > problems. > > WHAT? My scheme is a superset of yours. Only objects in the viewpoint > are updated, and only if they have changed since they last were in > the clients viewport. > > This can be done very efficiently in the server. No need to add flags > dynamically to objects, just reserve a long word as a bitmask (max. > 32 clients). Object size is currently ~250 bytes, so this doesn't > make much of a difference RAM-wise or CPU-wise, but it has a > tremendous effect bandwidth-wise. You mean to say that every single map square even in a huge map is almost 1/4 of a kByte large ? I have to admit that it has been some time since I studied the crossfire source, but I hadn't realized that. If that is so, another extra longword probably isn't worth fighting about. > > No side _ever_ sends binary data without the other side requesting > > it first. And the REQUEST command contains a TYPE field which > > allows the client to specify what kind of data it wants. > > That was exactly my point. When the client requests an image, the > server can respond with an image type unknown to the client, and the > client can do _nothing_ about it. No, there will only be one single image type (e.g. XPM) and every single client will have to understand that type. We really don't want to have to build TIFF, GIF, JPEG, the MS Windows formats, IFFs a.s.o. in the server. One single image type in the server and the client is free to cache images in its local format. > > However the client can REQUEST not just PIX and SND types, but can > > request the types BW1, BW2, BW3, .. BW8 to receive black and white > > XPMs of one to eight bit planes and CO1 to CO8 to receive color > > XPMs of one to eight bit planes per color. > > Why restrict yourself to 8 bit planes? The full set of XPM's in > Crossfire could use 16,777,216 colours. Now, if I may be so bold as to suggest that you read _my_ post before responding to it ? 8/bits per color and 3 colors == 16,777,216 total colors. > An individual bitmap can only use 256 of them, though. More seriously > - this isn't something we need to decide now, if you just allow some > sort of negotiation. Indexed colors really are a hack. The server/transmission format should not contain it. If the client has to work with fixed or limited color maps, let it request a direct color image of some color resolution and then do the conversion itself. > And Carl, have a look at the crossfire.pix file to see that XPM is a > different beast altogether from just an 8 bit colour image. (search > for booze, for example) I'm sorry but I do almost all my programming these days far away from graphics -- and if I have to do graphics programming I use NeXTstep i.e. display postscript so I've to plead ignorance about the details of the various X formats. > One more thing I forgot last post: You misread the meaning of my MAP > extension - it should list multiple pixmaps on that coordinate! Multiple pixmaps in one square ? But one paragraph below you say that you like ITEMs -- which make more than one pixmap in one square completely unnecessary. > I must say I agree with Tero, though - we really don't want to go > back to .om. That is really a question for the server design. I can see good points on either side, but I'm in too many discussions already. > I revise my standpoint, and suggest > > MAP > > currently, will only have two meanings, 0 (corresponds to > UNMAP) and 9. When we get light sources later, we can send other > numbers. Many clients could map all values > 0 to 9, ie. no shading. As much as I like lighting in principle your proposal requires that in the common case where the player carries a light source, you send MAP commands for almost every square in the viewport every time the player takes a step. Do you think you could live with a system in which every square is either lighted (i.e. MAPed) or unlighted (i.e. UNMAPed) ? > Okay, with all that said, perhaps a little on where I agree with you? > :) ITEM commands are a nice, general approach to it, especially after > you said that animation sequences is just another sort of image. Thank you. It is nice to see that at least one reader agrees on at least one part of my proposal. :-) > BTW, I think there should be a protocol response for damage. DAM > > > That way a client can present it graphically, not just spew out a > stream of text. Since the client knows the names, it can make up the > text itself if it wishes to. Sounds fine to me with the exception that I'd add a string to the end of the DAM command which gives some text description like e.g. "burns" or "hits %s terribly with darkblade.". Just saying 'Foo damages bar for 5 points' sounds a little bland. Carl Edman From crossfire-request Thu Apr 14 20:08: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 ; Thu, 14 Apr 1994 20:08:57 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id LAA21520 for crossfire@ifi.uio.no; Thu, 14 Apr 1994 11:08:53 -0700 From: Philip Brown Message-Id: <199404141808.LAA21520@soda.berkeley.edu> Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Thu, 14 Apr 1994 11:08:50 -0700 (PDT) In-Reply-To: <9404141441.AA07188@capitalist.princeton.edu> from "Carl Edman" at Apr 14, 94 10:41:54 am X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1293 Status: RO >>>>[From Carl Edman] Maybe I'm a little slow today. A player with axes reversed will either see a mirror image world or a world rotated by 180 degrees. But such a world makes perfect internal sense. Nope. Actually, some multiple-square constructs (like shops, and "big_wiz") depend on axes being the "proper" way. Here I disagree. What you are proposing is just a variation of the client-side LOS scheme ... :-P OK, let me propose a compromise. The server will not know or care what kind of color hardware the client has. However the client can REQUEST not just PIX and SND types, but can request the types BW1, BW2, BW3, .. BW8 to receive black and white XPMs of one to eight bit planes and CO1 to CO8 to receive color XPMs of one to eight bit planes per color. To use one of your arguments back at you.. do you _really_ want to "support" 8 different kinds of display for each and every item face? that's a lot of (anoying and unneccessary) work. 8-bit greyscale systems have default dithering from color to what they have got. less capable systems will have to deal with black-and-white. It's their fault for buying inadequate hardware. [Ergo, I say, "color", or "b&w" selection only, just to be explicit.] From crossfire-request Thu Apr 14 20:00:00 1994 Return-Path: Received: from welch.ncd.com (root@welch.ncd.com [192.43.160.250]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 19:59:58 +0200 Received: from hemlock.ncd.com (root@hemlock.ncd.com [138.43.112.23]) by welch.ncd.com (8.6.8.1/8.6.6) with ESMTP id KAA15549 for ; Thu, 14 Apr 1994 10:59:55 -0700 Received: from localhost.ncd.com (lemke@localhost.ncd.com [127.0.0.1]) by hemlock.ncd.com (8.6.5/8.6.5.Beta11) with SMTP id KAA22734 for ; Thu, 14 Apr 1994 10:59:54 -0700 Message-Id: <199404141759.KAA22734@hemlock.ncd.com> X-Authentication-Warning: hemlock.ncd.com: Host localhost.ncd.com didn't use HELO protocol To: crossfire@ifi.uio.no In-reply-to: Message from "Carl Edman" of Thu, 14 Apr 1994 00:11:11 EDT. Organization: Network Computing Devices, Mountain View, CA Reply-to: lemke@ncd.com Subject: Re: ASCII vs binary - holy war... Date: Thu, 14 Apr 1994 10:59:53 PDT From: Dave Lemke Status: RO From: "Carl Edman" Date: Thu, 14 Apr 94 00:11:11 -0400 > So, tell me, what's the point in using ASCII? I've given the long list a number of times. Please re-read the articles. the CPU spent by the client's parsing probably will be dwarfed by its graphic display -- but the server will be doing a lot of it too. fixed-length blocks will be the most common, since most of them will be simple MOVE commands. the compressors won't work any better on ascii than binary -- it'll see the same patterns in both. but with binary it has less data to paw over. All that I can add is that I actually went and wrote a binary protocol for a game like crossfire and a client and a server for it. My aversion to binary protocols stems from that real world experience. and my appreciation of them from also comes from real-world experience. and i actually implemented the binary protocol for the X font server, numerous X extensions, and am currently at work on the protocol for Low Bandwidth X. i've spent much of the last year worrying about how to make network protocols work well over low speed/high latency links. i think you're over-estimating the difficulty in writing a binary protocol that doesn't run into padding or byte order problems. your worries about bugs will happen no matter what -- the choice of a network format will have a minimal impact on the support problems of the overall product. as i see it, the best argument you have for using ascii is that its easier to debug, and you are willing to accept slowdowns everywhere else, assuming they'll be in the noise, for the small help in debugging ascii provides. in the overall picture, the protocol format probably won't even matter. but i hate to see a choice made on what i feel are bogus grounds. From crossfire-request Thu Apr 14 19:50: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, 14 Apr 1994 19:50:30 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id KAA16640 for crossfire@ifi.uio.no; Thu, 14 Apr 1994 10:50:27 -0700 From: Philip Brown Message-Id: <199404141750.KAA16640@soda.berkeley.edu> Subject: Re: ASCII vs binary - holy war... To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Thu, 14 Apr 1994 10:50:26 -0700 (PDT) In-Reply-To: <9404140411.AA06634@capitalist.princeton.edu> from "Carl Edman" at Apr 14, 94 00:11:11 am X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 870 Status: RO >>>>[From Carl Edman] > No conversion is necessary, unless the byte order is different (and > it's easy to handle that case). Or if the padding is different or if data sizes are different. Can it be done by a staff of experienced network programmers who are willing to devote significant amounts of time debugging (not an enjoyable experience in any environment) for free just to find an elusive client bug ? Sure. Do we have such a staff i.e. people who have actually designed and implemented network protocols before _and_ are willing to debug DOS clients ? I don't think so. I'd like to point out that 1) we have made no commitment to "support" a DOS client 2) we don't have to 3) whoever says they're going to write one wil have the job of supporting it 4) no one has commited to writing one From crossfire-request Thu Apr 14 19:45:29 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, 14 Apr 1994 19:45:25 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id KAA15370 for crossfire@ifi.uio.no; Thu, 14 Apr 1994 10:45:22 -0700 From: Philip Brown Message-Id: <199404141745.KAA15370@soda.berkeley.edu> Subject: Line-of-sight, still To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Thu, 14 Apr 1994 10:45:20 -0700 (PDT) In-Reply-To: <9404140335.AA06570@capitalist.princeton.edu> from "Carl Edman" at Apr 13, 94 11:35:40 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1774 Status: RO [Note: I actualy changed the Subject: line to keep it relevant! Ooooooo.... AAaahhhh......] >>>>[From Carl Edman] Again, I disagree. We have been over this terrain three or four times already in the last few days, but I guess I'm the only one who actually reads all the articles (it helps in replying). Having LOS done on the client side both costs you huge latency every time you enter or leave a map even if you only move a few squares in it and requires the constant transmission to the client the location of every single moving monster in the entire map even if the player is standing still. Where did you get this??? You only have to transmit things that chnge in the 11x11 part of the map. People who have chhacked their client to "see a larger area" wil be able to see where they are relative to other things (which I think is a wonderful idea). However, their actual character can only physically see 5 squares ahead, so that's what they get updates for. "monster-rich" maps have the same liability as just moving without using scroll buffering (which is what we've been doing all along, so far), so we don't make anything unplayable. The "unplayable" argument is bogus, because even with LOS on server, you still have to deal with a big open are without walls. If that is "unplayable", then you lose anyway. If you're that paranoid about cheating, you can always add #define PARANOID_SERVER_GOD 1 #define BUTCH_SERVER 1 and hve the server only send LOS stuff instead of the whole 11x11 automaticaly. Remember that it will require a diffrent set of movement update routines. It will have to black out, and unblack, squares, just becaus the player moved, not because anything on the map actually changed. From crossfire-request Thu Apr 14 19:28:39 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, 14 Apr 1994 19:28:31 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id KAA11207 for crossfire@ifi.uio.no; Thu, 14 Apr 1994 10:28:28 -0700 From: Philip Brown Message-Id: <199404141728.KAA11207@soda.berkeley.edu> Subject: Re: images and maps To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Thu, 14 Apr 1994 10:28:26 -0700 (PDT) In-Reply-To: <9404131858.AA06176@capitalist.princeton.edu> from "Carl Edman" at Apr 13, 94 02:58:25 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 2576 Status: RO >>>>[From Carl Edman] First of all, note that I insisted on two independent channels in the protocol (for this very reason, among others). Even if the server->client connection is clogged up with large image transfers, the client->server connection is not affected. That means that you _never_ "freeze". But you won't be able to see what you're fighting, until the update is completely. This is crucial. if you knew you were fighting a rust monster, instead of some generic_monster, you would run away, not stay and fight. Then, it is also a matter of map design. Already I believe it is considered quite bad form to place aggressive and dangerous monsters right next to a map entrance because it tends to lead to fatalities even now. Doesn't matter. monsters follow players to the exit, making deadly "traps" for the next person through. In either the hang situation, or th generic_monster situation, a player is going to be very pissed at the design eventually. Just because a problem occurs infrequently does not make it a non-problem. > Anything that requires , or > COULD require, mass loading of data , should be done one time only, > at startup time. (and then never again, until the server gets > updated) But servers are going to be run by us hackers -- there are going to be almost continuous updates. This scheme will transmit many times more images than most players will ever see, more times than any player needs to have them transferred (once) and then compounds its sin by doing the transfer in the way most painful for players by resulting in long pauses rather than tiny unnoticeable delays during play. But they are NOT unnoticable. Personally, I do not intend playing on a "hacker" server much, and I suspect neither will most other people. Too unstable, and you don't get to skip loading in this fasion. Ah, but I thought that there was something of a consensus now that we can not assume control over the clients and that telling something to the client is morally equivalent to tell it to the user. That was the main argument for server-side LOS. What's so bad about showing them pixmaps where's the cheat? It's not like they even have names to them?! BTW: about the MAp thing... you might want to incorprate a vertical mode, for left-right scrolling. eg: MAP 0,-1 id id id id id id Or, if we start the indexes at 1, it would be a little nicer to do MAP 1,0 id id id id id ... From crossfire-request Thu Apr 14 19:26:02 1994 Return-Path: Received: from welch.ncd.com (root@welch.ncd.com [192.43.160.250]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 19:25:58 +0200 Received: from hemlock.ncd.com (root@hemlock.ncd.com [138.43.112.23]) by welch.ncd.com (8.6.8.1/8.6.6) with ESMTP id KAA13417 for ; Thu, 14 Apr 1994 10:25:53 -0700 Received: from localhost.ncd.com (lemke@localhost.ncd.com [127.0.0.1]) by hemlock.ncd.com (8.6.5/8.6.5.Beta11) with SMTP id KAA21581 for ; Thu, 14 Apr 1994 10:25:52 -0700 Message-Id: <199404141725.KAA21581@hemlock.ncd.com> X-Authentication-Warning: hemlock.ncd.com: Host localhost.ncd.com didn't use HELO protocol To: crossfire@ifi.uio.no In-reply-to: Message from Mark Wedel of Thu, 14 Apr 1994 02:57:49 PDT. Organization: Network Computing Devices, Mountain View, CA Reply-to: lemke@ncd.com Subject: Re: cheating Date: Thu, 14 Apr 1994 10:25:51 PDT From: Dave Lemke Status: RO i'm one of those who think cheating is unimportant -- people who really want to do it will probably find away around any safeguards, if only for the challenge (as most crackers will tell you). if you're really worried about it, then perhaps some form of server access control is the simplest solution. just disallow connections from users/sites/playernames that are caught cheating, and as as many of the security checks out of things like rshd that you need. From crossfire-request Thu Apr 14 17:56:42 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id ; Thu, 14 Apr 1994 17:56:41 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Thu, 14 Apr 1994 17:56:39 +0200 Date: Thu, 14 Apr 1994 17:56:39 +0200 Message-Id: <199404141556.3950.bera.ifi.uio.no@ifi.uio.no> To: cedman@Princeton.EDU CC: crossfire@ifi.uio.no In-reply-to: "Carl Edman"'s message of Thu, 14 Apr 94 10:41:54 -0400 <9404141441.AA07188@capitalist.princeton.edu> Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol Status: RO Next time, Carl, please READ my posts before replying. First - BITMAPS won't be rotated for the player, so the roof of the shop would appear beneath the door. +--- | But even a client which keeps old mapping information is allowed to | throw it away if there is a real memory crunch. The point was that the client could tell the server that it wouldn't do that in order to save bandwidth. +--- | Here I disagree. What you are proposing is just a variation of the | client-side LOS scheme with all (or at least most) the attendant | problems. WHAT? My scheme is a superset of yours. Only objects in the viewpoint are updated, and only if they have changed since they last were in the clients viewport. This can be done very efficiently in the server. No need to add flags dynamically to objects, just reserve a long word as a bitmask (max. 32 clients). Object size is currently ~250 bytes, so this doesn't make much of a difference RAM-wise or CPU-wise, but it has a tremendous effect bandwidth-wise. +--- | No side _ever_ sends binary data without the other side requesting it | first. And the REQUEST command contains a TYPE field which allows the | client to specify what kind of data it wants. That was exactly my point. When the client requests an image, the server can respond with an image type unknown to the client, and the client can do _nothing_ about it. +--- | However the client can REQUEST not just PIX and SND types, but can | request the types BW1, BW2, BW3, .. BW8 to receive black and white | XPMs of one to eight bit planes and CO1 to CO8 to receive color XPMs | of one to eight bit planes per color. Why restrict yourself to 8 bit planes? The full set of XPM's in Crossfire could use 16,777,216 colours. An individual bitmap can only use 256 of them, though. More seriously - this isn't something we need to decide now, if you just allow some sort of negotiation. And Carl, have a look at the crossfire.pix file to see that XPM is a different beast altogether from just an 8 bit colour image. (search for booze, for example) One more thing I forgot last post: You misread the meaning of my MAP extension - it should list multiple pixmaps on that coordinate! I must say I agree with Tero, though - we really don't want to go back to .om. I revise my standpoint, and suggest MAP currently, will only have two meanings, 0 (corresponds to UNMAP) and 9. When we get light sources later, we can send other numbers. Many clients could map all values > 0 to 9, ie. no shading. Okay, with all that said, perhaps a little on where I agree with you? :) ITEM commands are a nice, general approach to it, especially after you said that animation sequences is just another sort of image. BTW, I think there should be a protocol response for damage. DAM That way a client can present it graphically, not just spew out a stream of text. Since the client knows the names, it can make up the text itself if it wishes to. Kjetil T. From crossfire-request Thu Apr 14 17:41:35 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 17:41:19 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA21463; Thu, 14 Apr 94 11:41:06 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA07288; Thu, 14 Apr 94 11:37:18 -0400 Date: Thu, 14 Apr 94 11:37:18 -0400 From: "Carl Edman" Message-Id: <9404141537.AA07288@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: cheating Reply-To: cedman@Princeton.EDU Status: RO Mark Wedel writes: > Back some on pickup: Implementing it might be possible to do on the > client, but this means the clients needs to have more information. In > addition to the fairly straight forward pickup modes (0-5), there is > pick up all known magical and all gems/coins. Then there is pickup > based on value density. What I was thinking of were pickup modes based on name regexps with couple of regexps which pick up e.g. all coins and gems and everything marked as magical built in. People could use those and advanced players could write their own regexps. > However, I do not know if this is any better than the client just > sending a request to the server of something like 'pickup (x) (y) > mode (z)'. Sure, it can be done. But one advantage of client/server is that the server can be at least somewhat simplified by moving out whatever can be moved out. > This is because one reason that was suggested for client pickup was > so that new pickup modes could be added on the client side. However, > if the pickup is based on something that is not mentioned above (ie, > magical plus of weapons), then the server would just need to be > changed to update on the client side. So new pickup modes for the > client could not easily be made unless that pickup mode only uses > data that is transmitted. Well, to pick up items with identified magic pluses, just use a regexp like this '+[1234]'. > It might be a good idea to have the client state what level of detail > it wants. This, someone running on a slow link could have the client > just get the bare mininum number of objects (floor and top object), > and any time more detail is needed, it makes that request to the > server (like, to see what might be in a stack.) But clients on a > fast link could specify a high detail level, getting every object, > plus value, magical, etc. No, please don't. Not sending all the items based on purely graphical concerns destroys the abstraction around which I designed the proposed protocol and which I firmly believe is both a good and an interesting one. Plus value and magical doesn't safe you much in any case -- it is just a few bytes in the name which is only transmitted when an ITEM moves and even then not necessarily as all the ITEM fields except for tag, x and y are optional for an ITEM which the server knows is already known to the client. Carl Edman From crossfire-request Thu Apr 14 17:31:32 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 17:31:27 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA19876; Thu, 14 Apr 94 11:31:10 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA07261; Thu, 14 Apr 94 11:27:23 -0400 Date: Thu, 14 Apr 94 11:27:23 -0400 From: "Carl Edman" Message-Id: <9404141527.AA07261@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: A few thoughts on client/server Reply-To: cedman@Princeton.EDU Status: RO Tero Haatanen : > About doing animation in client is partical solution only. Most alive > objects moves around so animating those in client side don't help, > since you have update them anyway. So objects which can be animated > on client side are backgrounds (currently 3) and normal objects (e.g. > diamonds and so, currently about 50). If client animates these, it > helps server side. Note that alive object's animation can have a > real meaning, like different animation of wizard, when he concentrate > to cast a spell, director turning around and so on. So maybe there > should be two types animations on server side, first done by client > and second done be server. Absolutely. If an animation actually means something, it has to be done on the server side. When I said animations I was thinking exclusively of aesthetic repeating patterns (like waves, or fire, or darkblade). Those I believe are both much more frequent and happen much faster. All of that is handled with relative ease by the proposed protocol. The only case which is really worrisome are spikes because they both have meaning _and_ they are constantly and quickly repeating. A couple of spikes could really load a slow connection. > One point about Carl Edman's protocol is that it makes difference > between backgrounds and objects and that doesn't make sense. Does > that mean that background objects don't have same properties that > other objects? And what are these terrrains? Floors? Floors and > walls? If walls does it count weak walls? And so on. I think it's > not worth it. Yes, MAPs lack one extremely important property which ITEMs have -- they can't move. Also in most places they are considerably more plentiful. Over time I've come to the conclusion that this is a real fundamental distinction and so I think have the designers of crossfire. However, if you don't agree just view the distinction as a performance optimization. As things are now, MAPs don't need a name, a quantity or a tag and you can have any number in one single command. That will probably give you real performance increases. > And there isn't anywhere seen requirements how long client have to > keep items in the memory. Does UNMAP mean that client can delete this > square totally and server sends it again or does client have to keep > all places in memory where player is visited or so only to next CLEAR > command? The proposed protocol says: "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). 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." I take that to mean that a client may do whatever it wants when it receives an UNMAP statement. It may delete all memory of the square in question as the server is going to send it again when it enters the LOS again in any case or it may keep it around as a sort of automatic map drawing for the player. > Note that client really shouldn't been aware which physical > map player is, although it probably knows it. Think something like > current world maps, client don't need to know which physical map is > in question. I agree. However, that is a crossfire server decision and I'm in too many discussion in this group right now in any case to want to open up another can of worms. > One thing which makes hard to send just updates in visible items is > that server has to remember all things what it has been send to every > player in the game. With 10 players and big map this is quite much of > memory to keep tracked. Not really. The server (as I would write it though that really is protocol independent) just keeps a set of all the squares which are in the LOS of each player. That should be less than 1k. As an item enters or leaves a square in that set, the server generates an ITEM command. As the set changes, all items in squares which enter the set are sent to the client (no need to worry about items in squares which leave the set -- the client is assumed to understand that items in UNMAPed squares are no longer visible). Even chosing an implementation which sacrifices compactness for speed (as one probably should) that will be less than 1kByte/player. > I prefer Kjetil's idea that client tells how many stacked objects > client wants and server send images without names. Since how many > times players click on walls to see their names? Walls are MAPs and don't have names. Only ITEMs have names. > If player wants to look at a specific square it sends command to > server ("look x y"). Server sends back a string (and maybe pixmaps) > what player see there. To paraphrase myself: Latency is evil. Latency for just _looking_ at things (rather than doing something) is doubly so. > So server can implement feature that player don't see all items if > looking from too far. If that is what you want (and it certainly sounds like a good idea), then just don't send ITEM commands for faraway small items. > I think it's also good assume that player is always in the centre of > view (currently 11x11). Maps are designed that way, so no need of > changing that. This view can be probably get up to 15x15, but bigger > that change the game too much. All maps are designed only for small > views. Maps are designed for a certain LOS. That is a server side decision. How big a view the client choses to give player is none of the business of the server. > One solution to send updates for map is that when player first time > enters to the new map, whole 11x11 (or 13x13, 15x15) area is send > player. With binary packet it makes 11 * 11 * 2 = 242 bytes > per/graphics level. Next time when view is changed server checks if > how much that byte array is changed. If it changed only little then > update packet can be send. If player moves, that array is shifted in > same direction that player moves. It would be very easy to server > remember what is send to each player since you need keep only latest > update, not whole map. Update packet use 3 bytes per location per > graphics level, so it don't even use much bandwidth. Clearly, we are talking about two entirely different kinds of client here. You are talking about a glorified VT100 which can draw graphics and play sounds but has no more brains or understanding of the world it is in than the dumbest of terminals. That is what we had until now in X which is probably the reason so many think in terms of a *graphics* protocol. There are probably some gains to be made in this area, but let me tell you that the people who designed X were not stupid. If you want to play their game and beat them at it you either have to work very very hard or imposes enormous restrictions. This is frankly something which I personally don't have the slightest bit of interest in investing my own time in writing and maintaining. What I'm thinking of is a *simulation* protocol (for lack of a better term). A protocol which doesn't consist out of instruction to draw FOO at BAR now but rather one which *describes* a world without any immediate consideration of graphical representation. Graphical representation (or the lack thereof) is a client matter. A protocol which actually allows the receiver to make rational decision about the simulated world and gain understanding about it. Carl Edman From crossfire-request Thu Apr 14 16:46:00 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 16:45:54 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA11095; Thu, 14 Apr 94 10:45:41 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA07188; Thu, 14 Apr 94 10:41:54 -0400 Date: Thu, 14 Apr 94 10:41:54 -0400 From: "Carl Edman" Message-Id: <9404141441.AA07188@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol Reply-To: cedman@Princeton.EDU Status: RO From: Kjetil Torgrim Homme > >--- Carl Edman: > > A player with the coordinate system the other way around would see > > a mirror image of the world but everything would work just for him > > as well. > > The big shops are constructed as > AB Our "backwards" friend would see CD > CD AB > Result - jumbled graphics. Direction of axes needs to be defined. Maybe I'm a little slow today. A player with axes reversed will either see a mirror image world or a world rotated by 180 degrees. But such a world makes perfect internal sense. It is just as if all the maps on the server had been rotated around. They'd still work just fine. Until the player actually talks with other players and happens to mention e.g. that the guild is north of the armour shop, he'd probably never even notice that anything is wrong (nor would the server). Nevertheless of course we _should_ define the axis directions, so that players can switch clients with a minimum of confusion and players with different clients can communicate more easily. > > [...] animation information is part of the image information and is > > handled 100% on the client side. The server nevers sends a command > > to animate something. The ITEM information is about items, not > > pixmaps. > > Well, then you should define more clearly what you mean by image > information and how you are going to handle synchronization. For many > objects, it is vital that the right frame of the animation is shown > at the right time (e.g. spikes). I think the best way may be to add a > argument to the ITEM packet. Ah, yes, I hadn't thought of spikes. I guess that means that both clients and servers will have to have good clocks and we need some clock synchronization at connection. It seems a lot of work for just the spikes, but we have to do it... > > The client is only _required_ to keep the information on the couple > > dozen squares which are in current view (though good clients will > > want to keep more around as a form of automatic map drawing). > > If the server only can assume that the objects in the current > viewport is known, it will have to send the information when the > viewport changes. If the "good" client keeps more information, it > will be of practically no use. But not at all. A client which keeps at least the MAP information also from squares which have been UNMAPed would work as an automatic mapper which is judging from its popularity in many commercial game a very desireable feature to many players. > A little arithmetic: For every object, the client will need tag, > animation pointer, name pointer, X and Y coordinates -- roughly 16 > bytes. I just went into "Andreas living apartment", the largest and > most computing intensive map I know of, and Crossfire reports 7571 > objects. That's 128kB. All in all, I think a client can keep all its > state for a map in under a megabyte. That really does sound like quite a lot. But even a client which keeps old mapping information is allowed to throw it away if there is a real memory crunch. When an object enters the viewport again, the server will send the MAP and ITEM information again in any case. > Okay, onto my goofups. I repeatedly said "stateless client". I > actually meant "stateless server" - a server which doesn't need to > know what information the client has. In the strictest sense, this is > unusable. According to Carl, the server assumes the client knows > everything about the objects visible. The state for each client in > the server is then small - basically a pair of coordinates. A stateless server is something I'd like to see as well. However I suspect that in the interest of server CPU efficiency (and without any impact on the protocol) the server will want to keep a list (or some other structure) of all the squares which are in the LOS of the player. The client will probably want to do the same (well, for it is just the list of all coordinates for which it has received a MAP but not yet an UNMAP). > Let's say the client keeps all map info, which should be possible for > even low-end PC's and Mac's (4 MB is minimum configuration these > days, and they have at least that amount in virtual memory). The > server keeps a bit in every object for each client saying whether > it's up-to-date. If the object moves or its name changes, the flag > word(s) are set to 0. When the object comes into view for a client, > the flag is consulted, and if it not set, an ITEM message is sent. > > If there are no moving objects on the map, the only thing on the wire > is one MOVE and one ITEM every time the player moves. Here I disagree. What you are proposing is just a variation of the client-side LOS scheme with all (or at least most) the attendant problems. I thought that of clients which keep UNMAPed squares for automatic map drawing and other convenience, but never really rely on it. > >--- > > I don't think we should negotiate colors. Colors are up to the > > client side. Please try not to think purely in terms of current X > > hardware -- there are machines with one million and one different > > kinds of color hardware. And in every case the client knows far > > better how to make use of it than the server will. The server > > gives the client full information and the client makes use of it as > > best it can without any server interference. > > First, I am _not_ "purely thinking in terms of current X hardware" - > why make such accusations? Always, always, always leave room for > future expansion in the protocol. As your protocol stands, the server > can send data of unknown types to the client, but the client has no > way of telling the server that it doesn't understand them. No side _ever_ sends binary data without the other side requesting it first. And the REQUEST command contains a TYPE field which allows the client to specify what kind of data it wants. > If you want to give the client full information, the only alternative > is the XPM-format. One colourful XPM-file uses ~900 bytes, gzip can > reduce that ~300. Compare this to sending the raw colour data (a > palette with 32 colours is preset): 24*24*5/8 = 360 bytes > (uncompressed, but still... and I set out to prove the superiority of > raw data :-) > > In any case, a raw monochrome image is just 72 bytes. 300 bytes takes > one sixth of a second to transmit with a 14.4 modem. (assuming no > overhead from SLIP - hah!). 72 bytes takes one 25th. > > Note that you cannot make monochrome images from raw colour data. OK, let me propose a compromise. The server will not know or care what kind of color hardware the client has. However the client can REQUEST not just PIX and SND types, but can request the types BW1, BW2, BW3, .. BW8 to receive black and white XPMs of one to eight bit planes and CO1 to CO8 to receive color XPMs of one to eight bit planes per color. The client is not required to always REQUEST the same type even within a session. The server may either have all images stored in all image formats (unlikely) or it may just keep a few representative XPMs (like BW1 and CO8) and generate the rest as needed in whatever manner it believes best. Carl Edman From crossfire-request Thu Apr 14 16:41:05 1994 Return-Path: Received: from cc.lut.fi (hevi@cc.lut.fi [157.24.15.37]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 16:41:05 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id RAA09697; Thu, 14 Apr 1994 17:41:03 +0300 Date: Thu, 14 Apr 1994 17:41:02 +0300 (EETDST) From: Petri Heinil{ Subject: Re: cheating To: crossfire@ifi.uio.no In-Reply-To: <199404132114.OAA09472@soda.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 14 Apr 1994, Peter Mardahl wrote: >Part of the reason that I'd like to see LOS done on the >client is that it would be nice to have a larger display, >as large as your client could handle computationally. No. >That isn't to say I wouldn't mind the game display to be larger than >11x11. But it should be the same size for all clients. And yes. As a mapmaker I design the maps in that manner there is 5 square space between places the player can go and the border. This gives the better feel of continuing world. If the client vision is changing it crashes the design principles. The vision have to be fixed in every client (X/PC/Mac) ! And, I think, the server builder should be capable to make other kind of visual effects like LOS also. For example the proposed shadowig (that's good ... I played doom also :), or like blindness or hallucination. -- The Page -- From crossfire-request Thu Apr 14 16:08:32 1994 Return-Path: Received: from dyggve.ifi.uio.no (2102@dyggve.ifi.uio.no [129.240.78.20]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 16:08:32 +0200 From: =?iso-8859-1?Q?H=E5vard_Lindheim?= MIME-Version: 1.0 Received: (from haavarl@localhost) by dyggve.ifi.uio.no ; Thu, 14 Apr 1994 16:08:30 +0200 Date: Thu, 14 Apr 1994 16:08:30 +0200 To: crossfire Subject: subscribe announce Message-ID: Status: RO From crossfire-request Thu Apr 14 16:08:19 1994 Return-Path: Received: from dyggve.ifi.uio.no (2102@dyggve.ifi.uio.no [129.240.78.20]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 16:08:19 +0200 From: =?iso-8859-1?Q?H=E5vard_Lindheim?= MIME-Version: 1.0 Received: (from haavarl@localhost) by dyggve.ifi.uio.no ; Thu, 14 Apr 1994 16:08:17 +0200 Date: Thu, 14 Apr 1994 16:08:16 +0200 To: crossfire Subject: subscribe Message-ID: Status: RO From crossfire-request Thu Apr 14 16:04:27 1994 Return-Path: Received: from hilja.it.lut.fi (haatanen@hilja.it.lut.fi [157.24.21.72]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 16:04:23 +0200 Received: from localhost (haatanen@localhost) by hilja.it.lut.fi (8.6.5/8.6.5/1.12.kim) id RAA12545; Thu, 14 Apr 1994 17:04:21 +0300 (for crossfire@ifi.uio.no) From: Tero Haatanen Message-Id: <199404141404.RAA12545@hilja.it.lut.fi> Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol To: crossfire@ifi.uio.no Date: Thu, 14 Apr 94 17:04:20 EET DST In-Reply-To: <199404140615.1728.bera.ifi.uio.no@ifi.uio.no>; from "Kjetil Torgrim Homme" at Apr 14, 94 8:15 am X-Mailer: ELM [version 2.3 PL11] Status: RO From: Kjetil Torgrim Homme > Phew, this will probably be long. If my previous mail wouldn't be delayed because of local network problems, we probably haven't repeat the same things :). I must say that I agree with most things. The major thing I disagree is that client should get only images, not object data. (exclude object names below player). How random objects are implemented (rune is invisible half of time). And most this information is mostly useless, names of all no_pick items including monsters, walls and so on. And examining squares not below player is not very frequently used action. And making diffence between background and objects creates and old problem that eartwall is object but wall isn't. Back to .oo and .om files :( Objects data of items in players inventory is totally different story, this client of course knows. The protocol main purpose is to get servers world to players, not making it easy to build robots. I don't want to start discussion if admins should allow robots or not (go rec.games.mud.admin if you want opinions on that ;) > [Animation synchronization] Let client do dump animation and leave smart ones to server and send only images [see my last mail]. > All in all, I think a client can keep all its state for a map in > under a megabyte. Hmm, DOS programmers loves allocating big memory arrays :) > Let's say the client keeps all map info, For one map or ALL maps? Players change maps quite active, keep that in mind. > The server > keeps a bit in every object for each client saying whether it's > up-to-date. If the object moves or its name changes, the flag word(s) > are set to 0. When the object comes into view for a client, the flag > is consulted, and if it not set, an ITEM message is sent. This is the first solution what I see this problem, but it really consumes servers memory and CPU time. The each object has to be flag for each player and these must be dynamically allocated and updated everytime that someone moves. Probably this overhead is not a problem. How about if client remembers it's current view and server remembers last view it send to server. It would make much easier to implement server side (save CPU time) and wouldn't require client to keep big arrays. After view changes server check how many squares are changed (after LOS calculation). If there is no changes even player moves (walks in jungle and see only 9 jungle square and everything else in black) nothing is send. Also walking in the long corridor wouldn't need any updates. This adds little more traffic if player moves in same map, but saves traffic in battles (much updates in objects). > Like Carl said, a larger viewport is possible, but only the closest > 11x11 (or whatever the default viewport size is - I vote we go for > 13x13) will get updated. Agreed here, but maybe client could select one of 11x11, 13x13 or 15x15? 15x15 could be nice if server implements moving light sources. And this is one point more point to do LOS calculation in server side (some servers might use it while others not). Fixed size might still better when thinking xrays and other map features. -Tero From crossfire-request Thu Apr 14 16:07:47 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 16:07:45 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA04795; Thu, 14 Apr 94 10:07:40 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA07111; Thu, 14 Apr 94 10:03:52 -0400 Date: Thu, 14 Apr 94 10:03:52 -0400 From: "Carl Edman" Message-Id: <9404141403.AA07111@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: cheating Reply-To: cedman@Princeton.EDU Status: RO From: Mark Wedel > Where as if LOS is handled on server, only those visible objects need > to be sent. The client should buffer that information, so if the > player moves, only a new row and/or column needs to be drawn. The updated number of map fields will not necessarily be in a row or a column due to LOS. That is why the proposed MAP command allows you to give the location for every square which is newly mapped in. If it turns out that they are frequently enough rows or columns, I'm certainly not opposed to making a little optimization which allows the transmission of such mapping information without having to give _all_ the coordinates. > In general, for most maps, not a lot of objects move in the game > window at the same time, so the updates shouldn't be that bad. Absolutely. And objects which don't move only get a single ITEM command when they come into view and then never again. They are essentially free. > However, what gets more complicated is smart updates. IF you are > fighting 20 gnolls, and kill the one in front, and another one > quickly steps up (and thus, lots of gnolls change position), do you > necessarily want to re-send the position of all 20 gnolls? It might > be much better just to remove one gnoll from the mass.0 However, > under the current protocol, this would not be possible, as all > objects are tagged with an ID number, and if this method was used, > all the ID numbers would be off. But I am not sure how much the ID > numbers are used for monsters. This is really not a case worth worrying about for three reasons: (1) Even sending ITEM commands for all twenty gnolls in the ASCII format takes only 580 bytes. That is compressed down to 137 bytes by gzip. While V.42bis is slightly less effective, it'd have more context to work with so you can expect similar results there. Sending 137 bytes even over the slowest acceptable link takes 70-140 ms. That's certainly acceptable. And on an ethernet it'd take merely a fraction of a millisecond. (3) Because of LOS considerations, you wouldn't see all twenty gnolls which are in a line anyway further shortening display time. If the gnolls are not all in a line, not all will make a step when you kill one. (3) Due to the bidirectional nature of the proposed protocol even during those milliseconds that you get the gnoll updates, you can still move and fight. You want to run away ? No problem. You continue hacking&slashing ? It is as if the delay hadn't happend. Carl Edman From crossfire-request Thu Apr 14 11:59:16 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 Apr 1994 11:58:25 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA03436 (5.67a8/IDA-1.5 for ); Thu, 14 Apr 1994 02:57:50 -0700 Received: by bolero.rahul.net id AA00197 (5.67a8/IDA-1.5); Thu, 14 Apr 1994 02:57:49 -0700 Date: Thu, 14 Apr 1994 02:57:49 -0700 From: Mark Wedel Message-Id: <199404140957.AA00197@bolero.rahul.net> To: crossfire@ifi.uio.no, elsbernd@dfki.uni-kl.de Subject: Re: cheating Status: RO I doubt that for each new version of crossfire, a new client would be required. That means once someone has a cheater client, he is set. In fact, it would be pretty stupid to require a new client with each new version of crossfire. IT has suggested that there could in fact be several clients (mac, PC, unix), with each of these platforms perhaps having different clients (on unix side, some may be simple and straight Xlib calls. Other may be motif based, athena widget, etc.) The person who installs the client can always cheat - that is not an issue. The issue is really to prevent some remote user from cheating and ruining the fun for everyone else. Most people may only want to play, but it only takes a few cheaters to ruin the fun. As I see it, LOS could either be handled on the client or server. A cheater client with LOS may not gain a lot, depending on the size of the game window and the maps. However, what is more important is reducing the traffic. Handling LOS on the client does not necessarily reduce the server->client traffic - you need to send all the objects, with a fair amount of detail so the client knows if they block view, plus any changes anywhere in the game window of the map, even if it is not visible. Where as if LOS is handled on server, only those visible objects need to be sent. The client should buffer that information, so if the player moves, only a new row and/or column needs to be drawn. In general, for most maps, not a lot of objects move in the game window at the same time, so the updates shouldn't be that bad. However, what gets more complicated is smart updates. IF you are fighting 20 gnolls, and kill the one in front, and another one quickly steps up (and thus, lots of gnolls change position), do you necessarily want to re-send the position of all 20 gnolls? It might be much better just to remove one gnoll from the mass. However, under the current protocol, this would not be possible, as all objects are tagged with an ID number, and if this method was used, all the ID numbers would be off. But I am not sure how much the ID numbers are used for monsters. --Mark From crossfire-request Thu Apr 14 09:23:24 1994 Return-Path: <<@isg-204.dfki.uni-kl.de:elsbernd@dfki.uni-kl.de>> Received: from uni-kl.de (mmdf@stepsun.uni-kl.de [131.246.136.50]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 09:23:22 +0200 Received: from isg-204.dfki.uni-kl.de by stepsun.uni-kl.de id aa03165; 14 Apr 94 9:23 MET DST Received: from dfki.uni-kl.de (isg-201.dfki.uni-kl.de [131.246.241.71]) by isg-204.dfki.uni-kl.de (8.6.4/8.6.4) with ESMTP id JAA04375; Thu, 14 Apr 1994 09:23:19 +0200 Message-Id: <199404140723.JAA04375@isg-204.dfki.uni-kl.de> To: crossfire@ifi.uio.no, elsbernd@dfki.uni-kl.de Subject: Re: cheating In-reply-to: Your message of "Wed, 13 Apr 1994 18:48:48 MET DST." <9404140148.AA01770@axys69.nwest.mccaw.com> Date: Thu, 14 Apr 1994 09:23:17 +0200 From: Klaus Elsbernd Status: RO That's only my five silver coins on that. I think most of people who care about cheating, overestimate that. If don't change the program, yet you can cheat. If someone wants to change the client, he should do that. He could change the server too, if he installs his private version. In the next version of crossfire at least, he has to redo some of the work. And if the people try to cheat by modifying the client, most of them will recognize, that tey don't have the skills to do that. On the other hand, in the next version of crossfire they have to redo some of the work (ok: one goal of writing the client is to disconnect the developing of the client from the development of the server. But that's only part of the story and depends i.e. on how frequently there is a need to change the protocoll. Most of the new versions of crossfire will come with a new version of the client) If LOS should be on the client, because it reduces the load on the server, we should do so. And that should be the argument. The possibility of cheating is not an argument. I think most of the people only want to play. MfG Klaus From crossfire-request Thu Apr 14 08:15:04 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 08:15:03 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Thu, 14 Apr 1994 08:15:02 +0200 Date: Thu, 14 Apr 1994 08:15:02 +0200 Message-Id: <199404140615.1728.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: "Carl Edman"'s message of Wed, 13 Apr 94 08:02:01 -0400 <9404131202.AA04998@capitalist.princeton.edu> Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol Status: RO Phew, this will probably be long. +--- Carl Edman: | A player with the coordinate system the other way around would see a | mirror image of the world but everything would work just for him as | well. The big shops are constructed as AB Our "backwards" friend would see CD CD AB Result - jumbled graphics. Direction of axes needs to be defined. +--- | [...] animation information is part of the image information and is | handled 100% on the client side. The server nevers sends a command | to animate something. The ITEM information is about items, not | pixmaps. Well, then you should define more clearly what you mean by image information and how you are going to handle synchronization. For many objects, it is vital that the right frame of the animation is shown at the right time (e.g. spikes). I think the best way may be to add a argument to the ITEM packet. +--- | The client is only _required_ to keep the information on the couple | dozen squares which are in current view (though good clients will | want to keep more around as a form of automatic map drawing). If the server only can assume that the objects in the current viewport is known, it will have to send the information when the viewport changes. If the "good" client keeps more information, it will be of practically no use. A little arithmetic: For every object, the client will need tag, animation pointer, name pointer, X and Y coordinates -- roughly 16 bytes. I just went into "Andreas living apartment", the largest and most computing intensive map I know of, and Crossfire reports 7571 objects. That's 128kB. All in all, I think a client can keep all its state for a map in under a megabyte. Okay, onto my goofups. I repeatedly said "stateless client". I actually meant "stateless server" - a server which doesn't need to know what information the client has. In the strictest sense, this is unusable. According to Carl, the server assumes the client knows everything about the objects visible. The state for each client in the server is then small - basically a pair of coordinates. Let's say the client keeps all map info, which should be possible for even low-end PC's and Mac's (4 MB is minimum configuration these days, and they have at least that amount in virtual memory). The server keeps a bit in every object for each client saying whether it's up-to-date. If the object moves or its name changes, the flag word(s) are set to 0. When the object comes into view for a client, the flag is consulted, and if it not set, an ITEM message is sent. If there are no moving objects on the map, the only thing on the wire is one MOVE and one ITEM every time the player moves. Of course, if we want to, we can on a per client basis reset the flag whenever an object exits that client's viewport. SETF ONLY_KEEPS_VIEWPORT or somesuch. +--- | I don't think we should negotiate colors. Colors are up to the | client side. Please try not to think purely in terms of current X | hardware -- there are machines with one million and one different | kinds of color hardware. And in every case the client knows far | better how to make use of it than the server will. The server gives | the client full information and the client makes use of it as best | it can without any server interference. First, I am _not_ "purely thinking in terms of current X hardware" - why make such accusations? Always, always, always leave room for future expansion in the protocol. As your protocol stands, the server can send data of unknown types to the client, but the client has no way of telling the server that it doesn't understand them. If you want to give the client full information, the only alternative is the XPM-format. One colourful XPM-file uses ~900 bytes, gzip can reduce that ~300. Compare this to sending the raw colour data (a palette with 32 colours is preset): 24*24*5/8 = 360 bytes (uncompressed, but still... and I set out to prove the superiority of raw data :-) In any case, a raw monochrome image is just 72 bytes. 300 bytes takes one sixth of a second to transmit with a 14.4 modem. (assuming no overhead from SLIP - hah!). 72 bytes takes one 25th. Note that you cannot make monochrome images from raw colour data. +--- Peter Mardahl: | The current little display is kinda small, in my opinion, and I'd | like to see the freedom in the design of the client to make the | display larger..... Like Carl said, a larger viewport is possible, but only the closest 11x11 (or whatever the default viewport size is - I vote we go for 13x13) will get updated. In Xpilot, you can make the window as large as you like. This has the affect that people on large displays (1280x1024 or even 1600x1280) have a MAJOR advantage over those using lowly terminals with 1024x768, especially in tournament maps. (This design decision in Xpilot is even sillier when you consider that it uses vector graphics and therefore easily could scale the graphics according to display size.) +--- Philip Brown: | Plus, what if some pixmaps got updated to "nifty k00l knew 1s", and | the client doesn't know about it? The user would never know to | request the new version. We could modify Scarrow's proposal. During lulls in network traffic, the client could ask for checksums of (individual) images, and would then request the images which didn't match its own checksums. The client should remember when it last checked, of course. That way, an intelligent client would have updated pixmaps after a day or so. Kjetil T. From crossfire-request Thu Apr 14 07:35:00 1994 Return-Path: Received: from eden-valley.aaii.oz.AU (eden-valley.aaii.oz.AU [192.35.59.254]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 07:34:20 +0200 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA19773; Thu, 14 Apr 1994 15:32:50 +1000 Date: Thu, 14 Apr 1994 15:32:50 +1000 From: "Rupert G. Goldie" Message-Id: <199404140532.AA19773@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no Subject: Re: Endless repetition (short&important) Status: RO > > I understand that it is not possible for most people to read all the > > messages all the time, but could all the posters please try to read at > > least the messages of the last few days before making a new post ? It > > would be a real help for all of us. > > Well, as a systems administrator here at PSU, along with maintaining all of > our game upgrades, plus quite a few other packages, I get a continual flood > of mail by which even the crossfire mailing list is made trivial. I think > I'd have an easier time of it if we were to move to a newsgroup. It's > easier to wade through crossfire all by itself when I'm in the mood for it > rather than wading through a huge number of unrelated articles. I don't > seem to recall any restrictions on running an alt group other than the fact > that not all sites carry them? I dunno, just an observation. > > NO NO NO NO NO NO NO NO NO ! An alt.games.crossfire is going to be worse because there will be much more low content posting. The mailing list (even though it has been high volume of late) has a pretty high signal to noise ratio. Also the things we have been discussing are about game development and it makes more sense for the developers to discuss them in a mailing list than the sewer of AltNet. If you want to read crossfire postings separately either get a mail reader which can auto-file messages for you or redirect them into a local newsgroup. If you are a sys admin you should have the priviledges to set up a local newsgroup. If you want to know how to do it properly send me some mail (and please do it properly, otherwise the list administrator is going to get bounces every time your news system screws up). As Frank mentioned when this last came up, we will be much better off getting rec.games.crossfire created rather than making an alt group now and then trying to switch to a mainstream group later. Rupert (who really is working on spell paths in the spare microseconds he can escape from work) From crossfire-request Thu Apr 14 06:54:00 1994 Return-Path: Received: from ursula.ee.pdx.edu (ursula.ee.pdx.edu [131.252.20.155]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 06:53:59 +0200 Received: from potrzebie.ee.pdx.edu by ursula.ee.pdx.edu (4.1/SMI-4.1) id AA15772; Wed, 13 Apr 94 21:55:30 PDT From: bairds@ee.pdx.edu (Scarrow) Message-Id: <9404140455.AA15772@ursula.ee.pdx.edu> Subject: Re: Endless repetition (short&important) To: cedman@Princeton.EDU Date: Wed, 13 Apr 1994 21:55:35 -0700 (PDT) Cc: crossfire@ifi.uio.no In-Reply-To: <9404140344.AA06576@capitalist.princeton.edu> from "Carl Edman" at Apr 13, 94 11:44:17 pm X-Mailer: ELM [version 2.4 PL23beta] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 847 Status: RO > I understand that it is not possible for most people to read all the > messages all the time, but could all the posters please try to read at > least the messages of the last few days before making a new post ? It > would be a real help for all of us. Well, as a systems administrator here at PSU, along with maintaining all of our game upgrades, plus quite a few other packages, I get a continual flood of mail by which even the crossfire mailing list is made trivial. I think I'd have an easier time of it if we were to move to a newsgroup. It's easier to wade through crossfire all by itself when I'm in the mood for it rather than wading through a huge number of unrelated articles. I don't seem to recall any restrictions on running an alt group other than the fact that not all sites carry them? I dunno, just an observation. From crossfire-request Thu Apr 14 06:44:02 1994 Return-Path: Received: from netcom9.netcom.com (netcom10.netcom.com [192.100.81.120]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 06:44:00 +0200 Received: from localhost by netcom9.netcom.com (8.6.4/SMI-4.1/Netcom) id VAA10515; Wed, 13 Apr 1994 21:45:09 -0700 From: huma@netcom.com (Ben Fennema) Message-Id: <199404140445.VAA10515@netcom9.netcom.com> Subject: CPU -- Ultima 8 To: crossfire@ifi.uio.no Date: Wed, 13 Apr 1994 21:45:08 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 167 Status: RO Well, last time I checked a 486 wasn't the lowest machine out there, and thats whats recommened to run Ultima 8 on... On a 386 heard its REALLY slow... *shrug* Ben From crossfire-request Thu Apr 14 06:30:46 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 06:30:45 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Thu, 14 Apr 1994 06:30:44 +0200 Date: Thu, 14 Apr 1994 06:30:44 +0200 Message-Id: <199404140430.1643.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: Peter Mardahl's message of Wed, 13 Apr 1994 21:12:10 -0700 <199404140412.VAA04255@soda.berkeley.edu> Subject: Re: newsgroup Status: RO +--- Peter Mardahl: | is anyone pursuing getting a newsgroup right now? No. If you think volume (and perhaps noise) is bad now, it is nothing compared to what it will be like as a newsgroup. Make a local mail->news gateway if you like, or learn how to filter your mail. Kjetil T. From crossfire-request Thu Apr 14 06:12:17 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, 14 Apr 1994 06:12:15 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id VAA04255 for crossfire@ifi.uio.no; Wed, 13 Apr 1994 21:12:10 -0700 Date: Wed, 13 Apr 1994 21:12:10 -0700 From: Peter Mardahl Message-Id: <199404140412.VAA04255@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: newsgroup Status: RO is anyone pursuing getting a newsgroup right now? regards, peterM From crossfire-request Thu Apr 14 06:15:13 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 06:15:05 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA19120; Thu, 14 Apr 94 00:14:58 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA06634; Thu, 14 Apr 94 00:11:11 -0400 Date: Thu, 14 Apr 94 00:11:11 -0400 From: "Carl Edman" Message-Id: <9404140411.AA06634@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: ASCII vs binary - holy war... Reply-To: cedman@Princeton.EDU Status: RO quinet@montefiore.ulg.ac.be (Raphael Quinet) writes: > It won't be easier to parse ASCII data. You will have to keep a > table with all commands and do several strcmp's to find the one > that matches. Then you will have to convert all numbers from ASCII > to binary. CPU time will not be a limiting factor for any client, even the lowliest PC or Mac. A machine which can run Ultima 8 which unlike more complicated than crossfire can parse a few fixed-format ascii characters. I'll bet you $1 that any client which does graphical display will spend less than 5% of CPU time in parsing or unparsing protocol lines. Do you take that bet ? > If you send binary data, you can have fixed-length blocks in you > packets. Each block begins with the command number on 1 or 2 bytes > (very easy to parse, you only need to use a switch statement) and > the following data is already in binary form. No, you don't have fixed length blocks. Lots of commands will require variable length even if you chose binary. > No conversion is necessary, unless the byte order is different (and > it's easy to handle that case). Or if the padding is different or if data sizes are different. Can it be done by a staff of experienced network programmers who are willing to devote significant amounts of time debugging (not an enjoyable experience in any environment) for free just to find an elusive client bug ? Sure. Do we have such a staff i.e. people who have actually designed and implemented network protocols before _and_ are willing to debug DOS clients ? I don't think so. > Binary will be much more compact. Compare the number of bytes > needed in each case for a map update, for instance. In an ASCII > packet, we will have the following things: command name (5 to 15 > bytes), newline (1 byte), first coord (2 to 4 bytes), space (1 > byte), second coord (2 to 4 bytes), space (1 byte), name of > object/picture (5 to 15 bytes), newline (1 byte), ... (repeated if > there are several objects), end marker (2 bytes). In a binary > packet, we will have: command number (2 bytes), number of objects > in the following block (2 bytes), first coord (2 bytes), second > coord (2 bytes), dynamic reference number for the object/picture (2 > bytes), ... (may be repeated), and that's all. Come on, don't tell > me that some compression protocol in CSLIP will compress ASCII 5 > times better than binary! CSLIP doesn't do that data compression. It does Van Jacobsen TCP/IP header compression which is a different thing entirely. What you mean are the V.42bis modem data compression modes. And yes, the kind of compression it does (in essence, find repeated patterns and assign tokens of various bit length according to frequency of the patterns) would recognize just the kind of redundancy which the proposed ASCII protocol has and compress it away. > ASCII won't be easier to debug. Even if you are debugging the > protocol layer, you won't enter the data by hand in real time on a > telnet connection! Why not ? I do that with all kinds of protocols almost daily. It is an almost invalueable tool. > So you will need to write a little program that sends/receives the > packets and it will be easier if the packets are in binary form, > with fixed-length blocks. No, you won't. And the blocks (as you implicitly admit in the above paragraph) will not be fixed length in a binary protocol either. > If we want to have CrossFire on MACs and PCs, the protocol must be > designed in such a way that it is: > 1) easy and fast to parse - binary is better. Parsing speed is almost insignificant compared to other tasks the client has to fulfill. > 2) compact to save bandwith - binary is better. Compression makes up for almost all of the difference and may in some circumstances even create a net-win for ASCII. Your argument reminds of the one which says that the primary goals of program design is to make it: 1) Run in as little resources as possible 2) Make it run as fast as possible So all programs should always be written in machine language. When I was younger I used to believe that. > So, tell me, what's the point in using ASCII? I've given the long list a number of times. Please re-read the articles. All that I can add is that I actually went and wrote a binary protocol for a game like crossfire and a client and a server for it. My aversion to binary protocols stems from that real world experience. Carl Edman From crossfire-request Thu Apr 14 05:51:49 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 Apr 1994 05:51:45 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA15449 (5.67a8/IDA-1.5 for ); Wed, 13 Apr 1994 20:51:34 -0700 Received: by bolero.rahul.net id AA11379 (5.67a8/IDA-1.5); Wed, 13 Apr 1994 20:51:34 -0700 Date: Wed, 13 Apr 1994 20:51:34 -0700 From: Mark Wedel Message-Id: <199404140351.AA11379@bolero.rahul.net> To: crossfire@ifi.uio.no, jason.fosback@mccaw.com Subject: Re: cheating Status: RO Actually, if LOS is done on the server, the only thing that needs to be transmitted as a player moves are the new spaces that become visible (a row and column, and perhaps some other spaces), and what squares are no longer visible. If LOS is done on the client, information needs to be transmitted that may not be used (ie, thigns around the corner, behind walls, etc). Larger maps for clients: I think that would give such clients hugh advantages. If the map was 20x20 (instead of 11x11), that is a lot more information to be seen. Assuming it is in line of sight, you will no where generators, monsters, etc are. With 11x11, sometimes you need to charge into a group of monsters to see what is around. That isn't to say I wouldn't mind the game display to be larger than 11x11. But it should be the same size for all clients. Back some on pickup: Implementing it might be possible to do on the client, but this means the clients needs to have more information. In addition to the fairly straight forward pickup modes (0-5), there is pick up all known magical and all gems/coins. Then there is pickup based on value density. There is no reason why the client could not know whether an item is magical, its value, or if its a coin. However, that is more information that gets sent down the wire. As for cheating, have some mechanism to update the objects. So, you kill a bunch of monsters that have a bunch of objects. Even if those objects are magical, the server does not tell the client so until the client player casts detect magic. The server then tells the client which of those items are magical. The same could be true for value density. Default value is assumed, but if identify is cast, then the server updates the value of the items accordingly. However, I do not know if this is any better than the client just sending a request to the server of something like 'pickup (x) (y) mode (z)'. This is because one reason that was suggested for client pickup was so that new pickup modes could be added on the client side. However, if the pickup is based on something that is not mentioned above (ie, magical plus of weapons), then the server would just need to be changed to update on the client side. So new pickup modes for the client could not easily be made unless that pickup mode only uses data that is transmitted. It might be a good idea to have the client state what level of detail it wants. This, someone running on a slow link could have the client just get the bare mininum number of objects (floor and top object), and any time more detail is needed, it makes that request to the server (like, to see what might be in a stack.) But clients on a fast link could specify a high detail level, getting every object, plus value, magical, etc. --Mark From crossfire-request Thu Apr 14 05:48:09 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 05:48:08 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA14617; Wed, 13 Apr 94 23:48:04 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA06576; Wed, 13 Apr 94 23:44:17 -0400 Date: Wed, 13 Apr 94 23:44:17 -0400 From: "Carl Edman" Message-Id: <9404140344.AA06576@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Endless repetition (short&important) Reply-To: cedman@Princeton.EDU Status: RO During the past couple days the same points have been brought up over and over and over again apparently by people who hadn't read the other messages on the same subject only a day earlier requiring reposts of the refutations. That is at least partially responsible for the recent high volume on this list. I understand that it is not possible for most people to read all the messages all the time, but could all the posters please try to read at least the messages of the last few days before making a new post ? It would be a real help for all of us. Carl Edman From crossfire-request Thu Apr 14 05:51:42 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 05:51:39 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA14113; Wed, 13 Apr 94 23:44:47 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA06573; Wed, 13 Apr 94 23:41:00 -0400 Date: Wed, 13 Apr 94 23:41:00 -0400 From: "Carl Edman" Message-Id: <9404140341.AA06573@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol Reply-To: cedman@Princeton.EDU Status: RO From: Jason Fosback > All this talk of transmitting pixmaps and maps and items and ... is > all well and good, but I'd also like to consider the possibility of > having a "smart" client. A client that has its own pixmaps (or > tiffs, or picts, or .bmp's) could just receive placement of an > item, and the client could display it. That is definitly possible under the protocol I proposed a few days ago. A client which has its own bitmaps (or which doesn't need bitmaps because it runs under curses or because it is a robot client) just uses the names given in the MAP/ITEM commands and never requests the transmission of the bitmaps from the server via REQUEST/TRANSMIT. That's all -- no magic. > The worries about cheating, I think, are unfounded. It would be easy > to cheat, no matter how you implement the client/server > architecture. Carl has already mentioned the possibility of > "robot" clients that cruise around picking things up. Your average > user wouldn't be able to do this type of thing, and probably > wouldn't care to. A robot client is IMHO not a cheat. It can do nothing which you can't do by hand. Admittedly, it may decide what to do faster than you, but it can't run any faster, hit any harder, carry more or see more than you can. A client-side LOS client is a different matter entirely. It actually gives the player capabilities which can not even theoretically be matched by any honest client. Carl Edman From crossfire-request Thu Apr 14 05:39:40 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 05:39:32 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA13539; Wed, 13 Apr 94 23:39:27 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA06570; Wed, 13 Apr 94 23:35:40 -0400 Date: Wed, 13 Apr 94 23:35:40 -0400 From: "Carl Edman" Message-Id: <9404140335.AA06570@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: cheating Reply-To: cedman@Princeton.EDU Status: RO From: Jason Fosback : > > I disagree. In any sort of a multiuser game where actions of one > > player can influence another the decision of what should reside on > > the server and what should reside on the client is critical. Why > > open up yourself to problems before they exist? LOS calculations > > are not so excrutiatingly intensive that they _must_ be farmed out > > to the clients. If my client gets object A, and thus prevents you > > from getting object A, and my client was computer controlled, you'd > > be upset. Now, I may be able to get object A before you do because > > I can see that "tile X" is really a destructable wall, or just > > because I can see the staircase leading up to the area where object > > A exists. > > Okay, but if the LOS calculations are done on the server, you have to > transmit EVERYTHING THAT'S VISIBLE, every time you move. That's just not so. Under the protocol I posted a few days ago the server is only required to send squares and items which have recently come into view (as well as noting which ones have left). > At minimum, the server would have to transmit an on-off packet > which would represent squares that're visible and squares which > aren't, along with new squares that have come into view. If the > client is aware of the map, either having it locally or via > transmission, it has all the information about the map already. The > only thing the server has to send is updates in x, y coordinates > for items and monsters. All LOS calculation and displaying of the > map is done by the client, vastly reducing the load on the server, as > well as transmission over the wire. Again, I disagree. We have been over this terrain three or four times already in the last few days, but I guess I'm the only one who actually reads all the articles (it helps in replying). Having LOS done on the client side both costs you huge latency every time you enter or leave a map even if you only move a few squares in it and requires the constant transmission to the client the location of every single moving monster in the entire map even if the player is standing still. While either algorithm will win in some cases, it is debatable which algorithm gives the better performance on average. Also it is clear that if you adopt client-side LOS we have to drop the 1-2 kBytes/second and 100-200 ms roundtrip minimum as many monster-rich maps will definitly become unplayable. In addition client-side LOS requires that the client set LOS policy. Under it would have been complete impossible to add items like the helmet of xray-vision (or different vision for different races or infravision) without changing every single client. Client-side LOS buys you all of that _and_ the cheating problem. > If there is a concern about cheaters, the sysadmin can delete a > user's character, or someone could implement a forbid-type thing > for users and/or hosts. Just don't allow cheaters to play, it's > that simple. Sure, you couldn't always detect cheating, but no one > really can all the time, can they? There is absolutely _no_ reliable way to detect client omniscience cheating unless the prepetrator actually comes out to admit it which is rather unlikely if there are any penalties (like you propose) for it. Even worse, Greshams Law applies here as well and cheating clients will drive out honest clients until LOS is completely gone from crossfire. If that is what you want, an argument can be made for it, but at least lets decide on it now before we spend lots of man-hours implementing LOS which will be discarded anyway. > It may not be really compute-intensive, but it forces more reliance > on the server to do things. We live in a distributed computing > environment with computers that are more than capable of sharing > the load of computation. So, why limit yourself so much? Especially > intentionally. It just doesn't make sense to me. For all the reasons listed above. Off loading computation to the client is a nice concept and in general I'm all for it (and I've argued quite strenously for it in other contexts here), but for LOS it just won't fly. Carl Edman From crossfire-request Thu Apr 14 05:25:16 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 05:25:15 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA10879; Wed, 13 Apr 94 23:25:07 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA06547; Wed, 13 Apr 94 23:21:20 -0400 Date: Wed, 13 Apr 94 23:21:20 -0400 From: "Carl Edman" Message-Id: <9404140321.AA06547@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: cheating Reply-To: cedman@Princeton.EDU Status: RO From: Peter Mardahl > Part of the reason that I'd like to see LOS done on the client is > that it would be nice to have a larger display, as large as your > client could handle computationally. > > The current little display is kinda small, in my opinion, and I'd > like to see the freedom in the design of the client to make the > display larger..... The protocol I proposed a few days ago allows arbitrarily large displays and makes use of them by allowing the client to keep all parts of the map it has ever seen in the display, even if LOS is done server-side. Those two issues are unrelated. All the server determines how far away an event can happen and the player still perceive it. That is a fact of the simulated world (much like the weight of items or how many spell points a fire ball costs) and as such falls under the domain of the server. > As to player killing, most server gods forbid it. I think that is a pity. Killing players should be hard and at least when done in towns have very serious in-game consequences. Also it should be not too hard to resurrect powerful players so that a potential assassin also has to consider the possible revenge of the character himself (in addition to other characters of the same player, characters of friends and automated law-enforcement "monsters"). Just making it illegal by server god fiat greatly detracts from the human interaction which makes a game like crossfire so fascinating and from at least my enjoyment of the game (even and in particular as I very rarely indeed actually would try to kill another player character). Carl Edman From crossfire-request Thu Apr 14 03:46:40 1994 Return-Path: Received: from mccaw.com (wombat.mccaw.com [192.135.191.118]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 03:46:36 +0200 Received: from nwestmail.entp.mccaw.com ([155.176.15.34]) by mccaw.com (4.1/SMI-4.1) id AA17079; Wed, 13 Apr 94 18:46:30 PDT Received: from axys69.nwest.mccaw.com by nwestmail.entp.mccaw.com (4.1/McCaw SUN-RMR Mailer, SMI-4.1) id AA27142; Wed, 13 Apr 94 18:46:28 PDT Received: from divac by axys69.nwest.mccaw.com (NX5.67d/NX3.0M, dpg hack 15oct93) id AA01770; Wed, 13 Apr 94 18:48:55 -0700 From: Jason Fosback Message-Id: <9404140148.AA01770@axys69.nwest.mccaw.com> Received: by divac.nwest.mccaw.com (NX5.67d/NX3.0X, dpg hack 20mar93) id AA01769; Wed, 13 Apr 94 18:48:48 -0700 Date: Wed, 13 Apr 94 18:48:48 -0700 Received: by NeXT.Mailer (1.100.RR) Received: by NeXT Mailer (1.100.RR) To: crossfire@ifi.uio.no Subject: Re: cheating Status: RO > I disagree. In any sort of a multiuser game where actions of one player > can influence another the decision of what should reside on the server and > what should reside on the client is critical. Why open up yourself to > problems before they exist? LOS calculations are not so excrutiatingly > intensive that they _must_ be farmed out to the clients. If my client > gets object A, and thus prevents you from getting object A, and my client > was computer controlled, you'd be upset. Now, I may be able to get object > A before you do because I can see that "tile X" is really a destructable > wall, or just because I can see the staircase leading up to the area where > object A exists. Okay, but if the LOS calculations are done on the server, you have to transmit EVERYTHING THAT'S VISIBLE, every time you move. At minimum, the server would have to transmit an on-off packet which would represent squares that're visible and squares which aren't, along with new squares that have come into view. If the client is aware of the map, either having it locally or via transmission, it has all the information about the map already. The only thing the server has to send is updates in x, y coordinates for items and monsters. All LOS calculation and displaying of the map is done by the client, vastly reducing the load on the server, as well as transmission over the wire. > They'll cheat more, they'll kill your characters with the items they got > cheating, they'll brag about solving a quest without telling you they > cheated (what, are you expecting honest cheaters only?). This works akin > to the idea that ignoring a bully will make him go away. Sorry, some > people like the attention, but some just like to make people feel pain. Sure, but taking a bully's sling-shot away doesn't mean he can't go out and get a BB gun or a two-by-four. I'm sorry, but your analogy doesn't hold water. If there is a concern about cheaters, the sysadmin can delete a user's character, or someone could implement a forbid-type thing for users and/or hosts. Just don't allow cheaters to play, it's that simple. Sure, you couldn't always detect cheating, but no one really can all the time, can they? > Move anything the player should know or that is essential to the client to > the client. LOS is not so computation expensive as to require being > embedded into the client, so don't, but since I'm not going to write it > and since I currently play crossfire about one hour per week, I don't > care. :) It may not be really compute-intensive, but it forces more reliance on the server to do things. We live in a distributed computing environment with computers that are more than capable of sharing the load of computation. So, why limit yourself so much? Especially intentionally. It just doesn't make sense to me. -jason ____________________________________________________________ Jason Fosback, Systems Engineer | No sir, I didn't like it --- Paradigm Systems Corp --- | -R&S Internet: jason_fosback@psca.com | Star Trek: NeXT mail: jason_fosback@psca.com | The NeXT Generation... From crossfire-request Thu Apr 14 03:31:11 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, 14 Apr 1994 03:31:10 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id SAA18228; Wed, 13 Apr 1994 18:31:02 -0700 Date: Wed, 13 Apr 1994 18:31:02 -0700 From: Peter Mardahl Message-Id: <199404140131.SAA18228@soda.berkeley.edu> To: bairds@ee.pdx.edu, peterm@soda.berkeley.edu Subject: Re: cheating Cc: crossfire@ifi.uio.no Status: RO Part of the reason that I'd like to see LOS done on the client is that it would be nice to have a larger display, as large as your client could handle computationally. The current little display is kinda small, in my opinion, and I'd like to see the freedom in the design of the client to make the display larger..... As to player killing, most server gods forbid it. And as to bullying, bullys can be bullys wihtout being able to cheat. It's really not too hard to kill someone from ambush in this game. I just wait for you to come, blast you with a bunch of burning hands spells, and foom, you're dead. Everyone is vulnerable to everyone else, and people who act in such a manner that others wish to avenge themselves on them will find themselves dying often no matter how high a level they are, or what they have. The invisibility spell just gives even more incentive for being nice. You wouldn't see anyone untill the icestorms started flying....... and then you're dead. From crossfire-request Thu Apr 14 05:06:07 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be (vm1.ulg.ac.be [139.165.32.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 05:06:04 +0200 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Thu, 14 Apr 94 02:50:50 +0200 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA17850; Thu, 14 Apr 94 02:50:46 +0200 Date: Thu, 14 Apr 94 02:50:46 +0200 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9404140050.AA17850@montefiore.ulg.ac.be> To: crossfire@ifi.uio.no Subject: ASCII vs binary - holy war... Status: RO Another contribution to the ASCII vs binary controversy... Some people (hello, Carl!) want to have an ASCII protocol for CrossFire, mainly because it would be easier to implement it on various systems (MACs, PCs, etc.). Well, I disagree with that, and here is why: - It won't be easier to parse ASCII data. You will have to keep a table with all commands and do several strcmp's to find the one that matches. Then you will have to convert all numbers from ASCII to binary. - If you send binary data, you can have fixed-length blocks in you packets. Each block begins with the command number on 1 or 2 bytes (very easy to parse, you only need to use a switch statement) and the following data is already in binary form. No conversion is necessary, unless the byte order is different (and it's easy to handle that case). - Binary will be much more compact. Compare the number of bytes needed in each case for a map update, for instance. In an ASCII packet, we will have the following things: command name (5 to 15 bytes), newline (1 byte), first coord (2 to 4 bytes), space (1 byte), second coord (2 to 4 bytes), space (1 byte), name of object/picture (5 to 15 bytes), newline (1 byte), ... (repeated if there are several objects), end marker (2 bytes). In a binary packet, we will have: command number (2 bytes), number of objects in the following block (2 bytes), first coord (2 bytes), second coord (2 bytes), dynamic reference number for the object/picture (2 bytes), ... (may be repeated), and that's all. Come on, don't tell me that some compression protocol in CSLIP will compress ASCII 5 times better than binary! - ASCII won't be easier to debug. Even if you are debugging the protocol layer, you won't enter the data by hand in real time on a telnet connection! So you will need to write a little program that sends/receives the packets and it will be easier if the packets are in binary form, with fixed-length blocks. - If we want to have CrossFire on MACs and PCs, the protocol must be designed in such a way that it is: 1) easy and fast to parse - binary is better. 2) compact to save bandwith - binary is better. So, tell me, what's the point in using ASCII? Just my $0.2... -Raphael From crossfire-request Thu Apr 14 02:36:30 1994 Return-Path: Received: from po4.andrew.cmu.edu (PO4.ANDREW.CMU.EDU [128.2.11.131]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 02:36:28 +0200 Received: (from postman@localhost) by po4.andrew.cmu.edu (8.6.7/8.6.6) id UAA03367 for crossfire@ifi.uio.no; Wed, 13 Apr 1994 20:36:24 -0400 Received: via switchmail; Wed, 13 Apr 1994 20:36:19 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Wed, 13 Apr 1994 20:35:30 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Wed, 13 Apr 1994 20:35:25 -0400 (EDT) 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; Wed, 13 Apr 1994 20:35:24 -0400 (EDT) Message-ID: Date: Wed, 13 Apr 1994 20:35:24 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol In-Reply-To: <9404131736.AA06098@capitalist.princeton.edu> References: <9404131736.AA06098@capitalist.princeton.edu> Status: RO "Carl Edman" writes: & "Eric A. Anderson" writes: [ Line oriented packets .vs. size & data oriented packets ] > (a) that you can't any longer use telnet or any of the other standard > line oriented clients to just check on a server when you have no client > available which makes debugging harder This is absolutely trivial to write. It takes 20 minutes -- I checked, I wrote it. I also wrote a server process in that time that will broadcast messages to all connected clients. > [ need an arbitrary limit because otherwise people will be hostile, > or not enough memory] Yea, but then the limit can be changed based on the amount of memory available, allowing more batching of commands. Anyway, with the given limitations on network bandwith, a message over 4-8k wouldn't be practical anyway. > (c) (for the byte counters) That adds an extra 1 or 3 bytes to every > single command ! I don't think this really matters -- the ascii commands will be longer in the general case also. Anyway, lzw would compress out this information if it repeats very often, so the cost is low. Furthermore, I believe it makes handling the packets much easier because there is an additional check as to how much information should arrive. -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 Thu Apr 14 02:27:42 1994 Return-Path: Received: from ursula.ee.pdx.edu (ursula.ee.pdx.edu [131.252.20.155]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 02:27:38 +0200 Received: from potrzebie.ee.pdx.edu by ursula.ee.pdx.edu (4.1/SMI-4.1) id AA10627; Wed, 13 Apr 94 17:29:02 PDT From: bairds@ee.pdx.edu (Scarrow) Message-Id: <9404140029.AA10627@ursula.ee.pdx.edu> Subject: Re: cheating To: peterm@soda.berkeley.edu (Peter Mardahl) Date: Wed, 13 Apr 1994 17:29:05 -0700 (PDT) Cc: crossfire@ifi.uio.no In-Reply-To: <199404132114.OAA09472@soda.berkeley.edu> from "Peter Mardahl" at Apr 13, 94 02:14:38 pm X-Mailer: ELM [version 2.4 PL23beta] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1985 Status: RO > Who really cares about cheating anyway? This game isn't > like netrek where cheating makes it easier for you to kill > other players. By and large, you're competing against > the computer, not each other. cheating isn't therefore such > a big deal, IMHO. I disagree. In any sort of a multiuser game where actions of one player can influence another the decision of what should reside on the server and what should reside on the client is critical. Why open up yourself to problems before they exist? LOS calculations are not so excrutiatingly intensive that they _must_ be farmed out to the clients. If my client gets object A, and thus prevents you from getting object A, and my client was computer controlled, you'd be upset. Now, I may be able to get object A before you do because I can see that "tile X" is really a destructable wall, or just because I can see the staircase leading up to the area where object A exists. > If someone wants to ruin the game for themselves by cheating, > let 'em. They'll soon get bored and quit. What are they going to > do? Brag about how they cheated to get to the end of a quest? > "Gee, I did this quest! Kiss my ass! (Of course, I cheated)" > If they do cheat, it doesn't really hurt anything or ruin > the game for everyone else. They'll cheat more, they'll kill your characters with the items they got cheating, they'll brag about solving a quest without telling you they cheated (what, are you expecting honest cheaters only?). This works akin to the idea that ignoring a bully will make him go away. Sorry, some people like the attention, but some just like to make people feel pain. > Move LOS to the client! Move anything the player should know or that is essential to the client to the client. LOS is not so computation expensive as to require being embedded into the client, so don't, but since I'm not going to write it and since I currently play crossfire about one hour per week, I don't care. :) From crossfire-request Wed Apr 13 23:14:44 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 Apr 1994 23:14:43 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id OAA09472 for crossfire@ifi.uio.no; Wed, 13 Apr 1994 14:14:38 -0700 Date: Wed, 13 Apr 1994 14:14:38 -0700 From: Peter Mardahl Message-Id: <199404132114.OAA09472@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: cheating Status: RO Who really cares about cheating anyway? This game isn't like netrek where cheating makes it easier for you to kill other players. By and large, you're competing against the computer, not each other. cheating isn't therefore such a big deal, IMHO. If someone wants to ruin the game for themselves by cheating, let 'em. They'll soon get bored and quit. What are they going to do? Brag about how they cheated to get to the end of a quest? "Gee, I did this quest! Kiss my ass! (Of course, I cheated)" If they do cheat, it doesn't really hurt anything or ruin the game for everyone else. Move LOS to the client! Regards, PeterM From crossfire-request Thu Apr 14 08:09:46 1994 Return-Path: Received: from anna.it.lut.fi (root@anna.it.lut.fi [157.24.21.68]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 14 Apr 1994 08:09:45 +0200 Received: from localhost (haatanen@localhost) by anna.it.lut.fi (8.6.5/8.6.5/1.12.kim) id AAA01201; Thu, 14 Apr 1994 00:01:16 +0300 (for crossfire@ifi.uio.no) From: Tero Haatanen Message-Id: <199404132101.AAA01201@anna.it.lut.fi> Subject: Re: A few thoughts on client/server To: crossfire@ifi.uio.no Date: Thu, 14 Apr 94 0:01:15 EET DST X-Mailer: ELM [version 2.3 PL11] Status: RO Now I have read so many articles about client/server that I throw in some my own comments. I probably repeat something that is already said, but take this as just my opinion. The first point I want to make is that client it just user interface for the game. This is of course obvious, but this is sometimes forgetten. And that means that everything that player can do, can made also in client automatically. Like if player can look the ground and pickup all diamonds, client can be configured so that it sends needed pickup commands automatically. Client purpose is offer nice playing interface not force player do manually simple things like this. Pickup by value/ weight index can be either client (where it really belongs) or in server (to save a little bandwidth, not need send examine/pickup packets). And everything that player has seen can be stored in clients memory. But client shouldn't get _any_ updates about items behind players vision. So if monster dies behind wall updates shouldn't be send before that player can really see that there is now more any monster. I personally prefer binary protocol because it easier parse and it saves CPU-time and bandwidth. XPM (I talk here XPMs, althought client use graphic format most suided it needs, of course) caching in client side is not very easy problem to solve. Two different server can use same name to refer two totally different pixmap. Maybe this problem disappears if servers use same name to prefer _exactly_ same image. The number of image sets affects here, keeping two set of images is acceptable, but ten is too much. Server should notify client in the beginning of the session that when images was updated and send list of changed images, so that client can delete old versions. In server side pixmaps are easy collect files according to date, it just take a little more building time for images. The best solution would be a smart cache which reads new pixmaps from every server and compares images existing ones and adds it to general cache if it not exist or server ones if it different than the general image or if it is same as a general images already then simply use general image. I think its better send number-name list begin of connection and after that use only numbers to refer to images. This saves really bandwidth a long term. Let's make some calculations from the current version. The number of pixmap is 2200, average length of name 12.6, so it takes about 32 Kbytes send a list. After that you can refer each image with two bytes, so you save about 10.6 bytes per image. And average size of map is 27x26 which makes 702 squares. So using numbers to refer images saves you 7441 bytes per map (and this is only floors not objects or animations). So after 4.3 maps it starts really save bandwitdh. And little longer pause in the beginning of play isn't so bad than slow play the whole time. I think it better client tell to server if it use B/W bitmaps or color ones. First those B/W versions are already drawn and they looks much better than if client tries convert color ones to B/W. And secondly 24 * 24 bits = 72 bytes, where color images are 72 * 8 = 576 bytes. The client knows only how to display data so that it looks good after when server is told client what data really is (bitmap name doesn't tell anything it's just reference to actual graphics data). Simple way to transfer images are transfer colors when server starts and images when they needed as 576 bytes binary data. Or if limiting to current colors you need 5 bits per pixel and it would make 360 bytes data. Easy to use everywhere and don't need any special parsing. About doing animation in client is partical solution only. Most alive objects moves around so animating those in client side don't help, since you have update them anyway. So objects which can be animated on client side are backgrounds (currently 3) and normal objects (e.g. diamonds and so, currently about 50). If client animates these, it helps server side. Note that alive object's animation can have a real meaning, like different animation of wizard, when he concentrate to cast a spell, director turning around and so on. So maybe there should be two types animations on server side, first done by client and second done be server. One point about Carl Edman's protocol is that it makes difference between backgrounds and objects and that doesn't make sense. Does that mean that background objects don't have same properties that other objects? And what are these terrrains? Floors? Floors and walls? If walls does it count weak walls? And so on. I think it's not worth it. And there isn't anywhere seen requirements how long client have to keep items in the memory. Does UNMAP mean that client can delete this square totally and server sends it again or does client have to keep all places in memory where player is visited or so only to next CLEAR command? Note that client really shouldn't been aware which physical map player is, although it probably knows it. Think something like current world maps, client don't need to know which physical map is in question. One thing which makes hard to send just updates in visible items is that server has to remember all things what it has been send to every player in the game. With 10 players and big map this is quite much of memory to keep tracked. I prefer Kjetil's idea that client tells how many stacked objects client wants and server send images without names. Since how many times players click on walls to see their names? If player wants to look at a specific square it sends command to server ("look x y"). Server sends back a string (and maybe pixmaps) what player see there. So server can implement feature that player don't see all items if looking from too far. Player don't need names most objects anyway, so don't wast time to sending them. I think it's also good assume that player is always in the centre of view (currently 11x11). Maps are designed that way, so no need of changing that. This view can be probably get up to 15x15, but bigger that change the game too much. All maps are designed only for small views. One solution to send updates for map is that when player first time enters to the new map, whole 11x11 (or 13x13, 15x15) area is send player. With binary packet it makes 11 * 11 * 2 = 242 bytes per/graphics level. Next time when view is changed server checks if how much that byte array is changed. If it changed only little then update packet can be send. If player moves, that array is shifted in same direction that player moves. It would be very easy to server remember what is send to each player since you need keep only latest update, not whole map. Update packet use 3 bytes per location per graphics level, so it don't even use much bandwidth. One thing about protocol, it really can't be a stateless in sense that server must know what packets are accepted from client. I mean that dead players can't move around and so. It can be a very simple as discussed protocol has shown. I use those commands only as commands, not how they are encoded and sended. -Tero -- From crossfire-request Wed Apr 13 22:49:47 1994 Return-Path: Received: from cardhu.cs.hut.fi (cardhu.cs.hut.fi [130.233.192.95]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 13 Apr 1994 22:49:46 +0200 Received: by cardhu.cs.hut.fi id AA04689 (5.65c8/HUTCS-C 1.3 for ); Wed, 13 Apr 1994 23:49:35 +0300 Date: Wed, 13 Apr 1994 23:49:35 +0300 Message-Id: <199404132049.AA04689@cardhu.cs.hut.fi> From: Tero Kivinen To: Scarrow Cc: Subject: Re: images and maps In-Reply-To: <9404132004.AA01185@ursula.ee.pdx.edu> References: <9404131858.AA06176@capitalist.princeton.edu> <9404132004.AA01185@ursula.ee.pdx.edu> Organization: Helsinki University of Technology/Lifelong Learning Institute Dipoli Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Status: RO Scarrow writes: > have yet to be cached by the client. This may not seem like as good of a > solution as sending all the bitmaps at the beginning, but I for one don't > care for large delays at the opening which could be relegated to small > delays while playing. Of course, an intelligent client could cache these You can also combine these with correct planning of protocol, so that when client notices that user isn't doing anything it might ask some images from server for its cache, and after a while it might have all the pixmaps downloaded to local cache. After that everything will run at the full speed again. -- 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 Wed Apr 13 22:02:44 1994 Return-Path: Received: from ursula.ee.pdx.edu (ursula.ee.pdx.edu [131.252.20.155]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 13 Apr 1994 22:02:39 +0200 Received: from potrzebie.ee.pdx.edu by ursula.ee.pdx.edu (4.1/SMI-4.1) id AA01185; Wed, 13 Apr 94 13:04:06 PDT From: bairds@ee.pdx.edu (Scarrow) Message-Id: <9404132004.AA01185@ursula.ee.pdx.edu> Subject: Re: images and maps To: cedman@Princeton.EDU Date: Wed, 13 Apr 1994 13:04:09 -0700 (PDT) Cc: crossfire@ifi.uio.no In-Reply-To: <9404131858.AA06176@capitalist.princeton.edu> from "Carl Edman" at Apr 13, 94 02:58:25 pm X-Mailer: ELM [version 2.4 PL23beta] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2395 Status: RO > > player walks into a new map area, with 20 different monsters he's > > never seen before. > > His connection gets flooded with loading new information. > > Meanwhile, the monsters trash the player. > > We COULD make it so when you enter a map, you are "invulnerable", but > > I think that's an unclean thing to do. > Ah, yes, this is a real problem. I only have a few partial answers to > it. Well, here's a suggestion. Transfer, at the beginning, a set of bitmaps designed to represent the default (i.e., a monster default, some wall defaults, etc.). If the transfer of a bitmap takes longer than a certain length, display the map using default bitmaps for those bitmaps which have yet to be cached by the client. This may not seem like as good of a solution as sending all the bitmaps at the beginning, but I for one don't care for large delays at the opening which could be relegated to small delays while playing. Of course, an intelligent client could cache these images permanently to disk, and then you'd experience no delays unless new bitmaps were sent. It could also be possible to key the bitmaps somehow so that, say, revising an old bitmap could cause it's retransfer. This key could specify whether or not the bitmap is local to this server or not (have user defined bitmaps set some sort of flag, for example), which bitmap it is, which revision of this bitmap it is, etc. By the way, I think efficient LOS is possible (indeed, NetHack claims to have gained an overall savings after having switched over their code to a LOS based method), probably using precompiled tables of some sort. I think a server should try to isolate to itself any mechanisms which limit the amount of information the client should receive. The client should receive only that information which is perceivable by the player using the client. Netrek has gotten unreasonably complex and irritating with it's RSA key scheme just because of the player written client problem. I don't care if somebody writes a client that can play a game of Crossfire better than I can, but I do care if somebody writes a client that can play better than I can because it can see invisible properties, see around corners, etc. Arguing that only a few people would be able to do it is pointless, since once a few people have done it a few billion more can usually get the source code and do it as well. From crossfire-request Wed Apr 13 21:00:50 1994 Return-Path: Received: from mccaw.com (wombat.mccaw.com [192.135.191.118]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 13 Apr 1994 21:00:12 +0200 Received: from nwestmail.entp.mccaw.com ([155.176.15.34]) by mccaw.com (4.1/SMI-4.1) id AA15084; Wed, 13 Apr 94 11:59:33 PDT Received: from axys69.nwest.mccaw.com by nwestmail.entp.mccaw.com (4.1/McCaw SUN-RMR Mailer, SMI-4.1) id AA20501; Wed, 13 Apr 94 11:59:26 PDT Received: from divac by axys69.nwest.mccaw.com (NX5.67d/NX3.0M, dpg hack 15oct93) id AA09842; Wed, 13 Apr 94 12:01:56 -0700 From: Jason Fosback Message-Id: <9404131901.AA09842@axys69.nwest.mccaw.com> Received: by divac.nwest.mccaw.com (NX5.67d/NX3.0X, dpg hack 20mar93) id AA00541; Wed, 13 Apr 94 12:01:36 -0700 Date: Wed, 13 Apr 94 12:01:36 -0700 Received: by NeXT.Mailer (1.100.RR) Received: by NeXT Mailer (1.100.RR) To: crossfire@ifi.uio.no Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol Status: RO All this talk of transmitting pixmaps and maps and items and ... is all well and good, but I'd also like to consider the possibility of having a "smart" client. A client that has its own pixmaps (or tiffs, or picts, or .bmp's) could just receive placement of an item, and the client could display it. This raises at least two issues, one good, one bad. The client could display a native image, with whatever resolution and color depth they wanted. This allows for some REALLY nice client implementations that take full advantage of the native client environment. The disadvantage is in getting updated pixmaps. If a pixmap changes or a new one is added, it has to be transmitted and translated into some sort of displayable format on the client. This isn't too difficult, but it would just look funky on the client side (e.g., a jaggy, scaled black and white pixmap on a 24-bit color machine). Of course, the client could implement a "default" pixmap that could be displayed for different archtypes. I would advocate that the protocol should definitely be a transmit-on-request protocol; the server should assume that the client "knows" about everthing, unless the client says otherwise. This allows for a virtually unlimited client that could maximize the native environment (YES!) and use only the barest resources of the server. LOS, as well as other compute-intensive operations, could be computed on the client, unless the client says "no, I can't compute this". This would allow the server to be just a glorified event-processor that maintains a matrix of items and movements. Then, all that's transmitted to the client is the barest of information in order to represent the state of the current map. The worries about cheating, I think, are unfounded. It would be easy to cheat, no matter how you implement the client/server architecture. Carl has already mentioned the possibility of "robot" clients that cruise around picking things up. Your average user wouldn't be able to do this type of thing, and probably wouldn't care to. Only a handful of hackers (like all of you) would be able to. However, anyone that actually writes code for Crossfire should be smart enough to cheat, regardless of what restrictions we put in :) So, we shouldn't limit the possibilities of things like LOS computation. -jason ____________________________________________________________ Jason Fosback, Systems Engineer | No sir, I didn't like it --- Paradigm Systems Corp --- | -R&S Internet: jason_fosback@psca.com | Star Trek: NeXT mail: jason_fosback@psca.com | The NeXT Generation... From crossfire-request Wed Apr 13 21:02:19 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 13 Apr 1994 21:02:18 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA07470; Wed, 13 Apr 94 15:02:12 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA06176; Wed, 13 Apr 94 14:58:25 -0400 Date: Wed, 13 Apr 94 14:58:25 -0400 From: "Carl Edman" Message-Id: <9404131858.AA06176@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: images and maps Reply-To: cedman@Princeton.EDU Status: RO From: Philip Brown > >>>>[From Carl Edman] > > > - when the client connects to a server, the server sends all > > filenames (images and sounds) to the client, along with their > > id numbers. Then, each time a sound or image has to be used, > > its id number (2 or 4 bytes) is sent instead of its name. > > That is a false economy. On the systems on which bandwidth > _really_ matters i.e. SLIP or 57.6 kBps fixed line systems you > are trading adding several minutes to the startup time for > being able to shave off some unnoticeable 2 or 3 bytes off a > reference to a new image or sound. The user visible performance > gain for that is completely below the threshold of noticability > (and may even be a loss as I explained in the article about the > efficiency of ASCII vs. binary I posted yesterday). > > I don't get how you can justify this, or maybe I'm misunderstanding > what you're saying. > > Counter-situation: Server/client uses the method of loading > images/whatever on demand, instead of at startup. > > player walks into a new map area, with 20 different monsters he's > never seen before. > > His connection gets flooded with loading new information. > > Meanwhile, the monsters trash the player. > > We COULD make it so when you enter a map, you are "invulnerable", but > I think that's an unclean thing to do. Ah, yes, this is a real problem. I only have a few partial answers to it. First of all, note that I insisted on two independent channels in the protocol (for this very reason, among others). Even if the server->client connection is clogged up with large image transfers, the client->server connection is not affected. That means that you _never_ "freeze". So you'll always be able to run away in this case, even if it may take a little while for the graphics you see on the screen to catch up with your flight. Then, it is also a matter of map design. Already I believe it is considered quite bad form to place aggressive and dangerous monsters right next to a map entrance because it tends to lead to fatalities even now. Also _I_'ve never seen more than two or three new monsters I've never seen before at one time and even that only very very rarely. So this problem may not be as signficant as you think. > Anything that requires , or > COULD require, mass loading of data , should be done one time only, > at startup time. (and then never again, until the server gets > updated) But servers are going to be run by us hackers -- there are going to be almost continuous updates. This scheme will transmit many times more images than most players will ever see, more times than any player needs to have them transferred (once) and then compounds its sin by doing the transfer in the way most painful for players by resulting in long pauses rather than tiny unnoticeable delays during play. > Of course this proposal also gives away a list of all images and > sounds to the user -- arguably not as bad a problem of cheating > as sending the entire map to the client, but nevertheless. > > Are you referring to crossfire displaying all the images onscreen, > when starting in "pixmap" mode? it doesn't HAVE to show them, you > know. Ah, but I thought that there was something of a consensus now that we can not assume control over the clients and that telling something to the client is morally equivalent to tell it to the user. That was the main argument for server-side LOS. > BTW: as far as sending screen updates across, I quite like the > > VIEW x y {imageface imageface ... } [x y {imageface ...}] > > idea. This would actually allow some notion of client map caching. > For example, moving "up" one square, on a quiet map would only > require the server sending the new row. Well, that is just the MAP command with the optimization that when two words follow each other the location of the second is assumed to be one to the left/right of the first one. I'd be perfectly happy to make that change to MAP, though frankly it doesn't buy you very much if you move left or right (which you'll do at least half the time) or when revealed areas (because of LOS) are not lines. > Even if there are monsters, server is only required to send new top > row, plus whatever monter has moved. Monsters are items, not map and are transmitted with a different command (which also automatically erases the last image of the monster or other item). Even if a monster is in some field, a client will still want to know what the terrain is. > Given the arguments about auto-compression, and relative sizing, I > think I will concur that having "imageface" as an ascii value is > acceptable. Ah, I'm glad to hear that ! Carl Edman From crossfire-request Wed Apr 13 20:38:32 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 13 Apr 1994 20:38:24 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA02455; Wed, 13 Apr 94 14:38:15 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA06170; Wed, 13 Apr 94 14:34:28 -0400 Date: Wed, 13 Apr 94 14:34:28 -0400 From: "Carl Edman" Message-Id: <9404131834.AA06170@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol Reply-To: cedman@Princeton.EDU Status: RO lemke@ncd.com writes: > Well, I've given the list of arguments why not N times on the list, > so why not do it N+1 times ? Forgive me if it is the short form. > > i've seen them -- but my experience is that the binary solutions is > better. (which i also sent, and saw no response to). Yes, I saw that article and found it interesting, but at the time I had already exceeded my personal crossfire-list posting quota. > * Less conflict between independent groups of extenders > > no conflict at all if you specify the extension mechanism up front. > look at X, and any of the related protocols. X was developed and is maintained by a staffs of dozens of professional programmers at universities and OS developers who do nothing else but extend, optimize and fix bugs in it. Unfortunately crossfire doesn't have that kind of programmer resources, so it needs to be a little bit friendly to the programmer. > * Doubtful if binary will use less bandwidth overall. Certain that > it won't in many cases. > > name some. a single byte opcode is smaller than a string. 2 bytes > of length data is usually smaller than the ascii representation of > the same. if the packets have a fixed format, there's no need for > whitespace and other artificial delimiters. On really slow connections (and those are what we are haggling about -- an unloaded ethernet can handle anything we can dream no matter how badly designed) almost without exception use compression on the stream (like e.g. V.42bis). In that case binary _and_ ascii will be compressed to a binary format. I seriously doubt that after compression an originally binary format is still significantly smaller than an ASCII format. Also, those compression algorithms were designed and tuned for ASCII text and may end up doing a better job on it that on binary. > * Byte order, data sizes and packing. That can be solved on > systems more easily than on others but is a perenial source of > bugs in binary network protocols. > > only poorly written ones. all these problems have been solved, > numerous times. specify items in terms of bytes, don't use 'int'. > choose a byte order and stick with it, having one side swap where > necessary. I know, I know, I know. You and I know the hoops we have to jump through and the operating systems we work under provide the libraries and tools to do that relatively painlessly. Mac, DOS and Windows clients don't have that luxury and their programmer don't have that experience. Considering how important these clients are going to be, I think it is important to make life easier for them if we can. > Ultimately it is true that it is possible to write a binary > standard and enforce it and likely it will give a (slight) > performance increase in a perfect program. But then the same can > be said for writing crossfire completely in machine language and > rewriting it for every port. > > if your goal is to reduce bandwith, binary is faster. Not necessarily. See above. > Its also faster to parse. True, but not by as much as you may want to believe. Remember that we are parsing machine generated statements of a fixed format and without ambiguity and not natural language (which is very slow to do well). Also I think we agreed that for virtually every client the limiting factor will be the network bandwidth/latency, not CPU. > the major performance limitation of the game is > communications -- that's where the effort is well-spent. That's true. But the commands worth optimizing are MAP, ITEM, and TRANSMIT (by reducing the number of unnecessary tranfers and interspersing them), not PLAY. I'll offer you a bet of $1 that when the client is written in excess of 95% of server->client traffic will consist of these commands in virtually all situations. > ascii may make the debugging simpler, but the players don't give a > damn, they just want the best possible game. And for most users that is a game which is relatively bug free and in which bugs get fixed as soon as they are reported. > make the choice that best solves the customer's problems, not the > developer's. Well, that may hold in the commercial world. When a very small number of good programmers write something which very many users want and do it for free, the programmers do get to have some say about the product. :-) > > > you'll want to have room for options here -- does the client > > > support sound, what format does it want the images in (1 bit, > > > color, etc). > > > > > The server does not care. A client without sound, just never > > REQUESTs the sound files. A client without graphics (i.e. a > > curses or robot client) just never REQUESTs the images. > > Clients with limited graphics convert the received graphics > > into whatever format displays best natively. > > > > > from what i saw, the server sent the 'play sound' messages no > > matter what. sure the client doesn't have to fetch them, but why > > waste the packets if they're going to dropped? a simple "here's > > what i do" startup packet saves a lot of bandwidth. > > How often is a sound played on average ? Once a minute on average > ? For 10-15 bytes for the command (as very few events only > consist out of a sound, the play command will almost always be > part of a larger TCP packet which would be sent anyway) it is > just not worth it. I'm trying very hard to keep all these kinds > of little server hacks which require the server to take > particular care of each client for very very marginal performance > improvements out of the protocol definition. > > you said latency was important to you -- reducing round trips is the > best way. why is there a hack? the code that plays the sound simply > checks a client's attributes before sending it the sound. I just think that is a complication which buys you almost nothing. I'll bet you another $1 than we the server is running and you add an option which disables play commands on clients which don't have sound, you'll reduce total server network traffic by less than 0.2%. > > you also want to avoid round-trip whenvever possible. a server > > that tells a client about an image for the first time should send > > the image then, not wait for the client to ask for it. > > The server doesn't (and shouldn't have) the foggiest idea if a > client (a) even needs images (robots and curses interfaces don't) > or (b) already has the image from an earlier session or another > source or (c) needs the image again during the same session or > (d) ... > > which is the whole point of having the client tell the server this up > front. if the client doesn't even have a display (i believe you had > an earlier example of a client that was text-only), why should it be > sent all the map commands? why does it ever need images? Even a client which doesn't display (like a robot) still wants to know what the terrain looks like. A robot may not care what a firewall looks like, but it doesn't want to walk into one. Also a curses clients, may not want the bitmaps, but it still needs to know the map so that it can draw the appropriate ASCII characters. > making these choices up front is trivial, and saves lots of effort. Well, if I wrote it, I wouldn't bother about enabling/disabling the PLAY command. But I'm sure when the server is up, the maintainers will be happy to accept your patch. > Please lets try not to blow up the source for the client or the > server by introducing vast numbers of mutual client/server > dependencies. > > obviously we have different ideas of what should be in control. > > to me, the server is in full control -- how can it be otherwise when > it has to talk to multiple clients? it must track where everything > is at all times -- otherwise you get two people killing the same > monster, or picking up the same item, etc. the server should know as > much as possible about the client, so it only sends the client the > protocol the client cares about. all the client does is provide the > interface between the user and the game -- it displays what's > happening and relays the user's actions to the server. the client > can do trivial stuff, like not allowing the user to walk into a wall, > but anything that can change the world state needs to be handled in a > central location. Of course the server has to be in total and exclusive control over everything which actually happens in the simulated world. I'd even go as far as to say the client should not prevent players from walking into walls -- who says that there wont be a spell which allows players to walk through walls some day ? (also, how should the client know what a wall is -- a list of names ?). But by the same token the _client_ is in absolute control of how, when and in what form it displays the world to the user and the server shouldn't care about that. You can think of it like this: Whenever the player character moves a limb or in any other way affects the actual simulated world, the client has to make that request to the server (and may not assume that the server will fulfill it). Whenever the player character has some sensory perception of some form, the server has to tell client (and can then forget about it). For example, the player wants to pick up a sword. So it communicates that desire in some way to the client. Then the client has to tell the server that the player wants to do that (in the current protocol: MOVE IN ). That is all. The client does not change its own view to display that the sword actually is in the possession of the player. Whenever the server gets around to processing the MOVE command, it checks whether it is valid (i.e. if somebody else has already picked up the sword in the mean time) and if so executes it. That means that the view of the world has changed, so the server has to tell all players within the LOS that they've seen the sword become a possession of the moving player (in the current protocol: ITEM IN Sword). Then when the client receives that message will transmit it to the user in some form. Typically that'd be something like adding the sword image to the inventory window. I hope that was understandable -- it think it is very important to get the abstraction right. > (i don't believe pickup (at least as i think of it) can be handled > locally -- the server has to know that the object has been claimed by > the user, so another user (or monster) can't pick it up.) The point about PICKUP was a misunderstanding. Currently there is a command called 'pickup' in crossfire which puts the player into a mode in which he picks up all items he runs over. The argument was about whether the server would have to know about the pickup mode, or the client could just automatically send 'MOVE IN ' to the server for all items in every square the player runs into. Carl Edman From crossfire-request Wed Apr 13 19:40:25 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 13 Apr 1994 19:40:23 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA19141; Wed, 13 Apr 94 13:40:16 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA06098; Wed, 13 Apr 94 13:36:29 -0400 Date: Wed, 13 Apr 94 13:36:29 -0400 From: "Carl Edman" Message-Id: <9404131736.AA06098@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol Reply-To: cedman@Princeton.EDU Status: RO "Eric A. Anderson" writes: > Kjetil Torgrim Homme writes: > > +--- | 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. > > > > Of course, "packet" here is in the meaning "command" - one command > > can consume several TCP-packets (or whatever) or the other way > > around. A TCP-packet can contain one and a half command, and the > > first command must then be processed before the other half of the > > second command arrives. (Obvious, but I think it needs saying) > > I think it might be better to transfer each packet as a size and the > data. This will work for both strings and binary data, and it > eliminates the problem of having to figure out how much of the data > is really yours. -- You can also eliminate arbitrary limits like 4096 > using this strategy. Well, maybe. That is the scheme I used in my last prototype client for a game like this (you know, the one which makes me dislike binary protocols so vigorously :-) ). However, that means (a) that you can't any longer use telnet or any of the other standard line oriented clients to just check on a server when you have no client available which makes debugging harder (b) you need an arbitrary limit anyway. Many clients will run on relatively small computers without virtual memory where you can guarantee correctness without a guranteed maximum packet size. And while the server is probably running on better hardware than the client, it too has limits. And considering that virtually every game like crossfire attracts immature hostile players earlier or later who may want to bring down the server (i.e. as revenge for having died), the server too needs to put some limit on packet size in any case. (c) (for the byte counters) That adds an extra 1 or 3 bytes to every single command ! Carl Edman From crossfire-request Wed Apr 13 19:31:02 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 Apr 1994 19:31:00 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id KAA23693 for crossfire@ifi.uio.no; Wed, 13 Apr 1994 10:30:14 -0700 From: Philip Brown Message-Id: <199404131730.KAA23693@soda.berkeley.edu> Subject: smaller client machines To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Wed, 13 Apr 1994 10:30:12 -0700 (PDT) X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1027 Status: RO I noted the point that "people may be playing on macs, pee-cee's, {...}, and will have limited space" somewheres in the latest mail flood :-) This was in reference to clients storing lots of information about servers, I believe. Quite frankly, that's not an argument we can afford to listen to. Crossfire is a net-intensive, space-intensive, RAM-intensive game. If they haven't got the space, they just can't play, too bad. Let's have no 8088 compatability here! Net-connected macs/whatever usually share space on a fileserver. This is perfect. All of the little machines could share one main crossfire client directory. Then, when one of them connects to a server and gets the latest pixmaps, no-one else has to. Note that there is a "slight" contension problem here, if multiple peole from the same site try to sign on to a new site at the same time! Since the same thing applies to any site with shared filesystems, and a shared client installation, considering a way out of that is not being machine+client specific. From crossfire-request Wed Apr 13 19:31:17 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 13 Apr 1994 19:31:11 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA17388; Wed, 13 Apr 94 13:30:23 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA06093; Wed, 13 Apr 94 13:26:35 -0400 Date: Wed, 13 Apr 94 13:26:35 -0400 From: "Carl Edman" Message-Id: <9404131726.AA06093@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol Reply-To: cedman@Princeton.EDU Status: RO philb@cats.ucsc.edu writes: > --->[From Carl Edman] > > The client is only _required_ to keep the information on the > couple dozen squares which are in current view (though good > clients will want to keep more around as a form of automatic > map drawing). > > This I disagree with. You can get HUGE piles of artifacts (10-30 > items deep) on each square. Huge piles of artifacts in each square ? What dungeon is that -- I think I'd like to visit it. :-) > The client should only be required to know what is on "top". > Otherwise, you add a whole lot of mostly useless information being > transmitted across the wire, which will never be used. Who says that that information is useless ? Some clients may be able to show several (or even all) of those artifacts in one big heap. In any case the amount of information transmitted is not "vast". All you get are about 30 or 40 bytes for each item when you see it the first time (all of which will be in one TCP packet). All that is not retransmitted every time you make a step or move somewhere else. Note that the ITEM command is also what tells you what you yourself (and others) are carrying and what is inside containers. > If the player is _really_ interested in all the items on a square, > the "EXAMINE" comand should be used on that square. (and after all, > this is more realistic.. you should have to use a turn or > two going through a large pile of stuff) I disagree most strongly. All latency is annoying to players but where latency when the player actually does something is bearable, latency for just looking at things is extremely frustrating. By having all visible items known to the client and only having actual actions require a round-trip, you can avoid the later _and_ give clients greater freedom in how to design their user interfaces. EXAMINE is a useful command, but its syntax should be 'EXAMINE ' and it should refer to the more careful and deliberate examination which can give you history or special magical bonuses. > Personally, I'd love to see as much as humanly feasible of these > interface decisions to go into the client. For example, a client > may have several 'pickup' lists (some hardcoded, others added > by the user) which cause it to e.g. automatically pick up (i.e. > send MOVE commands for) anything called 'diamonds', 'rubies', > 'pearls' and 'platinum coins'. > > This sounds quite good. But it still will have to send a "PICKUP" > command to the server. Well, that is what the MOVE command does (MOVE IN ). Note that this would not work if the client doesn't know all the items which are in every square as you suggested above. Carl Edman From crossfire-request Wed Apr 13 19:03:20 1994 Return-Path: Received: from cats.ucsc.edu (cats-po-1.UCSC.EDU [128.114.129.22]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 13 Apr 1994 19:03:18 +0200 From: philb@cats.ucsc.edu Received: from am.ucsc.edu by cats.ucsc.edu with SMTP id KAA14195; Wed, 13 Apr 1994 10:03:15 -0700 Received: by am.ucsc.edu (8.6.8/4.7) id KAA06962; Wed, 13 Apr 1994 10:03:14 -0700 Message-Id: <199404131703.KAA06962@am.ucsc.edu> Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol To: cedman@Princeton.EDU Date: Wed, 13 Apr 1994 10:03:14 -0700 (PDT) Cc: crossfire@ifi.uio.no In-Reply-To: <9404131202.AA04998@capitalist.princeton.edu> from "Carl Edman" at Apr 13, 94 08:02:01 am X-Disclaimer: These opinions are MINE. You want em? Pay for em! X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1498 Status: RO --->[From Carl Edman] The client is only _required_ to keep the information on the couple dozen squares which are in current view (though good clients will want to keep more around as a form of automatic map drawing). This I disagree with. You can get HUGE piles of artifacts (10-30 items deep) on each square. The client should only be required to know what is on "top". Otherwise, you add a whole lot of mostly useless information being transmitted across the wire, which will never be used. If the player is _really_ interested in all the items on a square, the "EXAMINE" comand should be used on that square. (and after all, this is more realistic.. you should have to use a turn or two going through a large pile of stuff) Personally, I'd love to see as much as humanly feasible of these interface decisions to go into the client. For example, a client may have several 'pickup' lists (some hardcoded, others added by the user) which cause it to e.g. automatically pick up (i.e. send MOVE commands for) anything called 'diamonds', 'rubies', 'pearls' and 'platinum coins'. This sounds quite good. But it still will have to send a "PICKUP" command to the server. ---------------------------------------------------------------------- "Look! Up in the Sky! It's a bird!" "It's a plane!" "It's... time for lunch!" "Naaa. it's just SuperBabs" "Well, I was hoping it was time for lunch..." philb@cats.ucsc.edu philb@soda.berkeley.edu From crossfire-request Wed Apr 13 17:53:31 1994 Return-Path: Received: from po4.andrew.cmu.edu (PO4.ANDREW.CMU.EDU [128.2.11.131]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 13 Apr 1994 17:53:30 +0200 Received: (from postman@localhost) by po4.andrew.cmu.edu (8.6.7/8.6.6) id LAA01300 for crossfire@ifi.uio.no; Wed, 13 Apr 1994 11:53:17 -0400 Received: via switchmail; Wed, 13 Apr 1994 11:53:14 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Wed, 13 Apr 1994 11:51:57 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Wed, 13 Apr 1994 11:51:53 -0400 (EDT) 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; Wed, 13 Apr 1994 11:51:46 -0400 (EDT) Message-ID: Date: Wed, 13 Apr 1994 11:51:46 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol In-Reply-To: <199404130233.27762.bera.ifi.uio.no@ifi.uio.no> References: <199404130233.27762.bera.ifi.uio.no@ifi.uio.no> Status: RO Kjetil Torgrim Homme writes: > +--- > | 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. > > Of course, "packet" here is in the meaning "command" - one command can > consume several TCP-packets (or whatever) or the other way around. A > TCP-packet can contain one and a half command, and the first command > must then be processed before the other half of the second command > arrives. (Obvious, but I think it needs saying) I think it might be better to transfer each packet as a size and the data. This will work for both strings and binary data, and it eliminates the problem of having to figure out how much of the data is really yours. -- You can also eliminate arbitrary limits like 4096 using this strategy. -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 Wed Apr 13 14:41:06 1994 Return-Path: Received: from gyda.ifi.uio.no (0@gyda.ifi.uio.no [129.240.78.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 13 Apr 1994 14:41:05 +0200 Received: from Princeton.EDU by gyda.ifi.uio.no ; Wed, 13 Apr 1994 14:41:02 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA23493; Wed, 13 Apr 94 08:39:22 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA05038; Wed, 13 Apr 94 08:35:36 -0400 Date: Wed, 13 Apr 94 08:35:36 -0400 From: "Carl Edman" Message-Id: <9404131235.AA05038@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: Pixmaps, and client/server startup Reply-To: cedman@Princeton.EDU Status: RO Klaus Elsbernd writes: > There is a whole bunch of discussions referring to the item slow > connections. > > But I miss an agreed definition of what is a slow connection. I proposed 1-2 kBytes/sec minimum bandwidth (in addition to some form of compression) and 100-200 ms roundtrip time maximum. SLIP connections can live up to that (just barely) which is why I specified it. :-) I also think that a protocol can be designed which is playable under those conditions (though people will always like faster connections). As a matter of fact, I think I posted a draft of such a protocol a day or two ago. > Does everybody play on a local network (ethernet) or are there serial > lines between server and clients. Do you use slip or ppp? Yep, some of us do. I found playing X crossfire across a SLIP link just barely feasible. It does work to some extent, but in the long run it was just too painful to me. That is another reason I'm so involved in creating a good client/server protocol. :-) > (baud-rate?) Almost all SLIP connections these days are at V.32bis/V.42bis speeds of 14.4kBps. Considering how cheap and plentiful such modems are today, there is no reason to use anything less. Over the next one or two years most that market will likely step up to V.34 which will exactly double the transfer speeds. > Are there someone playing over connection to another > country/state/city? Yep, there are. > Or, are there router between the client-display and the server? I > can't test crossfire outside the university, because I don't know any > servers which are not so far away.(Hi there, is anyone out there > near KL.) If you want to see if you could use crossfire with a server under the client/server protocol, just ping it. If you get times consistently below 200 ms, it should work. Local players will still have the advantage of lower latency, but let's try to make that advantage no more crucial than necessary. > We're managing a network of severall subnet (router included). And I > noticed the following: There is no problem, when running on our > ethernet, if the server is fast enough. If he isn't (I've tested > server and display on my own colored 3/60) xpm-mode isn't desirable. That will change with client/server. Pixmaps are stored on the client and the amount of network bandwidth used will be independent of the graphics used. Also if the protocol uses some 1-2 kBytes/second, calculate how many crossfire connections it will take to bring down an ethernet and .5-1 MBytes/second. Carl Edman From crossfire-request Wed Apr 13 14:29:35 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 13 Apr 1994 14:29:30 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA22252; Wed, 13 Apr 94 08:29:25 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA05030; Wed, 13 Apr 94 08:25:38 -0400 Date: Wed, 13 Apr 94 08:25:38 -0400 From: "Carl Edman" Message-Id: <9404131225.AA05030@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: Pixmaps, and client/server startup Reply-To: cedman@Princeton.EDU Status: RO From: Mark Wedel : > XPM's are in general very inefficient storage medium. I take your word for it. But then they likely will only be the storage format on the server. Most clients are going to use their own internal format to store the pixmaps in a form which they can use quickly and which doesn't contain more information than they actually need. Conversion is done when the images/sounds are sent. > An entire character (8 bits) is used for each pixel. If a pixmap is > only using 2 colors, this means 7 bits is wasted. Remember that on really slow connections (which is the only ones on which this really matters considering that all pixmaps are tranferred _once_ at most and then only when needed) already incorporate some form of huffman compression. That means that a long text consisting only out of 1s and 0s doesn't use up much more than 1 bit per character. > There is some header information that also takes up some space, but > the main space consumer of XPM files is the pixmap data. I agree -- a little bit of header information is not worth worrying about. > The nice thing about XPM files, is being that they are text, they are > very easy to handle. I doubt it would be that difficult to write a > simple program that converts it to the native format, without using > the XPM library. And in fact, some of the standard XPM header > information could be discarded (for example, we know that all > pixmaps, at present time, are 24x24). If that is so (and again I take your word for it), then I think XPMs would be just fine as the specified transport format for the crossfire protocol. > Right now, large montage's of the pixmaps are created to speed up > load time. There is no reason that the pixmaps could not be kept > apart on the server side, so that sending just one or two new pixmaps > would be easy. The client end would be responsible for either > updating its files however it things is appropriate for quick > loading. Couldn't agree more. > It should be possible for the client to keep pixmaps between > different connections, and also be able to get new pixmaps. IF the > client decides to discard the new changes and request new ones each > time, that is fine, but it is just the clients loss (in terms of > connect or startup time.) Just my argument ! > One thing that needs to be kept in mind in general is that the server > still have to keep track of all actions that client does, to some > extent. So even if all pickup was handled in the client, the server > would still need to be notified about anything that is picked up. Again, I agree completely. Whenever something actually occurs in the "physical" world the server needs to know about it (as a matter of fact it needs to actually _do_ it). But I think it could be feasible to have the functionality of the 'pickup' command be part of the client. The client knows where the player is and where all the items the player sees are and what they are, so why shouldn't it just send 'MOVE IN ' commands whenever it enters a new square ? > I think it might work best if the client just has a bare minimum of > information. This saves transferring information that is not needed. > For objects, probably just the name, pixmaps, number of objects, and > the animation information should be kept track of. Things like > value, magical information, hp, sp, etc, should not be needed by the > client. Again, I couldn't agree more. That is all the ITEM command has (though I forgot a field for quantity which is something the client _does_ need to know). To find out more specific information the client uses some 'EXAMINE ' command and the results are sent back by the server in form of TEXT descriptions. HP, SP and food of the player though I think is something which the client should know at all times. > As I said before, the biggest problem is reducing the server->client > information. A method needs to be found so that map information does > not need to be sent very often, but is also only sent as needed. It > probably is not a good idea to send the entire map - on slow > connections this could be quite time consuming. But instead, send > information about the map in the players immediate area. Again, I agree. I do think though that the actual amount of bandwidth which is consumed by the protocol I posted two days ago is small enough to fit the requirement I made up (1-2 kBytes/sec bandwidth minimum, 100-200ms round trip time maximum). Right now I more worried about latency and what can be done about it, though I think that is a soluble problem as well. > When the player moves, in general, only a new row and/or column would > need to be sent, and not the entire 11x11 map area. And certain > objects would be pretty static (floors, walls, etc), so only updates > of information like monsters moving and fireballs would need to be > sent. I agree (this is getting repetitive, isn't it ?). The protocol only sends 'MAP' commands for newly visible squares (and 'UNMAP's for newly invisible squares) and ITEM commands only when items first come into view and when they actually move from one location to another (like a moving monster or an item which is picked up/dropped). Carl Edman From crossfire-request Wed Apr 13 14:06:04 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 13 Apr 1994 14:05:56 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA19022; Wed, 13 Apr 94 08:05:49 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA04998; Wed, 13 Apr 94 08:02:01 -0400 Date: Wed, 13 Apr 94 08:02:01 -0400 From: "Carl Edman" Message-Id: <9404131202.AA04998@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol Reply-To: cedman@Princeton.EDU Status: RO From: Kjetil Torgrim Homme : > >--- [ about the direction of the axes ] > > In any case a client which got this convention wrong might appear > > slightly confusing to the player who is used to see the map the > > other way around but would be perfectly functional. > > Nope. Imagine the big buildings and monsters. I think I can, but I don't see how this changes anything. A player with the coordinate system the other way around would see a mirror image of the world but everything would work just for him as well (until, that is he works with other players and they all agree to walk north now :-) ). > > The way I see it every location has just one map type which > > describes what kind of 'terrain' it is in. _Everything_ else is > > items. How the client choses to represent items (only display the > > top one, overlay them, whatever) is purely up to it and the server > > doesn't care. > > Fine, but this changes my view on your protocol entirely. It could > (with minor modification) easily be supported by a stateless client, > but still have reasonable performance on a clever client. Now you say > that the client needs to remember where _every_ object in the map is. No, only those objects which the user can see at the time. > Well, then it makes little sense to lump together the update commands > for position, outlook and name. What's worse, if you have a stack > with animated objects in it, they will send commands like > > ITEM 323 2 2 diamond.111 nineteen diamonds ITEM 324 2 2 pearls.111 > five pearls ITEM 325 2 2 finesword.112 an Elven sword ITEM 323 2 2 > diamond.112 nineteen diamonds ITEM 324 2 2 pearls.112 five pearls > ITEM 325 2 2 finesword.113 an Elven sword > > etc. even if they are not strictly in view! No, it won't. You still think of the protocol as a series of commands to the client to draw this then and there. It is not. The protocol is a means by which the server describes the actual world to the client. The client adds that information to its own internal database of the world and then uses that entire database to draw the world -- or not. A perfectly fine client may not do any graphics at all. One could easily conceive of a robot client which just reads and writes the protocol, running around picking up valueables and following the player around without ever creating a graphical representation. Another client may be curses based and never use the pixmaps but instead a custom set (of its own chosing) of ASCII characters. All of that is purely up to the client. The server does not care. To answer your specific question, animation information is part of the image information and is handled 100% on the client side. The server nevers sends a command to animate something. The ITEM information is about items, not pixmaps. ITEM commands are only send when something actually physically happens in the world, such as when an item (not pixmap) is created, destroyed or moved from one location to another. (Only if it moves by itself -- items inside other items are moved along automatically without any further commands sent). > Also, the client has no ordering information. The server should have > some way of hinting to the client which objects are more prominent. > 1. ITEM should be split into three commands. 2. The client should > have a way of _hinting_ the server how many items it considers for > each square. It doesn't need to. Every client needs to know all items in a square, if not for graphical display, then for the case when the user clicks on the square (in current crossfire terms). > > Besides I think that image format is something which really should > > be up to the client. Or are you going to add more conversion code > > to the server every single time a new client is created ? > > No, don't be cheap. I want it mainly for expansion, but it is needed > to negotiate colours. I don't think we should negotiate colors. Colors are up to the client side. Please try not to think purely in terms of current X hardware -- there are machines with one million and one different kinds of color hardware. And in every case the client knows far better how to make use of it than the server will. The server gives the client full information and the client makes use of it as best it can without any server interference. > > Probably the server should send the item command first and the view > > command only after that. > > VIEW with an unknown object as argument should present the player > with a black screen (good for rolling characters). That is probably a good idea. > > Examining items or locations is something which is done 100% client > > side without any server calls. That is what all those ITEM calls > > were good for. > > Uhm, Carl, when did you last examine an object in Crossfire? Must be > some time ago... Well, there are different levels of information. Everything that you would see e.g. in an inventory or when you click on a monster or a spot on the map is in the 'name' part of the ITEM command. Admittedly for longer texts (like descriptions of weight, value, or special magical properties like e.g. the rings of Storm/Life/whatever) you probably need an 'EXAMINE ' command. But the reponse to that is just a couple of TEXT descriptions. There is no need for special client smarts here. > Also remember that you can currently click at an > arbitrary spot in the map view, and that Sure. And if the client knows of some item there (i.e. when it has ever seen anything there), it will give a full list just like it does in crossfire today. If it hasn't it wont. Some client may even pop up a window when you click on a square or a character and allow you to move items around just dragging them from one window to another. All that is up to the client. All the server does is send ITEM commands when the items become visible and receive MOVE commands when the user wants to move one item somewhere else. Everything in between is a user interface matter exclusively of concern to the client. > I thought a (possibly) stateless connection was a goal. No, that would be using the client just as a dumb terminal which would be a waste. If you are going to write a custom client, make it a smart one. > The EXAMINE command could also be used by the client to get updated > information about a square if it for some reason had thrown that > information had been thrown away. (Also nice for debugging, I > imagine.) The client is only _required_ to keep the information on the couple dozen squares which are in current view (though good clients will want to keep more around as a form of automatic map drawing). > > As a matter of fact a 'magic mapping' spell would be implemented by > > sending the client map commands for all squares in the map and then > > unmaps at end of the spell. > > Cute, but how would the client know that it should zoom out or > whatever? That's a good question. I was thinking of clients which don't zoom out at all, but instead keep the entire known map in some sort of scrolling view. If players want to look elsewhere they just shift the scrollers around. But that is just an idea for the particular client I intend to write, not a general requirement. Other clients may want to use heuristics. If that doesn't work we may have to add a bit of complication to the protocol and give the client a hint that we are seeing the entire world. > (currently, "magic mapping" reports monsters as well as > floors, btw). No, not on my old B&W system it doesn't ! :-) Seriously, that only means that magic mapping not only has to send MAP commands for the entire map, but also ITEM commands for all items. > > BTW, i think pickup can be implemented purely on the client side. > > Not with the new functionality Peter Mardahl (I think!) added - it > considers value towards weight. That is what I thought about which is why I said "I think". :-) Personally, I'd love to see as much as humanly feasible of these interface decisions to go into the client. For example, a client may have several 'pickup' lists (some hardcoded, others added by the user) which cause it to e.g. automatically pick up (i.e. send MOVE commands for) anything called 'diamonds', 'rubies', 'pearls' and 'platinum coins'. Whether that is an acceptable solution is debatable. > However, the "search" function would be very appropriate to put into > the client (good thing - "search" used to consume a fair bit of CPU > in the server :-) Absolutely. Carl Edman From crossfire-request Wed Apr 13 13:33:23 1994 Return-Path: <<@isg-204.dfki.uni-kl.de:elsbernd@dfki.uni-kl.de>> Received: from uni-kl.de (stepsun.uni-kl.de [131.246.136.50]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 13 Apr 1994 13:33:17 +0200 Received: from isg-204.dfki.uni-kl.de by stepsun.uni-kl.de id aa13429; 13 Apr 94 13:32 MET DST Received: from dfki.uni-kl.de (isg-201.dfki.uni-kl.de [131.246.241.71]) by isg-204.dfki.uni-kl.de (8.6.4/8.6.4) with ESMTP id NAA03441; Wed, 13 Apr 1994 13:32:38 +0200 Message-Id: <199404131132.NAA03441@isg-204.dfki.uni-kl.de> To: crossfire@ifi.uio.no cc: elsbernd@dfki.uni-kl.de Subject: Re: Pixmaps, and client/server startup In-reply-to: Your message of "Wed, 13 Apr 1994 01:37:51 MET DST." <199404130837.AA05037@bolero.rahul.net> Date: Wed, 13 Apr 1994 13:32:37 +0200 From: Klaus Elsbernd Status: RO There is a whole bunch of discussions referring to the item slow connections. But I miss an agreed definition of what is a slow connection. Does everybody play on a local network (ethernet) or are there serial lines between server and clients. Do you use slip or ppp? (baud-rate?) Are there someone playing over connection to another country/state/city? Or, are there router between the client-display and the server? I can't test crossfire outside the university, because I don't know any servers which are not so far away.(Hi there, is anyone out there near KL.) We're managing a network of severall subnet (router included). And I noticed the following: There is no problem, when running on our ethernet, if the server is fast enough. If he isn't (I've tested server and display on my own colored 3/60) xpm-mode isn't desirable. Perhaps we should make a small statistic over what connections the people play. (I'll summarize if someone's interested.) The client/server split should minimize the net traffic. But can we define a lower boundary on what has to be send to/from the client. Perhaps we have to state, that there should be at least a connection of bytes per second to play crossfire? MfG Klaus From crossfire-request Wed Apr 13 10:38:07 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 ; Wed, 13 Apr 1994 10:37:59 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA19665 (5.67a8/IDA-1.5 for ); Wed, 13 Apr 1994 01:37:52 -0700 Received: by bolero.rahul.net id AA05037 (5.67a8/IDA-1.5); Wed, 13 Apr 1994 01:37:51 -0700 Date: Wed, 13 Apr 1994 01:37:51 -0700 From: Mark Wedel Message-Id: <199404130837.AA05037@bolero.rahul.net> To: cedman@Princeton.EDU, philb@soda.berkeley.edu Subject: Re: Pixmaps, and client/server startup Cc: crossfire@ifi.uio.no Status: RO XPM's are in general very inefficient storage medium. An entire character (8 bits) is used for each pixel. If a pixmap is only using 2 colors, this means 7 bits is wasted. There is some header information that also takes up some space, but the main space consumer of XPM files is the pixmap data. The nice thing about XPM files, is being that they are text, they are very easy to handle. I doubt it would be that difficult to write a simple program that converts it to the native format, without using the XPM library. And in fact, some of the standard XPM header information could be discarded (for example, we know that all pixmaps, at present time, are 24x24). Right now, large montage's of the pixmaps are created to speed up load time. There is no reason that the pixmaps could not be kept apart on the server side, so that sending just one or two new pixmaps would be easy. The client end would be responsible for either updating its files however it things is appropriate for quick loading. It should be possible for the client to keep pixmaps between different connections, and also be able to get new pixmaps. IF the client decides to discard the new changes and request new ones each time, that is fine, but it is just the clients loss (in terms of connect or startup time.) One thing that needs to be kept in mind in general is that the server still have to keep track of all actions that client does, to some extent. So even if all pickup was handled in the client, the server would still need to be notified about anything that is picked up. I think it might work best if the client just has a bare minimum of information. This saves transferring information that is not needed. For objects, probably just the name, pixmaps, number of objects, and the animation information should be kept track of. Things like value, magical information, hp, sp, etc, should not be needed by the client. As I said before, the biggest problem is reducing the server->client information. A method needs to be found so that map information does not need to be sent very often, but is also only sent as needed. It probably is not a good idea to send the entire map - on slow connections this could be quite time consuming. But instead, send information about the map in the players immediate area. When the player moves, in general, only a new row and/or column would need to be sent, and not the entire 11x11 map area. And certain objects would be pretty static (floors, walls, etc), so only updates of information like monsters moving and fireballs would need to be sent. --Mark From crossfire-request Wed Apr 13 08:45:56 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 Apr 1994 08:45:53 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id XAA04526; Tue, 12 Apr 1994 23:45:43 -0700 From: Philip Brown Message-Id: <199404130645.XAA04526@soda.berkeley.edu> Subject: Re: Pixmaps, and client/server startup To: cedman@Princeton.EDU Date: Tue, 12 Apr 1994 23:45:42 -0700 (PDT) Cc: crossfire@ifi.uio.no In-Reply-To: <9404120118.AA02131@capitalist.princeton.edu> from "Carl Edman" at Apr 11, 94 09:18:30 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 2213 Status: RO >>>>[From Carl Edman] No, that means that the client has to download the complete set of images every single time any of its servers changes even a single of its pixmaps. What in the world is the win in this over a scheme in which the server just assumes that the client has the named bitmap and it is up to client the client to request the bitmap for the server on an as-needed basis ? As I mentioned, at at least has to be on a per-server basis, because custom servers will have conflicting names for things. You could throw in a part of the protocol, "Send me pixmaps which have been changed since XXX". Kinda sucky, though, as that means the server has to keep dates on every pixmap. Far simpler just to say "If outdated, update" Plus, what if some pixmaps got updated to "nifty k00l knew 1s", and the client doesn't know about it? The user would never know to request the new version. THe client should take care of this automatically. Yes, the source is available but how much overhead do you add to clients which run on machines which quite possible are not X (and so very likely wont have Xpm) or not even UN*X (and so will have a hard time installing gzip and executing it as a subprocess) ? SOURCE, my friend, means that they can simply incorporate the gzip (or rather, just the gunzip ) source directly into their client, eliminating the need for a subprocess. Ditto for Xpm stuff. This is particularily questionable as gzip is not even very effective on image data. Actualy, it's EXTREMELY effective on Xpm data, last time I recall using it. But it would be not very useful if the protocol only allowed for downloading images at a time. It would really shine if block pixmap updating were allowed. My vote for the format would be something much simpler like raw ppm. You can write a parser which translates it into virtually any native format in a page or two. If you really want to compress it, use something simple but effective on image data like run-length encoding. Run-length encoding doesn't work too well on xpm's, I think. Not because offormat, but because of type of data, From crossfire-request Wed Apr 13 06:49:12 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 13 Apr 1994 06:49:11 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Wed, 13 Apr 1994 06:49:10 +0200 Date: Wed, 13 Apr 1994 06:49:10 +0200 Message-Id: <199404130449.27881.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: "Carl Edman"'s message of Tue, 12 Apr 94 23:51:50 -0400 <9404130351.AA04580@capitalist.princeton.edu> Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol Status: RO ++--- Kjetil T. Homme: || Good! I'd like to add something like "whitespace is not ignored and || not allowed in arguments except where indicated. +--- Carl Edman: | Well, one could add that but it wouldn't gain much. [...] I wasn't thinking of CPU. I was thinking about flexibility in the grammar, don't allow people to be too smart for the server's good and so on. Besides, it was needed for my extensions to MAP and QUERY :-) ++--- || Control characters (0-31, 128-159) are only allowed in binary data." +--- | Let's make it client dependent with clients encouraged to interpret | characters with the high bit set as ISO Latin characters where that | is easily done. That's what I implied, really. The range mentioned is control codes in all ISO character sets, the rest of it is OK to use. +--- [ about the direction of the axes ] | In any case a client which got this convention wrong might appear | slightly confusing to the player who is used to see the map the | other way around but would be perfectly functional. Nope. Imagine the big buildings and monsters. +--- | The way I see it every location has just one map type which | describes what kind of 'terrain' it is in. _Everything_ else is | items. How the client choses to represent items (only display the | top one, overlay them, whatever) is purely up to it and the server | doesn't care. Fine, but this changes my view on your protocol entirely. It could (with minor modification) easily be supported by a stateless client, but still have reasonable performance on a clever client. Now you say that the client needs to remember where _every_ object in the map is. Well, then it makes little sense to lump together the update commands for position, outlook and name. What's worse, if you have a stack with animated objects in it, they will send commands like ITEM 323 2 2 diamond.111 nineteen diamonds ITEM 324 2 2 pearls.111 five pearls ITEM 325 2 2 finesword.112 an Elven sword ITEM 323 2 2 diamond.112 nineteen diamonds ITEM 324 2 2 pearls.112 five pearls ITEM 325 2 2 finesword.113 an Elven sword etc. even if they are not strictly in view! Also, the client has no ordering information. The server should have some way of hinting to the client which objects are more prominent. 1. ITEM should be split into three commands. 2. The client should have a way of _hinting_ the server how many items it considers for each square. +--- | I'm prejudiced against SET commands in all kinds of protocols and | languages. In general they just add four characters which need to | be sent with little gain. If you really want an IMAGEFORMAT | command, why not just call it IMAGEFORMAT ? Because unknown commands should be errors in general. Also, I said I wanted two commands for each keyword, SET and SETF. (SETF may not be the best way of doing it.) +--- | Besides I think that image format is something which really should | be up to the client. Or are you going to add more conversion code | to the server every single time a new client is created ? No, don't be cheap. I want it mainly for expansion, but it is needed to negotiate colours. +--- | Probably the server should send the item command first and the view | command only after that. VIEW with an unknown object as argument should present the player with a black screen (good for rolling characters). +--- | Examining items or locations is something which is done 100% client | side without any server calls. That is what all those ITEM calls | were good for. Uhm, Carl, when did you last examine an object in Crossfire? Must be some time ago... Also remember that you can currently click at an arbitrary spot in the map view, and that I thought a (possibly) stateless connection was a goal. The EXAMINE command could also be used by the client to get updated information about a square if it for some reason had thrown that information had been thrown away. (Also nice for debugging, I imagine.) +--- | As a matter of fact a 'magic mapping' spell would be implemented by | sending the client map commands for all squares in the map and then | unmaps at end of the spell. Cute, but how would the client know that it should zoom out or whatever? (currently, "magic mapping" reports monsters as well as floors, btw). +--- | BTW, i think pickup can be implemented purely on the client side. Not with the new functionality Peter Mardahl (I think!) added - it considers value towards weight. However, the "search" function would be very appropriate to put into the client (good thing - "search" used to consume a fair bit of CPU in the server :-) Kjetil T. From crossfire-request Wed Apr 13 05:55:46 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 13 Apr 1994 05:55:43 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA05454; Tue, 12 Apr 94 23:55:37 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA04580; Tue, 12 Apr 94 23:51:50 -0400 Date: Tue, 12 Apr 94 23:51:50 -0400 From: "Carl Edman" Message-Id: <9404130351.AA04580@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol Reply-To: cedman@Princeton.EDU Status: RO Kjetil Torgrim Homme writes: > >--- Carl Edman: > > 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. > > Seems like a a good design goal. QUERY/REPLY doesn't fit into this, > though, see below. It is true. QUERY/REPLY was a late addition which nevertheless I think is needed (though your version may be better). > >--- > > 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. > > Of course, "packet" here is in the meaning "command" - one command > can consume several TCP-packets (or whatever) or the other way > around. A TCP-packet can contain one and a half command, and the > first command must then be processed before the other half of the > second command arrives. (Obvious, but I think it needs saying) Absolutely. > > All characters are case sensitive. > > Good! I'd like to add something like "whitespace is not ignored and > not allowed in arguments except where indicated. Well, one could add that but it wouldn't gain much. while(isspace(*c)) c++; is not really more complicated or slower than if (isspace(*c)) c++; else error(..); if (isspace(*c)) error(); > Control characters (0-31, 128-159) are only allowed in binary data." Let's make it client dependent with clients encouraged to interpret characters with the high bit set as ISO Latin characters where that is easily done. No reason to make life harder than necessary for our european friends. :-) > > 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. > > You haven't defined coordinate, but I assume it is relative to the > top left corner of the map, and that the axes runs from top to bottom > and left to right. Doesn't really matter. All the client has is the current coordinate of the view point object and the coordinate of something in the map. If everything the top left corner happens to have coordinate -10000,43434 who is to care or to know ? I'd like it that way to make one of my private preferences -- making all maps appear as just one big seamless map to the player easier. But that is not really a dependent matter. In any case probably the most efficient way from a bandwidth standpoint is to chose the origin of the coordinte system to be wherever the player entered the map. As far as the axis are concerned my prejudice is towards the mathematical convention i.e. x-axis starts at the far left at negative infinity and goes to the far right at plus infinity, the y-axis starts at the bottom of the page at negative infinity and reaches plus infinity at the top. In any case a client which got this convention wrong might appear slightly confusing to the player who is used to see the map the other way around but would be perfectly functional. > This doesn't seem cater for seeing several objects at a spot in the > map, though. Suggested solution: Default number of objects is 1. > The client can send a SET command. Ah, here I disagree. The way I see it every location has just one map type which describes what kind of 'terrain' it is in. _Everything_ else is items. How the client choses to represent items (only display the top one, overlay them, whatever) is purely up to it and the server doesn't care. > There will be more SET commands to control client/server > communication, for example "SET IMAGEFORMAT XPM". Unimplemented SET > commands should be ignored by the server. A companion command "SETF" > should be used if failure to recognize the command is fatal to the > client. The server will then send an ERROR packet in reply. I'm prejudiced against SET commands in all kinds of protocols and languages. In general they just add four characters which need to be sent with little gain. If you really want an IMAGEFORMAT command, why not just call it IMAGEFORMAT ? Besides I think that image format is something which really should be up to the client. Or are you going to add more conversion code to the server every single time a new client is created ? Standard TIFFs for NeXTs ? Macintosh TIFFs for Macs ? Whatever benighted format Windows uses ? GIFS for PCs ? IFFs for Amiga clients ? Let the clients worry about image conversion. The server should just one format with the requirements (in order of significance) that it a) be simple and easy to convert into most other formats and doesn't require any big non-portable libraries to make use of like TIFF or XBM, b) contains a great deal of information so that even reasonably high end clients get displays worthy of them and c) is reasonably compact. The last requirement is not all that important considering that with this protocol only a few bitmaps are transferred and even that in a nice interspersed manner. Clients will cache the images in a format which doesn't contain more information than they need anyway. > Should the view change immedietely, or is it reasonable for the > client to wait until it receives a new ITEM for that tag? Probably the server should send the item command first and the view command only after that. > In general, how much caching/state _must_ the client have? MOVE seems > to assume some state, but it is not clear to me. Oh a lot of it and the higher quality the client the more. MAP and ITEM instructions are not to be understood as command to the client to "draw this now there !". Rather they are a description of the world which the client adds to its own internal 'world database'. It is that database which it uses when it has to draw something. > > 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. > > > > REPLY [YES|NO] The response to the most recent QUERY command. > > This won't do. My suggestion: Yeah, probably you want to do something like you suggest. > EXAMINE If is "IN", the server sends a > description with REPLY . If is a real > coordinate, a sequence of ITEM packets for all objects at that > coordinate is returned in bottom up order, terminated by an automatic > REPLY for the topmost object. Not at all -- this is important ! Examining items or locations is something which is done 100% client side without any server calls. That is what all those ITEM calls were good for. At all times the client already know what visible items there are, where they are, what they are called and what they look like. It also knows what the floor looks like everywhere in sight and it may have drawn a map of what the floor looks like everywhere else. As a matter of fact a 'magic mapping' spell would be implemented by sending the client map commands for all squares in the map and then unmaps at end of the spell. > Maybe also COMMAND This should be used for things like > "who" and "pickup" unless we decide to put _everything_ into the > protocol. well, i see no reason not to. BTW, i think pickup can be implemented purely on the client side. Carl Edman From crossfire-request Wed Apr 13 04:33:24 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 13 Apr 1994 04:33:24 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Wed, 13 Apr 1994 04:33:22 +0200 Date: Wed, 13 Apr 1994 04:33:22 +0200 Message-Id: <199404130233.27762.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: "Carl Edman"'s message of Mon, 11 Apr 94 22:19:59 -0400 <9404120219.AA02209@capitalist.princeton.edu> Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol Status: RO (plenty of disclaimers in the Subject, eh? :-) +--- Carl Edman: | 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. Seems like a a good design goal. QUERY/REPLY doesn't fit into this, though, see below. +--- | 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. Of course, "packet" here is in the meaning "command" - one command can consume several TCP-packets (or whatever) or the other way around. A TCP-packet can contain one and a half command, and the first command must then be processed before the other half of the second command arrives. (Obvious, but I think it needs saying) +--- | All characters are case sensitive. Good! I'd like to add something like "whitespace is not ignored and not allowed in arguments except where indicated. Control characters (0-31, 128-159) are only allowed in binary data." +--- | 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. You haven't defined coordinate, but I assume it is relative to the top left corner of the map, and that the axes runs from top to bottom and left to right. This doesn't seem cater for seeing several objects at a spot in the map, though. Suggested solution: Default number of objects is 1. The client can send a SET command. SET GRAPHICSLEVEL 3 The server will then send MAP ... An empty string for an image name means no object in that position. Note: --------+ v MAP 1 1 grass 1 2 grass orc 1 3 ... Images are sent in bottom up order, ie. last image in list should (partly) obscure the others. For GRAPHICSLEVEL 1, only the top-most image is sent. For higher graphics levels, as many floor objects as possible are sent in addition, and then objects from the top of the stack. There will be more SET commands to control client/server communication, for example "SET IMAGEFORMAT XPM". Unimplemented SET commands should be ignored by the server. A companion command "SETF" should be used if failure to recognize the command is fatal to the client. The server will then send an ERROR packet in reply. +--- | 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 [...] | | 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. Should the view change immedietely, or is it reasonable for the client to wait until it receives a new ITEM for that tag? In general, how much caching/state _must_ the client have? MOVE seems to assume some state, but it is not clear to me. +--- | STAT [] | This tells the client that the value of the player statistic called | is . If given indicates the maximum value | of that stat. It should be made clear that for a given , will either always be sent or never ( == "weight"). +--- | 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. | | [...] | | REPLY [YES|NO] | The response to the most recent QUERY command. This won't do. My suggestion: QUERY Ask the user a question with the text . No parsing is done on the string after . may be reused as soon as the server has received a reply for it. is one of the following: "BOOL" - reply with , 0 for NO and 1 for YES "NUMBER" - reply with "RANGE " - reply with which is in the range "MULTIPLE Choice 1Choice 2" is a single character (may be SPACE), list is terminated by an empty choice. - reply with the sequence number of the choice made. "TEXT" - reply with free form text, with the exception of newline. With the above extensions to QUERY/REPLY, you can code the login sequence. We also need EXAMINE If is "IN", the server sends a description with REPLY . If is a real coordinate, a sequence of ITEM packets for all objects at that coordinate is returned in bottom up order, terminated by an automatic REPLY for the topmost object. Maybe also COMMAND This should be used for things like "who" and "pickup" unless we decide to put _everything_ into the protocol. I can't think of anything more missing right now (well, except shout :-). Kjetil T. From crossfire-request Tue Apr 12 18:27:17 1994 Return-Path: Received: from cc.lut.fi (hevi@cc.lut.fi [157.24.15.37]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 12 Apr 1994 18:27:16 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id TAA16799; Tue, 12 Apr 1994 19:27:14 +0300 Date: Tue, 12 Apr 1994 19:27:13 +0300 (EETDST) From: Petri Heinil{ Subject: Re: A few thoughts on client/server in multi-player games To: crossfire@ifi.uio.no In-Reply-To: <199404121214.23751.bera.ifi.uio.no@ifi.uio.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Tue, 12 Apr 1994, Kjetil Torgrim Homme wrote: > PS: This a slightly simpler, faster and more correct atoi ;-) > > short int = atoi(char *str) { > while (isdigit(*str)) /* table lookup, one step */ > res = res*10 + (*str++) - '0'; /* three steps */ > } > /* atoi("123") requires 3*4 + 1 = 13 steps */ Yes, this sounds better, I put this into pocket :) > Fred Brooks wrote (in "The Mythical Man-month", I think) that > premature optimising is the biggest of all programming evils. Hmm, well he seems to be more than right. Maybe the discussion focused wrong, like bin vs. ascii. It would more needed to think about the protocol as a model now. And the implemented it in ascii or bin. And I guess, that if there is good interface that server and client uses into protocol, it doesn't show or matter is it ascii or binary. Like a begin, I draw a OSI reference model :-p :-) CrossServer/CrossClient ------------ application - the CrossFire-API up ------------ presentation - data's (like object in point) coded with ASN.1 ------------ or whitout session - session is a null layer ------------ transport - TCP/UDP ------------ network - UDP ------------ link ------------ physical -- The Page -- From crossfire-request Tue Apr 12 14:53:43 1994 Return-Path: Received: from plague.berkeley.edu (plague-ether.Berkeley.EDU [128.32.184.252]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 12 Apr 1994 14:53:41 +0200 Received: from monsoon.Berkeley.EDU by plague.berkeley.edu (5.65c/CHAOS) id AA20705; Tue, 12 Apr 1994 05:53:19 -0700 Message-Id: <199404121253.AA20705@plague.berkeley.edu> To: Peter Mardahl Cc: crossfire@ifi.uio.no, mehlhaff@soda.berkeley.edu, mehlhafff@soda.berkeley.edu, mehlhaff@plague.berkeley.edu Subject: Re: client/server? In-Reply-To: Message from Peter Mardahl of Fri, 08 Apr 1994 12:44:57 -0700 <199404081944.MAA03194@soda.berkeley.edu> Date: Tue, 12 Apr 1994 05:53:17 -0700 From: "'Evil' ERic Mehlhaff" Status: RO Peter Mardahl recently wrote: > >Is anyone actually working on this? >ERic Mehlhaff at berkeley doesn't seem to be doing >anything with it these last >few weeks. I've been sitting back and waiting for the 'new' crossfire to become 'stable' and trying to get a useable 'developement platform' in the meantime. The original protocol scheme I'd worked out got broken minorly by the advent of pixmaps, and I'd been waiting to decide if we wanted to stick with it or not. I'm not sure if I can discuss this much on this list right now, as it seems I've been inadvertantly removed! ACK! ERic mehlhaff, mehlhaff@ocf.Berkeley.EDU OCF staff From crossfire-request Tue Apr 12 14:14:04 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 12 Apr 1994 14:14:03 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Tue, 12 Apr 1994 14:14:01 +0200 Date: Tue, 12 Apr 1994 14:14:01 +0200 Message-Id: <199404121214.23751.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no Mime-Version: 1.0 In-reply-to: Petri Heinil{'s message of Tue, 12 Apr 1994 10:38:45 +0300 (EETDST) Subject: Re: A few thoughts on client/server in multi-player games Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Status: RO +--- Petri Heinil=E4: | And there should be able to transmit 121 (11*11) points at 10 | fps. Every point have 2 numbers so the comparision is 2783 vs. 363 | steps. This might be significant. Okay, but how many steps per second can an average CPU do? 10 MIPS is pretty low-end these days. Even with 100 players, you're talking about 2% of the CPU. Fred Brooks wrote (in "The Mythical Man-month", I think) that premature optimising is the biggest of all programming evils. Kjetil T. PS: This a slightly simpler, faster and more correct atoi ;-) short int =3D atoi(char *str) { while (isdigit(*str)) /* table lookup, one step */ res =3D res*10 + (*str++) - '0'; /* three steps */ } /* atoi("123") requires 3*4 + 1 =3D 13 steps */ From crossfire-request Tue Apr 12 14:13:53 1994 Return-Path: Received: from cardhu.cs.hut.fi (cardhu.cs.hut.fi [130.233.192.95]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 12 Apr 1994 14:13:52 +0200 Received: by cardhu.cs.hut.fi id AA29228 (5.65c8/HUTCS-C 1.3 for ); Tue, 12 Apr 1994 15:13:34 +0300 Date: Tue, 12 Apr 1994 15:13:34 +0300 Message-Id: <199404121213.AA29228@cardhu.cs.hut.fi> From: Tero Kivinen To: Petri Heinil Cc: Subject: Re: A few thoughts on client/server in multi-player games In-Reply-To: References: <9404110210.AA01012@capitalist.princeton.edu> Organization: Helsinki University of Technology/Lifelong Learning Institute Dipoli Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Status: RO Petri Heinil{ writes: > so 3 steps. Ie. the parsing ascii is about 23/3 = 8 times > slower than using net-host conversion direct. > And there should be able to transmit 121 (11*11) points > at 10 fps. Every point have 2 numbers so the comparision > is 2783 vs. 363 steps. This might be singnificant. In current workstations that would be about 55 us vs 7 us, so with ascii we can only 1796 users with 10 fps... so that won't be any issue. > And note from space. The size of trafferred data is > overall unsignificant, but it makes the protocol somewhat > faster in the packets fits into one IP packet. There > is no need splitting and rerouting the another packets. Usually the network overhead etc will be much higher than difference between ascii and binary, so I think we should use the one that is easier to implement. -- 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 Tue Apr 12 09:39:18 1994 Return-Path: Received: from cc.lut.fi (hevi@cc.lut.fi [157.24.15.37]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 12 Apr 1994 09:39:17 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id KAA23483; Tue, 12 Apr 1994 10:39:10 +0300 Date: Tue, 12 Apr 1994 10:38:45 +0300 (EETDST) From: Petri Heinil{ Subject: Re: A few thoughts on client/server in multi-player games To: crossfire@ifi.uio.no In-Reply-To: <9404110210.AA01012@capitalist.princeton.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO tmp = *((char*)&net)[0]; On Sun, 10 Apr 1994, Carl Edman wrote: > Ah, yes, there's the rub. As I've been trying to explain in a recent > post on this subject, ASCII packets are not necessarily larger or > slower. And contrary to popular perception parsing ASCII packets does > not have a signficant impact on CPU performance. Remember that we are > not trying to parse arbitray ambiguous natural language sentences here > like an adventure game would. Those packets will almost always be > machine generated and clear. Generating and parsing such ASCII can be > done extremely quickly. Hmm, thinking atoi function (roughly) short int = atoi(char *str = "123") lenght = strlen(str) # lenght of string, about 4 steps exp = 1 # exponent multiplier, 1 step for(i = lenght; i; i--) # checkin loop, 1 step res += *(str+i) * exp # calculating & adding, 4 steps exp *= 10 # updating exp, 1 step # there were 3 number, so 6 * 3 = 18 steps # there were no handling for sign so the atoi takes 23 steps. And thinking ntohs. Many machines, like sun, has a same byte order an network so ntohs is: #define ntohs(n) (0 step) . Some machines, like PC, the byte order is opposite, then short int = ntohs(short int net) char tmp # do the swap tmp = *((char*)&net)[0] # store tmp, 1 step ((char*)&net)[0] = ((char*)&net)[1] # 1st part, 1 step ((char*)&net)[1] = tmp # 2th part, 1 step so 3 steps. Ie. the parsing ascii is about 23/3 = 8 times slower than using net-host conversion direct. And there should be able to transmit 121 (11*11) points at 10 fps. Every point have 2 numbers so the comparision is 2783 vs. 363 steps. This might be singnificant. And note from space. The size of trafferred data is overall unsignificant, but it makes the protocol somewhat faster in the packets fits into one IP packet. There is no need splitting and rerouting the another packets. -- The Page -- From crossfire-request Tue Apr 12 04:30:10 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 12 Apr 1994 04:30:08 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA06124; Mon, 11 Apr 94 22:30:04 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA02212; Mon, 11 Apr 94 22:26:17 -0400 Date: Mon, 11 Apr 94 22:26:17 -0400 From: "Carl Edman" Message-Id: <9404120226.AA02212@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: A few thoughts on client/server in multi-player games Reply-To: cedman@Princeton.EDU Status: RO philb@cats.ucsc.edu writes: > No, the ideal protocol would work something like this: > > Server -> client > map 1 2 floor > map 1 3 floor > map 1 4 firewall > > [ Client notices the name 'firewall'. Checks its cache (either > on disk or in memory) and find it has no image associated with > the name 'firewall' ] > > Trouble with that is with name conflicts on different servers, that > have added similar, yet contradictory, items. Reference my previously > sent mail for a different idea. Such name conflicts may very rarely happen but it is hardly tragic if a user sees one artists idea of a "vampire" instead of anothers. Keeping completely distinct data bases for each server just to avoid this rare and at very worst slightly annoying occurence is both a waste of disk space and bandwidth. Remember, clients may not have multi-gigabyte disk arrays -- they may be little Macs and PCs or normal users on large systems with a very limited quota for games. Carl Edman From crossfire-request Tue Apr 12 04:24:02 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 12 Apr 1994 04:23:58 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA05009; Mon, 11 Apr 94 22:23:47 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA02209; Mon, 11 Apr 94 22:19:59 -0400 Date: Mon, 11 Apr 94 22:19:59 -0400 From: "Carl Edman" Message-Id: <9404120219.AA02209@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: A quick draft of a preliminary proposal for a possible version of the crossfire protocol Reply-To: cedman@Princeton.EDU Status: RO This is the basic idea of how I think the crossfire protocol should look. I've only been thinking about it a few days, so what you see is completely in a state of flux. I post it only to give a concrete image to some of the basis ideas I've expounding here in the last few days and not in the expectation that it will be adopted in a form even similar to this. It is certainly not complete though it covers most common game situations. You have been warned. Carl Edman 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. 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). 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. CLEAR Erases the entire map. 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. 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). 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. 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. 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. There are more fine points to be explained about how this protocol handles certain events, but I'm sure those will come up in questions anyway. :-) From crossfire-request Tue Apr 12 03:32:57 1994 Return-Path: Received: from corpse.ecst.csuchico.edu (corpse.ecst.csuchico.edu [132.241.5.10]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id ; Tue, 12 Apr 1994 03:32:54 +0200 Received: (from tvangod@localhost) by corpse.ecst.csuchico.edu (8.6.8/8.6.6) id SAA12666; Mon, 11 Apr 1994 18:32:50 -0700 From: Tyler Van Gorder Message-Id: <199404120132.SAA12666@corpse.ecst.csuchico.edu> Subject: Re: uhm..memory usage. To: kjetilho@ifi.uio.no (Kjetil Torgrim Homme) Date: Mon, 11 Apr 1994 18:32:48 -0700 (PDT) Cc: crossfire@ifi.uio.no In-Reply-To: <199404120024.19133.bera.ifi.uio.no@ifi.uio.no> from "Kjetil Torgrim Homme" at Apr 12, 94 02:24:46 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 887 Status: RO > > +--- Tyler van Gorder: > | I was able to find an xterm in which I can monitor how much memory > | crossfire with color pixmaps takes up. Hold you breath: > | 6megs! ack! > > Uhm no, I think you measured the wrong thing - namely the size of the > crossfire server process. You should measure the increase in size of > the X server. no...I measured how much memory was used up on the xterm...when crossfire is running not the size of the server process. The reason I did this at all is we are experencing frequent "out of memory" errors. Mark requested I do some more tests with just pixmaps...and then with fonts......I will let everyone know what the results are. Mark also mentioned that it would be good to know what the depth of our displays are...I will also check that :> > On this NCD19C, the colour pixmaps use 1836 kB. Still a fair bit of > memory, though. > Tyler. From crossfire-request Tue Apr 12 03:22:24 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 12 Apr 1994 03:22:22 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA23122; Mon, 11 Apr 94 21:22:18 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA02131; Mon, 11 Apr 94 21:18:30 -0400 Date: Mon, 11 Apr 94 21:18:30 -0400 From: "Carl Edman" Message-Id: <9404120118.AA02131@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: Pixmaps, and client/server startup Reply-To: cedman@Princeton.EDU Status: RO philb@cats.ucsc.edu writes: > It would be nice if, on startup, servers sent their client a bunch of > version headers. Especially about the pixmap-type data. > > Server Client > Hello server@blah.blah > Hello Client. This is server@blah.blah Sound Enabled Color Enabled > (Disabled is default, ... Enabled.. so never bother to > say "Disabled") Why should the server care what kind of sound/color/a.s.o. the client has ? A client without sound capability will just never request any sound files from the server. A black and white client will just convert the color images to black and white images when it receives them. > At any rate, you could have a "standard" distribution, and tons of > specialized ones. The beauty of it is that 1) None will conflict > with each other 2) There's no wondering about whether you have the > "proper" pix 3) You only have to go through the excruciatingly long > download setup once. No, that means that the client has to download the complete set of images every single time any of its servers changes even a single of its pixmaps. What in the world is the win in this over a scheme in which the server just assumes that the client has the named bitmap and it is up to client the client to request the bitmap for the server on an as-needed basis ? > Ideally, though, we would send the bitmaps/pixmaps in some > independant format, and its up to the client how it stores them. I > personally suggest Xpm gzipped "files", seeing as how the source to > both of them is freely available, so it will be "easily" > incorporatable into most any setup. Yes, the source is available but how much overhead do you add to clients which run on machines which quite possible are not X (and so very likely wont have Xpm) or not even UN*X (and so will have a hard time installing gzip and executing it as a subprocess) ? This is particularily questionable as gzip is not even very effective on image data. My vote for the format would be something much simpler like raw ppm. You can write a parser which translates it into virtually any native format in a page or two. If you really want to compress it, use something simple but effective on image data like run-length encoding. Carl Edman From crossfire-request Tue Apr 12 02:24:48 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 12 Apr 1994 02:24:47 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Tue, 12 Apr 1994 02:24:46 +0200 Date: Tue, 12 Apr 1994 02:24:46 +0200 Message-Id: <199404120024.19133.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: Tyler Van Gorder's message of Mon, 11 Apr 1994 16:01:31 -0700 (PDT) <199404112301.QAA09722@corpse.ecst.csuchico.edu> Subject: Re: uhm..memory usage. Status: RO +--- Tyler van Gorder: | I was able to find an xterm in which I can monitor how much memory | crossfire with color pixmaps takes up. Hold you breath: | 6megs! ack! Uhm no, I think you measured the wrong thing - namely the size of the crossfire server process. You should measure the increase in size of the X server. On this NCD19C, the colour pixmaps use 1836 kB. Still a fair bit of memory, though. Kjetil T. From crossfire-request Tue Apr 12 01:19:48 1994 Return-Path: Received: from cats.ucsc.edu (cats-po-1.UCSC.EDU [128.114.129.22]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 12 Apr 1994 01:19:47 +0200 From: philb@cats.ucsc.edu Received: from as215-ws-3.UCSC.EDU by cats.ucsc.edu with SMTP id QAA06358; Mon, 11 Apr 1994 16:19:42 -0700 Received: by as215-ws-3.UCSC.EDU (8.6.8/4.7) id QAA02846; Mon, 11 Apr 1994 16:19:38 -0700 Message-Id: <199404112319.QAA02846@as215-ws-3.UCSC.EDU> Subject: Re: A few thoughts on client/server in multi-player games To: crossfire@ifi.uio.no Date: Mon, 11 Apr 1994 16:19:37 -0700 (PDT) In-Reply-To: <9404110237.AA01037@capitalist.princeton.edu> from "Carl Edman" at Apr 10, 94 10:37:57 pm X-Disclaimer: These opinions are MINE. You want em? Pay for em! X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 784 Status: RO --->[From Carl Edman] No, the ideal protocol would work something like this: Server -> client map 1 2 floor map 1 3 floor map 1 4 firewall [ Client notices the name 'firewall'. Checks its cache (either on disk or in memory) and find it has no image associated with the name 'firewall' ] Trouble with that is with name conflicts on different servers, that have added similar, yet contradictory, items. Reference my previously sent mail for a different idea. ---------------------------------------------------------------------- "Look! Up in the Sky! It's a bird!" "It's a plane!" "It's... time for lunch!" "Naaa. it's just SuperBabs" "Well, I was hoping it was time for lunch..." philb@cats.ucsc.edu philb@soda.berkeley.edu From crossfire-request Tue Apr 12 01:16:29 1994 Return-Path: Received: from cats.ucsc.edu (cats-po-1.UCSC.EDU [128.114.129.22]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 12 Apr 1994 01:16:27 +0200 From: philb@cats.ucsc.edu Received: from as215-ws-3.UCSC.EDU by cats.ucsc.edu with SMTP id QAA06001; Mon, 11 Apr 1994 16:16:24 -0700 Received: by as215-ws-3.UCSC.EDU (8.6.8/4.7) id QAA02837; Mon, 11 Apr 1994 16:16:18 -0700 Message-Id: <199404112316.QAA02837@as215-ws-3.UCSC.EDU> Subject: Pixmaps, and client/server startup To: crossfire@ifi.uio.no Date: Mon, 11 Apr 1994 16:16:18 -0700 (PDT) X-Disclaimer: These opinions are MINE. You want em? Pay for em! X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1441 Status: RO It would be nice if, on startup, servers sent their client a bunch of version headers. Especially about the pixmap-type data. Basically, it should go something like Server Client Hello server@blah.blah Hello Client. This is server@blah.blah Sound Enabled Color Enabled (Disabled is default, ... Enabled.. so never bother to say "Disabled") Pixmaps version: server@blah.blah March 24, 1994 Ready to play! [ or: Send Pixmap updates, please!] The client should have a save of its most recent pixmaps. Note that this way, it could also have multiple pixmap saves for different servers, if desired. It would store indexed by server. At any rate, you could have a "standard" distribution, and tons of specialized ones. The beauty of it is that 1) None will conflict with each other 2) There's no wondering about whether you have the "proper" pix 3) You only have to go through the excruciatingly long download setup once. Ideally, though, we would send the bitmaps/pixmaps in some independant format, and its up to the client how it stores them. I personally suggest Xpm gzipped "files", seeing as how the source to both of them is freely available, so it will be "easily" incorporatable into most any setup. (note that the client might be able to make its own font using this method.) From crossfire-request Tue Apr 12 01:06:12 1994 Return-Path: Received: from cats.ucsc.edu (cats-po-1.UCSC.EDU [128.114.129.22]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 12 Apr 1994 01:06:10 +0200 From: philb@cats.ucsc.edu Received: from as215-ws-3.UCSC.EDU by cats.ucsc.edu with SMTP id QAA04986; Mon, 11 Apr 1994 16:06:07 -0700 Received: by as215-ws-3.UCSC.EDU (8.6.8/4.7) id QAA02830; Mon, 11 Apr 1994 16:05:58 -0700 Message-Id: <199404112305.QAA02830@as215-ws-3.UCSC.EDU> Subject: Protocols To: crossfire@ifi.uio.no Date: Mon, 11 Apr 1994 16:05:55 -0700 (PDT) In-Reply-To: <9404112226.AA01893@capitalist.princeton.edu> from "Carl Edman" at Apr 11, 94 06:26:44 pm X-Disclaimer: These opinions are MINE. You want em? Pay for em! X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 725 Status: RO Since someone asked about UDP packet size.. this is what "TCP/IP network administration" sez about them, UDP packets have 64 bits of header, followed by arbitrary length of data. TCP packets have 192 bits of header, followed by arbitrary length of data. It so happens that the length of data, when sensibly planned, is normally calculated to fit into a 1500-byte IP frame without fragmentation. However you look at it, though, UDP is a bunch faster. ---------------------------------------------------------------------- "Look! Up in the Sky! It's a bird!" "It's a plane!" "It's... time for lunch!" "Naaa. it's just SuperBabs" "Well, I was hoping it was time for lunch..." philb@cats.ucsc.edu philb@soda.berkeley.edu From crossfire-request Tue Apr 12 01:01:39 1994 Return-Path: Received: from corpse.ecst.csuchico.edu (corpse.ecst.csuchico.edu [132.241.5.10]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 12 Apr 1994 01:01:36 +0200 Received: (from tvangod@localhost) by corpse.ecst.csuchico.edu (8.6.8/8.6.6) id QAA09722 for crossfire@ifi.uio.no; Mon, 11 Apr 1994 16:01:31 -0700 From: Tyler Van Gorder Message-Id: <199404112301.QAA09722@corpse.ecst.csuchico.edu> Subject: uhm..memory usage. To: crossfire@ifi.uio.no Date: Mon, 11 Apr 1994 16:01:31 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 223 Status: RO Ok, I was able to find an xterm in which I can monitor how much memory crossfire with color pixmaps takes up. Hold you breath: 6megs! ack! er....dynamically loading pixmaps might be in order.... Tyler. From crossfire-request Tue Apr 12 00:48:25 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, 12 Apr 1994 00:48:22 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id PAA06271 for crossfire@ifi.uio.no; Mon, 11 Apr 1994 15:48:08 -0700 From: Philip Brown Message-Id: <199404112248.PAA06271@soda.berkeley.edu> Subject: Line-of-Sight To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Mon, 11 Apr 1994 15:48:02 -0700 (PDT) X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 748 Status: RO Sending this while I remember.. sorry if this was covered, but it looks like I have 10k of messages in front of me to read.. :-/ ANYways... The point was made "server should do line-of-sight calculation to save on bandwidth" This is not as valid as may seem. It depends on how populated the monsters are, and where they are. For a "monster-sparse" map, there will be no gain to doing LOS calc. in the server. On the other hand, if there are a lot of doors, the server will have to keep adding what squares are blacked out, and what squares have suddenly become visible. So doing LOS calc on the client is a major win, with respect to bandwidth, in this case. (and keeps the server free to calculate monster attacks on players somewhere else!) From crossfire-request Tue Apr 12 00:31:24 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 12 Apr 1994 00:30:49 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA20745; Mon, 11 Apr 94 18:30:31 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA01893; Mon, 11 Apr 94 18:26:44 -0400 Date: Mon, 11 Apr 94 18:26:44 -0400 From: "Carl Edman" Message-Id: <9404112226.AA01893@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: A few thoughts on client/server in multi-player games Reply-To: cedman@Princeton.EDU Status: RO Eric A. Anderson writes : > "Carl Edman" writes: > > Eric A. Anderson writes: > > [ not easy to setup a server not a problem because smart hacker > > types will be maintaining the server ] > Why make it hard to setup a server? Ease of having servers is a good > thing because the more people that run servers, the more people will > play. Nobody said that it _should_ be hard to set up the server. All that was said was that it is OK to expect a certain degree of technical competence of the part of server gods. It is not OK to expect more technical competence on the part of a client user than is e.g. required to install a typical shrink-wrapped MS-DOS or Mac program. > > I think we can build a good protocol which assumes nothing more of > > the client than that it has a bidirectional 8-bit channel to > > server with a bandwidth of at least 1-2 kBytes/second and round > > trip time of at most 100-200 ms. The class of such machines is > > vast and the rest can be built on top of that basis. > > Which bring back my earlier point of 4 fps. You'd need to change the > style of the game to play with 200 ms of net delay. Especially if a > packet gets dropped, and you suffer a round trip to get it resent. > Unfortunately, 4fps means less of the arcade feel that some people > want to have. 200 ms _round_trip_ at the outer end of playability. That means 100 ms to drop a packet one way or 10 fps. And nobody said that all servers have to run at that speed for all users. I just picked those numbers out of the air as what a good protocol can be designed to accomodate. Most people will of course have far better net connections. Carl Edman From crossfire-request Mon Apr 11 23:17:13 1994 Return-Path: Received: from sfi.santafe.edu (sfi.santafe.edu [192.12.12.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 11 Apr 1994 23:17:11 +0200 Received: by sfi.santafe.edu (4.1/SMI-4.1) id AA23492; Mon, 11 Apr 94 15:23:24 MDT Date: Mon, 11 Apr 94 15:23:24 MDT From: scott@santafe.edu (Scott D. Yelich) Message-Id: <9404112123.AA23492@sfi.santafe.edu> To: Benjamin Thomas Ketteridge Cc: Nick Williams , crossfire@ifi.uio.no Subject: Re: FTP site for crossfire In-Reply-To: Your message at 12:56:06 on Wed, 30 March 1994 References: <14592.765032166@mailhost.aber.ac.uk> Status: RO >>>>> "Benjamin" == Benjamin Thomas Ketteridge writes: Benjamin> Wow! Serious speed up in net performance Nick! Instead of Benjamin> taking half an hour to get a new version of crossfire - it Benjamin> took me about 2 minutes!!!!! I haven't been reading too much of the discussion... if this has been beaten to death, please tell me to read first and the post ... etc. What about playing performance? the UDP storm generated by crossfire really doesn't hold up well over 56kb links. Scott From crossfire-request Mon Apr 11 20:12:20 1994 Return-Path: Received: from welch.ncd.com (root@welch.ncd.com [192.43.160.250]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 11 Apr 1994 20:12:13 +0200 Received: from hemlock.ncd.com (root@hemlock.ncd.com [138.43.112.23]) by welch.ncd.com (8.6.8.1/8.6.6) with ESMTP id LAA01171 for ; Mon, 11 Apr 1994 11:11:04 -0700 Received: from localhost.ncd.com (lemke@localhost.ncd.com [127.0.0.1]) by hemlock.ncd.com (8.6.5/8.6.5.Beta11) with SMTP id LAA20680 for ; Mon, 11 Apr 1994 11:11:02 -0700 Message-Id: <199404111811.LAA20680@hemlock.ncd.com> X-Authentication-Warning: hemlock.ncd.com: Host localhost.ncd.com didn't use HELO protocol To: crossfire@ifi.uio.no In-reply-to: Message from quinet@montefiore.ulg.ac.be (Raphael Quinet) of Mon, 11 Apr 1994 01:56:43 +0200. Organization: Network Computing Devices, Mountain View, CA Reply-to: lemke@ncd.com Subject: Re: A few thoughts on client/server in multi-player games Date: Mon, 11 Apr 1994 11:11:00 PDT From: Dave Lemke Status: RO From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Date: Mon, 11 Apr 94 01:56:43 +0200 > I find Carl Edman's views very convincing. A two-digit number can be > transferred in less space than a 32-bit binary number. You don't have > to name the protocol commands "transfer_this_list_of_images_please", > "TMI" will do :-) > Sure, but what about command #7, where the "7" is stored in a single char? We don't need to use 32-bit numbers. We could use single chars when the value is small (int8), and two chars for greater values (int16), using 32-bit ints only for huge values. I already hear you say: "but you will need to translate all numbers, so why don't you use ASCII instead?". Simple: binary data consumes fewer bytes than ASCII data, and casting a char to an int is much faster than using atoi/itoa/sprintf/sscanf, etc... i've been involved in the development of a half-dozen or so client-server protocols (X font server, LBX, a number of NCD-proprietary), and i'll offer a few observations. - binary vs ascii. either can work fine -- choose the one that best solves the problem. byte swapping and data size is a red herring. byte swapping is easily solved by communicating the byte order of the client or server at startup time, and having one of them swap stuff as required. data size is worked around by defining things in terms of bytes or bits -- don't use 'long' or 'int'. check out the X protocol's usage of BYTE, CARD16, CARD32 etc. one thing you may want to do is force word padding, since a lot of archs get annoyed (or slow down) if you try to look at (say) a CARD32 that doesn't start on a word boundary. floating point is uglier, but its been handled in a number of X extensions -- take a look at XIE or PEX. i haven't thought enough about what crossfire needs to know which is better. ascii can be much easier to debug when you're developing the protocol, and if the messages are simple enough, its probably compact enough. but remember that decoding the ascii stream will take more effort than decoding a binary stream. a bunch of strcmp()s are a lot more expansive than a big switch statement that looks at the first message byte as an opcode. a binary protocol is also easier to make more uniform. you can lay out the packets to be a similar as possible, which speeds up decoding time. either form can be extended with similar ease, though you should specify the extension methods up front. - avoid the ftp thing completely, and build it into the protocol. when the server tells the client to display some new object, it sends the object description down to it, along with a tag it will use for any future references. having the server transport the data should be at least as fast as ftp, and attaching the tag to the packet is a safe way to keep things in sync. if the client gets too full of objects, or decides one is 'old', it simply tells the server. the server can also obsolete objects this way, if that becomes interesting (maybe you want to change the maps out from under a running server, or change a monster bitmap...) we use this concept a lot in LBX and its a major win in reducing bandwidth. (you may want to borrow some of the LBX code...) building in the transport avoids security issues -- if you let the client connect, then you must consider it secure enough to transport files. just make sure the client can't ask for anything the server doesn't want it to have. - make sure your connection protocol agrees on all possible options. if the client can't handle sounds, don't waste the time sending anything to do with sound. if the client is monochrome, make sure it gets bitmaps, not pixmaps, etc as for the rationale for client-server, i don't know if its needed or not, but i agree that it should be possible to make a non-X crossfire client. it shouldn't be too hard to make a Mac or Windows client, and if you want to make the game more popular, that's certainly a good goal. and this means data (maps, images, sounds) must be in some canonical format. ascii may be too general for maps (and the current crossfire map format should at least be compressed before putting it on the wire). one other thing i haven't seen discussed is the type of connection you want to use. since its multi-player, you have to be able to deal with different connection speeds to the same server. if one of the players is running at 9600 baud, and the others on the local ethernet, someone is likely to be unhappy. if you use TCP, it'll run at 9600 baud for everyone unless you start tossing frames. if you use UDP, you'll have an easier time keeping things in sync, but if the wrong packet gets tossed by the OS, a player could be very unhappy. you may want to check out xpilot. it uses UDP, but losing a packet is less catastrophic, and all the large data transfer is up-front. and as for using gprof to tune, you're not likely to get terrinbly far that way. i'd guess it shows lots of time in process_events() for the normal reason -- its primarily event driven, so it spends all its time waiting for a new event to come in or a new frame to occur. Dave From crossfire-request Mon Apr 11 18:02:33 1994 Return-Path: Received: from po2.andrew.cmu.edu (PO2.ANDREW.CMU.EDU [128.2.10.102]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 11 Apr 1994 18:02:19 +0200 Received: (postman@localhost) by po2.andrew.cmu.edu (8.6.7/8.6.4) id MAA09146 for crossfire@ifi.uio.no; Mon, 11 Apr 1994 12:02:08 -0400 Received: via switchmail; Mon, 11 Apr 1994 12:02:04 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Mon, 11 Apr 1994 12:00:48 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Mon, 11 Apr 1994 12:00:46 -0400 (EDT) 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; Mon, 11 Apr 1994 12:00:46 -0400 (EDT) Message-ID: Date: Mon, 11 Apr 1994 12:00:46 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: A few thoughts on client/server in multi-player games In-Reply-To: <9404110158.AA00987@capitalist.princeton.edu> References: <9404110158.AA00987@capitalist.princeton.edu> Status: RO "Carl Edman" writes: > Eric A. Anderson writes: > > Tyler Van Gorder writes: > > > [ use ftp to transfer pixmaps ] > > [ another program to transfer the fonts ] > > Yes, and how endlessly long was the list of bug reports caused by > people not downloading the proper set of fonts, or not having it in the > right directory or not having compiled for it ? None because it was all automated. It downloaded the bdf font, converted it to pcf of snf depending on what kind of server you had, and added it to the fontpath. No problems, no errors. If the font couldn't be downloaded, then the crossfire server wasn't running, so it didn't really matter. > [ not easy to setup a server not a problem because smart hacker > types will be maintaining the server ] Why make it hard to setup a server? Ease of having servers is a good thing because the more people that run servers, the more people will play. > I think we can build a good protocol which assumes nothing more of the > client than that it has a bidirectional 8-bit channel to server with a > bandwidth of at least 1-2 kBytes/second and round trip time of at most > 100-200 ms. The class of such machines is vast and the rest can be > built on top of that basis. Which bring back my earlier point of 4 fps. You'd need to change the style of the game to play with 200 ms of net delay. Especially if a packet gets dropped, and you suffer a round trip to get it resent. Unfortunately, 4fps means less of the arcade feel that some people want to have. -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 Mon Apr 11 14:15:33 1994 Return-Path: Received: from gyda.ifi.uio.no (0@gyda.ifi.uio.no [129.240.78.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 11 Apr 1994 14:15:32 +0200 Received: from thrall.cm.cf.ac.uk by gyda.ifi.uio.no ; Mon, 11 Apr 1994 14:15:29 +0200 Received: from cm.cf.ac.uk by thrall.cm.cf.ac.uk with SMTP (PP) id <10868-0@thrall.cm.cf.ac.uk>; Mon, 11 Apr 1994 13:13:18 +0100 Date: Mon, 11 Apr 94 13:13:16 BST From: Simon McIntosh-Smith Message-Id: <9404111213.AA01420@garnet.cm.cf.ac.uk> To: crossfire@ifi.uio.no Subject: Re: lights, action, sound! (longish) Status: RO > From: Nick Williams These ideas for light are superb, and would go a long way to making crossfire an all-time classic game. It would certainly add a lot of perhaps the only thing crossfire lacks - atmosphere! > Modified objects: > * elves and thieves should be able to see in dark naturally. > * fireborn should emit light. > * vampires, bats, etc, should have be scared of light. > * a glowing crystal should emit a low intensity light. Creatures with infra-vision like elves and halflings should be able to make out the monsters or anything warm, but the walls should still be cloaked in blackness, since most of them would be cold and wouldn't emit any detectable infra-radiation. So, only the creatures would show up while most of the room would be black - does this sound right to everyone? Of course you've then got the old AD&D problem - does an elf have both infra and normal vision going at the same time, or do you have to swap between the two (automatically or manually)? We'd have to make a decision and then stick to it... Sy Simon N. McIntosh-Smith, PhD candidate | Email : Simon.N.Smith@cm.cf.ac.uk Room M/1.36 Department of Computing Maths | Phone : +44 (0)222 874000 University of Wales, College of Cardiff | Fax : +44 (0)222 666182 PO Box 916, Cardiff, Wales, CF2 4YN, U.K. | Home : +44 (0)222 560522 Http : http://www.cm.cf.ac.uk:/People/Simon.Smith.html From crossfire-request Mon Apr 11 12:35:51 1994 Return-Path: Received: from barney.cs.city.ac.uk (root@barney.cs.city.ac.uk [138.40.91.8]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 11 Apr 1994 12:35:46 +0200 Received: from wilma.cs.city.ac.uk by barney.cs.city.ac.uk; Mon, 11 Apr 1994 11:40:02 +0100 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; Mon, 11 Apr 1994 11:33:16 +0100 (BST) Message-Id: <8heGRgG__5g9Qun41e@cs.city.ac.uk> Date: Mon, 11 Apr 1994 11:33:16 +0100 (BST) From: Nick Williams To: crossfire@ifi.uio.no Subject: lights, action, sound! (longish) Cc: Andy Whitcroft Status: RO Well, it's been a while since I posted my strange ideas on the development of crossfire, so here's some more! (Also, I think these ones are easy to do... discussion on that later). How about having light sources in crossfire. Both "natural" light and artificial. By default, a map would be naturally lit. However some maps (e.g. a dungeon or a house) may have a flag set saying "dark"/"indoors". Then players would not be able to see areas which are not lit. There could be torches on the walls, windows letting light in, or the player may carry around a torch, or use a spell of light. This would add much more atmosphere, methinks, and would allow neat effects. For example, bats would be able to see in the dark and could continue attacking you, but may be scared by the light and keep away from you. Vampires should, of course, receive damage from natural light. How to display light? Well, anywhere "normally" lit would be the normal display code. Anywhere lit dimly should be either converted to monochrome or stippled. And then anywhere else is black. As the number of light sources will always be small (always?), then overhead in computing light levels for a room will not be large. They could be computed for a map and then modified as objects with light output move, or they could be computed all the time, for only those spots within LOS (easier to hack in as experiment, but slower in the long run). When a player's view is generated, the light levels would be used as thresholds as to how to display any particular square, modified by a "see_in_dark" parameter of the player. A new flag would be needed on objects: light_output which would indicate range of any light emitted. Most objects, this would be zero. Candles could have 1 or 2, fireballs should have 3 or so. Fireborn creatures could have a light-range of 2 or 3 (they'd be immune to vampires and bats et al, as they would run away from the light! An invaluable feature). With this, you could also make light absorbers.... As players would now have code which takes into account eyesight, you can easily introduce more. Whenever they get diseased, or injured, their eyesight could dim, or go red! (yes, I've been playing DOOM recently) :-). Too much light could cause blindness for a period of time. This would require objects to have two seperate parameters: light_range and light_intensity. Once this code was in place, you can add various effects: * fireballs actually light up a room. * creatures which are sensitive to light (a player needing to recover from a battle might light a large fire and stay near it....) * add blindness as an effect which players may experience (a fireball explodes near you, you get blinded). * players can wield a firebrand and then attack with fire... New spells: * light, magically increases light values of all squares within a certain radius * dark. opp. of light of course * curse of blindness * pyrotechnics: cause any light sources to boost their value temporarily, thus blinding people. See fireworks later. New objects: * candle (when applied, toggle light_output from 0 to lit (2, for example). Also, should consume hp and when hp <=zero, become junk). * torch. similar to candle, but with better range. * fire. similar to torch, but cannot be picked up or moved, just dropped at a point. will cause damage if walked into. (burning item -> fire) * firestarting kit. when applied, creates a fire in specified direction. * firework? when applied creates a fireball of small damage value, but with large light emitting value, blinding people. A spell of pyrotechnics could cause all objects in the area which have flame to create a firework moving in a random direction. The more intense the light emitted by the original object, the more fireworks created. For example a large fire could create many fireworks, all moving in different directions. Modified objects: * elves and thieves should be able to see in dark naturally. * fireborn should emit light. * vampires, bats, etc, should have be scared of light. * a glowing crystal should emit a low intensity light. Possible Cute Features But Unsure of Feasability: * crystals and gems might "sparkle" even if in area of no light, as they can pick up light from elsewhere.... * "natural" light could be modified by time of day, so that if it is night where the server is running, the towns become dark... Scared of light could be worked out as whenever a creature enters a square of light intensity greater than a paramaterised value, its SCARED flag becomes set. Of course, since a player may become blind, or may not be able to see in the dark, you need to rely on sounds more.... Comments? (I wouldn't mind having a go at implementing some of this) Nick Nick Williams, Systems Architecture Research Centre, City University, London, EC1V 0HB. UK. Web: http://web.cs.city.ac.uk/finger?njw E-mail: njw@cs.city.ac.uk (MIME and ATK) Work Telephone: +44 71 477 8551 Work Fax: +44 71 477 8587 From crossfire-request Mon Apr 11 05:53:50 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 11 Apr 1994 05:53:49 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Mon, 11 Apr 1994 05:53:48 +0200 Date: Mon, 11 Apr 1994 05:53:48 +0200 Message-Id: <199404110353.13252.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: Klaus Elsbernd's message of Sat, 09 Apr 1994 12:20:29 +0200 <199404091020.MAA06803@isg-204.dfki.uni-kl.de> Subject: Re: encounter maps Status: RO +--- Klaus Elsbernd: | 1) We introduce a keyword in the definition of maps or the | archetypes which allows to randomly place groundfloor in maps. [...] Actually, this sounds like a nice idea to generalize the object definition. I'd like to see it as oneof face ytree_2.111 ytree_2.112 endoneof However, this isn't necessarily the best way to get the functionality you want. One alternative route is to add to the artifact functionality, and allow people to specify objects to be artifacts. (That would necessitate more flexible naming of artifacts. "jungle of big trees" is OK, but it gets tedious to find meaningful names to distinguish types after a while). The other thing I wanted to say, is that it is _TRIVIAL_ to add varied encounter maps to the game. Just draw some suitably sized tiles similar to the ones found in lib/maps/terrain, and change the line sprintf(buf2, "%s/%s/%s_%ld", LibDir, MapDir, mapobs[x][y]->race, RANDOM()%2+1); here ---------------^ in server/encounter.c. Now, there's one catch - that code assumes there's the same number of alternatives for all terrain types. I've already sent a patch to do determine that number dynamically to Mark. (Map creators can actually make their own terrains, and use them by setting the race variable in the trees in their magic forests or whatever. E.g.: Object tree race /peterm/terrain-tiles/forest end The code will then use /peterm/terrain-tiles/forest_1 or .../forest_2) Kjetil T. From crossfire-request Mon Apr 11 05:22:42 1994 Return-Path: Received: from erau.db.erau.edu (db.erau.edu [155.31.1.13]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 11 Apr 1994 05:22:40 +0200 Received: by erau.db.erau.edu (Smail3.1.28.1 #2) id m0pqCb1-0007w7C; Sun, 10 Apr 94 23:23 EDT Date: Sun, 10 Apr 1994 23:23:08 -0400 (EDT) From: Jeff Judkins Subject: Re: Baby Ketteridge announcement! To: Benjamin Thomas Ketteridge cc: crossfire@ifi.uio.no In-Reply-To: <14103.765902520@mailhost.aber.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Sat, 9 Apr 1994, Benjamin Thomas Ketteridge wrote: > Dear all, [those who know me :-) ] > I am very happy to announce, at last, that Laura and I now have a wonderful > daughter, who we have decided to name Hannah Rachel. She was born by > Caesarian Section at 16:42 on Friday 8th April. > > At birth, Hannah weighed 8lbs 10.25oz, her head had a circumfirence of > 14.5inches, and she was 21.5inches long. She was 16 days late, having been > expected on 23rd March, but both she and Laura are fine, :-) , though they'll > be in hospital until at least Wednesday, recovering from the operation. > > That's all the news for now, I don't know when all this is going to sink in! > > Thanks, Ben. > > +--------------------------------------------------------------------------+ > | _|--|_ o | Disclaimer: I've got a baby, and I don't know what to do! | > | (\/) +---+ +---------------------------------+-------------------------+ > | vv / \ | But I'm over the moon! :-) | btk@aber.ac.uk | > +--------------+---------------------------------+-------------------------+ Congratulations... I think... ;-) +============================+=========================================+ | This message courtesy of: | "Do you want me to make your life a | | | living hell?" | | Jeff Judkins | "Sorry, I'm not looking for a relation- | | judkinsj@erau.db.erau.edu | ship right now, but thanks for asking" | +============================+=========================================+ Kill'em all and then just let God sort out the mess. From crossfire-request Mon Apr 11 05:15:19 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id ; Mon, 11 Apr 1994 05:15:19 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Mon, 11 Apr 1994 05:15:18 +0200 Date: Mon, 11 Apr 1994 05:15:18 +0200 Message-Id: <199404110315.13218.bera.ifi.uio.no@ifi.uio.no> To: cedman@Princeton.EDU CC: crossfire@ifi.uio.no In-reply-to: "Carl Edman"'s message of Sun, 10 Apr 94 22:37:57 -0400 <9404110237.AA01037@capitalist.princeton.edu> Subject: Re: A few thoughts on client/server in multi-player games Status: RO Ah yes, a persistent cache is nice, perhaps even a must. That doesn't necessitate always referring to images by name, though. If we keep the "pixmap array" in the server for every connection (~10kB), we can have this communication: Server doesn't yet know whether the client has the images a firewall or fireorc: Server -> client have? firewall fireorc Client -> server send fireorc have 2123 2788 Server -> client transmit fireorc 567 .... 567 bytes of arbitrary 8-bit binary .... map 1,1 1,2 2123 map 2,2 2788 The above isn't perfect, and introduces even more state in the server -- it needs to keep a queue of names it has asked for with "have?". Datapoint: the average length of a bitmap name is currently 12 characters. I look forward to seeing your proposal. It will be good to have a concrete protocol to comment on. We could even calculate the number of bytes needed :-) Kjetil T. From crossfire-request Mon Apr 11 04:41:50 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 11 Apr 1994 04:41:48 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA04861; Sun, 10 Apr 94 22:41:44 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA01037; Sun, 10 Apr 94 22:37:57 -0400 Date: Sun, 10 Apr 94 22:37:57 -0400 From: "Carl Edman" Message-Id: <9404110237.AA01037@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: A few thoughts on client/server in multi-player games Reply-To: cedman@Princeton.EDU Status: RO Tyler Van Gorder writes: > ok..here is a thought: When a client connects: ask the user if they > want to download the "standard library" of pixmaps. If yes, then > automate an ftp process to download the crossfire.pix files that will > be standard to all servers. Then additionally ask if they want to > download the pixmap files that our specific to that server. If these > files get time stamps...then the user can be made aware that changes > to those pixmap files have changed. From the last time they > downloaded them. Thus, what you have done is after the initial > downloading of the files...the client side has all pixmaps. Second, > if you spawn an external ftp process to do the downloading....then > the server does not have to worry about sending pixmaps to the > client. Let ftp deal with it. :> Oh please don't ! That both _requires_ the client to have a working anonymous ftp which many potential clients (like PCs and Macs) don't have _and_ it imposes a large startup cost on slow connections (which is after all, what we are concerned with here). No, the ideal protocol would work something like this: Server -> client map 1 2 floor map 1 3 floor map 1 4 firewall [ Client notices the name 'firewall'. Checks its cache (either on disk or in memory) and find it has no image associated with the name 'firewall' ] Client -> Server send firewall Server -> Client transmit firewall 567 .... 567 bytes of arbitrary 8-bit binary .... [ Client converts the binary image into whatever the locally preferred format is (possibly adjusting colors and resolution to the local preference) and (if that is its policy) caches the result ] a.s.o. The server never sends any image or sound to the client unless the client specifically asks for it. On the other hand, if the client asks for it the server will send immediately as often as the client asks for it. That means that clients can decide on their own caching policies. Clients short on hard disk space but long on bandwidth, can only cache binaries in memory for a limited time within each session. Other clients will always save all binaries and never delete them. Yet other clients may choose to delete binaries which haven't been used for a number of weeks. All that is up to the client and the server doesn't care. For animation I think the best solution is to have animated images contain several "subimages" and instructions on how quickly they should be flipped through. As soon as the client has the animated image, the server never again has to worry about animations. I'm working on a draft of a possible crossfire protocol. I've there interest, I can post it in a few days. Carl Edman From crossfire-request Mon Apr 11 04:14:47 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 11 Apr 1994 04:14:44 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA01344; Sun, 10 Apr 94 22:14:38 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA01012; Sun, 10 Apr 94 22:10:51 -0400 Date: Sun, 10 Apr 94 22:10:51 -0400 From: "Carl Edman" Message-Id: <9404110210.AA01012@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: A few thoughts on client/server in multi-player games Reply-To: cedman@Princeton.EDU Status: RO quinet@montefiore.ulg.ac.be (Raphael Quinet) writes: > Carl Edman (cedman@cedman.remote.Princeton.EDU) wrote: > > Mark Wedel writes: > > > I don't think all images and sounds should be referred to by name > > > when the client is actually playing. > > > > [stuff deleted] > > But haven't we learned from the old map numbering scheme what > > happens with fixed numbering schemes when several independent > > groups work on the code ? *Please* let us avoid that pitfall in > > the client/server design. > > First note: remember that you never need to send the binary data for > the sounds. The rplay daemon will fetch the sound files from the > nearest RPTP server if they aren't available locally. So you only > need to send the filenames. If you chose that route you virtually guarantee that the crossfire client will never run on anything but X machines. That throws out of the window one of the beauties of the client/server design -- that you can write a client to work well on virtually any hardware platform. How far do you think the World Wide Web would have gone if you needed to have an X terminal to use it ? With just a little bit of care in the protocol design stage the possibilities for expansion are without bounds. For example, I imagine that at some point a programmer should be able to easily write a "dumb" client which only connects to the server, puts the terminal in a raw mode and then just streams data between the socket and the users tty. Then the vast majority of home users with non-networked Macs and PCs and will be able to run serial clients at home (which for most people is the best place to play games). > But the pictures are another problem: if a client doesn't have the > pixmap for one object, it will have to get it from the CrossFire > server. Exactly. If you go to the lengths of having a naming scheme, caching, conversion a.s.o. for the images, why not just use the same scheme for the sounds (but probably with a separate name space) ? > There are two solutions if we want to save bandwidth: > - when the client connects to a server, the server sends all > filenames (images and sounds) to the client, along with their id > numbers. Then, each time a sound or image has to be used, its id > number (2 or 4 bytes) is sent instead of its name. That is a false economy. On the systems on which bandwidth _really_ matters i.e. SLIP or 57.6 kBps fixed line systems you are trading adding several minutes to the startup time for being able to shave off some unnoticeable 2 or 3 bytes off a reference to a new image or sound. The user visible performance gain for that is completely below the threshold of noticability (and may even be a loss as I explained in the article about the efficiency of ASCII vs. binary I posted yesterday). Of course this proposal also gives away a list of all images and sounds to the user -- arguably not as bad a problem of cheating as sending the entire map to the client, but nevertheless. > - same as above, except that nothing is sent when the client > connects. The names and id numbers are sent when they are needed > for the first time. The server will have to keep a table with what > has been sent to every client. Hmmm... Not a good idea... Exactly. The solution is always to refer to all images and sounds by name. (Not necessarily filename -- the name is just a handle used by the client and the server. Either one may use it (or some mangling of it) as a filename, but that really shouldn't be a requirement). > The list of id's will be created when the server starts, so there is > no need to worry about compatibility, etc. Static lists of numbers > are a bad thing (look at the old maps), but dynamically-created lists > save a lot of time... They may (almost certainly do) save time internally for the client and the server. They do not save bandwidth and do not enhance performance over slow links. When Fred Brooks called premature optimization the root of all programming evil, he knew what he was talking about. > I'm not sure that ASCII would help, at least on the server side. > Unix comes with various functions to convert short and long integers > in network or host format (htons, htonl, etc.), so this shouldn't be > a problem. But we need to keep the packets as short as possible, in > order to save bandwidth and processing time. Ah, yes, there's the rub. As I've been trying to explain in a recent post on this subject, ASCII packets are not necessarily larger or slower. And contrary to popular perception parsing ASCII packets does not have a signficant impact on CPU performance. Remember that we are not trying to parse arbitray ambiguous natural language sentences here like an adventure game would. Those packets will almost always be machine generated and clear. Generating and parsing such ASCII can be done extremely quickly. > Obviously (?), the server will have to send its data in binary form. > You don't want to waste your time translating a map from binary to > ASCII in the server, then back from ASCII to binary again, do you? > BTW, how do you want to translate a map to ASCII? What the server sends the client is not the map. What it sends is a description of what the player would see (for which the client then chooses an appropriate graphical representation). There is nothing equivalent in the server. I hope you are not suggesting that the server should just take some arbitrary internal structure which it happens to have now and just write(fd,&my_struct,sizeof(my_struct)) it out. Doing so would both impose great constraints on the internal structure of the client and make any deep changes in the server almost impossible once there is an installed basis of clients. > But, as was mentionned in a previous message, ASCII might help when > an "old" client wants to send a new command to a server. IMHO, only > unrecognized commands should be sent in ASCII format. All other > commands should be sent in binary, with all pre-processing done by > the client. But why have two distinct instruction formats ? It doesn't gain you much if anything in bandwidth, or CPU time and it does cost you human readability, ease of extension, and a huge number of bugs which are invariably created when sharing binary data on the net between computers of different archictectures (and that is not just my assumption -- it is an empirical fact). Carl Edman From crossfire-request Mon Apr 11 04:02:30 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 11 Apr 1994 04:02:29 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA29262; Sun, 10 Apr 94 22:02:21 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA00987; Sun, 10 Apr 94 21:58:33 -0400 Date: Sun, 10 Apr 94 21:58:33 -0400 From: "Carl Edman" Message-Id: <9404110158.AA00987@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: A few thoughts on client/server in multi-player games Reply-To: cedman@Princeton.EDU Status: RO Eric A. Anderson writes: > Tyler Van Gorder writes: > > [ use ftp to transfer pixmaps ] > This is probably not the best idea because some people may not be > able to setup their machine to do anonymous ftp even if they can run > a crossfire server on it. Moreover, automatic ftp isn't really easy. > Why not just have another program do the transfer? This is what I > did in the original crossfire server implementation. I downloaded > the font every time you started playing to make sure that people had > a current font. Yes, and how endlessly long was the list of bug reports caused by people not downloading the proper set of fonts, or not having it in the right directory or not having compiled for it ? The server will be for us hackers where we can extend the game. We will maintain them ourselves, so minor problems in stability, system requirements or complicated installation really isn't that terrible a problem for the server. The client however should be idiot^H^H^H^H^Hunsophistcated user proof if we don't want to be flooded with bug reports. Also when designing the protocol we should make minimal assumptions about what facilities are available to the client. Remember that most potential client machines in the world do not have a) X, b) rplay, c) ftp, d) good preemptive multi-tasking and e) most importantly competent technical support for the installation of games. I think we can build a good protocol which assumes nothing more of the client than that it has a bidirectional 8-bit channel to server with a bandwidth of at least 1-2 kBytes/second and round trip time of at most 100-200 ms. The class of such machines is vast and the rest can be built on top of that basis. Carl Edman From crossfire-request Mon Apr 11 03:01:33 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 11 Apr 1994 03:01:33 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Mon, 11 Apr 1994 03:01:34 +0200 Date: Mon, 11 Apr 1994 03:01:34 +0200 Message-Id: <199404110101.12453.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: "Eric A. Anderson"'s message of Sun, 10 Apr 1994 20:42:43 -0400 (EDT) Subject: Re: A few thoughts on client/server in multi-player games Status: RO +--- Eric Anderson: | [suggestion to use a hybrid] I _am_ partial to optimising the heck out of common operations like monster updates, but how much do we gain? Let's say that on a 15x15 board (11x11), a quarter of the squares change. That's 168 bytes (90) with your binary protocol. How big is an IP fragment? (I'd love to know!) +--- | We are currently trying to do ~10 updates a second. Lowering this | number to 4 would substantially reduce the bandwidth needed. Ugh. Yes, but I wouldn't want to play it at 4 fps. With the current state of the Internet, playing across the Atlantic is not possible. Aim for WAN's (ping round-trip < 100ms). For me, this means all of Scandinavia, I think that is acceptable. +--- | If you only need a two digit number, send it as a byte, not a 32-bit | number. But then you have locked yourself to a range. ASCII protocols' main virtue is easy extensibility. +--- | Moreover, commands like TMI aren't particularily good because they | don't really tell you what the command is trying to do, which was | the whole point of trying to have ascii commands. It was meant to stand for "Transfer Multiple Images" - I (obviously) think it is mnemonic, better than "7" in any case :-) Kjetil T. From crossfire-request Mon Apr 11 02:54:23 1994 Return-Path: Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 11 Apr 1994 02:54:22 +0200 Received: (postman@localhost) by andrew.cmu.edu (8.6.7/8.6.4) id UAA22249 for crossfire@ifi.uio.no; Sun, 10 Apr 1994 20:54:22 -0400 Received: via switchmail; Sun, 10 Apr 1994 20:54:21 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Sun, 10 Apr 1994 20:53:16 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Sun, 10 Apr 1994 20:53:12 -0400 (EDT) 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; Sun, 10 Apr 1994 20:53:11 -0400 (EDT) Message-ID: <4he9xre00Zk2AqmKQ1@andrew.cmu.edu> Date: Sun, 10 Apr 1994 20:53:11 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: A few thoughts on client/server in multi-player games In-Reply-To: <199404110031.RAA23861@corpse.ecst.csuchico.edu> References: <199404110031.RAA23861@corpse.ecst.csuchico.edu> Status: RO Tyler Van Gorder writes: > [ use ftp to transfer pixmaps ] This is probably not the best idea because some people may not be able to setup their machine to do anonymous ftp even if they can run a crossfire server on it. Moreover, automatic ftp isn't really easy. Why not just have another program do the transfer? This is what I did in the original crossfire server implementation. I downloaded the font every time you started playing to make sure that people had a current font. -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 Mon Apr 11 02:43:21 1994 Return-Path: Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 11 Apr 1994 02:43:17 +0200 Received: (postman@localhost) by andrew.cmu.edu (8.6.7/8.6.4) id UAA21948 for crossfire@ifi.uio.no; Sun, 10 Apr 1994 20:43:11 -0400 Received: via switchmail; Sun, 10 Apr 1994 20:43:10 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Sun, 10 Apr 1994 20:42:47 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Sun, 10 Apr 1994 20:42:44 -0400 (EDT) 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; Sun, 10 Apr 1994 20:42:43 -0400 (EDT) Message-ID: Date: Sun, 10 Apr 1994 20:42:43 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: A few thoughts on client/server in multi-player games In-Reply-To: <9404101445.AA00373@capitalist.princeton.edu> References: <9404101445.AA00373@capitalist.princeton.edu> Status: RO "Carl Edman" writes: > But haven't we learned from the old map numbering scheme what happens > with fixed numbering schemes when several independent groups work on > the code ? *Please* let us avoid that pitfall in the client/server > design. So why not use a compromise setup? Have some messages use a numbered format, and have a special number which is an ascii extention. -- I don't really believe that it matters what format the messages from the client to the server take because there will not be very many of them. I do believe it is important the format of the messages from the server to the client. There will be a lot of them. For example, if you will assume that there will never be more than a 16x16 board, you can send updates for a particular monster in 3 bytes. 1 for the x and y coordinates in the upper and lower nybble, and 2 for the pixmap id. This is substantially more compressed than sending an ascii string describing the same thing. Moreover, it is faster to process. Kjetil Torgrim Homme writes: > +--- > | The most important thing is that several commands should be sent in > | a single packet, to avoid the 40 bytes overhead. > > I agree - getting the number of packets down must be the main > goal. Games like XPilot and Crossfire really kill local networks > because they require so many updates per second. I agree too, but I believe the only real solution is to lower the number of updates/second. We are currently trying to do ~10 updates a second. Lowering this number to 4 would substantially reduce the bandwidth needed. Moreover, it would reduce problems with latency. > I find Carl Edman's views very convincing. A two-digit number can be > transferred in less space than a 32-bit binary number. You don't have > to name the protocol commands "transfer_this_list_of_images_please", > "TMI" will do :-) If you only need a two digit number, send it as a byte, not a 32-bit number. Moreover, commands like TMI aren't particularily good because they don't really tell you what the command is trying to do, which was the whole point of trying to have ascii commands. -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 Mon Apr 11 02:31:48 1994 Return-Path: Received: from corpse.ecst.csuchico.edu (corpse.ecst.csuchico.edu [132.241.5.10]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 11 Apr 1994 02:31:47 +0200 Received: (from tvangod@localhost) by corpse.ecst.csuchico.edu (8.6.8/8.6.6) id RAA23861; Sun, 10 Apr 1994 17:31:30 -0700 From: Tyler Van Gorder Message-Id: <199404110031.RAA23861@corpse.ecst.csuchico.edu> Subject: Re: A few thoughts on client/server in multi-player games To: quinet@montefiore.ulg.ac.be (Raphael Quinet) Date: Sun, 10 Apr 1994 17:31:29 -0700 (PDT) Cc: cedman@Princeton.EDU, crossfire@ifi.uio.no In-Reply-To: <9404102049.AA19147@montefiore.ulg.ac.be> from "Raphael Quinet" at Apr 10, 94 10:49:17 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: 2010 Status: RO > > Carl Edman (cedman@cedman.remote.Princeton.EDU) wrote: > > Mark Wedel writes: > > > I don't think all images and sounds should be referred to by name > > > when the client is actually playing. > > > > [stuff deleted] > > But haven't we learned from the old map numbering scheme what happens > > with fixed numbering schemes when several independent groups work on > > the code ? *Please* let us avoid that pitfall in the client/server > > design. > > > First note: remember that you never need to send the binary data for the > sounds. The rplay daemon will fetch the sound files from the nearest RPTP > server if they aren't available locally. So you only need to send the > filenames. But the pictures are another problem: if a client doesn't have > the pixmap for one object, it will have to get it from the CrossFire server. > > There are two solutions if we want to save bandwidth: > - when the client connects to a server, the server sends all filenames (images > and sounds) to the client, along with their id numbers. Then, each time a > sound or image has to be used, its id number (2 or 4 bytes) is sent instead > of its name. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ok..here is a thought: When a client connects: ask the user if they want to download the "standard library" of pixmaps. If yes, then automate an ftp process to download the crossfire.pix files that will be standard to all servers. Then additionally ask if they want to download the pixmap files that our specific to that server. If these files get time stamps...then the user can be made aware that changes to those pixmap files have changed. From the last time they downloaded them. Thus, what you have done is after the initial downloading of the files...the client side has all pixmaps. Second, if you spawn an external ftp process to do the downloading....then the server does not have to worry about sending pixmaps to the client. Let ftp deal with it. :> Tyler. From crossfire-request Mon Apr 11 01:56:48 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be (vm1.ulg.ac.be [139.165.32.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 11 Apr 1994 01:56:47 +0200 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Mon, 11 Apr 94 01:55:44 +0200 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA20462; Mon, 11 Apr 94 01:56:43 +0200 Date: Mon, 11 Apr 94 01:56:43 +0200 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9404102356.AA20462@montefiore.ulg.ac.be> To: crossfire@ifi.uio.no Subject: Re: A few thoughts on client/server in multi-player games Status: RO > Kjetil Torgrim Homme (kjetilho@ifi.uio.no) wrote: > > +--- > | BTW, how do you want to translate a map to ASCII? > > Err, that's the native format of a map. But it's a mute point anyway, > since whole maps shouldn't be sent. It's unnecessary, and if you do > that, the cheater will know the magical effects of items, or what > magic words guards respond to, or ... > Well, I should have made things clear. Sorry if this wasn't the case. What I meant is: the server has its internal copy of the map; when it sends a part of the map to the client (if the LOS computation is done by the server), it will have to send the list of objects, floor textures, etc. Inside the server, everything is in binary form (cross-refs, id numbers, flags, etc.), except for the objects names. So what I wanted to say is: it would be stupid and time-consuming to translate all that to ASCII in the server, then do the reverse translation in the client. I feel that the server should send the list of objects to the client, not only the pictures, because the client will then be able to do more processing if it knows the list of animations for each object (given by the server when the client connects). Also, when the player asks for the description of an object, the client will be able to do it without asking anything to the server. And finally, this would open the way for a new improvement: some clients could display their own pixmaps for some objects. Why not? If I want to write a client that uses 64x64 pixmaps... :-) Of course, the server won't send all its internal info about each object. It should only send what is directly available to the player. > I find Carl Edman's views very convincing. A two-digit number can be > transferred in less space than a 32-bit binary number. You don't have > to name the protocol commands "transfer_this_list_of_images_please", > "TMI" will do :-) > Sure, but what about command #7, where the "7" is stored in a single char? We don't need to use 32-bit numbers. We could use single chars when the value is small (int8), and two chars for greater values (int16), using 32-bit ints only for huge values. I already hear you say: "but you will need to translate all numbers, so why don't you use ASCII instead?". Simple: binary data consumes fewer bytes than ASCII data, and casting a char to an int is much faster than using atoi/itoa/sprintf/sscanf, etc... -Raphael From crossfire-request Mon Apr 11 01:18:02 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 11 Apr 1994 01:18:01 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Mon, 11 Apr 1994 01:17:59 +0200 Date: Mon, 11 Apr 1994 01:17:59 +0200 Message-Id: <199404102317.12323.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: Raphael Quinet's message of Sun, 10 Apr 94 22:49:17 +0200 <9404102049.AA19147@montefiore.ulg.ac.be> Subject: Re: A few thoughts on client/server in multi-player games Status: RO +--- Raphael Quinet: | - same as above, except that nothing is sent when the client | connects. The names and id numbers are sent when they are needed | for the first time. The server will have to keep a table with | what has been sent to every client. Hmmm... Not a good idea... Why not? The server already has to keep such a table if players use pixmaps... Actually, the _client_ should decide the reference number, so that it can simply return the Pixmap value (which is just a 32 bit reference number). The value 0 would mean that the image hasn't been transferred yet. +--- | The most important thing is that several commands should be sent in | a single packet, to avoid the 40 bytes overhead. I agree - getting the number of packets down must be the main goal. Games like XPilot and Crossfire really kill local networks because they require so many updates per second. +--- | BTW, how do you want to translate a map to ASCII? Err, that's the native format of a map. But it's a mute point anyway, since whole maps shouldn't be sent. It's unnecessary, and if you do that, the cheater will know the magical effects of items, or what magic words guards respond to, or ... I find Carl Edman's views very convincing. A two-digit number can be transferred in less space than a 32-bit binary number. You don't have to name the protocol commands "transfer_this_list_of_images_please", "TMI" will do :-) Kjetil T. From crossfire-request Sun Apr 10 22:49:22 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be (vm1.ulg.ac.be [139.165.32.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sun, 10 Apr 1994 22:49:21 +0200 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Sun, 10 Apr 94 22:48:18 +0200 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA19147; Sun, 10 Apr 94 22:49:17 +0200 Date: Sun, 10 Apr 94 22:49:17 +0200 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9404102049.AA19147@montefiore.ulg.ac.be> To: cedman@Princeton.EDU, crossfire@ifi.uio.no Subject: Re: A few thoughts on client/server in multi-player games Status: RO Carl Edman (cedman@cedman.remote.Princeton.EDU) wrote: > Mark Wedel writes: > > I don't think all images and sounds should be referred to by name > > when the client is actually playing. > > [stuff deleted] > But haven't we learned from the old map numbering scheme what happens > with fixed numbering schemes when several independent groups work on > the code ? *Please* let us avoid that pitfall in the client/server > design. > First note: remember that you never need to send the binary data for the sounds. The rplay daemon will fetch the sound files from the nearest RPTP server if they aren't available locally. So you only need to send the filenames. But the pictures are another problem: if a client doesn't have the pixmap for one object, it will have to get it from the CrossFire server. There are two solutions if we want to save bandwidth: - when the client connects to a server, the server sends all filenames (images and sounds) to the client, along with their id numbers. Then, each time a sound or image has to be used, its id number (2 or 4 bytes) is sent instead of its name. - same as above, except that nothing is sent when the client connects. The names and id numbers are sent when they are needed for the first time. The server will have to keep a table with what has been sent to every client. Hmmm... Not a good idea... The list of id's will be created when the server starts, so there is no need to worry about compatibility, etc. Static lists of numbers are a bad thing (look at the old maps), but dynamically-created lists save a lot of time... > > I personally don't see the need of the client to be extremly > > efficient in how it sends to the server as really important. I doubt > > the client will be sending a lot of data. However, how the server > > sends to the client is much more important. But it also depends on > > what information the client knows. > > I agree completely. Remember that every TCP/IP packet (and UDP/IP is > not much better) has 40 bytes overhead. Most single commands sent > using either ASCII or binary in either direction will be completely > swamped by that in any case. The only exception will be the actual > contents of sounds and images and they will be transferred by an agreed > upon, simple binary standard in any case. Given that we agree on that, > why not use ASCII to send commands and descriptions either way given > all the advantages I listed in my other recent post on this subject ? > A few weeks ago, there has been a discussion about the server->client protocol. The most important thing is that several commands should be sent in a single packet, to avoid the 40 bytes overhead. (There were lots of useful info in these messages. Read them again if you forgot...) I'm not sure that ASCII would help, at least on the server side. Unix comes with various functions to convert short and long integers in network or host format (htons, htonl, etc.), so this shouldn't be a problem. But we need to keep the packets as short as possible, in order to save bandwidth and processing time. Obviously (?), the server will have to send its data in binary form. You don't want to waste your time translating a map from binary to ASCII in the server, then back from ASCII to binary again, do you? BTW, how do you want to translate a map to ASCII? But, as was mentionned in a previous message, ASCII might help when an "old" client wants to send a new command to a server. IMHO, only unrecognized commands should be sent in ASCII format. All other commands should be sent in binary, with all pre-processing done by the client. -Raphael From crossfire-request Sun Apr 10 22:34:42 1994 Return-Path: Received: from nef.ens.fr (nef.ens.fr [129.199.96.12]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sun, 10 Apr 1994 22:34:41 +0200 Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0) Id AA08123 ; Sun, 10 Apr 1994 22:34:35 +0200 Received: from melilot.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05) id AA16922; Sun, 10 Apr 94 22:34:30 +0200 Date: Sun, 10 Apr 94 22:34:30 +0200 From: belabas@clipper.ens.fr (Karim Belabas) Message-Id: <9404102034.AA16922@clipper.ens.fr> To: crossfire@ifi.uio.no Subject: key bindings Status: RO Sorry for the inconvenience if this is already adressed in one of the help/man files, but I've never seen the subject discussed here, and haven't found anything in a quick overview of the code (v0.90.4, hopefully the most recent one). Shouldn't it be possible to have a personnal set of default bindings ? Say, have a resource telling crossfire where to find a file describing what key bindings it should use, in addition to LIBDIR/def_keys. I've got a set of favored bindings ('P' is pickup 4, 'p' pickup 0, 'N' say Name, and so on) which I thought cumbersome to redefine each time I played a new character. I installed the game here, so I'm able to add those few definitions directly to the character file, but well... K.B. From crossfire-request Sun Apr 10 16:51:40 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sun, 10 Apr 1994 16:51:39 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA26101; Sun, 10 Apr 94 10:49:23 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA00373; Sun, 10 Apr 94 10:45:35 -0400 Date: Sun, 10 Apr 94 10:45:35 -0400 From: "Carl Edman" Message-Id: <9404101445.AA00373@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: A few thoughts on client/server in multi-player games Reply-To: cedman@Princeton.EDU Status: RO Mark Wedel writes: > I don't think all images and sounds should be referred to by name > when the client is actually playing. > > Doing some handshaking at startup to agree on integer values for each > image/sound to use when the game is running seems like a very > reasonable and fast way to do it. Whether these integers are passed > as binary values (probably 2 bytes), or ascci characters (probably 4 > characters, but could be 5 some day) might be less relevant. But haven't we learned from the old map numbering scheme what happens with fixed numbering schemes when several independent groups work on the code ? *Please* let us avoid that pitfall in the client/server design. > I personally don't see the need of the client to be extremly > efficient in how it sends to the server as really important. I doubt > the client will be sending a lot of data. However, how the server > sends to the client is much more important. But it also depends on > what information the client knows. I agree completely. Remember that every TCP/IP packet (and UDP/IP is not much better) has 40 bytes overhead. Most single commands sent using either ASCII or binary in either direction will be completely swamped by that in any case. The only exception will be the actual contents of sounds and images and they will be transferred by an agreed upon, simple binary standard in any case. Given that we agree on that, why not use ASCII to send commands and descriptions either way given all the advantages I listed in my other recent post on this subject ? > For example, if the client knows about the entire map, either all > that stuff needs to be stored on the client end (which would be > really unsecure, and not especially feasible for those sites that add > new archetypes and maps), or that information needs to be sent down > the wire. I agree. And because different sites will extend the server in various ways, using ASCII 'commands' (what the client sends to the server) and 'descriptions' (what the server sends to the client with the exception of the contents of images/sounds which are a little different) is much better because it is less likely to lead to name space conflicts. > Depending on many factors, sending an entire map with > various object information may not be any better than sending small > pieces as required. Absolutely. That is one of the arguments I make for why server-side LOS is not really inefficient, in particular for people with slow links. Carl Edman From crossfire-request Sun Apr 10 15:44:08 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sun, 10 Apr 1994 15:44:07 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA19365; Sun, 10 Apr 94 09:44:01 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA00279; Sun, 10 Apr 94 09:40:13 -0400 Date: Sun, 10 Apr 94 09:40:13 -0400 From: "Carl Edman" Message-Id: <9404101340.AA00279@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: A few thoughts on client/server in multi-player games Reply-To: cedman@Princeton.EDU Status: RO Philip Brown writes: > >>>>[From Carl Edman] > 1. Do all possible processing on the client. ... > > 2. In an ideal world this would mean doing all LOS calculations > on the client (as a matter of fact, that is what my last > prototype did). ... So LOS has to be done on the server. > > > But that directly contradicts the idea behind #1, which is to reduce > load on the server. Exactly. That is why I listed them one after another -- to indicate that while in general as much processing as possible should be shifted to the client, both for performance reasons and to give more flexibility in client design, LOS is an exception. > Let me remind you that currently line-of-sight processing is BUGGY > as-is. it will require more processing than it now uses. kinda > backwards to our goals. I've found the current algorithm to work well in most circumstances so I don't see any pressing need to replace it with something more CPU intensive, but if you say it has to be done, I can dig out a couple of conversations I had a few years back on the net and in email about fast table-driven LOS algorithms needed for my project at the time. I recall that it was fast enough to allow four or five players on one of the really slow machines of the day. Considering that todays typical servers are on average about ten times faster, fourty or fifty players shouldn't be a problem with it. And if that isn't enough, we can start to actually optimize the algorithm. > It just means that people will ahve to define maps with challenges > that don't require something as simple as not being able to see the > entire map. > > After all, there ARE scrolls of magic mapping, are there not? It's > still pretty silly to design a challenge that can be nullified by one > single game item, let alone cheating. Magic mapping is really pretty limited compared to downloading the entire map and having the client do the LOS calculations. Magic maps give a rough idea of the shape of the dungeon and are today already blocked in all situations where they would be _really_ useful. Downloading the map to the client and trusting the honesty of its programmer tells the player the exact location and idenity of every single treasure and (by inference) the location of every single hidden door. Furthermore it also requires constantly updating the location of every moving monster in the entire map. In that regard doing LOS on the server is actually a positive virtue for us with the low speed links as it saves us a lot of traffic both whenever we enter a map and when any monster we can't see moves. That is positively a win for players who travel, only moving a couple of squares in every map before entering the next one. In the maps which players spend a lot of time totally exploring them, server-side LOS may break even in total bandwidth consumed. However the data will not all be transferred at once when entering the map (which leads to player-noticeable delays). Instead it trickles in all the time while playing at a relatively low rate. That is a far preferable situation. In any case, I still think regardless of the above server-side LOS is essential to prevent cheating. If you don't, Greshams Law applies: Dishonest clients drive out honest clients. In effect, you'll have eliminated LOS from crossfire. Now whether that is either a) a good idea anyway or b) worth doing for the possible simplification of client/server is debatable. But if we decide to do that, please let's do so explicitly. It will save us a lot of hard programming and angry accusations later. > The server should always refer to pictures and sounds by name > (or possibly persistent unique integers). For example, it might > send the command 'disp 15 -34 vampire' to tell the client that > the player sees a vampire a coordinate (15,-34)..... > > Again, that goes against the previously brought up issue. using ascii > is too verbose for the 14.4kbps SLIP model. Only viable method is > constant predefined integer indexes. Direct, binary, 16-bit integer, > I might add. > > FOr byteorder, you just have to specify for your client at compile > time. It will then have to switch byte-order if needed. This is > trivial integer math that takes comparatively zero time. I've written and posted a long article dealing with these issues in detail, though you may not have had a chance to read it before responding to this article. If you do read it and still disagree, please let me know. Carl Edman From crossfire-request Sun Apr 10 12:21:53 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, 10 Apr 1994 12:21:51 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA26165 (5.67a8/IDA-1.5 for ); Sun, 10 Apr 1994 03:21:36 -0700 Received: by bolero.rahul.net id AA19912 (5.67a8/IDA-1.5); Sun, 10 Apr 1994 03:21:36 -0700 Date: Sun, 10 Apr 1994 03:21:36 -0700 From: Mark Wedel Message-Id: <199404101021.AA19912@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Re: A few thoughts on client/server in multi-player games Cc: elsbernd@dfki.uni-kl.de Status: RO Process events can hopefully be slimmed down a bit. By separating two a list of active (alive) and non active (static) objects, that should quicken things up. Also, if all floating point (speed and stuff) is converted to integers, that will probably also speed things up. Also, depending on the system, the floating point may not hurt quite as much as it does mine, but I don't know. I would guess that those values would transfer reasonably close across systems and architectures. I think the big thing with client/server will be that it will free up quite a bit of memory on the server side. Also, there are lots of misc. small functions that will be moved over. I also think one of the advantages to the client/server will be the ability to better play over a limited speed link. Those hoping for major reduction of cpu time by the server may be disappointed. --Mark From crossfire-request Sun Apr 10 11:48:12 1994 Return-Path: <<@isg-204.dfki.uni-kl.de:elsbernd@dfki.uni-kl.de>> Received: from uni-kl.de (mmdf@stepsun.uni-kl.de [131.246.136.50]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sun, 10 Apr 1994 11:48:10 +0200 Received: from isg-204.dfki.uni-kl.de by stepsun.uni-kl.de id aa04312; 10 Apr 94 11:48 MET DST Received: from dfki.uni-kl.de (isg-201.dfki.uni-kl.de [131.246.241.71]) by isg-204.dfki.uni-kl.de (8.6.4/8.6.4) with ESMTP id LAA00311; Sun, 10 Apr 1994 11:48:02 +0200 Message-Id: <199404100948.LAA00311@isg-204.dfki.uni-kl.de> To: crossfire@ifi.uio.no, philb@soda.berkeley.edu cc: elsbernd@dfki.uni-kl.de Subject: Re: A few thoughts on client/server in multi-player games In-reply-to: Your message of "Sun, 10 Apr 1994 02:17:12 MET DST." <199404100917.AA18685@bolero.rahul.net> Date: Sun, 10 Apr 1994 11:48:01 +0200 From: Klaus Elsbernd Status: RO From: Mark Wedel > I've actually run some crossfire (albeit single player) with profiling > information, and the big cpu hog is the process_events function > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 38.9 257.66 257.66 10671 24.15 31.31 _process_events [3] > 11.3 332.36 74.70 38211 1.95 2.23 _get_ob_diff [10] > 10.0 398.96 66.60 mcount (841) > 3.1 419.61 20.65 184745 0.11 0.18 _get_variable [18] > 2.9 438.75 19.14 10738 1.78 1.78 _draw_color_pix [21] > 2.3 453.90 15.15 305860 0.05 0.05 _update_position [24] > 1.6 464.32 10.42 3975 2.62 2.92 _expand_sight [28] That sounds sad. Does that mean, that one can't expect much more performance if we change to a client server model. Perhaps the values change when there are more players. (But I don't think that) MfG Klaus From crossfire-request Sun Apr 10 11:17:43 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, 10 Apr 1994 11:17:36 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA23008 (5.67a8/IDA-1.5 for ); Sun, 10 Apr 1994 02:17:13 -0700 Received: by bolero.rahul.net id AA18685 (5.67a8/IDA-1.5); Sun, 10 Apr 1994 02:17:12 -0700 Date: Sun, 10 Apr 1994 02:17:12 -0700 From: Mark Wedel Message-Id: <199404100917.AA18685@bolero.rahul.net> To: crossfire@ifi.uio.no, philb@soda.berkeley.edu Subject: Re: A few thoughts on client/server in multi-player games Status: RO I don't think all images and sounds should be referred to by name when the client is actually playing. Doing some handshaking at startup to agree on integer values for each image/sound to use when the game is running seems like a very reasonable and fast way to do it. Whether these integers are passed as binary values (probably 2 bytes), or ascci characters (probably 4 characters, but could be 5 some day) might be less relevant. I personally don't see the need of the client to be extremly efficient in how it sends to the server as really important. I doubt the client will be sending a lot of data. However, how the server sends to the client is much more important. But it also depends on what information the client knows. For example, if the client knows about the entire map, either all that stuff needs to be stored on the client end (which would be really unsecure, and not especially feasible for those sites that add new archetypes and maps), or that information needs to be sent down the wire. Depending on many factors, sending an entire map with various object information may not be any better than sending small pieces as required. I've actually run some crossfire (albeit single player) with profiling information, and the big cpu hog is the process_events function (I have since split the player portions away from it, but haven't played enough to see how that changes things). That function consumes about half of the total cpu time of crossfire. Beyond that, there is no single function in crossfire that consumes a lot of cpu time. get_ob_diff actually consumes a fair amount (about 25% of what process events does). get_variable and draw_color_pix both consume about the same amount, which is about 1/12'th of what process_events does. Actually, here is a portion of the information: granularity: each sample hit covers 2 byte(s) for 0.00% of 662.78 seconds % cumulative self self total time seconds seconds calls ms/call ms/call name 38.9 257.66 257.66 10671 24.15 31.31 _process_events [3] 11.3 332.36 74.70 38211 1.95 2.23 _get_ob_diff [10] 10.0 398.96 66.60 mcount (841) 3.1 419.61 20.65 184745 0.11 0.18 _get_variable [18] 2.9 438.75 19.14 10738 1.78 1.78 _draw_color_pix [21] 2.3 453.90 15.15 305860 0.05 0.05 _update_position [24] 1.6 464.32 10.42 3975 2.62 2.92 _expand_sight [28] 1.5 474.31 9.99 21841 0.46 0.46 _write [31] 1.4 483.37 9.06 326905 0.03 0.03 _memccpy [34] 1.3 492.29 8.92 33467 0.27 0.27 _read [35] 1.2 500.33 8.04 _ParsePixels [36] 1.2 508.33 8.00 29376 0.27 0.27 _select [37] 1.1 515.72 7.39 184745 0.04 0.31 _set_variable [15] 1.1 522.82 7.10 193145 0.04 0.04 _hashstr [40] 1.0 529.42 6.60 288059 0.02 0.05 _fgets [26] Not all that many of these functions will ever be in the client. draw_color_pix definately will be. But beyond that, it is hard to say. As such, I am not sure how much difference it will make for the client to be doing a lot of work, especially if it is not really secure to do so, or makes things more complicated. These values will vary from system to system. The general usage of how much each function uses is pretty consitent run to run on my system. Having multiple players may shift it some, but if they are on different maps, probably not that much (as there will just be more objects). --Mark From crossfire-request Sun Apr 10 11:13:17 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, 10 Apr 1994 11:13:16 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id CAA26994 for crossfire@ifi.uio.no; Sun, 10 Apr 1994 02:13:07 -0700 From: Philip Brown Message-Id: <199404100913.CAA26994@soda.berkeley.edu> Subject: Re: client/server? To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Sun, 10 Apr 1994 02:13:06 -0700 (PDT) In-Reply-To: <199404090435.AA17806@bolero.rahul.net> from "Mark Wedel" at Apr 8, 94 09:35:45 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 2119 Status: RO >>>>[From Mark Wedel] I would freeze new versions if I actually got the idea that client/server woudl be seriously worked on. The problem I see is that if I freeze it (no new releases), if it takes 6 months to do client/server, then other people will likely have put out patches or their own versions that would need to get merged in or lost. Fair enough (sort of :-) How about, at some point, you "freeze" the code, but allow official patch diffs for bugs, etc. So, while you could still provide bug updates, the tree that client/server people are working from would not change. (ie they'd work from the PRE-diff'd tree, since they're going to change most stuff anyways. When done, THEN they could hand-diff in anything that still might be relevant) If people put out there own "special" versions in the interim.. well, this will always happen. I don't think we should spend too much time worrying about it You're certainly correct in saying that client/server issues are still needed to be decided beore something will get done, thou :-) About the byte-order issue... It's NOT THAT HARD, people! X depends on a particular byte ordering, and certain bit lengths. This is GREAT, because there are defines in the Imake/header stuff. You can pull out of the X support files, information on the machine you are compiling on. You can pull out: byte order bit order what to use for 8-bit value what to use for 16-bit value what to use for 32-bit value What else do you need, folks?!! (Please don't give me any "what about windoze/mac, whatever" stuff. Those are specific architechtures, not the nice general architechture that X allows. Whoever does the client port for those machines is going to be working on a completely machine-specific source tree anyways. They'll just hard-code in the appropriate values, most likely.) PS: I would personally love to do coding on this, but 1) I'm starting a new job, so I have way less time. 2) I'm going to be under some nasty non-disclosure agreements, so it is not beneficial for me to do actual code :-/ Philip From crossfire-request Sun Apr 10 10:46:07 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, 10 Apr 1994 10:46:03 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id BAA25461 for crossfire@ifi.uio.no; Sun, 10 Apr 1994 01:45:55 -0700 From: Philip Brown Message-Id: <199404100845.BAA25461@soda.berkeley.edu> Subject: Re: A few thoughts on client/server in multi-player games To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Sun, 10 Apr 1994 01:45:53 -0700 (PDT) In-Reply-To: <9404090403.AA12208@capitalist.princeton.edu> from "Carl Edman" at Apr 9, 94 00:03:17 am X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1812 Status: RO >>>>[From Carl Edman] 1. Do all possible processing on the client. ... 2. In an ideal world this would mean doing all LOS calculations on the client (as a matter of fact, that is what my last prototype did). ... So LOS has to be done on the server. But that directly contradicts the idea behind #1, which is to reduce load on the server. Let me remind you that currently line-of-sight processing is BUGGY as-is. it will require more processing than it now uses. kinda backwards to our goals. It just means that people will ahve to define maps with challenges that don't require something as simple as not being able to see the entire map. After all, there ARE scrolls of magic mapping, are there not? It's still pretty silly to design a challenge that can be nullified by one single game item, let alone cheating. 5. Remember that an increasingly large part of the net is connected with relatively low bandwidth such as 57.6 kBps leased lines or even 14.4 kBps SLIP lines. True. I'm one of those people. ALthough I find response is better through "term" instead of SLIP. The server should always refer to pictures and sounds by name (or possibly persistent unique integers). For example, it might send the command 'disp 15 -34 vampire' to tell the client that the player sees a vampire a coordinate (15,-34)..... Again, that goes against the previously brought up issue. using ascii is too verbose for the 14.4kbps SLIP model. Only viable method is constant predefined integer indexes. Direct, binary, 16-bit integer, I might add. FOr byteorder, you just have to specify for your client at compile time. It will then have to switch byte-order if needed. This is trivial integer math that takes comparatively zero time. From crossfire-request Sat Apr 9 23:23:38 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 9 Apr 1994 23:23:35 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA18317; Sat, 9 Apr 94 17:23:29 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA18852; Sat, 9 Apr 94 17:20:07 -0400 Date: Sat, 9 Apr 94 17:20:07 -0400 From: "Carl Edman" Message-Id: <9404092120.AA18852@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: A few thoughts on client/server in multi-player games Reply-To: cedman@Princeton.EDU Status: RO Peter Mardahl writes: > I'm no expert on protocols, BUT: sending things as ascii any more > than necessary is a mistake, I think. Binary is very concise. Not really. A typical int has the same length has four ASCII characters. That is certainly not much shorter than the average word length used for an english command, in particular as you would chose relatively short words for the most common objects and commands. Add to that the fact that an ASCII command is just as long as it needs to be even if different commands vary greatly in length while binary commands tend to be fixed in size and you may very well end up with ASCII commands using less bandwidth. Also remember that most really slow connections use some form of compression which very likely will compress a binary and an ASCII format to pretty much the same tokens. Considering that these compression algorithms have been optimized for text, the ASCII stream may actually work even better here. This discussion is moot in any case as most of the user visible delays will happen when transferring pictures and sounds which haven't been cached and that would happen in a binary format in any case. > I think if the coding of the protocol is accessible and > straightforward, it will still be accessible enough for people on > other platforms to use. > > For example, you could distribute the core of a protocol, which could > be portable to any machine whatsoever.... Define a few standard > structs, etc. perhaps even some higher level functions for > interpreting packets. It is just not worth it. 1. If you chose a binary standard for structures to transmit over the net, you'll have to deal with the fact that ints on different target machines are 16, 32, and 64 bits large. You'll have to deal with the fact that different machines have different byte order. You'll have to compensate for the fact that different compilers pad the same structure in different ways. All of these things can and have been dealt with on UN*X machines in the past. But even on them it is a lot of hassle. If you go to other popular machines on which the client at least should be able to run like Macs and PCs, you are even worse off as there is virtually no developer support for dealing with these issues. I can _guarantee_ to you today that if you chose a binary protocol, dozens if not hundreds of programmer hours will be spent fixing bugs caused by these differences. 2. Dont' underestimate the value of a human readable, understandable and writable format. It is a boon during debugging if you can read and understand the traffic between client and server. If you can't, very likely you'll end up having to write a tool which does the decoding for you. That will of course just be another program which has to be kept up to date with every protocol change. It is also very useful if both the client and server can just punt on messages which they don't understand and print them out to the user/programmer. Also it helps that on occasion users can just type in the odd message which their client hasn't learned to generate yet (e.g. to test a new option). 3. If there are several quasi-independent teams of programmers continuing to extend the protocol (as was the case with crossfire), refering to things by name and not by number (as a binary protocol would) avoids many conflicts. For example, there are quickly going to be a dozen different assignments for the first couple command numbers you don't assign in your protocol. How is a client or server to deal with that when connected to a slightly different strain ? And how are the various improvements going to merged together again if that involves changing all but one of the clients/servers at the same time ? This really is just the same problem just on a different level as we had with the old map numbering scheme. You will agree that going to a name scheme turned out to be a great improvement. > You gain a lot in simplicity using ascii, but it may lose you a > factor of two in net performance, a very big deal on 14.4k..... Not really as I explained above. Please believe me on this point. As you may have guessed from my intensity on this matter, I've written binary protocols for use on the net before and have lived to regret it. ** :-) Carl Edman ** And not only me. For another case just consider that otalk/ntalk incompatibility which plagues the net. With an ASCII interface that would never have happend and the net would have a universal, reliable way to communicate in real time today. From crossfire-request Sat Apr 9 16:42:12 1994 Return-Path: Received: from mailsun.aber.ac.uk (isode@mailsun.aber.ac.uk [144.124.16.7]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 9 Apr 1994 16:42:10 +0200 Received: from athene.dcs.aber.ac.uk by mailsun.aber.ac.uk with SMTP (PP); Sat, 9 Apr 1994 15:42:05 +0100 Received: from thorbb by athene.dcs.aber.ac.uk (4.1/aberclient-4.0-cs-1.1) id AA26231; Sat, 9 Apr 94 15:42:02 BST To: crossfire@ifi.uio.no Subject: Baby Ketteridge announcement! Date: Sat, 09 Apr 1994 14:42:00 +0000 Message-Id: <14103.765902520@mailhost.aber.ac.uk> From: Benjamin Thomas Ketteridge Status: RO Dear all, [those who know me :-) ] I am very happy to announce, at last, that Laura and I now have a wonderful daughter, who we have decided to name Hannah Rachel. She was born by Caesarian Section at 16:42 on Friday 8th April. At birth, Hannah weighed 8lbs 10.25oz, her head had a circumfirence of 14.5inches, and she was 21.5inches long. She was 16 days late, having been expected on 23rd March, but both she and Laura are fine, :-) , though they'll be in hospital until at least Wednesday, recovering from the operation. That's all the news for now, I don't know when all this is going to sink in! Thanks, Ben. +--------------------------------------------------------------------------+ | _|--|_ o | Disclaimer: I've got a baby, and I don't know what to do! | | (\/) +---+ +---------------------------------+-------------------------+ | vv / \ | But I'm over the moon! :-) | btk@aber.ac.uk | +--------------+---------------------------------+-------------------------+ From crossfire-request Sat Apr 9 12:20:50 1994 Return-Path: <<@isg-204.dfki.uni-kl.de:elsbernd@dfki.uni-kl.de>> Received: from uni-kl.de (mmdf@stepsun.uni-kl.de [131.246.136.50]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 9 Apr 1994 12:20:43 +0200 Received: from isg-204.dfki.uni-kl.de by stepsun.uni-kl.de id aa23182; 9 Apr 94 12:20 MET DST Received: from dfki.uni-kl.de (isg-201.dfki.uni-kl.de [131.246.241.71]) by isg-204.dfki.uni-kl.de (8.6.4/8.6.4) with ESMTP id MAA06803; Sat, 9 Apr 1994 12:20:31 +0200 Message-Id: <199404091020.MAA06803@isg-204.dfki.uni-kl.de> To: Mark Wedel cc: crossfire@ifi.uio.no, elsbernd@dfki.uni-kl.de Subject: Re: encounter maps In-reply-to: Your message of "Sat, 09 Apr 1994 00:14:21 MET DST." <199404090714.AA24834@bolero.rahul.net> Date: Sat, 09 Apr 1994 12:20:29 +0200 From: Klaus Elsbernd Status: RO From: Mark Wedel >1) At a certain level, some of the encoutner maps are just nuisance >encounters, and the map can provide a good place to rest. ... > A few possible solutions (corresponding to the numbers above) > >1) Have the monsters on the encounter map of the same difficulty as the >map the encounter is on. So that if the map is difficult 10 and a >random encounter happens, there are going to be some pretty tough >monsters. I agree, this should make it more real. I've got some ideas about to the encounter maps, and would like to do some coding in that area. I think we could fill the encounter maps with some more interesting things if we introduce something like the following: 1) We introduce a keyword in the definition of maps or the archetypes which allows to randomly place groundfloor in maps. I'm not shure if this should happen in the archetypes or in the map definition. If we chose the first it would show like this Object ytree_2 name tree oneof random face ytree_2.111 face ytree_2.112 face ytree_2.113 face ytree_2.114 end no_pick 1 slow_move 1 editable 8 end For some maps this should be specified in the maps (in the case of encounter maps) At loadtime of the map, one would randomly choose the face of that tree. This should make the encounter maps not to look all the same. On the other hand it might be used to simulate wind or daylight .... if we introduce instead of random other keywords like wind, daytime... 2) One of the things, which I didn't like in the game is, that there is random food everywhere, when there is no thing/person/idea, where it should come from. Perhaps we should introduce something like a kitchen, bakery or and that I would like to propose too we should create sheeps, cows,... which, when get killed leave food around. Those animals can easily placed in the encounter maps on random positions. So there would be a need to enter these maps if somenone is hungry. I liked to send this mail next month. But Mark brought it into the discussion. If no one has arguments against it, I would like to beginn next month. MfG Klaus From crossfire-request Sat Apr 9 12:15:25 1994 Return-Path: Received: from menja.ifi.uio.no (1232@menja.ifi.uio.no [129.240.82.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id ; Sat, 9 Apr 1994 12:15:25 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by menja.ifi.uio.no ; Sat, 9 Apr 1994 12:15:24 +0200 Date: Sat, 9 Apr 1994 12:15:24 +0200 Message-Id: <199404091015.18988.menja.ifi.uio.no@ifi.uio.no> To: master@rahul.net CC: crossfire@ifi.uio.no In-reply-to: Mark Wedel's message of Sat, 9 Apr 1994 00:14:21 -0700 <199404090714.AA24834@bolero.rahul.net> Subject: Re: map.thoughts Status: RO +--- Mark Wedel: | I've changed the encounter code so that random encounter maps can no | longer happen if the source map is difficulty 1 (which most every | town is). That should solve problem of encoutners in towns. NO! This is definitely the wrong thing to do - encounter maps are meant to happen on the world overview maps, which usually have no monsters, and hence are level 1. Your change will make encounters happen exclusively in places like the tabb-church. +--- | The problem this means is that you might have some path through a | forest, and just 5 minutes later, you get encoutner maps on it as | you re-tract your steps. This is not a problem, IMHO this is the way it should work - remember, these are "random encounters" - something out of the ordinary happening as you move from one place to another. +--- | 1) Have the monsters on the encounter map of the same difficulty as | the map the encounter is on. So that if the map is difficult 10 and | a random encounter happens, there are going to be some pretty tough | monsters. It should still be possible to have difficult encounter maps in easy maps (cf. mountains in world maps). Choosing and inserting appropriate monsters into the map doesn't seem trivial to do == I wouldn't bother implementing it :-) +--- | 2) When loading a map for the first time, determine which hexes will | be random encounter areas, and turn the rest into normal terrain. | This way, once you find a path without any encoutners, it will | remain like that until the map is reset. Like I said, this will change the meaning of encounter maps to being random scenery instead. Personally, I think it is a thrill to go through jungles and the like as a low level character, wondering if I will encounter something behind the next tree. +--- | 3) Decrease the chance of random encounter maps. Yeah, 25% may be a little high. On the other hand, if you stick to the beaten path, or walk along the shore, you won't get many (any) encounter maps. +--- | Another thing to do would be add a field to the map structure that | when set, means that no random encounter maps will be generated for | that map. This way, many old maps would not need to have all the | terrain converted to have encoutners be disabled. Now _this_ is what should have been done from the beginning :-) I would invert the meaning of the flag, BTW - set the flag if you want encounters. That way there'll be even less problems with old maps :-) This has been brought up before in a different context. A little more than a year ago (4 days, to be exact :-), I wrote: +--- Kjetil T: | Maybe we could allow the map-object (ie. the first object in the | .oo-file) to contain modifiers. Ie., if it had no_magic, all objects | contained in that map would get that as a default value. I know this | might slow down map-loading, especially if we allowed general | modifiers - but I can't think of any other attribute which would | make sense on a global sense. Hmm, this idea is a little different from Mark's idea, I see now. Basically, I would implement it so that the objects would be initialised from the map-object sans the variables which have meaning for the map->map_object (msg, hp, x, y - more?) instead of the empty object. With this in place, you could make small regions in your map where the object flag "no_encounter" was set to 0 (which, come to think of it, would have the same effect as setting "race" to 0 - race is the string holding the terrain name for that sort of tile). That would mean that in this case, the flag could be in the map-structure. Pro: slight savings of memory, although the cost of a bit in each object is negligble in itself. Con: complicates code. Incidentally, some obscure keyword must be chosen to represent it to get this saving unless you change the parser. (if you add a flag and keyword, it must be in the object structure) I'll supply patches for the above if there's interest. I hope my stream of conciousness mode didn't make this indecipherable. Kjetil T. From crossfire-request Sat Apr 9 09:15:05 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 Apr 1994 09:14:45 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA29453 (5.67a8/IDA-1.5 for ); Sat, 9 Apr 1994 00:14:22 -0700 Received: by bolero.rahul.net id AA24834 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Sat, 9 Apr 1994 00:14:21 -0700 Date: Sat, 9 Apr 1994 00:14:21 -0700 From: Mark Wedel Message-Id: <199404090714.AA24834@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: map.thoughts Status: RO I've looked over the code, and a a few notes: An encounter can happen anyplace where there is a 3x3 area of terrain, all of that terrain being encounter type terrain (which, as of now, I believe is desert, forest, hills, jungle, mountains, plains (grass) and swamp. The reason you usually don't get random encounters in town is that few towns have a 3x3 area of this type of terrain. However, the starting city actually does have this, in the keep area in the lower left (south west) area. There is a terrain type 'grass_only', which does not have random encounters. No comparable archetypes exist for brush, jungle, etc. I've changed the encounter code so that random encounter maps can no longer happen if the source map is difficulty 1 (which most every town is). That should solve problem of encoutners in towns. The problems I see with encounter maps right now is this: 1) At a certain level, some of the encoutner maps are just nuisance encounters, and the map can provide a good place to rest. 2) A piece of terrain that did not have an encounter map may have one the next time you step on it, provided the 3x3 rule above is not a problem (note also that none of the hexes can contain a living object, or be an encoutner map). The problem this means is that you might have some path through a forest, and just 5 minutes later, you get encoutner maps on it as you re-tract your steps. 3) Encounter maps can happen a lot. Right now, there is a 1:4 chance that when you enter a terrain type that is of encoutner type, it will create an encounter map (provided by the 3x3 rule). I think in the dtabb/church, probably about half a dozen encounter maps were created. A few possible solutions (corresponding to the numbers above) 1) Have the monsters on the encounter map of the same difficulty as the map the encounter is on. So that if the map is difficult 10 and a random encounter happens, there are going to be some pretty tough monsters. 2) When loading a map for the first time, determine which hexes will be random encounter areas, and turn the rest into normal terrain. This way, once you find a path without any encoutners, it will remain like that until the map is reset. 3) Decrease the chance of random encounter maps. If #2 happens, this will be less of a problem, because new random encoutners would not e (be) created by walking ove the old terrain. I think as an immediate solution, I'll add an option in config.h that allows/disallows random encounters. Another thing to do would be add a field to the map structure that when set, means that no random encounter maps will be generated for that map. This way, many old maps would not need to have all the terrain converted to have encoutners be disabled. --Mark From crossfire-request Sat Apr 9 06:36:10 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 Apr 1994 06:36:06 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA21636 (5.67a8/IDA-1.5 for ); Fri, 8 Apr 1994 21:35:46 -0700 Received: by bolero.rahul.net id AA17806 (5.67a8/IDA-1.5); Fri, 8 Apr 1994 21:35:45 -0700 Date: Fri, 8 Apr 1994 21:35:45 -0700 From: Mark Wedel Message-Id: <199404090435.AA17806@bolero.rahul.net> To: eanders+@CMU.EDU, philb@soda.berkeley.edu Subject: Re: client/server? Cc: crossfire@ifi.uio.no Status: RO Certainly deciding what the client handles and what the server handles will be very important. This will form a key to what the client and server communicate to each other. I know quite a bit about X, but lack a lot of knowledge about the actual protocols, and what will work best and so on. I would freeze new versions if I actually got the idea that client/server woudl be seriously worked on. The problem I see is that if I freeze it (no new releases), if it takes 6 months to do client/server, then other people will likely have put out patches or their own versions that would need to get merged in or lost. Also, most changes are bug fixes or not really major changes. I would think that some work could progress on the split without a totally frozen version. If I actually get a request of something like 'we are about ready to actually start coding client/server, please releasea version that will be stable for a while', I would probably do so. Right now, as I see it, most of client/server is still on the drawing board, and I don't want to freeze new versions for 6 months. --Mark From crossfire-request Sat Apr 9 06:24:30 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 Apr 1994 06:24:27 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA20546 (5.67a8/IDA-1.5 for ); Fri, 8 Apr 1994 21:24:11 -0700 Received: by bolero.rahul.net id AA17213 (5.67a8/IDA-1.5); Fri, 8 Apr 1994 21:24:09 -0700 Date: Fri, 8 Apr 1994 21:24:09 -0700 From: Mark Wedel Message-Id: <199404090424.AA17213@bolero.rahul.net> To: crossfire@ifi.uio.no, jason.fosback@mccaw.com Subject: Re: HELP! crossfire 0.90.4 Status: RO I am not sure how much encounter maps add to the game. For example, I believe it was the church in dtabb where I got random encounters on the grass. This gave me a great place to rest an re-gain hitpoints. The gnolls and orcs that were there were easy to kill. And in fact, in one case, the encounter map saved my life as I was surrounded by skeletons and ghost with few HP left and wondered onto one. A worthwhile change would probably be to make it so that a map can not have any encounters on it. As far as I know, it is possible to make more encounter maps (different layout of the forest, and so on.) I think right now, there are 2 for each terrain type. --Mark From crossfire-request Sat Apr 9 07:27:18 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 9 Apr 1994 07:27:16 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA23930; Sat, 9 Apr 94 00:06:39 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA12208; Sat, 9 Apr 94 00:03:17 -0400 Date: Sat, 9 Apr 94 00:03:17 -0400 From: "Carl Edman" Message-Id: <9404090403.AA12208@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: A few thoughts on client/server in multi-player games Reply-To: cedman@Princeton.EDU Status: RO I've been reading this thread for some time and as I've thought about the issues involved in writing such a game for more years than I care to admit and have actually written a working prototype (or two or three or ... you get the idea) of such a game, please allow me to make a few points of varying signficance and generality in no particular order which this discussion has brought to mind. 1. Do all possible processing on the client. There are at least two reasons for that. First of all, the client is very likely to be less loaded than the server when there several players, so this is a performance win. It will also allow a higher maximum number of simultaneous players and you are more likely to find a willing and stable server when you don't put quite so high demands on its hardware. The second is that client side processing allows users to extensively and efficiently customize clients to their own preferences and local requirements. 2. In an ideal world this would mean doing all LOS calculations on the client (as a matter of fact, that is what my last prototype did). Unfortunately that will allow players to cheat in an undetectable fashion. In particular as maps become more and more complex and oriented towards puzzle solving and more and more users play and compete on the same server, such cheating becomes increasingly unacceptable. So LOS has to be done on the server. And, yes, I've seen the approaches which have been taken to beat this. They don't work. They will be broken and they have been broken. 3. A corollary to 1. is that you should communicate with the client on a high level. That means that the client sends the server complete commands describing one action. The server sends the client a description of what the player would perceive. How commands get entered into the client or how the world is described to the player should be matters which are left completely to the client. That is by no means should the server concern itself about such matters, as mouse clicks, graphics resolution, simple keystrokes, display size and the like of the client. Functionality like that of 'bind' in crossfire 0.90.4 should be purely implemented on the client size. 4. I believe that 3. is best accomplished by sending ASCII commands between client and server. Not only does this completely avoid the byte ordering problem, it also makes building and improving the interface very much simpler. As new commands are added to the server, players will always be able to just type them in (just as they do the rarer commands today) until the client is upgraded to produce them. Also as new 'descriptions' are created by the server which some clients don't yet understand they can always just be printed out as text on the client side (again, until it is upgraded). The efficiency gained by binary communication between client and server over a well-designed and unforgiving (after all it expects its input to be generated by a computer program) command parser is drowned out completely all the other computation which a crossfire server has to do. 5. Remember that an increasingly large part of the net is connected with relatively low bandwidth such as 57.6 kBps leased lines or even 14.4 kBps SLIP lines. There is no fundamental reason via a game like crossfire shouldn't run perfectly fine via connections like this if the designers of the protocol just take a little care. In particular it is very important to allow for various persistent caching policies on the client side. The server should always refer to pictures and sounds by name (or possibly persistent unique integers). For example, it might send the command 'disp 15 -34 vampire' to tell the client that the player sees a vampire a coordinate (15,-34). Then it would be up to the client to request a vampire image from the server (if it doesn't already have one) via a command like 'send vampire'. Pictures and sounds, BTW, should (in contradiction to 4.) be sent in a binary format. Just make sure that it is very simple and not too machine specific. If a client prefers a particular format, it can always convert the sent binary to that preferred format upon receipt and cache it in that format. 6. Not all the world is an X terminal. Please remember that when you design the protocol. Sure you want to design something which is implemented relatively easily under X, but there is also NeXTstep and even more importantly Macs and Windows. Much as many of us may dislike these GUIs don't forget that they are the vast majority of the installed hardware in the world and a significant fraction of the Internet. You won't even have to write those clients yourself. The user base for these systems is so huge that it will not be at all hard finding someone who'll love to do it for you (and won't even hate himself for it in the morning) as long as you don't make it completely impossible by silly protocol design. Much of the phenomenal success of the World Wide Web/Mosaic can be traced back to the fact that nice Mac and Windows interfaces are available. If you can be as open about how you design your protocol as the W3 people were, you might very well end up not just writing another ultima clone which a couple of us here on the net play, but create something which in a few years can give Origin a real run for their money in terms of popularity. BTW, much as I'd personally love to get involved more actively in writing the crossfire client/server, I've too little time in the foreseeable future to do the kind of job which this task deserves. However, if there is a NeXTstep client to be written, I demand the first shot at it. :-) Also, I could write a curses style client if that is possible and there is a demand. Finally, I'm also happy to discuss the above points in more detail. Carl Edman From crossfire-request Sat Apr 9 07:09:21 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 9 Apr 1994 07:09:20 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA02363; Sat, 9 Apr 94 01:09:15 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA12208; Sat, 9 Apr 94 00:03:17 -0400 Date: Sat, 9 Apr 94 00:03:17 -0400 From: "Carl Edman" Message-Id: <9404090403.AA12208@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: A few thoughts on client/server in multi-player games Reply-To: cedman@Princeton.EDU Status: RO I've been reading this thread for some time and as I've thought about the issues involved in writing such a game for more years than I care to admit and have actually written a working prototype (or two or three or ... you get the idea) of such a game, please allow me to make a few points of varying signficance and generality in no particular order which this discussion has brought to mind. 1. Do all possible processing on the client. There are at least two reasons for that. First of all, the client is very likely to be less loaded than the server when there several players, so this is a performance win. It will also allow a higher maximum number of simultaneous players and you are more likely to find a willing and stable server when you don't put quite so high demands on its hardware. The second is that client side processing allows users to extensively and efficiently customize clients to their own preferences and local requirements. 2. In an ideal world this would mean doing all LOS calculations on the client (as a matter of fact, that is what my last prototype did). Unfortunately that will allow players to cheat in an undetectable fashion. In particular as maps become more and more complex and oriented towards puzzle solving and more and more users play and compete on the same server, such cheating becomes increasingly unacceptable. So LOS has to be done on the server. And, yes, I've seen the approaches which have been taken to beat this. They don't work. They will be broken and they have been broken. 3. A corollary to 1. is that you should communicate with the client on a high level. That means that the client sends the server complete commands describing one action. The server sends the client a description of what the player would perceive. How commands get entered into the client or how the world is described to the player should be matters which are left completely to the client. That is by no means should the server concern itself about such matters, as mouse clicks, graphics resolution, simple keystrokes, display size and the like of the client. Functionality like that of 'bind' in crossfire 0.90.4 should be purely implemented on the client size. 4. I believe that 3. is best accomplished by sending ASCII commands between client and server. Not only does this completely avoid the byte ordering problem, it also makes building and improving the interface very much simpler. As new commands are added to the server, players will always be able to just type them in (just as they do the rarer commands today) until the client is upgraded to produce them. Also as new 'descriptions' are created by the server which some clients don't yet understand they can always just be printed out as text on the client side (again, until it is upgraded). The efficiency gained by binary communication between client and server over a well-designed and unforgiving (after all it expects its input to be generated by a computer program) command parser is drowned out completely all the other computation which a crossfire server has to do. 5. Remember that an increasingly large part of the net is connected with relatively low bandwidth such as 57.6 kBps leased lines or even 14.4 kBps SLIP lines. There is no fundamental reason via a game like crossfire shouldn't run perfectly fine via connections like this if the designers of the protocol just take a little care. In particular it is very important to allow for various persistent caching policies on the client side. The server should always refer to pictures and sounds by name (or possibly persistent unique integers). For example, it might send the command 'disp 15 -34 vampire' to tell the client that the player sees a vampire a coordinate (15,-34). Then it would be up to the client to request a vampire image from the server (if it doesn't already have one) via a command like 'send vampire'. Pictures and sounds, BTW, should (in contradiction to 4.) be sent in a binary format. Just make sure that it is very simple and not too machine specific. If a client prefers a particular format, it can always convert the sent binary to that preferred format upon receipt and cache it in that format. 6. Not all the world is an X terminal. Please remember that when you design the protocol. Sure you want to design something which is implemented relatively easily under X, but there is also NeXTstep and even more importantly Macs and Windows. Much as many of us may dislike these GUIs don't forget that they are the vast majority of the installed hardware in the world and a significant fraction of the Internet. You won't even have to write those clients yourself. The user base for these systems is so huge that it will not be at all hard finding someone who'll love to do it for you (and won't even hate himself for it in the morning) as long as you don't make it completely impossible by silly protocol design. Much of the phenomenal success of the World Wide Web/Mosaic can be traced back to the fact that nice Mac and Windows interfaces are available. If you can be as open about how you design your protocol as the W3 people were, you might very well end up not just writing another ultima clone which a couple of us here on the net play, but create something which in a few years can give Origin a real run for their money in terms of popularity. BTW, much as I'd personally love to get involved more actively in writing the crossfire client/server, I've too little time in the foreseeable future to do the kind of job which this task deserves. However, if there is a NeXTstep client to be written, I demand the first shot at it. :-) Also, I could write a curses style client if that is possible and there is a demand. Finally, I'm also happy to discuss the above points in more detail. Carl Edman From crossfire-request Sat Apr 9 05:59:05 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 Apr 1994 05:59:03 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA19706 (5.67a8/IDA-1.5 for ); Fri, 8 Apr 1994 20:58:51 -0700 Received: by bolero.rahul.net id AA15937 (5.67a8/IDA-1.5); Fri, 8 Apr 1994 20:58:49 -0700 Date: Fri, 8 Apr 1994 20:58:49 -0700 From: Mark Wedel Message-Id: <199404090358.AA15937@bolero.rahul.net> To: Inge.Fenstad@alkymi.unit.no, crossfire@ifi.uio.no Subject: Re: Buggy maps Status: RO That problem will have been fixed in the next version, which should be out sometime next week. --Mark From crossfire-request Sat Apr 9 03:40: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 ; Sat, 9 Apr 1994 03:40:28 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id SAA14398; Fri, 8 Apr 1994 18:40:19 -0700 From: Philip Brown Message-Id: <199404090140.SAA14398@soda.berkeley.edu> Subject: Re: client/server? To: eanders+@CMU.EDU (Eric A. Anderson) Date: Fri, 8 Apr 1994 18:40:17 -0700 (PDT) Cc: crossfire@ifi.uio.no In-Reply-To: <0hdSYsC00Zk2QckroW@andrew.cmu.edu> from "Eric A. Anderson" at Apr 8, 94 07:31:04 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1736 Status: RO >>>>[From Eric A. Anderson] > This is something which should get done soon, I think. > I'd undertake it, but I'm too clueless! X-programming > is largely mysterious to me, as are network protocols. Well, the simplest thing to get it started would be to separate out every single function which makes an X call into their own subdirectory. Then start moving as much of the "thinking" functionality into routines that call the client routines. No, no.. the first thing to do, is replace ALL X calls with CURSES calls. Only THEN can you truely make it the equal of nethack, and other fine games..... But seriously :-) I would personally advise a structural/functional analysis of the code. Get a list of all routines (easy to do, with ctags) then document what each of them does relating to X display issues. You also have to spec out _exactly_ what you want the client to handle, and hunt down all relavant stuff in the code to that, also. Once you have isolated all cases of "what displays when", then you can throw away the old X-biased groupings, and make your own groupings. "groupings" just being a set name, under which you can indicate functions For example : ManipulatePlayerInventory: pickup(),throw(),.. UpdateScreen: ... ChangeAttribute: ... ... ... etc When you have done all THAT, then you can start putting together a protocol with handling for each of those situations. Not that I think it's going to happen soon. Because yet again, emphasis is being put on the old way of doing things. Hopefully, some time in the near future, Mark is going to say "Okay, code is now FROZEN! all work will now commence on client/server breakup" and something will get done. From crossfire-request Sat Apr 9 01:32:20 1994 Return-Path: Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sat, 9 Apr 1994 01:32:18 +0200 Received: (postman@localhost) by andrew.cmu.edu (8.6.7/8.6.4) id TAA28837 for crossfire@ifi.uio.no; Fri, 8 Apr 1994 19:32:13 -0400 Received: via switchmail; Fri, 8 Apr 1994 19:32:13 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 8 Apr 1994 19:31:19 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 8 Apr 1994 19:31:04 -0400 (EDT) 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; Fri, 8 Apr 1994 19:31:04 -0400 (EDT) Message-ID: <0hdSYsC00Zk2QckroW@andrew.cmu.edu> Date: Fri, 8 Apr 1994 19:31:04 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: client/server? In-Reply-To: <199404081944.MAA03194@soda.berkeley.edu> References: <199404081944.MAA03194@soda.berkeley.edu> Status: RO Peter Mardahl writes: > Is anyone actually working on this? I've been working on implementing the Inter Client Exchange (ICE) protocol which is described by a document on ftp.x.org. I thought that once I finished that, then I would use it to start working on client server. > This is something which should get done soon, I think. > I'd undertake it, but I'm too clueless! X-programming > is largely mysterious to me, as are network protocols. Well, the simplest thing to get it started would be to separate out every single function which makes an X call into their own subdirectory. Then start moving as much of the "thinking" functionality into routines that call the client routines. -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 Fri Apr 8 23:24:02 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 Apr 1994 23:24:00 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id OAA15911; Fri, 8 Apr 1994 14:23:51 -0700 Date: Fri, 8 Apr 1994 14:23:51 -0700 From: Peter Mardahl Message-Id: <199404082123.OAA15911@soda.berkeley.edu> To: crossfire@ifi.uio.no, v912152@jong.si.hhs.nl Subject: Re: Some ideas Status: RO Let's all remember that crossfire is supposed to be fun, not work. Let's not build things into the game which are tedious and which are not important. We also don't want to complicate the game too much. The game consumes too much disk space as it is. I also think it's a bad idea to duplicate functions served perfectly well by UNIX email, UNIX files, ftp. If someone wants a tutorial, he should go to a newsgroup or help files. Documents written by players for players do not belong anywhere in the maps: I can forsee people writing things like "the password is xxx", ruining quests..... As to player class guilds, etc. I think: not yet. There aren't enough players of crossfire yet to enforce firm class distinctions: you cannot count on getting friends to help you through rough spots. NPC's may solve this problem, but I cannot imagine them being adequate without major, major work. The guilds idea is a good one, and will add flavor, but I don't want the game to enforce this yet. Maybe after the client/server split. Regards, PeterM From crossfire-request Fri Apr 8 21:58:02 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 Apr 1994 21:57:58 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id MAA04784; Fri, 8 Apr 1994 12:57:41 -0700 Date: Fri, 8 Apr 1994 12:57:41 -0700 From: Peter Mardahl Message-Id: <199404081957.MAA04784@soda.berkeley.edu> To: crossfire@ifi.uio.no, master@rahul.net Subject: Re: Coins Status: RO > This is a forwarding of a discussion that Kjetil Torgrim Homme > and I have had about value of coins and gems. A quick summary was that he thought platinum and gold should be worth more (1 pp = 12 gp = 144 sp was his initial suggeted). In his last message, he suggested adding copper coins to replace silver, and bump everything up in value. I'm actually very happy with the current coin system. I think some prices are screwed up, like that for food, but I think the solution is to screw around with those, not with the coin system. >their head. Also, any change in coin values could greatly affect >saved players. Perhaps. What might be better is to make GEMS worth a lot more money (in AD&D, a pearl is worth abou 100 gp, both rubies and diamonds aroudn 1000-5000 GP). Gems are a pretty heterogeneous lot. I see all the current gems as being sort of semi-precious. There are big diamonds of high value, and little ones of moderate value. In real life, the little ones are sold by weight, and the prices for these are just about right! Large, valuable gems are very rare, little itty bitty ones are not. I'd rather see a new class of more precious types of gems than changes. I made the power_crystal archetype ridiculously valuable so it could serve this purpose. > Obviously, in gems increase is value, the number you find would be less. Ordinary gems should stay as they are, artifact-level-rarity/value gems should be as common as the artifacts..... I think the charisma bonus right now is far too extreme for treasure. I think there should be at most a 30% difference between 10 and 30, instead of a 200% or more as it is. A merchant who priced his stuff in that way would be put out of business quickly. > As a person who plays AD&D (first edition), copper coins are almost never > used because they are wroth so little. Even when low level parties find > 2,000 cp, they might leave it behind due to weight. Also, in soem games, Crossfire would have exactly the same problem.... Regards, PeterM From crossfire-request Fri Apr 8 22:04:37 1994 Return-Path: Received: from mccaw.com (wombat.mccaw.com [192.135.191.118]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 8 Apr 1994 22:04:32 +0200 Received: from nwestmail.entp.mccaw.com ([155.176.15.34]) by mccaw.com (4.1/SMI-4.1) id AA03780; Fri, 8 Apr 94 12:54:01 PDT Received: from axys69.nwest.mccaw.com by nwestmail.entp.mccaw.com (4.1/McCaw SUN-RMR Mailer, SMI-4.1) id AA21185; Fri, 8 Apr 94 12:52:31 PDT Received: from divac by axys69.nwest.mccaw.com (NX5.67d/NX3.0M, dpg hack 15oct93) id AA20392; Fri, 8 Apr 94 12:54:52 -0700 From: Jason Fosback Message-Id: <9404081954.AA20392@axys69.nwest.mccaw.com> Received: by divac.nwest.mccaw.com (NX5.67d/NX3.0X, dpg hack 20mar93) id AA11799; Fri, 8 Apr 94 12:54:52 -0700 Date: Fri, 8 Apr 94 12:54:52 -0700 Received: by NeXT.Mailer (1.100.RR) Received: by NeXT Mailer (1.100.RR) To: crossfire@ifi.uio.no Subject: Re: HELP! crossfire 0.90.4 Status: RO > Encounter maps inside city is a bug in map, IMHO. And if moving outside > use paths so you don't need worry encounters. If moving in wilderness > everything can happen :) > > -Tero Definitely. However, it can definitely be ANOYING! Encounters should be an exception, not the rule. They should be made much more infrequent than what comes with the current release; in addition, there should be something entertaining you can find during the encounter, such as a pile of gold and gems. There should also be some variety! It seems like there is only ONE encounter map for grass, ONE encounter map for forest, etc. This becomre very tedious. -jason ____________________________________________________________ Jason Fosback, Systems Engineer | No sir, I didn't like it --- Paradigm Systems Corp --- | -R&S Internet: jason_fosback@psca.com | Star Trek: NeXT mail: jason_fosback@psca.com | The NeXT Generation... From crossfire-request Fri Apr 8 21:45:23 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 Apr 1994 21:45:07 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id MAA03194; Fri, 8 Apr 1994 12:44:57 -0700 Date: Fri, 8 Apr 1994 12:44:57 -0700 From: Peter Mardahl Message-Id: <199404081944.MAA03194@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: client/server? Cc: mehlhaff@soda.berkeley.edu, mehlhafff@soda.berkeley.edu Status: RO Is anyone actually working on this? ERic Mehlhaff at berkeley doesn't seem to be doing anything with it these last few weeks. This is something which should get done soon, I think. I'd undertake it, but I'm too clueless! X-programming is largely mysterious to me, as are network protocols. From crossfire-request Fri Apr 8 20:25:58 1994 Return-Path: Received: from po5.andrew.cmu.edu (PO5.ANDREW.CMU.EDU [128.2.10.105]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 8 Apr 1994 20:25:57 +0200 Received: (postman@localhost) by po5.andrew.cmu.edu (8.6.7/8.6.4) id OAA21126 for crossfire@ifi.uio.no; Fri, 8 Apr 1994 14:25:54 -0400 Received: via switchmail; Fri, 8 Apr 1994 14:25:53 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 8 Apr 1994 14:24:27 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 8 Apr 1994 14:24:22 -0400 (EDT) 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; Fri, 8 Apr 1994 14:24:22 -0400 (EDT) Message-ID: Date: Fri, 8 Apr 1994 14:24:22 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: Some ideas In-Reply-To: <199404081606.TAA16267@venla.it.lut.fi> References: <199404081606.TAA16267@venla.it.lut.fi> Status: RO Tero Haatanen writes: > - if some more advanced parsing system is being made, I would prefer > that it's coded rather than using something like tcl. Even currently you > already need perl, (last version needed gawk) and so on. And it can > very simple and still powerful. Something which can react different > actions (object is created, dropped, applied, hitted, destroyed, etc.) > and can execute simple functions (info players, modify objects variables, > changed states, creating objects, activate gates, giving and receiving > items). Why do you want this? I don't see any difference between using tcl and having something coded. If people want, they you just put the tcl distribution inside of the crossfire distribution and it gets automatically compiled. The reason I'd rather go with tcl then rolling our own is becuase tcl is turing complete, and I don't see any good reason for us to write an entire language on our own. Especially because it's hard to predict everything someone might want to do. For example, with tcl, I could make a gambling hall where you could go and play poker and blackjack and roulette. I could also make a guided tour, where you get on a boat and are moved around to see a bunch of different places, but you can't get off. -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 Fri Apr 8 20:07:03 1994 Return-Path: Received: from cc.lut.fi (haatanen@cc.lut.fi [157.24.15.37]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 8 Apr 1994 20:07:02 +0200 Received: (from haatanen@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id VAA00561; Fri, 8 Apr 1994 21:06:52 +0300 (for crossfire@ifi.uio.no) From: Tero Haatanen Message-Id: <199404081806.VAA00561@cc.lut.fi> Subject: Re: HELP! crossfire 0.90.4 To: crossfire@ifi.uio.no Date: Fri, 8 Apr 1994 21:06:52 +0300 (EETDST) In-Reply-To: from "Eric A. Anderson" at Apr 8, 94 01:43:48 pm 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: 382 Status: RO > gee, I actually find the encounter maps increadibly tedious because > they make it take a really long time to get to some places. It's also > a little unreasonable to go into an encounter inside a city. Encounter maps inside city is a bug in map, IMHO. And if moving outside use paths so you don't need worry encounters. If moving in wilderness everything can happen :) -Tero From crossfire-request Fri Apr 8 19:53:16 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 ; Fri, 8 Apr 1994 19:53:12 +0200 Received: (postman@localhost) by po6.andrew.cmu.edu (8.6.7/8.6.4) id NAA06075 for crossfire@ifi.uio.no; Fri, 8 Apr 1994 13:52:50 -0400 Received: via switchmail; Fri, 8 Apr 1994 13:52:49 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 8 Apr 1994 13:52:04 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 8 Apr 1994 13:52:03 -0400 (EDT) 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; Fri, 8 Apr 1994 13:52:03 -0400 (EDT) Message-ID: Date: Fri, 8 Apr 1994 13:52:03 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: Some ideas In-Reply-To: <9404080945.AA06983@jong.si.hhs.nl> References: <9404080945.AA06983@jong.si.hhs.nl> Status: RO v912152@jong.si.hhs.nl writes: > CREATE: > - let players choose a family before starting, assign a house to that family > - class-exit (only one class allowed) > - family-exit (only one family allowed) > - a player-exit (only one player allowed) I don't really like these unless there is a really good explanation. I personally think I should be able to break into other peoples places. > - library-exit ?? What would this do? > - pen (let players write messages on walls/floors) The marking rune will let you do this. > - public office, has some brochers with holiday-ideas etc, also has > the adress of all major places in the town (family-houses, guilds) Generally people put signs in the towns identifying what is open and available. -- In general this seem to involve lots of bitmaps. If you draw the bitmaps, the code is more likely to follow. Many of the people who are working on the code can write code, but can't draw too 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 Fri Apr 8 19:49:48 1994 Return-Path: Received: from po3.andrew.cmu.edu (PO3.ANDREW.CMU.EDU [128.2.10.103]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 8 Apr 1994 19:49:47 +0200 Received: (postman@localhost) by po3.andrew.cmu.edu (8.6.7/8.6.4) id NAA20631 for crossfire@ifi.uio.no; Fri, 8 Apr 1994 13:49:38 -0400 Received: via switchmail; Fri, 8 Apr 1994 13:49:36 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 8 Apr 1994 13:48:37 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 8 Apr 1994 13:48:35 -0400 (EDT) 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; Fri, 8 Apr 1994 13:48:34 -0400 (EDT) Message-ID: Date: Fri, 8 Apr 1994 13:48:34 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: Coins In-Reply-To: <199404080618.AA03638@bolero.rahul.net> References: <199404080618.AA03638@bolero.rahul.net> Status: RO Mark Wedel writes: > A quick summary was that he thought platinum and gold should be worth > more (1 pp = 12 gp = 144 sp was his initial suggeted). In his last > message, he suggested adding copper coins to replace silver, and bump > everything up in value. I'd rather have the 10 10 10 setup. Just add platinum on the top. Alternately, don't worry about it. Right now there just isn't a lot you need a great deal of money for. > The following is new stuff. Comments? > > Perhaps. What might be better is to make GEMS worth a lot more > money (in AD&D, a pearl is worth abou 100 gp, both rubies and diamonds > aroudn 1000-5000 GP). This would be interesting. You could try creating big diamonds and see what happens. > generation method) becomes the stat to put your low score in. In crossfire, > all abilities are fairly important, and it can be difficult to choose which > stat to have low. IF charisma became only necessary for reaction or > something, this might become an ability to toss yoru low score into. > And I wouldn't really like the idea of NPC's not sharing information if you > have a low charisma, because this could then make it impossible for characters > to get the information needed to solve quests. Actually, I always put my low score in charisma, and then I just create a priest character with a 20 cha and 17-19 str to do all my buying and selling. (Well I used to do this, but when you're able to cast cha on yourself it became less valuable) -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 Fri Apr 8 19:45:31 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 ; Fri, 8 Apr 1994 19:45:30 +0200 Received: (postman@localhost) by po6.andrew.cmu.edu (8.6.7/8.6.4) id NAA05922 for crossfire@ifi.uio.no; Fri, 8 Apr 1994 13:45:25 -0400 Received: via switchmail; Fri, 8 Apr 1994 13:45:24 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 8 Apr 1994 13:44:00 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 8 Apr 1994 13:43:49 -0400 (EDT) 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; Fri, 8 Apr 1994 13:43:48 -0400 (EDT) Message-ID: Date: Fri, 8 Apr 1994 13:43:48 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: HELP! crossfire 0.90.4 In-Reply-To: <199404080057.13951.gjalp.ifi.uio.no@ifi.uio.no> References: <199404080057.13951.gjalp.ifi.uio.no@ifi.uio.no> Status: RO Kjetil Torgrim Homme writes: > The encounter maps are fine for accumulating experience. Grasslands at > first, then forests and mountains if you are daring. gee, I actually find the encounter maps increadibly tedious because they make it take a really long time to get to some places. It's also a little unreasonable to go into an encounter inside a city. -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 Fri Apr 8 19:44:29 1994 Return-Path: Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 8 Apr 1994 19:44:26 +0200 Received: (postman@localhost) by andrew.cmu.edu (8.6.7/8.6.4) id NAA14828 for crossfire@ifi.uio.no; Fri, 8 Apr 1994 13:44:19 -0400 Received: via switchmail; Fri, 8 Apr 1994 13:44:17 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 8 Apr 1994 13:42:17 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 8 Apr 1994 13:42:16 -0400 (EDT) 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; Fri, 8 Apr 1994 13:42:13 -0400 (EDT) Message-ID: Date: Fri, 8 Apr 1994 13:42:13 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: feedback requested In-Reply-To: <199404072350.QAA13478@soda.berkeley.edu> References: <199404072350.QAA13478@soda.berkeley.edu> Status: RO Peter Mardahl writes: > How do people like the Quetzalcoatl and Fireborn > race types? > Too strong? Too weak? Okay? They are both quite strong at the beginning where their natural a.c. protect them from being hurt. As they advance they become much weaker because at least as a fireborn, you can't really kill monsters which are immune to magic. (for example guards, raas, skulls and beholders) This makes it pretty much impossible for them to complete some of the quests. I don't know as much about the quetzalcoatls. -- I think some sort of level dependance needs to exist for them so that they can improve their ac & damage. I'd suggest making some amount of level dependance, but then I think that other people should also have a level dependance. Perhaps something more reasonable is a quest where they can get special weapons/armor that they can wear/use. -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 Fri Apr 8 17:41:25 1994 Return-Path: Received: from condor.CC.UMontreal.CA (condor.CC.UMontreal.CA [132.204.2.103]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 8 Apr 1994 17:41:18 +0200 Received: from aster.JSP.UMontreal.CA by condor.CC.UMontreal.CA with SMTP id AA04132 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Fri, 8 Apr 1994 11:36:14 -0400 Received: from spb51.jsp.umontreal.ca by aster.jsp.umontreal.ca (920330.SGI/5.17) id AA27098; Fri, 8 Apr 94 11:40:17 -0400 Received: by spb51.jsp.umontreal.ca (920330.SGI/5.17) id AA06800; Fri, 8 Apr 94 11:41:02 -0400 From: kosmatoo@JSP.UMontreal.CA (Kosmatos Odisseas) Message-Id: <9404081541.AA06800@spb51.jsp.umontreal.ca> Subject: Re: Some ideas To: v912152@jong.si.hhs.nl Date: Fri, 8 Apr 1994 11:41:01 -0500 (EDT) Cc: crossfire@ifi.uio.no In-Reply-To: <9404080945.AA06983@jong.si.hhs.nl> from "v912152@jong.si.hhs.nl" at Apr 8, 94 11:45:55 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 913 Status: RO > From: v912152@jong.si.hhs.nl > Hi guys, here's a little brainwave: > > CREATE: > - let players choose a family before starting, assign a house to that family Excelent idea, just like in Dune. "House Harkonnen" :-) > - class-exit (only one class allowed) Bravo! > - foutains Yes! > - pen (let players write messages on walls/floors) Marvellous! If any of these are left in the summer, I'd love to code some. > - post office (finally a way to send messages to other players) Neat! And of course there are postmen NPC's all over the place trying to deliver mail :-) > IDEAS: > mailbox:-contains all the letters (and packages) send to you. Packages: Neat.. You send a nice Dragonslayer +3 to a friend! -- "More than a treasure, Usul. There are thousands of such caches, and only a few of us know all their locations. One day, we will change the face of Arrakis." -- Stilgar, Fremen leader. From crossfire-request Fri Apr 8 18:14:23 1994 Return-Path: Received: from ild.alkymi.unit.no (ild.alkymi.unit.no [129.241.113.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 8 Apr 1994 18:14:22 +0200 Received: by ild.alkymi.unit.no id AA10041 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Fri, 8 Apr 1994 18:14:04 +0200 From: Inge Berg Fenstad Message-Id: <199404081614.AA10041@ild.alkymi.unit.no> Subject: Buggy maps To: crossfire@ifi.uio.no Date: Fri, 8 Apr 1994 18:14:04 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 353 Status: RO Hello It was said that the bugs with maps should have been fixed (At least i though i heard that) but have anyone else that me noticed that crossfire have a tendency to start throw ppl to wild places and making exits closed when there are many ppl playing on a server. And do anyone have a cure for this (making map_timeout small or whatever )? Inge From crossfire-request Fri Apr 8 18:06:35 1994 Return-Path: Received: from venla.it.lut.fi (haatanen@venla.it.lut.fi [157.24.21.67]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 8 Apr 1994 18:06:26 +0200 Received: from localhost (haatanen@localhost) by venla.it.lut.fi (8.6.5/8.6.5/1.12.kim) id TAA16267; Fri, 8 Apr 1994 19:06:22 +0300 (for crossfire@ifi.uio.no) From: Tero Haatanen Message-Id: <199404081606.TAA16267@venla.it.lut.fi> Subject: Re: Some ideas To: crossfire@ifi.uio.no Date: Fri, 8 Apr 94 19:06:21 EET DST In-Reply-To: <9404080945.AA06983@jong.si.hhs.nl>; from "v912152@jong.si.hhs.nl" at Apr 8, 94 11:45 am X-Mailer: ELM [version 2.3 PL11] Status: RO From: v912152@jong.si.hhs.nl > Hi guys, here's a little brainwave: Ok. let's continue it little more :) > - class-exit (only one class allowed) Pedestals can work with races and players race is same as players class, so it's possible to make different guild's for different classes already. > - a player-exit (only one player allowed) Give player an unique key and modify door code so that door isn't removed. Updating object which are 'owned' by players is very hard to update (e.g. player dies and exit is some map that is not even loaded currently by server, etc.). Keys don't have this problem. > - saveable rooms (even there after crash, saved in special directory) I have implemented unique-flag, all items with this flag are saved another directory and keep between games. Used with graveyards and deposit boxes, but allows also the real artifacts. Deposit boxes have weight limit so you can control number of items being saved (and easily implement rent if wanted), but saveable rooms players can fill junk too easily, IMHO. > - a player-save-bed recieves the name of the first player that applies it Easy to implement with unique-flag, but I'm not sure if it's good idea. Makes much harder save your character if you want leave to game soon. > - foutains > - canteens (fillable from rivers,fountains,sinks ect) Agree, I have sometimes think this also. But it requires that code can handle different liquids (water, beer, wine, poisonois water, etc.) and mixtures of them ;). Magic potions could be handled this way also. > - more clothings like: leather shoes,cowboy-hat,shawl,gloves,jeans,etc It would be nice have some normal shoes and gloves, but this shouldn't improve ac much or total ac comes too good. And when thinking little about environment, jeans don't belong to crossfire, IMHO. > - library-exit What is this? > - pen (let players write messages on walls/floors) > - writing desk (let players write books, scrolls and letters) Good idea and even easy to implement, just have flag where you can write your messages. > - post office (finally a way to send messages to other players) Written letters could be left to post-office where players could go and check if they got new letters. Little code added to players to get only their own letters would be needed. Roadnames, addresses and automatic delivier of letter are unncessary things, and little out of atmosphere of the game, IMHO. > - books can only be read when seated (finaly some use for those chairs) They are weapons currently, so you can use them :). Maybe if you really want some use them make player heal faster when sitting or sleeping (normal beds). Of course getting up would take more time that just walking around. > postoff:-contains a shop, selling stamps, paper I have had idea of general shop long time, which would sell normal tools like keys, bags, sacks, pens, papers and so on. > home: -only entered by ONE family I had idea that high level players could buy their own house somewhere. These should probably be _very_ expensive. Of course nothing prevent having more than one key per house. > CODE: > exits: The special exits need something like: > exit->allow = { ALLOW_CLASS, ALLOW_FAMILY, ALLOW_PLAYER }; Maybe allow class, but family and player entering should be used with items, so that familys could have their own symbol which is used to identify in which family player belongs. Maybe player could join guild and get guild symbol, which identifies in which guild player belongs. > rooms: The saveable rooms must belong to a class, family or player. I made so that they are saved accordind to map-names. Wait the new version to test this. Allowing saving whole map causes problem of saving enormous amount items (i.e. collecting all artifacts and other good items). If players can have own houses, we need furniture shop, of course :). Some my own ideas - wastebaskets and junkyards, simply destroys all items - maybe there could be level limitation in exits, so you could make quest low level players ONLY. Some challange also low level players. - checkpoint, which doesn't allow players pass if it has (or doesn't have) some item(s) in inventory. Like checking unpaid items, won't allow exporting some items from some room, etc. - square, where objects can pass only in defined direcrions. - make spells objects so then when you learn new spell, spell is added to the spellbook, which is container. There could be a different spellbooks which could contain different to spells (summon, attack, healing and so on). You could then select spell also with mouse just applying spell. After holding time you just select casting directtion. Putting this spell item to monster inventory would cause monster to 'learn' this spell. - if time system is changed, add the real game time, nights and days and so on. Some kind of calendar system would be also cool. Some other comments - Maybe the old maps should be updated by authors and they offers maps to Mark, so it's possible to know who is author of maps. And if there is problems with maps so everyone can contact directly to author. I think that bad maps should be left from the standard disribution. Most people don't want get any problems, just working maps ;). - why was max limit of stats changed from 25 to 30? It seems just making balancing to game much harder. And allowing players add stats bonus to weapons seems too powerful, adding magic bonus and maybe little damage and wc seems more reasonable. - if some more advanced parsing system is being made, I would prefer that it's coded rather than using something like tcl. Even currently you already need perl, (last version needed gawk) and so on. And it can very simple and still powerful. Something which can react different actions (object is created, dropped, applied, hitted, destroyed, etc.) and can execute simple functions (info players, modify objects variables, changed states, creating objects, activate gates, giving and receiving items). - how about cleaning TODO list before next version, Mark? Too many ideas in same time ? ;) -Tero From crossfire-request Fri Apr 8 11:49:10 1994 Return-Path: Received: from paaltjens.si.hhs.nl (paaltjens.si.hhs.nl [145.52.80.3]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 8 Apr 1994 11:48:51 +0200 From: v912152@jong.si.hhs.nl Received: from jong.si.hhs.nl by paaltjens.si.hhs.nl id <07017-0@paaltjens.si.hhs.nl>; Fri, 8 Apr 1994 11:45:58 +0200 Received: by jong.si.hhs.nl (5.0/2.0) id AA06983; Fri, 8 Apr 94 11:45:55 +0200 Date: Fri, 8 Apr 94 11:45:55 +0200 Message-Id: <9404080945.AA06983@jong.si.hhs.nl> To: crossfire@ifi.uio.no Subject: Some ideas Content-Length: 2582 Status: RO Hi guys, here's a little brainwave: CREATE: - let players choose a family before starting, assign a house to that family - class-exit (only one class allowed) - family-exit (only one family allowed) - a player-exit (only one player allowed) - saveable rooms (even there after crash, saved in special directory) - a player-save-bed recieves the name of the first player that applies it (and doesn't allow other players to apply it, until the original player is gone) - foutains - canteens (fillable from rivers,fountains,sinks ect) - more clothings like: leather shoes,cowboy-hat,shawl,gloves,jeans,etc - library-exit - pen (let players write messages on walls/floors) - writing desk (let players write books, scrolls and letters) - post office (finally a way to send messages to other players) with a post-box, and stamp-and-paper shop. - stamps (wow! deliver the letter to the room of the reciepient!) - mailbox (need that too ofcourse!) - public office, has some brochers with holiday-ideas etc, also has the adress of all major places in the town (family-houses, guilds) - roadnames (need that to specify adresses) CHANGE: - some rooms are to be saved permanently (thus creating storage rooms) - books can only be read when seated (finaly some use for those chairs) IDEAS: mailbox:-contains all the letters (and packages) send to you. postbox:-sends your letter (or package) to the mailbox of the reciepient. postoff:-contains a shop, selling stamps, paper guild: -only entered by ONE class -special items for class collected in the 'holy-class room' (saveable) -books (written by players) in a library, helping beginning players home: -only entered by ONE family -has sleeping-hall with player-save-beds -has a family-share in some things (players must be fair, or they will be abbandoned from the family (and thus their belonings)) -has private rooms for each player in the family foutain:-will be endlessly drinkable canteen:-can be filled with water from a foutain etc CODE: exits: The special exits need something like: exit->allow = { ALLOW_CLASS, ALLOW_FAMILY, ALLOW_PLAYER }; If this field is empty, allow everything. exit->allow_name = { CLASS,FAMILY,PLAYER }_name; rooms: The saveable rooms must belong to a class, family or player. It must be able to restore them to original (thus work with a copy). Place them in a directory: maps/save_{classes,families,players}/* canteen:Need a max-fill number foutain:can't be picked up, can't be burned, can be drinked from, doesn't disapear after drinking. That's all, Patrick van Logchem From crossfire-request Fri Apr 8 08:18:16 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 Apr 1994 08:18:14 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA24884 (5.67a8/IDA-1.5 for ); Thu, 7 Apr 1994 23:18:11 -0700 Received: by bolero.rahul.net id AA03638 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 7 Apr 1994 23:18:10 -0700 Date: Thu, 7 Apr 1994 23:18:10 -0700 From: Mark Wedel Message-Id: <199404080618.AA03638@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Re: Coins Status: RO This is a forwarding of a discussion that Kjetil Torgrim Homme and I have had about value of coins and gems. A quick summary was that he thought platinum and gold should be worth more (1 pp = 12 gp = 144 sp was his initial suggeted). In his last message, he suggested adding copper coins to replace silver, and bump everything up in value. The few thoughts I had was the the coin system right now is fairly nice and simple, so players can do conversions somehwat easily in their head. Also, any change in coin values could greatly affect saved players. The following is new stuff. Comments? Perhaps. What might be better is to make GEMS worth a lot more money (in AD&D, a pearl is worth abou 100 gp, both rubies and diamonds aroudn 1000-5000 GP). food in crossfire is relatively expensive compared to most equipment. This may go back more to when it was more a gauntlet type game, and food was more critical. Obviously, in gems increase is value, the number you find would be less. Also, with such a change in gems, also change the value based on charisma. So that you maybe buy them for 10% above straight value, and sell for 90% of value or something, and have no other adjustments made by charisma. The big problem with gems now is that if you are low charisma, even if you use the gem tables, you lose a lot of money in the deal. There was talk about making it so Charisma does not affect prices at all, and is instead a reaction for monsters. I don't know if removing charisma right now for shops would be a good idea. As a person who plays AD&D (first edition), copper coins are almost never used because they are wroth so little. Even when low level parties find 2,000 cp, they might leave it behind due to weight. Also, in soem games, the DM hardly uses charisma at all, and it quickly (depending on character generation method) becomes the stat to put your low score in. In crossfire, all abilities are fairly important, and it can be difficult to choose which stat to have low. IF charisma became only necessary for reaction or something, this might become an ability to toss yoru low score into. And I wouldn't really like the idea of NPC's not sharing information if you have a low charisma, because this could then make it impossible for characters to get the information needed to solve quests. --Mark From crossfire-request Fri Apr 8 02:57:38 1994 Return-Path: Received: from gjalp.ifi.uio.no (1232@gjalp.ifi.uio.no [129.240.84.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 8 Apr 1994 02:57:37 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by gjalp.ifi.uio.no ; Fri, 8 Apr 1994 02:57:36 +0200 Date: Fri, 8 Apr 1994 02:57:36 +0200 Message-Id: <199404080057.13951.gjalp.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: "Eric A. Anderson"'s message of Thu, 7 Apr 1994 20:08:48 -0400 (EDT) Subject: Re: HELP! crossfire 0.90.4 Status: RO The encounter maps are fine for accumulating experience. Grasslands at first, then forests and mountains if you are daring. Someone should design some more tiles to get more varied encounter maps, BTW. They're easy to add into the game. Kjetil T. From crossfire-request Fri Apr 8 02:49:58 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 Apr 1994 02:49:52 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA05559 (5.67a8/IDA-1.5 for ); Thu, 7 Apr 1994 17:49:43 -0700 Received: by bolero.rahul.net id AA14873 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 7 Apr 1994 17:49:42 -0700 Date: Thu, 7 Apr 1994 17:49:42 -0700 From: Mark Wedel Message-Id: <199404080049.AA14873@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Re: HELP! crossfire 0.90.4 Status: RO I totally agree that dumping in the old maps is a bad idea. I've actually had a chance to play the game a bit lately, and that is hwy (why) I have been making the minor map corrections. I plan to add in the old maps, but want to have a decent idea of what maps already exist. I have changed some of the maps in Santo Dominion, to eliminate some of the stores, as well fix some bugs (the basic 4 stores are unchanged except for minor bugs. But I removed teh stores inside of house of hell, for example, and eliminate the secret area of the lord of the rings shop. Even the small shop is plenty large..) I don't know how many of the old maps will be put in. The old mansion, for example, would require many changes to bring it up to standards. I am not going to spend a lot of time on maps bringing them up to standards, but rather, if they look mostly fine, I will spend a little time making minor changes. --Mark From crossfire-request Fri Apr 8 02:09:27 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 ; Fri, 8 Apr 1994 02:09:24 +0200 Received: (postman@localhost) by po6.andrew.cmu.edu (8.6.7/8.6.4) id UAA14442 for crossfire@ifi.uio.no; Thu, 7 Apr 1994 20:09:18 -0400 Received: via switchmail; Thu, 7 Apr 1994 20:09:18 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Thu, 7 Apr 1994 20:08:57 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Thu, 7 Apr 1994 20:08:50 -0400 (EDT) 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; Thu, 7 Apr 1994 20:08:48 -0400 (EDT) Message-ID: Date: Thu, 7 Apr 1994 20:08:48 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: HELP! crossfire 0.90.4 In-Reply-To: <9404071700.AA29366@axys69.nwest.mccaw.com> References: <9404071700.AA29366@axys69.nwest.mccaw.com> Status: RO As a general comment, could people please only send messages to the crossfire list rather than to the sender and the list? It should be clear that I read the list. Thanks, -Eric Jason Fosback writes: > > Eric writes: [it should be a challenge to get exp] > > [ but it's frustrating if all the newbie places are cleared out ] Well, then I guess I would propose that you write more maps. I'll agree that there are now fewer maps, and that this makes things harder, but I don't think the solution is to dump in all the old maps which are much more unbalanced than the current ones; the solution is to make new maps which are also cool. Invent some quests for beginning characters. > no clear way out of the new maps. If we could get out of the new maps, > and into the old world, we'd be okay. However, there's no clear way how > to do this. You can't get to the old maps -- at least not with the distributions I have seen. -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 Fri Apr 8 01:50:41 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 Apr 1994 01:50:37 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id QAA13478 for crossfire@ifi.uio.no; Thu, 7 Apr 1994 16:50:30 -0700 Date: Thu, 7 Apr 1994 16:50:30 -0700 From: Peter Mardahl Message-Id: <199404072350.QAA13478@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: feedback requested Status: RO How do people like the Quetzalcoatl and Fireborn race types? Too strong? Too weak? Okay? Here's a summary of what they can do: race attacktype restrictions immunities prot./vuln. bonus fireborn fire,phys no armour, fire vuln:ghosthit -7st-3con no weapons poison drain,cold +4dex+4int +3wis-4cha net:-3 Fireborns are supposed to be fire spirits. they're closely in tune with magic and are powerful and learn magic easily. Being fire spirits, they are immune to fire and poison, and vulnerable to cold. They are vulnerable to ghosthit and drain because being mostly non-physical, anything which strikes directly at the spirit hits them harder.... Quetzalcoatl physical no armour fire vuln:paral +4st-4dex poison,cold +4con-7wis +5int net:+2 Quetzalcoatl's are now born knowing the spell of burning hands, but because of their wisdom negative bonus, they have a very hard time learning new spells. I believe their all-time maximum wisdom is 13. They're supposed to be powerful spellcasters of what few spells they know, but too mentally inflexible to learn anything new easily. Should I build in a level dependence of their armour class? Perhaps the wis bonus should be -9. I also changed it so that they could use weapons, but when I do this they are very devastating at low level: they have a low enough natural ac that they can make mincemeat of low-level monsters. However, at midlevel, they really begin to have problems because they cannot use armour. Perhaps they should start at ac 7 and gain 1 ac point for every 3 levels they advance. From crossfire-request Thu Apr 7 20:51:21 1994 Return-Path: Received: from cc.lut.fi (hevi@cc.lut.fi [157.24.15.37]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 7 Apr 1994 20:51:20 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id VAA02652; Thu, 7 Apr 1994 21:06:55 +0300 Date: Thu, 7 Apr 1994 21:06:55 +0300 (EETDST) From: Petri Heinil{ Subject: Re: Talking to NPC's To: Gregor Schmid cc: crossfire@ifi.uio.no In-Reply-To: <199404061006.AA21698@fb3-s7.math.tu-berlin.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 6 Apr 1994, Gregor Schmid wrote: > Mark Wedel writes: > > Conversation code should really be re-done at some point, to allow for > > more advanced features (give or take, for example), as well as different > > states. Right now, if there is a match for yes, there can only be > > one response. Different states should be used, so you can be asked a series > > of yes/no questions, and with each answer, have a different question come > > up. > > > > --Mark > > I think it's time to rethink the general approach here. I have thinked, yes :^) > Crossfire implements a simple parser for the archetypes, including > the @match handling, which does it's job but not much more. > Whenever there is need for a new feature, tha parser has to be > extended. Going sightseen trough lib, ... the language is used in: treasures - descripe different type treasure, where are the changes in dirrefferent item, when creating object that have that treasure, or when object dies. spell_params - descripe what spells exists, and what are the charasterisks of those spell. This is like table form. sounds - description what sounds exists, and their mappings motd - the word of day maps - descripe the contents of the map. And descriping the detailed parameters for the instance of the object class. The map format is also used in temporary saving of the maps. help - files that contains pure for for helping info. fsconfig - hmm, something for server info. I think, does this really exist here. def_keys - input system keybiard mapping def_help - help for inputs artifacts - descripes different type of artifact and what to it can be effect. arch - descripes the attributes of the architypes. And the faces of the archetypes. [generated files and adm are out of vision] The purposes of the files are like system configuration, files sounds, motd, help. These are server side stuff and could be well in one file ar by command line params (look xpilot). The client side configuration, files: def_keys, because this is a x-program these should be in x-resources (the .ad -file). And then there are the world management (we are the gods, aren't we :). These are the files: treasures, spell_params, artifacts, arch. And for these there should exist common, consistent language. > How about including a real scripting language like tcl into crossfire. Scripting vs. coding ! There have to draw line between things that are coded (by some compiled machine depend language) and what things are scipted (by high-level (means crossfire oriented language :) machine independ language). > It would be hard at first, but tcl runs on just about every unix box > (there's even a DOS port, ugh) and is easy to combine with any app. Tcl is easy combine to most applications because it's designed common configuration language. And it could be used as server side sytem configuration. But for the describe the world and the objects need some more specific language where the primary messages (= routines) are like "move direction", "drop item" or "create object". And tcl eats quite amount of memory; whitout Tk the consuption can be 2MB and with 5MB, and thinking the crossfire more, it would be 7MB. The form of language sould be some like describing the values of attributes of the objects (the number of attributes should be constant, because of creation of variables in language leads to allocation and performance problems). And there are defined the behaviour of objects (= monsters) in different events, like "born", "die", "apply", "say" or "hit". Languages like these, are the real-time system or simulation system description languages, like simscript, simula or smalltalk (that is derived from simula). > Archetypes and maps could then include tcl-scripts that are evaluated > at run time, which brings about unlimited possibilities. > > I'm afraid it is a bit late for that though, but maybe it's a thought. > > By the way, the overhead wouldn't be much more than the existing > parser. Hee, say parsers :). Foreach file exists own parsing system. The situation now is not quite robust. -- The Page -- From crossfire-request Thu Apr 7 19:00:00 1994 Return-Path: Received: from mccaw.com (wombat.mccaw.com [192.135.191.118]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 7 Apr 1994 18:59:51 +0200 Received: from nwestmail.entp.mccaw.com ([155.176.15.34]) by mccaw.com (4.1/SMI-4.1) id AA01062; Thu, 7 Apr 94 09:59:43 PDT Received: from axys69.nwest.mccaw.com by nwestmail.entp.mccaw.com (4.1/McCaw SUN-RMR Mailer, SMI-4.1) id AA12601; Thu, 7 Apr 94 09:59:41 PDT Received: from divac by axys69.nwest.mccaw.com (NX5.67d/NX3.0M, dpg hack 15oct93) id AA29366; Thu, 7 Apr 94 10:00:58 -0700 From: Jason Fosback Message-Id: <9404071700.AA29366@axys69.nwest.mccaw.com> Received: by divac.nwest.mccaw.com (NX5.67d/NX3.0X, dpg hack 20mar93) id AA04613; Thu, 7 Apr 94 10:01:12 -0700 Date: Thu, 7 Apr 94 10:01:12 -0700 Received: by NeXT.Mailer (1.100.RR) Received: by NeXT Mailer (1.100.RR) To: "Eric A. Anderson" Subject: Re: HELP! crossfire 0.90.4 Cc: crossfire@ifi.uio.no Status: RO > I think it is good that there are no places to get exp fast. I think > it should be a challenge to get experience, not a cake-walk. > Otherwise it's not experience. I also think that things should be > interesting for low-level characters as well as high level ones. > -Eric Yes, but it can also be extremely frustrating for people using persistent servers. If one character clears out the newbie tower, beginners, Gork's Grovel, etc., other characters have a very difficult time getting higher levels. At least with the previous maps, there was a HUGE world we could get to, and this wasn't a problem. With the new maps, it's very difficult for a multi-player low-level campaign. The new maps a cool, but they aren't well designed for mulitple players. Several of us have been having no end of headaches trying to advance with the new maps. It's very hard for a character under level seven to get anywhere after the newbie stuff is cleared out. Once you reach level five, you're set; but what do we do in the meantime? It's tough (if not impossible) to take out swarms of bats at level one or two. And, there is no clear way out of the new maps. If we could get out of the new maps, and into the old world, we'd be okay. However, there's no clear way how to do this. As an aside, the new keyboard routines seem to be more stable, but the key buffering is causing some problems. If you attack a raas, for example, and want to run away, you're hosed. About 25 key strokes have been buffered for the attack, and there's no way to get away. Can this be fixed? P.S. - for all you NeXT users, I've been able to create a FAT version of Crossfire! As soon as a REAL STABLE (tm) version comes out, I'll release it to the archives. -jason ____________________________________________________________ Jason Fosback, Systems Engineer | No sir, I didn't like it --- Paradigm Systems Corp --- | -R&S Internet: jason_fosback@psca.com | Star Trek: NeXT mail: jason_fosback@psca.com | The NeXT Generation... From crossfire-request Thu Apr 7 16:59:01 1994 Return-Path: Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 7 Apr 1994 16:58:58 +0200 Received: (postman@localhost) by andrew.cmu.edu (8.6.7/8.6.4) id KAA09456 for crossfire@ifi.uio.no; Thu, 7 Apr 1994 10:58:54 -0400 Received: via switchmail; Thu, 7 Apr 1994 10:58:53 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Thu, 7 Apr 1994 10:57:27 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Thu, 7 Apr 1994 10:57:23 -0400 (EDT) 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; Thu, 7 Apr 1994 10:57:22 -0400 (EDT) Message-ID: Date: Thu, 7 Apr 1994 10:57:22 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: HELP! crossfire 0.90.4 In-Reply-To: <9404071257.AA02581@condor.Philabs.Philips.Com> References: <9404071257.AA02581@condor.Philabs.Philips.Com> Status: RO sew@philabs.Philips.COM writes: > - No areas for newbies to go and get EXP fast to move up lower levels quickly. > This was a good idea in the 89 version because you could move up to level > 10 with a minimum of frustration. The little monsters are annoying when > you are a lower level. The "spiral" design was excellent for this, as you > progressed it got harder, and when you finished you could be at least > level seven, the really hard one was good for 250,000 exp. I think it is good that there are no places to get exp fast. I think it should be a challenge to get experience, not a cake-walk. Otherwise it's not experience. I also think that things should be interesting for low-level characters as well as high level ones. -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 Thu Apr 7 15:10:44 1994 Return-Path: Received: from erau.db.erau.edu (db.erau.edu [155.31.1.13]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 7 Apr 1994 15:10:41 +0200 Received: from scorpius.sun by erau.db.erau.edu with smtp (Smail3.1.28.1 #2) id m0potrq-0007w4C; Thu, 7 Apr 94 09:11 EDT Received: by scorpius.sun (4.1/SMI-4.1) id AA07750; Thu, 7 Apr 94 09:14:50 EDT Date: Thu, 7 Apr 1994 09:13:21 -0400 (EDT) From: Jeff Judkins Subject: Re: TODO (for sure) in the future. To: Tyler Van Gorder Cc: crossfire@ifi.uio.no In-Reply-To: <199404070627.XAA22228@corpse.ecst.csuchico.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 6 Apr 1994, Tyler Van Gorder wrote: > First off, I think the color pixmaps really add a whole lot to crossfire, they > are really cool. But a problem we have here is our xterms running out of memory > when running crossfire....yes.....In order to run crossfire you need to only be > running the "BARE" minimum on your xterm....no xv, no 3 xterms running, no > xbiff, just one xterm and crossfire. Try to open two clients to crossfire...I > dont think so! :> I always have at least 3 xterms, xbiff, perfmeter, audiocontrol, xclock and my virtual window open and I can still run crossfire. I've had at least three open with that setup before. This is on Sparc IPX's with 16 megs and IPC's with 12 megs. +============================+=========================================+ | This message courtesy of: | "Do you want me to make your life a | | | living hell?" | | Jeff Judkins | "Sorry, I'm not looking for a relation- | | judkinsj@erau.db.erau.edu | ship right now, but thanks for asking" | +============================+=========================================+ Kill'em all and then just let God sort out the mess. From crossfire-request Thu Apr 7 14:57:54 1994 Return-Path: Received: from philabs.Philips.COM (root@philabs.philips.com [192.207.123.2]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 7 Apr 1994 14:57:49 +0200 From: sew@philabs.Philips.COM Received: from condor.Philabs.Philips.Com by philabs.Philips.COM (smail2.5/12-15-87/4.1) id AA06738; Thu, 7 Apr 94 08:57:41 EDT Received: from loopback by condor.Philabs.Philips.Com (4.1/SMI-4.1) id AA02581; Thu, 7 Apr 94 08:57:40 EDT Message-Id: <9404071257.AA02581@condor.Philabs.Philips.Com> To: crossfire@ifi.uio.no Subject: HELP! crossfire 0.90.4 Date: Thu, 07 Apr 94 08:57:39 -0400 Status: RO Has anyone else been having problems with the latest version? We just installed 90.4 a few days ago and we have been having nothing but problems since then. We upgraded from 90.3 which was buggy, but not this buggy. But the maps & quests are better now. Here are some of the problems we have noticed, - Constantly crashes, and doesn't do an emergency save so we lose all our hard earned equipment. - Whenever we enter Santo Dominion/Stinking_bungalow, it crashes. This will always happen. - Small/Medium/Large_fireballs shoot blanks. They don't engulf the area in flames. - We weren't able to use our old players ( which were level 30 and higher ) - No areas for newbies to go and get EXP fast to move up lower levels quickly. This was a good idea in the 89 version because you could move up to level 10 with a minimum of frustration. The little monsters are annoying when you are a lower level. The "spiral" design was excellent for this, as you progressed it got harder, and when you finished you could be at least level seven, the really hard one was good for 250,000 exp. - When you first start out, you get no weapons or armour. This was nice as a default and when you had enough money you could buy better stuff. We enjoy this game, but we're pulling our hair out here. Anyone have suggestions I can pass on to my SYS ADMIN ? Can you recommend any other maps besides the 90.4 maps? Also, how are these implented? Happy Gaming ! thanks, Scott -------- From crossfire-request Thu Apr 7 09:49:12 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, 7 Apr 1994 09:49:04 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA20747 (5.67a8/IDA-1.5 for ); Thu, 7 Apr 1994 00:48:58 -0700 Received: by bolero.rahul.net id AA17269 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 7 Apr 1994 00:48:57 -0700 Date: Thu, 7 Apr 1994 00:48:57 -0700 From: Mark Wedel Message-Id: <199404070748.AA17269@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Several notes. Status: RO Will combine a few unrelated things into one message: First, if you have source changes that you want to get in the next version, try to get them to me Monday. I plan to put out a new version next week, so that I can work on re-doing objects into two lists - one for living, and one for non living. With more objects being added to maps (ie, floors below walls that were not there before), I think this is becoming a little more important. Map editing: Most editing I have done so far has been the following: Adding signs to various places describing what buildings are open and stuff. Also, if while playing, I notice some errors (ie, exit does not match up to entrance, meaning, that hwen you exit, you end up 5 squares away from the entrance), or minor things like that, I fix them. I've taken over the city hall map, and have added statues for everyone in the CREDITS list. If I notice a major problem with maps, I will put it in the problem directory (already, all the unlinked maps have been moved there. Also, I am not adding background pixmaps for every map either. In summary, I am only editing maps that have minor problems. Maps with major problems get put in the problems directory, I don't mess with maps without any problems. XPM file space: According to my calculation, each XPM image (24x24) should take up 648 bytes (including mask). This does not include any overhead that the server puts in. With 2100 (or so) pixmaps, this amounts to about 1.36 MB. However, if the display device is 24 bit, then the pixmaps might be stored as 24 bit images. This would make the size of each about 1800 bytes (about 3.75 MB for all of them.) While 1.3 MB is a bit, I don't see that as being a major problem. If the display devices are 24 bit, it should not be to hard to create the pixmaps as 8 bit images. Sometime when I run it on my sun, I'll have to see how much more space the X server takes up. I've (hopefully) fixed the bug of two different floor types under a stretch of wall with the same type. Have yet to test it, however. --Mark From crossfire-request Thu Apr 7 08:35:03 1994 Return-Path: Received: from corpse.ecst.csuchico.edu (corpse.ecst.csuchico.edu [132.241.5.10]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 7 Apr 1994 08:34:59 +0200 Received: (from tvangod@localhost) by corpse.ecst.csuchico.edu (8.6.8/8.6.6) id XAA22272; Wed, 6 Apr 1994 23:34:23 -0700 From: Tyler Van Gorder Message-Id: <199404070634.XAA22272@corpse.ecst.csuchico.edu> Subject: Re: Various thoughts. To: Tero.Haatanen@lut.fi (Tero Haatanen) Date: Wed, 6 Apr 1994 23:34:22 -0700 (PDT) Cc: crossfire@ifi.uio.no In-Reply-To: <199404060853.LAA14498@kaisa.it.lut.fi> from "Tero Haatanen" at Apr 6, 94 11:53:27 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3183 Status: RO > > > Maps: If you plan on editing the ones in the offical distribution, let > > me know first, so I can tell you if I ahve done any editing or not. > > I think it probably better that the original author do all editing, if (s)he > is still interested updating maps. Otherwise the new version of map might > override all changes made be other people. Not a bad idea, this would take some of the load off of Mark so he can concentrate on other things :> > > > Also, if there is information that the NPC needs to tell you, there should > > be some way of knowing to ask the correct question, and not just guesswork. > > Also every monster who have something to say should respond something to > all words. I udes to test if monster can talk saying "hi", but changed > that after I notice that some monsters react only for "hello", "name", etc. > > There was a small bug in load_original_map, which caused 2 players entering > new map in same time entering different locations. I have fixed it now. > I haven't seen the closing exit bug, so can't say anything about it. > > About pixmaps. Like Mark already said, it would be nice get all building > same rotation and shading (if any). About cobblestones entry in shops, > it's probably compromise, since if you left it away and put cobblestones > under shop it looks good. But when player is top of shop, pixmap behind > player is cobblestones and not the shop and that looks really weird. > One more thing I like to see is more pixmaps for normal big houses (2x2). > I think that towns with many small (and empty) houses don't look so good > than towns with few big houses. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ note: We here at Chico have been going color pixmap crazy coloring all houses.. we did not do the rotation stuff yet, will try to do this before we ship them to mark. Does this mean that the top down houses (1 dimension) have to be redrawn to look 3d??? On other note.....in many of the towers, keeps, palaces we also added shading to make it look as if a light source were shining on one side of the building...it looks really nice...but again we tryed to keep consistancy, in that all buildings are shaded on the same side( as if light source were down and to the right of the building) It would look really wierd if one building was shaded on the the same side that another building has light shining on it. Just another thing to keep in mind. > There seems to be a small bug in pixmap drawing. If there is two different > floors under wall (e.g. starting city, citywalls, grass and cobblestones) > game doesn't update floor under wall right. Also player can see through the > walls sometimes (cityhall and altar), probably caused only slow window > updates. It seems that game first draws the view and then calculates LOS > and blocks the view. > > It was me who said about doing those special arrows. I have been quite > busy lataly, but I try get patch Mark before next release. I still think > that exploding arrows don't belong to crossfire. There is enough magic > already, IMHO. slaying arrows would be really cool! :> Tyler From crossfire-request Thu Apr 7 08:27:18 1994 Return-Path: Received: from corpse.ecst.csuchico.edu (corpse.ecst.csuchico.edu [132.241.5.10]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 7 Apr 1994 08:27:15 +0200 Received: (from tvangod@localhost) by corpse.ecst.csuchico.edu (8.6.8/8.6.6) id XAA22228 for crossfire@ifi.uio.no; Wed, 6 Apr 1994 23:27:09 -0700 From: Tyler Van Gorder Message-Id: <199404070627.XAA22228@corpse.ecst.csuchico.edu> Subject: TODO (for sure) in the future. To: crossfire@ifi.uio.no Date: Wed, 6 Apr 1994 23:27:09 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1510 Status: RO First off, I think the color pixmaps really add a whole lot to crossfire, they are really cool. But a problem we have here is our xterms running out of memory when running crossfire....yes.....In order to run crossfire you need to only be running the "BARE" minimum on your xterm....no xv, no 3 xterms running, no xbiff, just one xterm and crossfire. Try to open two clients to crossfire...I dont think so! :> This all made a point clear that has to be met........I dont see this being something that we implement in the current version..as we will be scrapping it soon enough (hopefully) for the client/server stuff. We need to dynamically allocate space for pixmaps and deallocate pixmaps that arent used on the client side for a given period of time.....this would definately make crossfire a little more xterm friendly :> I guess you could call it a pixmap cacheing system? why have the pixmaps of a galeotroll loaded if you only run into 1 troll in a 3 hour session? I dont think that dynamic loading of the pixmaps would be that big of a deal, as you load a map, you check to see that each object on the map has its pixmaps in memory...if not..you load them. Then have a routine to swap out pixmaps that haven't been used in a while.....once every n ticks? thoughts??? ideas??? Tyler. ps. Has anyone else run into this out of memory problem?? our xterms we use have 8 megs of memory to play with.....so crossfire must be allocating one huge amount of that with color pixmaps. From crossfire-request Thu Apr 7 04:35:16 1994 Return-Path: Received: from po5.andrew.cmu.edu (PO5.ANDREW.CMU.EDU [128.2.10.105]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 7 Apr 1994 04:35:13 +0200 Received: (postman@localhost) by po5.andrew.cmu.edu (8.6.7/8.6.4) id WAA19073 for crossfire@ifi.uio.no; Wed, 6 Apr 1994 22:35:04 -0400 Received: via switchmail; Wed, 6 Apr 1994 22:35:03 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Wed, 6 Apr 1994 22:34:11 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Wed, 6 Apr 1994 22:34:07 -0400 (EDT) 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; Wed, 6 Apr 1994 22:34:07 -0400 (EDT) Message-ID: <0hcr4TW00Zk20Ntv8u@andrew.cmu.edu> Date: Wed, 6 Apr 1994 22:34:07 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: Talking to NPC's In-Reply-To: <199404061006.AA21698@fb3-s7.math.tu-berlin.de> References: <199404061006.AA21698@fb3-s7.math.tu-berlin.de> Status: RO Gregor Schmid writes: > Mark Wedel writes: > I'm afraid it is a bit late for that though, but maybe it's a thought. I've been thinking about putting in tcl for more general purposes. I want to be able to have boats that move, and monsters that think more when they deal with players. -Eric ********************************************************* "It seemed like a good idea at the time" -The Mad Hatter "Yes, you're very smart. Shut up." -In "The Princess Bride" ********************************************************* From crossfire-request Wed Apr 6 13:15:14 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 ; Wed, 6 Apr 1994 13:15:00 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA21715 (5.67a8/IDA-1.5 for ); Wed, 6 Apr 1994 03:59:26 -0700 Received: by bolero.rahul.net id AA26628 (5.67a8/IDA-1.5); Wed, 6 Apr 1994 03:59:25 -0700 Date: Wed, 6 Apr 1994 03:59:25 -0700 From: Mark Wedel Message-Id: <199404061059.AA26628@bolero.rahul.net> To: crossfire@ifi.uio.no, schmid@fb3-s7.math.tu-berlin.de Subject: Re: xpm: designing Status: RO The reason only the floor and top object is drawn for any space is for reasons of speed. All floor and top objects are stored in an array the size of the map. This makes lookup of that floor or top object very quick. To actually get the objects at the maps location, and then go through and check them for various status will be quite a bit slower. The idea is a good one, I am not sure of the performance aspect. Depending on how it is handled with client/server, it could perhaps be done then without much problem. I really don't know how the display is going to be handled in that case. --Mark From crossfire-request Wed Apr 6 12:18:38 1994 Return-Path: Received: from gyda.ifi.uio.no (0@gyda.ifi.uio.no [129.240.78.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 6 Apr 1994 12:18:37 +0200 Received: from mailgzrz.TU-Berlin.DE by gyda.ifi.uio.no ; Wed, 6 Apr 1994 12:10:40 +0200 Received: from fb3-s7.math.TU-Berlin.DE by mailgzrz.TU-Berlin.DE (5.65c/ZRZ-MX) for id AA17553; Wed, 6 Apr 1994 12:06:22 +0200 Received: by fb3-s7.math.tu-berlin.de id AA21698 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Wed, 6 Apr 1994 12:06:21 +0200 Date: Wed, 6 Apr 1994 12:06:21 +0200 From: Gregor Schmid Message-Id: <199404061006.AA21698@fb3-s7.math.tu-berlin.de> To: crossfire@ifi.uio.no In-Reply-To: <199404052219.AA13033@bolero.rahul.net> Subject: Re: Talking to NPC's Status: RO Mark Wedel writes: > Conversation code should really be re-done at some point, to allow for > more advanced features (give or take, for example), as well as different > states. Right now, if there is a match for yes, there can only be > one response. Different states should be used, so you can be asked a series > of yes/no questions, and with each answer, have a different question come > up. > > --Mark I think it's time to rethink the general approach here. Crossfire implements a simple parser for the archetypes, including the @match handling, which does it's job but not much more. Whenever there is need for a new feature, tha parser has to be extended. How about including a real scripting language like tcl into crossfire. It would be hard at first, but tcl runs on just about every unix box (there's even a DOS port, ugh) and is easy to combine with any app. Archetypes and maps could then include tcl-scripts that are evaluated at run time, which brings about unlimited possibilities. I'm afraid it is a bit late for that though, but maybe it's a thought. By the way, the overhead wouldn't be much more than the existing parser. Regards, Greg From crossfire-request Wed Apr 6 12:07:38 1994 Return-Path: Received: from mailgzrz.TU-Berlin.DE (mailgzrz.TU-Berlin.DE [130.149.4.10]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 6 Apr 1994 12:02:41 +0200 Received: from fb3-s7.math.TU-Berlin.DE by mailgzrz.TU-Berlin.DE (5.65c/ZRZ-MX) for id AA16293; Wed, 6 Apr 1994 11:59:52 +0200 Received: by fb3-s7.math.tu-berlin.de id AA21539 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Wed, 6 Apr 1994 11:59:51 +0200 Date: Wed, 6 Apr 1994 11:59:51 +0200 From: Gregor Schmid Message-Id: <199404060959.AA21539@fb3-s7.math.tu-berlin.de> To: crossfire@ifi.uio.no In-Reply-To: <199404052223.AA13250@bolero.rahul.net> Subject: Re: xpm: designing Status: RO Mark Wedel writes: > I am not sure if I totally followed your message correctly, but a > few comments. > > As far as I know, there is nothing preventing a map designer to > change the is_floor variables for specific archetypes inside of > crossedit. So in some cases, that shop building might be a floor, while > in others, it should be an actual object. > > I actually think that the cobblestone entry way for shops, while looking > nice for towns which have cobblestone roads, looks odd for towns that > using something else. It would probably be better to just leave that > blank, and then put whatever the appropriate floor is below it. I did those cobblestone shops, and I don't like them this way either. I tried to put a floor below and leave the space blank, but then you only see the floor instead of the shop whenever there's an object or player on it, and that looks horrible. How about he following solution: Change the display code to draw all items of type is_floor on top of each other, then draw the topmost item on the stack. If archetypes are handled carefully so that floor-type items are always no_pick, we don't run the risk of having to draw hundreds of pixmaps in one spot, but mostly two or maybe three. Then you just put whatever floor you want under the shop and get both drawn, even if you step on the entrance. This would also help for levers and handles, which would then only be hidden by large objects, but not by an arrow or bolt. Any thoughts? Regards, Greg From crossfire-request Wed Apr 6 20:24:37 1994 Return-Path: Received: from acasun.eckerd.edu (acasun.eckerd.edu [198.187.211.2]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 6 Apr 1994 20:24:32 +0200 Received: by acasun.eckerd.edu (5.0/SMI-SVR4) id AA02195; Wed, 6 Apr 1994 14:21:11 +0500 Date: Wed, 6 Apr 1994 14:21:11 +0500 From: roy@eckerd.edu (Jonathan Roy) Message-Id: <9404061821.AA02195@acasun.eckerd.edu> To: crossfire@ifi.uio.no Subject: Re: Elemental spells Content-Length: 1003 Status: RO My idea for elemental spells is to allow control of them like normal. If you switch from the spell (tap plus or something) then the elemental disappears. However, if you are hit, then you lose control, and the elemental attacks you instead. :) If you add more summoning type spells (and ever break up spells by class or something) then there could be a whole class Summoner or something. :) (I like the systems of magic where it's broken into 'realms' or something. If you are a Summoner, for instance, you can learn summoning spells easier, they are stronger, and you can learn the most powerful summoning spells. If you are an Evoker, let's say, you can learn large fireball and firewire and all that, but only weaker summoning spells, since you are focused on the evocation spells, not summoning spells...) I just sort of like that more, myself. I like the flavor of games where fighters can't (or can only barely) cast magic, wizards have their spells, priests have different spells, etc etc. From crossfire-request Wed Apr 6 10:53:43 1994 Return-Path: Received: from kaisa.it.lut.fi (haatanen@kaisa.it.lut.fi [157.24.21.70]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 6 Apr 1994 10:53:42 +0200 Received: from localhost (haatanen@localhost) by kaisa.it.lut.fi (8.6.5/8.6.5/1.12.kim) id LAA14498; Wed, 6 Apr 1994 11:53:29 +0300 (for crossfire@ifi.uio.no) From: Tero Haatanen Message-Id: <199404060853.LAA14498@kaisa.it.lut.fi> Subject: Re: Various thoughts. To: crossfire@ifi.uio.no Date: Wed, 6 Apr 94 11:53:27 EET DST In-Reply-To: <199404050256.AA29096@bolero.rahul.net>; from "Mark Wedel" at Apr 4, 94 7:56 pm X-Mailer: ELM [version 2.3 PL11] Status: RO > Maps: If you plan on editing the ones in the offical distribution, let > me know first, so I can tell you if I ahve done any editing or not. I think it probably better that the original author do all editing, if (s)he is still interested updating maps. Otherwise the new version of map might override all changes made be other people. > Also, if there is information that the NPC needs to tell you, there should > be some way of knowing to ask the correct question, and not just guesswork. Also every monster who have something to say should respond something to all words. I udes to test if monster can talk saying "hi", but changed that after I notice that some monsters react only for "hello", "name", etc. There was a small bug in load_original_map, which caused 2 players entering new map in same time entering different locations. I have fixed it now. I haven't seen the closing exit bug, so can't say anything about it. About pixmaps. Like Mark already said, it would be nice get all building same rotation and shading (if any). About cobblestones entry in shops, it's probably compromise, since if you left it away and put cobblestones under shop it looks good. But when player is top of shop, pixmap behind player is cobblestones and not the shop and that looks really weird. One more thing I like to see is more pixmaps for normal big houses (2x2). I think that towns with many small (and empty) houses don't look so good than towns with few big houses. There seems to be a small bug in pixmap drawing. If there is two different floors under wall (e.g. starting city, citywalls, grass and cobblestones) game doesn't update floor under wall right. Also player can see through the walls sometimes (cityhall and altar), probably caused only slow window updates. It seems that game first draws the view and then calculates LOS and blocks the view. It was me who said about doing those special arrows. I have been quite busy lataly, but I try get patch Mark before next release. I still think that exploding arrows don't belong to crossfire. There is enough magic already, IMHO. -Tero From crossfire-request Wed Apr 6 07:36:15 1994 Return-Path: Received: from eden-valley.aaii.oz.AU (eden-valley.aaii.oz.AU [192.35.59.254]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 6 Apr 1994 07:35:58 +0200 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA13584; Wed, 6 Apr 1994 15:35:04 +1000 Date: Wed, 6 Apr 1994 15:35:04 +1000 From: "Rupert G. Goldie" Message-Id: <199404060535.AA13584@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no, peterm@soda.berkeley.edu Subject: Re: change to how AT_TURN_UNDEAD works Status: RO > > I don't much like the fact that holy word will nuke items. > It really shouldn't. No it shouldn't. I was never really happy that holy word did AT_PHYSICAL, but it was the last spell on a Saturday afternoon and it pretty much did what I wanted so the hack remained (ohhh the legacy of hacks 8-) [...] > Is there any reason not to change attack.c and the archetypes so > that both holy word and turn undead spells both do AT_TURN_UNDEAD, > except that turn undead spell will have a dam of zero and > holy word will have a damage base of 3? > Will this break anything? > > Regards, > > PeterM > That's probably the best way to handle it. It is probably easiest to AND AT_PHYSICAL onto type in the bit of code that handles AT_TURN_UNDEAD. hit_player() needs to be rewritten anyway. It is waaaaaay to long at 430 lines and should probably be split into separate functions for each attack type with another for calculating experience. Rupert From crossfire-request Wed Apr 6 05:37:43 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, 6 Apr 1994 05:37:40 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id UAA03751 for crossfire@ifi.uio.no; Tue, 5 Apr 1994 20:37:33 -0700 Date: Tue, 5 Apr 1994 20:37:33 -0700 From: Peter Mardahl Message-Id: <199404060337.UAA03751@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: change to how AT_TURN_UNDEAD works Status: RO I don't much like the fact that holy word will nuke items. It really shouldn't. The ability of that spell to both turn the undead and do damage to them was done by means of OR-ing AT_PHYSICAL with AT_TURN_UNDEAD. Objects exposed to holy word have to make saving throws agains physical damage. This caused holy word to destroy items like scrolls and spellbooks and food etc... Is there any reason not to change attack.c and the archetypes so that both holy word and turn undead spells both do AT_TURN_UNDEAD, except that turn undead spell will have a dam of zero and holy word will have a damage base of 3? Will this break anything? Regards, PeterM From crossfire-request Wed Apr 6 05:14:26 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, 6 Apr 1994 05:14:23 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id UAA01528 for crossfire@ifi.uio.no; Tue, 5 Apr 1994 20:13:58 -0700 Date: Tue, 5 Apr 1994 20:13:58 -0700 From: Peter Mardahl Message-Id: <199404060313.UAA01528@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: cancellation Status: RO has anyone actually observed cancellation to have worked? I mean, actually seen an object get cancelled? Regards, Peterm From crossfire-request Wed Apr 6 03:59:43 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, 6 Apr 1994 03:59:40 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id SAA23960 for crossfire@ifi.uio.no; Tue, 5 Apr 1994 18:59:27 -0700 Date: Tue, 5 Apr 1994 18:59:27 -0700 From: Peter Mardahl Message-Id: <199404060159.SAA23960@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: call for images for traps, can you help? Status: RO Would someone please think about making some images/archetypes for traps? Pits, mousetraps, beartraps, poison needles, blades, paralysis, sleeping gas, shockers.... Traps could do any of the following damage types: physical, fire, electricity, cold, confusion, acid, drain, (well, weaponmagic, whatever the hell that is), ghosthit, poison, slow, paralyze, fear, cancellation, depletion, death. Whatever suits your fancy. I'll do the archetypes if someone will do the images. I've tried to do artwork for crossfire, but I've failed miserably.... Regards, PeterM From crossfire-request Wed Apr 6 00:27:52 1994 Return-Path: Received: from bolero.rahul.net (master@bolero.rahul.net [192.160.13.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 6 Apr 1994 00:27:41 +0200 Received: by bolero.rahul.net id AA13489 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Tue, 5 Apr 1994 15:26:41 -0700 Date: Tue, 5 Apr 1994 15:26:41 -0700 From: Mark Wedel Message-Id: <199404052226.AA13489@bolero.rahul.net> To: cdarlast@mcs.dundee.ac.uk, crossfire@ifi.uio.no Subject: Re: A couple of Player questions Status: RO potions will raise a stat permanently. If you die too many times, it may be worth while to just state a new character. IF all your stats are 1, this is definately so. --Mark From crossfire-request Wed Apr 6 00:27:08 1994 Return-Path: Received: from bolero.rahul.net (master@bolero.rahul.net [192.160.13.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 6 Apr 1994 00:27:00 +0200 Received: by bolero.rahul.net id AA13419 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Tue, 5 Apr 1994 15:25:22 -0700 Date: Tue, 5 Apr 1994 15:25:22 -0700 From: Mark Wedel Message-Id: <199404052225.AA13419@bolero.rahul.net> To: cdarlast@mcs.dundee.ac.uk, crossfire@ifi.uio.no Subject: Re: Coloring Pixmaps Status: RO Just send a message to the list, saying you plan on coloring whatever pixmaps. If no one sends something back saying they are going to color those, or already have, feel save in coloring them yourself. One note for those coloring: Lets try to get all the buildings in the same facing. That is, trailing off to the left (like the shops.) As it is now, some buidlings trail off to the left (meaning, the two faces you see are the forward and left), while other buildings trail off to the right. I believe pixmap has some simple button that will do this rotation, but if you are doing shading, this could make things look odd. --Mark From crossfire-request Wed Apr 6 00:25:15 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, 6 Apr 1994 00:25:12 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id PAA26751 for crossfire@ifi.uio.no; Tue, 5 Apr 1994 15:24:59 -0700 Date: Tue, 5 Apr 1994 15:24:59 -0700 From: Peter Mardahl Message-Id: <199404052224.PAA26751@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: special/magical arrows, bolts Status: RO What's the status on putting those in the game? I'd really like to see them in. Arrows of slaying, or whatever. Arrows which explode into a spell on impact. someone was working on those..... PeterM From crossfire-request Wed Apr 6 00:23:26 1994 Return-Path: Received: from bolero.rahul.net (master@bolero.rahul.net [192.160.13.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 6 Apr 1994 00:23:22 +0200 Received: by bolero.rahul.net id AA13250 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Tue, 5 Apr 1994 15:23:01 -0700 Date: Tue, 5 Apr 1994 15:23:01 -0700 From: Mark Wedel Message-Id: <199404052223.AA13250@bolero.rahul.net> To: Petri.Heinila@lut.fi, crossfire@ifi.uio.no Subject: Re: xpm: designing Status: RO I am not sure if I totally followed your message correctly, but a few comments. As far as I know, there is nothing preventing a map designer to change the is_floor variables for specific archetypes inside of crossedit. So in some cases, that shop building might be a floor, while in others, it should be an actual object. I actually think that the cobblestone entry way for shops, while looking nice for towns which have cobblestone roads, looks odd for towns that using something else. It would probably be better to just leave that blank, and then put whatever the appropriate floor is below it. --Mark From crossfire-request Wed Apr 6 00:20:24 1994 Return-Path: Received: from bolero.rahul.net (master@bolero.rahul.net [192.160.13.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id ; Wed, 6 Apr 1994 00:20:18 +0200 Received: by bolero.rahul.net id AA13033 (5.67a8/IDA-1.5); Tue, 5 Apr 1994 15:19:47 -0700 Date: Tue, 5 Apr 1994 15:19:47 -0700 From: Mark Wedel Message-Id: <199404052219.AA13033@bolero.rahul.net> To: bjornlu@ifi.uio.no, crossfire@ifi.uio.no Subject: Re: Talking to NPC's Status: RO Conversation code should really be re-done at some point, to allow for more advanced features (give or take, for example), as well as different states. Right now, if there is a match for yes, there can only be one response. Different states should be used, so you can be asked a series of yes/no questions, and with each answer, have a different question come up. --Mark From crossfire-request Wed Apr 6 00:17:29 1994 Return-Path: Received: from bolero.rahul.net (master@bolero.rahul.net [192.160.13.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id ; Wed, 6 Apr 1994 00:17:23 +0200 Received: by bolero.rahul.net id AA12894 (5.67a8/IDA-1.5); Tue, 5 Apr 1994 15:17:08 -0700 Date: Tue, 5 Apr 1994 15:17:08 -0700 From: Mark Wedel Message-Id: <199404052217.AA12894@bolero.rahul.net> To: bjornlu@ifi.uio.no, crossfire@ifi.uio.no Subject: Re: Configuring movement keys Status: RO As I see it, the new input method is much more flexible than the old. 'search' can be used, but by default in the config.h file, it is disabled. At one time there was a bug that would cause it to hang, that might be fixed now. --Mark From crossfire-request Tue Apr 5 23:54:59 1994 Return-Path: Received: from bolero.rahul.net (master@bolero.rahul.net [192.160.13.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 5 Apr 1994 23:54:55 +0200 Received: by bolero.rahul.net id AA11474 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Tue, 5 Apr 1994 14:54:48 -0700 Date: Tue, 5 Apr 1994 14:54:48 -0700 From: Mark Wedel Message-Id: <199404052154.AA11474@bolero.rahul.net> To: crossfire@ifi.uio.no, tpeland@utu.fi Subject: Re: About (missing) colors Status: RO Certain vendors do distribute different rgb.txt files, with differing amount of colors. I remember getting a report from someone using X-Terminals that was missing a few colors. I think with the XPM files, it gets more difficult. The colors it uses are pre-defined in the file. There are methods to over-ride at load time, I believe. --Mark From crossfire-request Tue Apr 5 22:11:02 1994 Return-Path: Received: from castor.cc.utu.fi (root@castor.cc.utu.fi [130.232.1.14]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 5 Apr 1994 22:11:01 +0200 Received: by utu.fi id <165724-3>; Tue, 5 Apr 1994 23:10:48 +0300 Subject: The problem with closing exits From: Tero Jyri Michael Pelander To: crossfire@ifi.uio.no Date: Tue, 5 Apr 1994 23:10:43 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT Content-Length: 672 Message-Id: <94Apr5.231048eet_dst.165724-3@utu.fi> Status: RO I have now found out one of the ways that bring the 'the exit is closed' bug constantly. When a player is moving to a _new_ (=unloaded) map and and other player enters an exit the later player will get where he wanted to but the player that initiated the load of new map is going to be stuck. The loaded map has all exits closed. Even if the other player is comming to the same map as the previous player they will get to different locations. Only way out of the 'stuck map' is word of recall or invis_exit. The later will return to the real map (and even load it if needed) after he returns. I don't know what to fix. That is left for others. (crossfire 0.90.4) From crossfire-request Tue Apr 5 21:21:26 1994 Return-Path: <<@ib.rl.ac.uk:cdarlast@mcs.dundee.ac.uk>> Received: from ib.rl.ac.uk (ib.rl.ac.uk [192.100.78.20]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 5 Apr 1994 21:21:26 +0200 Received: from letterbox.rl.ac.uk by ib.rl.ac.uk (IBM VM SMTP V2R1) with TCP; Tue, 05 Apr 94 20:21:15 BST Received: from pop.mcs.dundee.ac.uk by letterbox.rl.ac.uk with SMTP (PP) id <20502-0@letterbox.rl.ac.uk>; Tue, 5 Apr 1994 19:19:45 +0000 Received: from clyde.mcs.dund.ac.uk (clyde.mcs.dundee.ac.uk) by pop.mcs.dundee.ac.uk (4.1/SMI-4.1) id AA29641; Tue, 5 Apr 94 20:22:53 BST Date: Tue, 5 Apr 94 20:22:53 BST From: cdarlast@mcs.dundee.ac.uk (Chris Darlaston) Message-Id: <9404051922.AA29641@pop.mcs.dundee.ac.uk> To: crossfire@ifi.uio.no Subject: Coloring Pixmaps Status: RO Who do we ask about getting a couple of pixmaps assigned to us so that we can color them in. We do not want to color in ones that are already colored or in the process of being colored. Thanks Chris Darlaston (cdarlast@mcs.dund.ac.uk) From crossfire-request Tue Apr 5 21:19:23 1994 Return-Path: <<@ib.rl.ac.uk:cdarlast@mcs.dundee.ac.uk>> Received: from ib.rl.ac.uk (ib.rl.ac.uk [192.100.78.20]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 5 Apr 1994 21:19:22 +0200 Received: from letterbox.rl.ac.uk by ib.rl.ac.uk (IBM VM SMTP V2R1) with TCP; Tue, 05 Apr 94 20:19:11 BST Received: from pop.mcs.dundee.ac.uk by letterbox.rl.ac.uk with SMTP (PP) id <20403-0@letterbox.rl.ac.uk>; Tue, 5 Apr 1994 19:17:46 +0000 Received: from clyde.mcs.dund.ac.uk (clyde.mcs.dundee.ac.uk) by pop.mcs.dundee.ac.uk (4.1/SMI-4.1) id AA29633; Tue, 5 Apr 94 20:20:53 BST Date: Tue, 5 Apr 94 20:20:53 BST From: cdarlast@mcs.dundee.ac.uk (Chris Darlaston) Message-Id: <9404051920.AA29633@pop.mcs.dundee.ac.uk> To: crossfire@ifi.uio.no Subject: A couple of Player questions Status: RO Now that you can enable no permanent death, is there a way that the player can regain permanent points of a stat? At the moment there is a chance that a player who is careful, but has a bad share of luck will end up at all stats 1. I asked the local person who installed crossfire, but he did not know about it, so I thought that I better ask the experts. We seem to have a problem with crossedit and gzipping. The 'editor/picks' do not work when they are gzipped. Is it a problem with our set up? I can mail the set up to people if they want it. Thanks for the advice (Hopefully) :-) Chris Darlaston (cdarlast@mcs.dund.ac.uk) Ps: Keep up all the good work.... It is a great game :) From crossfire-request Wed Apr 6 04:00:55 1994 Return-Path: Received: from acasun.eckerd.edu (acasun.eckerd.edu [198.187.211.2]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 6 Apr 1994 04:00:49 +0200 Received: by acasun.eckerd.edu (5.0/SMI-SVR4) id AA20280; Tue, 5 Apr 1994 21:57:32 +0500 Date: Tue, 5 Apr 1994 21:57:32 +0500 From: hluciano@eckerd.edu (Henry J. Luciano) Message-Id: <9404060157.AA20280@acasun.eckerd.edu> To: crossfire@ifi.uio.no Subject: Elemental spells Content-Length: 450 Status: RO A minor annoyance: is there an easy way to make a summoned elemental move using only a single keystroke? That is, without having to "re-hold" the summon spell move it? -------------------------------------------------------------------- Henry John Luciano, IV | Good... Bad... I'm the guy with the gun. hluciano@eckerd.edu | --"Good" Ash, from _Army of Darkness_ -------------------------------------------------------------------- From crossfire-request Tue Apr 5 18:35:20 1994 Return-Path: Received: from cc.lut.fi (hevi@cc.lut.fi [157.24.15.37]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 5 Apr 1994 18:35:19 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id TAA20200; Tue, 5 Apr 1994 19:34:59 +0300 Date: Tue, 5 Apr 1994 19:34:59 +0300 (EETDST) From: Petri Heinil{ Subject: xpm: designing To: crossfire@ifi.uio.no Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO There is one point to solve in xpm designing. When showed the map-place there is first drawed the floor and then the item. But how about the houses or generally object that should be visible for applying in "you see" window, like exists. There is now in shops solved this by drawing the gobblestones into shop. And the shop is used as floor. But if one want use some other ground ? Is it new shop to be drawed ? The other way is to keep ground and exits separate and combinatory. In this case there is lost ground in "you see" window. But this somewhat common way. Thinks ? -- The Page -- From crossfire-request Tue Apr 5 17:22:31 1994 Return-Path: Received: from atuk.aspentec.com (rouge.atuk.aspentec.com [192.160.185.48]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 5 Apr 1994 17:22:26 +0200 Received: by atuk.aspentec.com (MX V3.3 VAX) id 318; Tue, 05 Apr 1994 16:21:50 GMT Date: Tue, 05 Apr 1994 16:21:05 GMT From: "Sam Mackrill : AspenTech UK" To: crossfire@ifi.uio.no CC: mackrill@atuk.aspentec.com Message-ID: <0097C828.3EBB0500.318@atuk.aspentec.com> Subject: Re: Charisma Status: RO Eric writes > Why don't we just get rid of the charisma bonus thing for buying and > selling stuff? Here, here. I've never heard of such guillable shopkeepers. They all invest in magic to prevent you casting spells within their shop, so you'd think they would protect against amazingly charismatic customers. And anyway what sort of business do they think they are running , letting their profits be slashed by a pretty face / charming voice? Sam From crossfire-request Tue Apr 5 16:17:06 1994 Return-Path: Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 5 Apr 1994 16:17:03 +0200 Received: from localhost (postman@localhost) by andrew.cmu.edu (8.6.4/8.6.4) id KAA06131 for crossfire@ifi.uio.no; Tue, 5 Apr 1994 10:16:54 -0400 Received: via switchmail; Tue, 5 Apr 1994 10:16:53 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Tue, 5 Apr 1994 10:16:23 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Tue, 5 Apr 1994 10:16:16 -0400 (EDT) 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, 5 Apr 1994 10:16:16 -0400 (EDT) Message-ID: Date: Tue, 5 Apr 1994 10:16:16 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: Charisma CC: crossfire@ifi.uio.no In-Reply-To: <199404031408.AA08288@ild.alkymi.unit.no> References: <199404031408.AA08288@ild.alkymi.unit.no> Status: RO Inge Berg Fenstad writes: > Well it was said that you couldn't multiply money with 30 Cha...but you DO. > At least when you get diamonds for money in bank and then sell them > with 30Cha...You still earn approx 10%. > > Inge who still thinks 30Cha is cheap. Why don't we just get rid of the charisma bonus thing for buying and selling stuff? If nothing else, when you couldn't cast multiple charisma spells, I just created another character with a really high charisma and strength and just used them to buy and sell everything. -- Make charisma keep monsters from attacking you or make it cause people to be more helpful or something like that. -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 Apr 5 12:26:07 1994 Return-Path: Received: from gyda.ifi.uio.no (2116@gyda.ifi.uio.no [129.240.78.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 5 Apr 1994 12:26:06 +0200 From: =?iso-8859-1?Q?Bj=F8rn_Georg_Ludvigsen?= MIME-Version: 1.0 Received: (from bjornlu@localhost) by gyda.ifi.uio.no ; Tue, 5 Apr 1994 12:26:05 +0200 Date: Tue, 5 Apr 1994 12:26:04 +0200 To: crossfire@ifi.uio.no Subject: Talking to NPC's Message-ID: Status: RO > Also, if there is information that the NPC needs to tell you, there should > be some way of knowing to ask the correct question, and not just > guesswork. Most 'conversations' are set up to use keywords. The playe > should have some idea of the keyword to use (either from a previous > response, or as a referral.) Back in the good old Ultima days, you had to talk to a character for a while, ask him/her several questions before you could ask some of the really important questions. In Ultima IV, you had to collect a lot of information, for example about some stones, among othet things. But you couldn't just walk up to the character and say/ask 'stone', you had to small-talk a bit first. (Ok, so you only had to ask one spesific question, but the information was not revealed at once) A simple (?) boolean-thingie in the conversation code? It sure would improve the questmaking possibilities... - Regards, Bjorn. From crossfire-request Tue Apr 5 11:55:50 1994 Return-Path: Received: from gyda.ifi.uio.no (2116@gyda.ifi.uio.no [129.240.78.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 5 Apr 1994 11:55:50 +0200 From: =?iso-8859-1?Q?Bj=F8rn_Georg_Ludvigsen?= MIME-Version: 1.0 Received: by gyda.ifi.uio.no ; Tue, 5 Apr 1994 11:55:48 +0200 Date: Tue, 5 Apr 1994 11:55:48 +0200 To: crossfire@ifi.uio.no Subject: Configuring movement keys Message-ID: Status: RO And while I'm at it; who didn't like the old way movement keys were configured, and why? - Regards, Bjorn. From crossfire-request Tue Apr 5 11:51:56 1994 Return-Path: Received: from gyda.ifi.uio.no (2116@gyda.ifi.uio.no [129.240.78.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 5 Apr 1994 11:51:56 +0200 From: =?iso-8859-1?Q?Bj=F8rn_Georg_Ludvigsen?= MIME-Version: 1.0 Received: by gyda.ifi.uio.no ; Tue, 5 Apr 1994 11:51:52 +0200 Date: Tue, 5 Apr 1994 11:51:48 +0200 To: crossfire@ifi.uio.no Subject: Search? Message-ID: Status: RO What happened to 'search'? And, what happened to internal command completion? Were they not just about the two most used features? - Regards, Bjorn. From crossfire-request Tue Apr 5 11:51:59 1994 Return-Path: Received: from castor.cc.utu.fi (root@castor.cc.utu.fi [130.232.1.14]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 5 Apr 1994 11:51:58 +0200 Received: from polaris.cc.utu.fi by utu.fi id <165717-4>; Tue, 5 Apr 1994 12:51:49 +0300 Subject: About (missing) colors From: Tero Jyri Michael Pelander To: crossfire@ifi.uio.no Date: Tue, 5 Apr 1994 12:51:37 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT Content-Length: 537 Message-Id: <94Apr5.125149eet_dst.165717-4@utu.fi> Status: RO Locally I have found one problem with crossfire. One type of the X clients does not have any of the colors that have a number behind them. That means that colors like "dimgrey" exists but "grey50" doesn't. I have made patches that switch to an alternate color list when it notices this. I would like to know if any others have this problem so that the patches for handling this should be added or is it just a local problem. The symptoms are: you have color display and get errors "Color not found", "Switching to black and white". From crossfire-request Tue Apr 5 09:42:14 1994 Return-Path: Received: from corpse.ecst.csuchico.edu by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 5 Apr 1994 09:42:11 +0200 Received: (from tvangod@localhost) by corpse.ecst.csuchico.edu (8.6.8/8.6.6) id AAA28461; Tue, 5 Apr 1994 00:41:49 -0700 From: Tyler Van Gorder Message-Id: <199404050741.AAA28461@corpse.ecst.csuchico.edu> Subject: Re: Various thoughts. To: jorgens@pvv.unit.no (Kjetil Wiekhorst J|rgensen) Date: Tue, 5 Apr 1994 00:41:49 -0700 (PDT) Cc: crossfire@ifi.uio.no In-Reply-To: <9404050408.AA19366@nova.pvv.unit.no> from "Kjetil Wiekhorst J|rgensen" at Apr 5, 94 06:08:21 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 789 Status: RO > > I've colored the towers and speedboots. > I'll do the armors later. > > Kjetil > We here at chico have done ALL buildings...houses, towers, banks, etc etc.... I really like the towers as we have added shading into most...so they look as if daylight were hitting them from one side.....also with the bigger castle/ keep we have put vines up the side...it looks pretty cool, would really like to get these into the official release :> so maybe we can compare towers and choose. we have also done the entire magic directory. we have started on the monster directory...but havent done much with it yet. If you wish to also do the monsters...let us know which ones your doing...and likewise I will try to keep people on the list..up to date on which pixmaps we are editing. Tyler From crossfire-request Tue Apr 5 06:08:24 1994 Return-Path: Received: from flipper.pvv.unit.no by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 5 Apr 1994 06:08:24 +0200 Received: from nova.pvv.unit.no (nova.pvv.unit.no [129.241.36.207]) by flipper.pvv.unit.no (8.6.8/8.6.6) with SMTP id FAA22037 for ; Tue, 5 Apr 1994 05:08:22 +0100 From: Kjetil Wiekhorst J|rgensen Received: by nova.pvv.unit.no ; Tue, 5 Apr 94 06:08:21 +0200 Date: Tue, 5 Apr 94 06:08:21 +0200 Message-Id: <9404050408.AA19366@nova.pvv.unit.no> To: crossfire@ifi.uio.no Subject: Re: Various thoughts. Status: RO I've colored the towers and speedboots. I'll do the armors later. Kjetil From crossfire-request Tue Apr 5 04:57:01 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 5 Apr 1994 04:56:56 +0200 Received: by bolero.rahul.net id AA29096 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Mon, 4 Apr 1994 19:56:48 -0700 Date: Mon, 4 Apr 1994 19:56:48 -0700 From: Mark Wedel Message-Id: <199404050256.AA29096@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Various thoughts. Status: RO Just a mixture of thoughts and suggestions I have: Those coloring XPM files: It would probably be a good idea to write on the list what files you are or are planning on coloring. I know that several people/groups are coloring them, and as far as I know, there is no coordinated effort. Also, to make things easier, it would probably be best to complete all the files in a directory before moving onto the next. This way, you can just say something like 'I've done all the images in monsters/acid, and plan to work on monsters/dragon next' Maps: If you plan on editing the ones in the offical distribution, let me know first, so I can tell you if I ahve done any editing or not. If I have edited that map, your map file may not make it into the distribution depending on the changes I made to mine. Also, if its just a minor change (spelling, missing archetype in a place or two, etc), you can just tell me what they are, and I will do it myself. Quests: I like the quest dungeons I have done so far. Some can take quite a while to do, however (old city). And while needing to get information from NPC's is a nice touch, be careful of the method. If there is a room full of 100 mostly identical creatures (townfolk, pirates, whatever), and just a few contain information, it is a real pain to have to go up to all of them and see if they actually have any information for you. At least in ultima, you either killed what you met, or talked to it. And pretty much everthing that was nonagressive had something notable to say. This is not true in crossfire. Also, if there is information that the NPC needs to tell you, there should be some way of knowing to ask the correct question, and not just guesswork. Most 'conversations' are set up to use keywords. The playe should have some idea of the keyword to use (either from a previous response, or as a referral.) --Mark From crossfire-request Sun Apr 3 16:08:36 1994 Return-Path: Received: from ild.alkymi.unit.no by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sun, 3 Apr 1994 16:08:35 +0200 Received: by ild.alkymi.unit.no id AA08288 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Sun, 3 Apr 1994 16:08:23 +0200 From: Inge Berg Fenstad Message-Id: <199404031408.AA08288@ild.alkymi.unit.no> Subject: Re: Charisma To: ingebf@alkymi Date: Sun, 3 Apr 1994 16:08:23 +0200 (MET DST) Cc: crossfire@ifi.uio.no X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 223 Status: RO Well it was said that you couldn't multiply money with 30 Cha...but you DO. At least when you get diamonds for money in bank and then sell them with 30Cha...You still earn approx 10%. Inge who still thinks 30Cha is cheap. From crossfire-request Sat Apr 2 05:51:39 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.7/ifi2.4) id for ; Sat, 2 Apr 1994 05:51:34 +0200 Received: by bolero.rahul.net id AA01544 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Fri, 1 Apr 1994 19:51:09 -0800 Date: Fri, 1 Apr 1994 19:51:09 -0800 From: Mark Wedel Message-Id: <199404020351.AA01544@bolero.rahul.net> To: crossfire@ifi.uio.no, khw2x@sonja.math.virginia.edu Subject: Re: Compressing xpm's... Status: RO According the the XPM libraries, if an XPM file is compress/gzip'd, the load routine should automatically uncrompess/gunzip them. I wonder if the compressed name needs to be given, however. I'll look into it From crossfire-request Sat Apr 2 02:47:51 1994 Return-Path: Received: from virginia.edu by ifi.uio.no with SMTP (8.6.7/ifi2.4) id for ; Sat, 2 Apr 1994 02:47:48 +0200 Received: from sonja.math.virginia.edu by uvaarpa.virginia.edu id aa04629; 1 Apr 94 19:47 EST Received: by sonja.math.Virginia.EDU (NX5.67c/NX3.0S) id AA07856; Fri, 1 Apr 94 19:47:48 -0500 From: "Kevin H. Weiss" Message-Id: <9404020047.AA07856@sonja.math.Virginia.EDU> Subject: Compressing xpm's... To: crossfire@ifi.uio.no Date: Fri, 1 Apr 1994 19:47:44 -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: 373 Status: RO How can I keep the xpm files compressed? When I did, crossfire would not read them. (obviously, this also means I got crossfire to compile with the XPM option!!! :) Compressed (with gzip) maps seem to work with no problems... Anybody have a simple hack to fix this? thanks, kevin PS My server, sonja.math.virginia.edu, seems to be up and running (and quite stable :) From crossfire-request Fri Apr 1 19:16:54 1994 Return-Path: Received: from terra.wiwi.uni-frankfurt.de by ifi.uio.no with SMTP (8.6.7/ifi2.4) id for ; Fri, 1 Apr 1994 19:16:53 +0200 Received: by terra.wiwi.uni-frankfurt.de (Linux Smail3.1.28.1 #2) id m0pmmtK-0003GsC; Fri, 1 Apr 94 19:20 MET DST Sender: aherbst@terra.wiwi.uni-frankfurt.de (Andreas Herbst) Date: Fri, 1 Apr 1994 19:20:11 +0200 (MET DST) From: Andreas Herbst Sender: Andreas Herbst Reply-To: Andreas Herbst Subject: Re: new stat spell system To: crossfire@ifi.uio.no In-Reply-To: <199403282319.PAA13506@soda.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On Mon, 28 Mar 1994, Peter Mardahl wrote: > > I tested trying to get my charisma from 21 to 30. > It took 500sp nder the current system I've installed. > Non-hacked characters aside, 500 spellpoints are very difficult > to come by. Mhh, the situation is a litte bit more complicated. If you have high charisma, the spell gives you only little more. If you start with 21 Charisma, you may need a loot of Spellpoints to get to 30 Charisma ( I never tested that), but if you start with say 13 Charisma, you can get 30 Charisma with about 60 spellpoints. That doesn't seem to be fair to characters with high natural charisma. :-( There is probably a bug, so that your real stat is used to compute the new value and not the actual one. cu, Andreas From crossfire-request Fri Apr 1 15:07:09 1994 Return-Path: Received: from cc.lut.fi by ifi.uio.no with ESMTP (8.6.7/ifi2.4) id for ; Fri, 1 Apr 1994 15:07:08 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id QAA03279; Fri, 1 Apr 1994 16:07:07 +0300 Date: Fri, 1 Apr 1994 16:07:07 +0300 (EETDST) From: Petri Heinil{ Subject: Re: Getting Xpm to work on a NeXT To: crossfire@ifi.uio.no In-Reply-To: <199403312309.AA28310@bolero.rahul.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 31 Mar 1994, Mark Wedel wrote: > I've noticed that on some systems, it seems that duuring compile, > it is using -DXpm_pix instead of -DXpm_Pix The later is what must > be used. I don't know why in some cases the first one is being > used. Here raises the question of naming conventions in my mind. Frank used the convention function_to_object, and macros in BIG and I used the style in crossedit ObjectFunction, macros in same way and there now seems to exists Function_Object or Object_Function, macros in same way I do not say whict way is best, but I say it would be good for development ahead, that there are common logical way to name objects and functions. -- The Page -- From crossfire-request Fri Apr 1 14:55:15 1994 Return-Path: Received: from cc.lut.fi by ifi.uio.no with ESMTP (8.6.7/ifi2.4) id for ; Fri, 1 Apr 1994 14:55:15 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id PAA03143; Fri, 1 Apr 1994 15:55:13 +0300 Date: Fri, 1 Apr 1994 15:55:12 +0300 (EETDST) From: Petri Heinil{ Subject: Re: Getting Xpm to work on a NeXT To: crossfire@ifi.uio.no In-Reply-To: <9403312201.AA09621@axys69.nwest.mccaw.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 31 Mar 1994, Jason Fosback wrote: > If you can tell me where the sources to XPM are, I'll try to get Crossfire > to work with it. ftp://ftp.x.org/contrib/ is the source of the X software. -- The Page -- From crossfire-request Fri Apr 1 10:24:12 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.7/ifi2.4) id for ; Fri, 1 Apr 1994 10:24:08 +0200 Received: by bolero.rahul.net id AA29281 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Fri, 1 Apr 1994 00:24:03 -0800 Date: Fri, 1 Apr 1994 00:24:03 -0800 From: Mark Wedel Message-Id: <199404010824.AA29281@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: developer list. 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 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 Frank Tore Johansen - misc. "Eric A. Anderson" - general bug fixing In the next version, this file will be part of the distribution. --Mark From crossfire-request Fri Apr 1 10:22:31 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.7/ifi2.4) id for ; Fri, 1 Apr 1994 10:22:26 +0200 Received: by bolero.rahul.net id AA29234 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Fri, 1 Apr 1994 00:22:18 -0800 Date: Fri, 1 Apr 1994 00:22:18 -0800 From: Mark Wedel Message-Id: <199404010822.AA29234@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: FTP update. Status: RO The messages of the preferred site seems to have trickled to a halt, and the results were that the ftp.world.net site is preferred by more people than the ifi site in Norway. As such, the ftp.world.net site will become the primary site for crossfire source. IT seems that almost no one actually uses the incoming directory, and for sake of simplicity on the mirror sites, I see no reason why the world.net site should not be the primary area for the entire directory tree. After worl.net is set up properly for me to use, I will then inform the mirror sites. The Australian site administrator said there would be no problem making the change. I would guess that the same would be true of the new UK site. Please do not send mail stating that with those results, you now vote for the ifi site. Because then in ifi site comes out in the majority, you can bet that in the next round, all the people preferring the US site would send me mail, and this would go on for ever. --Mark From crossfire-request Sun May 1 05:28: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 ; Sun, 1 May 1994 05:28:30 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.9/PHILMAIL-1.10) id UAA20804 for crossfire@ifi.uio.no; Sat, 30 Apr 1994 20:28:26 -0700 Date: Sat, 30 Apr 1994 20:28:26 -0700 From: Peter Mardahl Message-Id: <199405010328.UAA20804@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: buttons/altars question Status: RO What exactly is a trigger_altar SUPPOSED to do? I see no difference in its behavior from a regular altar. What I'd LIKE a trigger altar to do is toggle state (and the states of all the things it's connected to) whenever someone dumps the requisite garbage on it. that isn't the current behavior..... Anyone object if I make this happen? Will it break any maps? I'd really love it if someone would fix this for me. The button code is currently very nasty. regards, PeterM From crossfire-request Sat Apr 30 23:26:12 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 ; Sat, 30 Apr 1994 23:26:10 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.9/PHILMAIL-1.10) id OAA19385 for crossfire@ifi.uio.no; Sat, 30 Apr 1994 14:26:05 -0700 Date: Sat, 30 Apr 1994 14:26:05 -0700 From: Peter Mardahl Message-Id: <199404302126.OAA19385@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: yet another mailing list? Status: RO How about a crossfire-projects mailing list? Idea is, people who are working on stuff could mail to crossfire-projects, saying "i am working on this" it might eliminate duplication of effort for some things. regards peterm From crossfire-request Sat Apr 30 09:36:59 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sat, 30 Apr 1994 09:36:59 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Sat, 30 Apr 1994 09:36:58 +0200 Date: Sat, 30 Apr 1994 09:36:58 +0200 Message-Id: <199404300736.4683.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no Subject: New mailing list - crossfire-bugs Status: RO There's a new mailing list for reporting bugs, crossfire-bugs@ifi.uio.no For the time being, there's only Mark, Frank and myself on the list. If you have an interest in getting to hear about and fixing bugs, send mail to crossfire-bugs-request@ifi.uio.no (that's me). You don't need to be on the list to send a bug report there, of course. Kjetil T. From crossfire-request Fri Apr 29 08:54:21 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, 29 Apr 1994 08:54:19 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA18178 (5.67a8/IDA-1.5); Thu, 28 Apr 1994 23:43:08 -0700 Received: by bolero.rahul.net id AA14952 (5.67a8/IDA-1.5); Thu, 28 Apr 1994 23:43:06 -0700 Date: Thu, 28 Apr 1994 23:43:06 -0700 From: Mark Wedel Message-Id: <199404290643.AA14952@bolero.rahul.net> To: Petri.Heinila@lut.fi, jason.fosback@mccaw.com Subject: Re: A few thoughts on client/server Cc: crossfire@ifi.uio.no Status: RO The way I see the editor is this: If a person wants to create maps, they can just get the crossedit program for their local machine - after all, crossedit really does need to know full detail about all the objects - it certainly needs to know more about the objects than the client program would. The player can then submit these maps to whatever servers (or the standard distribution) that he wants to. If I was running a server, I certainly wouldn't want anyone to be able to create new maps or change existing maps, and in fact, I would want to know about most any change made. And if the maps have to be submitted anyways, why jsut use the crossclient program locally - it is sure to be a lot faster. From crossfire-request Wed Apr 27 02:34:42 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, 27 Apr 1994 02:34:41 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.9/PHILMAIL-1.10) id RAA09800 for crossfire@ifi.uio.no; Tue, 26 Apr 1994 17:33:49 -0700 Date: Tue, 26 Apr 1994 17:33:49 -0700 From: Peter Mardahl Message-Id: <199404270033.RAA09800@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: word-activated teleporters Status: RO Are done. I'll send patches in to mark for them in a few days, along with archetypes and pixmaps. This is the documentation for them: To use a word activated teleporter: start with any teleporter archetype (type 41 in the archetypes file) using the map editor, set its speed to 0 (otherwise it will teleport people who step on it whether it's activated or not) Also using the map editor, set the connected value to something (this means you can trigger the teleporter with anything that will use connected--altar, button, magic ear, whatever) Put a magic ear in the center of the teleporter. When the keyword is spoken, Bang, you're teleported. This has *lots* of cool map applications. For example, summoning demons (the magic ear is far from the teleporter), gateways, etc. I've drawn a pentagram which is such a teleporter: the default speed is zero. So start thinking of some cool map ideas! Now a question: 1) Is there any way to create a square that no monster will step on, but which players can move on freely? Pentagrams would be much cooler if i could make them trap demons. In the future, I'm going to make word-activated creators of items. You say something, and it turns into other_arch. Actually, I'll use the "connected" variable for this as well (you pull a lever and it creates food, or whatever.) Regards, PeterM From crossfire-request Tue Apr 26 18:04:25 1994 Return-Path: Received: from barney.cs.city.ac.uk (root@barney.cs.city.ac.uk [138.40.91.8]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 26 Apr 1994 18:04:24 +0200 Received: from wilma.cs.city.ac.uk by barney.cs.city.ac.uk; Tue, 26 Apr 1994 17:08:47 +0100 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; Tue, 26 Apr 1994 17:01:35 +0100 (BST) Message-Id: <4hjHfTq__5g9NR3kN3@cs.city.ac.uk> Date: Tue, 26 Apr 1994 17:01:35 +0100 (BST) From: Nick Williams To: crossfire@ifi.uio.no Subject: Some comments about the game in general Status: RO Using the user feedback facility of our WorldWideWeb pages, I recently received the following message based on our pages about Crossfire.... >klemmt@informatik.uni-frankfurt.de sent the following comments about "CrossFire": > >Hi and many thanxs for this great game :-). The only >two wishes I have are: 1. more spells > 2. and more quests >and for the gameplay: >it's just nice to wear a shield, a weapon and bow at the >same time, but this is normaly impossible. Please add >two handed weapons and perhaps a character screen to >outfit this one. Nick Williams, Systems Architecture Research Centre, City University, London, EC1V 0HB. UK. Web: http://web.cs.city.ac.uk/finger?njw E-mail: njw@cs.city.ac.uk (MIME and ATK) Work Telephone: +44 71 477 8551 Work Fax: +44 71 477 8587 From crossfire-request Tue Apr 26 01:04:42 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, 26 Apr 1994 01:04:39 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id QAA07124 for crossfire@ifi.uio.no; Mon, 25 Apr 1994 16:04:23 -0700 Date: Mon, 25 Apr 1994 16:04:23 -0700 From: Peter Mardahl Message-Id: <199404252304.QAA07124@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: pixmap coloring Status: RO If they're not already colored, I'm going to color the rune pixmaps regards, peterM From crossfire-request Mon Apr 25 08:24:38 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 ; Mon, 25 Apr 1994 08:24:35 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA16531 (5.67a8/IDA-1.5 for ); Sun, 24 Apr 1994 23:24:15 -0700 Received: by bolero.rahul.net id AA02832 (5.67a8/IDA-1.5); Sun, 24 Apr 1994 23:24:15 -0700 Date: Sun, 24 Apr 1994 23:24:15 -0700 From: Mark Wedel Message-Id: <199404250624.AA02832@bolero.rahul.net> To: crossfire@ifi.uio.no, martin@cse.unsw.edu.au Subject: Re: How do you sell stuffs in version 0.90.5? Status: RO there is a bug in input.c, such that if SAVE_INTERVAL was not defined, items would not always be sold properly. Here is a patch: *************** *** 277,287 **** insert_ob_in_ob(tmp,op->container); draw_info(op,buf); } else { ! if(!QUERY_FLAG(tmp, FLAG_UNPAID)&&tmp->nrof?tmp->value*tmp->nrof:tmp->value>2000) /* If SAVE_INTERVAL is commented out, we never want to save the * player here. */ #ifdef SAVE_INTERVAL #if SAVE_INTERVAL if((op->contr->last_save_time+SAVE_INTERVAL)<=time(NULL)) { --- 279,290 ---- insert_ob_in_ob(tmp,op->container); draw_info(op,buf); } else { ! /* If SAVE_INTERVAL is commented out, we never want to save the * player here. */ #ifdef SAVE_INTERVAL + if(!QUERY_FLAG(tmp, FLAG_UNPAID)&&(tmp->nrof?tmp->value*tmp->nrof:tmp->value>2000)) #if SAVE_INTERVAL if((op->contr->last_save_time+SAVE_INTERVAL)<=time(NULL)) { --Mark From crossfire-request Mon Apr 25 07:09:14 1994 Return-Path: Received: from jarrah.cse.unsw.EDU.AU (jarrah.cse.unsw.EDU.AU [129.94.238.20]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 25 Apr 1994 07:09:11 +0200 Received: From tuba20 With LocalMail ; Mon, 25 Apr 94 15:08:51 +1000 From: martin@cse.unsw.edu.au (Shun-Wu Li) To: crossfire@ifi.uio.no Date: Mon, 25 Apr 94 15:08:48 +1000 Message-Id: <940425050848.6290@cse.unsw.edu.au> Subject: How do you sell stuffs in version 0.90.5? Status: RO I played in verison v0.90.4, sell things back to the shops were easy, but how do you sell things in the latest version. cheers martin@cse.unsw.edu.au From crossfire-request Mon Apr 25 06:06: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 ; Mon, 25 Apr 1994 06:06:21 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id VAA15611 for crossfire@ifi.uio.no; Sun, 24 Apr 1994 21:06:16 -0700 Date: Sun, 24 Apr 1994 21:06:16 -0700 From: Peter Mardahl Message-Id: <199404250406.VAA15611@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: bug again Status: RO value definitely has something to do with it, but it isn't as simple as I thought with 1/value needing to sum to less than 1 From crossfire-request Mon Apr 25 06:03:52 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 ; Mon, 25 Apr 1994 06:03:51 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id VAA15402 for crossfire@ifi.uio.no; Sun, 24 Apr 1994 21:03:46 -0700 Date: Sun, 24 Apr 1994 21:03:46 -0700 From: Peter Mardahl Message-Id: <199404250403.VAA15402@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: Bug report: problems with the artifacts code Status: RO A very strange thing is happening with the artifacts code. I can change one number in the lib/artifacts file, and the difference in server behavior is dramatic. Basically what happens is this: one number change in lib/artifacts causes crossfire's memory to become corrupted. What happened is that the LibDir variable got overwritten causing crossfire's load to fail. The number is from a 4 to a 3 of the 'value' field in the artifacts field value 4 runs, value 3 causes the memory to get corrupted. My suspicion is that this is due to an undocumented constraint that the sum over all members in a type of (1/value) has to be less than 1. I'm not sure of this, however. Could some of you guys with better debugging tools than me check this out? Try changing value fields in artifacts to lower than they are. Regards, PeterM From crossfire-request Sun Apr 24 21:36:41 1994 Return-Path: Received: from corpse.ecst.csuchico.edu (corpse.ecst.csuchico.edu [132.241.5.10]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sun, 24 Apr 1994 21:36:39 +0200 Received: (from tvangod@localhost) by corpse.ecst.csuchico.edu (8.6.8/8.6.6) id MAA03683; Sun, 24 Apr 1994 12:36:32 -0700 From: Tyler Van Gorder Message-Id: <199404241936.MAA03683@corpse.ecst.csuchico.edu> Subject: Re: A few thoughts on client/server To: master@rahul.net (Mark Wedel) Date: Sun, 24 Apr 1994 12:36:31 -0700 (PDT) Cc: crossfire@ifi.uio.no, philb@soda.berkeley.edu In-Reply-To: <199404240820.AA05728@bolero.rahul.net> from "Mark Wedel" at Apr 24, 94 01:20:04 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1367 Status: RO > Mark wrote: > Light: As I said, it really should be done on the client side. This > offloads a little cpu time from the server, but more important, if light > information is transmitted with image data, then a lot of information would > be sent each time as light information changes. > > Light should not be too hard to do. However, a lot of clients may not > do anything with it (for XPM images, (or in fact, any image type on > X systems), it would not be easy (quick) to do it on the fly - that is to > say to create a new pixmap with the shading lightened/darkened because of > the light. And creating alternate pixmaps for every lighitng situtation > at start up would chew up huge amounts of memory.) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ a suggestion on this.....how about having about 5 or six pixmaps with increasing amounts of their pixels shaded to black...the rest to transparent? then you can overlay these pixmaps..depending on how far from the light source over the other xpms..... Doesn't even necessaryly have to be black...could be grey...... We have done some coloring here to make things like ghosts...spheres...look somewhat transparent..by mixing transparent throughtout the body of the object It seems to give a dimming effect to the pixmap underneath....might be something to try. Tyler. From crossfire-request Sun Apr 24 11:49:13 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, 24 Apr 1994 11:49:09 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA25837 (5.67a8/IDA-1.5 for ); Sun, 24 Apr 1994 02:49:01 -0700 Received: by bolero.rahul.net id AA08398 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Sun, 24 Apr 1994 02:48:59 -0700 Date: Sun, 24 Apr 1994 02:48:59 -0700 From: Mark Wedel Message-Id: <199404240948.AA08398@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Subject: Speeding up the server Status: RO I've already implemented a new list that keeps track of active (ie, speed is nonzero) objects, so process_objects goes through a much smaller list for each tick (in most cases, with only me playing on the server, the number of objects on the active list is less than 100). This seems to make things snappier, but it is hard to really, because I run in XPM mode, and the number of images that need to be drawn can really start to bog down the server. The next step for speeding things up is to get rid of the floats, or at least make it so that they do not have to be adjusted every tick. My thought is this: Have an element in structure that determines what tick the item gets to go (on_tick). Thus, it might be tick 500 right now, but on_tick is 510. The loop has some check like 'if (pticks < ob->on_tick) continue;' This saves adding a float to float every tick for active objects, and instead is just a simple integer comparison, which should be fairly quick. The speed variable would remain a float. This saves A LOT of conversion work throughout the problem, and if speed was changed to a int, it would still be synthesized as a float (ie, instead of speed 0.5, it might be speed 500 (ie, just multiply it by 1000)). When on object actually moves, the next tick it goes on would be pticks + (speed_remainder + 1/speed) Where speed_remainder = 1/speed - (int) (1/speed) (there might be a function to do that instead). Thus, something with a speed of 0.5 would go every 2 ticks, where as something with speed 0.03 would go every 33 ticks, with speed_remainder = 0.333. The advantage with this method is that that only area of code that would really change is in process_events. The disadvantage is that objects that have a high speed would need that updating very often, and thus may not be any faster (could, in fact, be slower, because those divisions are probably slower than float additions - however, that division oculd be stored in a tmp value to make sure it is only calculated once per updated object..) The other difficulty is when the speed of an object changes from a nonzero value to another nonzero value (if it changes to or from zero, then taht is a simple case). The nonzero -> nonzero becomes more difficult. This is because right now, if an object has speed 0.1, that value is added each time, and when speed left is above 1, the object goes. Thus, if the speed changes to 0.5, things still work out nicely. However, in the new method, if the speed changes, then the next time that object goes (on_tick) would need to be re-calculated, the result being based on the old speed, how close it was to getting its turn, and the new speed). For example, if an object has speed .1, it means every 10 ticks, the object goes. IF it changes to speed .2, it means that every 5 ticks, it moves. If on tick 1, the speed changes, then around tick 5 or 6, the object should now move. If on tick 5 the speed changes, it means that on tick 7 (with 5 remainder), the object should move. The code is not that complicated, however, the calculation would probably require a fair amount of floating point time (which is what we want to avoid.) The simple solution could be that when the speed changes, if the the next time the object moves in MIN(present move calculation, new one based on present speed). Thus, if in the .1 ->.2 case, the object would move on 10, and when the speed changes to .2, it would move anywhere from tick 6 to 10, depending on what tick the speed changed on (if it changed on 9, the new time would be 14, but 10 is less). OR an average of the two could be used. If speed changed on tick 1, then the average of the old and new (10 and 6) would be used, so it would mve on tick 8. Actually, this is probably a bad idea, as if somethings speed changes from very slow (.05) to fairly fast (1.0), it would still be up to 10 ticks before it moves. Anyways, just putting this out for various thoughts and suggestions. --Mark From crossfire-request Sun Apr 24 10:20:15 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, 24 Apr 1994 10:20:12 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA21257 (5.67a8/IDA-1.5 for ); Sun, 24 Apr 1994 01:20:05 -0700 Received: by bolero.rahul.net id AA05728 (5.67a8/IDA-1.5); Sun, 24 Apr 1994 01:20:04 -0700 Date: Sun, 24 Apr 1994 01:20:04 -0700 From: Mark Wedel Message-Id: <199404240820.AA05728@bolero.rahul.net> To: crossfire@ifi.uio.no, philb@soda.berkeley.edu Subject: Re: A few thoughts on client/server Status: RO A few notes: The server will be sending the pixmap ID/name to the client, and not what the object necessarily is (thus, an earthwall and stone block would both have the name name/ID until one is damaged.) A few of the wall categories at least of XPM files with very minor differences for the weak walls. (ie, extra pixel added in), so if you look closely, you can notice that a weak wall exists. A client could obviously make its version of hte pixmap much more obvious - the only solution is really to make sure that all weak walls appear the same as normal walls until damaged (perhaps a detect weak wall spell could be added to make finding them easier, if it is a problem). Light: As I said, it really should be done on the client side. This offloads a little cpu time from the server, but more important, if light information is transmitted with image data, then a lot of information would be sent each time as light information changes. Light should not be too hard to do. However, a lot of clients may not do anything with it (for XPM images, (or in fact, any image type on X systems), it would not be easy (quick) to do it on the fly - that is to say to create a new pixmap with the shading lightened/darkened because of the light. And creating alternate pixmaps for every lighitng situtation at start up would chew up huge amounts of memory.) I suppose a smart caching system could be used (keep a couple hundred pixmaps around, and knew their lighting value). But also, on 8 bit display systems, depending on the number of lighting types, a lot of colors could also be used up (about 30 colors are used right now for all the XPM images. If you assume that dimming them due to light very rarely matches up with an already used color, then depending on the number of dimming categories, you could easily have more than 256 colors needed.) I suppose dynamic updating of the color map as required could be done. I guess, in quick summary, the client on X systems could handle light changes, but it would be fairly complicted to do (display light changes, that is) Thus, it makes even more sense to handle light on the client side - if client is not using light for display, it can just choose not to even figure out intensity on any of the squares. And the server doesn't waste time workign on information that is not needed. --Mark From crossfire-request Sun Apr 24 03:57:45 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, 24 Apr 1994 03:57:43 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id SAA21401 for crossfire@ifi.uio.no; Sat, 23 Apr 1994 18:57:39 -0700 Date: Sat, 23 Apr 1994 18:57:39 -0700 From: Peter Mardahl Message-Id: <199404240157.SAA21401@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: documentation for artifacts list Status: RO Could whomever wrote the artifacts code please document it? Hacking the artifacts file doesn't answer all the questions, and I don't particularly want to hack the artifacts generation code to figure out how to make random artifacts. Regards, PeterM (questions: I added a cloak to the game. I wanted to make things like 'cloak of protection' or 'cloak of warmpth' or 'cloak of displacement'...... What does the value field do? Is it kosher to have two things with the same object name? Like this: Allowed all Object Protection type 87 value 4 ac 2 end # Allowed all Object Protection type 87 value 8 ac 3 end # From crossfire-request Sat Apr 23 20:13: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 ; Sat, 23 Apr 1994 20:13:54 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id LAA08793 for crossfire@ifi.uio.no; Sat, 23 Apr 1994 11:13:48 -0700 From: Philip Brown Message-Id: <199404231813.LAA08793@soda.berkeley.edu> Subject: Re: A few thoughts on client/server To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Sat, 23 Apr 1994 11:13:47 -0700 (PDT) In-Reply-To: <199404230856.AA08465@cardhu.cs.hut.fi> from "Tero Kivinen" at Apr 23, 94 11:56:07 am X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 637 Status: RO >>>>[From Tero Kivinen] [...] I would say that they should be reliable too. I hate in xpilot that usually when you enter to battle when there are few ships the next thing you see is you flying back to base after crash. In xpilot that isn't so bad because you are dying all the time, but in crossfire one death of that kind would be one too much. [...] Exactly. That situation is fairly common in xtrek. It has nothing to do with UDP failure. In fact, UDP makes it less common. The reason it happens is because of too many events being generated in that situation, and there's a bottleneck somewheres. From crossfire-request Sat Apr 23 14:57:13 1994 Return-Path: Received: from bera.ifi.uio.no (2037@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sat, 23 Apr 1994 14:57:12 +0200 From: Frank Tore Johansen Received: (from frankj@localhost) by bera.ifi.uio.no ; Sat, 23 Apr 1994 14:57:11 +0200 Message-Id: <199404231257.23074.bera.ifi.uio.no@ifi.uio.no> Subject: Re: bracing To: crossfire@ifi.uio.no Date: Sat, 23 Apr 1994 14:57:10 +0200 (MET DST) In-Reply-To: <199404230857.BAA12872@soda.berkeley.edu> from "Peter Mardahl" at Apr 23, 94 01:57:59 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 866 Status: RO > The only advantage i ever observed to bracing oneself > was simply that you didn't need to move into a square > to hit something. > > Is that what the creator of 'bracing' had in mind? No, I added those disadvantages after receiving the patch. In the early days of bracing, monsters (most) had no range attacks (no bows, could not use wands, etc), thus you could just find a room with lots of generators and a 1-square wide door, stack up with lots of food, then brace yourself outside the opening and leave crossfire iconified overnight. (If you move the mouse out of the window before you release the move-button, the key-release event is never received, and you continue to hack your way...) I wanted to make this less easy. Now this is more risky though, if the monsters suddenly decide to nail you with arrows or wands...things are more random. -Frank. From crossfire-request Sat Apr 23 10:58:05 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 ; Sat, 23 Apr 1994 10:58:04 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id BAA12872 for crossfire@ifi.uio.no; Sat, 23 Apr 1994 01:57:59 -0700 Date: Sat, 23 Apr 1994 01:57:59 -0700 From: Peter Mardahl Message-Id: <199404230857.BAA12872@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: bracing Status: RO Do people remember how one could 'brace' oneself? All I could tell about it was that it: removed any dexterity bonus to your armour class worsened your armour class by 2 more worsened your weapon class The only advantage i ever observed to bracing oneself was simply that you didn't need to move into a square to hit something. Is that what the creator of 'bracing' had in mind? regards, peterM From crossfire-request Sat Apr 23 11:01:14 1994 Return-Path: Received: from cardhu.cs.hut.fi (cardhu.cs.hut.fi [130.233.192.95]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 23 Apr 1994 11:01:14 +0200 Received: by cardhu.cs.hut.fi id AA08465 (5.65c8/HUTCS-C 1.3 for ); Sat, 23 Apr 1994 11:56:07 +0300 Date: Sat, 23 Apr 1994 11:56:07 +0300 Message-Id: <199404230856.AA08465@cardhu.cs.hut.fi> From: Tero Kivinen To: Tero Haatanen Cc: Subject: Re: A few thoughts on client/server In-Reply-To: <199404221116.OAA10415@kaisa.it.lut.fi> References: <199404220242.13021.bera.ifi.uio.no@ifi.uio.no> <199404221116.OAA10415@kaisa.it.lut.fi> Organization: Helsinki University of Technology/Lifelong Learning Institute Dipoli Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Status: RO Tero Haatanen writes: > If client writer makes his 'own superior sets of images' then server > admins take these anyway and use these as server images also. :) And > client maker forgets convert anyway some part of wall (which can be > added to server later) and give out all secret doors. Server will of course send same image for wall and secret doors until the player finds the secret door. There is no way the client can make 'own superior sets of images' except that they can look better or be faster for players display. Player cannot get any more information about anything with them. > Clients should be easy to make and expand, but they should show the world > that server gives them, not make their own, IMHO. This includes maps, > images, sounds, LOS and probably much more. Cheat clients use every way > thay can, but 'normal' clients shouldn't use any these features. And > 3D clients aren't really useful to crossfire, someone probably hacks > server to support for them and then makes client which use 3D features. If someone is using some SGI workstation to play and he wants to use gl-graphics and show the 3d view of world too, there should not be anything in protocol that requires any changes in the server. The client only shows some 3d objects in 3d graphics world for every image. So if server sends info saying here is wall the SGI client will draw 3d box in the players view. There should be no modification for server to do this. Of course if the server uses some images (say new table) that SGI client doesn't know how to draw in 3d the client can fetch the pixmap of image and try to do some cleaver with it (like drawing a 3d box which have that image in all the sides, or if player have already walked through it (or there is some other items in the same place) it can draw it as floor with pixmap acting as texture). Then when new client will come out it will add new code to display this table as real 3d object. Why should the server be prepared to send data in all possible formats in which the client may want it. I think the server should send something very simple and all the converting etc is left to client. It should be enough the server to support pixmaps, and perhaps the 1-bit bitmaps too (if client is say 2-bit display, it may use either one of those as selected by player). > > Onto ASCII->binary->UDP: The way I see it, that's the route we should > > take. > And leave that ASCII step away :). I agree that first version is probably > better be TCP, so that something gets done. I would leave the binary part away, and not even thinking to going UDP. Crossfire WILL need reliable data transfer protocol anyway, so if we are using UDP we have to create such over UDP thus recreating TCP. The TCP is very clever for doing all kinds of optimizations for slow or long turnaround links. If we are trying to do better than that we have quite a lot to do... > I totally agree, here. And this is why I don't like Carl's original > protocol since it requires reliable comminication channel. As a said in previous paragraph we WILL niid reliable communication channel anyway. At least for some data, so why not use it for all data. > > A protocol which doesn't care about lost packets would have to be > > _very_ graphical in nature. > > Not _very_, if we divide protocol to two parts. The first is on which If the protocol have any graphical nature I think it is bad. It should be in much higher level than that. The client will usually already have one graphical protocol talking to display, why should we add another? > offers reliable transfer. All player commands, and some server > commands (like pickup) use this. This is only small part of traffic. > The biggest part of traffic is map updates and these don't need > be reliable (in strict sense). And these go old very fast, means if > you get view which was true the second ago, you can be in trouble. I would say that they should be reliable too. I hate in xpilot that usually when you enter to battle when there are few ships the next thing you see is you flying back to base after crash. In xpilot that isn't so bad because you are dying all the time, but in crossfire one death of that kind would be one too much. The only thing in Carl's proposal that bothers me is that this can happen in that too, but there can only be some time difference between the action and the time it is seen in display. In UDP those time differences happen much more often... Another thing with UDP is that we have to be sending the images all the time (if we are not doing that then we will need reliable channel), thus even if I don't do anything in crossfire there will be constant flow of UDP-packets flowing from server to my client. As network adminstrator I think that IS VERY BAD. Currently the xpilot has caused several problems with network load and it have even caused our main nameserver to crash several times (ok, there was bug in xpilot then, but if any of such thing is repeated with any other game here it may cause that all games will be forbidden again). It is very easy to fill in the network with junk just be sending the same data again and again. TCP headers are small compared to sending all the user visible data every time (tcp headers (20 bytes) - udp headers (8 bytes) = 12 bytes, full image 11 * 11 = 121 images). TCP will also send ACKs etc together with data so if we have some data going another way too the ACK will take no extra bytes. > I prefer simple graphical client, but this is partly only playing > with words. If we think Carl's protocol and don't require the whole > map caching, it's graphical protocol since it tells client what > player see, nothing more or less. Some object names are send, others I would say it is world mapping telling the information player can see from the world. It isn't graphical because it doesn't say draw that image to there, but it tells that you see that item there. If client wants to know how to draw that item it can requests some simple image of item, but that isn't mandatory. > not. Of course client can show items which it 'remembers', but > it has not knoledge if they are still there. The protocol gives > coordinates, but these aren't useful for player since they don't > identify players location in world, only in one map. If server > send updates 11x11 area then the protocol is graphical in nature, > it doesn't make differentce if origo is upper left corner of map > or upper left corner of players view. I don't see how that the server only sends stuff that player can have information about makes the protocol graphical? > I have to admit how Carl wants to keep his original protocol, if some > feature requires more bandwidth then better drop feature and not > find better protocol :) :). Or add it as an extension that can be disabled if you don't have enough bandwidth. > If shading is implemented and protocol use only graphical updates and > not item updates, then this would add almost no overhead. Since server > has to calculate this anyway why bother client with it, just give > nice looking view. The server could also send only the static shading information and the client can add the light that items are emitting (add one more information to item telling how much it will emit light). Because all the shading is only to make display nicer (it may not have any effect to play, because the information about items is send to clients anyway even if they are mostly in shadows) there is no need it to be server matter. Of course server can calculate the area seen by player using lights but then it wont have anything to do with client, because server is only sending information from player visible area. > but object face could be changed so that one face can be more than > one image (face image1,image2,image3). This is quite easy implement This sounds good, perhaps we should add flips and rotations there too, so the image can be (face (grass), (table, 45)) table rotated 45 degrees on a grass or (face (grass), (table,,h)) table flipped horizontically on a grass. All this image manipulation can be done quite fast when the image is first time needed, and after that it can be cached. Of course you cannot rotate wall 45 degrees and assume it will make join perfectly to other walls, but at least you can make some more varations for items etc. > One more useful feature would be have different looking floors > below walls (face woodfloor_left,grass_right,wall). Cool... > Any comments? Any one want to make code? I hope I would have more that 24 hours time in a day so I would have some time to hack on crossfire, but perhaps I will have more time in the summer (I have said so every year :-) -- 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 Apr 22 19:31:56 1994 Return-Path: Received: from mccaw.com (wombat.mccaw.com [192.135.191.118]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 22 Apr 1994 19:31:38 +0200 Received: from nwestmail.entp.mccaw.com ([155.176.15.34]) by mccaw.com (4.1/SMI-4.1) id AA16807; Fri, 22 Apr 94 10:31:11 PDT Received: from axys69.nwest.mccaw.com by nwestmail.entp.mccaw.com (4.1/McCaw SUN-RMR Mailer, SMI-4.1) id AA05429; Fri, 22 Apr 94 10:31:05 PDT Received: from divac by axys69.nwest.mccaw.com (NX5.67d/NX3.0M, dpg hack 15oct93) id AA24556; Fri, 22 Apr 94 10:30:34 -0700 From: Jason Fosback Message-Id: <9404221730.AA24556@axys69.nwest.mccaw.com> Received: by divac.nwest.mccaw.com (NX5.67d/NX3.0X, dpg hack 20mar93) id AA17424; Fri, 22 Apr 94 10:30:37 -0700 Date: Fri, 22 Apr 94 10:30:37 -0700 Received: by NeXT.Mailer (1.100.RR) Received: by NeXT Mailer (1.100.RR) To: crossfire@ifi.uio.no Subject: Re: A few thoughts on client/server Status: RO Hey, I just thought of something: it would be nice to extend our protocol to allow us to create a client-side map editor. If we could come up with some extensions to return pixmaps and archtypes (and whatever else we need), we could create client-side map editors. If we could move some of the changes we make into a protocol, we could attempt to create a generic map editor that could be extended just like our simple clients. Think of the tons of maps we'd have if everyone could create them! Just look at all of those Doom wads, for example... -jason ____________________________________________________________ Jason Fosback, Systems Engineer | No sir, I didn't like it --- Paradigm Systems Corp --- | -R&S Internet: jason_fosback@psca.com | Star Trek: NeXT mail: jason_fosback@psca.com | The NeXT Generation... From crossfire-request Fri Apr 22 15:06:45 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 22 Apr 1994 15:06:42 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA22064; Fri, 22 Apr 94 09:06:30 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA01711; Fri, 22 Apr 94 09:06:22 -0400 Date: Fri, 22 Apr 94 09:06:22 -0400 From: "Carl Edman" Message-Id: <9404221306.AA01711@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: MAP, UNMAP and ITEM Reply-To: cedman@Princeton.EDU Status: RO Mark Wedel writes: > But with crossedit, specific variables can be changed, so two > distinct archetyps would not necessarily be needed. IT just requires > setting the invisible variable for the objects below floors you don't > want people to see. > > As I said, the code right now is in place to handle that. However, > it does mean that a lot of maps would likely need to be changed. Yes, but would it be hard to write a script which automatically makes all items below floors invisible ? In my opinion that would be the ideal solution. Putting things 'below' floors to make them invisible seems such a hack. As for visibility of items to the client, my opinion when writing the protocol was that exactly those items which today you could get listed by clicking on a square would have ITEM commands generated for them. (Can you see items in open containers today that way ? Have to check, but ITEM commands for them should be sent as well). Carl Edman From crossfire-request Fri Apr 22 14:18:00 1994 Return-Path: Received: from thrall.cm.cf.ac.uk (thrall.cm.cf.ac.uk [131.251.42.22]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 22 Apr 1994 14:17:58 +0200 Received: from cm.cf.ac.uk by thrall.cm.cf.ac.uk with SMTP (PP) id <00153-0@thrall.cm.cf.ac.uk>; Fri, 22 Apr 1994 13:16:01 +0100 Date: Fri, 22 Apr 94 13:15:59 BST From: Simon McIntosh-Smith Message-Id: <9404221215.AA20929@diamond.cm.cf.ac.uk> To: crossfire@ifi.uio.no Subject: active servers list Status: RO 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: ?? If you know of others please e-mail me at the address below! Sy Simon N. McIntosh-Smith, PhD candidate | Email : Simon.N.Smith@cm.cf.ac.uk Room M/1.36 Department of Computing Maths | Phone : +44 (0)222 874000 University of Wales, College of Cardiff | Fax : +44 (0)222 666182 PO Box 916, Cardiff, Wales, CF2 4YN, U.K. | Home : +44 (0)222 560522 Http : http://www.cm.cf.ac.uk:/People/Simon.Smith.html From crossfire-request Fri Apr 22 13:17:04 1994 Return-Path: Received: from kaisa.it.lut.fi (haatanen@kaisa.it.lut.fi [157.24.21.70]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 22 Apr 1994 13:17:02 +0200 Received: from localhost (haatanen@localhost) by kaisa.it.lut.fi (8.6.5/8.6.5/1.12.kim) id OAA10415; Fri, 22 Apr 1994 14:16:58 +0300 (for crossfire@ifi.uio.no) From: Tero Haatanen Message-Id: <199404221116.OAA10415@kaisa.it.lut.fi> Subject: Re: A few thoughts on client/server To: crossfire@ifi.uio.no Date: Fri, 22 Apr 94 14:16:57 EET DST In-Reply-To: <199404220242.13021.bera.ifi.uio.no@ifi.uio.no>; from "Kjetil Torgrim Homme" at Apr 22, 94 4:42 am X-Mailer: ELM [version 2.3 PL11] Status: RO From: Kjetil Torgrim Homme > One of the advantages of using symbolic names for all of the images > was that an entreprising client writer could draw his own superior > sets of images. Of course we need symbolic names if client is going to cache images, but this hopefully mean that they are mapped to numbers beginning of connection and not used all time. If client writer makes his 'own superior sets of images' then server admins take these anyway and use these as server images also. :) And client maker forgets convert anyway some part of wall (which can be added to server later) and give out all secret doors. Clients should be easy to make and expand, but they should show the world that server gives them, not make their own, IMHO. This includes maps, images, sounds, LOS and probably much more. Cheat clients use every way thay can, but 'normal' clients shouldn't use any these features. And 3D clients aren't really useful to crossfire, someone probably hacks server to support for them and then makes client which use 3D features. > 2. I think it is best that an animations replay speed can not be > changed via the protocol. Animations with same images but > different speeds should have different names. I don't think this > will be common, anyhow. Huh! The animation speed is depended to object's speed and speed changes are really common. One example which I have wanted to done long time is players animation. Is there anyone who wants to fix animate_object() so that in can handle animations in 8 directions? This could be really useful for directors, cannons, arrows, spells, players and so on. > Onto ASCII->binary->UDP: The way I see it, that's the route we should > take. And leave that ASCII step away :). I agree that first version is probably better be TCP, so that something gets done. > We should make the protocol so that making a UDP version isn't more of > a hassle than necessary. I totally agree, here. And this is why I don't like Carl's original protocol since it requires reliable comminication channel. > A protocol which doesn't care about lost packets would have to be > _very_ graphical in nature. Not _very_, if we divide protocol to two parts. The first is on which offers reliable transfer. All player commands, and some server commands (like pickup) use this. This is only small part of traffic. The biggest part of traffic is map updates and these don't need be reliable (in strict sense). And these go old very fast, means if you get view which was true the second ago, you can be in trouble. And I prefer that server sends only images, which are players view and updates for them. Makes easy and new features server and keeps client code very simple. (Of course) dump animations are done by client. This issue is very specific also how much cache client has to keep. If its only the current view. most object names is useless. But if it keeps the whole map, then these names are little more useful, but this makes clients more complicated and requires clients be aware of maps, so server can't implemented so easily the big maps (from Ultima). I prefer simple graphical client, but this is partly only playing with words. If we think Carl's protocol and don't require the whole map caching, it's graphical protocol since it tells client what player see, nothing more or less. Some object names are send, others not. Of course client can show items which it 'remembers', but it has not knoledge if they are still there. The protocol gives coordinates, but these aren't useful for player since they don't identify players location in world, only in one map. If server send updates 11x11 area then the protocol is graphical in nature, it doesn't make differentce if origo is upper left corner of map or upper left corner of players view. > It would be a win over X, for sure, but not much else. What this has to do with X? [description some variant of sliding window mechanism deleted] > (every packet has a byte-sized sequence number, which is reset eachly > tick) And this doesn't make sense. You loose everything which don't came through in one tick or did I misunderstand? And what is tick? Could you give definition of this. The smallest time unit of server, update speed (fps) or something do with player speed? About damage command: Server should give those text descriptions and hint about scale of damage. Damage values like 1 or 100 don't tell client anything without useful scale. And server admins might like implemented system where actually nimbers are not show to players. I have to admit how Carl wants to keep his original protocol, if some feature requires more bandwidth then better drop feature and not find better protocol :) :). If shading is implemented and protocol use only graphical updates and not item updates, then this would add almost no overhead. Since server has to calculate this anyway why bother client with it, just give nice looking view. And floor discussion seems that you are talking totally different thing with same name. Mark refers floors with meaning they are used currently, players can't see under them. Kjetil refers floors as meaning background (and mostly nameless ones). If you want backgrounds you have to add flag and update archetypes and not change meaning of floors. And I agree that the current floors should not be transparent, it really doesn't make sense. Now one new idea since I have disagreed in this post almost anything :). Only reason to stack backgrounds is that you get nice looking map. So there is grass below citywall, it isn't there because object grass has some meaning (wall has the meaning, of course), but because wall in grass looks better. One solution would be draw the huge number of images (all walls top of all floors). This isn't the reasonable, but object face could be changed so that one face can be more than one image (face image1,image2,image3). This is quite easy implement even currently. Add some support to crossedit make it easy to use. Achetypes could use default combinations which can be changed in editor if needed. These could be drawed only ones and added to dynamical array (same that player pixmaps use) or drawad each time (not very good). Last image could be used if only one image is drawn. Remember that one object size is little under 250 bytes, so getting rid of unneeded objects from maps is useful in this way also. Example: The first is the current way from starting map: arch cobblestones2 x 17 y 19 end arch sign name Press 'A' for Dungeon List x 17 y 19 end arch dungeon_magic x 17 y 19 end would come: arch sign name Press 'A' for Dungeon List face cobblesto1.111,sign.111 x 17 y 19 no_magic 1 end One more useful feature would be have different looking floors below walls (face woodfloor_left,grass_right,wall). Any comments? Any one want to make code? I was just going to post this when Gregor Schmid writes > The code could be changed that you still can't see anything below a FLOOR -- > except another FLOOR. Could you consider my idea? It little more work, but much more general solution. If game could even draw multiple faces same time would be good, caching and crossedit support can be added later. -Tero From crossfire-request Fri Apr 22 13:00:02 1994 Return-Path: Received: from mailgzrz.TU-Berlin.DE (mailgzrz.TU-Berlin.DE [130.149.4.10]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 22 Apr 1994 12:53:53 +0200 Received: from fb3-s7.math.TU-Berlin.DE by mailgzrz.TU-Berlin.DE (5.65c/ZRZ-MX) for id AA17009; Fri, 22 Apr 1994 12:47:44 +0200 Received: by fb3-s7.math.tu-berlin.de id AA19088 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Fri, 22 Apr 1994 12:47:40 +0200 Date: Fri, 22 Apr 1994 12:47:40 +0200 From: Gregor Schmid Message-Id: <199404221047.AA19088@fb3-s7.math.tu-berlin.de> To: crossfire@ifi.uio.no Subject: Multiple Floors Status: RO How about the following solution (hack) for multiple floors: I don't think we will need mor than 2 FLOOR objects on top of each other. More would just clutter the display. The code could be changed that you still can't see anything below a FLOOR -- except another FLOOR. In fact this is just what I have done. I'm going to send the patches to Mark, they are protected with #ifdef so he should be able to put them in the next release without causing any problems, and we can continue the discussion then. I can tell you now: It looks good and it doesn't SEEM to cause problems, neither with object visibility, nor with drawing speed. Regards, Greg From crossfire-request Fri Apr 22 11:05:31 1994 Return-Path: Received: from thrall.cm.cf.ac.uk (thrall.cm.cf.ac.uk [131.251.42.22]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 22 Apr 1994 11:05:30 +0200 Received: from cm.cf.ac.uk by thrall.cm.cf.ac.uk with SMTP (PP) id <15643-0@thrall.cm.cf.ac.uk>; Fri, 22 Apr 1994 10:05:25 +0100 Date: Fri, 22 Apr 94 10:05:23 BST From: Simon McIntosh-Smith Message-Id: <9404220905.AA29446@garnet.cm.cf.ac.uk> To: crossfire@ifi.uio.no Subject: NEW list of active servers! Status: RO Thanks to the response from all those concerned, we now have an up-to-date list of active crossfire servers. The list will be permanently kept on the WWW Crossfire pages here at Cardiff at the following URL: http://www.cm.cf.ac.uk:/Crossfire/servers.html Information on the version of the server, what time of day it's up etc can all be found there. I'll post a plain text version to this list later today. Sy Simon N. McIntosh-Smith, PhD candidate | Email : Simon.N.Smith@cm.cf.ac.uk Room M/1.36 Department of Computing Maths | Phone : +44 (0)222 874000 University of Wales, College of Cardiff | Fax : +44 (0)222 666182 PO Box 916, Cardiff, Wales, CF2 4YN, U.K. | Home : +44 (0)222 560522 Http : http://www.cm.cf.ac.uk:/People/Simon.Smith.html From crossfire-request Fri Apr 22 10:53: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 ; Fri, 22 Apr 1994 10:53:47 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA08963 (5.67a8/IDA-1.5); Fri, 22 Apr 1994 01:05:35 -0700 Received: by bolero.rahul.net id AA20748 (5.67a8/IDA-1.5); Fri, 22 Apr 1994 01:05:33 -0700 Date: Fri, 22 Apr 1994 01:05:33 -0700 From: Mark Wedel Message-Id: <199404220805.AA20748@bolero.rahul.net> To: crossfire@ifi.uio.no, peterm@soda.berkeley.edu, rgg@aaii.oz.au Subject: Re: MAP, UNMAP and ITEM Status: RO But with crossedit, specific variables can be changed, so two distinct archetyps would not necessarily be needed. IT just requires setting the invisible variable for the objects below floors you don't want people to see. As I said, the code right now is in place to handle that. However, it does mean that a lot of maps would likely need to be changed. --Mark From crossfire-request Fri Apr 22 08:45: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, 22 Apr 1994 08:45:07 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id XAA02806; Thu, 21 Apr 1994 23:44:57 -0700 Date: Thu, 21 Apr 1994 23:44:57 -0700 From: Peter Mardahl Message-Id: <199404220644.XAA02806@soda.berkeley.edu> To: crossfire@ifi.uio.no, rgg@aaii.oz.au Subject: Re: MAP, UNMAP and ITEM Status: RO invisible flag: there is one already for objects! I've used it to make spectres invisible. Completely. Also, how do you thnk i make runes invisible? I couldn't use tranparent pixmaps before xpm came out. We don't want to make two archetypes for buttons, one visible and one not, i think, when we can hide things below floors. Regards, PeterM From crossfire-request Fri Apr 22 08:26:22 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, 22 Apr 1994 08:25:48 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA15994 (5.67a8/IDA-1.5 for ); Thu, 21 Apr 1994 23:23:08 -0700 Received: by bolero.rahul.net id AA14747 (5.67a8/IDA-1.5); Thu, 21 Apr 1994 23:23:07 -0700 Date: Thu, 21 Apr 1994 23:23:07 -0700 From: Mark Wedel Message-Id: <199404220623.AA14747@bolero.rahul.net> To: crossfire@ifi.uio.no, rgg@aaii.oz.au Subject: Re: MAP, UNMAP and ITEM Status: RO Actually, all the look code will handle invisible objects just fine. Changing all such cases to invisible objects would work just fine, however, that would be a lot of maps to be updated. --Mark From crossfire-request Fri Apr 22 07:44:28 1994 Return-Path: Received: from eden-valley.aaii.oz.AU (eden-valley.aaii.oz.AU [192.35.59.254]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 22 Apr 1994 07:44:04 +0200 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA15670; Fri, 22 Apr 1994 15:43:02 +1000 Date: Fri, 22 Apr 1994 15:43:02 +1000 From: "Rupert G. Goldie" Message-Id: <199404220543.AA15670@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no Subject: Re: MAP, UNMAP and ITEM Status: RO > TO get rid of the "on top of" problem, for hidden items... isn't it about > time there was an "invisible" flag? then it wouldn't matter "under" what > you put special items. > > Good idea. There are a couple of nasty bits of code for making sure that you don't see what's under a 'floor' and that clicking on a square doesn't show you what's under the floor. Rupert From crossfire-request Fri Apr 22 07:30:55 1994 Return-Path: Received: from po2.andrew.cmu.edu (PO2.ANDREW.CMU.EDU [128.2.10.102]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 22 Apr 1994 07:30:54 +0200 Received: (from postman@localhost) by po2.andrew.cmu.edu (8.6.7/8.6.6) id BAA16243 for crossfire@ifi.uio.no; Fri, 22 Apr 1994 01:30:48 -0400 Received: via switchmail; Fri, 22 Apr 1994 01:30:47 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 22 Apr 1994 01:29:29 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 22 Apr 1994 01:29:23 -0400 (EDT) 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; Fri, 22 Apr 1994 01:29:23 -0400 (EDT) Message-ID: Date: Fri, 22 Apr 1994 01:29:23 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: lists of current active servers? In-Reply-To: <9404211247.AA29943@topaz.cm.cf.ac.uk> References: <9404211247.AA29943@topaz.cm.cf.ac.uk> Status: RO madhatter.ws.cc.cmu.edu 90.3 or 4 right now. I'm working on my thesis, so don't have a lot of time to work on crossfire, so I'm waiting for 90.6, which should be more stable than 90.5 -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 Fri Apr 22 05:47:31 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 22 Apr 1994 05:47:30 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Fri, 22 Apr 1994 05:47:29 +0200 Date: Fri, 22 Apr 1994 05:47:29 +0200 Message-Id: <199404220347.13077.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: Mark Wedel's message of Sun, 17 Apr 1994 18:05:52 -0700 <199404180105.AA20881@bolero.rahul.net> Subject: Re: MAP, UNMAP and ITEM Status: RO Rereading Mark's comments on my FLOOR proposal, I find that they were negative :-( +--- Mark Wedel: | Floors are meant to be so you can not see anything below them. This | allows designers to put a button or teleporter or whatever else | below a floor, with the player needing to figure it out. That's a server issue - just don't send ITEM commands for those hidden objects. +--- | With the fact that you are only supposed to see the top floor | object, there is no need to send more than 1 floor object for any | space. That's a tautology, and I don't agree with that "fact". +--- | If you take the example of Goth's tavern on top of grass, the grass | would be the floor, and the tavern would be a non floor object. | [...] With client/server, the client can display as many objects on | one space as it is willing to. If the client is displaying several | objects, then the problem with an object on top of tavern with a | grass floor is not a problem. Let's consider a client which has upped the number of pixmaps per square to three. The player drops a stack of objects on the entrance to the tavern. What will the client display -- a figure standing on an axe in a meadow, or a figure standing in front of a tavern? Both are equally reasonable -- the client doesn't know what to do. +--- | Also, I don't think any floor object (As done now) should have any | type of masking, because by definition of what a floor is meant to | do, you can't see anything below it in any case (so the masking just | turns to white.) That will complicate matters for little or no gain. I don't think keeping separate name spaces for the images used in ITEM and MAP will do any good at all. (Of course the client is free to draw the first pixmap without masking - no one will see the difference) Kjetil T. From crossfire-request Fri Apr 22 04:59:32 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 22 Apr 1994 04:59:32 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Fri, 22 Apr 1994 04:59:30 +0200 Date: Fri, 22 Apr 1994 04:59:30 +0200 Message-Id: <199404220259.13031.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: "Carl Edman"'s message of Thu, 14 Apr 94 14:25:20 -0400 <9404141825.AA07419@capitalist.princeton.edu> Subject: Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol Status: RO ++--- Kjetil T. Homme: || BTW, I think there should be a protocol response for damage. || DAM || || That way a client can present it graphically, not just spew out a || stream of text. Since the client knows the names, it can make up the || text itself if it wishes to. || +--- Carl Edman: | Sounds fine to me with the exception that I'd add a string to the | end of the DAM command which gives some text description like | e.g. "burns" or "hits %s terribly with darkblade.". Just saying | 'Foo damages bar for 5 points' sounds a little bland. Fine, but leave it optional. Keep in mind that the server currently just maps damage levels to verbs like "graze", "hit very hard". The client could do this itself until the server is enhanced to allow more advanced messages specified in archetypes (?). +--- | As much as I like lighting in principle your proposal requires that | in the common case where the player carries a light source, you send | MAP commands for almost every square in the viewport every time the | player takes a step. Do you think you could live with a system in | which every square is either lighted (i.e. MAPed) or unlighted | (i.e. UNMAPed) ? A server which hasn't implemented shading, should be free to send MAP messages with just 0 or 9. Perhaps even if the server did support shading, the client could request to turn it off to reduce bandwidth? +--- | It is nice to see that at least one reader agrees on at least one | part of my proposal. :-) FWIW, the only point where I disagree with you is the MAP command. FLOOR is more general and has obsolensce built out.(*) Kjetil T. *) Guess what computer I preferred back in 1985? From crossfire-request Fri Apr 22 04:42:10 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 22 Apr 1994 04:42:10 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Fri, 22 Apr 1994 04:42:09 +0200 Date: Fri, 22 Apr 1994 04:42:09 +0200 Message-Id: <199404220242.13021.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: "Carl Edman"'s message of Thu, 14 Apr 94 11:27:23 -0400 <9404141527.AA07261@capitalist.princeton.edu> Subject: Re: A few thoughts on client/server Status: RO I'm going to comment upon stuff that was posted a week ago. Be warned. +--- Carl Edman: | If an animation actually means something, it has to be done on the | server side. When I said animations I was thinking exclusively of | aesthetic repeating patterns (like waves, or fire, or darkblade). | Those I believe are both much more frequent and happen much faster. | All of that is handled with relative ease by the proposed protocol. | The only case which is really worrisome are spikes because they both | have meaning _and_ they are constantly and quickly repeating. A | couple of spikes could really load a slow connection. One of the advantages of using symbolic names for all of the images was that an entreprising client writer could draw his own superior sets of images. He could even make a 3D version of Crossfire (like Wolfenstein, not Doom). Clearly, putting some animations here and some there in the model will complicate matters. All we need is a syncing parameter so that the client knows where to start in the sequence. ITEM [ [ [ []]] Default value for is 1, of course. ++--- Tero Haatanen: || Note that alive object's animation can have a real meaning, like || different animation of wizard, when he concentrate to cast a spell Okay, let's take that example: ITEM 1232 1 2 wizconcentrate ITEM 1232 1 2 wizard.111 _versus_ ITEM 1232 1 2 wizconc.111 <0.2 seconds passes> ITEM 1232 1 2 wizconc.111 <0.2 seconds passes> [...] ITEM 1232 1 2 wizard.111 Notes: 1. could be an animation in a future version of crossfire. 2. I think it is best that an animations replay speed can not be changed via the protocol. Animations with same images but different speeds should have different names. I don't think this will be common, anyhow. 3. The fancy 3D client would have to download the animation descriptions to get the number of frames and hence the timings. 4. As for syncing - we don't get sub-frame resolution here. This can be a problem if we allow variable frame length in the animation, so we probably should use a constant frame rate within the animation description, too. This makes it easier to handle at a possible slight performance penalty (size of animation description). Of course, the client can collapse it into (duration,image) pairs if it wants to. ++--- Tero: || So server can implement feature that player don't see all items if || looking from too far. || +--- Carl: | If that is what you want (and it certainly sounds like a good idea), | then just don't send ITEM commands for faraway small items. You realize of course that this won't work unless you put a lot of state in the server for each client, a lot more state than I have called for :-) Onto ASCII->binary->UDP: The way I see it, that's the route we should take. It is trivial to convert Carl's ASCII protocol into a binary protocol, and it will be almost as efficient as a protocol designed to be binary. The only exception I can think of is MAP/UNMAP which could (as suggested by a gentleman whose name I've forgotten) be optimised into transmitting an 11x11 array - with 16 luminance values that is 61 bytes. The argument about the VIEW not necessarily being in the centre of the display is mute - the client will have to map co-ordinates in any case. We should make the protocol so that making a UDP version isn't more of a hassle than necessary. A protocol which doesn't care about lost packets would have to be _very_ graphical in nature. It would be a win over X, for sure, but not much else. So we'd need to ack, but not necessarily for every packet. The other thing TCP gives us is packet ordering. We can design the protocol so that it doesn't depend on it. A sort of mini-TCP: server -> client: ACK? 3 packets client -> server: ACK! 3 packets _or_ client -> server: NAK missing packet with sequence number 2 server -> client: ACK? 3 packets and so on... (every packet has a byte-sized sequence number, which is reset each tick) Getting UDP right is very difficult, though -- just look at the FSP failure! I'll definitely recommend that we write the ASCII layer first, which will be plenty fast enough for LANs and WANs. If we do it right, slipping in a new transport layer would be piece of cake. One more thing: It would be a good thing if the server sent some kind of command at the end of a tick for the convenience of the client. The client must otherwise use a select() with a small timeout to guess when it is opportune to update the screen (assuming the client wants to handle screen refresh in an optimal manner). Kjetil T. PS. I have actually played Crossfire over a 2400 modem while downloading a file in the background (using term :-) I think that with LBX and a 9600 modem or above, performance would be acceptable. (Looking forward to May 2!) From crossfire-request Fri Apr 22 02:30:17 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, 22 Apr 1994 02:28:14 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA26406 (5.67a8/IDA-1.5 for ); Thu, 21 Apr 1994 17:23:11 -0700 Received: by bolero.rahul.net id AA20409 (5.67a8/IDA-1.5); Thu, 21 Apr 1994 17:23:12 -0700 Date: Thu, 21 Apr 1994 17:23:12 -0700 From: Mark Wedel Message-Id: <199404220023.AA20409@bolero.rahul.net> To: Simon.N.Smith@cm.cf.ac.uk, crossfire@ifi.uio.no, peterm@soda.berkeley.edu Subject: Re: lists of current active servers? Status: RO The latest list (albeit fairly old) is the following: These are up and working: madhatter.ws.cc.cmu.edu 13326 sonja.math.virginia.edu 13326 fermat.dartmouth.edu 13326 scotch.berkeley.edu 13326 corpse.ecst.csuchico.edu 13326 Status and versions they are running is unknown, but you could just telent to that port and first, find out if the server is actually up, and second, type version and find out what version it is running. If you know that any of these sites are permantly down, let me know. If you know of additional sites, also let me know. --Mark From crossfire-request Thu Apr 21 22:55:06 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 Apr 1994 22:55:05 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id NAA25586; Thu, 21 Apr 1994 13:54:38 -0700 Date: Thu, 21 Apr 1994 13:54:38 -0700 From: Peter Mardahl Message-Id: <199404212054.NAA25586@soda.berkeley.edu> To: Simon.N.Smith@cm.cf.ac.uk, crossfire@ifi.uio.no Subject: Re: lists of current active servers? Status: RO I know of two active servers: corpse.ecst.csuchico.edu 13326 scotch.berkeley.edu 13326 (fontserver: 13325) Regards, PeterM From crossfire-request Thu Apr 21 14:47:48 1994 Return-Path: Received: from thrall.cm.cf.ac.uk (thrall.cm.cf.ac.uk [131.251.42.22]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 21 Apr 1994 14:47:47 +0200 Received: from cm.cf.ac.uk by thrall.cm.cf.ac.uk with SMTP (PP) id <02375-0@thrall.cm.cf.ac.uk>; Thu, 21 Apr 1994 13:47:38 +0100 Date: Thu, 21 Apr 94 13:47:35 BST From: Simon McIntosh-Smith Message-Id: <9404211247.AA29943@topaz.cm.cf.ac.uk> To: crossfire@ifi.uio.no Subject: lists of current active servers? Status: RO Does anyone have a list of all the currently known active crossfire servers, together with their version numbers? (although I guess most should be 0.90.5 by now...) If you don't know of a list but you DO know of a server, tell me about that too and I'll make the list as complete as possible. The list is going to be added to the WWW crossfire pages at Cardiff, so that it is kept permanently somewhere - I could mail it to the list every so often too to keep everyone up-to-date. All responses to the e-mail address below, Cheers, Sy Simon N. McIntosh-Smith, PhD candidate | Email : Simon.N.Smith@cm.cf.ac.uk Room M/1.36 Department of Computing Maths | Phone : +44 (0)222 874000 University of Wales, College of Cardiff | Fax : +44 (0)222 666182 PO Box 916, Cardiff, Wales, CF2 4YN, U.K. | Home : +44 (0)222 560522 Http : http://www.cm.cf.ac.uk:/People/Simon.Smith.html From crossfire-request Thu Apr 21 07:54:49 1994 Return-Path: Received: from corpse.ecst.csuchico.edu (corpse.ecst.csuchico.edu [132.241.5.10]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 21 Apr 1994 07:54:47 +0200 Received: (from hendel@localhost) by corpse.ecst.csuchico.edu (8.6.8/8.6.6) id WAA18862 for crossfire@ifi.uio.no; Wed, 20 Apr 1994 22:54:43 -0700 From: Chris Hendelberg Message-Id: <199404210554.WAA18862@corpse.ecst.csuchico.edu> Subject: Re: XPM files. To: crossfire@ifi.uio.no Date: Wed, 20 Apr 1994 22:54:42 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 256 Status: RO I have nearly completed the XOM conversion of the bitmaps here at chico, there are only a few large monsters and tid bits left to color. Monsters larger than 4 squares have not been done. Mail me or Tyler if you want the XPM'd pixmaps. Chris Hendelberg From crossfire-request Thu Apr 21 05:54:48 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, 21 Apr 1994 05:50:46 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA02615 (5.67a8/IDA-1.5 for ); Wed, 20 Apr 1994 20:50:41 -0700 Received: by bolero.rahul.net id AA08958 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Wed, 20 Apr 1994 20:50:40 -0700 Date: Wed, 20 Apr 1994 20:50:40 -0700 From: Mark Wedel Message-Id: <199404210350.AA08958@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: XPM files. Status: RO I know that several different people/groups are coloring XPM files. I recently got a batch from Kjetil Wiekhorst J|rgensen , and figured I might as well send to the list which ones he sent in, so that others will not end up coloring the same ones. Here is the list: # 865 -rw-r--r-- arch/monster/acid/acid_pool.111.xpm # 865 -rw-r--r-- arch/monster/acid/acid_pool.112.xpm # 852 -rw-r--r-- arch/monster/acid/acidsphere.111.xpm # 852 -rw-r--r-- arch/monster/acid/acidsphere.112.xpm # 852 -rw-r--r-- arch/monster/acid/acidsphere.113.xpm # 852 -rw-r--r-- arch/monster/acid/acidsphere.114.xpm # 848 -rw-r--r-- arch/monster/acid/bpudding.111.xpm # 848 -rw-r--r-- arch/monster/acid/bpudding.112.xpm # 850 -rw-r--r-- arch/monster/acid/bpudding_g.111.xpm # 850 -rw-r--r-- arch/monster/acid/bpudding_g.112.xpm # 850 -rw-r--r-- arch/monster/acid/bpudding_g.113.xpm # 850 -rw-r--r-- arch/monster/acid/bpudding_g.114.xpm # 850 -rw-r--r-- arch/monster/acid/bpudding_g.115.xpm # 850 -rw-r--r-- arch/monster/acid/bpudding_g.116.xpm # 850 -rw-r--r-- arch/monster/acid/bpudding_g.117.xpm # 850 -rw-r--r-- arch/monster/acid/bpudding_g.118.xpm # 850 -rw-r--r-- arch/monster/acid/bpudding_g.119.xpm # 850 -rw-r--r-- arch/monster/acid/bpudding_s.111.xpm # 850 -rw-r--r-- arch/monster/acid/bpudding_s.112.xpm # 850 -rw-r--r-- arch/monster/acid/bpudding_s.113.xpm # 850 -rw-r--r-- arch/monster/acid/bpudding_s.114.xpm # 886 -rw-r--r-- arch/monster/dragon/Dragon/dragon.131.xpm # 886 -rw-r--r-- arch/monster/dragon/Dragon/dragon.132.xpm # 898 -rw-r--r-- arch/monster/dragon/Dragon/dragon.133.xpm # 931 -rw-r--r-- arch/monster/dragon/Dragon/dragon.171.xpm # 956 -rw-r--r-- arch/monster/dragon/Dragon/dragon.172.xpm # 956 -rw-r--r-- arch/monster/dragon/Dragon/dragon.173.xpm # 898 -rw-r--r-- arch/monster/dragon/Dragon/dragon.231.xpm # 898 -rw-r--r-- arch/monster/dragon/Dragon/dragon.232.xpm # 898 -rw-r--r-- arch/monster/dragon/Dragon/dragon.233.xpm # 898 -rw-r--r-- arch/monster/dragon/Dragon/dragon.271.xpm # 898 -rw-r--r-- arch/monster/dragon/Dragon/dragon.272.xpm # 898 -rw-r--r-- arch/monster/dragon/Dragon/dragon.273.xpm # 931 -rw-r--r-- arch/monster/dragon/Dragon/dragon.331.xpm # 956 -rw-r--r-- arch/monster/dragon/Dragon/dragon.332.xpm # 956 -rw-r--r-- arch/monster/dragon/Dragon/dragon.333.xpm # 886 -rw-r--r-- arch/monster/dragon/Dragon/dragon.371.xpm # 886 -rw-r--r-- arch/monster/dragon/Dragon/dragon.372.xpm # 898 -rw-r--r-- arch/monster/dragon/Dragon/dragon.373.xpm # 887 -rw-r--r-- arch/monster/dragon/Dragon/dragon.431.xpm # 914 -rw-r--r-- arch/monster/dragon/Dragon/dragon.432.xpm # 914 -rw-r--r-- arch/monster/dragon/Dragon/dragon.433.xpm # 858 -rw-r--r-- arch/monster/dragon/Dragon/dragon.471.xpm # 858 -rw-r--r-- arch/monster/dragon/Dragon/dragon.472.xpm # 858 -rw-r--r-- arch/monster/dragon/Dragon/dragon.473.xpm # 858 -rw-r--r-- arch/monster/dragon/Dragon/dragon.531.xpm # 858 -rw-r--r-- arch/monster/dragon/Dragon/dragon.532.xpm # 887 -rw-r--r-- arch/monster/dragon/Dragon/dragon.533.xpm # 858 -rw-r--r-- arch/monster/dragon/Dragon/dragon.571.xpm # 858 -rw-r--r-- arch/monster/dragon/Dragon/dragon.572.xpm # 887 -rw-r--r-- arch/monster/dragon/Dragon/dragon.573.xpm # 858 -rw-r--r-- arch/monster/dragon/Dragon/dragon.631.xpm # 858 -rw-r--r-- arch/monster/dragon/Dragon/dragon.632.xpm # 858 -rw-r--r-- arch/monster/dragon/Dragon/dragon.633.xpm # 887 -rw-r--r-- arch/monster/dragon/Dragon/dragon.671.xpm # 914 -rw-r--r-- arch/monster/dragon/Dragon/dragon.672.xpm # 914 -rw-r--r-- arch/monster/dragon/Dragon/dragon.673.xpm # 884 -rw-r--r-- arch/monster/beholder/dread.111.xpm # 884 -rw-r--r-- arch/monster/beholder/dread.112.xpm # 884 -rw-r--r-- arch/monster/beholder/dread.113.xpm # 896 -rw-r--r-- arch/monster/beholder/dread.211.xpm # 884 -rw-r--r-- arch/monster/beholder/dread.212.xpm # 884 -rw-r--r-- arch/monster/beholder/dread.213.xpm # 884 -rw-r--r-- arch/monster/beholder/dread.311.xpm # 884 -rw-r--r-- arch/monster/beholder/dread.312.xpm # 884 -rw-r--r-- arch/monster/beholder/dread.313.xpm # 884 -rw-r--r-- arch/monster/beholder/dread.411.xpm # 884 -rw-r--r-- arch/monster/beholder/dread.412.xpm # 884 -rw-r--r-- arch/monster/beholder/dread.413.xpm # 873 -rw-r--r-- arch/monster/undead/demilich.111.xpm # 873 -rw-r--r-- arch/monster/undead/demilich.112.xpm # 873 -rw-r--r-- arch/monster/undead/demilich.113.xpm # 830 -rw-r--r-- arch/connect/Hole/hole.111.xpm # 830 -rw-r--r-- arch/connect/Hole/hole.112.xpm # 830 -rw-r--r-- arch/connect/Hole/hole.113.xpm # 830 -rw-r--r-- arch/connect/Hole/hole.114.xpm # 830 -rw-r--r-- arch/connect/Hole/hole.115.xpm # 830 -rw-r--r-- arch/connect/Hole/hole.116.xpm # 830 -rw-r--r-- arch/connect/Hole/hole.117.xpm # 830 -rw-r--r-- arch/connect/Hole/hole.118.xpm # 830 -rw-r--r-- arch/connect/Hole/hole.119.xpm # 830 -rw-r--r-- arch/connect/Hole/hole.11A.xpm # 849 -rw-r--r-- arch/connect/Hole/trapdoor_1.111.xpm # 849 -rw-r--r-- arch/connect/Hole/trapdoor_2.111.xpm # 836 -rw-r--r-- arch/connect/Hole/trapdoor_3.111.xpm # 847 -rw-r--r-- arch/connect/Hole/trapdoor_4.111.xpm --Mark From crossfire-request Wed Apr 20 23:49:16 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, 20 Apr 1994 23:49:14 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id OAA04292 for crossfire@ifi.uio.no; Wed, 20 Apr 1994 14:49:08 -0700 Date: Wed, 20 Apr 1994 14:49:08 -0700 From: Peter Mardahl Message-Id: <199404202149.OAA04292@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: level dependencies for spells Status: RO I'm beginning to think that if you gain more damage from a spell, as you go up in level, you should pay more in sp also. Your damage/time will still increase. Is there any support for this? If not, I won't do it. To those against: i promise to #ifdef the spellpoint level dependency so you can get rid of it.... Regards, PeterM From crossfire-request Wed Apr 20 23:47:48 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 ; Wed, 20 Apr 1994 23:47:45 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id OAA04129; Wed, 20 Apr 1994 14:47:31 -0700 Date: Wed, 20 Apr 1994 14:47:31 -0700 From: Peter Mardahl Message-Id: <199404202147.OAA04129@soda.berkeley.edu> To: bjornlu@ifi.uio.no, crossfire@ifi.uio.no Subject: Re: Easy advancement in 0.90.5 maps Status: RO icestorm isn't as bad as you think for blasting the trapped dragon. You can hit at most 2 dragon's squares with frostbolt, you can hit 6 dragon's with the icestorm. I dont think that frostbolt does 3 times more damage/tick than icestorm.... it might. However, with frostbolt, one could avoid freezing it's hoard, which is a very good argument for icestorm. I've really gotta get an object set up which will report how much damage was done by a spell. It would be very helpful in balancing sp cost vs. damage done..... Regards, PeterM From crossfire-request Wed Apr 20 23:06:24 1994 Return-Path: Received: from yrsa.ifi.uio.no (2116@yrsa.ifi.uio.no [129.240.104.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 20 Apr 1994 23:06:23 +0200 From: =?iso-8859-1?Q?Bj=F8rn_Georg_Ludvigsen?= MIME-Version: 1.0 Received: (from bjornlu@localhost) by yrsa.ifi.uio.no ; Wed, 20 Apr 1994 23:06:20 +0200 Date: Wed, 20 Apr 1994 23:06:19 +0200 To: crossfire@ifi.uio.no Subject: Re: Easy advancement in 0.90.5 maps Message-ID: Status: RO >Virtually any spell caster who reaches level 5 and can cast large >fireball can rise to level 10 or 15 within half an hour in the barn >outside Santo Dominion. Just stand near the door and fire large >fireballs into the corners of the room at the same rate as you recover >mana. It may take a little while but you can be assured of killing 16 >chinese dragons without being in any danger whatsoever. When you get tired of this, try running to the non-non-magic square and use burning hands instead. Quicker, uses less mana, adds some exitement. >The large dragon in the center can be dealt with similarily using the >icestorm spell. Or, again, more efficiently, with frostbolt. You seem to be one of those "blast'emtohellandbacksowe'resurethey'redead"- mages. Try adding a little finesse, will you? What about all the mana wasted trying to destroy the wall if you use large fireball? Did you ever think about the fact that 3/4 of your mana is wasted? And as for using icestorm to kill off a single, trapped dragon - rrright. - Daimon PS: For some REAL exitement in the 0.90.5 maps, check out what we like to refer to around here as "the mountain". Artifacts included. From crossfire-request Wed Apr 20 20:55:47 1994 Return-Path: Received: from castor.cc.utu.fi (root@castor.cc.utu.fi [130.232.1.14]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 20 Apr 1994 20:55:46 +0200 Received: by utu.fi id <166004-3>; Wed, 20 Apr 1994 21:55:35 +0300 Subject: Small bugs in 90.5 From: Tero Jyri Michael Pelander To: crossfire@ifi.uio.no Date: Wed, 20 Apr 1994 21:55:27 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT Content-Length: 756 Message-Id: <94Apr20.215535eet_dst.166004-3@utu.fi> Status: RO 'Animating' empty pictures. When your inventory doesn't have enough items to fill it totally the 'empty picture' is redrawn all the time. You can notice the mouse pointer flickering when it is on top of the area where the pictures should be. This was noticed in xpm mode and using 'unused items' listing. (I have noticed the same behaviour with pix in previous version.) When you apply an unidentified spellbook and you already know the spell the inventory window isn't updated to show the name of spellbook. Also you still seem to be able to make money by using the tables in bank to convert gold into diamonds and then selling them with charisma 30. It is still quite easy to get charisma 30 by using some rings and other stuff to add to the spell. From crossfire-request Wed Apr 20 20:49:50 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, 20 Apr 1994 20:49:49 +0200 Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) with SMTP id LAA06734 for ; Wed, 20 Apr 1994 11:49:45 -0700 Message-Id: <199404201849.LAA06734@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: Really weird bug that I can't figure out Date: Wed, 20 Apr 1994 11:49:43 -0700 From: Scott MacFiggen Status: RO I was trying to get tell to work at noticed something really funny. It finds the proper command in parse_string just fine and passes command_tell the proper arguments but when I step into command_tell, the second argument changes. Actually the pointer it gets is basically null (it points to 0x1008 instead of the address of the argument string). I'm pretty sure the code is right so the only other explaination I can think of is a compiler bug. Anybody out there have crossfire compiled with something besides gcc that can test this theory for me? ############################################################################## # Scott MacFiggen -- 88 VTR250 -- EUVE Systems Administrator -- CEA # # # # smurf@soda.berkeley.edu scottmm@cea.berkeley.edu # ############################################################################## From crossfire-request Wed Apr 20 09:52:43 1994 Return-Path: Received: from thrall.cm.cf.ac.uk (thrall.cm.cf.ac.uk [131.251.42.22]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 20 Apr 1994 09:52:39 +0200 Received: from cm.cf.ac.uk by thrall.cm.cf.ac.uk with SMTP (PP) id <28809-0@thrall.cm.cf.ac.uk>; Wed, 20 Apr 1994 08:52:36 +0100 Date: Wed, 20 Apr 94 08:52:33 BST From: Simon McIntosh-Smith Message-Id: <9404200752.AA22071@garnet.cm.cf.ac.uk> To: crossfire@ifi.uio.no Subject: Re: Some bugs in 0.90.5 Status: RO I've experienced something I've never come across before. I tried to sell something in a shop by dropping it (as usual) but I just got the "you would recieve 4 platinum coins for that ..." message, the shop wouldn't actually buy the item off me. The item was identified and not cursed. I tried selling other items, and the shop wouldn't take those either. I've compiled with "UNIQUE_ITEMS" turned OFF because the game was crashing a lot and I thought it might be more stabl without this new feature. Any ideas? Sy From crossfire-request Wed Apr 20 05:41:36 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 ; Wed, 20 Apr 1994 05:41:31 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA08729 (5.67a8/IDA-1.5 for ); Tue, 19 Apr 1994 20:41:24 -0700 Received: by bolero.rahul.net id AA15145 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Tue, 19 Apr 1994 20:41:22 -0700 Date: Tue, 19 Apr 1994 20:41:22 -0700 From: Mark Wedel Message-Id: <199404200341.AA15145@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Poison core dump bug (patch) Status: RO Here is a patch that will fix the problem with crossfire core dumping when poisoning ends. Note: In general, I will not put out intermediate patches, but this problem is serious/common enough that a fix is needed, and not enough has changed to put out a new version. *** 1.17 1994/04/16 02:22:42 --- time.c 1994/04/20 01:40:13 *************** *** 152,163 **** /* need to remove the object before fix_player is called, else fix_player * will not do anything. */ - remove_ob(op); if(op->env->type==PLAYER) { ! SET_FLAG(op, FLAG_APPLIED); fix_player(op->env); draw_info(op->env,"You feel much better now."); } free_object(op); return; } --- 152,163 ---- /* need to remove the object before fix_player is called, else fix_player * will not do anything. */ if(op->env->type==PLAYER) { ! CLEAR_FLAG(op, FLAG_APPLIED); fix_player(op->env); draw_info(op->env,"You feel much better now."); } + remove_ob(op); free_object(op); return; } From crossfire-request Wed Apr 20 03:03:02 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 ; Wed, 20 Apr 1994 03:02:59 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA26614 (5.67a8/IDA-1.5 for ); Tue, 19 Apr 1994 18:02:35 -0700 Received: by bolero.rahul.net id AA04406 (5.67a8/IDA-1.5); Tue, 19 Apr 1994 18:02:34 -0700 Date: Tue, 19 Apr 1994 18:02:34 -0700 From: Mark Wedel Message-Id: <199404200102.AA04406@bolero.rahul.net> To: crossfire@ifi.uio.no, tpeland@utu.fi Subject: Re: Some bugs in 0.90.5 Status: RO The crossfire.pix.* files can be compressed/gzip'd. However, the XPM library handles the decompression of these files, and old version of XPM may not have that feature. Also, it would mean that the location of the executables need to be in your PATH enviromental variable for the XPM library to find them. --Mark From crossfire-request Wed Apr 20 02:56:07 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 ; Wed, 20 Apr 1994 02:56:05 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA26193 (5.67a8/IDA-1.5 for ); Tue, 19 Apr 1994 17:55:54 -0700 Received: by bolero.rahul.net id AA04099 (5.67a8/IDA-1.5); Tue, 19 Apr 1994 17:55:54 -0700 Date: Tue, 19 Apr 1994 17:55:54 -0700 From: Mark Wedel Message-Id: <199404200055.AA04099@bolero.rahul.net> To: Dirk.Grabenkamp@arbi.informatik.uni-oldenburg.de, crossfire@ifi.uio.no Subject: Re: Crossfire 0905 and runes Status: RO It is a bug in the code, which should be fixed for the next version. --Mark From crossfire-request Wed Apr 20 01:47:36 1994 Return-Path: Received: from castor.cc.utu.fi (root@castor.cc.utu.fi [130.232.1.14]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 20 Apr 1994 01:47:35 +0200 Received: by utu.fi id <165974-2>; Wed, 20 Apr 1994 02:47:26 +0300 Subject: Some bugs in 0.90.5 From: Tero Jyri Michael Pelander To: crossfire@ifi.uio.no Date: Wed, 20 Apr 1994 02:47:18 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT Content-Length: 604 Message-Id: <94Apr20.024726eet_dst.165974-2@utu.fi> Status: RO Crossfire: v0.90.5 ========== While casting you try to read a scroll you get "you are casting" but the scroll disappears as read. Also nonmagic areas propably should just stop the magic from working and not destroy the scroll. After all it is the power of released magic that makes the scoll become useless ashes. The crossfire.pix.? files can't be compressed if you use -xpm. It does work for -pix mode. The README in the lib directory suggests compressing them. Crossedit: ========== In file select window the file bar doesn't work when there are more files then there can fit on the listed area. From crossfire-request Tue Apr 19 22:24:55 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 Apr 1994 22:24:49 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id NAA21143 for crossfire@ifi.uio.no; Tue, 19 Apr 1994 13:24:44 -0700 Date: Tue, 19 Apr 1994 13:24:44 -0700 From: Peter Mardahl Message-Id: <199404192024.NAA21143@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: new public server Status: RO scotch.berkeley.edu 13326 is open. Please 'set font' before adding your display. If you would like to use the x11r5 font server, xset +fp tcp/scotch.berkeley.edu:13325 Regards, PeterM From crossfire-request Tue Apr 19 20:57:13 1994 Return-Path: Received: from po3.andrew.cmu.edu (PO3.ANDREW.CMU.EDU [128.2.10.103]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Apr 1994 20:57:11 +0200 Received: (from postman@localhost) by po3.andrew.cmu.edu (8.6.7/8.6.6) id OAA28543 for crossfire@ifi.uio.no; Tue, 19 Apr 1994 14:57:06 -0400 Received: via switchmail; Tue, 19 Apr 1994 14:57:04 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Tue, 19 Apr 1994 14:54:56 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Tue, 19 Apr 1994 14:54:53 -0400 (EDT) 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, 19 Apr 1994 14:54:52 -0400 (EDT) Message-ID: Date: Tue, 19 Apr 1994 14:54:52 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: TCP vs UDP In-Reply-To: <9404191339.AA02813@capitalist.princeton.edu> References: <9404191339.AA02813@capitalist.princeton.edu> Status: RO "Carl Edman" writes: > In the proposed protocol, there is no 'MOVE n' command. Instead there > is a 'MOVE '. A server which receives this > command will try and move the player to the named location as fast as > possible by the straightest route. Losing a packet under these > circumstances can still be annoying, but it isn't quite as bad. I'm not convinced this is a good idea. How much does the server "know" about when figuring out the fastest shortest route? Does is consider some squares could be bad to walk across[runes]? Does it consider you might want to run around a monster and not go next to it? -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 Apr 19 20:33:45 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 Apr 1994 20:33:44 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id LAA07084 for crossfire@ifi.uio.no; Tue, 19 Apr 1994 11:33:35 -0700 From: Philip Brown Message-Id: <199404191833.LAA07084@soda.berkeley.edu> Subject: Re: TCP vs UDP To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Tue, 19 Apr 1994 11:33:34 -0700 (PDT) In-Reply-To: <9404191342.AA02819@capitalist.princeton.edu> from "Carl Edman" at Apr 19, 94 09:42:27 am X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 595 Status: RO >>>>[From Carl Edman] Yes, according to the original paper (available as RFC something or other) VJ TCP header compression (which is the only thing widely used) compresses TCP headers down to an average of about 6 bytes. UDP headers are different and not compressed at all. Yeah.. UDP headers don't NEED to be compressed :-) But that's pretty durn good. Can't complain much about 6 bytes. Only point of contention I have, then, is the required acknoledgement of stuff we don't really need acknowledged. Ah well. We'll just have to see how much it lags, I guess. From crossfire-request Tue Apr 19 18:56:06 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 Apr 1994 18:56:05 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id JAA27019; Tue, 19 Apr 1994 09:54:35 -0700 Date: Tue, 19 Apr 1994 09:54:35 -0700 From: Peter Mardahl Message-Id: <199404191654.JAA27019@soda.berkeley.edu> To: Dirk.Grabenkamp@arbi.informatik.uni-oldenburg.de Subject: Re: Crossfire 0905 and runes Cc: crossfire@ifi.uio.no Status: RO Select the rune spell you want by typing 'cast rune and then hitting the tab key until you get the one you want. The code which looks up the spellname only seems to want to match the first word for some reason. Regards, PeterM From crossfire-request Tue Apr 19 18:49:07 1994 Return-Path: Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Apr 1994 18:49:06 +0200 Received: from enstb.enst-bretagne.fr by melimelo.enst-bretagne.fr (5.67b8/090294); Tue, 19 Apr 1994 19:48:34 +0200 Received: from bernoulli.enst-bretagne.fr by enstb.enst-bretagne.fr (5.65c8/180193); Tue, 19 Apr 1994 18:48:44 +0200 Date: Tue, 19 Apr 1994 18:48:44 +0200 From: rollet@enstb.enst-bretagne.fr (ROLLET Romaric) Message-Id: <199404191648.AA14385@enstb.enst-bretagne.fr> To: crossfire@ifi.uio.no Subject: address X-Charset: LATIN1 X-Char-Esc: 29 Status: RO I'd like to know a server address...... Please send me one..... Thanx rollet@enstb.enst-bretagne.fr From crossfire-request Tue Apr 19 16:22:40 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Apr 1994 16:22:34 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA02114; Tue, 19 Apr 94 09:53:56 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA02834; Tue, 19 Apr 94 09:53:53 -0400 Date: Tue, 19 Apr 94 09:53:53 -0400 From: "Carl Edman" Message-Id: <9404191353.AA02834@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: MAP, UNMAP and ITEM Reply-To: cedman@Princeton.EDU Status: RO From: Kjetil Torgrim Homme > The three commands MAP, UNMAP and ITEM are really key to the > performance of the protocol, and it is important that the > implications of this division is understood. I agree. Those are the three big ones. > As the protocol proposal stands, the semantics of MAP is twofold: > 1. Tell the client that items at (x,y) are now visible > 2. Tell the client that the floor at (x,y) looks like Exactly. > (1) is fine, but (2) is just a special case of ITEM without a > descriptive text. This isn't a big deal with Carl's model, because > the server will have to retransmit all items at a coordinate when it > comes back into view, and having names for the floor isn't vital, > although it is nice at times. Couldn't agree more. > But I guess you've gathered that I think I have a better suggestion: > > 1: MAP [ ...] > I mentioned this earlier: == 0 means UNMAP, other > light values give different amounts of shadow. It is left to the > client to render areas with little light appropriately. The > client is allowed to ignore the different levels of light when > rendering. Well, as I said before (and wasn't responded to, I think), this is very nice. However in the most common case in which there is any lighting i.e. in a dark map with the player carrying a light source, this means that you have to send MAP commands for every single visible square every single time you take a step. That may add up to signficant amounts of bandwidth very quickly. Is lighting (which I would like to have as well) worth this cost ? > 1: ITEM > 2: ITEM [ []] > Like Carl's proposal. Note that the coordinates can be changed by > itself. Absolutely. I think I said something like this before somewhere, but I forgot to mention it in the draft. However, you do need one more bit of info which I also forgot: quantity. If a client is to deal sensibly with items with quantities (like e.g. allowing the player to split up a stack of gold coins), it needs to know about numbers. I'd use this format: ITEM [ [ []]] Here of course means the short form, like you'd see in an inventory or when clicking on a square, not the long form which some items have (and for which I think we need an examine command). > 1: FLOOR [] > 2: FLOOR [ []] > This is like an ITEM, except it should be rendered below the > items. The object shall not move. The can change > (ie., for earth walls). Like an ITEM, a FLOOR can be removed by > specifying " " == "IN VOID". The FLOOR which is most > important to render is sent first. The client is free to display > as many FLOOR-objects as it likes, including none. I'm not entirely sure I like having a tag for each floor. It will probably be similar in length to and , so why not just use this ? FLOOR [ []] Also, as MAP and FLOOR will frequently be sent together and for the same squares, maybe there could be some hybrid form which can send all the data in one command ? > On a completely unrelated note, you forgot to specify animation > sequences in the image format, Carl! That is a pretty vital point. I > think there should be a separate file format for animations, which > just sends (duration, image name) pairs. (I'm not sure whether > allowing recursion is useful.) Important note: the name space for > animations and images is the same. The client will not know whether > the filename is an animation until it is told via in TRANSMIT. Absolutely. I didn't say anything at all about binary standards. Your idea about composite "animated" images is a good one though, in particular if we use a standard format which we couldn't alter to have the animation information inside the image itself. Carl Edman From crossfire-request Tue Apr 19 15:42:36 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Apr 1994 15:42:33 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA00169; Tue, 19 Apr 94 09:42:29 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA02819; Tue, 19 Apr 94 09:42:27 -0400 Date: Tue, 19 Apr 94 09:42:27 -0400 From: "Carl Edman" Message-Id: <9404191342.AA02819@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: TCP vs UDP Reply-To: cedman@Princeton.EDU Status: RO Philip Brown writes: > Anyone got some figures as to exactly how much gets "compressed", in > a tcp packet with 40 bytes of header, and 40 bytes of user > information?! (compared to UDP. does UDP get compressed at all?) Yes, according to the original paper (available as RFC something or other) VJ TCP header compression (which is the only thing widely used) compresses TCP headers down to an average of about 6 bytes. UDP headers are different and not compressed at all. Eric is right. If you have CSLIP, UDP may not be a win bandwidth-wise and may very well be a loss. Carl Edman From crossfire-request Tue Apr 19 15:45:48 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Apr 1994 15:45:45 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA29272; Tue, 19 Apr 94 09:39:09 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA02813; Tue, 19 Apr 94 09:39:06 -0400 Date: Tue, 19 Apr 94 09:39:06 -0400 From: "Carl Edman" Message-Id: <9404191339.AA02813@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: TCP vs UDP Reply-To: cedman@Princeton.EDU Status: RO Rupert G. Goldie writes: > Absolutely not. As a player I have to be able to hit a movement key > three times and _know_ that I will move three times. If I am doing > soem fancy maneuvering it is totally unacceptable for one move to be > dropped so that I end up bashing my head into a wall while the > monster chasing me pounds me to death. With the real time action of > Crossfire that sort of behaviour will piss players off no end. In the proposed protocol, there is no 'MOVE n' command. Instead there is a 'MOVE '. A server which receives this command will try and move the player to the named location as fast as possible by the straightest route. Losing a packet under these circumstances can still be annoying, but it isn't quite as bad. > Also, aren't we going to lose the benefit of having an ASCII protocol > if we use UDP ? No more telnetting for diagnosing problems. Yep, that is one benefit which we would lose. But there are others. But please don't misunderstand me -- I'm not arguing in favour of a UDP protocol, at least not know. I'm just trying to point out that if done right and with enough work you can probably reach a point with UDP in which the advantages outweigh the disadvantages. Carl Edman From crossfire-request Tue Apr 19 15:34:17 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Apr 1994 15:34:15 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA28551; Tue, 19 Apr 94 09:33:53 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA02810; Tue, 19 Apr 94 09:33:50 -0400 Date: Tue, 19 Apr 94 09:33:50 -0400 From: "Carl Edman" Message-Id: <9404191333.AA02810@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: TCP vs UDP Reply-To: cedman@Princeton.EDU Status: RO Philip Brown writes: > You're neglecting my other proposal, which is that "updates" as far > as mapping goes, use absolute coordinates, and tell client what > "center" is reguarded as. Lest there be any misunderstanding on this point, let me make clear that I think that this is an awful idea. Why would you want to do such a display centric thing ? Just to make clients which want to automatically draw maps (in the traditional sense of the word) for the player harder to write. Also, this makes the packet ordering problem worse. If you tell the client what the absolute position of the player is and what the absolute position of some piece of mapping information is, it doesn't matter in what order they come. However, if you insist on sending all mapping data relative to the player, a simple reversal of order will completely screw up your display. Finally (and only peripherally related) I don't think that the client should always be required to have the player at the center of the screen. Instead clients may want to move the screen in such a manner that the maximum number of mapped squares is visible. That would mean that for example a player walking into a corner of the map would end up in the corner of the viewport. Why waste 3/4s of the screen real estate ? Of course, if clients want to do that they should be free to. Carl Edman From crossfire-request Tue Apr 19 14:25:41 1994 Return-Path: Received: from cc.lut.fi (hevi@cc.lut.fi [157.24.15.37]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Apr 1994 14:25:40 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id PAA01425; Tue, 19 Apr 1994 15:24:55 +0300 Date: Tue, 19 Apr 1994 15:24:54 +0300 (EETDST) From: Petri Heinil{ Subject: Re: Documentation ... To: "Rupert G. Goldie" cc: crossfire@ifi.uio.no In-Reply-To: <199404190021.AA03597@eden-valley.aaii.oz.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Tue, 19 Apr 1994, Rupert G. Goldie wrote: > > > Unfortunately, some of us are on the other side of a fire-wall. This > > > means *nothing* besides FTP, telnet, and mail gets in OR out. This means > > > I *can't* use WWW or Mosaic. > > > > Hmm, I think you should take the Skullcleaver and go to talk > > to your company security people :). The stateful sessions like, > > telnet and ftp are much more bigger security risk, than stateless > > sessions like WWW or gopher. > > > > No, actually. Until the recent version 2.3 Mosaic had an appalling security > hole. It was possible for someone to write a URL which would execute arbitrary > commands on your machine (and a firewall would not stop it) ! > On the other hand we are behind a firewall and let WWW through, but it is a > matter of weighing the risk/benefit. For some companies it may not be worth > the risk. > > > Your company is lost incredible good information source if it > > does not let people go out to use WWW. (no talk to let anyone > > access in, just out). > > > > It is useful, but don't assume that it isn't a security risk. That's right. When usign services the is no absolute security. Because the programs are human made there is always bugs, that allows security holes. I think this will also apply to client server version of the crossfire. -- The Page -- From crossfire-request Tue Apr 19 14:22:45 1994 Return-Path: Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Apr 1994 14:22:42 +0200 Received: from enstb.enst-bretagne.fr by melimelo.enst-bretagne.fr (5.67b8/090294); Tue, 19 Apr 1994 15:22:04 +0200 Received: from galois.enst-bretagne.fr by enstb.enst-bretagne.fr (5.65c8/180193); Tue, 19 Apr 1994 14:22:14 +0200 Date: Tue, 19 Apr 1994 14:22:14 +0200 From: rollet@enstb.enst-bretagne.fr (ROLLET Romaric) Message-Id: <199404191222.AA11797@enstb.enst-bretagne.fr> To: crossfire@ifi.uio.no Subject: address X-Charset: LATIN1 X-Char-Esc: 29 Status: RO I'd like to know the address of a server in Europe... Could you give me some? Thanx. Rom. rollet@enstb.enst-bretagne,fr From crossfire-request Tue Apr 19 11:07:09 1994 Return-Path: Received: from thrall.cm.cf.ac.uk (thrall.cm.cf.ac.uk [131.251.42.22]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Apr 1994 11:07:08 +0200 Received: from cm.cf.ac.uk by thrall.cm.cf.ac.uk with SMTP (PP) id <04264-0@thrall.cm.cf.ac.uk>; Tue, 19 Apr 1994 10:06:59 +0100 Date: Tue, 19 Apr 94 10:06:56 BST From: Simon McIntosh-Smith Message-Id: <9404190906.AA18850@garnet.cm.cf.ac.uk> To: crossfire@ifi.uio.no Subject: Re: Documentation ... Status: RO > I haven't looked at the crossfire documentation available by the WWW, but > if it is more complete or has additional information than what is > distributed, it would be nice if it was sent along to me. > > --Mark The documentation available on the WWW at Cardiff is only a html conversion of the stuff that comes in the crossfire distribution, found in the "doc" directory. These include the survival guide, map maker's guide etc. Also, there's a good chance that most of this documentation is out of date, but the files don't carry any version number so we have no quick way of telling. It's probably not worth anyone doing major updates until the game calms down and stops changing so much :-) It would be no trouble to tar up the html versions of these documents - they wouldn't be much bigger than the plain text versions already distributed. If the html docs were included in the distribution it would allow you to browse them locally if you've got something like mosaic, lynx or cello. Whether this is a good idea or not is another matter... Sy Simon N. McIntosh-Smith, PhD candidate | Email : Simon.N.Smith@cm.cf.ac.uk Room M/1.36 Department of Computing Maths | Phone : +44 (0)222 874000 University of Wales, College of Cardiff | Fax : +44 (0)222 666182 PO Box 916, Cardiff, Wales, CF2 4YN, U.K. | Home : +44 (0)222 560522 Http : http://www.cm.cf.ac.uk:/People/Simon.Smith.html From crossfire-request Tue Apr 19 10:03:34 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 Apr 1994 10:03:31 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id BAA25524 for crossfire@ifi.uio.no; Tue, 19 Apr 1994 01:03:22 -0700 From: Philip Brown Message-Id: <199404190803.BAA25524@soda.berkeley.edu> Subject: Re: TCP vs UDP To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Tue, 19 Apr 1994 01:03:19 -0700 (PDT) In-Reply-To: from "Eric A. Anderson" at Apr 19, 94 00:49:20 am X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 662 Status: RO >>>>[From Eric A. Anderson] > (This is kinda silly. Eventually, when all the fiddling around is done, > and people want more response/features/you-name-it, the game WILL be > re-written to use UDP, just as most other fast-update real-time net games > have been. May as well plan from the start) Such as xtank? Which is written using TCP? xtank hasn't been updated in years, to my recollection. Please correct me if I'm wrong. newer versions of xtrek all support UDP. xpilot supports UDP. I'm not sure what acm uses. acm is mostly video-hardware intensive, however. What other multiplayer, real-time net games for unix are there? From crossfire-request Tue Apr 19 07:21:30 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 Apr 1994 07:21:26 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id WAA09069 for crossfire@ifi.uio.no; Mon, 18 Apr 1994 22:21:21 -0700 From: Philip Brown Message-Id: <199404190521.WAA09069@soda.berkeley.edu> Subject: Re: TCP vs UDP To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Mon, 18 Apr 1994 22:21:20 -0700 (PDT) In-Reply-To: from "Eric A. Anderson" at Apr 19, 94 01:07:47 am X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1953 Status: RO >>>>[From Eric A. Anderson] Philip Brown writes: > >>>>[From Eric A. Anderson] > This introduces the problem of how fast does the client generate move > north commands. Conceptually, what *I* want is a move to the > following location command, not move n w n n w e e s w w. > > Client could implement that, too. a "click to move here" command. But now you need acknowledgements and checks to make things arrive in order, and etc. etc. Some things it matters, some things it doesn't. In this particular example, the user clicks to move. If he doesn't start moving, he clicks again. No big deal. > > Are you talking bout loading pixmaps or something? No, I'm talking about the tcp algorithms to make sure that slow links aren't flooded at startup. The lack of knowledge of stuff like this is precicely the problem that I'm talking about. We as a programming group do not appear to know very much about how TCP is implemented. Hence it is not clear that we are qualified to implement some protocol overtop of UDP. I believe we will end up implementing some decent proportion of TCP. (Checksums for example) UDP HAS: 1) souce socket 2) dest socket 3) checksum 4) user data. If you want, I'll post ALL the things tcp shoves in its packets. > Wel.. you have different problems with tcp, after all. it IS a tradeoff. > Sometimes, the "move north" tcp packet gets delayed, so you end up > pressing it a few more times, making movement unpredictable. If you press it once, you know you will move north once. Are we going to put any such nice guarentee into our protocol? If you want a guarantee to get somewheres, you could use he "click-to-move" feature, ie "MOVE x y" in protocol-speak. otherwise, a guarantee of getting to square x in time y, never existed anyway over a slow link anyways :-/ From crossfire-request Tue Apr 19 06:44:03 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 Apr 1994 06:44:02 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id VAA03962; Mon, 18 Apr 1994 21:43:54 -0700 From: Philip Brown Message-Id: <199404190443.VAA03962@soda.berkeley.edu> Subject: Re: TCP vs UDP To: eanders+@CMU.EDU (Eric A. Anderson) Date: Mon, 18 Apr 1994 21:43:53 -0700 (PDT) Cc: crossfire@ifi.uio.no In-Reply-To: from "Eric A. Anderson" at Apr 18, 94 10:55:57 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 2643 Status: RO >>>>[From Eric A. Anderson] > You want to move north. You hold down the "up" arrow. > client generates "move north" commands. > You get to where you want to go. > You let go the up arrow. client stops generating "move north" commands. This introduces the problem of how fast does the client generate move north commands. Conceptually, what *I* want is a move to the following location command, not move n w n n w e e s w w. Client could implement that, too. a "click to move here" command. > Actually, depending on how the protocol finally happens, it won't make a > difference if we use UDP. Except we will have to re-implement all the slow start stuff to keep from overflowing slow and/or loaded links, we have to re-implement guarenteed delivery stuff, etc. etc. Not sure what you're referring do, vis-a-vis "slow start stuff". Are you talking bout loading pixmaps or something? > Pressing the uparrow could generate a "keep going north" protocol request. > releasing the uparrow could generate a "Stop going north" request. > This would exactly mirror the response you might get with tcp, but > with much less overhead. Except there are problems with latency and lost packets. What happens when the stop going north request gets lost? You don't have this problem with tcp. Wel.. you have different problems with tcp, after all. it IS a tradeoff. Sometimes, the "move north" tcp packet gets delayed, so you end up pressing it a few more times, making movement unpredictable. > Sound reasonable? I personally think UDP would be a really big mistake. We don't seem to have a very coherent opinion of what the protocol should be like, and I think it would be a really big mistake to try and implement stuff over UDP unless there is some very clear benefit. Overhead is not a clear benifit because over the slow links we keep worrying about, the protocols usually do some sort of header compression. Anyone got some figures as to exactly how much gets "compressed", in a tcp packet with 40 bytes of header, and 40 bytes of user information?! (compared to UDP. does UDP get compressed at all?) Furthermore, we lose a lot of work that already gone into making tcp work well. yes, sure.. but do we need somthing that works quite as thoroughly as tcp? If we do not, then it's up to us to put some very reduced form of that onto UDP, and save the net some bother. If we end up putting 50% or more of what tcp already comprises, than of course we should stick with tcp. But we don't need all that!! From crossfire-request Tue Apr 19 06:36: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 ; Tue, 19 Apr 1994 06:36:52 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id VAA03140 for crossfire@ifi.uio.no; Mon, 18 Apr 1994 21:36:49 -0700 From: Philip Brown Message-Id: <199404190436.VAA03140@soda.berkeley.edu> Subject: Re: TCP vs UDP To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Mon, 18 Apr 1994 21:36:48 -0700 (PDT) In-Reply-To: <199404190321.AA04924@eden-valley.aaii.oz.AU> from "Rupert G. Goldie" at Apr 19, 94 01:21:41 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 289 Status: RO >>>>[From Rupert G. Goldie] Also, aren't we going to lose the benefit of having an ASCII protocol if we use UDP ? No more telnetting for diagnosing problems. Well, we wouldn't lose the ASCII protocol part. BUt we would have to write a small UDP version of telnet :-) From crossfire-request Tue Apr 19 05:41:49 1994 Return-Path: Received: from mccaw.com (wombat.mccaw.com [192.135.191.118]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Apr 1994 05:41:45 +0200 Received: from nwestmail.entp.mccaw.com ([155.176.15.34]) by mccaw.com (4.1/SMI-4.1) id AA00408; Mon, 18 Apr 94 20:41:39 PDT Received: from axys69.nwest.mccaw.com by nwestmail.entp.mccaw.com (4.1/McCaw SUN-RMR Mailer, SMI-4.1) id AA04194; Mon, 18 Apr 94 20:41:37 PDT Received: from divac by axys69.nwest.mccaw.com (NX5.67d/NX3.0M, dpg hack 15oct93) id AA11674; Mon, 18 Apr 94 20:44:04 -0700 From: Jason Fosback Message-Id: <9404190344.AA11674@axys69.nwest.mccaw.com> Received: by divac.nwest.mccaw.com (NX5.67d/NX3.0X, dpg hack 20mar93) id AA12846; Mon, 18 Apr 94 20:47:04 -0700 Date: Mon, 18 Apr 94 20:47:04 -0700 Received: by NeXT.Mailer (1.100.RR) Received: by NeXT Mailer (1.100.RR) To: crossfire@ifi.uio.no Subject: Re: Crossfire 90.5 Status: RO Well, I seem to have found a small bug in 0.90.5. As I had previously written, there have been some consistent crashes with this latest release. Well, it turned out that our players were SICK. As soon as the sickness wore off, the server would receive a SIGBUS. To play again, I had to edit our characters and remove the "arch sickness" (I think it was that...). -jason ____________________________________________________________ Jason Fosback, Systems Engineer | No sir, I didn't like it --- Paradigm Systems Corp --- | -R&S Internet: jason_fosback@psca.com | Star Trek: NeXT mail: jason_fosback@psca.com | The NeXT Generation... From crossfire-request Tue Apr 19 05:24:51 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 ; Tue, 19 Apr 1994 05:24:49 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA19803 (5.67a8/IDA-1.5 for ); Mon, 18 Apr 1994 20:24:46 -0700 Received: by bolero.rahul.net id AA18749 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Mon, 18 Apr 1994 20:24:45 -0700 Date: Mon, 18 Apr 1994 20:24:45 -0700 From: Mark Wedel Message-Id: <199404190324.AA18749@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Cf 0.90.5 core dumps. Status: RO For those that have been having numerous core dumps, you may want to make sure that the unique-items directory is created in LIBDIR (make install should do this), and that the directory is writable by whatever uid/gid crossfire runs under. Or, you can just turn off the UNIQUE_ITEMS code in the config.h file. --Mark From crossfire-request Tue Apr 19 05:23:11 1994 Return-Path: Received: from eden-valley.aaii.oz.AU (eden-valley.aaii.oz.AU [192.35.59.254]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Apr 1994 05:22:39 +0200 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA04924; Tue, 19 Apr 1994 13:21:41 +1000 Date: Tue, 19 Apr 1994 13:21:41 +1000 From: "Rupert G. Goldie" Message-Id: <199404190321.AA04924@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no Subject: Re: TCP vs UDP Status: RO > You want to move north. You hold down the "up" arrow. > client generates "move north" commands. > You get to where you want to go. > You let go the up arrow. client stops generating "move north" commands. > > If a packet gets lost, it will just take a little longer to get there :-/ > It depends whetner you like overshooting more, or getting to where you > want more. > > Actually, depending on how the protocol finally happens, it won't make a > difference if we use UDP. > > Pressing the uparrow could generate a "keep going north" protocol request. > releasing the uparrow could generate a "Stop going north" request. > This would exactly mirror the response you might get with tcp, but > with much less overhead. > > Sound reasonable? > Absolutely not. As a player I have to be able to hit a movement key three times and _know_ that I will move three times. If I am doing soem fancy maneuvering it is totally unacceptable for one move to be dropped so that I end up bashing my head into a wall while the monster chasing me pounds me to death. With the real time action of Crossfire that sort of behaviour will piss players off no end. Also, aren't we going to lose the benefit of having an ASCII protocol if we use UDP ? No more telnetting for diagnosing problems. People behind firewalls will lose too. I'm must more prepared to poke a small hole in my firewall to let one TCP port through than a bunch of UDP ports. Rupert From crossfire-request Tue Apr 19 04:58:12 1994 Return-Path: Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Apr 1994 04:58:09 +0200 Received: (from postman@localhost) by andrew.cmu.edu (8.6.7/8.6.6) id WAA27366 for crossfire@ifi.uio.no; Mon, 18 Apr 1994 22:58:04 -0400 Received: via switchmail; Mon, 18 Apr 1994 22:58:04 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Mon, 18 Apr 1994 22:56:03 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Mon, 18 Apr 1994 22:56:00 -0400 (EDT) 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; Mon, 18 Apr 1994 22:55:57 -0400 (EDT) Message-ID: Date: Mon, 18 Apr 1994 22:55:57 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: TCP vs UDP In-Reply-To: <199404182031.NAA04787@soda.berkeley.edu> References: <199404182031.NAA04787@soda.berkeley.edu> Status: RO Philip Brown writes: > >>>>[From Tero Jyri Michael Pelander] > > > [I write..] > [ packet lost tcp ==> server resends ] > > [ what about missed update on map ] > > No, it does NOT matter. You'll get another update in a split second. > There's no benefit in getting repeated old information before the newer > update you _really_ care about. Well, that depends on your protocol. Under the proposed protocol, of which there is currently only one, you would send information like, there is a monster @ 11,11. And if this monster never moves, then you will never get another update on the monster. > You want to move north. You hold down the "up" arrow. > client generates "move north" commands. > You get to where you want to go. > You let go the up arrow. client stops generating "move north" commands. This introduces the problem of how fast does the client generate move north commands. Conceptually, what *I* want is a move to the following location command, not move n w n n w e e s w w. > Actually, depending on how the protocol finally happens, it won't make a > difference if we use UDP. Except we will have to re-implement all the slow start stuff to keep from overflowing slow and/or loaded links, we have to re-implement guarenteed delivery stuff, etc. etc. > Pressing the uparrow could generate a "keep going north" protocol request. > releasing the uparrow could generate a "Stop going north" request. > This would exactly mirror the response you might get with tcp, but > with much less overhead. Except there are problems with latency and lost packets. What happens when the stop going north request gets lost? You don't have this problem with tcp. > Sound reasonable? I personally think UDP would be a really big mistake. We don't seem to have a very coherent opinion of what the protocol should be like, and I think it would be a really big mistake to try and implement stuff over UDP unless there is some very clear benefit. Overhead is not a clear benifit because over the slow links we keep worrying about, the protocols usually do some sort of header compression. Furthermore, we lose a lot of work that already gone into making tcp 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 Apr 19 03:24:18 1994 Return-Path: Received: from cc.lut.fi (hevi@cc.lut.fi [157.24.15.37]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Apr 1994 03:24:18 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id EAA10067; Tue, 19 Apr 1994 04:24:11 +0300 Date: Tue, 19 Apr 1994 04:24:11 +0300 (EETDST) From: Petri Heinil{ Subject: Re: Crossedit To: Tyler Van Gorder cc: crossfire@ifi.uio.no In-Reply-To: <199404182053.NAA18550@pathogen.ecst.csuchico.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 18 Apr 1994, Tyler Van Gorder wrote: > hello, I just compiled crossedit under .90.5 > > > when you attempt to do a "crossedit -xpm" you get: > $ crossedit -xpm > X Error of failed request: BadName (named color or font does not exist) > Major opcode of failed request: 45 (X_OpenFont) > Serial number of failed request: 9708 > Current serial number in output stream: 9715 > > > hmm. trying to set a font? doh. That's the bug I mentioned. It's fixed and patches are on. -- The Page -- From crossfire-request Tue Apr 19 03:46:03 1994 Return-Path: Received: from eden-valley.aaii.oz.AU (eden-valley.aaii.oz.AU [192.35.59.254]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Apr 1994 03:45:55 +0200 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA03597; Tue, 19 Apr 1994 10:21:48 +1000 Date: Tue, 19 Apr 1994 10:21:48 +1000 From: "Rupert G. Goldie" Message-Id: <199404190021.AA03597@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no Subject: Re: Documentation ... Status: RO > > Unfortunately, some of us are on the other side of a fire-wall. This > > means *nothing* besides FTP, telnet, and mail gets in OR out. This means > > I *can't* use WWW or Mosaic. > > Hmm, I think you should take the Skullcleaver and go to talk > to your company security people :). The stateful sessions like, > telnet and ftp are much more bigger security risk, than stateless > sessions like WWW or gopher. > No, actually. Until the recent version 2.3 Mosaic had an appalling security hole. It was possible for someone to write a URL which would execute arbitrary commands on your machine (and a firewall would not stop it) ! On the other hand we are behind a firewall and let WWW through, but it is a matter of weighing the risk/benefit. For some companies it may not be worth the risk. > Your company is lost incredible good information source if it > does not let people go out to use WWW. (no talk to let anyone > access in, just out). > It is useful, but don't assume that it isn't a security risk. Rupert From crossfire-request Tue Apr 19 01:07: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 ; Tue, 19 Apr 1994 01:07:55 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id QAA25834; Mon, 18 Apr 1994 16:07:42 -0700 From: Philip Brown Message-Id: <199404182307.QAA25834@soda.berkeley.edu> Subject: Re: Documentation ... To: master@rahul.net (Mark Wedel) Date: Mon, 18 Apr 1994 16:07:41 -0700 (PDT) Cc: Petri.Heinila@lut.fi, crossfire@ifi.uio.no In-Reply-To: <199404182146.AA25431@bolero.rahul.net> from "Mark Wedel" at Apr 18, 94 02:46:29 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 625 Status: RO >>>>[From Mark Wedel] A few thoughts on the subject: 2) It should be in a fairly standard format, and not require much in the way of special software to access (text and postscript formats fall into this.) Most www clients, as I recall, tend to require Motif, which can be a problem for those systems that do not have it by default. "most"??? lynx doesn't. chimera doesn't. I dont see a problem. And why should I end up compiling an entire package just to look at the documentation. That's a valid point, though :-) html, and text. that's all thats neccessary, really. From crossfire-request Tue Apr 19 01:06:04 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 Apr 1994 01:06:02 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id QAA25639 for crossfire@ifi.uio.no; Mon, 18 Apr 1994 16:05:52 -0700 From: Philip Brown Message-Id: <199404182305.QAA25639@soda.berkeley.edu> Subject: Re: TCP vs UDP To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Mon, 18 Apr 1994 16:05:46 -0700 (PDT) In-Reply-To: <94Apr19.011950eet_dst.165937-2@utu.fi> from "Tero Jyri Michael Pelander" at Apr 19, 94 01:19:46 am X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1141 Status: RO >>>>[From Tero Jyri Michael Pelander] Example on UPD error: The map looks like this. @@ is player a1 a2 a3 a4 a5 b1 b2 b3 b4 b5 c1 c2 @@ c4 c5 d1 d2 d3 d4 d5 e1 e2 e3 e4 e5 Now the player tries to move east but the returning MAP message is dropped out by net. After second move (this time successfull return message) the map looks like: a2 a3 a4 a5 a7 b2 b3 b4 b5 b7 c2 c3 @@ c5 c7 d2 d3 d4 d5 d7 e2 e3 e4 e5 e7 ^ missing line ^ ^ ^ these lines should be one more left. ^ this should no longer be visible You're neglecting my other proposal, which is that "updates" as far as mapping goes, use absolute coordinates, and tell client what "center" is reguarded as. With that in mind, if a client moves a player from (3,3) to (5,3), and receives only a map which has center of (5,3), the client knowns enough to ask for a map refresh. This simultaneously handles the case of "lost" packets, and "out-of-order" packets. Yes, handling some of the details gets a bit complicated. But it will majorly improve the speed of the game. From crossfire-request Tue Apr 19 00:19:58 1994 Return-Path: Received: from castor.cc.utu.fi (root@castor.cc.utu.fi [130.232.1.14]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Apr 1994 00:19:58 +0200 Received: by utu.fi id <165937-2>; Tue, 19 Apr 1994 01:19:50 +0300 Subject: Re: TCP vs UDP From: Tero Jyri Michael Pelander To: crossfire@ifi.uio.no Date: Tue, 19 Apr 1994 01:19:46 +0300 In-Reply-To: <199404182031.NAA04787@soda.berkeley.edu> from "Philip Brown" at Apr 18, 94 11:31:00 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT Content-Length: 1878 Message-Id: <94Apr19.011950eet_dst.165937-2@utu.fi> Status: RO [example on udp drop out] >No, it does NOT matter. You'll get another update in a split second. >There's no benefit in getting repeated old information before the newer >update you _really_ care about. > Of course I still get the 'grimreaper hit you' and I know that > the exit is "sw" and not "s" as I see it. No problem. I just want to give > my commands a bit faster. >It's actually the opposite. You'll get UPDATES faster, That's what I care >about. Using the system that has been proposed for the information passing there is a big difference. You should keep in mind that only changed data is transmitted. Transmitting the whole screens would use much more bandwith then TCP and would not be acceptable for slow connections. Example on UPD error: The map looks like this. @@ is player a1 a2 a3 a4 a5 b1 b2 b3 b4 b5 c1 c2 @@ c4 c5 d1 d2 d3 d4 d5 e1 e2 e3 e4 e5 Now the player tries to move east but the returning MAP message is dropped out by net. After second move (this time successfull return message) the map looks like: a2 a3 a4 a5 a7 b2 b3 b4 b5 b7 c2 c3 @@ c5 c7 d2 d3 d4 d5 d7 e2 e3 e4 e5 e7 ^ missing line ^ ^ ^ these lines should be one more left. ^ this should no longer be visible The player may move two more east and there is still one line missing and 2/5 of the screen is messed up. You might stop for five minutes there and the map around would look messed up all the time. By sending only the changes and not the full map bandwith is saved quite a lot. UPD would need that the whole map is sent every time and even at times when there are no changes just to make sure that the information got through. Comparing this to xtrek is not very good because there are no 'inactivity' times in it. If you want to add messages confirming that the client has already the data then you have implemented TCP on top of UDP. From crossfire-request Mon Apr 18 23:46:45 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 ; Mon, 18 Apr 1994 23:46:42 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA28342 (5.67a8/IDA-1.5 for ); Mon, 18 Apr 1994 14:46:31 -0700 Received: by bolero.rahul.net id AA25431 (5.67a8/IDA-1.5); Mon, 18 Apr 1994 14:46:29 -0700 Date: Mon, 18 Apr 1994 14:46:29 -0700 From: Mark Wedel Message-Id: <199404182146.AA25431@bolero.rahul.net> To: Petri.Heinila@lut.fi, crossfire@ifi.uio.no Subject: Re: Documentation ... Status: RO A few thoughts on the subject: 1) Complete documentation should be able to be accessibly locally and not through net connections. This is because of people who may have firewalls, and others (like myself) may not have their developement machine on the internet, and thus need to log into other machines to use that service. 2) It should be in a fairly standard format, and not require much in the way of special software to access (text and postscript formats fall into this.) Most www clients, as I recall, tend to require Motif, which can be a problem for those systems that do not have it by default. And why should I end up compiling an entire package just to look at the documentation. There is nothing saying that the documentation could not be in several forms. I haven't looked at the crossfire documentation available by the WWW, but if it is more complete or has additional information than what is distributed, it would be nice if it was sent along to me. --Mark From crossfire-request Mon Apr 18 22:53:22 1994 Return-Path: Received: from pathogen.ecst.csuchico.edu (pathogen.ecst.csuchico.edu [132.241.4.10]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 22:53:19 +0200 Received: (from tvangod@localhost) by pathogen.ecst.csuchico.edu (8.6.8/8.6.6) id NAA18550 for crossfire@ifi.uio.no; Mon, 18 Apr 1994 13:53:17 -0700 From: Tyler Van Gorder Message-Id: <199404182053.NAA18550@pathogen.ecst.csuchico.edu> Subject: Crossedit To: crossfire@ifi.uio.no Date: Mon, 18 Apr 1994 13:53:17 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 371 Status: RO hello, I just compiled crossedit under .90.5 when you attempt to do a "crossedit -xpm" you get: $ crossedit -xpm X Error of failed request: BadName (named color or font does not exist) Major opcode of failed request: 45 (X_OpenFont) Serial number of failed request: 9708 Current serial number in output stream: 9715 hmm. trying to set a font? doh. Tyler. From crossfire-request Mon Apr 18 22:32:57 1994 Return-Path: Received: from cc.lut.fi (hevi@cc.lut.fi [157.24.15.37]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 22:32:56 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id XAA03253; Mon, 18 Apr 1994 23:32:53 +0300 Date: Mon, 18 Apr 1994 23:32:53 +0300 (EETDST) From: Petri Heinil{ Subject: Re: Documentation ... To: Crossfire mailing list In-Reply-To: <9404181700.AA26343@axys69.nwest.mccaw.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 18 Apr 1994, Jason Fosback wrote: > Unfortunately, some of us are on the other side of a fire-wall. This > means *nothing* besides FTP, telnet, and mail gets in OR out. This means > I *can't* use WWW or Mosaic. Hmm, I think you should take the Skullcleaver and go to talk to your company security people :). The stateful sessions like, telnet and ftp are much more bigger security risk, than stateless sessions like WWW or gopher. Your company is lost incredible good information source if it does not let people go out to use WWW. (no talk to let anyone access in, just out). > I would prefer some docs we could read in the distribution. PostScript > format is great! But anyway you can use www as local from disk. Because www is a hypertext format it gives much more flexible way to browse documentation as paper. [The documentation, say crossdoc.X.X.tar.gz, is meant to distribute in same way, as other packages, in addition server use.] -- The Page -- From crossfire-request Mon Apr 18 22:31: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 ; Mon, 18 Apr 1994 22:31:07 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id NAA04787 for crossfire@ifi.uio.no; Mon, 18 Apr 1994 13:31:03 -0700 From: Philip Brown Message-Id: <199404182031.NAA04787@soda.berkeley.edu> Subject: Re: TCP vs UDP To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Mon, 18 Apr 1994 13:31:00 -0700 (PDT) In-Reply-To: <94Apr18.154936eet_dst.165936-3@utu.fi> from "Tero Jyri Michael Pelander" at Apr 18, 94 03:49:34 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 2644 Status: RO >>>>[From Tero Jyri Michael Pelander] > [I write..] > IFF there is a holdup, and a packet gets lost with tcp... the server tcpd > will retransmit until it gets through. That is stupid, since by the time > it is retransmitted, you won't WANT the data anyway! It only serves to > screw up your responsiveness. So... It doesn't matter that I just missed the update packet on the last change on the map. There was just a new monster that attacks me and I don't know of it and the exit is no longer directly south as I see it on my screen. No, it does NOT matter. You'll get another update in a split second. There's no benefit in getting repeated old information before the newer update you _really_ care about. Of course I still get the 'grimreaper hit you' and I know that the exit is "sw" and not "s" as I see it. No problem. I just want to give my commands a bit faster. It's actually the opposite. You'll get UPDATES faster, That's what I care about. No matter that the commands that tried to move my character newer got to the server as that connection too is just UDP connection. Oops. forgot about that part :-) Although if the client is implemented sensibly, the following will happen: You want to move north. You hold down the "up" arrow. client generates "move north" commands. You get to where you want to go. You let go the up arrow. client stops generating "move north" commands. If a packet gets lost, it will just take a little longer to get there :-/ It depends whetner you like overshooting more, or getting to where you want more. Actually, depending on how the protocol finally happens, it won't make a difference if we use UDP. Pressing the uparrow could generate a "keep going north" protocol request. releasing the uparrow could generate a "Stop going north" request. This would exactly mirror the response you might get with tcp, but with much less overhead. Sound reasonable? In this model, there might be a benefit for having seperate protocol commands for WALK RUN [and possibly a separate ATTACK ] STOP {with direction, or maybe not} In xtrek the updates basically send the nearly same information many times over as the enemy ships move continuously. This isn't the case in crossfire where there is a "grid" where the monsters/players can move. Are you saying since there's a grid, monsters will move less? That's true, IFF you let them all lock you into a square, and they all pile around you. Otherwise, you'll be generating just as many updates as xtrek :-/ From crossfire-request Mon Apr 18 20:48:49 1994 Return-Path: Received: from mccaw.com (wombat.mccaw.com [192.135.191.118]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 20:48:45 +0200 Received: from nwestmail.entp.mccaw.com ([155.176.15.34]) by mccaw.com (4.1/SMI-4.1) id AA28132; Mon, 18 Apr 94 11:48:41 PDT Received: from axys69.nwest.mccaw.com by nwestmail.entp.mccaw.com (4.1/McCaw SUN-RMR Mailer, SMI-4.1) id AA00459; Mon, 18 Apr 94 11:48:40 PDT Received: from divac by axys69.nwest.mccaw.com (NX5.67d/NX3.0M, dpg hack 15oct93) id AA29378; Mon, 18 Apr 94 11:51:06 -0700 From: Jason Fosback Message-Id: <9404181851.AA29378@axys69.nwest.mccaw.com> Received: by divac.nwest.mccaw.com (NX5.67d/NX3.0X, dpg hack 20mar93) id AA11465; Mon, 18 Apr 94 11:53:53 -0700 Date: Mon, 18 Apr 94 11:53:53 -0700 Received: by NeXT.Mailer (1.100.RR) Received: by NeXT Mailer (1.100.RR) To: crossfire@ifi.uio.no Subject: Re: Crossfire 90.5 Status: RO As a followup, the map that's crashing our game is: load_original_map: /santo_dominion/map.andreasIX Within 15 seconds of loading a character on that map, the games gets a SIGBUS. -jason ____________________________________________________________ Jason Fosback, Systems Engineer | No sir, I didn't like it --- Paradigm Systems Corp --- | -R&S Internet: jason_fosback@psca.com | Star Trek: NeXT mail: jason_fosback@psca.com | The NeXT Generation... From crossfire-request Mon Apr 18 20:37:37 1994 Return-Path: Received: from mccaw.com (wombat.mccaw.com [192.135.191.118]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 20:37:33 +0200 Received: from nwestmail.entp.mccaw.com ([155.176.15.34]) by mccaw.com (4.1/SMI-4.1) id AA28076; Mon, 18 Apr 94 11:37:29 PDT Received: from axys69.nwest.mccaw.com by nwestmail.entp.mccaw.com (4.1/McCaw SUN-RMR Mailer, SMI-4.1) id AA00368; Mon, 18 Apr 94 11:37:28 PDT Received: from divac by axys69.nwest.mccaw.com (NX5.67d/NX3.0M, dpg hack 15oct93) id AA29176; Mon, 18 Apr 94 11:39:53 -0700 From: Jason Fosback Message-Id: <9404181839.AA29176@axys69.nwest.mccaw.com> Received: by divac.nwest.mccaw.com (NX5.67d/NX3.0X, dpg hack 20mar93) id AA11082; Mon, 18 Apr 94 11:42:39 -0700 Date: Mon, 18 Apr 94 11:42:39 -0700 Received: by NeXT.Mailer (1.100.RR) Received: by NeXT Mailer (1.100.RR) To: Inge Berg Fenstad Subject: Re: Crossfire 90.5 Cc: crossfire@ifi.uio.no Status: RO > I have just installed the new version of crossfire and > have experienzed even more crashes than with the last > version. Things that crashed version 90.4 seems to be > ok..but there seem to be other and more mysterious things > which sometimes take it in less than 10 minutes (EVEN > when there are not many ppl on) > > Have anyone else made these observations ? > > Inge Yes, I've noticed an awful lot of crashes under this release as well. Trying to do the Stinking Bungalow->deep dark hole crashes the game after a while. There was a time when the game would consistently crash within just a few seconds of loading a saved character (restored from the autosaved character). -jason ____________________________________________________________ Jason Fosback, Systems Engineer | No sir, I didn't like it --- Paradigm Systems Corp --- | -R&S Internet: jason_fosback@psca.com | Star Trek: NeXT mail: jason_fosback@psca.com | The NeXT Generation... From crossfire-request Mon Apr 18 20:32:56 1994 Return-Path: Received: from ild.alkymi.unit.no (ild.alkymi.unit.no [129.241.113.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 20:32:56 +0200 Received: from jord.alkymi.unit.no by ild.alkymi.unit.no with SMTP id AA26781 (5.65c/IDA-1.4.4 for ); Mon, 18 Apr 1994 20:32:54 +0200 From: Inge Berg Fenstad Received: by jord.alkymi.unit.no ; Mon, 18 Apr 1994 20:32:54 +0200 Message-Id: <199404181832.AA06872@jord.alkymi.unit.no> Subject: Re: Crossfire 90.5 To: jason.fosback@mccaw.com (Jason Fosback) Date: Mon, 18 Apr 1994 20:32:53 +0200 (MET DST) Cc: crossfire@ifi.uio.no In-Reply-To: <9404181700.AA26343@axys69.nwest.mccaw.com> from "Jason Fosback" at Apr 18, 94 10:03:03 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 357 Status: RO I have just installed the new version of crossfire and have experienzed even more crashes than with the last version. Things that crashed version 90.4 seems to be ok..but there seem to be other and more mysterious things which sometimes take it in less than 10 minutes (EVEN when there are not many ppl on) Have anyone else made these observations ? Inge From crossfire-request Mon Apr 18 19:54:33 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 ; Mon, 18 Apr 1994 19:54:32 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id KAA13313 for crossfire@ifi.uio.no; Mon, 18 Apr 1994 10:54:27 -0700 Date: Mon, 18 Apr 1994 10:54:27 -0700 From: Peter Mardahl Message-Id: <199404181754.KAA13313@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: errors in 90.5 Status: RO Anyone know about this error? I'm reading it in the log, don't know what to make of it.: Change object without other_arch error. From crossfire-request Mon Apr 18 18:58:34 1994 Return-Path: Received: from mccaw.com (wombat.mccaw.com [192.135.191.118]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 18:58:29 +0200 Received: from nwestmail.entp.mccaw.com ([155.176.15.34]) by mccaw.com (4.1/SMI-4.1) id AA27572; Mon, 18 Apr 94 09:57:56 PDT Received: from axys69.nwest.mccaw.com by nwestmail.entp.mccaw.com (4.1/McCaw SUN-RMR Mailer, SMI-4.1) id AA29396; Mon, 18 Apr 94 09:57:54 PDT Received: from divac by axys69.nwest.mccaw.com (NX5.67d/NX3.0M, dpg hack 15oct93) id AA26343; Mon, 18 Apr 94 10:00:20 -0700 From: Jason Fosback Message-Id: <9404181700.AA26343@axys69.nwest.mccaw.com> Received: by divac.nwest.mccaw.com (NX5.67d/NX3.0X, dpg hack 20mar93) id AA09891; Mon, 18 Apr 94 10:03:03 -0700 Date: Mon, 18 Apr 94 10:03:03 -0700 Received: by NeXT.Mailer (1.100.RR) Received: by NeXT Mailer (1.100.RR) To: Crossfire mailing list , Petri Heinil{ Subject: Re: Documentation ... Status: RO > Uh, um, eh, m, documentation, er, yes, I have planned to > do documentation about :). > > There is documentation about crossfire in ./doc, and in > http://www.cm.cf.ac.uk:/Crossfire/. > > I think I would be good idea to merge these documenation > into one distributable package done by html pages (I > think www is not a problem because CrossFire works with > X and net, and same does www). Unfortunately, some of us are on the other side of a fire-wall. This means *nothing* besides FTP, telnet, and mail gets in OR out. This means I *can't* use WWW or Mosaic. I would prefer some docs we could read in the distribution. PostScript format is great! -jason ____________________________________________________________ Jason Fosback, Systems Engineer | No sir, I didn't like it --- Paradigm Systems Corp --- | -R&S Internet: jason_fosback@psca.com | Star Trek: NeXT mail: jason_fosback@psca.com | The NeXT Generation... From crossfire-request Mon Apr 18 18:21:05 1994 Return-Path: Received: from phantasm.ecst.csuchico.edu (phantasm.ecst.csuchico.edu [132.241.4.11]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 18:21:04 +0200 Received: (from tvangod@localhost) by phantasm.ecst.csuchico.edu (8.6.8/8.6.6) id JAA24636; Mon, 18 Apr 1994 09:20:52 -0700 From: Tyler Van Gorder Message-Id: <199404181620.JAA24636@phantasm.ecst.csuchico.edu> Subject: Re: Easy advancement in 0.90.5 maps To: master@rahul.net (Mark Wedel) Date: Mon, 18 Apr 1994 09:20:52 -0700 (PDT) Cc: cedman@Princeton.EDU, crossfire@ifi.uio.no In-Reply-To: <199404180542.AA03077@bolero.rahul.net> from "Mark Wedel" at Apr 17, 94 10:42:21 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: 652 Status: RO > > The Santo Dominion maps pre-date the chico maps, but were part of > the distribution. As such, many of the maps would not be considered to be > good maps by any standards. > > I don't know the initial reason the folks at Chico chose to keep those maps, > but they should either be fixed up, or phased out as the map size gets large > enough to have a good playing base. > > --Mark > The maps definately need to be fixed....the reason I included them was because of complaints about not having enough stuff to explore. Unfortunately, I am just now getting around to fixing the maps so they dont give players "easy" exp and artifacts. Tyler. From crossfire-request Tue Apr 19 14:37:09 1994 Return-Path: Received: from arbi.informatik.uni-oldenburg.de (arbi.Informatik.Uni-Oldenburg.DE [134.106.1.7]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 19 Apr 1994 14:34:50 +0200 Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Mon, 18 Apr 94 16:40 CES Received: by diamant.Informatik.Uni-Oldenburg.DE (Smail-3.1.28.1) id ; Mon, 18 Apr 94 16:37 MET DST Message-Id: Subject: Crossfire 0905 and runes To: crossfire@ifi.uio.no Date: Mon, 18 Apr 1994 16:37:30 +0200 (MET DST) From: Dirk Grabenkamp X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 304 Status: RO HI, Does someone else have the following problem or possible solutions: It's not possible for me, to cast another rune than a rune of blasting :( I have testet this even with a dungeonmaster with same result. It's not possible to change the type of rune which i would like to cast... greatings, anatar From crossfire-request Mon Apr 18 15:09:33 1994 Return-Path: Received: from cc.lut.fi (hevi@cc.lut.fi [157.24.15.37]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 15:09:33 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id QAA13058; Mon, 18 Apr 1994 16:09:27 +0300 Date: Mon, 18 Apr 1994 16:09:27 +0300 (EETDST) From: Petri Heinil{ Subject: Re: Crossfire 0.90.5 announcement To: Michael Glenn cc: crossfire@ifi.uio.no In-Reply-To: <9404180338.AA24827@fermat.dartmouth.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Sun, 17 Apr 1994, Michael Glenn wrote: > 4) As with 0.95.4, -xpm mode doesn't work from the MouseX server. BadValue and BadDrawable stuff. As with crossedit the xpm's don't work straight. I fixed the bug and has sended patch to mark. -- The Page -- From crossfire-request Mon Apr 18 14:49:44 1994 Return-Path: Received: from castor.cc.utu.fi (root@castor.cc.utu.fi [130.232.1.14]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 14:49:43 +0200 Received: by utu.fi id <165936-3>; Mon, 18 Apr 1994 15:49:36 +0300 Subject: Re: TCP vs UDP From: Tero Jyri Michael Pelander To: crossfire@ifi.uio.no Date: Mon, 18 Apr 1994 15:49:34 +0300 In-Reply-To: <199404180513.WAA15379@soda.berkeley.edu> from "Philip Brown" at Apr 18, 94 08:13:54 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT Content-Length: 1243 Message-Id: <94Apr18.154936eet_dst.165936-3@utu.fi> Status: RO > IFF there is a holdup, and a packet gets lost with tcp... the server tcpd > will retransmit until it gets through. That is stupid, since by the time > it is retransmitted, you won't WANT the data anyway! It only serves to > screw up your responsiveness. So... It doesn't matter that I just missed the update packet on the last change on the map. There was just a new monster that attacks me and I don't know of it and the exit is no longer directly south as I see it on my screen. Of course I still get the 'grimreaper hit you' and I know that the exit is "sw" and not "s" as I see it. No problem. I just want to give my commands a bit faster. No matter that the commands that tried to move my character newer got to the server as that connection too is just UDP connection. Anything for the speed. > This is especially bad if a whole chunk of packets gets lost or delayed > (as often happens playing xtrek in tcp mode) > (although i wouldn't dare play xtrek over my 14.4 line. but it was bad > enough over ethernet) In xtrek the updates basically send the nearly same information many times over as the enemy ships move continuously. This isn't the case in crossfire where there is a "grid" where the monsters/players can move. From crossfire-request Mon Apr 18 14:20:08 1994 Return-Path: Received: from cc.lut.fi (hevi@cc.lut.fi [157.24.15.37]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 14:20:07 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id PAA07711; Mon, 18 Apr 1994 15:19:52 +0300 Date: Mon, 18 Apr 1994 15:19:51 +0300 (EETDST) From: Petri Heinil{ Subject: Re: Documentation ... To: David Cook cc: Crossfire mailing list In-Reply-To: <9404180340.AA03526@thurso.maths.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 18 Apr 1994, David Cook wrote: > Hello, > Is there any documentation available to help people trying to create maps ? > I've managed to work out some things from looking at existing maps, but it'd > be nice to know _all_ of the things that can be done with maps (it's possible > that crossedit can do things like specifying where an exit goes to, but I > can't see how). Explanations (somewhere!) of all the fields used in archetypes > would be nice, as well - there doesn't seem to be any useful documentation > included in the crossfire-0.90.4-arch package either. Uh, um, eh, m, documentation, er, yes, I have planned to do documentation about :). There is documentation about crossfire in ./doc, and in http://www.cm.cf.ac.uk:/Crossfire/. I think I would be good idea to merge these documenation into one distributable package done by html pages (I think www is not a problem because CrossFire works with X and net, and same does www). -- The Page -- From crossfire-request Mon Apr 18 07:42: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 ; Mon, 18 Apr 1994 07:42:25 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA14843 (5.67a8/IDA-1.5 for ); Sun, 17 Apr 1994 22:42:22 -0700 Received: by bolero.rahul.net id AA03077 (5.67a8/IDA-1.5); Sun, 17 Apr 1994 22:42:21 -0700 Date: Sun, 17 Apr 1994 22:42:21 -0700 From: Mark Wedel Message-Id: <199404180542.AA03077@bolero.rahul.net> To: cedman@Princeton.EDU, crossfire@ifi.uio.no Subject: Re: Easy advancement in 0.90.5 maps Status: RO The Santo Dominion maps pre-date the chico maps, but were part of the distribution. As such, many of the maps would not be considered to be good maps by any standards. I don't know the initial reason the folks at Chico chose to keep those maps, but they should either be fixed up, or phased out as the map size gets large enough to have a good playing base. --Mark From crossfire-request Mon Apr 18 07:37:34 1994 Return-Path: Received: from gyda.ifi.uio.no (0@gyda.ifi.uio.no [129.240.78.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 07:37:33 +0200 Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by gyda.ifi.uio.no ; Mon, 18 Apr 1994 07:37:31 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA14551 (5.67a8/IDA-1.5 for ); Sun, 17 Apr 1994 22:35:57 -0700 Received: by bolero.rahul.net id AA02860 (5.67a8/IDA-1.5); Sun, 17 Apr 1994 22:35:55 -0700 Date: Sun, 17 Apr 1994 22:35:55 -0700 From: Mark Wedel Message-Id: <199404180535.AA02860@bolero.rahul.net> To: crossfire@ifi.uio.no, dcook@spam.maths.adelaide.edu.au Subject: Re: Documentation ... Status: RO There are some files in the 'doc' directory which contains some information. A lot of the documentation needs to be updated (or in some cases, actually written.) --Mark From crossfire-request Mon Apr 18 07:37:11 1994 Return-Path: Received: from gyda.ifi.uio.no (0@gyda.ifi.uio.no [129.240.78.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 07:37:11 +0200 Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by gyda.ifi.uio.no ; Mon, 18 Apr 1994 07:37:08 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA14529 (5.67a8/IDA-1.5 for ); Sun, 17 Apr 1994 22:34:36 -0700 Received: by bolero.rahul.net id AA02791 (5.67a8/IDA-1.5); Sun, 17 Apr 1994 22:34:36 -0700 Date: Sun, 17 Apr 1994 22:34:36 -0700 From: Mark Wedel Message-Id: <199404180534.AA02791@bolero.rahul.net> To: crossfire@ifi.uio.no, fermat@fermat.dartmouth.edu Subject: Re: Crossfire 0.90.5 announcement Status: RO The map.c problem was that I believe Ter Haatanen gave me patches that created xdir.c, which contains a generic directory reading routine, with the various #ifdef's for appropriate machines. The call in map.c used standard readdir call. I've changed it to use the standard xreaddir in xdir.c. Also, if you have a bug report, please don't mail it to the list, unless you think it is of general interest. Most people probably are not especially interested in bugs that don't apply to their system. --Mark From crossfire-request Mon Apr 18 07:14:00 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 ; Mon, 18 Apr 1994 07:13:59 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id WAA15379 for crossfire@ifi.uio.no; Sun, 17 Apr 1994 22:13:56 -0700 From: Philip Brown Message-Id: <199404180513.WAA15379@soda.berkeley.edu> Subject: Re: TCP vs UDP To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Sun, 17 Apr 1994 22:13:54 -0700 (PDT) In-Reply-To: <9404180420.AA00659@capitalist.princeton.edu> from "Carl Edman" at Apr 18, 94 00:20:12 am X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1517 Status: RO >>>>[From Carl Edman] > So when calculating required bandwidth to sustain a fast game with > TCP, you've also got to allow packet acknowledgement for TCP. This is > what makes for bad net lag (as opposed to just "mild" net lag with > udp ;-) That I think is misleading. The really slow connections (which is those we need to worry about -- any reasonable protocol will do well on even medium speed connections) are all full duplex (like modem links or 57.6 kbps leased lines). Sending acknowledgments on the back channel doesn't subtract any bandwidth on the forward channel. Eh... it does and it doesn't. Sort of like the amusing line, "In theory, there is no difference between theory and practice. In practice, there is." Speaking specifically of 14.4 modem lines, since that is what I am directly familiar with, sending data the other way shouldn't slow things down. But it does. This is on a sparc 1, with a USR sportster 14.4k sportster Fax/modem. Then there's the whole "latency" issue. IFF there is a holdup, and a packet gets lost with tcp... the server tcpd will retransmit until it gets through. That is stupid, since by the time it is retransmitted, you won't WANT the data anyway! It only serves to screw up your responsiveness. This is especially bad if a whole chunk of packets gets lost or delayed (as often happens playing xtrek in tcp mode) (although i wouldn't dare play xtrek over my 14.4 line. but it was bad enough over ethernet) From crossfire-request Mon Apr 18 06:20:22 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 06:20:21 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA09208; Mon, 18 Apr 94 00:20:16 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA00659; Mon, 18 Apr 94 00:20:12 -0400 Date: Mon, 18 Apr 94 00:20:12 -0400 From: "Carl Edman" Message-Id: <9404180420.AA00659@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: TCP vs UDP Reply-To: cedman@Princeton.EDU Status: RO From Philip Brown : > >>>>[From Eric A. Anderson] > > Philip Brown writes: > > [ largest amount of changes when lots of monsters ] > > > > If they are getting updated here and there, let's say 10 pieces > > of information in one packet, with tcp packet overhead, that > > generates a hell of a lot of overhead. > > THe easiest way to deal with this is to batch up each of the > packets which you conceptually send to the client. Instead of > sending a separate tcp packet for each update, you just keep > putting data in a buffer, and when the server finishes processing > a turn, it flushes all of the connections. > > Exactly. Except Carl said he is firmly against the idea of "turns". > Go figure. I'm so happy to see that my words are taken as gospel now even in partibus infidelium. :-) What I think Eric means is not turns in any game mechanical sense, but rather that a clever algorithm will not send all data it is handled immediately but will wait a little to see if it gets more data quickly so that it can make a larger packet. Fortunately most of the smarts you need already are in all good TCP/IP implementations. > [ A few accurate points deleted ] > So when calculating required bandwidth to sustain a fast game with > TCP, you've also got to allow packet acknowledgement for TCP. This is > what makes for bad net lag (as opposed to just "mild" net lag with > udp ;-) That I think is misleading. The really slow connections (which is those we need to worry about -- any reasonable protocol will do well on even medium speed connections) are all full duplex (like modem links or 57.6 kbps leased lines). Sending acknowledgments on the back channel doesn't subtract any bandwidth on the forward channel. Carl Edman From crossfire-request Mon Apr 18 06:12:35 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 06:12:33 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA08066; Mon, 18 Apr 94 00:12:28 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA00639; Mon, 18 Apr 94 00:12:08 -0400 Date: Mon, 18 Apr 94 00:12:08 -0400 From: "Carl Edman" Message-Id: <9404180412.AA00639@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: cheating & LOS Reply-To: cedman@Princeton.EDU Status: RO From "Eric A. Anderson" : > Philip Brown writes: > > [ largest amount of changes when lots of monsters ] > > > > If they are getting updated here and there, let's say 10 pieces of > > information in one packet, with tcp packet overhead, that generates > > a hell of a lot of overhead. > > THe easiest way to deal with this is to batch up each of the packets > which you conceptually send to the client. Instead of sending a > separate tcp packet for each update, you just keep putting data in a > buffer, and when the server finishes processing a turn, it flushes > all of the connections. It's not hard to do; you just do it in a > library and don't deal with it from then on. Actually, that is not something which you have to do in your code either. Most socket implementations support options to have the system handle things like that. > > If you agrees to switch solely to UDP, I don't think I would have a > > problem with this. > > I think this would be a mistake. UDP means you have to repeat all of > the work of transferring sequenced data; with all the chances of > getting it wrong. Why not just use TCP and take advantage of years > of work? I agree with the basic sentiments. However, there are some performance advantages to UDP and the way the protocol is proposed today, it would not be too hard to make it robust to packet reordering i.e. as each packet represents not some display instructions but some true fact about the world to be entered into the client database, sequence ceases to matter very much. There are still a few sequence dependencies in the proposed protocol, but if there is real interest, I'd be happy to get rid of them. Carl Edman From crossfire-request Mon Apr 18 06:05:27 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 ; Mon, 18 Apr 1994 06:05:25 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id VAA08377 for crossfire@ifi.uio.no; Sun, 17 Apr 1994 21:05:20 -0700 From: Philip Brown Message-Id: <199404180405.VAA08377@soda.berkeley.edu> Subject: TCP vs UDP To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Sun, 17 Apr 1994 21:05:18 -0700 (PDT) X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 2562 Status: RO >>>>[From Eric A. Anderson] Philip Brown writes: > [ largest amount of changes when lots of monsters ] > > If they are getting updated here and there, let's say 10 pieces of > information in one packet, with tcp packet overhead, that generates a > hell of a lot of overhead. THe easiest way to deal with this is to batch up each of the packets which you conceptually send to the client. Instead of sending a separate tcp packet for each update, you just keep putting data in a buffer, and when the server finishes processing a turn, it flushes all of the connections. Exactly. Except Carl said he is firmly against the idea of "turns". Go figure. > If you agrees to switch solely to UDP, I don't think I would have a > problem with this. I think this would be a mistake. UDP means you have to repeat all of the work of transferring sequenced data; with all the chances of getting it wrong. Why not just use TCP and take advantage of years of work? I personally am not too worried about packets arriving out of order. but for the paranoid, You could always use absolute values in data, so out-of-order things would soon be corrected. Example1: server transmits that player has 10 out of 50 hp left, even right after a heal spell. This will get corrected in the next packet or two that comes along. (we're talking about half a second here) example 2: server transmits obsolete map data. obsolete, because player is no longer there. However, this wouldn't matter if: #1 map data always is prefaced with WHICH map this data is for #2 data comes in coordinates relative to the whole map, not the 11x11 player area. eg: player WAS at map coordinates 10,10, and receivs old data about that. However, player is now at coordinates 20,20, and client automatically ignores most of that data. Besides which, even if we choose to put our own sequencing serial number on packets.. even if the headers we tacked out got just as large as tcp packets(and no way would we somhow add 36 extra bytes!!) UDP would still have one very important advantage. TCP packets REQUIRE that the receiver acknowledge them. (not neccessarily for each one, but the requirement is still there) UDP packets just go, and are forgotten about. So when calculating required bandwidth to sustain a fast game with TCP, you've also got to allow packet acknowledgement for TCP. This is what makes for bad net lag (as opposed to just "mild" net lag with udp ;-) From crossfire-request Mon Apr 18 05:40:49 1994 Return-Path: Received: from thurso.maths.adelaide.edu.au (thurso.maths.adelaide.edu.au [129.127.44.113]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 05:40:47 +0200 Received: by thurso.maths.adelaide.edu.au (5.64+1.3.1+0.50/UA-5.19) id AA03526; Mon, 18 Apr 1994 13:10:12 +0930 From: David Cook Message-Id: <9404180340.AA03526@thurso.maths.adelaide.edu.au> Subject: Documentation ... To: crossfire@ifi.uio.no (Crossfire mailing list) Date: Mon, 18 Apr 1994 13:10:10 +0930 (CST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 812 Status: RO Hello, Is there any documentation available to help people trying to create maps ? I've managed to work out some things from looking at existing maps, but it'd be nice to know _all_ of the things that can be done with maps (it's possible that crossedit can do things like specifying where an exit goes to, but I can't see how). Explanations (somewhere!) of all the fields used in archetypes would be nice, as well - there doesn't seem to be any useful documentation included in the crossfire-0.90.4-arch package either. Thanks in advance, David T Cook e-mail: dcook@spam.adelaide.edu.au Phone: +61 8 303 5709 Assistant Computer Manager, Stats, Pure and Applied Maths, Adelaide Uni. "Behind the lines, a face that glimmers. Still looking for a face that shines." - Heartland, The Sisters of Mercy From crossfire-request Mon Apr 18 05:38:03 1994 Return-Path: Received: from dartvax.dartmouth.edu (dartvax.dartmouth.edu [129.170.16.4]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 05:38:02 +0200 Received: from fermat.dartmouth.edu by dartvax.dartmouth.edu (8.6.8.1+DND/4.5HUB) id XAA21599; Sun, 17 Apr 1994 23:38:00 -0400 Received: by fermat.dartmouth.edu (NX5.67d/NX3.0S) id AA24827; Sun, 17 Apr 94 23:38:08 -0400 Date: Sun, 17 Apr 94 23:38:08 -0400 From: Michael Glenn Message-Id: <9404180338.AA24827@fermat.dartmouth.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: Crossfire 0.90.5 announcement Status: RO > Well, I couldn't get it to compile on my NeXT... Only a very few small problems for NeXT people. I detail: 1) common/map.c: Change "struct dirent" to "struct direct". 2) server/main.c: Warning about malloc_debug as usual. 3) crossedit/Attr.c: Need to remove the include of sys/types.h. 4) As with 0.95.4, -xpm mode doesn't work from the MouseX server. BadValue and BadDrawable stuff. Great job! Keep it up. Michael From crossfire-request Mon Apr 18 05:34:22 1994 Return-Path: Received: from po2.andrew.cmu.edu (PO2.ANDREW.CMU.EDU [128.2.10.102]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 05:34:21 +0200 Received: (from postman@localhost) by po2.andrew.cmu.edu (8.6.7/8.6.6) id XAA16632 for crossfire@ifi.uio.no; Sun, 17 Apr 1994 23:34:17 -0400 Received: via switchmail; Sun, 17 Apr 1994 23:34:16 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Sun, 17 Apr 1994 23:33:21 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Sun, 17 Apr 1994 23:33:13 -0400 (EDT) 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; Sun, 17 Apr 1994 23:33:08 -0400 (EDT) Message-ID: Date: Sun, 17 Apr 1994 23:33:08 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: cheating & LOS In-Reply-To: <199404180219.TAA29854@soda.berkeley.edu> References: <199404180219.TAA29854@soda.berkeley.edu> Status: RO Philip Brown writes: > [ largest amount of changes when lots of monsters ] > > If they are getting updated here and there, let's say 10 pieces of > information in one packet, with tcp packet overhead, that generates a > hell of a lot of overhead. THe easiest way to deal with this is to batch up each of the packets which you conceptually send to the client. Instead of sending a separate tcp packet for each update, you just keep putting data in a buffer, and when the server finishes processing a turn, it flushes all of the connections. It's not hard to do; you just do it in a library and don't deal with it from then on. > If you agrees to switch solely to UDP, I don't think I would have a > problem with this. I think this would be a mistake. UDP means you have to repeat all of the work of transferring sequenced data; with all the chances of getting it wrong. Why not just use TCP and take advantage of years of work? -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 Mon Apr 18 05:32:34 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 05:32:33 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA01449; Sun, 17 Apr 94 23:32:29 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA00571; Sun, 17 Apr 94 23:32:25 -0400 Date: Sun, 17 Apr 94 23:32:25 -0400 From: "Carl Edman" Message-Id: <9404180332.AA00571@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Easy advancement in 0.90.5 maps Reply-To: cedman@Princeton.EDU Status: RO Virtually any spell caster who reaches level 5 and can cast large fireball can rise to level 10 or 15 within half an hour in the barn outside Santo Dominion. Just stand near the door and fire large fireballs into the corners of the room at the same rate as you recover mana. It may take a little while but you can be assured of killing 16 chinese dragons without being in any danger whatsoever. The large dragon in the center can be dealt with similarily using the icestorm spell. The daemon lords and the titan are best dealt with using create bomb I find, but that requires a little skill and luck to do right, so I wouldn't count that as a problem. Carl Edman From crossfire-request Mon Apr 18 04:20:05 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 ; Mon, 18 Apr 1994 04:20:03 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id TAA29854; Sun, 17 Apr 1994 19:19:58 -0700 From: Philip Brown Message-Id: <199404180219.TAA29854@soda.berkeley.edu> Subject: Re: cheating & LOS To: cedman@Princeton.EDU Date: Sun, 17 Apr 1994 19:19:56 -0700 (PDT) Cc: crossfire@ifi.uio.no In-Reply-To: <9404172206.AA21588@capitalist.princeton.edu> from "Carl Edman" at Apr 17, 94 06:06:48 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1411 Status: RO >>>>[From Carl Edman] Ah, yes, some people packets/commands interchangably but that is a different matter. Sending updates asynchroneously probably will tend to increase the number of packets. However, that is not as bad as it sounds as the increased TCP/IP packets will mostly occur when the connection is idle in any case. What? I don't grok this. Why would more packets occur when conenction is idle??!! seems contradictory to me. The largest amounts of data (which need all the bandwidth they can get) are generated when the LOS set changes which requires both MAPs, UNMAPs and ITEMs for the new items. That will still be just one packet for all of them. I don't think that's a completely accurate summation. The largest amounts of data conceptually will be generated when you are surrounded by 100 orcs, trolls, dragons, and skulls. Movement all over the place, spells flying, and various missile weapons. This can potentially generate more than 11x11 pieces of information all at once.. or rather, asyncronously. If they are getting updated here and there, let's say 10 pieces of information in one packet, with tcp packet overhead, that generates a hell of a lot of overhead. If you agrees to switch solely to UDP, I don't think I would have a problem with this. Glad to hear you will also be able to do a lot of the coding for this! ;-) From crossfire-request Mon Apr 18 03:06:08 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 ; Mon, 18 Apr 1994 03:06:03 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA27138 (5.67a8/IDA-1.5); Sun, 17 Apr 1994 18:05:53 -0700 Received: by bolero.rahul.net id AA20881 (5.67a8/IDA-1.5); Sun, 17 Apr 1994 18:05:52 -0700 Date: Sun, 17 Apr 1994 18:05:52 -0700 From: Mark Wedel Message-Id: <199404180105.AA20881@bolero.rahul.net> To: crossfire@ifi.uio.no, kjetilho@ifi.uio.no Subject: Re: MAP, UNMAP and ITEM Status: RO Notes on multiple floors: Floors are meant to be so you can not see anything below them. This allows designers to put a button or teleporter or whatever else below a floor, with the player needing to figure it out. With the fact that you are only supposed to see the top floor object, there is no need to send more than 1 floor object for any space. If you take the example of Goth's tavern on top of grass, the grass would be the floor, and the tavern would be a non floor object. The reason many buildings are marked as floors right now is a 'cheap' hack. Because only the top (non floor) object and floor object are displayed, this method is used so things look proper (otherwise, when another object is standing on top of the tavern with grass underneath, you no longer see the tavern object, but rather than top object on grass.) With client/server, the client can display as many objects on one space as it is willing to. If the client is displaying several objects, then the problem with an object on top of tavern with a grass floor is not a problem. Also, I don't think any floor object (As done now) should have any type of masking, because by definition of what a floor is meant to do, you can't see anything below it in any case (so the masking just turns to white.) --Mark From crossfire-request Mon Apr 18 02:47:42 1994 Return-Path: Received: from eden-valley.aaii.oz.AU (eden-valley.aaii.oz.AU [192.35.59.254]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 02:47:05 +0200 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA00687; Mon, 18 Apr 1994 10:46:11 +1000 Date: Mon, 18 Apr 1994 10:46:11 +1000 From: "Rupert G. Goldie" Message-Id: <199404180046.AA00687@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no Subject: Re: maps maps maps maps Status: RO > > Who is working on incorporating the old maps > into the map set? > > The chico world is nice, but it needs to be > extended. The chico people are working on > new maps, but lots of maps already exist.... > > Anyway, we at soda are looking seriously at > adding many of the old maps to the chico set. > We'd rather not collide with anyone else's > effort. > > PeterM > I'm fixing my Nyka maps. Rupert From crossfire-request Mon Apr 18 01:40:19 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 01:40:19 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Mon, 18 Apr 1994 01:40:17 +0200 Date: Mon, 18 Apr 1994 01:40:17 +0200 Message-Id: <199404172340.16607.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no Subject: MAP, UNMAP and ITEM Status: RO The three commands MAP, UNMAP and ITEM are really key to the performance of the protocol, and it is important that the implications of this division is understood. As the protocol proposal stands, the semantics of MAP is twofold: 1. Tell the client that items at (x,y) are now visible 2. Tell the client that the floor at (x,y) looks like (1) is fine, but (2) is just a special case of ITEM without a descriptive text. This isn't a big deal with Carl's model, because the server will have to retransmit all items at a coordinate when it comes back into view, and having names for the floor isn't vital, although it is nice at times. But I guess you've gathered that I think I have a better suggestion: 1: MAP [ ...] I mentioned this earlier: == 0 means UNMAP, other light values give different amounts of shadow. It is left to the client to render areas with little light appropriately. The client is allowed to ignore the different levels of light when rendering. 1: ITEM 2: ITEM [ []] Like Carl's proposal. Note that the coordinates can be changed by itself. 1: FLOOR [] 2: FLOOR [ []] This is like an ITEM, except it should be rendered below the items. The object shall not move. The can change (ie., for earth walls). Like an ITEM, a FLOOR can be removed by specifying " " == "IN VOID". The FLOOR which is most important to render is sent first. The client is free to display as many FLOOR-objects as it likes, including none. An example where a square enters LOS, vanishes, and reappears: (';' is just shorthand for '\n') "MAP 1 1 grass;ITEM 1 1 tavern Goth's inn ITEM 1 1 axe a rusty broadaxe" "UNMAP 1 1" "MAP 1 1 grass;ITEM 1 1 tavern Goth's inn ITEM 1 1 axe a rusty broadaxe" becomes "MAP 1 1 9;FLOOR 1 1 grass;FLOOR 1 1 tavern Goth's inn ITEM 1 1 axe a rusty broadaxe" "MAP 1 1 0" "MAP 1 1 9;FLOOR 1 1 grass;FLOOR 1 1 tavern Goth's inn ITEM 1 1 axe a rusty broadaxe" No gain? Well - the client can now draw a nice tavern on a grassy background if it wishes. It got no hint on how to do complex graphics like this before. The client also knows that it is impossible to pick up the tavern. And we can support light sources later. If we allow the client to be smart, and remember all data about the current map, the above transaction would look like: "MAP 1 1 9 FLOOR 1 1 grass;FLOOR 1 1 tavern Goth's inn ITEM 1 1 axe a rusty broadaxe" "MAP 1 1 0" "MAP 1 1 9" There's a lot to be gained there! ----------- On a completely unrelated note, you forgot to specify animation sequences in the image format, Carl! That is a pretty vital point. I think there should be a separate file format for animations, which just sends (duration, image name) pairs. (I'm not sure whether allowing recursion is useful.) Important note: the name space for animations and images is the same. The client will not know whether the filename is an animation until it is told via in TRANSMIT. Kjetil T. From crossfire-request Mon Apr 18 00:07:00 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 18 Apr 1994 00:06:58 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA07110; Sun, 17 Apr 94 18:06:52 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA21588; Sun, 17 Apr 94 18:06:48 -0400 Date: Sun, 17 Apr 94 18:06:48 -0400 From: "Carl Edman" Message-Id: <9404172206.AA21588@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: cheating & LOS Reply-To: cedman@Princeton.EDU Status: RO Phillipe Brown writes: > >>>>[From Carl Edman] > > From: Philip Brown : > > > asynchronous updates WASTE bandwidth, because they generate > > many many more packets than would otherwise be sent. > > Can you please give one single common game situation in which an > async protocol (as proposed and explained in the example I > posted) will cost "many" more commands than if used > synchroneously ? > > _packets_, I said, packets. With the emphasis being that for every > command you send, you send 40 bytes of header. Ah, yes, some people packets/commands interchangably but that is a different matter. Sending updates asynchroneously probably will tend to increase the number of packets. However, that is not as bad as it sounds as the increased TCP/IP packets will mostly occur when the connection is idle in any case. The largest amounts of data (which need all the bandwidth they can get) are generated when the LOS set changes which requires both MAPs, UNMAPs and ITEMs for the new items. That will still be just one packet for all of them. > > 2) it preserves a concept of relative "speed" between > > monsters/players/etc nicely > > That is certainly a concept worth preserving. How it relates to > the fact that you have to do things synchroneously I do not > see. > > Lemme put it another way. What's your completely new way of doing > things in the server that will make asynchronous updating work, and > are you going to do the programming for it? Yes. My last major project (a native port of Emacs 19 to NeXTstep) is just winding down. I'm perfectly willing to invest the number of necessary hours to change the server so that full advantage of the client/server concept is taken. > > 3) It equalizes play between fast-update and medium-update > > players. > > Do you mean to say that you deliberately add unnecessary latency > to fast connections to punish those players ? I don't think > that is a virtue. > > What are you complaining about? There's no need to change the current > schema. There is going to have to be a maximum frame rate that is > practical to support. Fast clients will not get any benefit from > getting their frame updates a piece at a time. They still cannot move > any faster than the specified frame rate. I'm not quite sure why you insist on mixing up something real inside the game world (like movement rate) with something which is just part of the mechanics like when data gets sent to the client. _Of_course_ movement rate has to be independent from the network bandwidth and I can see absolutely no reason why the two should even be related. Also, I think that talking about "frame rate" in crossfire like in a flight simulator is somewhat misleading. In a flight simulator you have a continuous change of the world and the faster you can draw the better. In crossfire on the other hand, everything in the world happens in a discrete fashion and if nothing happens the frame should not be redrawn at all. A better perfomance measure in my opinion is average "latency" i.e. the average amount of time it takes for some change in the state of the world to actually become visible to the user. > Fast connections get extra info on each update. But they don't get > any extra updates. To do otherwise is unfair to midrange connections > > Note that the other hand, mid-speed conenctions will find a serious > detriment from having updates a bit at a time. You've got to work > with the framework of IP communication. The more fragmented your data > for updates, the worse real-time response will be. If we can get anywhere close to having the minimum specification I suggested a while ago (1-2 kBytes/sec bandwidth, 100-200 ms roundtrip time) and I'm confident that we can get close and think there is a good chance that we can actually make that spec, there is no reason to worry about mid-speed connections. If the game is playable at 1-2 kBytes/sec, you won't even be able to feel the difference between a midrange connection which is more than 10x faster (like cross-country internet) or a high speed connection which is more than 100x faster (like a local ethernet). > I promise that I do try to be open to your suggestions and > criticisms and am sure that they will improve the protocol. But > please do also try yourself to be open to the idea that the > client/server protocol may change things for the better and more > rational and that should be its goal and not a slavish > replication of _exactly_ the way the current X client looks and > works. > > I was one of the first, if not the first, to push for a switch to a > client/server model. At times I got the impression that you were completely opposed to client/server and liked things just fine the way they were. I'm glad that that's not the reality. > However, we are dealing with very large code here. Things will go a > lot smoother if you don't get fired up about re-writing everything in > sight. Just the conversion from current to client/server model is > going to be a horrendously long task, and involve many may hours of > tuning things. Attempting to re-write significantly many other things > will screw things up by a factor of 10 or more. If you realy want to > do that, you'd be better off organising people to write a game from > scratch. I'm quite serious about this, and most other experienced > programmers will agree with me. I agree with you about the size of this project. Client/Server done right will involve large amounts of programming by people who know what they are doing. The question is whether we just want to add another layer of code atop the current code, or if we want to take advantage of the opportunity which client/server offers to actually simplify and rationalize things which touch on it. The former may require slightly less work in the short run, but in the long run it is certainly more efficient to clean up several interrelating problems at once. I believe that if we do client/server right, the total server code size will actually shrink compared to what we have now and maintenance will become much easier. Carl Edman From crossfire-request Sun Apr 17 23:30:23 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sun, 17 Apr 1994 23:30:23 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Sun, 17 Apr 1994 23:30:22 +0200 Date: Sun, 17 Apr 1994 23:30:22 +0200 Message-Id: <199404172130.16478.bera.ifi.uio.no@ifi.uio.no> To: In-reply-to: <199404172113.OAA06739@soda.berkeley.edu> Subject: Re: 90.5: what's a guy gotta do to get Status: RO The correct address is ftp.ifi.uio.no, not ifi.uio.no. We couldn't figure out the best way tell you this, but the Right Thing is to use the alias. (This is the kind of prose you get when it's written by committee.) Kjetil T. From crossfire-request Sun Apr 17 23:21:20 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 ; Sun, 17 Apr 1994 23:21:16 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA00514 (5.67a8/IDA-1.5); Sun, 17 Apr 1994 14:21:11 -0700 Received: by bolero.rahul.net id AA11555 (5.67a8/IDA-1.5); Sun, 17 Apr 1994 14:21:11 -0700 Date: Sun, 17 Apr 1994 14:21:11 -0700 From: Mark Wedel Message-Id: <199404172121.AA11555@bolero.rahul.net> To: crossfire@ifi.uio.no, kjetilho@ifi.uio.no Subject: Re: CPU -- Ultima 8 Status: RO I've removed some of the stuff from the TODO list. If you see stuff in the TODO list for the new version that you know have been removed, send me mail. A lot of the stuff I am just not sure of. --Mark From crossfire-request Sun Apr 17 23:13: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 ; Sun, 17 Apr 1994 23:13:54 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id OAA06739 for crossfire@ifi.uio.no; Sun, 17 Apr 1994 14:13:44 -0700 Date: Sun, 17 Apr 1994 14:13:44 -0700 From: Peter Mardahl Message-Id: <199404172113.OAA06739@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: 90.5: what's a guy gotta do to get Status: RO his hands on it? i tried both ifi.uio.no and world.net both are refusing connections. Anywhere else i could get it? PeterM From crossfire-request Sun Apr 17 22:47:11 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sun, 17 Apr 1994 22:47:09 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA25105; Sun, 17 Apr 94 16:47:06 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA20083; Sun, 17 Apr 94 16:47:04 -0400 Date: Sun, 17 Apr 94 16:47:04 -0400 From: "Carl Edman" Message-Id: <9404172047.AA20083@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: Crossfire 0.90.5 announcement Reply-To: cedman@Princeton.EDU Status: RO "Kevin H. Weiss" writes: > Well, I couldn't get it to compile on my NeXT... I don't think it > liked the LOCK_ITEM code... Here's where it stopped... Make that single dirent in map.c a direct and you should be fine. Also you should include and not . Carl Edman From crossfire-request Sun Apr 17 22:29:38 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 ; Sun, 17 Apr 1994 22:29:37 +0200 Received: from sonja.math.virginia.edu by uvaarpa.virginia.edu id aa18949; 17 Apr 94 16:29 EDT Received: by sonja.math.Virginia.EDU (NX5.67c/NX3.0S) id AA15108; Sun, 17 Apr 94 16:29:49 -0400 Date: Sun, 17 Apr 94 16:29:49 -0400 From: "Kevin H. Weiss" Message-Id: <9404172029.AA15108@sonja.math.Virginia.EDU> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: crossfire@ifi.uio.no Subject: Re: Crossfire 0.90.5 announcement Status: RO Well, I couldn't get it to compile on my NeXT... I don't think it liked the LOCK_ITEM code... Here's where it stopped... cc -DNeXT -DBSD -I../include -I/usr/include -DX_WCHAR -DX_LOCALE -DNeXT -DLONGJUMP -DXpm_Pix -I/users/khw2x/include/ -DFUNCPROTO=3 -DFONTDIR=\"/usr/games/crossfire/fonts\" -DFONTNAME=\"crossfire\" -DLIBDIR=\"/usr/games/crossfire/lib\" -DCOMPRESS=\"/usr/local/bin/gzip\" -DUNCOMPRESS=\"/usr/local/bin/gunzip\" -DCOMPRESS_SUFFIX=\".gz\" -c map.c -o map.o map.c: In function `load_unique_objects': map.c:808: warning: assignment from incompatible pointer type map.c:809: invalid use of undefined type `struct dirent' map.c:809: dereferencing pointer to incomplete type map.c:815: invalid use of undefined type `struct dirent' map.c:815: dereferencing pointer to incomplete type map.c:818: invalid use of undefined type `struct dirent' map.c:818: dereferencing pointer to incomplete type map.c:819: invalid use of undefined type `struct dirent' map.c:819: dereferencing pointer to incomplete type make[1]: *** [map.o] Error 1 From crossfire-request Sun Apr 17 13:07:33 1994 Return-Path: Received: from bera.ifi.uio.no (1232@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sun, 17 Apr 1994 13:07:32 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by bera.ifi.uio.no ; Sun, 17 Apr 1994 13:07:31 +0200 Date: Sun, 17 Apr 1994 13:07:31 +0200 Message-Id: <199404171107.15696.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: Mark Wedel's message of Sun, 17 Apr 1994 01:13:25 -0700 <199404170813.AA16944@bolero.rahul.net> Subject: Re: CPU -- Ultima 8 Status: RO +--- Mark Wedel: | At some time, I will probably try and replace all the floating point | calls with fixed point. Just converting from floating point to fixed point is likely to be slower on "hot" boxes. Please consider this (old!) snippet from the TODO file: > - Change the speed variables from float to long to save speed in > computers that lack floating-point co-processorc. > System: Have a global tick-variable which counts endlessly up (and wraps > at MAX_INT). > Have two variables in the objects, one int which specifies at which > global tick the monster will move next, and one char containing > the remainder from the last division. The advantage of this scheme is that you don't have to write back the results, a single compare is sufficient except when the object is updated. Kjetil T. PS: The next entry in the TODO file is > - Maybe add light/darkness and moving light-sources to the game. > (if it can be made fast enough) This idea has been around forever - sometime it will be reality, and the protocol should allow for it. :-) PPS: Some of the items in the TODO list have actually been implemented/fixed. Mark, you shouldn't be afraid to change the list to your own liking. From crossfire-request Sun Apr 17 13:04:26 1994 Return-Path: Received: from chsun.eunet.ch (chsun.eunet.ch [146.228.10.15]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sun, 17 Apr 1994 13:04:24 +0200 Received: from riva.dial.eunet.ch by chsun.eunet.ch (8.6.4/1.34) id NAA19692; Sun, 17 Apr 1994 13:07:52 +0200 Received: (from markus@localhost) by riva.dial.eunet.ch (8.6.8/8.6.6) id NAA02257 for crossfire@ifi.uio.no; Sun, 17 Apr 1994 13:00:52 +0200 Date: Sun, 17 Apr 1994 13:00:52 +0200 From: Markus Weber Message-Id: <199404171100.NAA02257@riva.dial.eunet.ch> To: crossfire@ifi.uio.no Subject: old crossfire maps Status: RO Hello, A while back I downloaded cleaned-up versions of the old maps to ftp.ifi.uio.no:/pub/crossfire/incoming/old-maps/... The exits are cleaned up some, obsolete archetypes fixed, and the map names are converted to more meaningful names such as map.1234... They are NOT properly connected to the chico maps, but this shouldn't be too much work. Have fun -Markus From crossfire-request Sun Apr 17 10:14:08 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 Apr 1994 10:14:06 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA23712 (5.67a8/IDA-1.5 for ); Sun, 17 Apr 1994 01:13:26 -0700 Received: by bolero.rahul.net id AA16944 (5.67a8/IDA-1.5); Sun, 17 Apr 1994 01:13:25 -0700 Date: Sun, 17 Apr 1994 01:13:25 -0700 From: Mark Wedel Message-Id: <199404170813.AA16944@bolero.rahul.net> To: crossfire@ifi.uio.no, drew@kinglear.cs.Colorado.EDU, rgg@aaii.oz.au Subject: Re: CPU -- Ultima 8 Status: RO At some time, I will probably try and replace all the floating point calls with fixed point. IT shouldn't be too bad - still store things in floatin point format in the file, and scale them to integers upon loading (and rescale down to floats when saving.) This shouldn't be all that difficult, but rather needs to be done carefully (best way might be to changed the name of all the floating point elements when going to fixed point format, so errors occur wherever a floating poitn element name is used. And fix that code by hand. I might attempt that for the next release. I'll have to see if there are many other bugs that need to be fixed. --Mark From crossfire-request Sun Apr 17 00:50:23 1994 Return-Path: Received: from kinglear.cs.Colorado.EDU (kinglear.cs.colorado.edu [128.138.245.80]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sun, 17 Apr 1994 00:50:19 +0200 Received: from localhost (localhost [127.0.0.1]) by kinglear.cs.Colorado.EDU (8.6.5/8.6.5) with SMTP id QAA10253; Sat, 16 Apr 1994 16:49:35 -0600 Message-Id: <199404162249.QAA10253@kinglear.cs.Colorado.EDU> X-Authentication-Warning: kinglear.cs.Colorado.EDU: Host localhost didn't use HELO protocol To: "Rupert G. Goldie" , crossfire@ifi.uio.no Subject: Re: CPU -- Ultima 8 In-reply-to: Your message of "Fri, 15 Apr 1994 12:08:47 +1000." <199404150208.AA25752@eden-valley.aaii.oz.AU> Date: Sat, 16 Apr 1994 16:49:34 -0600 From: Drew Eckhardt Status: RO -------- I run 0.90.4 on my 486SX/25 under Linux. I noticed that when I run it the idle time drops to 0% and system time climbs to 91%. This is on the startin g map with nothing moving about. top says it is crossfire using the system time, not X. I tried changing the speed, here's what I found: speed system % 100000 91 (The remaining is user time) 200000 91 300000 72 500000 46 1000000 17 All of the system time is being spent in the floating point emulator. So crossfire is quite a burden even on a (ok fairly lowly) 486. Crossfire runs fine on 386s, as long as you have a 387. All of the timing things are done using floating point arithmatic, rather than fixed point like they should have been, resulting in abysmal performance on FPU less machines and less than optimal performance on faster boxes (although adds usually execute in one clock on the integer side of chips like the R4400, floating point may take 3 or 4 clocks). At one time, I attempted to replace ]all of the floating point code with fixed point. Although the resulting binary core dumped ocassionally, it was about an order of magnitude faster on my FPUless 386-33. The changes were really trivial, basically a global search and replace of float for fixed which was typedef'd for long, adds and subtracts were unmodified, multiplies and divides were replaced with macros which rescaled things afterwards, etc. Unfortunately, I lost the patches in a disk crash, but fortunately I upgraded my machine to something fast enough that I don't care - but if any one else is interested, I can point them in the right direction and can recreate the fixed point macros, etc. From crossfire-request Sat Apr 16 22:56: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 ; Sat, 16 Apr 1994 22:56:52 +0200 Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) with SMTP id NAA22238 for ; Sat, 16 Apr 1994 13:56:48 -0700 Message-Id: <199404162056.NAA22238@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: Re: modified /city/taverns/goths availabile In-reply-to: Your message of "Sat, 16 Apr 1994 22:16:24 +0300." Date: Sat, 16 Apr 1994 13:56:46 -0700 From: Scott MacFiggen Status: RO In message you write: >On Fri, 15 Apr 1994, Peter Mardahl wrote: > >> >> public ftp at >> scotch.berkeley.edu >> pub/crossfire > >I have problem in accessing like: > >> ftp scotch.berkeley.edu >Connected to scotch.berkeley.edu. >220 scotch.Berkeley.EDU FTP server (SunOS 4.1) ready. >Name (scotch.berkeley.edu:hevi): anonymous >530 User anonymous unknown. >Login failed. > >And same for user "ftp". Any other succeed ? >Problem here or there ? > >-- The Page -- > Peter made a mistake. At the moment the crossfire stuff is on soda.berkeley.edu not scotch. Very soon it will be available from ftp.csua. -Scott From crossfire-request Sat Apr 16 22:48:18 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, 16 Apr 1994 22:48:12 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA01324 (5.67a8/IDA-1.5 for ); Sat, 16 Apr 1994 13:48:06 -0700 Received: by bolero.rahul.net id AA22766 (5.67a8/IDA-1.5); Sat, 16 Apr 1994 13:48:05 -0700 Date: Sat, 16 Apr 1994 13:48:05 -0700 From: Mark Wedel Message-Id: <199404162048.AA22766@bolero.rahul.net> To: Petri.Heinila@lut.fi, crossfire@ifi.uio.no Subject: Re: modified /city/taverns/goths availabile Status: RO I couldn't connect to scotch.berkely, but they appear to be on soda.berkeley.edu. I also agree that be very careful about putting specific items on maps. I notice this especially with potions. But putting a specific potion (potion of strength, potion of int, etc), that potion is guaranteed to be there, and identified, and not cursed. But putting a random potion there, means that the potoin may be cursed, or may not be a potion at all. --Mark From crossfire-request Sat Apr 16 21:16:27 1994 Return-Path: Received: from cc.lut.fi (hevi@cc.lut.fi [157.24.15.37]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sat, 16 Apr 1994 21:16:26 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id WAA14510; Sat, 16 Apr 1994 22:16:24 +0300 Date: Sat, 16 Apr 1994 22:16:24 +0300 (EETDST) From: Petri Heinil{ Subject: Re: modified /city/taverns/goths availabile To: crossfire@ifi.uio.no In-Reply-To: <199404160632.XAA08860@soda.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 15 Apr 1994, Peter Mardahl wrote: > > public ftp at > scotch.berkeley.edu > pub/crossfire I have problem in accessing like: > ftp scotch.berkeley.edu Connected to scotch.berkeley.edu. 220 scotch.Berkeley.EDU FTP server (SunOS 4.1) ready. Name (scotch.berkeley.edu:hevi): anonymous 530 User anonymous unknown. Login failed. And same for user "ftp". Any other succeed ? Problem here or there ? -- The Page -- From crossfire-request Sat Apr 16 21:11:39 1994 Return-Path: Received: from cc.lut.fi (hevi@cc.lut.fi [157.24.15.37]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sat, 16 Apr 1994 21:11:38 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id WAA14466; Sat, 16 Apr 1994 22:11:24 +0300 Date: Sat, 16 Apr 1994 22:11:24 +0300 (EETDST) From: Petri Heinil{ Subject: Re: new picks maps for ftp--try them, you'll like them To: Peter Mardahl cc: crossfire@ifi.uio.no, master@rahul.net In-Reply-To: <199404160205.TAA17805@soda.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 15 Apr 1994, Peter Mardahl wrote: > I've gone through the picks maps for crossedit. Good ! > -- All the artifacts extant are in the artifacts pick map (i hope) > > -- I added an 'equipment' pick map which has every weapon, armour, > shield and helmet around. The shields, armour, and helmets are > sorted horizontally by order of effectiveness. Some words of warning here. The fixed items and artifacts should be used carefylly when added to maps. Because they will be wellknown itemplaces the player can be fetch the item from. This costs the, say playeruse, from the other maps. For example, in the old maps, the wizard tower, where was fixed speedboots, was one of the must maps when I construct the character :) So I think in most cases It's better to use random artifact mark in the map. ... And generally increase the randomness in maps. -- The Page -- From crossfire-request Sat Apr 16 20:59:37 1994 Return-Path: Received: from cc.lut.fi (hevi@cc.lut.fi [157.24.15.37]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sat, 16 Apr 1994 20:59:36 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id VAA14324; Sat, 16 Apr 1994 21:59:34 +0300 Date: Sat, 16 Apr 1994 21:59:34 +0300 (EETDST) From: Petri Heinil{ Subject: Re: mithril chain versus regular chain To: crossfire@ifi.uio.no In-Reply-To: <199404160008.RAA04726@soda.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 15 Apr 1994, Peter Mardahl wrote: > > Chain mail: > > Regular Mithril > ac 4 ac 4 > armour 30 armour 25 > weight 60 weight 15 > last_heal 15 last_heal 5 > last_sp 10 last_sp 18 > > > last_heal: How much it retards spellpoint regeneration > (Honest, I hacked the code to find this out!) > > Last sp: How much it effects your maximum speed: I think > your maximum speed with chainmail on is 1.0 + magical > bonuses, > 1.8 + magical bonuses for mithril. > > The code which handles this is really nasty! It cycles through your > inventory every time looking for last_heal to see if you go up a > point or not in sp. > > > Anyone else think that mithril chainmail should have at least a higher > ac and armour rating than regular chainmail? I played nethack yesterday, and just there changed chain mail to mithril elvel mail, and the was no increasement in ac. And I think the way is good as in crossfire also. The main adwantage in mithril is the lightness, and the next is that it does mot rust. And it's more flexible to use ie. more speed. I think there are advantages enought. And if you think the chain mail, it's made from connected chain pieces. That contstruct gives even maybe better ac and armor effect than in mithril. I think there is misinterpretation that mithril mail is some kind of artifact, what's wrong because it's not named or "given from god" in no way. The material is just mithril. BTW. Does there exits mithril as a material. If it does not, it could be added. Material that is light, rustproof and flexible, but costs very much. Comments ? -- The Page -- From crossfire-request Sat Apr 16 09:20:21 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, 16 Apr 1994 09:20:19 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA20959 (5.67a8/IDA-1.5 for ); Sat, 16 Apr 1994 00:20:11 -0700 Received: by bolero.rahul.net id AA06075 (5.67a8/IDA-1.5); Sat, 16 Apr 1994 00:20:11 -0700 Date: Sat, 16 Apr 1994 00:20:11 -0700 From: Mark Wedel Message-Id: <199404160720.AA06075@bolero.rahul.net> To: crossfire@ifi.uio.no, peterm@soda.berkeley.edu Subject: Re: my hacks to goths Status: RO I actually put in most of the signs, since in many cases, there might be no idea of what to do or what is available to do. The buffer for messages has been increased to 4096 bytes I believe. There were some long messages (longer than 1024 before). I don't see any problem with a big message size - whether it is just one very large message buffer, or several small ones, it adds up the same. Various note: If you are going to take 'control' of a map, please make sure that the Creator/EMail field in the map object is filled in. This would at least give people an idea of who they should contact for changes on that map. --MArk From crossfire-request Sat Apr 16 08:28:29 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 ; Sat, 16 Apr 1994 08:28:28 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id XAA08458 for crossfire@ifi.uio.no; Fri, 15 Apr 1994 23:28:20 -0700 Date: Fri, 15 Apr 1994 23:28:20 -0700 From: Peter Mardahl Message-Id: <199404160628.XAA08458@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: my hacks to goths Status: RO I hacked up a new goths inn. Instead of having a whole bunch of people who say nothing, there are a few people who tell stories about dungeons or quests. It adds some of the atmosphere that is said to be missing. It'd be cool if people would invent stories for their maps and stick someone in goths to tell people about them and give directoins and hints instaed of having signs in the middle of town saying where all the dungeons are. But this generates a lot of collisions as everyone adds their own storyteller in goths. Perhaps people should invent their stories and send them to me. I'll stick them into goths, and give goths to mark. It would be most convenient for me if you would actually put your story into someone in a map someplace, and then simply send me that person. I'll adjust his coordinates to fit gracefully into goths. Because of the finite buffer size for messages (1024 characters total per object, 256 per message) I found it necessary to use a monster and several magic ears to tell long stories. you just have the invisible magic ears speak in response to the player. The magic ears are perfectly invisible and can be stacked underneath the talking NPC. Regards, PeterM From crossfire-request Sat Apr 16 05:21:01 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, 16 Apr 1994 05:20:58 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA21204 (5.67a8/IDA-1.5 for ); Fri, 15 Apr 1994 20:20:49 -0700 Received: by bolero.rahul.net id AA23805 (5.67a8/IDA-1.5); Fri, 15 Apr 1994 20:20:48 -0700 Date: Fri, 15 Apr 1994 20:20:48 -0700 From: Mark Wedel Message-Id: <199404160320.AA23805@bolero.rahul.net> To: crossfire@ifi.uio.no, peterm@soda.berkeley.edu Subject: Re: adding maps Status: RO If you are adding old maps, and want them part of the standard distribution, a few hints follow: 1) Make sure the maps follow the recommendations of the doc/mapguide document. The point of this document is to try to keep at least a mininum quality of maps 2) Try to keep the map names organized. Many of the old maps are stored as something like 'map.1, map.2', or other non-descriptive names. Try to fix this, and make subdirectories as appropriate (for example, cities, with the maps in the directory or below it.) 3) Playtest the maps if all possible. This is how bugs are often noticed. 4) If working on maps that belong to a city, and that city is mostly empty, consider moving that map to one of the existing cities. There is no reason to have 20 cities, each with only a few open buildings. I will gladly take maps that meet this criteria, and merge them in with the standard map set. --Mark From crossfire-request Sat Apr 16 05:07: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 ; Sat, 16 Apr 1994 05:07:30 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id UAA24047 for crossfire@ifi.uio.no; Fri, 15 Apr 1994 20:07:25 -0700 Date: Fri, 15 Apr 1994 20:07:25 -0700 From: Peter Mardahl Message-Id: <199404160307.UAA24047@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: adding maps Status: RO if you're adding maps, please say what of the old maps you've added and where you've put them. We have added no old maps yet. PeterM From crossfire-request Sat Apr 16 04:26:46 1994 Return-Path: Received: from ild.alkymi.unit.no (ild.alkymi.unit.no [129.241.113.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 16 Apr 1994 04:26:46 +0200 Received: from vann.alkymi.unit.no by ild.alkymi.unit.no with SMTP id AA02824 (5.65c/IDA-1.4.4 for ); Sat, 16 Apr 1994 04:26:32 +0200 From: Inge Berg Fenstad Received: by vann.alkymi.unit.no ; Sat, 16 Apr 1994 04:25:15 +0200 Message-Id: <199404160225.AA02989@vann.alkymi.unit.no> Subject: Re: maps maps maps maps To: peterm@soda.berkeley.edu (Peter Mardahl) Date: Sat, 16 Apr 1994 04:25:15 +0200 (MET DST) Cc: crossfire@ifi.uio.no In-Reply-To: <199404160148.SAA16178@soda.berkeley.edu> from "Peter Mardahl" at Apr 15, 94 06:48:48 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 763 Status: RO I have done some converting (making old maps work on the new version) of old maps, and within that also removed the most obvious easy-exp and easy-equipment (removed ten-army and 'run past a titan to get Excalibur'-things). I have not done and major fixes in setup of the maps since i don't know how you guy have planned the adding of new maps. (I have worked under the motto:Just don't let it be easier than the existing maps) I would gladly do some more finishing on the maps if that is needed if you give me some guidelines to follow. Some things i have been noticing thou. Wizards (big mage) have seemed to have lost most of their spellcasting abilities. and mosters bigger than two squares doesn't seem to be able to move through teleporters. Inge From crossfire-request Sat Apr 16 04:05:46 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 ; Sat, 16 Apr 1994 04:05:44 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id TAA17805; Fri, 15 Apr 1994 19:05:34 -0700 Date: Fri, 15 Apr 1994 19:05:34 -0700 From: Peter Mardahl Message-Id: <199404160205.TAA17805@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: new picks maps for ftp--try them, you'll like them Cc: master@rahul.net Status: RO I've gone through the picks maps for crossedit. This is what I've done: -- All the monsters are in the monsters2 pick map (i think) -- All the artifacts extant are in the artifacts pick map (i hope) -- Almost every archetype is now in the picks maps somewhere, I probably only missed a few. (The spell archetypes aren't there, for example) -- The monsters2 pick map includes sanitized verisons of the players--they look like players, they feel like players, but they are monsters and will not crash the server. They are ideal for talking monsters in bars. -- I added an 'equipment' pick map which has every weapon, armour, shield and helmet around. The shields, armour, and helmets are sorted horizontally by order of effectiveness. Public FTP, pub/crossfire, soda.berkeley.edu Regards, PeterM From crossfire-request Sat Apr 16 08:32:28 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 ; Sat, 16 Apr 1994 08:32:27 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id XAA08860 for crossfire@ifi.uio.no; Fri, 15 Apr 1994 23:32:22 -0700 Date: Fri, 15 Apr 1994 23:32:22 -0700 From: Peter Mardahl Message-Id: <199404160632.XAA08860@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: modified /city/taverns/goths availabile Status: RO public ftp at scotch.berkeley.edu pub/crossfire regards, PeterM From crossfire-request Sat Apr 16 08:16:15 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 ; Sat, 16 Apr 1994 08:16:14 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id XAA07564 for crossfire@ifi.uio.no; Fri, 15 Apr 1994 23:16:09 -0700 Date: Fri, 15 Apr 1994 23:16:09 -0700 From: Peter Mardahl Message-Id: <199404160616.XAA07564@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: proposed new spell Status: RO How about a spell of beguilement? Cone spell, turns the victims into pets. PeterM From crossfire-request Sat Apr 16 04:47:09 1994 Return-Path: Received: from ild.alkymi.unit.no (ild.alkymi.unit.no [129.241.113.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 16 Apr 1994 04:47:08 +0200 Received: from jord.alkymi.unit.no by ild.alkymi.unit.no with SMTP id AA06549 (5.65c/IDA-1.4.4 for ); Sat, 16 Apr 1994 04:46:55 +0200 From: Inge Berg Fenstad Received: by jord.alkymi.unit.no ; Sat, 16 Apr 1994 04:47:46 +0200 Message-Id: <199404160247.AA25744@jord.alkymi.unit.no> Subject: Re: maps maps maps maps To: peterm@soda.berkeley.edu (Peter Mardahl) Date: Sat, 16 Apr 1994 04:47:46 +0200 (MET DST) Cc: crossfire@ifi.uio.no In-Reply-To: <199404160148.SAA16178@soda.berkeley.edu> from "Peter Mardahl" at Apr 15, 94 06:48:48 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 143 Status: RO Sorry.. I was wrong about the thing about monsters and teleporters..it was only the map that had some mistakes i didn't see untill now. Inge From crossfire-request Sat Apr 16 03:48:56 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 ; Sat, 16 Apr 1994 03:48:54 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id SAA16178; Fri, 15 Apr 1994 18:48:48 -0700 Date: Fri, 15 Apr 1994 18:48:48 -0700 From: Peter Mardahl Message-Id: <199404160148.SAA16178@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: maps maps maps maps Cc: john@soda.berkeley.edu Status: RO Who is working on incorporating the old maps into the map set? The chico world is nice, but it needs to be extended. The chico people are working on new maps, but lots of maps already exist.... Anyway, we at soda are looking seriously at adding many of the old maps to the chico set. We'd rather not collide with anyone else's effort. Regards, PeterM From crossfire-request Sat Apr 16 03:16:22 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 16 Apr 1994 03:16:21 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA01984; Fri, 15 Apr 94 21:09:19 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA10231; Fri, 15 Apr 94 21:05:31 -0400 Date: Fri, 15 Apr 94 21:05:31 -0400 From: "Carl Edman" Message-Id: <9404160105.AA10231@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: cheating & LOS Reply-To: cedman@Princeton.EDU Status: RO From: Philip Brown : > >>>>[From Carl Edman] > > Why don't we want asynchroneous updates ? Because we like > wasting processor cycles and network bandwidth ? Or because we > can't admit that we could possibly be mistaken about something > ? > > asynchronous updates WASTE bandwidth, because they generate many many > more packets than would otherwise be sent. Can you please give one single common game situation in which an async protocol (as proposed and explained in the example I posted) will cost "many" more commands than if used synchroneously ? > Having timer clicks for updates is neccessary because > 1) that's the way the game code is currently designed If that was a trumping argument, we wouldn't be talking about client/server at all because "that is not the way we do it here and now". We are talking about the significant changes which client/server involves just _because_ it allows us to improve the design of the game. > 2) it preserves a concept of relative "speed" between > monsters/players/etc nicely That is certainly a concept worth preserving. How it relates to the fact that you have to do things synchroneously I do not see. > 3) It equalizes play between fast-update and medium-update players. Do you mean to say that you deliberately add unnecessary latency to fast connections to punish those players ? I don't think that is a virtue. > You seem to be taking into your hands how the server will use the > protocol, instead of just sticking to your proposed protocol itself. > I'm pointing out how it will actually be used. You can not separate the two. What the correct server/client behaviour is depends on the meaning of the protocol commands. Separating the two is sure to produce gibberish. > As for your last comment.. you were the one you pleaded for > un-personal mail. Don't be a hypocrit. I did not mean to attack you. But in the last few days you have appeared to be so obstinately opposed to even for a second think about how things can be done differently and better and have instead always been defending the status quo regardless of consistency. For example, yesterday you within an hour both attacked the protocol as (a) too easy on the players because it tells the client about items in plain view and (b) as too hard on players because it doesn't tell clients what's behind solid walls. At times that is a triffle frustating to me. I promise that I do try to be open to your suggestions and criticisms and am sure that they will improve the protocol. But please do also try yourself to be open to the idea that the client/server protocol may change things for the better and more rational and that should be its goal and not a slavish replication of _exactly_ the way the current X client looks and works. Ok ? Carl Edman From crossfire-request Sat Apr 16 02:42:38 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 ; Sat, 16 Apr 1994 02:42:36 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id RAA09603; Fri, 15 Apr 1994 17:42:31 -0700 From: Philip Brown Message-Id: <199404160042.RAA09603@soda.berkeley.edu> Subject: Re: cheating & LOS To: cedman@Princeton.EDU Date: Fri, 15 Apr 1994 17:42:29 -0700 (PDT) Cc: crossfire@ifi.uio.no In-Reply-To: <9404152326.AA10065@capitalist.princeton.edu> from "Carl Edman" at Apr 15, 94 07:26:25 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1023 Status: RO >>>>[From Carl Edman] Why don't we want asynchroneous updates ? Because we like wasting processor cycles and network bandwidth ? Or because we can't admit that we could possibly be mistaken about something ? asynchronous updates WASTE bandwidth, because they generate many many more packets than would otherwise be sent. synchronous is relative to other players, not "send update... wait for client to acknoledge" as i pointed out. Having timer clicks for updates is neccessary because 1) that's the way the game code is currently designed 2) it preserves a concept of relative "speed" between monsters/players/etc nicely 3) It equalizes play between fast-update and medium-update players. You seem to be taking into your hands how the server will use the protocol, instead of just sticking to your proposed protocol itself. I'm pointing out how it will actually be used. As for your last comment.. you were the one you pleaded for un-personal mail. Don't be a hypocrit. From crossfire-request Sat Apr 16 02:09:06 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 ; Sat, 16 Apr 1994 02:09:05 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id RAA04726 for crossfire@ifi.uio.no; Fri, 15 Apr 1994 17:08:59 -0700 Date: Fri, 15 Apr 1994 17:08:59 -0700 From: Peter Mardahl Message-Id: <199404160008.RAA04726@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: mithril chain versus regular chain Status: RO Chain mail: Regular Mithril ac 4 ac 4 armour 30 armour 25 weight 60 weight 15 last_heal 15 last_heal 5 last_sp 10 last_sp 18 last_heal: How much it retards spellpoint regeneration (Honest, I hacked the code to find this out!) Last sp: How much it effects your maximum speed: I think your maximum speed with chainmail on is 1.0 + magical bonuses, 1.8 + magical bonuses for mithril. The code which handles this is really nasty! It cycles through your inventory every time looking for last_heal to see if you go up a point or not in sp. Anyone else think that mithril chainmail should have at least a higher ac and armour rating than regular chainmail? regards, PeterM (BTW, I don't think that the uses of last_sp and last_heal are documented anywhere for armour, though I didn't do any exhaustive search) From crossfire-request Sat Apr 16 01:30:23 1994 Return-Path: Received: from cc.lut.fi (hevi@cc.lut.fi [157.24.15.37]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sat, 16 Apr 1994 01:30:22 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id CAA21149; Sat, 16 Apr 1994 02:30:21 +0300 Date: Sat, 16 Apr 1994 02:30:20 +0300 (EETDST) From: Petri Heinil{ Subject: Re: followup on crossedit whines To: crossfire@ifi.uio.no In-Reply-To: <199404152318.AA10335@bolero.rahul.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 15 Apr 1994, Mark Wedel wrote: > Actually, what would be nice is for crossedit to display the > 'arch' name in addition to the visible name. That would make it much > easier. > > Several different archetypes share the same name (like grass and > grass_only are both called grass). It would be nice to click on one and > see that the archetype is actually called grass_only. As it is now, I > think the only way to find it out is via the dump command. The arch name could be added in the look-window like: * grass (grass) * grass_only (grass) Comments ? -- The Page -- From crossfire-request Sat Apr 16 01:30:20 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 16 Apr 1994 01:30:19 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA15130; Fri, 15 Apr 94 19:30:13 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA10065; Fri, 15 Apr 94 19:26:25 -0400 Date: Fri, 15 Apr 94 19:26:25 -0400 From: "Carl Edman" Message-Id: <9404152326.AA10065@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: cheating & LOS Reply-To: cedman@Princeton.EDU Status: RO From Philip Brown : > >>>>[From Carl Edman] > > The client/server protocol does not have "rounds". > > Yes it does. See below Forgive, me but I wrote this protocol. If you want to argue that it has to have, do so. But please don't tell me what I meant to say. > Yes, the server has to keep LOS maps, both for computational > efficiency and for the sake of the protocol. Whenever an item > moves or changes, the server goes through the list of the LOS > maps for all players and immediately sends ITEM commands to all > the players for whom the item is in the LOS. > > Absolutely positively not. Absolutely positively yes. > The protocol itself does not have an explicit notion of rounds, but > that's because it's underlying purpose is to best handle rounds. The > whole model for crossfire REQUIRES syncroynous rounds, across > player/monster movement. Synchronicity is a pain not a boon. It is much easier to construct a logically consistent and CPU efficient simulation in which all events are serialized. > At each round, the server goes through each player's 11x11 map, and > sends everything relevant. A player move takes (usually) one or more > number of rounds. But so does standing still for some amount of time. So the you require the server to go through the entire map for every client many times while nothing at all is happening. Personally, I do not consider thumb twiddling and wheel churning to be high virtues. > The only reason the protocol has support for partial uploading of a > 11x11 map to a client, is simply because it's more efficient that > way, not because we want asynchronous updates. Why don't we want asynchroneous updates ? Because we like wasting processor cycles and network bandwidth ? Or because we can't admit that we could possibly be mistaken about something ? Carl Edman From crossfire-request Sat Apr 16 01:18:21 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, 16 Apr 1994 01:18:19 +0200 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA08857 (5.67a8/IDA-1.5 for ); Fri, 15 Apr 1994 16:18:07 -0700 Received: by bolero.rahul.net id AA10335 (5.67a8/IDA-1.5); Fri, 15 Apr 1994 16:18:05 -0700 Date: Fri, 15 Apr 1994 16:18:05 -0700 From: Mark Wedel Message-Id: <199404152318.AA10335@bolero.rahul.net> To: crossfire@ifi.uio.no, peterm@soda.berkeley.edu Subject: Re: followup on crossedit whines Status: RO Actually, what would be nice is for crossedit to display the 'arch' name in addition to the visible name. That would make it much easier. Several different archetypes share the same name (like grass and grass_only are both called grass). It would be nice to click on one and see that the archetype is actually called grass_only. As it is now, I think the only way to find it out is via the dump command. --Mark From crossfire-request Sat Apr 16 00:19:51 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be (vm1.ulg.ac.be [139.165.32.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 16 Apr 1994 00:19:48 +0200 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Sat, 16 Apr 94 00:18:40 +0200 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA20977; Sat, 16 Apr 94 00:19:38 +0200 Date: Sat, 16 Apr 94 00:19:38 +0200 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9404152219.AA20977@montefiore.ulg.ac.be> To: crossfire@ifi.uio.no Subject: Re: Binary standards for images and sounds Status: RO A few words about the sounds... IMHO, the binary transfer for the sound files should be used as a last resort only. Yes, keep this feature available in the protocol, but I hope that most clients won't use it. There are several reasons for that: - Different players may like to customize the sounds for different events in the game. The server (during the game) should only send the events names or numbers, not the sound file name. Thus every player would be allowed to have a table that binds a sound name to every event. This table could be built from X resources, .INI file, or anything that suits the OS of the client. Naturally, there should be default entries in this table (taken from the server when the game starts), but we must allow for customization. - Most sound files are huge. It will save a lot of time and bandwidth if they are already on the client machine when the game starts. When the game starts, the server sends the default values for the table. These are event numbers or names followed by a sound name. If the file is not available at the client side (and not overriden by user's customization), then the client will ask for it. But not necessarily using an internal protocol... - The current implementation of the sounds in CrossFire uses the rplay library. This library provides automatic sound file fetching if a sound file could not be found in the local server. If this feature is available (I understand that some clients won't use rplay), it should be used... And it has some advantages over an internal protocol: it is handled by another process so it won't slow down the game, the rplay daemon can get the file from several rplay servers (and one of them could have a faster net connection than between the CrossFire client and server), it keeps the sounds in a temporary cache, etc. - The latest release of rplay (in beta at the time of this writing) supports various sound file formats: .au, .aiff, .wav, ... at 8, 11, 22, 44 KHz, mono or stereo. If a player can have CD-quality sound on his machine, he will certainly want to use it instead of the 8 KHz mono sounds. No problem if the files are local and referenced through an event table, but we will loose this advantage if the CrossFire protocol wants to use fixed file names or, even worst, directly sends its low-quality sound files no matter what the client wants. Most of these ideas also apply to the images. Why not have a reference table for the images, so that one client may be able to use different pictures for some objects, and only use the ones provided by the server if there is no picture available locally (on the client side) for one object? Well, actually the images don't need to be as easy to customize as the sounds should be. It's easy to change a sound because each sound can be played regardless of the others. This is not the case with the images: I don't want to have a Chinese dragon with the head of a beholder, etc. Anyway, the important thing is that we should allow for easy customization on both sides (client and server). BTW, this makes one more point in favor of a binary protocol which uses reference numbers in dynamic tables instead of ASCII commands and file names... :-) -Raphael From crossfire-request Fri Apr 15 23:53:18 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 Apr 1994 23:53:16 +0200 Received: (peterm@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id OAA13941 for crossfire@ifi.uio.no; Fri, 15 Apr 1994 14:53:06 -0700 Date: Fri, 15 Apr 1994 14:53:06 -0700 From: Peter Mardahl Message-Id: <199404152153.OAA13941@soda.berkeley.edu> To: crossfire@ifi.uio.no Subject: followup on crossedit whines Status: RO Turns out crossedit is fine. This is what had me confused: a very cleverly hidden exit: It was very hard to discern from a regular stones: arch exit name stones slaying forest face pstone_3.111 color_fg brown sp 14 x 29 y 10 is_animated 0 end Map makers, do not do such things. Hide exits UNDER things, don't make them impossible for another map editor to come find and fix if necessary. the only way to tell this was an exit was to examine it using the attr window of crossedit, or to look directly at the map file. Regards, PeterM From crossfire-request Fri Apr 15 19:36:18 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 19:36:16 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA07873; Fri, 15 Apr 94 13:35:54 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA09642; Fri, 15 Apr 94 13:32:07 -0400 Date: Fri, 15 Apr 94 13:32:07 -0400 From: "Carl Edman" Message-Id: <9404151732.AA09642@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: cheating & LOS Reply-To: cedman@Princeton.EDU Status: RO From: Philip Brown > It costs the server extra time vs the full transmission method. > > Full transmission just says: > > Check all squares that have changed , in vicinity of player, and > send. > > This is a constant order of calculation. But squares virtually never change. Well, you may break through fake walls or destroy doors, but apart from that almost all squares are constant. I do not understand what you mean here. > With precalculated LOS... I think you may hav to do som extra > handling on the server. I'm not sure you can automatically say > ONLY... > > "send squares in vicinity of player that have changed in that update, > and are in line of sight". > > AHA! Now I remember. It also has to keep a per-player line-of-sight > map. This is so the server can send across stuff that just came into > view, reguardless of whether it actually changed, last update. > Likewise, it has to check and see if anything was visible last round, > but out-of-sight this round, and blank it if so. The client/server protocol does not have "rounds". Yes, the server has to keep LOS maps, both for computational efficiency and for the sake of the protocol. Whenever an item moves or changes, the server goes through the list of the LOS maps for all players and immediately sends ITEM commands to all the players for whom the item is in the LOS. When a player moves (or an item with effect on LOS is destroyed or created inside the players LOS) a new LOS map is created for the player. Then the server compares the old and the new LOS maps and sends a single MAP command for all the squares in the new LOS and not in the old and a single UNMAP for all the squares in the old LOS but not in the new. Then the old LOS map is discarded. That is the entire display code in a nutshell. There are no "updates". There are no "rounds". Everything happens instantly. And yes, it is true that the server has to keep a LOS map for each player. But it does not have to keep a map of "what the players screen looked last time" and constantly call update functions to draw a new screen, compare it with the old screen and then send adjustment commands. That is certainly more overhead than a single simple LOS map. > Aha. Which brings us to the point that your method has a slight hole > in it. You can't just "not transmit" blank spots. You hav to also > have an explicit "blank this spot" call. Apologies if you covered > this already. Yes, it was listed in the proposed protocol. It is called the UNMAP command and it is followed by a list of all coordinate pairs which went out of the line of sight. Carl Edman From crossfire-request Fri Apr 15 19:27:30 1994 Return-Path: Received: from cc.lut.fi (hevi@cc.lut.fi [157.24.15.37]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 19:27:29 +0200 Received: (from hevi@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id UAA14608; Fri, 15 Apr 1994 20:27:27 +0300 Date: Fri, 15 Apr 1994 20:27:26 +0300 (EETDST) From: Petri Heinil{ Subject: Re: Binary standards for images and sounds To: crossfire@ifi.uio.no In-Reply-To: <199404151312.GAA22661@soda.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 15 Apr 1994, Scott MacFiggen wrote: > Before you start putting the XPM format down anymore I suggest > you download the libary and read throught the docs, it should take > about 1/2 hour. XPM format can take both named colors AND rgb > colors. The fact that it can take named colors is a big bonus. > X is pretty smart when it comes to color maps, if it is given a named > color but can't allocate it then it can find a pretty good match. If > its given a rgb value, it will have a harder time of doing this. Dont > ask me why but its true. I was planning on using the XPM format for > another game that i am/was/maybe going to write and did a bit of research on > this. I'm starting to lose confidence in what you are saying since you > keep telling us how bad XPM is but have no experience with it. One note for rgb's in xpm's. When I wrote library for images and first I used xpm's as inserting and extracting format, I found that there is no way (without /usr/lib/rgb.txt) to get out RGB values from the xpm API without connection to the X server. I needed this for calculating color- distancies (normal-rgb), when unifying color set to one image. So I decide to use ppm format for the file. And use pbmplus package to conversion. -- The Page -- From crossfire-request Fri Apr 15 18:54:42 1994 Return-Path: Received: from mccaw.com (wombat.mccaw.com [192.135.191.118]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 18:54:22 +0200 Received: from nwestmail.entp.mccaw.com ([155.176.15.34]) by mccaw.com (4.1/SMI-4.1) id AA22306; Fri, 15 Apr 94 09:54:10 PDT Received: from axys69.nwest.mccaw.com by nwestmail.entp.mccaw.com (4.1/McCaw SUN-RMR Mailer, SMI-4.1) id AA13244; Fri, 15 Apr 94 09:54:07 PDT Received: from divac by axys69.nwest.mccaw.com (NX5.67d/NX3.0M, dpg hack 15oct93) id AA02006; Fri, 15 Apr 94 09:56:34 -0700 From: Jason Fosback Message-Id: <9404151656.AA02006@axys69.nwest.mccaw.com> Received: by divac.nwest.mccaw.com (NX5.67d/NX3.0X, dpg hack 20mar93) id AA06124; Fri, 15 Apr 94 09:57:27 -0700 Date: Fri, 15 Apr 94 09:57:27 -0700 Received: by NeXT.Mailer (1.100.RR) Received: by NeXT Mailer (1.100.RR) To: crossfire@ifi.uio.no Subject: Re: cheating & LOS Status: RO philb@cats.ucsc.edu: > I think I picked up the rest of Jason's post, about using > a "mask" > > He proposes , instead of sending new faces, sending > 11-word binary viewing mask (?), that would change when > neccessary. Each "word" would be 11 bits long , or > whatever the width of the screen. Actually, no; the mask at this point could just be a stream of ones and zeroes, representing on/off for given squares. If we have an 11x11 screen, it would take 121 bits to mask the entire screen. That translates to a 16-byte number (on the same line as the NEWMAP command) representing the screen. On an n x m screen, this means the total number of bytes (B) required is: B = ceil((n x m) / 8) "Carl Edman" : > The server does not tell the client what to draw when and where. It > tells the client what it sees. Where it sees nothing because it is > behind walls, it does not send map commands. The client knows for what > areas it has received map commands and it only displays those. Those > areas which are not mapped in, it can display whatever it wants and it > doesn't need any instructions for it. Okay, so the server gives the client exactly what it sees. Hmmm. So, does the client do an automatic SHIFT of the map? Let's forget LOS for the moment, and focus on what you're proposing. In a large, open area (such as Scorn), would you be transmitting the MAP command for all squares, or does the client do this implicit SHIFT? Okay, so now when we head north from the starting area toward the wall, the top area of the sreen in not visible; when the client does the implicit SHIFT, does it automatically assume the new area is *outside* the LOS, consequently leaving the area black? -jason ____________________________________________________________ Jason Fosback, Systems Engineer | No sir, I didn't like it --- Paradigm Systems Corp --- | -R&S Internet: jason_fosback@psca.com | Star Trek: NeXT mail: jason_fosback@psca.com | The NeXT Generation... From crossfire-request Fri Apr 15 18:54:12 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 Apr 1994 18:54:06 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id JAA06822 for crossfire@ifi.uio.no; Fri, 15 Apr 1994 09:54:04 -0700 From: Philip Brown Message-Id: <199404151654.JAA06822@soda.berkeley.edu> Subject: Re: cheating & LOS To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Fri, 15 Apr 1994 09:54:03 -0700 (PDT) In-Reply-To: <9404151217.AA08869@capitalist.princeton.edu> from "Carl Edman" at Apr 15, 94 08:17:07 am X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1157 Status: RO >>>>[From Carl Edman] > I guess that makes your method a bandwidth win, at the expense of > some server time. Why does this cost extra server time ? It costs the server extra time vs the full transmission method. Full transmission just says: Check all squares that have changed , in vicinity of player, and send. This is a constant order of calculation. With precalculated LOS... I think you may hav to do som extra handling on the server. I'm not sure you can automatically say ONLY... "send squares in vicinity of player that have changed in that update, and are in line of sight". AHA! Now I remember. It also has to keep a per-player line-of-sight map. This is so the server can send across stuff that just came into view, reguardless of whether it actually changed, last update. Likewise, it has to check and see if anything was visible last round, but out-of-sight this round, and blank it if so. Aha. Which brings us to the point that your method has a slight hole in it. You can't just "not transmit" blank spots. You hav to also have an explicit "blank this spot" call. Apologies if you covered this already. From crossfire-request Fri Apr 15 18:27:59 1994 Return-Path: Received: from po5.andrew.cmu.edu (PO5.ANDREW.CMU.EDU [128.2.10.105]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 18:27:42 +0200 Received: (from postman@localhost) by po5.andrew.cmu.edu (8.6.7/8.6.6) id MAA12963 for crossfire@ifi.uio.no; Fri, 15 Apr 1994 12:27:36 -0400 Received: via switchmail; Fri, 15 Apr 1994 12:27:36 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 15 Apr 1994 12:25:37 -0400 (EDT) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 15 Apr 1994 12:25:33 -0400 (EDT) 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; Fri, 15 Apr 1994 12:25:32 -0400 (EDT) Message-ID: Date: Fri, 15 Apr 1994 12:25:32 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: sync was Re: cheating In-Reply-To: <9404150335.AA08366@capitalist.princeton.edu> References: <9404150335.AA08366@capitalist.princeton.edu> Status: RO "Carl Edman" writes: > > 3) Without synchronisation people will scream, so your bi-directional > > pipe doesn't buy you much. If you can make 3 moves while only one > > screen update occurs you are going to find yourself in big trouble, > > usually when you can least handle it. > > No, _with_ sync they will scream. Or rather they will throw away the > protocol over slow lines in disgust when being killed the Nth time > because they were frozen. There is absolutely nothing more frustrating > than being unable to act. Only a bi-directional protocol will prevent > that (and use all of the limited available bandwidth instead of only > half of it like synchronized protocol). In practice, we have no idea which one it will be, but in practice, it is the server that synchronizes to the clients, not the other way around. E.g. the server will send a "have you updated the last 10 frames" and the client will respond yes when they have. Someone who is too slow just gets saved out and terminated by the server. Without sync, you have really big problems with events queuing up, and commands not being executed in the state people think they will be executed in. > > (Despite flooding my mailbox Carl, you have generated a > > valuable discussion on the client/server issues) > > Thank you. You see, I have to. There are all these people saying all > these wrong things and somebody has to spread the TRUTH. :-) I just > sometimes wish they'd beat up on each other instead of all of them on > me. I think the TRUTH is a relative thing; I believe we all have our own experiences which tell us how we think things should be done, and each person just keeps espousing the beliefs that they have. -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 Fri Apr 15 14:47:49 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 14:47:46 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA17194; Fri, 15 Apr 94 08:47:42 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA08891; Fri, 15 Apr 94 08:43:55 -0400 Date: Fri, 15 Apr 94 08:43:55 -0400 From: "Carl Edman" Message-Id: <9404151243.AA08891@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: Binary standards for images and sounds Reply-To: cedman@Princeton.EDU Status: RO From Mark Wedel : > Even without the XPM library, it probably would not be difficult to > write code to interpert and XPM library. The file I wrote to convert > many small programs to montage images (ie, a large XPM image) was not > that difficult, and handles the color information properly (ie, it > does not drop monochrome information). The only thing that the > xpmtopix program lacks is multiple character depth on input or > output. That could probably be added in without a lot of effort. You wrote the code, so I take your word for it. But did you have to use the Xpm library to do the parsing for you, or did you find it possible to do it correctly by hand ? Would you be willing to write an XPM parser skeleton which does not use any extra libraries or X or UN*X specific system facilities for use in all the clients ? (No, that was not a rethorical question). If you are, I'd be very happy to make Xpm the image standard in the second draft of the protocol. > And while the data is not compact for XPM files, it is very > compressible. You (Carl) have been talking about how the links wil be > compressing the text information. The XPM data will be compressed > just as nicely. That's true. Compactness I thought ranked fairly low on the list of reasons for not using Xpm. > Also, clients probably should not be requesting new image files all > that often. I'm not so sure. Probably it would be a good idea to distribute the clients with some of the couple dozen most commonly used images (i.e. all that appear in the initial city) already pre-cached to make the first startup faster. > [A few more agreeable paragraphs deleted] > The XPM library source is quite small (less than a 100K tar gzipped > file). And for clients, much of that code would not be needed (ie, > reading from certain specific things or writing would not be needed.) 100 kBytes tarred and gzipped might be small compared to the server, but it may very well dwarf the size of source for most clients. I really do think that is too big to require the whole library to be included with every client. > I think you (Carl) are greatly over estimating how difficult it would > be to write a program that converts from XPM format. Maybe -- I'm always willing to take the word of the people who will do/did something for how easy it was going to be/was. But for example the fact that Xpm uses named colors (rather than RGB values) alone causes a lot of problems. Sure, X systems have the same standard list of colors (with some local extensions) and the library calls to handle it, so it is nothing to worry about. But what about other systems ? When I ported Emacs 19 to NeXTstep this fact added some 25 kBytes to the installation and that was just because NS already had a system of color naming and I just needed to convert from the X to the NS color table format. But what about systems which don't having any naming system at all ? Are you going to write the source the code for them ? Carl Edman From crossfire-request Fri Apr 15 14:28:53 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 14:28:52 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA14875; Fri, 15 Apr 94 08:28:46 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA08873; Fri, 15 Apr 94 08:24:58 -0400 Date: Fri, 15 Apr 94 08:24:58 -0400 From: "Carl Edman" Message-Id: <9404151224.AA08873@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: Binary standards for images and sounds Reply-To: cedman@Princeton.EDU Status: RO Philip Brown writes: > >>>>[From Carl Edman] > > >From Mark Wedel : > > This is not a direct reply to the image format posted by Carl, > > but a few notes. > > Well, that is well met because this not a direct reply to your > proposal. Rather I'd to express the opinion that Xpm seems to be > a very unsuited format for general distribution. While it does > look clever and cute it seems to be very far from being > compact. That may be a forgiveable failing, but it also looks > like a pretty heavy format to interpret properly in all cases. > Clients would have to write tons of code to handle it well. > And before someone suggests libXpm, using it would foreclose > the opportunity to run clients on anything but X systems which > I thought was one of the main reasons for the switch to > client/server. > > The code for Xpm is public! it's not like it's a commercial > library... the souce is all open!!! Porters would just hav to replace > a few X calls with their own windowing software stuff. I don't think > there are actually that many X calls in the library! The same is true of ghostscript (as I suggested in the paragraph you cut). Does that mean that we can use EPS ? That certainly would be a win for us who already have postscript on our system, but an extra burden for those who do not (like most X systems). Still, I think it would be to ask to much for everybody to install just to run a simple client. > It's not supposed to be "compact". It's supposed to be "thorough". Am I allowed to quote that back at you the next time you demand that only some items which are in the view of the user should be shown to the client ? Carl Edman From crossfire-request Fri Apr 15 14:20:59 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 14:20:58 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA14032; Fri, 15 Apr 94 08:20:53 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA08869; Fri, 15 Apr 94 08:17:07 -0400 Date: Fri, 15 Apr 94 08:17:07 -0400 From: "Carl Edman" Message-Id: <9404151217.AA08869@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no (Crossfire Mailing List) Subject: Re: cheating & LOS Reply-To: cedman@Princeton.EDU Status: RO From Philip Brown : >>>>[From Carl Edman] > The server does not tell the client what to draw when and where. > It tells the client what it sees. Where it sees nothing > because it is behind walls, it does not send map commands. The > client knows for what areas it has received map commands and it > only displays those. Those areas which are not mapped in, it > can display whatever it wants and it doesn't need any > instructions for it. > > Ahhhhh. I see. I don't think you explicitly stated that somewhers > before :-) Forgive me for not being clearer. I'll post a second draft in a few days and try to explain this better. > [although the server DOES "tell the client what to draw an > when". you're just fiddling with semantics :-)] Certainly it does ultimately for most clients. But I think the protocol should work at a higher level of abstraction. For example, the SMTP protocol doesn't tell the receiver: Here a few characters, show them in this order to this user when he or she logs in the next time. Instead the protocol says here is a complete mail message, do whatever it is to do with mail messages -- even if that ultimately results in the same output in many situations. On the other hand the VT100 protocol is just a series of commands to be executed immediately. I think that is the primary difference between different positions here. Some people argue for a protocol like e.g. SMTP which assumes and allows some understanding of the sent data by the client, like SMTP. Others demand a protocol which is just a series of instructions to a relatively dumb client, like VT100. > I guess that makes your method a bandwidth win, at the expense of > some server time. Why does this cost extra server time ? Carl Edman From crossfire-request Fri Apr 15 08:36: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, 15 Apr 1994 08:36:52 +0200 Received: (philb@localhost) by soda.berkeley.edu (8.6.8/PHILMAIL-1.10) id XAA21599 for crossfire@ifi.uio.no; Thu, 14 Apr 1994 23:36:43 -0700 From: Philip Brown Message-Id: <199404150636.XAA21599@soda.berkeley.edu> Subject: Re: cheating & LOS To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Thu, 14 Apr 1994 23:36:41 -0700 (PDT) In-Reply-To: <9404150352.AA08384@capitalist.princeton.edu> from "Carl Edman" at Apr 14, 94 11:52:41 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1469 Status: RO >>>>[From Carl Edman] The server does not tell the client what to draw when and where. It tells the client what it sees. Where it sees nothing because it is behind walls, it does not send map commands. The client knows for what areas it has received map commands and it only displays those. Those areas which are not mapped in, it can display whatever it wants and it doesn't need any instructions for it. Ahhhhh. I see. I don't think you explicitly stated that somewhers before :-) [although the server DOES "tell the client what to draw an when". you're just fiddling with semantics :-)] I guess that makes your method a bandwidth win, at the expense of some server time. BTW, you are a very strange person. Less than an hour ago you attacked the proposal in email for telling the client what items are in plain view. You claimed that obviously I was just trying to make it "easy" for players. Now you criticize the protocol for not telling the client what is located behind solid walls. Is there any consistency to this ? Certainly. If you ignore cheating, it doesn't make it easy for players, abnd makes it easier for server programmers :-) [As with www, it is MUCH more important to have a 100% solid server. There are many clients... (lynx, mosaic, chimera, www-for-next, ....), Each have their bugs. That's to be expected. But if the server is messed up, everyone loses.] From crossfire-request Fri Apr 15 05:39:52 1994 Return-Path: Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 15 Apr 1994 05:39:45 +0200 Received: from cedman.remote.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA04638; Thu, 14 Apr 94 23:39:39 -0400 Received: by capitalist.princeton.edu (NX5.67e/1.113) id AA08366; Thu, 14 Apr 94 23:35:52 -0400 Date: Thu, 14 Apr 94 23:35:52 -0400 From: "Carl Edman" Message-Id: <9404150335.AA08366@capitalist.princeton.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: cheating Reply-To: cedman@Princeton.EDU Status: RO From "Rupert G. Goldie" writes: > It is worth worrying about for several reasons: > > 1) You can easily get way more than 20 monsters. Worst case is 120 in > an empty area full of monsters. 40-50 wouldn't be an unreasonable > number to expect. That's correct. > 2) LOS isn't relevant in a mostly open area. The gnolls don't have to > be in a line. If they are in a mass and you kill one lots will move. No. Not unless they decide to start dancing around in circles. Killing one monster opens up one space. Only a monster further away will walk into it (no point for a monster which is already next to you). That opens up one space further away from you. One monster will walk into from even further away, a.s.o. until the edge of the visibile area i.e. five or six monsters. That is the maximum number which can gain in proximity by your killing one monster. > 3) Without synchronisation people will scream, so your bi-directional > pipe doesn't buy you much. If you can make 3 moves while only one > screen update occurs you are going to find yourself in big trouble, > usually when you can least handle it. No, _with_ sync they will scream. Or rather they will throw away the protocol over slow lines in disgust when being killed the Nth time because they were frozen. There is absolutely nothing more frustrating than being unable to act. Only a bi-directional protocol will prevent that (and use all of the limited available bandwidth instead of only half of it like synchronized protocol). > 4) When there are lots of monsters there will probably also be lots > of spells flying about. As a cone move across the screen do you want > to update every object each time ? You don't update "each object every time". You only update an object when it changes or enters the LOS after being outside the LOS. That happens fairly rarely. Yes, when you fight a dozen dragons and they all breath at you at the same time you'll have a real problem over a slow link. Of course that problem is only half as big as that which you would have in a simple 'graphical' protocol which some here have supported which not only has to send drawing commands for all the fireball components (much like the proposed protocol does), but also has to painstakingly sending _redrawing_ commands for everything below the dragon breath after it disappears (something which the proposed protocol doesn't have to do). But still, I'm open to suggestions for a special non-item-based command to describe dragon breath and the like. > 5) With all those spells monsters will be dying and dropping items. No big deal. Monster dies and three or four item commands are sent. That's all. And in contrast to the graphical protocol ideas, we don't have to send redrawing commands every time a monster walks over some of those items. > 6) This situation (confronting a horde of monsters) is the time you > least want to be hit by latency. I would much rather have latency > when I examine an object then when I'm fighting a large number of > spell casting monsters. Well, then isn't it fortunate that the same protocol which serves you best in one situation also does the best in the other (in addition to having real conceptual integrity) ? > (Despite flooding my mailbox Carl, you have generated a > valuable discussion on the client/server issues) Thank you. You see, I have to. There are all these people saying all these wrong things and somebody has to spread the TRUTH. :-) I just sometimes wish they'd beat up on each other instead of all of them on me. Carl Edman From frankj Sun Apr 17 02:46:49 1994 Subject: Crossfire 0.90.5 announcement To: crossfire-announce@ifi.uio.no Date: Sun, 17 Apr 1994 02:46:49 +0200 (MET DST) From: Mark Wedel X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1267 Status: RO There are three separate tar archives in the Crossfire 0.90.5 distribution. crossfire-0.90.5.tar.gz contains the actual program code, as well as premade archetype, bitmaps, and xpm files. crossfire-0.90.5-maps.tar.gz contains all the maps. The changes from the previous map distribution are mostly small, but if you plan on writing new maps or changing existing maps, you should get this file. crossfire-0.90.5-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. There are many changes in this version of crossfire, look at the CHANGES file for a complete list. AVAILABILITY: Crossfire is avaible on the following ftp sites ftp.ifi.uio.no:/pub/crossfire (129.240.64.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 From owner-crossfire Sun Apr 17 02:46:52 1994 Return-Path: Received: from bera.ifi.uio.no (2037@bera.ifi.uio.no [129.240.80.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sun, 17 Apr 1994 02:46:52 +0200 Received: (from frankj@localhost) by bera.ifi.uio.no ; Sun, 17 Apr 1994 02:46:51 +0200 Message-Id: <199404170046.14508.bera.ifi.uio.no@ifi.uio.no> Subject: Crossfire 0.90.5 announcement To: crossfire-announce@ifi.uio.no Date: Sun, 17 Apr 1994 02:46:49 +0200 (MET DST) From: Mark Wedel X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1266 Status: RO There are three separate tar archives in the Crossfire 0.90.5 distribution. crossfire-0.90.5.tar.gz contains the actual program code, as well as premade archetype, bitmaps, and xpm files. crossfire-0.90.5-maps.tar.gz contains all the maps. The changes from the previous map distribution are mostly small, but if you plan on writing new maps or changing existing maps, you should get this file. crossfire-0.90.5-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. There are many changes in this version of crossfire, look at the CHANGES file for a complete list. AVAILABILITY: Crossfire is avaible on the following ftp sites ftp.ifi.uio.no:/pub/crossfire (129.240.64.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