Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!zephyr.ens.tek.com!tektronix!reed!minar From: minar@reed.bitnet (Nelson Minar,L08,x640,7776519) Newsgroups: comp.sources.games.bugs Subject: Re: Does Stanley Shebs exist? (was Re: xconq docs) Message-ID: <15360@reed.UUCP> Date: 23 Aug 90 06:31:05 GMT References: <1990Aug14.202517.12939@viewlogic.com> <7575@ucdavis.ucdavis.edu> <15341@reed.UUCP> <9835@goofy.Apple.COM> <15356@reed.UUCP> <1158@cluster.cs.su.oz> Sender: news@reed.UUCP Reply-To: minar@reed.bitnet (Nelson Minar) Organization: Reed College, Portland, OR Lines: 50 In article <1158@cluster.cs.su.oz> jaa@cluster.cs.su.oz (James Ashton) writes: >I'm not sure we need hacking by someone unfamiliar with X and who is >likely to be busy and later to move on anyway. I concur (speaking as the person who is unfamiliar with X) >You'll notice that many of the 5.3 bugs are due to the new features >added since 5.1 When we've an apparently bug free version for people >to use, then we can start on souped up versions. Good point. Get it working first. I might add at this point that whoever did 5.3 was fairly sloppy with it, and we should really avoid mistakes like that. >Sometimes when a unit enters a base with low supplies it seems to be >forgotten. We've had this happen to bombers, transports. Survey mode >shows the unit to exist but it never gets any moves. Units in bases >still manage to achieve negative supplies. I think this is one of the 'features' of xconq, rather. What happens is that your fully-fueled transport will move into a base, and the base will say 'oh, I don't have any fuel - lets take it from the transport' and so your transport loses (out of fuel). Its not funny when you trap your battleship in a base this way, and the only way to get it out is to move infantry into the base, have them give over their fuel, and disband them. (bringing up the issue of supply lines, an interesting .per capability). Anyway, this is (I am told) actually setable in the .per file. If one sets it the other way (and I regret I do not know offhand what the 'other' way is), moving objects tend not to get fueled automatically (you have to do it by hand), but they never get trapped at least. >Restorations still cause core dumps often. Same here. >In multiplayer games there are problems when most of the players have >finished and are in survey mode. The game never seems to get to asking >the still moving players to move their final few units. It looks like >it's hung up on one of the survey mode players and wakes up when they >use a mouse click to examine a unit. I hadn't noticed the last bit, about other players survey modes locking things up. I think its actually the same problem as you relate below: >Things are definitely much too slow anyway, we find commonly more for >some players than others. You can spend most of your time in move mode >waiting for the machine to think of a unit for you to move. I suspect some non-clever code concerning finding the next piece to move.