[comp.sources.games.bugs] MDG is NEAT! Um...

dean@coplex.uucp (Dean Brooks) (02/21/91)

Hey!

   I just wanted to let everyone know that the recently posted MDG
is neat!  It has everything you could want from a multiplayer
dungeon game.  It has about every feature a multiplayer-hack type
game could get.

   However, there appears to be a small problem with curses when
running.  The screen is drawn almost correctly, except for misplaced
items (like the ". HOME HOME HOME ." string).  They get thrown
on the screen at the wrong position.  This only happens when you
first strat the game, or you redraw with CTRL-L.  When moving from
room to room, everything draws perfectly.

   Curses on our machine is pretty solid, so I would say there is
a refresh problem somewhere.  Any clues?

   (Also, the $LIB/players/default file was missing from the
    distributed source) 
                                            Dean
--
dean@coplex.UUCP   Dean A. Brooks
                   Copper Electronics, Inc.
                   Louisville, Ky
UUCP: !uunet!coplex!dean
 
   

thomas@hotb.radig.de (Thomas Brettinger) (02/24/91)

In <1991Feb21.021206.1085@coplex.uucp> dean@coplex.uucp (Dean Brooks) writes:

>Hey!

>   I just wanted to let everyone know that the recently posted MDG
>is neat!  It has everything you could want from a multiplayer
>dungeon game.  It has about every feature a multiplayer-hack type
>game could get.

True. It is really a pretty nice game.

>   However, there appears to be a small problem with curses when
>running.  The screen is drawn almost correctly, except for misplaced
>items (like the ". HOME HOME HOME ." string).  They get thrown
>on the screen at the wrong position.  This only happens when you
>first strat the game, or you redraw with CTRL-L.  When moving from
>room to room, everything draws perfectly.

I did not notice this, but another problem relatet to screen io:
on the console or the virtual screens, the game is running fine.
But it hangs on a serial line at a fputs(SOMETHING, stderr) statement.
As if this wasn't enough, if I go through it with a debugger,
everything works perfectly allright. Maybe I discovered a bug in ISC's
io libs but has anyone had similar problems?

>   (Also, the $LIB/players/default file was missing from the
>    distributed source) 
>                                            Dean

I created an empty file and gave myself hitpoints using a text editor
:-)

Thomas

-- 

"Oh boy, virtual memory! Now I'm gonna make myself a REALLY BIG ram disk!"
-- lennox@shire.hw.stratus.com

john@jwt.UUCP (John Temples) (02/25/91)

In article <1991Feb23.191404.4767@hotb.radig.de> thomas@hotb.radig.de (Thomas Brettinger) writes:
>I did not notice this, but another problem relatet to screen io:
>on the console or the virtual screens, the game is running fine.
>But it hangs on a serial line at a fputs(SOMETHING, stderr) statement.

I found possibly the same problem with ESIX.  The game runs fine from the
console.  I ran it from a serial port, and it would always hang during one
of the initial fputs(WHATEVER, stderr) calls when mdg first loads.  But --
I replaced the serial driver with FAS 2.08, and the problem went away.
I wonder if the ESIX and ISC asy drivers have common heritage, and have
some sort of bug?  Did you try a test program that just does
fputs(WHATEVER, stderr) to see if it hangs?  I've no longer got the stock
asy drivers in my kernel, so I can't test this.
-- 
John W. Temples -- john@jwt.UUCP (uunet!jwt!john)

jcollins@sal-sun84.usc.edu (James Collins) (02/25/91)

  This game is pretty neat, but I javen't found any items excet for doohicky's and widgets.   The Trader's were empty so where's all the good stuff, like swords and armor?

							James

dmw@prism1.UUCP (David Wright) (02/28/91)

In article <1991Feb23.191404.4767@hotb.radig.de> thomas@hotb.radig.de (Thomas Brettinger) writes:
>I did not notice this, but another problem relatet to screen io:
>on the console or the virtual screens, the game is running fine.
>But it hangs on a serial line at a fputs(SOMETHING, stderr) statement.
>As if this wasn't enough, if I go through it with a debugger,
>everything works perfectly allright. Maybe I discovered a bug in ISC's
>io libs but has anyone had similar problems?
	It works fine under SCO Unix 3.2.2 at 38.4K to a Wyse 60.

			dave