From crossfire-request Mon Jan 31 06:21:35 1994 Return-Path: Received: from corpse.ecst.csuchico.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Mon, 31 Jan 1994 06:21:34 +0100 Received: from localhost (tvangod@localhost) by corpse.ecst.csuchico.edu (8.6.4/8.6.4) id VAA11114; Sun, 30 Jan 1994 21:21:18 -0800 From: Tyler Van Gorder Message-Id: <199401310521.VAA11114@corpse.ecst.csuchico.edu> Subject: Re: Patches, ftp, new releases. To: master@rahul.net (Mark Wedel) Date: Sun, 30 Jan 1994 21:21:18 -0800 (PST) Cc: crossfire@ifi.uio.no In-Reply-To: <199401310452.AA26389@bolero.rahul.net> from "Mark Wedel" at Jan 30, 94 08:52:47 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: 1424 Status: RO > > I will make new releases based on how long since the last release, how > severe any bugs fixed since the last release were, and just how many > general features have been added. I hardly see that version 0.91 or > 0.92 needs to be the client server version. It is probably true that the > sooner it is done, the better, but provided that major changes are not > made to the source before the release of the client server version, I > don't think it will be that much more difficult to create the client > server version. > > I will probably release a new version in the next couple weeks, assuming > most of the major bugs are worked out. This give a hopefully stable > version to develope from, as well as note the various changes. > I do see one problem, in that the version Frank recently made available was worked on in parallel with the version that comes with crossedit-.7 The chico server we are running here was modified from the source that came with crossedit. The Berkeley server, scotch, is also running from more or less the same source. The differences from that code and the code that Frank released are large. If you are going to release a new version, I suppose we would want to merge the two versions before a release....this is a LARGE project, and I am wondering if it would be a better use of time to just move to client/server before the next release? Tyler. tvangod@ecst.csuchico.edu From crossfire-request Mon Jan 31 06:19:03 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Mon, 31 Jan 1994 06:18:51 +0100 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA21998; Mon, 31 Jan 1994 16:18:40 +1100 Date: Mon, 31 Jan 1994 16:18:40 +1100 From: "Rupert G. Goldie" Message-Id: <199401310518.AA21998@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no Subject: Comments on this weekend's flood of crossfire mail Status: RO Well it's good to see such a resurgence of interest in Crossfire ! Let's see if I can summarise and gratuitously editorialise. o we need a maintainer - Looks like Mark Wedel (master@rahul.net) is it. o we need a new release - Everyone agrees that we need a new release to renew interest in Crossfire, but we have a spread of views over what should be in the new release. The main bone of contention seems to be over whether or not to make the client/server split right now. My feeling on the matter is that we should get 0.90.0 out the door as quickly as possible - just fold in some patches which have already been tested and fix bugs. While we do that we _design_ the client/server interface. That way we at least get a version of Crossfire that people can play out quickly. o client binaries - The topic of a client/server split brought the question of authenication for clients. One option is to go the Netrek way and have binaries available for lots of platforms. Editorial opinion - let's just forget it for now, there are already lots of ways to cheat. o what the client should do - There is probably still plenty of discussion to go on the details of what the client should be doing, but the main consenus is that it should just be doing graphics. There are some strident calls for revamping the interface, using Xaw, etc. This is probably a good time to do it. Go have a look at the X code in crossfire if you're not convinced about using toolkits 8) o we need a site - We do have an ftp site, but we don't have a machine with accounts for people to develop from. I think we will have better control if Mark acts as coordinator and collects patches from people, plus as Crossfire is an X based game it will be a pain in the butt to debug remotely over slow links. o maps - Hopefully with a new release we will see some new maps being created (especially since crossedit is now so cool), but we will also face the task of picking the good maps and fixing the poor ones. o Crossfire is a great game - the volume of mail over the last few days shows how much people like Crossfire and want it to continue to develop. I hope we can continue to make people waste valuable work and study time playing this game 8-) Rupert -- Rupert G. Goldie, Research Scientist rgg@aaii.oz.au Australian Artificial Intelligence Institute /\/\|| 1 Grattan Street, Melbourne, Australia From crossfire-request Mon Jan 31 05:52:53 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Mon, 31 Jan 1994 05:52:49 +0100 Received: by bolero.rahul.net id AA26389 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Sun, 30 Jan 1994 20:52:47 -0800 Date: Sun, 30 Jan 1994 20:52:47 -0800 From: Mark Wedel Message-Id: <199401310452.AA26389@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Patches, ftp, new releases. Status: RO If you have a patch, mail to me (master@rahul.net) is probably the best and easiest method for me. Try to put something like 'crossfire patch' as the subject. ftp.world.net is best for me (the one in Norway can be a bit slow.) Anyone know how the mirrors work? IF I put something on ftp.world.net, will it eventually move back to the primary site in Norway, and then propagate out to the other sites? Putting the code on the Norway sites isn't that difficult for me, just a little slower. I will make new releases based on how long since the last release, how severe any bugs fixed since the last release were, and just how many general features have been added. I hardly see that version 0.91 or 0.92 needs to be the client server version. It is probably true that the sooner it is done, the better, but provided that major changes are not made to the source before the release of the client server version, I don't think it will be that much more difficult to create the client server version. I will probably release a new version in the next couple weeks, assuming most of the major bugs are worked out. This give a hopefully stable version to develope from, as well as note the various changes. Someone has taken over the maintenance of the mailing list, or Frank has resumed those duties, correct? If you plan on doing major developmental work to crossfire, let me know. I'll collect and organize this information, letting people working on the same area know the other people working on that area of code. Unless there are objections, about every week or two, I will post this information to the mailing list, so others have some idea what is being done, and can mail ideas directly to these developers. Mark Wedel master@rahul.net From crossfire-request Mon Jan 31 05:45:15 1994 Return-Path: Received: from amisk.cs.ualberta.ca by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Mon, 31 Jan 1994 05:45:10 +0100 Received: from gsb011.cs.ualberta.ca by amisk.cs.ualberta.ca id <138698>; Sun, 30 Jan 1994 21:44:57 -0700 Subject: Re: Client binaries From: Papp Denis Richard To: dyessww@Eng.Auburn.EDU (William W. Dyess) Date: Sun, 30 Jan 1994 21:44:45 -0700 Cc: crossfire@ifi.uio.no In-Reply-To: from "William W. Dyess" at Jan 30, 94 11:34:41 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1112 Message-Id: <94Jan30.214457-0700.138698@amisk.cs.ualberta.ca> Status: RO > One thing that helps in both cases though is the strong dislike of those > who are found using borgs. Someone found using a borg would be banned > from that server, his friends wouldn't talk to him, his girlfriend would > break up with him, and his dog would pee on his leg. > > As long as coding continues on Crossfire and it is made clear that borgs > are frowned upon, there shouldn't be a problem. > Crossfire Borgs??? I dont think anyone could relaly benefit from that. Well in a way its a lazy way to get xps, but I can probably do better than any borg anyone writes. Unless its got some amazing AI - and that woudl be a waste of time to write that. I'd say the closest we'll come to borgs in crossfire is 'spoilers' - but I dont see anything tremendously wrong with people who want to look at the code to figure out how somnething works. Unless there are 'cheat keys' of course -- Denis Papp dpapp@cs.ualberta.ca dpapp@amisk.cs.ualberta.ca "So, umm.. like uh... is that some sort of cow?" -- Benny Markapooza From crossfire-request Mon Jan 31 05:42:32 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Mon, 31 Jan 1994 05:42:25 +0100 Received: by bolero.rahul.net id AA26004 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Sun, 30 Jan 1994 20:42:16 -0800 Date: Sun, 30 Jan 1994 20:42:16 -0800 From: Mark Wedel Message-Id: <199401310442.AA26004@bolero.rahul.net> To: explorer@iastate.edu, kivinen@joker.cs.hut.fi Subject: Re: Is there anybody there? Cc: crossfire@ifi.uio.no Status: RO 'Unfortunately', as moderator, I do live in the USA, which means that for each official release I make, someone else (outside of USA), would need to add the appropriate code and put it on the ftp sites. Sounds like a bit of a pain to me. Mark Wedel master@rahul.net From master@rahul.net Mon Jan 31 05:39:27 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id ; Mon, 31 Jan 1994 05:39:25 +0100 Received: by bolero.rahul.net id AA25790 (5.67a8/IDA-1.5); Sun, 30 Jan 1994 20:39:22 -0800 Date: Sun, 30 Jan 1994 20:39:22 -0800 From: Mark Wedel Message-Id: <199401310439.AA25790@bolero.rahul.net> To: crossfire@ifi.uio.no, frankj@ifi.uio.no Subject: Re: site for project building Status: RO I've gathered the source off of the ftp site. As for using the Dec alpha for a base site: It looks like it is pretty easy to get the guest accounts (provided you live in the USA). But I don't know how good those guest accounts will be, for the reason that there is a pretty long use policy and restrictions. Under those guidelines, crossfire could pretty much be terminated. I am not really sure how good a semi public site would be in any case. People with limited access to the network, or who would prefer to work on local machines, might not find a public site of much use. Also, if it did get a lot of use, you could then have the problem with several people wanting to check out the same file out once to make changes. It also makes it more difficult for me to find out what changes have been made. Individual project groups (client developement, for example) might want to get something like that for their own use, so everyone in the group can work on that single cause together in a better fashion. But we'll have to wait for the developement of those groups to have a better idea. Mark Wedel master@rahul.net From crossfire-request Mon Jan 31 05:30:33 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Mon, 31 Jan 1994 05:30:27 +0100 Received: by bolero.rahul.net id AA25397 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Sun, 30 Jan 1994 20:30:22 -0800 Date: Sun, 30 Jan 1994 20:30:22 -0800 From: Mark Wedel Message-Id: <199401310430.AA25397@bolero.rahul.net> To: crossfire@ifi.uio.no, philb@soda.berkeley.edu Subject: Re: Client/server.. Status: RO I think a good first step would be for someone to write up a document describing what should be done in the client, and what is done in the server. Plus an adstract of how the two communicate. It seems to me which toolkit is used in the client is fairly unimportant, as you could have several clients, with the different ones using different graphic libraries. The text input code right now is pretty nasty. Since input is gained via X events, the routine that handles the events gathers the text, and depending on what a variable is set to, then calls the appropriate, depending what that variable is set to. This makes pausing durin a scroll more difficult, as another value needs to be added to that variable, with the event routine needing to know what function to call with the variable set. Also, when we do move to client server, each client program could also have a unique layout, so the standard crossfire layout could exist (what we have right now), as well as other ones which have different windows for input and output, etc. Mark Wedel master@rahul.net From crossfire-request Mon Jan 31 00:01:26 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Mon, 31 Jan 1994 00:01:24 +0100 Received: from localhost (philb@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id PAA16582 for crossfire@ifi.uio.no; Sun, 30 Jan 1994 15:01:22 -0800 From: Philip Brown Message-Id: <199401302301.PAA16582@soda.berkeley.edu> Subject: Re: Client/server.. To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Sun, 30 Jan 1994 15:01:21 -0800 (PST) In-Reply-To: <199401302236.OAA02574@corpse.ecst.csuchico.edu> from "Tyler Van Gorder" at Jan 30, 94 02:36:32 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 853 Status: RO >>>>[From Tyler Van Gorder] I think maybe it would be a good idea to have the server send messages to an message buffer, then the client could have the capability to have "more" button or scrolling back through the older text. Using Xaw and XawTextWidget, you automatically get scrolling. server should just send messages to the client as-is. It's up to the client where or not to buffer them, how much scrollback to save, etc, etc, etc. I have talked with Eric Melhaff (i probably spelled that wrong :> sorry Eric.) and he seems to think that no real advantage is gained by splitting things up into different processes. What do you all think? I would probably agree with Eric. Although if you want to get fancy, the best way would be to split into _threads_ But that's not generaly usable by all machines ;-> From crossfire-request Sun Jan 30 23:36:41 1994 Return-Path: Received: from corpse.ecst.csuchico.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sun, 30 Jan 1994 23:36:39 +0100 Received: from localhost (tvangod@localhost) by corpse.ecst.csuchico.edu (8.6.4/8.6.4) id OAA02574 for crossfire@ifi.uio.no; Sun, 30 Jan 1994 14:36:32 -0800 From: Tyler Van Gorder Message-Id: <199401302236.OAA02574@corpse.ecst.csuchico.edu> Subject: Client/server.. To: crossfire@ifi.uio.no Date: Sun, 30 Jan 1994 14:36:32 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2529 Status: RO Ok, its cool that we are finally getting some traffic on this mailing list. I have more or less read all of the recent posts and have a few thoughts. On the security thing, I think maybe it would be best to concentrate on getting a working client/server. Keeping in mind that we may (probably) will want to add a level of security down the road. Basically, lets put the security stuff on the back burner for now and instead focus on other things, like moving all display oriented stuff to the client. I've given this quite a bit of thought and as mentioned earlier about objects: The best way to approach this would be to distribute a standard set of objects with the client and then build into the client a way to download objects that aren't in the standard set. (Note : by "object" I am referring to an object as seen on the client side, with only display oriented stuff it in. This is not just pixmaps, but color, name, animation speed, etc) I believe we should definately rework how the info window is used. Currently, It is used for both input and output. Perhaps we should move towards having an input line and a then a message window where text based stuff is displayed, very similar to netrek. This would then make having to type "'" everytime we wish to do an extended command. As for the message window itself, a lot of players here have complained about having stuff scroll off the screen before they could read the things. (A good example is a player's spell list.) I think maybe it would be a good idea to have the server send messages to an message buffer, then the client could have the capability to have "more" button or scrolling back through the older text. We have discussed here at Chico about making the server side work in a similar fashion to netrek, in that it would have one process updating maps/objects, then have a process for each connected player that would have a shared memory segment with the process keeping track of things. Actually, we already have a very simple version of this sort of thing here at chico. It accepts a client and sits there waiting for a couple of things, nothing major by any means. I have talked with Eric Melhaff (i probably spelled that wrong :> sorry Eric.) and he seems to think that no real advantage is gained by splitting things up into different processes. What do you all think? Anyway, I seem to have written a book here :> hopefully, we can start to get some input on this stuff and start coding it :> Tyler. tvangod@ecst.csuchico.edu From crossfire-request Sun Jan 30 21:30:39 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sun, 30 Jan 1994 21:30:36 +0100 Received: from localhost (philb@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id MAA03877 for crossfire@ifi.uio.no; Sun, 30 Jan 1994 12:30:33 -0800 From: Philip Brown Message-Id: <199401302030.MAA03877@soda.berkeley.edu> Subject: Re: Client binaries To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Sun, 30 Jan 1994 12:30:32 -0800 (PST) In-Reply-To: from "Eric A. Anderson" at Jan 30, 94 10:44:48 am X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 3158 Status: RO >>>>[From Eric A. Anderson] Well, a client can be designed to make it easier to turn, make your shots more accurate, etc. Similar problems will occur in crossfire once you give the client more information. For example, I'd like to see more of the map at a time. No problem, just make the window on my client larger and keep around more information. Won't work. The server will only be updating what you can see. On the the hand, I think it's a FEATURE that you could scroll around and see roughly where you've been. An auto-mapping feature. I could design auto runaway, indeed, I could design auto-play. Want to collect a kagillion experience, find yourself a generator, wait in front of it. Kill the monster, wait, kill, wait, kill, etc. No person is likely to have the patience to do this, but I can set up a computer to do it for hours -- Lots of free experience, all I need is the create food spell. Whereas otherwise, really bored people just do it themselves. i don't think this is any big deal. On the other hand, if it isn't implemented already, you should not get ANY experience points from killing monsters that are 10 levels below you. That is the problem, even if you don't give the client any information they shouldn't have, the clients can still do more intelligent things than the X thing that is forced onto people's screens in the current implementation. The current implementation isn't intelligent enough anyways. that's part of the problem ;-) Yea, I do have shared libraries, but I've also used machines which don't, and the option of just use shared libraries may not be available for those machines. For example decstations running ultrix 4.x Tough noogies. Don't go for the "8086 compatibility" goal. This assumes that we've also gone to client server at the same time. I believe that client server will fix the problem of clients dying. I do not believe that Xaw will fix the problem of clients dying. No. but using Xaw under the current server-based paradigm would be absurd. In fact, I am not sure it is feasible at all. here was a place down inside of Santo Diago, that you got to past the giant beholder down into a hole, where the second room you got into was packed with monsters. This room by itself could make my machine relatively slow. Now it was doing both the display and the monsters, but still, there were hundreds of monsters that had to take actions more than once a second. Crossfire's basic model may make it very hard to support lots of people. Excellent point. It's all a matter of how far you let a monster's 'vision' be, I think. I haven't checked in the source, but i believe that a limited-range of vision is already implemented in some fashion. It should be augmented by having low-level monsters, and most kinds of other monsters, having really short-range vision. Then the problem will fix itself, I think. (of course, if some map-maker is stupid enough to put 100 "clairevoyant mind-flayers, speed 10" in a room together, nothing you can do :-) From crossfire-request Sun Jan 30 21:19:06 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sun, 30 Jan 1994 21:19:02 +0100 Received: from localhost (philb@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id MAA03074 for crossfire@ifi.uio.no; Sun, 30 Jan 1994 12:18:59 -0800 From: Philip Brown Message-Id: <199401302018.MAA03074@soda.berkeley.edu> Subject: Re: site for project building To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Sun, 30 Jan 1994 12:18:57 -0800 (PST) In-Reply-To: <19940130145752.931.drott.ifi.uio.no@ifi.uio.no> from "Frank Tore Johansen" at Jan 30, 94 03:57:50 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 3910 Status: RO >>>>[From Frank Tore Johansen] Note that I haven't given this careful thought yet..this might not be the most efficient way of doing things. And other people probably have more experience than me on this way of programming. I haven't had more experience at that sort of thing.. but I WAS planning to do the client/server port, so I have given it a lot of thought, although with a few other people. About client/server: I don't think a total rewrite is neccessary, only a "few" central functions needs to be changed. True.. technically, a "total" rewrite is not neccessary at all. However, 1) almost everything to do with displaying a player has to be scrapped. 2) you have to define the new protocol, and implement it in the server. 3) the code isn't QUITE as modular as all that, with respect to displaying a player. It mainly is, but I seem to recall there are a few nasties that would have to be tracked down and changed for a client/server model. [Frank continues..] I'm afraid the project might stagnate if we try to do too much at once. Let's just concentrate on making a common release first, to spawn some more interest in the game. Since there seem to be a lot of volunteers, we COULD have a two-tier development team. It would take a lot of professionalism. People could work on specific bugs (and ALWAYS use RCS).. patches to the display routines would be ignored by the client/server group. But patches to the main server code could be hand-diffed in. This would of course mean that nothing TOO drastic could be done to the old code, or that big mods have to be added in a modular way. Like most others (it seems), I vote for letting the client handle only display-specific things, like scrolling inventory, clicking on objects, etc. No need to transfer the whole objects to the client, only how they look, what color they have, their animations and a few flags (and probably a few things that I forgot). You really really really have to transfer animations to the client. Animations are a MAJOR drain on the server. There's no reason that the server should handle animations. It should only handle whether animating objects are visible or not. Other people were voting on the client having "read-only" access to game objects. That does not preclude having the client know about object types, etc. The main issues that came up were "what to do about pixmaps?" If you distribute a static set of pixmaps with the client, then adding new objects becomes nasty. On the other hand, if you DON'T, you have the problem that the -pix option has: a really long startup time loading ALL the pixmaps. What I and Eric Mehlhaff eventually agreed upon (I think :-) was that clients should come with an agreed-upon standard set of pixmaps. The client should ALSO have the capability to add more pixmaps on the fly. This could either take place at game start, or on a new map, or on demand, depending on how flexible we wanted to be about new pixmaps, custom player pixmaps, etc. [This makes for "interesting" startup pixmap negotiation, but is quite doable] All objects on a map should probably have a flag for each client, which is set if the object has been created, moved, or if it has changed in any way since the given client was told how (and where) it looked. Why not just tell all player clients in the vicinity [within 10 squares or whatever] anything that has changed since last update? I don't think the special caching for each client is going to be much of a gain, if at all. How would you implement this? Have "Boolean move_for_client[100]" in every single object? You SURE this would be worth the hassle/memory? It would be nice to have the client do more in the way of map caching. But actually implementing anything nice gets ugly fast. [In other words, you can't really, IMO] From crossfire-request Sun Jan 30 20:42:43 1994 Return-Path: Received: from halcyon.com by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sun, 30 Jan 1994 20:42:41 +0100 Received: by halcyon.com id AA16654 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Sun, 30 Jan 1994 11:42:34 -0800 Date: Sun, 30 Jan 1994 11:42:34 -0800 From: Jonathan Roy Message-Id: <199401301942.AA16654@halcyon.com> To: crossfire@ifi.uio.no, eanders+@CMU.EDU, quinet@montefiore.ulg.ac.be Subject: Re: Client binaries Status: RO Netrek seems to have a working system. They have precompiled binaries with RSA code to authroize themselves. These binaries can be sent anyplace out of the US. The source code for the clients is availible, but the RSA code is only availile seperatly by request, and only to those in teh US. Certain keys are used in sending out the by-request RSA code, so that if someone seems to be absuing it, you just expire that RSA key. The binaries have their own keys, and have default expirations of 3-4 months. This way you don't have to upgrade or even compile new patch level for all systems (binaries for Paradise usually run 5-6 patchs before a new binary is posted), but you can always compile it yourself if you like. Netrek server have the choice of allowing or disallowing non RSA clients. Paradise allow all to play, which is good for people who can't use RSA. (Using term, or whatever). MOst Bronco sites only allow RSA clients. So... That system seems reasonable. Pre-compiled RSA clients, source for non-RSA, and the server decides to allow non-RSA or now... From crossfire-request Sun Jan 30 19:43:31 1994 Return-Path: Received: from edison.eng.auburn.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sun, 30 Jan 1994 19:43:30 +0100 Received: from lab15.eng.auburn.edu (lab15.eng.auburn.edu [131.204.11.15]) by edison.eng.auburn.edu (8.6.4/8.6.4) with ESMTP id MAA15516 for ; Sun, 30 Jan 1994 12:43:28 -0600 Received: from localhost (dyessww@localhost) by lab15.eng.auburn.edu (8.6.4/8.6.4) id MAA17737; Sun, 30 Jan 1994 12:43:30 -0600 Date: Sun, 30 Jan 1994 12:34:41 -0600 (CST) From: "William W. Dyess" Subject: Re: Client binaries To: crossfire@ifi.uio.no In-Reply-To: <9401301745.AA17177@montefiore.ulg.ac.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO > I'm sure that we will find a way to prevent such things. But we must work on > the client and server *now*. Once we have a fully-working game, we can deal > with this kind of problems. I do a lot of client coding for Paradise (Netrek II). We don't use RSA or any other protection scheme. So far, it hasn't been a problem. Most of the people with the ability to code have been sucked into the development process. Netrek, on the other hand, has become a static game. There is nothing left to do except build better borgs. Hence, they need protection. One thing that helps in both cases though is the strong dislike of those who are found using borgs. Someone found using a borg would be banned from that server, his friends wouldn't talk to him, his girlfriend would break up with him, and his dog would pee on his leg. As long as coding continues on Crossfire and it is made clear that borgs are frowned upon, there shouldn't be a problem. --Bill From crossfire-request Sun Jan 30 18:46:00 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sun, 30 Jan 1994 18:45:58 +0100 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Sun, 30 Jan 94 18:44:31 +0100 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA17177; Sun, 30 Jan 94 18:45:41 +0100 Date: Sun, 30 Jan 94 18:45:41 +0100 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9401301745.AA17177@montefiore.ulg.ac.be> To: crossfire@ifi.uio.no, eanders+@CMU.EDU Subject: Re: Client binaries Status: RO > From: "Eric A. Anderson" > > quinet@montefiore.ulg.ac.be (Raphael Quinet) writes: > > I'd rather distribute the sources for the client, forget about encryption > > and never do "sensible" things in the client... Let's use the client for > > display-related operations only (inventory, animations, map, ...) > The problem is not what the developers do in the client, the problem > is what people who recieve the code do to the client. > Don't forget one thing: at present time, the first players are the developpers themselves. How do you want to keep an algorithm "secret" if people all around the world are working on it? Oh yes, you can always have only one person working on the encryption algorithm and have him send only the object files for all known systems in the universe to everybody else. And he will need to update his files after each major change in the client code. Very easy, isn't it? > That is the problem, even if you don't give the client any information > they shouldn't have, the clients can still do more intelligent things > than the X thing that is forced onto people's screens in the current > implementation. > I'm sure that we will find a way to prevent such things. But we must work on the client and server *now*. Once we have a fully-working game, we can deal with this kind of problems. -Raphael From crossfire-request Sun Jan 30 16:45:44 1994 Return-Path: Received: from po5.andrew.cmu.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sun, 30 Jan 1994 16:45:43 +0100 Received: from localhost (postman@localhost) by po5.andrew.cmu.edu (8.6.4/8.6.4) id KAA03757 for crossfire@ifi.uio.no; Sun, 30 Jan 1994 10:45:38 -0500 Received: via switchmail; Sun, 30 Jan 1994 10:45:36 -0500 (EST) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Sun, 30 Jan 1994 10:44:54 -0500 (EST) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Sun, 30 Jan 1994 10:44:49 -0500 (EST) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.madhatter.ws.cc.cmu.edu.sun4c.411 via MS.5.6.madhatter.ws.cc.cmu.edu.sun4c_411; Sun, 30 Jan 1994 10:44:48 -0500 (EST) Message-ID: Date: Sun, 30 Jan 1994 10:44:48 -0500 (EST) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: Client binaries In-Reply-To: <9401301157.AA16471@montefiore.ulg.ac.be> References: <9401301157.AA16471@montefiore.ulg.ac.be> Status: RO quinet@montefiore.ulg.ac.be (Raphael Quinet) writes: > I'd rather distribute the sources for the client, forget about encryption > and never do "sensible" things in the client... Let's use the client for > display-related operations only (inventory, animations, map, ...) The problem is not what the developers do in the client, the problem is what people who recieve the code do to the client. I will explain the problems by drawing the parallel of netrek. netrek is a game where you fly a ship around shooting at other people(oversimplification, but basically true). All the client recieves is locations of people and the shots. Well, a client can be designed to make it easier to turn, make your shots more accurate, etc. Similar problems will occur in crossfire once you give the client more information. For example, I'd like to see more of the map at a time. No problem, just make the window on my client larger and keep around more information. No more of the obnoxious problem of not being able to see around corners once I've been there. I could design auto runaway, indeed, I could design auto-play. Want to collect a kagillion experience, find yourself a generator, wait in front of it. Kill the monster, wait, kill, wait, kill, etc. No person is likely to have the patience to do this, but I can set up a computer to do it for hours -- Lots of free experience, all I need is the create food spell. That is the problem, even if you don't give the client any information they shouldn't have, the clients can still do more intelligent things than the X thing that is forced onto people's screens in the current implementation. -- More responses: Philip Brown writes: > >>>>[From Eric A. Anderson] > > Philip Brown writes: > > The display code is disgusting. It should be rewritten in Xaw. > > Why Xaw? The main thing Xaw seems to gain is a huge increase in the > size of the binaries. > > I don't think you have shared libraries. It doesn't add that much. Yea, I do have shared libraries, but I've also used machines which don't, and the option of just use shared libraries may not be available for those machines. For example decstations running ultrix 4.x > Moreover, the problem with losing a display wouldn't be helped by > moving to Xaw, you still have to longjmp out of an error handler > > So what? Problem fixed, because then the CLIENT dies, but the server can > go on happily, after it has handled the socket error. This assumes that we've also gone to client server at the same time. I believe that client server will fix the problem of clients dying. I do not believe that Xaw will fix the problem of clients dying. > -- Now client server would fix a lot of the problems, but it would be > nice to have a stable version of the game out there so that people > don't lose interest. > > People already have started to lose interest. crossfire has a lousy, > buggy user interface. People are losing interest because there have been no public improvements to crossfire in many months. As soon as improvements start coming out, people will be willing to start playing again. > 89.3 or whatever is stable enough for those purposes, as long as it has > the fix for losing the display. The code needs rewriting before it will > be "stable". I agree that some amount of reorganization is neccesary. However, we also need to consider how easy it will be to support 10-100 people on one server. Someone compared crossfire to muds. The main difference from what I've seen is that crossfire has many more computer controlled monsters. Indeed, all of the generators guarentee this. Hence, every time you add another person, you greatly increase the load on the server. There was a place down inside of Santo Diago, that you got to past the giant beholder down into a hole, where the second room you got into was packed with monsters. This room by itself could make my machine relatively slow. Now it was doing both the display and the monsters, but still, there were hundreds of monsters that had to take actions more than once a second. Crossfire's basic model may make it very hard to support lots of people. --- So there you go, those are my thoughts. I'm willing to work on the server and the client some, but I think we should watch how much we jump for in a single hop. We can start doing client server internally in the server by just acting as though the two parts are separate, and passing the information between the two parts with a function call. Then the move to client server will be much easier. -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 Sun Jan 30 15:57:53 1994 Return-Path: Received: from drott.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sun, 30 Jan 1994 15:57:53 +0100 From: Frank Tore Johansen Received: from localhost by drott.ifi.uio.no ; Sun, 30 Jan 1994 15:57:52 +0100 Message-Id: <19940130145752.931.drott.ifi.uio.no@ifi.uio.no> Subject: Re: site for project building To: crossfire@ifi.uio.no Date: Sun, 30 Jan 1994 15:57:50 +0100 (MET) In-Reply-To: <199401290421.AA03681@bolero.rahul.net> from "Mark Wedel" at Jan 28, 94 08:21:35 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2202 Status: RO > I just wonder if any porting would be needed to get it to work properly > on a Dec Alpha. I've compiled 0.90-a successfully on Dec Alpha, only had to fix some minor bugs to make it work. 0.90-a is at the ftp-site, please make patches against only that source. This means that those who have made changes, will have to get 0.90-a, then add their changes to that version, and then make a diff against their changed 0.90-a. If you break your changes up in separate patches for different features/bugfixes, you'll make the job of coordinating all the different patches much easier. I don't know how Mark Wedel wants to receive patches, email or ftp. Probably best to put them in the incoming directory and to mail him. We should probably define a "team", put all those names in a file somewhere, and add "(C) 1994 Crossfire Developement Team" to all those "(C) 1992 (me)" (how is this done with nethack?). About client/server: I don't think a total rewrite is neccessary, only a "few" central functions needs to be changed. I'm afraid the project might stagnate if we try to do too much at once. Let's just concentrate on making a common release first, to spawn some more interest in the game. Those who haven't, take a look at the TODO file (mostly unchanged since 0.89.2). There are lots of improvements that have nothing to do with client/server, which will still need to be done. Like most others (it seems), I vote for letting the client handle only display-specific things, like scrolling inventory, clicking on objects, etc. No need to transfer the whole objects to the client, only how they look, what color they have, their animations and a few flags (and probably a few things that I forgot). All objects on a map should probably have a flag for each client, which is set if the object has been created, moved, or if it has changed in any way since the given client was told how (and where) it looked. Note that I haven't given this careful thought yet..this might not be the most efficient way of doing things. And other people probably have more experience than me on this way of programming. Hmm, enough ramblings for now...the more I ramble the less gets done 8) -Frank. From frankj Sun Jan 30 15:57:50 1994 Subject: Re: site for project building To: crossfire@ifi.uio.no Date: Sun, 30 Jan 1994 15:57:50 +0100 (MET) In-Reply-To: <199401290421.AA03681@bolero.rahul.net> from "Mark Wedel" at Jan 28, 94 08:21:35 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2203 Status: RO > I just wonder if any porting would be needed to get it to work properly > on a Dec Alpha. I've compiled 0.90-a successfully on Dec Alpha, only had to fix some minor bugs to make it work. 0.90-a is at the ftp-site, please make patches against only that source. This means that those who have made changes, will have to get 0.90-a, then add their changes to that version, and then make a diff against their changed 0.90-a. If you break your changes up in separate patches for different features/bugfixes, you'll make the job of coordinating all the different patches much easier. I don't know how Mark Wedel wants to receive patches, email or ftp. Probably best to put them in the incoming directory and to mail him. We should probably define a "team", put all those names in a file somewhere, and add "(C) 1994 Crossfire Developement Team" to all those "(C) 1992 (me)" (how is this done with nethack?). About client/server: I don't think a total rewrite is neccessary, only a "few" central functions needs to be changed. I'm afraid the project might stagnate if we try to do too much at once. Let's just concentrate on making a common release first, to spawn some more interest in the game. Those who haven't, take a look at the TODO file (mostly unchanged since 0.89.2). There are lots of improvements that have nothing to do with client/server, which will still need to be done. Like most others (it seems), I vote for letting the client handle only display-specific things, like scrolling inventory, clicking on objects, etc. No need to transfer the whole objects to the client, only how they look, what color they have, their animations and a few flags (and probably a few things that I forgot). All objects on a map should probably have a flag for each client, which is set if the object has been created, moved, or if it has changed in any way since the given client was told how (and where) it looked. Note that I haven't given this careful thought yet..this might not be the most efficient way of doing things. And other people probably have more experience than me on this way of programming. Hmm, enough ramblings for now...the more I ramble the less gets done 8) -Frank. From crossfire-request Sun Jan 30 12:57:46 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sun, 30 Jan 1994 12:57:44 +0100 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Sun, 30 Jan 94 12:56:27 +0100 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA16471; Sun, 30 Jan 94 12:57:37 +0100 Date: Sun, 30 Jan 94 12:57:37 +0100 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9401301157.AA16471@montefiore.ulg.ac.be> To: crossfire@ifi.uio.no Subject: Client binaries Status: RO If we use some kind of password protection for client-server interactions, we need to distribute the clients as binaries. Right, but is this really a good thing? If we follow this approach, we need to provide binaries for different workstations with different versions of their operating system and different realeases of X11. That would lead to something like this: - three to four versions for SUNs running various version of SunOS and Solaris - two for DECs running Ultrix - one or two for HPs running HP-UX - at least one for IBMs running AIX - maybe even one or two for i386 and i486 PCs running Linux - ... Now let's imagine that we will need to compile every version of the client after each change made to the client. Is this really rational? I'd rather distribute the sources for the client, forget about encryption and never do "sensible" things in the client... Let's use the client for display-related operations only (inventory, animations, map, ...) -Raphael From crossfire-request Sun Jan 30 02:22:15 1994 Return-Path: Received: from cardhu.cs.hut.fi by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sun, 30 Jan 1994 02:22:15 +0100 Received: by cardhu.cs.hut.fi id AA23131 (5.65c8/HUTCS-C 1.3 for crossfire@ifi.uio.no); Sun, 30 Jan 1994 03:22:10 +0200 Date: Sun, 30 Jan 1994 03:22:10 +0200 Message-Id: <199401300122.AA23131@cardhu.cs.hut.fi> From: Tero Kivinen To: "Michael Graff" Cc: crossfire@ifi.uio.no Subject: Re: Is there anybody there? In-Reply-To: <9401282257.AA11679@tigger.cc.iastate.edu> References: <8hGJnP200Zk2NBi=sE@andrew.cmu.edu> <9401282257.AA11679@tigger.cc.iastate.edu> Organization: Helsinki University of Technology/Lifelong Learning Institute Dipoli Status: RO "Michael Graff" writes: > The problem with this is that the RSA code used to both generate and use the > keys cannot be exported from the USA, and any binaries made with this sort of > thing cannot be exported either. But the code can be imported to USA and so can the binaries (I think). So we only need to create and store that code outside of USA (Norway, Finland etc) :-) > Export laws suck, but they are laws... :( Luckily such laws exists only in USA... -- 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 Sun Jan 30 02:13:54 1994 Return-Path: Received: from cardhu.cs.hut.fi by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sun, 30 Jan 1994 02:13:53 +0100 Received: by cardhu.cs.hut.fi id AA23073 (5.65c8/HUTCS-C 1.3 for crossfire@ifi.uio.no); Sun, 30 Jan 1994 03:13:46 +0200 Date: Sun, 30 Jan 1994 03:13:46 +0200 Message-Id: <199401300113.AA23073@cardhu.cs.hut.fi> From: Tero Kivinen To: Philip Brown Cc: crossfire@ifi.uio.no Subject: Client-server stuffs In-Reply-To: <199401282012.MAA14353@soda.berkeley.edu> References: <199401280943.AA11810@bolero.rahul.net> <199401282012.MAA14353@soda.berkeley.edu> Organization: Helsinki University of Technology/Lifelong Learning Institute Dipoli Status: RO Philip Brown writes: > This portal stuff requires that we EITHER > have unique initial-server keys in player names > OR > require that a character be already created, with the same password, on > "server2". > Hmmm... perhaps the second method would be the best way to go.. > Although if we are nice, we would allow "creating" the character right > then, if it did not already exist.. Trouble is, what if you just happened > to choose a name on your home server that is used everywhere else? We would need unique names and ids for every server in this method anyway (to find the server passwd etc), so we could create the name in the form of "Conan the Bararian from Deniria", where Deniria is the name of home world where the character Conan come from. When player starts to play he connects to his home world and asks to load character and server finds that character isn't in his home world it would send a query to all servers asking who got the most resent version of character (each transation from one server to another would increase the version counter by one, so we could detect situations where server1 have lost the ack from server2 and the character was duplicated). If no character is found then the server holding character information must be down. If character dies in the another world that server tries to inform the home server about death, but until it can do that it keeps info about the died character, so it can respond if home server tries to load that character. In other words loading character would be like this: 1) client connects to home server 2) home server finds the basic information about character (does it exists, verifies the password etc). 3) If character is in home world, load it and start playing. 4) Send query to net about character and ask where it can be found (this query would be like directed broadcast, every server sending query to all its neigbours which aren't mentioned in the queries path (like path in news articles)). [This phase can be optimized by sending direct request to the server where the character have been seen most resently] 5) Collect responses from other servers for some time (say 60 seconds or something). 6) Take the most resent version of character from responses and inform client to connect there, or if the most resent version is died then inform the player about it. If there were other versions of character tell those servers to destroy them. Saving would save the player to the server where it currenlty is and send a notice to home server that player have been saved here. -- 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 Sun Jan 30 00:04:34 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sun, 30 Jan 1994 00:04:32 +0100 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Sun, 30 Jan 94 00:03:20 +0100 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA14679; Sun, 30 Jan 94 00:04:30 +0100 Date: Sun, 30 Jan 94 00:04:30 +0100 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9401292304.AA14679@montefiore.ulg.ac.be> To: crossfire@ifi.uio.no, philb@soda.berkeley.edu Subject: Re: crossfire source ramblings... Status: RO I agree with Philip's point of view. Xaw is a good thing if (and only if) it is handled only by the client. This could quickly overload the server if it had to manage all widgets. But if the client is in charge of the display, this should be fine. Here are several reasons to switch to Xaw: - It's standard and it's free (Philip already said that). - If you want to use Motif instead of the Athena Widgets, you don't need to change a lot of code. Most widgets are used in the same way in both systems. - Several widgets are well-known and provide a common user interface. - The way to control the widgets through X resources is standard too, and they understand the EditRes protocol, so it's easy to play with the widgets. - Your code gets cleaner. - I used to hate widgets before I really started working with them. Once you get accustomed to the programming style, your programs become more modular and therefore easier to debug. There are also some disadvantages, but nothing really serious: - If you don't use shared libraries, the size of the binaries will certainly increase. Solution: use shared libraries! - The program gets slower because it has more things to cope with. Solution: do all display-related operation in the client. -Raphael From crossfire-request Sat Jan 29 20:56:56 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 29 Jan 1994 20:56:54 +0100 Received: from localhost (philb@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id LAA01251 for crossfire@ifi.uio.no; Sat, 29 Jan 1994 11:56:52 -0800 From: Philip Brown Message-Id: <199401291956.LAA01251@soda.berkeley.edu> Subject: Re: crossfire source ramblings... To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Sat, 29 Jan 1994 11:56:50 -0800 (PST) In-Reply-To: from "Eric A. Anderson" at Jan 29, 94 12:17:53 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1217 Status: RO >>>>[From Eric A. Anderson] Philip Brown writes: > The display code is disgusting. It should be rewritten in Xaw. Why Xaw? The main thing Xaw seems to gain is a huge increase in the size of the binaries. I don't think you have shared libraries. It doesn't add that much. Why Xaw? It's standard. It's free. I'm thinking of Xaw over Xt mainly because it has a TextWidget. Of course, once you have an xaw version, it's fairly easy to convert it to Motif, too.. etc, etc, etc. Moreover, the problem with losing a display wouldn't be helped by moving to Xaw, you still have to longjmp out of an error handler So what? Problem fixed, because then the CLIENT dies, but the server can go on happily, after it has handled the socket error. -- Now client server would fix a lot of the problems, but it would be nice to have a stable version of the game out there so that people don't lose interest. People already have started to lose interest. crossfire has a lousy, buggy user interface. 89.3 or whatever is stable enough for those purposes, as long as it has the fix for losing the display. The code needs rewriting before it will be "stable". From crossfire-request Sat Jan 29 12:05:41 1994 Return-Path: Received: from cardhu.cs.hut.fi by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sat, 29 Jan 1994 12:05:41 +0100 Received: by cardhu.cs.hut.fi id AA16396 (5.65c8/HUTCS-C 1.3 for crossfire@ifi.uio.no (Crossfire Mailing List)); Sat, 29 Jan 1994 13:05:39 +0200 Date: Sat, 29 Jan 1994 13:05:39 +0200 From: Kalle Korpela Message-Id: <199401291105.AA16396@cardhu.cs.hut.fi> To: crossfire@ifi.uio.no (Crossfire Mailing List) Cc: Philip Brown Subject: site for project building In-Reply-To: <199401290408.UAA13958@soda.berkeley.edu> References: <199401290408.UAA13958@soda.berkeley.edu> Status: RO Philip Brown writes: >A while ago, dec was giving away free accounts on a dec alpha, as a >demo/research thing. I still have one of those accounts, for example. >But the point being, if you asked nicely, maybe dec would sponsor this >project by giving group members free accounts on the dec. The problem is, that they don't give access to people outside USA - at least to us in Finland, because of some US laws aimed at the old Eastern-block countries. I suppose that goes to a lot of us Europeans... >The machine name is axposf.pa.dec.com //kako From crossfire-request Sat Jan 29 05:42:01 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 29 Jan 1994 05:41:59 +0100 Received: from localhost (philb@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id UAA16315; Fri, 28 Jan 1994 20:41:52 -0800 From: Philip Brown Message-Id: <199401290441.UAA16315@soda.berkeley.edu> Subject: crossfire source ramblings... To: master@rahul.net (Mark Wedel) Date: Fri, 28 Jan 1994 20:41:51 -0800 (PST) Cc: crossfire@ifi.uio.no In-Reply-To: <199401290414.AA03337@bolero.rahul.net> from "Mark Wedel" at Jan 28, 94 08:14:33 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 898 Status: RO >>>>[From Mark Wedel] One good first step would be to move the display to the client, and see how much the load on the server is reduced. If we can get crossfire servers to be fairly lean on a cpu basis, then having a client that does most everything is not needed. [source reorganization suggestion too..] Mark.. PLEASE.. stop putting off what has to be done eventually. The best and most productive way to "reorganize the source" right now, is to rewrite the damn thing as client/server. The display code is disgusting. It should be rewritten in Xaw. Yes, it will be much longer until the next public release of the code. On the other hand, things will be a WHOLE lot cleaner. The handling of losing an X display [and/or xkill on a window] is a prime sourse of nastiness in the code, and i think contributes to an eventual server crash after it happens a few times. From crossfire-request Sat Jan 29 05:21:40 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sat, 29 Jan 1994 05:21:38 +0100 Received: by bolero.rahul.net id AA03681 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Fri, 28 Jan 1994 20:21:35 -0800 Date: Fri, 28 Jan 1994 20:21:35 -0800 From: Mark Wedel Message-Id: <199401290421.AA03681@bolero.rahul.net> To: crossfire@ifi.uio.no, philb@soda.berkeley.edu Subject: Re: site for project building Status: RO I'll mail that address and see what type of response I get. Worst case would be no, so nothing to lose, a lot to gain. I just wonder if any porting would be needed to get it to work properly on a Dec Alpha. Mark Wedel master@rahul.net From crossfire-request Sat Jan 29 05:21:36 1994 Return-Path: Received: from gyda.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 29 Jan 1994 05:21:35 +0100 Received: from bolero.rahul.net by gyda.ifi.uio.no ; Sat, 29 Jan 1994 05:21:32 +0100 Received: by bolero.rahul.net id AA03565 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Fri, 28 Jan 1994 20:19:58 -0800 Date: Fri, 28 Jan 1994 20:19:58 -0800 From: Mark Wedel Message-Id: <199401290419.AA03565@bolero.rahul.net> To: crossfire@ifi.uio.no, peterm@soda.berkeley.edu Subject: Re: Crossfire's Rebirth. Status: RO I will probably take over full crossfire control this Sunday or Monday. At that time, I will start putting in patches and working more on the new code. As a first request, I would prefer the first week or so to be actual bug fixes, and not new features or additions. Also, if possible, it would be nice if you could see if the bug was fixed in crossfire-0.90, and if possible, make your diff file relative to that. Some people have volunteered to run Purify on the source. That would also be very nice to do. Once the version is stable, I will release as version, and then be more willing to take patches that actually add features. Something that needs to be done, but as far as I know never was, is keeping the good maps and getting rid of the bad ones. The first step would be a document defining what is a good map, and what is a bad map. This might be good for people with a non programming background could do. Mark Wedel master@rahul.net From crossfire-request Sat Jan 29 05:14:48 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sat, 29 Jan 1994 05:14:46 +0100 Received: by bolero.rahul.net id AA03337 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Fri, 28 Jan 1994 20:14:33 -0800 Date: Fri, 28 Jan 1994 20:14:33 -0800 From: Mark Wedel Message-Id: <199401290414.AA03337@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Re: Is there anybody there? Status: RO But the problem with precompiled binaries is that distribution becomes more complicated. Now, you need to have binaries for many of those systems (I bet just the active people on the mailing list would require about half a dozen binaires), plus size and storage on systems. Even different operating systems may start to make things break One good first step would be to move the display to the client, and see how much the load on the server is reduced. If we can get crossfire servers to be fairly lean on a cpu basis, then having a client that does most everything is not needed. Also, re orginizing some of the source to make it quicker (and the expense of some memory) may be useful. Many people might be willing to make that trade, as long as the memory cost is not too high and the speed improvements gained are significant. Mark Wedel master@rahul.net From crossfire-request Sat Jan 29 05:08:52 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 29 Jan 1994 05:08:51 +0100 Received: from localhost (philb@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id UAA13958 for crossfire@ifi.uio.no; Fri, 28 Jan 1994 20:08:48 -0800 From: Philip Brown Message-Id: <199401290408.UAA13958@soda.berkeley.edu> Subject: site for project building To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Fri, 28 Jan 1994 20:08:47 -0800 (PST) X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 370 Status: RO A while ago, dec was giving away free accounts on a dec alpha, as a demo/research thing. I still have one of those accounts, for example. But the point being, if you asked nicely, maybe dec would sponsor this project by giving group members free accounts on the dec. The machine name is axposf.pa.dec.com A diplomatic spokeperson might send mail to root there. Mark? From crossfire-request Sat Jan 29 02:40:28 1994 Return-Path: Received: from po2.andrew.cmu.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 29 Jan 1994 02:40:27 +0100 Received: from localhost (postman@localhost) by po2.andrew.cmu.edu (8.6.4/8.6.4) id UAA01106 for crossfire@ifi.uio.no; Fri, 28 Jan 1994 20:40:21 -0500 Received: via switchmail; Fri, 28 Jan 1994 20:40:20 -0500 (EST) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 28 Jan 1994 20:16:39 -0500 (EST) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 28 Jan 1994 20:16:36 -0500 (EST) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.madhatter.ws.cc.cmu.edu.sun4c.411 via MS.5.6.madhatter.ws.cc.cmu.edu.sun4c_411; Fri, 28 Jan 1994 20:16:35 -0500 (EST) Message-ID: Date: Fri, 28 Jan 1994 20:16:36 -0500 (EST) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: Is there anybody there? In-Reply-To: <9401282257.AA11679@tigger.cc.iastate.edu> References: <9401282257.AA11679@tigger.cc.iastate.edu> Status: RO "Michael Graff" writes: > >The problem with clients being smarter is a classic one, the netrek > >solution is to have binaries distributed which have a "key" to connect > >them to servers so that the client and servers can mutually > >authenticate. There's not a lot you can do about this problem other > >than that solution. > > The problem with this is that the RSA code used to both generate and use the > keys cannot be exported from the USA, and any binaries made with this sort of > thing cannot be exported either. > > Export laws suck, but they are laws... :( So don't do it with RSA. Since you are doing security through obscurity anyway(someone could just disassemble the code), you perform any algorithm you want to on the i.p. addr of the server, and the packet it sends you and then you send the information back. The server just checks to make sure you did what you were supposed to have done. -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 Sat Jan 29 00:49:13 1994 Return-Path: Received: from gyda.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Sat, 29 Jan 1994 00:49:12 +0100 Received: from soda.berkeley.edu by gyda.ifi.uio.no ; Sat, 29 Jan 1994 00:49:10 +0100 Received: from localhost (peterm@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id PAA16365; Fri, 28 Jan 1994 15:47:00 -0800 Date: Fri, 28 Jan 1994 15:47:00 -0800 From: Peter Mardahl Message-Id: <199401282347.PAA16365@soda.berkeley.edu> To: master@rahul.net Subject: Re: Crossfire's Rebirth. Cc: crossfire@ifi.uio.no Status: RO I'd like to be on the coding team. MOre specifically, I'd like to contribute a lot of code I've already done. I am willing to install it myself into a server. Things I've done: Runes: magical traps which can contain ANY spell. Step on a rune, and you set off the spell. Adds a whole new dimension to dungeon design, and their visibility is tunable.` New spells: I and others at soda have added a great many new spells. Some of these are very cool, such as comet and counterspell. You can now magically support a friend who's in hand-to-hand combat by nullifying the magic thrown at him. Consolidation of spell parameters: I've moved control of many spell parameters from compiled in arrays and from the archetypes into a readable-on-the-fly spell parameter file. One of the biggest problems facing crossfire is tuning the spells. SOme spells are far too sexy while others are useless. Having this file readable on the fly will make the DM's task of balancing much easier--the dm may now change dynamically things like how much damage a spell does, how many sp it costs, its duration, and its level. New archetypes: (for runes and the new spells) The soda crew has generated a lot of new archetypes, in support of our other changes and to add new monsters to the game. Some of these are liches and spectres--powerful undead creatures. corpse.ecst.csuchico.edu (tvangod's server) has most of this stuff already--the chico people and we at Berkeley have communicated a bit. They don't have the latest rune code, the version they have is a bit buggy, I think. Regards, Peter Mardahl peterm@soda.berkeley.edu From crossfire-request Fri Jan 28 23:57:08 1994 Return-Path: Received: from tigger.cc.iastate.edu by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 23:57:07 +0100 Received: by tigger.cc.iastate.edu with sendmail-5.65 id ; Fri, 28 Jan 1994 16:57:04 -0600 Message-Id: <9401282257.AA11679@tigger.cc.iastate.edu> To: "Eric A. Anderson" Cc: crossfire@ifi.uio.no Subject: Re: Is there anybody there? In-Reply-To: Your message of Fri, 28 Jan 1994 13:43:39 -0500. <8hGJnP200Zk2NBi=sE@andrew.cmu.edu> Date: Fri, 28 Jan 1994 16:57:03 CST From: "Michael Graff" Status: RO >The problem with clients being smarter is a classic one, the netrek >solution is to have binaries distributed which have a "key" to connect >them to servers so that the client and servers can mutually >authenticate. There's not a lot you can do about this problem other >than that solution. The problem with this is that the RSA code used to both generate and use the keys cannot be exported from the USA, and any binaries made with this sort of thing cannot be exported either. Export laws suck, but they are laws... :( --Michael -- Michael Graff Iowa State University Computation Center Project Vincent 215 Durham voice: (515) 294-4994 explorer@iastate.edu Ames, IA 50011 fax: (515) 294-1717 gg.mlg@isumvs.bitnet From crossfire-request Fri Jan 28 23:51:18 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 23:51:16 +0100 Received: by bolero.rahul.net id AA15323 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Fri, 28 Jan 1994 14:51:14 -0800 Date: Fri, 28 Jan 1994 14:51:14 -0800 From: Mark Wedel Message-Id: <199401282251.AA15323@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Crossfire's Rebirth. Status: RO With all the messages here, that is what is happening. Ftp access: I see no reason the present ftp sites could not be ftp.ifi.uio.no and ftp.world.net in the USA). This seemed to work in the past. Project teams: Once the team is assembled, I don't see any reason they can't keep in touch of each other via e-mail. I think that do to how spread out people are, if each person works on something semi individual instead of working as a group on one thing, it would be easier. That is to say, don't have 5 people work on adding identified items, maybe only one person does it, another works on cursed items, etc. Very large additions may need to be done as groups, but I am sure the tasks could be split up some. A common source working area would be good for the group teams. I think it would be best that after they finish work on whatever projects, diff files are made compared to the master source, instead of having the master source be what they are working on. If this was the case, then diff files would need to be applied to that code, or a lot of people would need access to it.. Mark Wedel master@rahul.net From crossfire-request Fri Jan 28 23:12:58 1994 Return-Path: Received: from sfi.santafe.edu by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 23:12:56 +0100 From: scott@santafe.edu Received: from coronado (coronado.santafe.edu) by sfi.santafe.edu (4.1/SMI-4.1) id AA19337; Fri, 28 Jan 94 15:18:36 MST Received: by coronado (4.1/SMI-4.1) id AA28903; Fri, 28 Jan 94 15:12:47 MST Date: Fri, 28 Jan 94 15:12:47 MST Message-Id: <9401282212.AA28903@coronado> To: Papp Denis Richard Cc: crossfire@ifi.uio.no Subject: Crossfire - hints In-Reply-To: Your message at 14:04:39 on Fri, 28 January 1994 References: <94Jan28.140455-0700.138919@amisk.cs.ualberta.ca> Status: RO >>>>> "Papp" == Papp Denis Richard writes: Papp> Big monsters. Compared toa troll say, how tough is a Titan? a trolls regenerate... they're a pain. the best trick with the standard maps and starting character is this: Get starting stats of at least 16 int and 12 strength and 7sp... then hit "n" and choose a mage as a characterand hit "d" to select it. go to the beginners, get the wand of medium fireall.... READY IT, but don't cast it. then hit tab to get a spell. You can not use 8sp to cast a medium fireball without using any of the wands charge. exit out lower right of the castle (town) and exit at the far right, head NW to santo dominion, take the ship to eeur, take the bottom ship to unnamed town, go to the prison.. raid all chests. the 4th row somtimes has a chest with an artifact (ie: dragon shield) you should have at least ac -3 after raiding this area. You should have at least a +2 weapon (if you are lucky) ok, go to the area with the doors to the "eyes" and open the door, cast a spell of medium fireball (you may kill one eye) hit + until it selects the WAND medium fireball, when the fireball starts to go away, run up and use the wand to zap a second fireball. You'll kill all the beholders and you'll be like level 4 (ie: ~5000 experience points)... :-) Next, leave this area.... and go to castle doom... that's upper left in the town, ship back home, (to eeur) and then down about 4 spots to castle doom.... go all the way around in here up until the giants... then leave. If you have money or stuff, go to a magic shop and get a wand of polymorph. ONLY POLYMORPH 0 CHARGE WANDS (it will give you things like wands of large fireball with 82 charges :-) ) well, this is a way to get a jumpstart on a new char in a newly created dungeon :-) ... level 5 in 5 minutes... HOHOHO :-) Papp> Colossus (do they exist?) A dragon? there is a huge @$$ demonlord in a hour on one of the islands (with an artifact weapon just inside as a teaser). in one place (I forgot the name) there is a large eye (forgot the name) and sometimes up to 3 potions in the room.. and you can simply run in and get them and run out. NOTICE: drop all + items as the beholder will cast spells of "cancellation" and take away from your weapons and armor. Papp> How do you beat Reapers if you dont have invulnerable to drain? I've *NEVER* found immune to drain and I've had amulets of prote and rings of protect and they still drain. i've polymorphed piles of 50 or more rings and wands and amulets and never found "immune" to drain. reapers suck. they take like 10% or 20% (somethinglike that) of your experience and when you have 300,000 experience, it really sucks to lose such a large amount of experience. Papp> We hav a level 13 and level 9 character, and nothing seems to be Papp> a tremendous challenge - well troll's arent that easy. And I Papp> was wondering if it would besafe for us to take on something big try the demon lord :-) titan can be killed with 2 people and one with a bonecrusher+3 titan doesn't offer anything that can't be obtained easier elsewhere. Scott From crossfire-request Fri Jan 28 22:05:23 1994 Return-Path: Received: from amisk.cs.ualberta.ca by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 22:05:11 +0100 Received: from cab010.cs.ualberta.ca by amisk.cs.ualberta.ca id <138919>; Fri, 28 Jan 1994 14:04:55 -0700 Subject: Crossfire - hints From: Papp Denis Richard To: crossfire@ifi.uio.no Date: Fri, 28 Jan 1994 14:04:39 -0700 X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 370 Message-Id: <94Jan28.140455-0700.138919@amisk.cs.ualberta.ca> Status: RO Big monsters. Compared toa troll say, how tough is a Titan? a Colossus (do they exist?) A dragon? How do you beat Reapers if you dont have invulnerable to drain? We hav a level 13 and level 9 character, and nothing seems to be a tremendous challenge - well troll's arent that easy. And I was wondering if it would besafe for us to take on something big -- From crossfire-request Fri Jan 28 22:51:25 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 22:51:23 +0100 Received: from localhost (philb@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id MAA14353; Fri, 28 Jan 1994 12:12:29 -0800 From: Philip Brown Message-Id: <199401282012.MAA14353@soda.berkeley.edu> Subject: Client-server stuffs To: master@rahul.net (Mark Wedel) Date: Fri, 28 Jan 1994 12:12:27 -0800 (PST) Cc: crossfire@ifi.uio.no In-Reply-To: <199401280943.AA11810@bolero.rahul.net> from "Mark Wedel" at Jan 28, 94 01:43:27 am X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 2202 Status: RO >>>>[From Mark Wedel] The server keeps track of all the data, including player data. The only purpose the client holds is to handle the drawing of data. Drawing of data, AND player interaction. You should make the client to allow interesting keymaps, plus pull up inventory windows, etc without draining the server processos.. In efect, "caching" inventory. That still doesn't make for "super-powers", because if you try to apply something not actually in your inventory, the server will get upset at you. about the only possibility I see for a 'bot is to have something that automatically dodges arrows. You are still limited by the server-defined movement rate, so you're probably still not going to be able to dodge lightning. and forget about ice storm. dodge code would more likely get you stuck in a corner, anyways! :-) An almost completely random side track: How to securely allow portals. ------------------------------ Player wanders over to a map that is actually on ANOTHER SERVER. * server1 pings server2 [accepted] * server1 gives server2 expected special "server key" * server1 uploads player character, (and EVERYTHING about player) to server2 (along with password) [and waits for accept signal] * server1 informs client to switch server * server1 waits for acknowledgement that new server information has been received by the client. * server1 moves player to backup file, but effectively, player is not there any more. ("dead", to that server) This of course is fairly net-intensive stuff, so admins shouldn't install a portal on a main road, for example :-/ But you could make it interesting. The client could show "Oh no! You are caught in a tornado!" animation while it waits :-) This portal stuff requires that we EITHER have unique initial-server keys in player names OR require that a character be already created, with the same password, on "server2". Hmmm... perhaps the second method would be the best way to go.. Although if we are nice, we would allow "creating" the character right then, if it did not already exist.. Trouble is, what if you just happened to choose a name on your home server that is used everywhere else? From crossfire-request Fri Jan 28 19:53:14 1994 Return-Path: Received: from pathogen.ecst.csuchico.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 19:53:12 +0100 Received: from localhost (tvangod@localhost) by pathogen.ecst.csuchico.edu (8.6.4/8.6.4) id KAA21339; Fri, 28 Jan 1994 10:52:23 -0800 From: Tyler Van Gorder Message-Id: <199401281852.KAA21339@pathogen.ecst.csuchico.edu> Subject: Re: Project team To: quinet@montefiore.ulg.ac.be (Raphael Quinet) Date: Fri, 28 Jan 1994 10:52:22 -0800 (PST) Cc: crossfire@ifi.uio.no In-Reply-To: <9401280959.AA04980@montefiore.ulg.ac.be> from "Raphael Quinet" at Jan 28, 94 10:59:41 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: 1689 Status: RO > > > If there are volunteers for the "Project team", as Frank said, we should > first have some way to know each other. There are several options: > > - Use the "crossfire" list and post a message saying "I'm a volunteer". > - Create another list and subsribe only if you are willing to offer serious > programming services. > - Send a mail to the maintainer, who will "manually" forward the message to > all other candidates. Tedious. > - Create a new "volunteers" directory on ftp.ifi.uio.no, where every > programmer would put a file named after his E-mail address. This file could > be empty or could contain a short message telling how much involved he wants > to be. > > Do you have other ideas? > > -Raphael > > ack! Where did all this mail come from???? :> ok, I maintain the local crossfire server at chico (aka corpse.ecst.csuchico.edu) Anyway, recently, myself and a few others here at chico and berkeley have been discussing rewritting most of the game to support client/server. Well, that has been put on the back burner for the time being, as I have found myself very very busy lately. :< But I do know of serveral people that are interested in working on the client/server protocols and code. I would also be interested on working on it, if i manage to free up some time. I think the first thing that needs to be done is to write up what protocols will be passed between the client and server. We also need to write up what structures will be used on the client side and which structues will be on the server side. Maybe we can post some thoughts on what these structures will look like to the mailing list? Tyler. tvangod@ecst.csuchico.edu From crossfire-request Fri Jan 28 19:45:12 1994 Return-Path: Received: from po5.andrew.cmu.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 19:45:04 +0100 Received: from localhost (postman@localhost) by po5.andrew.cmu.edu (8.6.4/8.6.4) id NAA18268 for crossfire@ifi.uio.no; Fri, 28 Jan 1994 13:44:51 -0500 Received: via switchmail; Fri, 28 Jan 1994 13:44:49 -0500 (EST) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 28 Jan 1994 13:43:48 -0500 (EST) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Fri, 28 Jan 1994 13:43:39 -0500 (EST) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.madhatter.ws.cc.cmu.edu.sun4c.411 via MS.5.6.madhatter.ws.cc.cmu.edu.sun4c_411; Fri, 28 Jan 1994 13:43:38 -0500 (EST) Message-ID: <8hGJnP200Zk2NBi=sE@andrew.cmu.edu> Date: Fri, 28 Jan 1994 13:43:39 -0500 (EST) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: Is there anybody there? In-Reply-To: <199401281412.AA17871@halcyon.com> References: <199401281412.AA17871@halcyon.com> Status: RO Jonathan Roy writes: > The server would simply say "display bitmap xxx at x,y" or something > like that... (I assume the server would simple send a map to the > client, and the client would have the bitmaps all stored locally. > Maybe.. :) ) > > That alone would help alot. X is a bear. This in particular wouldn't help at all because that command is precisely what the X calls do, if not more efficiently because with fonts, it can say "Here's the entire line". Now it would help if you let the client handle the changing bitmaps, and let the client cache most of the map (on a as provided by server basis.) -- UDP .vs. TCP I would vote for TCP, in general, unless you really understand network protocols, you'll get UDP stuff wrong, which means that you can easily swamp the network. Moreover, the overhead for TCP isn't particularily high, and the amount of savings in coding time is substantial. -- The problem with clients being smarter is a classic one, the netrek solution is to have binaries distributed which have a "key" to connect them to servers so that the client and servers can mutually authenticate. There's not a lot you can do about this problem other than that solution. -- Disk space and groups: I can provide space until late May(when I graduate), and I can add accounts. If someone else can offer a better deal, i.e. machine existing for longer, than I'd go with them. -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 coplex!dougc@uunet.uu.net Fri Jan 28 21:22:16 1994 Return-Path: Received: from relay2.UU.NET by ifi.uio.no with SMTP (8.6.4/ifi2.4) id ; Fri, 28 Jan 1994 21:22:14 +0100 Received: from coplex.coplex.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwavp29255; Fri, 28 Jan 94 15:21:38 -0500 Received: by coplex.coplex.com (Smail3.1.28.1 #8) id m0pPy6V-0009qTC; Fri, 28 Jan 94 13:39 EST Date: Fri, 28 Jan 1994 13:39:37 -0500 (EST) From: Doug Churchman Subject: Re: Is there anybody there? To: Jari Vanhala Cc: Nick Williams , crossfire@ifi.uio.no, frankj@ifi.uio.no, Raphael Quinet In-Reply-To: <199401281414.QAA03203@modeemi.modeemi.cs.tut.fi> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Unsubscribe From crossfire-request Fri Jan 28 16:37:54 1994 Return-Path: Received: from cardhu.cs.hut.fi by ifi.uio.no with SMTP (8.6.4/ifi2.4) id ; Fri, 28 Jan 1994 16:37:53 +0100 Received: by cardhu.cs.hut.fi id AA07237 (5.65c8/HUTCS-C 1.3); Fri, 28 Jan 1994 16:48:22 +0200 Date: Fri, 28 Jan 1994 16:48:22 +0200 Message-Id: <199401281448.AA07237@cardhu.cs.hut.fi> From: Tero Kivinen To: Frank Tore Johansen Cc: crossfire@ifi.uio.no Subject: Re: Is there anybody there? In-Reply-To: <19940128082629.29328.mimir.ifi.uio.no@ifi.uio.no> References: <19940128082629.29328.mimir.ifi.uio.no@ifi.uio.no> <9401280746.AA03788@montefiore.ulg.ac.be> Organization: Helsinki University of Technology/Lifelong Learning Institute Dipoli Status: RO Frank Tore Johansen writes: > My local version _still_ has that malloc bug...It's real nasty. Instead > of making the game crash, it puts crossfire strings among the X-variables > occasionally. Like changing the name of the window to "food", or something > similar... I will try to look that as soon as I can get the code with my on red zone memory allocator library (redzal). It will detect all access outside mallocated area, and almost all random memory access. I even found two malloc bugs from gcc with it. If you can tell as how to get that bug occur it will make the finding it faster. -- Tero_Kivinen@hut.FI Work : +358-0-451 4032 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-0-502 1573 From ninja@halcyon.com Fri Jan 28 17:10:27 1994 Return-Path: Received: from halcyon.com by ifi.uio.no with SMTP (8.6.4/ifi2.4) id ; Fri, 28 Jan 1994 17:10:22 +0100 Received: by halcyon.com id AA17888 (5.65c/IDA-1.4.4 for frankj@ifi.uio.no); Fri, 28 Jan 1994 06:15:04 -0800 Date: Fri, 28 Jan 1994 06:15:04 -0800 From: Jonathan Roy Message-Id: <199401281415.AA17888@halcyon.com> To: crossfire@ifi.uio.no, frankj@ifi.uio.no Subject: Re: Is there anybody there? Status: RO Is it unreasonable to rewrite parts of Crossfire in C++? That'd really be better for the OO aspect of the game, but it would lower portability... From jam@modeemi.cs.tut.fi Fri Jan 28 16:53:47 1994 Return-Path: Received: from modeemi.modeemi.cs.tut.fi by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id ; Fri, 28 Jan 1994 16:53:44 +0100 Received: from modeemi (localhost [127.0.0.1]) by modeemi.modeemi.cs.tut.fi (8.6.4/8.6.4) with SMTP id QAA03203; Fri, 28 Jan 1994 16:14:50 +0200 Message-Id: <199401281414.QAA03203@modeemi.modeemi.cs.tut.fi> X-Authentication-Warning: modeemi.modeemi.cs.tut.fi: Host localhost claimed to be modeemi To: Nick Williams cc: crossfire@ifi.uio.no, frankj@ifi.uio.no, quinet@montefiore.ulg.ac.be (Raphael Quinet) Subject: Re: Is there anybody there? In-reply-to: Your message of "Fri, 28 Jan 1994 10:05:17 GMT." <0hGCBRy__5g98mdhYE@cs.city.ac.uk> Date: Fri, 28 Jan 1994 16:14:49 +0200 From: Jari Vanhala Status: RO Nick Williams writes: >Well, I have the disk space and ftpness and all to provide a >distribution. I s'pose I could volunteer to maintain it, and withdraw a >volunteerness to code new things: I think that it's one or the other in >terms of how much spare time I could devote to it. Then again... any >excuse to get out of work :-) Is there any chance to get (group) account for few people to code crossfire (to get one master source) and maintain ftp? I could arrange too some disk space for crossfire-ftp (& 2-4 persons here could update it), but I don't have permission to create edit-accounts.. ++Jam From crossfire-request Fri Jan 28 17:10:38 1994 Return-Path: Received: from halcyon.com by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 17:10:36 +0100 Received: by halcyon.com id AA17871 (5.65c/IDA-1.4.4 for master@rahul.net); Fri, 28 Jan 1994 06:12:34 -0800 Date: Fri, 28 Jan 1994 06:12:34 -0800 From: Jonathan Roy Message-Id: <199401281412.AA17871@halcyon.com> To: crossfire@ifi.uio.no, master@rahul.net Subject: Re: Is there anybody there? Status: RO Is the client were only the display mechinism, you could use your own protocol instead of X, and animated bitmaps would be completely handled on teh client's end. It wouldn't effect the esrver at all... The server would simply say "display bitmap xxx at x,y" or something like that... (I assume the server would simple send a map to the client, and the client would have the bitmaps all stored locally. Maybe.. :) ) That alone would help alot. X is a bear. From crossfire-request Sat Jan 29 02:18:06 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id ; Sat, 29 Jan 1994 02:17:37 +0100 Received: from alamein (alamein.aaii.oz.AU) by eden-valley.aaii.oz.AU with SMTP (5.65c/SMI-4.0/AAII) id AA14892; Fri, 28 Jan 1994 21:41:03 +1100 Received: from [Family 1: 00:00:00:00:00:00:00:00:00:00:00:00:00:00] ([Family 1: 00:00:00:00:00:00:00:00:00:00:00:00:00:00]) by alamein (8.5/8.5-AAII) with SMTP id VAA22880; Fri, 28 Jan 1994 21:40:52 +1100 Message-Id: <199401281040.VAA22880@alamein> X-Authentication-Warning: alamein: Host [Family 1: 00:00:00:00:00:00:00:00:00:00:00:00:00:00] didn't use HELO protocol X-Authentication-Warning: alamein: anthony owned process doing -bs To: Mark Wedel Cc: crossfire@ifi.uio.no, frankj@ifi.uio.no, quinet@montefiore.ulg.ac.be From: anthony baxter Reply-To: anthony.baxter@aaii.oz.au Subject: Re: Is there anybody there? In-Reply-To: Message from Mark Wedel of 1994-Jan-28 1:45:29, <199401280945.AA11887@bolero.rahul.net> Date: Fri, 28 Jan 1994 21:40:38 +1100 Sender: anthony@aaii.oz.au Status: RO Mark Wedel wrote: > I found that with a previous version of crossfire, a malloc error that was > difficult to track down was not allocating enough space for the array, and > thus the program wrote beyond the malloc'd data, which then messed up some > other data. I was able to track that one down with the debug malloc > routines. That sort of thing is usually trivial to hunt down with purify (commercial memory leak tracker) We have it here, so either rgg or I can run it over the code, see what can be found... Anthony From crossfire-request Fri Jan 28 11:05:48 1994 Return-Path: Received: from barney.cs.city.ac.uk by ifi.uio.no with SMTP (8.6.4/ifi2.4) id ; Fri, 28 Jan 1994 11:05:45 +0100 Received: from wilma.cs.city.ac.uk by barney.cs.city.ac.uk; Fri, 28 Jan 1994 10:09:03 GMT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.wilma.cs.city.ac.uk.sun4.41 via MS.5.6.wilma.cs.city.ac.uk.sun4_41; Fri, 28 Jan 1994 10:05:17 +0000 (GMT) Message-Id: <0hGCBRy__5g98mdhYE@cs.city.ac.uk> Date: Fri, 28 Jan 1994 10:05:17 +0000 (GMT) From: Nick Williams Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: crossfire@ifi.uio.no, frankj@ifi.uio.no, quinet@montefiore.ulg.ac.be (Raphael Quinet) Subject: Re: Is there anybody there? In-Reply-To: <9401280912.AA04747@montefiore.ulg.ac.be> References: <9401280912.AA04747@montefiore.ulg.ac.be> Status: RO Excerpts from games.Crossfire: 28-Jan-94 Re: Is there anybody there? Raphael Quinet@montefior (1298) > > Volunteers? I spotted a volunteer?? Please! 8) > > > Well, errr... Volunteer for programming, yes. Sure! But not for > maintaining the distribution. Not enough time for that. Well, I have the disk space and ftpness and all to provide a distribution. I s'pose I could volunteer to maintain it, and withdraw a volunteerness to code new things: I think that it's one or the other in terms of how much spare time I could devote to it. Then again... any excuse to get out of work :-) Nick Williams E-mail: njw@cs.city.ac.uk (MIME and ATK) Systems Architecture Research Centre, Tel: +44 71 477 8551 London, EC1V 0HB Fax: +44 71 477 8587 From crossfire-request Fri Jan 28 11:00:08 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 11:00:03 +0100 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Fri, 28 Jan 94 10:58:31 +0100 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA04980; Fri, 28 Jan 94 10:59:41 +0100 Date: Fri, 28 Jan 94 10:59:41 +0100 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9401280959.AA04980@montefiore.ulg.ac.be> To: crossfire@ifi.uio.no Subject: Project team Status: RO If there are volunteers for the "Project team", as Frank said, we should first have some way to know each other. There are several options: - Use the "crossfire" list and post a message saying "I'm a volunteer". - Create another list and subsribe only if you are willing to offer serious programming services. - Send a mail to the maintainer, who will "manually" forward the message to all other candidates. Tedious. - Create a new "volunteers" directory on ftp.ifi.uio.no, where every programmer would put a file named after his E-mail address. This file could be empty or could contain a short message telling how much involved he wants to be. Do you have other ideas? -Raphael From master@rahul.net Fri Jan 28 10:45:35 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id ; Fri, 28 Jan 1994 10:45:31 +0100 Received: by bolero.rahul.net id AA11887 (5.67a8/IDA-1.5); Fri, 28 Jan 1994 01:45:29 -0800 Date: Fri, 28 Jan 1994 01:45:29 -0800 From: Mark Wedel Message-Id: <199401280945.AA11887@bolero.rahul.net> To: crossfire@ifi.uio.no, frankj@ifi.uio.no, quinet@montefiore.ulg.ac.be Subject: Re: Is there anybody there? Status: RO I found that with a previous version of crossfire, a malloc error that was difficult to track down was not allocating enough space for the array, and thus the program wrote beyond the malloc'd data, which then messed up some other data. I was able to track that one down with the debug malloc routines. Mark Wedel master@rahul.net From crossfire-request Fri Jan 28 10:43:36 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 10:43:29 +0100 Received: by bolero.rahul.net id AA11810 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Fri, 28 Jan 1994 01:43:27 -0800 Date: Fri, 28 Jan 1994 01:43:27 -0800 From: Mark Wedel Message-Id: <199401280943.AA11810@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Re: New version of crossfire: thoughts on distributed maps Status: RO The problem with that map idea, is that the client fetches a map. There is nothing preventing the person playing on that client to change the map file (perhaps add interesting things, or knock the oriental dragons down to 1 hp or something), and thus get super powers. For client server, what might work best is this (at least, this would be the safest): The server keeps track of all the data, including player data. The only purpose the client holds is to handle the drawing of data. It might also handle certain non criticial areas of animations, such as a fireball burning down, or taking a magic mapping request and then drawing the map. In this way, the best a person running a client could do is gain extra information. The map could also be downloaded to the client, so that a movement would be sent to the server (ie, north), and then the server would respond to the client to scroll the map down. Thus, the client only handles data display. Someone could hack up the client as much as they want, but they would not be able to create a supr character. Handling input and redraw code, if handled locally, would reduce the traffic some. I already said I would be maintainer. Unless someone else jumps up, it looks like I have the job. Perhaps if Frank could mention this in the crossfire 0.90 version he put up, so I get the patches instead of him. Address of master@rahul.net works fine. Mark Wedel master@rahul.net From crossfire-request Fri Jan 28 10:31:08 1994 Return-Path: Received: from thrall.cm.cf.ac.uk by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 10:31:06 +0100 Received: from cm.cf.ac.uk by thrall.cm.cf.ac.uk with SMTP (PP) id <10011-0@thrall.cm.cf.ac.uk>; Fri, 28 Jan 1994 09:29:02 +0000 Date: Fri, 28 Jan 94 09:29:00 GMT From: Simon McIntosh-Smith Message-Id: <9401280929.AA23651@garnet.cm.cf.ac.uk> To: crossfire@ifi.uio.no Subject: make or break for crossfire Status: RO Raphael Quinet wrote: > >From my point of view, here is what should be done: > 1) Get Frank's approval about this whole thing, or at least get some > comments form him. > 2) Choose a new maintainer (if Frank is out of the race) then build a team > of a few programmers who will work on the core of the game until we have > something ready for the first new "official" distribution. > 2) Get the latest alpha or beta version from Frank. > 3) Merge it with the latest version from Petri & Co (crossedit). > 4) Hold our breath, then jump into the client/server wolrd. > 5) Debug, debug, debug... > 6) Release the new version. > 7) Play Crossfire, add more nice features and restore hope in the world. Whatever happens, something needs to be done, and soon. Crossfire is at a critical point in its development. If we as its user community do not ensure its survival at this time when no official release is widely accepted, crossfire will sink into undeserved obscurity. Crossfire is one of the most exciting games I've seen, and I desperately want it to mature into a stable and well developed platform. But in its current state it is going nowhere. All those who have indicated that they have the time and inclination to take game development on will have more responsibility than they realise. The very life of the game is in there hands - if the current situation doesn't change in the near future crossfire will die. I think that a major step in ensuring crossfire's survival and progression will be the release of a new, amalgamated version. Good luck to all involved! Sy From crossfire-request Fri Jan 28 10:22:35 1994 Return-Path: Received: from barney.cs.city.ac.uk by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 10:22:33 +0100 Received: from wilma.cs.city.ac.uk by barney.cs.city.ac.uk; Fri, 28 Jan 1994 09:24:15 GMT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.wilma.cs.city.ac.uk.sun4.41 via MS.5.6.wilma.cs.city.ac.uk.sun4_41; Fri, 28 Jan 1994 09:20:29 +0000 (GMT) Message-Id: Date: Fri, 28 Jan 1994 09:20:29 +0000 (GMT) From: Nick Williams Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: crossfire@ifi.uio.no, master@rahul.net Subject: New version of crossfire: thoughts on distributed maps Status: RO It may be early to start talking features, but hey ;) I've often thought about the way the maps are used in crossfire; I think the current scheme is definitely wrong, and I have some ideas on what may be nicer. The problem with the current map loading scheme is that you must have all maps on a local filesystem: every crossfire server must allocate 5M of disk space just for maps and archetypes. Maps are just like any other data object in a distributed system: they want to be accessible to all of the distributed servers whilst behaving in a coherent manner: if one person fixes a map, everyone should see it, etc, etc. My thought is that maps should be searched for locally. However, if the map cannot be found locally, then a network request should be made for the map. Using what protocol? HTTP of course! :-). Maps would have to be cached. But this would be incredibly inefficient and horrible, I hear you say. Well, possibly. But there are many techniques to fix this, the most obvious being prefetching (in other thread of the server/client of course, so you continue to play while it prefetches) all maps accessible from the current map. Simple. The net access of maps is fairly trivial to do. The problem comes when you access a new map which contains some new archetypes, ones that you're server/client doesn't know about. Currently, this core dumps the server or performs other likewise interesting effects. Ideally, archetypes should be loadable on the fly, from the same source as the maps. i.e. Get map from source X, for all objects in map check archetype if !exists(archetype) then add to list (archetype) endfor if list is non-empty then Get archetype list from source X endif Graphics would have to be similarly treated. A simple way of implementing this right now is to change the loadmap routine to use http to retrieve the maps (and assume that all archetypes must exist). This will work immediately, with no modification to the maps, so long as the http root is set appropriately (i.e. the root of the map tree should be "file://localhost/crossfire/maps" instead of "$crosslib/maps"). This is for the current crossfire system. With a true client/server model, a different approach may be taken: the crossfire game could be considered to be one huge global game (not lots of different servers). When a particular client requests a map, it looks to see if anyone else is playing that map. If so, then it connects to that server. If not, then it becomes server for that map. This is a more complex system, but it could be very interesting to play. To be truly playable, perhaps this system should be implemented on a per-map basis, so that often used maps are replicated and only the more interesting/complex maps become globally coherent with this mechanism. Nick Nick Williams E-mail: njw@cs.city.ac.uk (MIME and ATK) Systems Architecture Research Centre, Tel: +44 71 477 8551 London, EC1V 0HB Fax: +44 71 477 8587 From crossfire-request Fri Jan 28 10:12:49 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be by ifi.uio.no with SMTP (8.6.4/ifi2.4) id ; Fri, 28 Jan 1994 10:12:06 +0100 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Fri, 28 Jan 94 10:10:52 +0100 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA04747; Fri, 28 Jan 94 10:12:02 +0100 Date: Fri, 28 Jan 94 10:12:02 +0100 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9401280912.AA04747@montefiore.ulg.ac.be> To: crossfire@ifi.uio.no, frankj@ifi.uio.no Subject: Re: Is there anybody there? Status: RO Frank (Yes, Frank! He's back!) wrote: > [A periscope pops up in the middle of the road, turning a full 360 degrees > before popping back where it came from. A nearby manhole is carefully > pushed aside, emitting a lot of steam. After a few seconds, an obviously > terrible embarrassed person returns from the murky depths] > Hurray! Hurray! An ever growing crowd welcomes the long-awaited hero, back from his long journey into the depths of the Earth... > A "Project team" or something similar sounds very nice to me. > Great! > Volunteers? I spotted a volunteer?? Please! 8) > Well, errr... Volunteer for programming, yes. Sure! But not for maintaining the distribution. Not enough time for that. > And give the maintainer some freedom to distribute workload among the team > if he for some reason is busy? > ...put the slaves at work, huh? ;-) > My local version _still_ has that malloc bug...It's real nasty. Instead > of making the game crash, it puts crossfire strings among the X-variables > occasionally. Like changing the name of the window to "food", or something > similar... > Yum! Looks like a good old wandering pointer... Who d'ya gonna call? Bug-hunters! Don't worry if there still are bugs in your version. After all, it's an alpha version. -Raphael From crossfire-request Fri Jan 28 09:32:38 1994 Return-Path: Received: from mimir.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 09:32:38 +0100 From: Frank Tore Johansen Received: from localhost by mimir.ifi.uio.no ; Fri, 28 Jan 1994 09:32:37 +0100 Message-Id: <19940128083237.29610.mimir.ifi.uio.no@ifi.uio.no> Subject: Re: Is there anybody there? To: crossfire@ifi.uio.no Date: Fri, 28 Jan 1994 09:32:36 +0100 (MET) In-Reply-To: from "frankj" at Jan 28, 94 09:26:27 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 335 Status: RO I wrote: > Raphael Quinet wrote: > > 2) Get the latest alpha or beta version from Frank. > > I'll put it out permanently as > ftp.ifi.uio.no:/pub/crossfire/crossfire-0.90.0-alpha.tar.Z > (will be there within an hour) I spotted some local changes (not by me) that made it unable to compile. Make that hour a day instead... -Frank. From frankj Fri Jan 28 09:32:35 1994 Subject: Re: Is there anybody there? To: crossfire@ifi.uio.no Date: Fri, 28 Jan 1994 09:32:35 +0100 (MET) In-Reply-To: from "frankj" at Jan 28, 94 09:26:27 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 336 Status: RO I wrote: > Raphael Quinet wrote: > > 2) Get the latest alpha or beta version from Frank. > > I'll put it out permanently as > ftp.ifi.uio.no:/pub/crossfire/crossfire-0.90.0-alpha.tar.Z > (will be there within an hour) I spotted some local changes (not by me) that made it unable to compile. Make that hour a day instead... -Frank. From crossfire-request Fri Jan 28 09:26:30 1994 Return-Path: Received: from mimir.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 09:26:29 +0100 From: Frank Tore Johansen Received: from localhost by mimir.ifi.uio.no ; Fri, 28 Jan 1994 09:26:29 +0100 Message-Id: <19940128082629.29328.mimir.ifi.uio.no@ifi.uio.no> Subject: Re: Is there anybody there? To: crossfire@ifi.uio.no Date: Fri, 28 Jan 1994 09:26:28 +0100 (MET) In-Reply-To: <9401280746.AA03788@montefiore.ulg.ac.be> from "Raphael Quinet" at Jan 28, 94 08:46:18 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1351 Status: RO [A periscope pops up in the middle of the road, turning a full 360 degrees before popping back where it came from. A nearby manhole is carefully pushed aside, emitting a lot of steam. After a few seconds, an obviously terrible embarrassed person returns from the murky depths] Raphael Quinet wrote: > From my point of view, here is what should be done: > 1) Get Frank's approval about this whole thing, or at least get some > comments form him. A "Project team" or something similar sounds very nice to me. > 2) Choose a new maintainer (if Frank is out of the race) then build a team > of a few programmers who will work on the core of the game until we have > something ready for the first new "official" distribution. Volunteers? I spotted a volunteer?? Please! 8) And give the maintainer some freedom to distribute workload among the team if he for some reason is busy? > 2) Get the latest alpha or beta version from Frank. I'll put it out permanently as ftp.ifi.uio.no:/pub/crossfire/crossfire-0.90.0-alpha.tar.Z (will be there within an hour) > 5) Debug, debug, debug... My local version _still_ has that malloc bug...It's real nasty. Instead of making the game crash, it puts crossfire strings among the X-variables occasionally. Like changing the name of the window to "food", or something similar... -Frank. From frankj Fri Jan 28 09:26:27 1994 Subject: Re: Is there anybody there? To: crossfire@ifi.uio.no Date: Fri, 28 Jan 1994 09:26:27 +0100 (MET) In-Reply-To: <9401280746.AA03788@montefiore.ulg.ac.be> from "Raphael Quinet" at Jan 28, 94 08:46:18 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1352 Status: RO [A periscope pops up in the middle of the road, turning a full 360 degrees before popping back where it came from. A nearby manhole is carefully pushed aside, emitting a lot of steam. After a few seconds, an obviously terrible embarrassed person returns from the murky depths] Raphael Quinet wrote: > From my point of view, here is what should be done: > 1) Get Frank's approval about this whole thing, or at least get some > comments form him. A "Project team" or something similar sounds very nice to me. > 2) Choose a new maintainer (if Frank is out of the race) then build a team > of a few programmers who will work on the core of the game until we have > something ready for the first new "official" distribution. Volunteers? I spotted a volunteer?? Please! 8) And give the maintainer some freedom to distribute workload among the team if he for some reason is busy? > 2) Get the latest alpha or beta version from Frank. I'll put it out permanently as ftp.ifi.uio.no:/pub/crossfire/crossfire-0.90.0-alpha.tar.Z (will be there within an hour) > 5) Debug, debug, debug... My local version _still_ has that malloc bug...It's real nasty. Instead of making the game crash, it puts crossfire strings among the X-variables occasionally. Like changing the name of the window to "food", or something similar... -Frank. From crossfire-request Fri Jan 28 08:47:13 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 08:47:10 +0100 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Fri, 28 Jan 94 08:45:43 +0100 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA03791; Fri, 28 Jan 94 08:46:52 +0100 Date: Fri, 28 Jan 94 08:46:52 +0100 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9401280746.AA03791@montefiore.ulg.ac.be> To: crossfire@ifi.uio.no, master@rahul.net Subject: Re: Is there anybody there? Status: RO >From: Mark Wedel > > There are several problems that do exist with a true client server approach. > If the client does a lot of the actions, with the server only acting to > mediate the actions (if several players are on the same map), it does open > the possibility of someone hacking a client to give themselves incredible > powers. > You're right! I one only needs to hack its client to obtain God-like powers on any server, we'll pretty soon loose all interest in the game. You don't like to be killed ten times in a row by the same player, don't you? > So even before hacking starts to make a client server approach, what the > client does and what the server does needs to be settled. If all the > client does is act as the display mechanism, I don't know how much bandwidth > or cpu time will be saved (especially if no animation code is added in..) > Here are some random thoughts : - The client could hold a part of the map so as to be able to update its window when needed. - The server would be responsible for all actions, collision detection, interaction between players, etc. This would prevent nasty hackers from cheating (unless they own the server, of course :-). - All animations would be on the client side. - Sending object ids will probably eat less bandwidth than sending X requests for drawing pixmaps and so on. I don't know how much, but I bet there will be a noticeable change in terms of speed when there are many players in the game. - This will be easier to maintain and enhance the code if we have most of the X stuff in one program, and the game engine in another. You want nicer graphics? Change your client, but don't touch the server. You want to add a new spell? Hack into the server. - We could even have several clients: one for slow machines, one for big displays with lots of colors, one which uses bitmaps while the other uses complex pixmaps,... But it's no time to dream: we have to build a fully working version of the game first. We'll add bells and whistles later. -Raphael From crossfire-request Fri Jan 28 08:47:07 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 08:47:03 +0100 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Fri, 28 Jan 94 08:45:08 +0100 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA03788; Fri, 28 Jan 94 08:46:18 +0100 Date: Fri, 28 Jan 94 08:46:18 +0100 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9401280746.AA03788@montefiore.ulg.ac.be> To: crossfire@ifi.uio.no Subject: Re: Is there anybody there? Status: RO >From: Philip Brown > > >>>>[From Rupert G. Goldie] > > While it would be nice to have a client-server with its own > protocol, I don't think it should be our primary concern right now. > > I completely disagree. The load is all in the server right now. > For more than a few people, reguardless of protocol, things get slow. > > The more stuff you add to the code, the harder it will be to split it all > out later. Do it NOW. The code needs a lot of rewriting/cleaning up > anyways. > > Yes. If the current server supports one or two "clients", the game is perfectly playable, even with a slow net. But try it with 10-20 players and tell me... I we want to be able to handle more than ten players, major changes are needed. From my point of view, here is what should be done: 1) Get Frank's approval about this whole thing, or at least get some comments form him. 2) Choose a new maintainer (if Frank is out of the race) then build a team of a few programmers who will work on the core of the game until we have something ready for the first new "official" distribution. 2) Get the latest alpha or beta version from Frank. 3) Merge it with the latest version from Petri & Co (crossedit). 4) Hold our breath, then jump into the client/server wolrd. 5) Debug, debug, debug... 6) Release the new version. 7) Play Crossfire, add more nice features and restore hope in the world. Any comments? -Raphael From crossfire-request Fri Jan 28 08:15:23 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 08:15:21 +0100 Received: by bolero.rahul.net id AA06042 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 27 Jan 1994 23:15:16 -0800 Date: Thu, 27 Jan 1994 23:15:16 -0800 From: Mark Wedel Message-Id: <199401280715.AA06042@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Re: Is there anybody there? Status: RO I think client server would be a good approach to take. However, a lot can also be done to just reduce the load on the servers without going to client server (organize the data structures better so that it is quicker to find those objects that are alive. I remember someone said they did this for an Amiga port, and it greatly increased performance.) Also, perhaps an option to prevent graphics animation. Fireballs would still burn things up, but grass would blow in the wind as it does now. This change would also reduce the bandwidth consumed by crossfire. There are several problems that do exist with a true client server approach. If the client does a lot of the actions, with the server only acting to mediate the actions (if several players are on the same map), it does open the possibility of someone hacking a client to give themselves incredible powers. So even before hacking starts to make a client server approach, what the client does and what the server does needs to be settled. If all the client does is act as the display mechanism, I don't know how much bandwidth or cpu time will be saved (especially if no animation code is added in..) Mark Wedel master@rahul.net From crossfire-request Fri Jan 28 07:47:05 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 07:47:04 +0100 Received: from localhost (philb@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id WAA19037; Thu, 27 Jan 1994 22:46:21 -0800 From: Philip Brown Message-Id: <199401280646.WAA19037@soda.berkeley.edu> Subject: Re: Is there anybody there? To: rgg@aaii.oz.au (Rupert G. Goldie) Date: Thu, 27 Jan 1994 22:46:18 -0800 (PST) Cc: crossfire@ifi.uio.no In-Reply-To: <199401280421.AA11275@eden-valley.aaii.oz.AU> from "Rupert G. Goldie" at Jan 28, 94 03:21:57 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 454 Status: RO >>>>[From Rupert G. Goldie] While it would be nice to have a client-server with its own protocol, I don't think it should be our primary concern right now. I completely disagree. The load is all in the server right now. For more than a few people, reguardless of protocol, things get slow. The more stuff you add to the code, the harder it will be to split it all out later. Do it NOW. The code needs a lot of rewriting/cleaning up anyways. From crossfire-request Fri Jan 28 05:22:36 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 05:22:16 +0100 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA11275; Fri, 28 Jan 1994 15:21:57 +1100 Date: Fri, 28 Jan 1994 15:21:57 +1100 From: "Rupert G. Goldie" Message-Id: <199401280421.AA11275@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no Subject: Re: Is there anybody there? Status: RO > From: joe@unipress.com > > Crossfire has to be re-programmed to use a client-server approach if we want > > to have an efficient and really distributed program. I'm not sure that the > > intermediate versions will be easy to maintain if several people are working > > on the project. > > I completely agree. This is one thing that has stopped me from working on > crossfire at all -- I think the design/protocol needs to be rethought. > > X protocol IMO is not efficient enough for this game, it needs it's own. > > --joe > While it would be nice to have a client-server with its own protocol, I don't think it should be our primary concern right now. We have a client and server that (pretty much) works and I don't think X is too inefficient for the job. I have run crossfire over a 9600bps serial link quite happily, so bandwidth isn't a big problem. My big problem with using X as a protocol is that there is no way that I'm allowing X through my firewall, but I would probably allow a Crossfire protocol through. I think a proper client-server interface is something we should be discussing and designing now, but getting a stable release out is of much higher priority. Rupert -- Rupert G. Goldie, Research Scientist rgg@aaii.oz.au Australian Artificial Intelligence Institute /\/\|| 1 Grattan Street, Melbourne, Australia From crossfire-request Fri Jan 28 05:11:20 1994 Return-Path: Received: from eden-valley.aaii.oz.AU by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 05:10:43 +0100 Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA11135; Fri, 28 Jan 1994 15:10:11 +1100 Date: Fri, 28 Jan 1994 15:10:11 +1100 From: "Rupert G. Goldie" Message-Id: <199401280410.AA11135@eden-valley.aaii.oz.AU> To: crossfire@ifi.uio.no Subject: Re: Crossfire maintenance. Status: RO Mark Wedel spake thus: > > I think any maintenance, and thus official releases, would be good. People > could still hack on their individual pieces (perhaps the maintainer would > keep track of what each person is doing), without any problems. > Yes this will certainly regenerate interest in the game. > However, with official releases, it would then mean that these changes > would then get put in the master source, so other people could use them, as > well as having moderately new versions to make diffs of. > > [...problems of file sharing...] > I would be willing to become official maintener/patch collector of the > source, as I have a bit of free time right now. I can't promise doing a lot > of hacking on it myself, but I would certainly put out new versions and > apply patches I receive. > It would be great to have you become maintainer so that we have a central point to send patches. I think having a maintainer will work better than having a shared source tree for the reasons you mentioned plus it allows you to control what goes into the game. That should help keep the source more stable than if we let everyone apply patches willy-nilly to some master source. > One thing that should be done, no matter how becomes the official person, > is to archive up the version Frank was working on. Unless it is considered > better to go back to the last official release as a baseline. > The big change between 0.89.2 and the last 0.89.3 beta I saw was the introduction of filepaths. I think this is a good reason to go with the latest version. I think the first task should be to assemble a stable release based on a recent 0.89.3 and to release it and the filepath-converted maps. Then people can start creating more maps again and have a baseline upon which to make patches. I can devote a bit of time to hacking code, and I'm willing to run the source through Purify to try to track down any nasty/obscure bugs. It would also be nice if we could get a comment or stamp of approval from Frank as Crossfire is his baby. > Mark Wedel > master@rahul.net > Rupert -- Rupert G. Goldie, Research Scientist rgg@aaii.oz.au Australian Artificial Intelligence Institute /\/\|| 1 Grattan Street, Melbourne, Australia From crossfire-request Fri Jan 28 04:37:15 1994 Return-Path: Received: from amisk.cs.ualberta.ca by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 04:37:12 +0100 Received: from gsb011.cs.ualberta.ca by amisk.cs.ualberta.ca id <138621>; Thu, 27 Jan 1994 20:36:54 -0700 Subject: Re: Is there anybody there? From: Papp Denis Richard To: joe@unipress.com Date: Thu, 27 Jan 1994 20:36:42 -0700 Cc: crossfire@ifi.uio.no In-Reply-To: <9401272107.AA25949@repo.unipress.com> from "joe@unipress.com" at Jan 27, 94 02:06:53 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1321 Message-Id: <94Jan27.203654-0700.138621@amisk.cs.ualberta.ca> Status: RO > > > > Crossfire has to be re-programmed to use a client-server approach if we want > > to have an efficient and really distributed program. I'm not sure that the > > intermediate versions will be easy to maintain if several people are working > > on the project. > > I completely agree. This is one thing that has stopped me from working on > crossfire at all -- I think the design/protocol needs to be rethought. > > X protocol IMO is not efficient enough for this game, it needs it's own. > I havent really been in the discussion much, but I definitely agree, crossfire is too slow (assuming the speed would be greatly improved with a crossfire client) I really only play it on the local server, the speed is great. Tried it a couple of times a while back on remote servers - couldnt stand it. Reminds me - has anyone every got a lot of participation at one time? The most I've seen at one time on the local server was 5 or 6 players, maybe 3 at most wandering together. I remember that one mUD a while ago that used to get 100-120 players about once a week (and the lag wasnt too bad - the shouting was :) -- Denis Papp dpapp@amisk.cs.ualberta.ca "So, uh, let me uh get this straight. You want to kidnap me and put me in some intuhguhlactic zoo?"-- Elvis Presley From crossfire-request Fri Jan 28 03:29:30 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 03:29:29 +0100 Received: from localhost (philb@localhost) by soda.berkeley.edu (8.6.5/PHILMAIL-1.10) id SAA22206; Thu, 27 Jan 1994 18:29:13 -0800 From: Philip Brown Message-Id: <199401280229.SAA22206@soda.berkeley.edu> Subject: Re: Is there anybody there? To: joe@unipress.com Date: Thu, 27 Jan 1994 18:29:12 -0800 (PST) Cc: crossfire@ifi.uio.no In-Reply-To: <9401272107.AA25949@repo.unipress.com> from "joe@unipress.com" at Jan 27, 94 04:06:53 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 507 Status: RO >>>>[From joe@unipress.com] I completely agree. This is one thing that has stopped me from working on crossfire at all -- I think the design/protocol needs to be rethought. Likewise. At one point, I was considering doing the split myself, with the help of a few other folks.. but the source kept changing... the rlease wasn't stable anyway... so I figured I'd wait for an Official version. first things first, thou. we need a definate, officially sanctioned, new caretaker for the src. From crossfire-request Fri Jan 28 02:16:48 1994 Return-Path: Received: from halcyon.com by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 02:16:45 +0100 Received: by halcyon.com id AA27201 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Thu, 27 Jan 1994 17:16:40 -0800 Date: Thu, 27 Jan 1994 17:16:40 -0800 From: Jonathan Roy Message-Id: <199401280116.AA27201@halcyon.com> To: crossfire@ifi.uio.no, joe@unipress.com Subject: Re: Is there anybody there? Status: RO DOes using USP packets instead of TCP packets relate to Crossfire at all? Or is that only important in more interactive games like Netrek, or whatever? From crossfire-request Fri Jan 28 00:51:40 1994 Return-Path: Received: from rutgers.edu by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Fri, 28 Jan 1994 00:51:37 +0100 From: joe@unipress.com Received: from unipress-link.rutgers.edu by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17779; Thu, 27 Jan 94 16:07:03 EST Received: from dot.unipress.com by repo.unipress.com (4.1/SMI-4.1/UniPress112493.1) id AA25949; Thu, 27 Jan 94 16:07:00 EST via Message-Id: <9401272107.AA25949@repo.unipress.com> To: crossfire@ifi.uio.no Subject: Re: Is there anybody there? In-Reply-To: Your message of "Thu, 27 Jan 94 09:02:36 +0100." <9401270802.AA26653@montefiore.ulg.ac.be> Date: Thu, 27 Jan 94 16:06:53 -0500 Status: RO > Crossfire has to be re-programmed to use a client-server approach if we want > to have an efficient and really distributed program. I'm not sure that the > intermediate versions will be easy to maintain if several people are working > on the project. I completely agree. This is one thing that has stopped me from working on crossfire at all -- I think the design/protocol needs to be rethought. X protocol IMO is not efficient enough for this game, it needs it's own. --joe From crossfire-request Thu Jan 27 14:23:55 1994 Return-Path: Received: from barney.cs.city.ac.uk by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Thu, 27 Jan 1994 14:23:49 +0100 Received: from wilma.cs.city.ac.uk by barney.cs.city.ac.uk; Thu, 27 Jan 1994 13:26:40 GMT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.wilma.cs.city.ac.uk.sun4.41 via MS.5.6.wilma.cs.city.ac.uk.sun4_41; Thu, 27 Jan 1994 13:22:56 +0000 (GMT) Message-Id: Date: Thu, 27 Jan 1994 13:22:56 +0000 (GMT) From: Nick Williams Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: crossfire@ifi.uio.no, master@rahul.net, quinet@montefiore.ulg.ac.be (Raphael Quinet) Subject: Re: Crossfire maintenance. In-Reply-To: <9401271127.AA28863@montefiore.ulg.ac.be> References: <9401271127.AA28863@montefiore.ulg.ac.be> Status: RO Well, I'm happy to help out with both disk space (altho not via NFS) and code work. Nick Nick Williams E-mail: njw@cs.city.ac.uk (MIME and ATK) Systems Architecture Research Centre, Tel: +44 71 477 8551 London, EC1V 0HB Fax: +44 71 477 8587 From crossfire-request Thu Jan 27 12:27:37 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Thu, 27 Jan 1994 12:27:35 +0100 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Thu, 27 Jan 94 12:26:21 +0100 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA28863; Thu, 27 Jan 94 12:27:31 +0100 Date: Thu, 27 Jan 94 12:27:31 +0100 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9401271127.AA28863@montefiore.ulg.ac.be> To: crossfire@ifi.uio.no, master@rahul.net Subject: Re: Crossfire maintenance. Status: RO Mark Wedel wrote: > > I think any maintenance, and thus official releases, would be good. People > could still hack on their individual pieces (perhaps the maintainer would > keep track of what each person is doing), without any problems. > > However, with official releases, it would then mean that these changes > would then get put in the master source, so other people could use them, as > well as having moderately new versions to make diffs of. > I totally agree! The most annoying thing when there is no official version is that some people write patches to the code but they are nearly useless for most other people because they don't have the same version of the source files. If we all agree to write our patches on the same *recent* set of files, then we won't see these problems anymore. > The problem with a file sharing problem is several. First, those people > with slow net connections, or who hack on unix machines not connected > permantly to the net, have problems. Also, for those that hack on school > machines or public accounts, possibly would not be able to get the files > via nfs, as you need to be root in order to use the mount command (and thus > mount nfs partitions.) > If we want to use CVS (or only RCS, or any other system), there will be a problem if we can't use a common filesystem. The only workaround I can think of is to have the files (source and deltas) available for anonymous ftp. This way, if you can't mount the nfs partition, you can always use ftp to fetch the files. Naturally, those users will break the locking mechanism, but if there is no other solution... > I would be willing to become official maintener/patch collector of the > source, as I have a bit of free time right now. I can't promise doing a lot > of hacking on it myself, but I would certainly put out new versions and > apply patches I receive. > Well, thanks a lot! If there are no other candidates, then you could start right now. :-) > One thing that should be done, no matter who becomes the official person, > is to archive up the version Frank was working on. Unless it is considered > better to go back to the last official release as a baseline. > We should merge the latest version Frank was working on with the latest changes in the crossedit distribution. This won't be an easy task... I may be able to spare some of my time if I can help someone doing this, but I can't do this myself (alone). Comments and help are welcome. -Raphael From crossfire-request Thu Jan 27 11:13:50 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Thu, 27 Jan 1994 11:13:43 +0100 Received: by bolero.rahul.net id AA07941 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 27 Jan 1994 02:13:41 -0800 Date: Thu, 27 Jan 1994 02:13:41 -0800 From: Mark Wedel Message-Id: <199401271013.AA07941@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Crossfire maintenance. Status: RO I wrote this before, but I think I replied to an individual person instead of the list. I think any maintenance, and thus official releases, would be good. People could still hack on their individual pieces (perhaps the maintainer would keep track of what each person is doing), without any problems. However, with official releases, it would then mean that these changes would then get put in the master source, so other people could use them, as well as having moderately new versions to make diffs of. The problem with a file sharing problem is several. First, those people with slow net connections, or who hack on unix machines not connected permantly to the net, have problems. Also, for those that hack on school machines or public accounts, possibly would not be able to get the files via nfs, as you need to be root in order to use the mount command (and thus mount nfs partitions.) I would be willing to become official maintener/patch collector of the source, as I have a bit of free time right now. I can't promise doing a lot of hacking on it myself, but I would certainly put out new versions and apply patches I receive. One thing that should be done, no matter how becomes the official person, is to archive up the version Frank was working on. Unless it is considered better to go back to the last official release as a baseline. Mark Wedel master@rahul.net From crossfire-request Thu Jan 27 09:02:46 1994 Return-Path: <<@vm1.ulg.ac.be:quinet@montefiore.ulg.ac.be>> Received: from vm1.ulg.ac.be by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Thu, 27 Jan 1994 09:02:44 +0100 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Thu, 27 Jan 94 09:01:31 +0100 Received: from verif1.montefiore.ulg.ac.be by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA26653; Thu, 27 Jan 94 09:02:36 +0100 Date: Thu, 27 Jan 94 09:02:36 +0100 From: quinet@montefiore.ulg.ac.be (Raphael Quinet) Message-Id: <9401270802.AA26653@montefiore.ulg.ac.be> To: crossfire@ifi.uio.no, eanders+@CMU.EDU Subject: Re: Is there anybody there? Status: RO eanders+@CMU.EDU (Eric A. Anderson) wrote: > > quinet@montefiore.ulg.ac.be (Raphael Quinet) writes: > > So what? Right now, I'm working on another project because I see no point in > > continuing until Frank returns or until someone else "officialy" maintains the > > CrossFire distribution. Sigh! > If we all agreed to put crossfire into CVS, and someone donated > machine time, we could work on it as a big group project. It would > require that people keep a list of what they're working on to try and > keep collisions from happening. I'd be willing to donate machine > time, but I can't export NFS because I'm currently running alex which > uses the nfs stuff to provide an anonymous ftp filesystem. > Crossfire has to be re-programmed to use a client-server approach if we want to have an efficient and really distributed program. I'm not sure that the intermediate versions will be easy to maintain if several people are working on the project. But once this has been done (the client-server conversion), this should be easier to maintain and to share between several programmers. CVS is probably the best system to use in this case. One last thing: I can't export NFS because out net connection is damn too slow! -Raphael From ea08+@andrew.cmu.edu Tue Jan 25 18:41:38 1994 Return-Path: Received: from andrew.cmu.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id ; Tue, 25 Jan 1994 18:41:25 +0100 Received: from localhost (postman@localhost) by andrew.cmu.edu (8.6.4/8.6.4) id MAA12833; Tue, 25 Jan 1994 12:41:16 -0500 Received: via switchmail; Tue, 25 Jan 1994 12:41:14 -0500 (EST) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Tue, 25 Jan 1994 12:40:39 -0500 (EST) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Tue, 25 Jan 1994 12:40:34 -0500 (EST) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.madhatter.ws.cc.cmu.edu.sun4c.411 via MS.5.6.madhatter.ws.cc.cmu.edu.sun4c_411; Tue, 25 Jan 1994 12:40:34 -0500 (EST) Message-ID: Date: Tue, 25 Jan 1994 12:40:34 -0500 (EST) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: Is there anybody there? CC: crossfire-request@ifi.uio.no, crossfire@ifi.uio.no In-Reply-To: <9401250814.AA13359@montefiore.ulg.ac.be> References: <9401250814.AA13359@montefiore.ulg.ac.be> Status: RO quinet@montefiore.ulg.ac.be (Raphael Quinet) writes: > So what? Right now, I'm working on another project because I see no point in > continuing until Frank returns or until someone else "officialy" maintains the > CrossFire distribution. Sigh! If we all agreed to put crossfire into CVS, and someone donated machine time, we could work on it as a big group project. It would require that people keep a list of what they're working on to try and keep collisions from happening. I'd be willing to donate machine time, but I can't export NFS because I'm currently running alex which uses the nfs stuff to provide an anonymous ftp filesystem. -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 Jan 25 17:58:17 1994 Return-Path: Received: from tbird.cc.iastate.edu by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Tue, 25 Jan 1994 17:58:15 +0100 Received: by tbird.cc.iastate.edu with sendmail-5.65 id ; Tue, 25 Jan 1994 10:57:50 -0600 Message-Id: <9401251657.AA04150@tbird.cc.iastate.edu> To: quinet@montefiore.ulg.ac.be (Raphael Quinet) Subject: Re: Is there anybody there? In-Reply-To: Your message of Tue, 25 Jan 1994 09:14:44 +0100. <9401250814.AA13359@montefiore.ulg.ac.be> Cc: crossfire@ifi.uio.no Date: Tue, 25 Jan 1994 10:57:49 CST From: "Michael Graff" Status: RO >So what? Right now, I'm working on another project because I see no point in >continuing until Frank returns or until someone else "officialy" maintains the >CrossFire distribution. Sigh! Do I hear a volunteer in this posting? Why not take it over yourself? >And my current project is not even a game! What's happening to the world? >Are we all going to work on serious (and maybe boring) projects? games -> play -> not paid -> no money -> apartment !games -> work -> paid -> money -> apartment :) --Michael -- Michael Graff Iowa State University Computation Center Project Vincent 215 Durham voice: (515) 294-4994 explorer@iastate.edu Ames, IA 50011 fax: (515) 294-1717 gg.mlg@isumvs.bitnet From crossfire-request Tue Jan 25 05:38:28 1994 Return-Path: Received: from condor.CC.UMontreal.CA by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Tue, 25 Jan 1994 05:38:19 +0100 Received: from aster.JSP.UMontreal.CA by condor.CC.UMontreal.CA with SMTP id AA21007 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Mon, 24 Jan 1994 23:36:01 -0500 Received: from ceres.jsp.umontreal.ca by aster.jsp.umontreal.ca (920330.SGI/5.17) id AA12392; Mon, 24 Jan 94 23:38:01 -0500 Received: by ceres.jsp.umontreal.ca (920330.SGI/5.17) id AA20972; Mon, 24 Jan 94 23:38:20 -0500 From: kosmatoo@JSP.UMontreal.CA (Kosmatos Odisseas) Message-Id: <9401250438.AA20972@ceres.jsp.umontreal.ca> Subject: Is there anybody there? To: crossfire@ifi.uio.no Date: Mon, 24 Jan 1994 23:38:19 -0500 (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: 558 Status: RO Hi. Is the crossfire development team still alive? It seems as if nothing new has entered the archives at ftp.world.net or ifi.uio.no for /pub/crossfire.. Can someone please update the /pub/crossfire/archives folder or AT LEAST send me a mail saying "Crossfire is still alive -- we're just on vacation". I tried to subscribe to crossfire-request but nothing happens. Its like the crossfire people have been wiped off the face of the earth! -- Odisseas Kosmatos kosmatoo@jsp.umontreal.ca "R2D2, you know better than to trust a strange computer." From crossfire-request Mon Jan 24 04:45:35 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Mon, 24 Jan 1994 04:45:28 +0100 Received: by bolero.rahul.net id AA01641 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Sun, 23 Jan 1994 19:45:22 -0800 Date: Sun, 23 Jan 1994 19:45:22 -0800 From: Mark Wedel Message-Id: <199401240345.AA01641@bolero.rahul.net> To: eanders+@CMU.EDU, peterm@soda.berkeley.edu Subject: Re: font idea (servers) Cc: crossfire@ifi.uio.no Status: RO Different fonts for different servers should not make it too much extra work for the server people. In fact, I believe there is a define in the config file for the font name (crossfire.cf in fact.) Also, for the local machines, you could alias the crossfire font to whatever name the server uses. The reasons I like for different font names for different sites is this: 1) I can have all the fonts on my local machine, for all the different servers. If the font that all the crossfire servers is called 'crossfire', it is difficult to do this. 2) Fontservers are nice, but if you have a slow connection (maybe over 14.4 modem), using pixmaps or downloading the font each time could be time consuming. 3) By having a different name for each server, I then don't have to change font paths or font names or do anything else to play on any server. I can just have all the fonts local, telnet to all the sites, see which one I want to play with, and that is it. Mark Wedel master@rahul.net From crossfire-request Mon Jan 24 03:04:00 1994 Return-Path: Received: from soda.berkeley.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Mon, 24 Jan 1994 03:03:58 +0100 Received: from localhost (peterm@localhost) by soda.berkeley.edu (8.6.4/PHILMAIL-1.10) id SAA23944; Sun, 23 Jan 1994 18:03:53 -0800 Date: Sun, 23 Jan 1994 18:03:53 -0800 From: Peter Mardahl Message-Id: <199401240203.SAA23944@soda.berkeley.edu> To: crossfire@ifi.uio.no, eanders+@CMU.EDU Subject: Re: font idea (servers) Status: RO When the scotch server is running (which it isn't right now) it's font changes often, so having a copy of the font might not help you too much. Anyway, it'd be cool if all the server gods would set up a font server. You can download the font for a server using the fstobdf command, I think. It might be nice to have different names for different fonts. (at different sites) I'll look into it when the scotch server can come back up. PeterM From crossfire-request Mon Jan 24 00:49:05 1994 Return-Path: Received: from po5.andrew.cmu.edu by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Mon, 24 Jan 1994 00:49:03 +0100 Received: from localhost (postman@localhost) by po5.andrew.cmu.edu (8.6.4/8.6.4) id SAA21819 for crossfire@ifi.uio.no; Sun, 23 Jan 1994 18:49:00 -0500 Received: via switchmail; Sun, 23 Jan 1994 18:48:59 -0500 (EST) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Sun, 23 Jan 1994 18:47:58 -0500 (EST) Received: from madhatter.ws.cc.cmu.edu via qmail ID ; Sun, 23 Jan 1994 18:47:53 -0500 (EST) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.madhatter.ws.cc.cmu.edu.sun4c.411 via MS.5.6.madhatter.ws.cc.cmu.edu.sun4c_411; Sun, 23 Jan 1994 18:47:51 -0500 (EST) Message-ID: Date: Sun, 23 Jan 1994 18:47:51 -0500 (EST) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: font idea (servers) In-Reply-To: <199401231007.AA28182@bolero.rahul.net> References: <199401231007.AA28182@bolero.rahul.net> Status: RO You could most of the font standard and then have additions be downloaded as pixmaps, or you could extend what I originally did when I wrote the client stuff, which is shove the font over in bdf format; but before transferring, you could check a cache to see if the md5 value(cool checksum) matched, and if it did then not perform the transfer. -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 Sun Jan 23 11:07:57 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Sun, 23 Jan 1994 11:07:54 +0100 Received: by bolero.rahul.net id AA28182 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Sun, 23 Jan 1994 02:07:51 -0800 Date: Sun, 23 Jan 1994 02:07:51 -0800 From: Mark Wedel Message-Id: <199401231007.AA28182@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: font idea (servers) Status: RO What might be a good idea is for each server admin (when setting up) to name their font something unique (ie, crossfire.madhatter, crossfire.corpse, etc.) This is for several reasons: In this way, a user can have fonts for all the different servers on his system without worry of conflicts (ie, if I grab the scotch font file, it may not match with what font corpse is using, or any other server), and also allows sites to change the font file without any worry. The site local to the server could obviously installed the properly named font for their system. The problem right now is that I could grab the font for one server, and it would not match up on another server. I could use bitmaps, but over a 14.4 kbps term connection, I have a feeling it could be slow to download the bitmaps. Thoughts? Mark Wedel master@rahul.net From crossfire-request Tue Jan 4 12:24:31 1994 Return-Path: Received: from dragon.cit.gu.edu.au by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Tue, 4 Jan 1994 12:24:28 +0100 Received: by dragon.cit.gu.edu.au id AA27008 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Tue, 4 Jan 1994 21:24:53 +1000 Date: Tue, 4 Jan 1994 21:24:53 +1000 From: Anthony Thyssen Message-Id: <199401041124.AA27008@dragon.cit.gu.edu.au> To: crossfire@ifi.uio.no Subject: Greetings X-Face: "Ech/vWX*#{vKw-OiDaKqy:=y'Kqji( Received: from virginia.edu by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Tue, 4 Jan 1994 01:13:00 +0100 Received: from sonja.math.virginia.edu by uvaarpa.virginia.edu id aa14249; 3 Jan 94 19:12 EST Received: by sonja.math.Virginia.EDU (NX5.67c/NX3.0S) id AA08474; Mon, 3 Jan 94 19:13:17 -0500 Date: Mon, 3 Jan 94 19:13:17 -0500 From: "Kevin H. Weiss" Message-Id: <9401040013.AA08474@sonja.math.Virginia.EDU> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: crossfire@ifi.uio.no Subject: crossedit-0.7 on NeXT Status: RO Hi folks, Now that I actually have a (very) little bit of free time, I wanted to update my server, sonja.math.virginia.edu, to the latest version crossfire. So, I was wondering if anybody has made patches to crossedit-0.7 so that it'll compile on a NeXT? Help!!! --Kevin P.S. Sorry to those players, whom I've ignored for the past two months. I've been REALLY busy. Honest!!! From crossfire-request Mon Jan 31 08:15:24 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Mon, 31 Jan 1994 08:15:19 +0100 Received: by bolero.rahul.net id AA02595 (5.67a8/IDA-1.5 for crossfire@ifi.uio.no); Sun, 30 Jan 1994 23:15:06 -0800 Date: Sun, 30 Jan 1994 23:15:06 -0800 From: Mark Wedel Message-Id: <199401310715.AA02595@bolero.rahul.net> To: master@rahul.net, tvangod@ecst.csuchico.edu Subject: Re: Patches, ftp, new releases. Cc: crossfire@ifi.uio.no Status: RO From Tyler Van Gorder : I do see one problem, in that the version Frank recently made available was worked on in parallel with the version that comes with crossedit-.7 The chico server we are running here was modified from the source that came with crossedit. The Berkeley server, scotch, is also running from more or less the same source. The differences from that code and the code that Frank released are large. If you are going to release a new version, I suppose we would want to merge the two versions before a release....this is a LARGE project, and I am wondering if it would be a better use of time to just move to client/server before the next release? Tyler. tvangod@ecst.csuchico.edu ---- Even if client server happens in the next release, the crossedit 0.7 and crossfire 0.90a difference still need to be merged. I'll have to look at 0.90a and see how much has been changed. One option might be to take one of these distributions and set it as the new standard, and slowly integrate the changes in the other version, if the changes are major. Does anyone recall the common ancestor to these two programs? Perhaps making diffs from that to either crossfire 0.90a or crossedit 0.7 would be the easiest way to join them up again, and have all the features of both distributions. (I guess Frank can say what version he used when he started hacking on crossfire 0.90a, and the crossedit 0.7 team can say the same thing..) Mark Wedel master@rahul.net h From crossfire-request Mon Jan 31 16:44:09 1994 Return-Path: Received: from cardhu.cs.hut.fi by ifi.uio.no with SMTP (8.6.4/ifi2.4) id ; Mon, 31 Jan 1994 16:44:08 +0100 Received: by cardhu.cs.hut.fi id AA14538 (5.65c8/HUTCS-C 1.3); Mon, 31 Jan 1994 17:44:06 +0200 Date: Mon, 31 Jan 1994 17:44:06 +0200 Message-Id: <199401311544.AA14538@cardhu.cs.hut.fi> From: Tero Kivinen To: Kjetil Torgrim Homme Cc: crossfire@ifi.uio.no Subject: Re: Patches, ftp, new releases. In-Reply-To: <19940131075214.17230.bera.ifi.uio.no@ifi.uio.no> References: <199401310715.AA02595@bolero.rahul.net> <19940131075214.17230.bera.ifi.uio.no@ifi.uio.no> Organization: Helsinki University of Technology/Lifelong Learning Institute Dipoli Status: RO Kjetil Torgrim Homme writes: > Frank *has* tried to use Purify, but he couldn't get it to > link... Let's hope you guys have more luck with it. I run it with my redzal about hour, but it didn't crash. I even enabled most of the special features (execpt CHRFONT (crashes immediately)). I played with one player, perhaps it needs more players to trigger to bug. I am going to try it more today with more players (it is quite pain to do that, because my redzal will take huge amount of memory, and my workstation got only 48 MB....). Perhaps I will try with efence in our sun. -- 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 Mon Jan 31 16:32:27 1994 Return-Path: Received: from cardhu.cs.hut.fi by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Mon, 31 Jan 1994 16:32:26 +0100 Received: by cardhu.cs.hut.fi id AA14406 (5.65c8/HUTCS-C 1.3 for crossfire@ifi.uio.no); Mon, 31 Jan 1994 17:31:55 +0200 Date: Mon, 31 Jan 1994 17:31:55 +0200 Message-Id: <199401311531.AA14406@cardhu.cs.hut.fi> From: Tero Kivinen To: Mark Wedel Cc: crossfire@ifi.uio.no Subject: Re: Is there anybody there? In-Reply-To: <199401310442.AA26004@bolero.rahul.net> References: <199401310442.AA26004@bolero.rahul.net> Organization: Helsinki University of Technology/Lifelong Learning Institute Dipoli Status: RO Mark Wedel writes: > 'Unfortunately', as moderator, I do live in the USA, which means that > for each official release I make, someone else (outside of USA), would > need to add the appropriate code and put it on the ftp sites. Sounds > like a bit of a pain to me. This is usually handled so that source contain only stubs for the encryption and encryption library can be found somewhere outside usa (I think the library will be quite static after the first release, so you propably need to get it only once). -- 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 Mon Jan 31 15:54:55 1994 Return-Path: Received: from cardhu.cs.hut.fi by ifi.uio.no with SMTP (8.6.4/ifi2.4) id for ; Mon, 31 Jan 1994 15:54:54 +0100 Received: by cardhu.cs.hut.fi id AA13656 (5.65c8/HUTCS-C 1.3 for crossfire@ifi.uio.no (Crossfire Mailing List)); Mon, 31 Jan 1994 16:54:46 +0200 Date: Mon, 31 Jan 1994 16:54:46 +0200 Message-Id: <199401311454.AA13656@cardhu.cs.hut.fi> From: Tero Kivinen To: Philip Brown Cc: crossfire@ifi.uio.no (Crossfire Mailing List) Subject: Monsters In-Reply-To: <199401302030.MAA03877@soda.berkeley.edu> References: <199401302030.MAA03877@soda.berkeley.edu> Organization: Helsinki University of Technology/Lifelong Learning Institute Dipoli Status: RO Philip Brown writes: > Excellent point. It's all a matter of how far you let a monster's > 'vision' be, I think. > I haven't checked in the source, but i believe that a limited-range of > vision is already implemented in some fashion. It should be augmented by > having low-level monsters, and most kinds of other monsters, having > really short-range vision. Then the problem will fix itself, I think. > (of course, if some map-maker is stupid enough to put > 100 "clairevoyant mind-flayers, speed 10" in a room together, nothing > you can do :-) When I few years back was implementing a game much similar that crossfire (but with my own curses), I planned to handle that by creating special kind of client that would connect to the main server. This client would be like robot who is playing the monsters. So one robot-client could easily play move for all orcs on the world, and other robot would take care of rest of small monster. Then when you created a new map, you could create a very special monster there (say the king of the world) and you could write robot to play that monster (the king could remember every player he has talked to and could act accordingly (order all the guards to attack the player etc... :-)). Those special robot-clients could have password protected connection to server, so the could get more information and do more than normal client. When someone writes a new monster-robot he could send mail to adminstrator of the server and agree password for client. -- 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 Mon Jan 31 11:45:16 1994 Return-Path: Received: from saffron.csv.warwick.ac.uk by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Mon, 31 Jan 1994 11:45:14 +0100 From: Brazil Message-Id: <4505.199401311045@saffron.csv.warwick.ac.uk> Received: from localhost by saffron.csv.warwick.ac.uk id KAA04505; Mon, 31 Jan 1994 10:45:10 GMT Subject: UNSUBSCRIBE To: crossfire@ifi.uio.no Date: Mon, 31 Jan 1994 10:45:07 +0000 (GMT) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 34 Status: RO UNSUBSCRIBE please unsubscribe me From crossfire-request Mon Jan 31 11:12:02 1994 Return-Path: Received: from cc.lut.fi by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Mon, 31 Jan 1994 11:11:59 +0100 Received: from localhost (haatanen@localhost) by cc.lut.fi (8.6.5/8.6.5/1.12.kim) id MAA22999; Mon, 31 Jan 1994 12:11:58 +0200 (for crossfire@ifi.uio.no) From: Tero Haatanen Message-Id: <199401311011.MAA22999@cc.lut.fi> Subject: Re: Patches, ftp, new releases. To: crossfire@ifi.uio.no Date: Mon, 31 Jan 1994 12:11:57 +0200 (EET) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 3361 Status: RO At least nobody can say that crossfire deveplopment is dead. I add some of my thoughts in this discussion. I think that the first we need the new release, so that people who like to try crossfire can get the stable and working version. Crossedit 0.7 and crossfire 0.90a must merged together and it seems interested challenge without mixing server/client concept there. So maybe next (not alpha/beta) version should contain - crossfire 0.90a code and new features - crossedit 0.7 editor and new map format and so on - xpm patches - good set of maps There have been some talk about getting a good set of maps, but nobody have said anything about bitmaps/pixmaps. Currently these are like maps. There are good ones and bad ones and everything between those. And all walls and houses have different 3d look :). If there are any artists who like to take a small :) project and redraw those bitmaps it would give a new look for crossfire. Seriosly this isn't easy task, but I see it still quite important one. After we have the stable version we can start doing the client/server version. Like Kjetil descripted differences between crossedit 0.7 and crossfire 0.90a, those don't affect client/server code. I would like that new version would in reasonable time, so that people don't loose their interest. The first version of client could use the current interface, after that people could do Xaw/Motif/whatever clients. I don't see it problem to have different clients if they just offer same functions. Also we have time to discuss, what client does and what server does and how they communicate with each other. I think that server should handle everything, excluding maybe animation. So slow client could have option no-animations, but this probably requires that where animation is used something important (i.e. opening/closing gates), those have to be done with changing objects. Client also could handle inventory, so that server only knows what item is applied, dropped, etc. How that is applied is client trouble (i.e. clicking with mouse or pressing 'a'). And when server sends info that player has 10/105 hp's, client can draw status bar, print numbers or play audiofile in /dev/audio :). Map caching in client offers interest possibilities. I'am not sure that it is more efficient, since maps changes dynamically quite much, monsters move, items get picked up, and so on. And it makes code more complicated. But one where it could be use is automapping feature. Player could remember where (s)he has visited and get map on that area (Note that isn't same that magic mapping). I think that possibility that there is ability cheat with 'superclient' isn't important. Mainly because there is not very much to gain. It's easier gain exp in the maps where you can kill trapped monster and gold collecting all those 'free' treasures on maps. And there is always some maps where this is possible. Only useful feature a can think is automatic 'read recall' when low hp's, but that probably cause more problem that it helps. Mud-players have done this kind of things and it's normally easy to detect. And binary distributions with RSA means much more work and many people don't like idea installing binaries from net, especially when it the network game. Good luck to new maintainer Mark Wedel. He probably needs it :) -Tero From crossfire-request Mon Jan 31 09:07:27 1994 Return-Path: Received: from bolero.rahul.net by ifi.uio.no with SMTP (8.6.4/ifi2.4) id ; Mon, 31 Jan 1994 09:07:21 +0100 Received: by bolero.rahul.net id AA06119 (5.67a8/IDA-1.5); Mon, 31 Jan 1994 00:07:17 -0800 Date: Mon, 31 Jan 1994 00:07:17 -0800 From: Mark Wedel Message-Id: <199401310807.AA06119@bolero.rahul.net> To: crossfire@ifi.uio.no, kjetilho@ifi.uio.no Subject: Re: Patches, ftp, new releases. Status: RO I suppose the one positive side of the integration is that it is pretty likely that I will be very familiar with the code after I finish it. Hopefully, it won't take too much time to integrate the two versions into one. Mark Wedel master@rahul.net From crossfire-request Mon Jan 31 08:52:15 1994 Return-Path: Received: from bera.ifi.uio.no by ifi.uio.no with ESMTP (8.6.4/ifi2.4) id for ; Mon, 31 Jan 1994 08:52:15 +0100 From: Kjetil Torgrim Homme Received: from localhost by bera.ifi.uio.no ; Mon, 31 Jan 1994 08:52:14 +0100 Date: Mon, 31 Jan 1994 08:52:14 +0100 Message-Id: <19940131075214.17230.bera.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: Mark Wedel's message of Sun, 30 Jan 1994 23:15:06 -0800 <199401310715.AA02595@bolero.rahul.net> Subject: Re: Patches, ftp, new releases. Status: RO I will be taking over maintenance of the crossfire list shortly. Our mail administrator has been to Usenix, and got back to work half an hour ago. (He has a mail queue of things to do some 600 messages long...) You may send unsubscribe messages directly to me the next couple of days, I'll tell you when crossfire-request points at me. --- Mirrors are generally one-way, so you must put your changes at ftp.ifi.uio.no, Mark, lest your files disappear altogether. --- Indeed, the differences between crossedit 0.7 and crossfire 0.90a must be sorted out whether or not we do the server/client thing (and we will, of course, eventually). The unified diff 1.7 MB.... Good luck Mark :-) Some points in favour of each: Crossedit 0.7 has removed omaps, better system for archetypes and named bitmaps, a special font file for speeding up reading pixmaps and probably lots more. (technical things, you see) Crossfire 0.90a has randomly generated artifacts (ie. a sword can become sword of Moria), encounters (randomly generated sub-maps), cursed/damned items (you should identify), special magic item types (rods (recharging wands), horns) So Crossfire 0.90a has many playability enhancing additions. Unfortunately, Crossedit has changed the directory structure of the code as well. What I am trying to say - it will be a lot of work merging the two whatever you do. BTW, Crossedit 0.5 was integrated at some point. Frank has it all in CVS, so if _you_ find an interesting date, you can get a snapshot (modulo the erratic frequency of check-ins :-) --- Frank *has* tried to use Purify, but he couldn't get it to link... Let's hope you guys have more luck with it. Kjetil T.