Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!pasteur!sham!scotts From: scotts@sham.uucp (Scott Silvey) Newsgroups: comp.windows.x Subject: Re: xtrek problem Summary: run both xtreks on one machine Keywords: xtrek Message-ID: <6999@pasteur.Berkeley.EDU> Date: 1 Nov 88 02:10:03 GMT References: <8810171520.AA28417@ATHENA.MIT.EDU> Sender: news@pasteur.Berkeley.EDU Reply-To: scotts@scam.UUCP (Scott Silvey) Organization: University of California, Berkeley Lines: 30 Xtrek actually composed of 3 programs ... a full game can have 17 to 21 different processes all on the same machine. Run 'xtrek' on the faster machine. This will start the daemon. Then run 'xtrek machine2_name:0' to get an xtrek running with i/o going to and from the second machine (make sure you have xhosted the daemon machine from the second one). This way all the processes can coordinate with the same block of shared memory. Incidentally, v4.0 is VERY old. There are several new versions running here at Cal 'XtrekII, The Next Generation', and 'xtrek v5.0'. They mainly sport various ship types along with new weapons, starbases, and scoring systems that keep track of your performance in various categories. An attemp was made at having custom ship design, but this worked out poorly and actually detracted from the fun. XtrekII also has a super-user ship in the form of the AT&T 'Death Star' logo. Sort of an insider here where we are fans of BSD. A major re-write will be made in the near future that will be independent of the windowing interface. In fact, we will encourage players to write their own custom interfaces. Hence, the game will no longer be called 'Xtrek'. Here at Cal we have little problem with CPU power ... our main clinch is network traffic which makes the game quite frustrating. We intend to restructure the game so that the client actually does some of the processing and the information that will have to travel back and forth will be minimized. Scott Silvey scotts@scam.berkeley.edu