Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83 (MC840302); site turing.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!mit-eddie!godot!harvard!seismo!mcvax!turing!aeb From: aeb@turing.UUCP Newsgroups: net.games Subject: Re: ungrateful mangy rabid dog in hack (actually mklev bug) Message-ID: <238@turing.UUCP> Date: Thu, 17-Jan-85 01:06:23 EST Article-I.D.: turing.238 Posted: Thu Jan 17 01:06:23 1985 Date-Received: Sun, 20-Jan-85 05:29:59 EST References: <302@wjvax.UUCP> <316@flame.UUCP> <585@genrad.UUCP> Reply-To: aeb@turing.UUCP (Andries Brouwer) Organization: CWI, Amsterdam Lines: 22 Apparently-To: rnews@mcvax.LOCAL > Has anyone noticed Hack hanging when going down a level. I finally broke > out of the game (I don't remember exactly what I did), but I noticed two > days later that an invocation of "mklev" was still chewing up CPU time. Yes, my little brother stumbled over this same bug just the other day. The bug occurs in some ancient code in mklev.c that I never got around to fixing; what happens is that with rather low probability mklev fails to create an acceptable level map; in despair it then calls itself again, but unfortunately the random generator is initialized with the same value so that this unlikely event will repeat itself until you hit the interrupt. You may choose between various temporary fixes: 1. ignore the bug (probably you'll never see it [again]) 2. remove the exec("mklev") call from mklev.c, and accept a possibly disconnected level map 3. use srand(time) instead of srand(getpid()) One of these days I'll post a set of diffs upgrading hack to version 1.0.1 The new mklev.c always produces correct maps so that there is no need for a recursive call in desperation. -- Andries Brouwer -- CWI, Amsterdam -- {philabs,decvax}!mcvax!aeb