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