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
djenner@arthur.Eng.Sun.COM (Doug Jenner) (02/26/91)
In article <15239@chaph.usc.edu> jcollins@sal-sun84.usc.edu (James Collins) writes: > > 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 Answer: NONESUCH. Actually, all items and treasure in the default config- uration begin at sector [-3], which is NONESUCH, or nowhere. As monsters are killed a random roll is made vs. 1/2 of the max_hp of the dead critter plus 10* the danger level of the critter. If the roll is greater than this number there is no treasure [giving a rat a chance of .5*(5+(10*2)) or a 12.5, rounded to 12% of having goodies, while a Blue Dragon has a chance of .5*(105+(20*10)) or a 152% chance of having goodies.] Now just HAVING goodies isn't good enough. There are actually two kinds of goodies. Treasure (gold) and items. 50% chance of either. Unfort- unatly, items are awarded in a braindamaged manner. A for loop in put_item_tr() bashes through the list and allocates the first available treasure found, starting with the best stuff and working down into potions torches, and then into Widgets -- but at any given prize has a 50% chance of changing the more expensive prize for a cheaper one... The net result is you need to kill off monsters, collect the stuff, and DUMP IT somewhere so that the stuff won't get tagged as being in NONESUCH place and therefore available. Otherwise you can go head to head with a Wailing Horror and get a damn TORCH as your only reward, while at a late point in the game can see a newbie bump off a jackel and pick up Sword of Fury as the treasure. A much more enlightened approach would be to group the treasures by worth, such that the higher danger level critters get the more valuable the stuff will be worth. One possible way would be to modify the if statement that skips all stuff not in NONESUCH, that are crystals, or are cash prizes to also make sure the cash value of the prize is adequate (say, 10*(danger^2)-10). In this fashion, an anhkheg will cough up a prize of at least $30, while a Efreeti will have at least a Shimmering Shield (cash value $900). For the case in which no proper prize exists, you are just out of luck. Here are the diffs to implement such a plan (NOTE: these haven't been debugged, I just make them up on the fly, use at your own risk): 8<--- cut here 8<--- *** combat.c.orig Fri Feb 22 11:48:22 1991 --- combat.c Mon Feb 25 13:23:17 1991 *************** *** 696,702 **** switch(rnd(2)) { case 1 : ! put_item_tr(sector, x, y); break; case 2 : put_treasure(tval * 20, sector, x, y); --- 696,702 ---- switch(rnd(2)) { case 1 : ! put_item_tr(sector, x, y, danger); break; case 2 : put_treasure(tval * 20, sector, x, y); *************** *** 741,748 **** } ! put_item_tr(sector, x, y) ! int sector, x, y; { int i, choice; --- 741,748 ---- } ! put_item_tr(sector, x, y, danger) ! int sector, x, y, danger; { int i, choice; *************** *** 751,757 **** for(i = 0; i < pseg->item_count; i++) { if(pseg->itm[i].loc.sector == LOC_NONESUCH && pseg->itm[i].type != CRYSTAL ! && pseg->itm[i].type != CASH) { if(choice == -1 || rnd(2) == 1) choice = i; } --- 751,758 ---- for(i = 0; i < pseg->item_count; i++) { if(pseg->itm[i].loc.sector == LOC_NONESUCH && pseg->itm[i].type != CRYSTAL ! && pseg->itm[i].type != CASH ! && pseg->itm[i].value > (10*(danger*danger)-10)) { if(choice == -1 || rnd(2) == 1) choice = i; } 8<--- cut here 8<--- Comments? -- _Doug Jenner_ Model: Homo Sapiens, version 0.24, Alpha release djenner@sun.com The above views are those of the author, and not necessarily those of Sun Microsystems, Inc. 'Though I haven't really asked them about it.
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