dean@coplex.UUCP (Dean Brooks) (07/13/88)
I have just recently obtained a copy of the source to ADL, the Adventure Definition Language used to create any kind of adventure. I successfully compiled the source without ANY problems whatsoever, but there seems to be something wrong with it. The adventure (.adl) files seem to compile with "adlcomp" FINE, but when I use "adlrun" to actually play the game it always gives an error and exits (it doesnt dump core tho). I was wondering if anyone had the same problem or if anyone knew of any bugfixes/patches that are available. We are running UNIX 5.2 on a PLEXUS P/75 (68020). I would GREATLY appreciate any help you could provide as I am very interested in this package. Thanks! Dean +========================================+===================+ |Dean Brooks @ Copper Electronics, Inc. | Gravity is a myth,| |4200 Produce Road, Louisville Ky. 40208 | The earth sucks. | |AT: (502)-968-8495 |=-=-=-=-=-=-=-=-=-=+ |UU: ihnp4!think!bloom-beacon!coplex!dean| Eat at Joes | |DO: dean@coplex.UUCP |=-=-=-=-=-=-=-=-=-=+ +========================================+===================+
kvp@daimi.UUCP (Knud V. Petersen) (07/14/88)
I also get run-time errors with adlrun, there is one error which I can make again and again, and it is typing to times <ENTER>, which will abort adlrun with a run-time error message. I also get other sort of error messages. Please fix the bugs !!!!!!!
greim@sbsvax.UUCP (Michael Greim) (08/02/88)
In <423@coplex.UUCP> Dean Brooks writes: < I have just recently obtained a copy of the source to ADL, the <Adventure Definition Language used to create any kind of adventure. < < I successfully compiled the source without ANY problems whatsoever, <but there seems to be something wrong with it. The adventure (.adl) files seem <to compile with "adlcomp" FINE, but when I use "adlrun" to actually play <the game it always gives an error and exits (it doesnt dump core tho). Which game?? What error? < < I was wondering if anyone had the same problem or if anyone knew of <any bugfixes/patches that are available. We are running UNIX 5.2 on <a PLEXUS P/75 (68020). < < I would GREATLY appreciate any help you could provide as I am very <interested in this package. Thanks! I played around a bit with adl. When I wrote my first dungeon I tried to get some demon running. I got a lot of core dumps until I figured out that I had specified too much brackets "(" and ")". The code for "adlrun -h" is buggy. I had some problems to get it running, and it still does not look very nice. Maybe if I have the time someday I will try to rewrite it. Maybe you could send me your dungeon (if you wrote one yourself) and I could check out on one of our VAX, SUN or PC-MX2 (by SIEMENS AG, the closest we have to SYS5) -mg -- +------------------------------------------------------------------------------+ | UUCP: ...!uunet!unido!sbsvax!greim | Michael T. Greim | | or greim@sbsvax.UUCP | Universitaet des Saarlandes | | CSNET: greim%sbsvax.uucp@Germany.CSnet| FB 10 - Informatik (Dept. of CS) | | ARPA: greim%sbsvax.uucp@uunet.UU.NET | Bau 36, Im Stadtwald 15 | | Phone: +49 681 302 2434 | D-6600 Saarbruecken 11, West Germany | +------------------------------------------------------------------------------+ | # include <disclaimers/std.h> | +------------------------------------------------------------------------------+
jaf@druhi.ATT.COM (John A. Frieman) (08/03/88)
In article <1520@daimi.UUCP>, kvp@daimi.UUCP (Knud V. Petersen) writes: > > I also get run-time errors with adlrun, there is one error which I can > make again and again, and it is typing to times <ENTER>, which will abort > adlrun with a run-time error message. > I also get other sort of error messages. > > Please fix the bugs !!!!!!! I just tried adlrun with the sample program aard and could not break it with the <RETURN> key. This is on an Ahmdal 580 running UTS 5.2.6. I will try it on my MS-DOS version to confirm this. The only responce I get is a "beg your pardon?", even after 20+ <RETURN>s in a row. Could you be more specific about your machine and OS? John A Frieman
cunniff@hpfcdc.HP.COM (Ross Cunniff) (08/04/88)
In article <579@sbsvax.UUCP> greim@sbsvax.UUCP (Michael Greim) writes: >In <423@coplex.UUCP> Dean Brooks writes: >< I have just recently obtained a copy of the source to ADL, the ><Adventure Definition Language used to create any kind of adventure. >< >< I successfully compiled the source without ANY problems whatsoever, ><but there seems to be something wrong with it. The adventure (.adl) files seem ><to compile with "adlcomp" FINE, but when I use "adlrun" to actually play ><the game it always gives an error and exits (it doesnt dump core tho). >Which game?? What error? Ditto. I would like to know this information as well. >< >< I was wondering if anyone had the same problem or if anyone knew of ><any bugfixes/patches that are available. We are running UNIX 5.2 on ><a PLEXUS P/75 (68020). >< >< I would GREATLY appreciate any help you could provide as I am very ><interested in this package. Thanks! >I played around a bit with adl. When I wrote my first dungeon I tried >to get some demon running. I got a lot of core dumps until I >figured out that I had specified too much brackets "(" and ")". What flags (in adltypes.h) did you compile with? If you compiled without the error checking code, errors WILL cause core dumps. The error checking code will catch most problems, but will cause the adventures to run more slowly. >The code for "adlrun -h" is buggy. I had some problems to get it >running, and it still does not look very nice. Maybe if I have the >time someday I will try to rewrite it. What bugs have you found in it? What kind of terminal are you using? It's been tested on HP terminals and on vt100's. >Maybe you could send me your dungeon (if you wrote one yourself) and >I could check out on one of our VAX, SUN or PC-MX2 (by SIEMENS AG, >the closest we have to SYS5) > > -mg Likewise. If you've written a dungeon with ADL, I'd be *GREATLY* interested in seeing a copy of it. Post it to comp.sources.games, or e-mail me a copy. >-- >+----------------------------------------------------------------------------+ >|UUCP: ...!uunet!unido!sbsvax!greim | Michael T. Greim | >| or greim@sbsvax.UUCP | Universitaet des Saarlandes | >|CSNET: greim%sbsvax.uucp@Germany.CSnet| FB 10 - Informatik (Dept. of CS) | >|ARPA: greim%sbsvax.uucp@uunet.UU.NET | Bau 36, Im Stadtwald 15 | >|Phone: +49 681 302 2434 | D-6600 Saarbruecken 11, West Germany| >+----------------------------------------------------------------------------+ >|# include <disclaimers/std.h> | >+----------------------------------------------------------------------------+ Ross Cunniff Hewlett-Packard Colorado Language Lab ...{ucbvax,hplabs}!hpda!cunniff cunniff%hpda@hplabs.ARPA
dean@coplex.UUCP (Dean Brooks) (08/07/88)
In article <5400002@hpfcdc.HP.COM> cunniff@hpfcdc.HP.COM (Ross Cunniff) writes: >> I have just recently obtained a copy of the source to ADL, the >>Adventure Definition Language used to create any kind of adventure. >> >> I successfully compiled the source without ANY problems whatsoever, >>but there seems to be something wrong with it. The adventure (.adl) files seem >>to compile with "adlcomp" FINE, but when I use "adlrun" to actually play >>the game it always gives an error and exits (it doesnt dump core tho). >>hich game?? What error? > >Ditto. I would like to know this information as well. > >What flags (in adltypes.h) did you compile with? If you compiled >without the error checking code, errors WILL cause core dumps. The >error checking code will catch most problems, but will cause the >adventures to run more slowly. > >>Maybe you could send me your dungeon (if you wrote one yourself) and >>I could check out on one of our VAX, SUN or PC-MX2 (by SIEMENS AG, >>the closest we have to SYS5) Let me clarify a few of the problems I have had with this. It seems that ADLRUN does weird things (like core dump or ignore all input) whenever I compile ANY adventure. This includes EVERY sample game released with ADL (let alone any I would write). One interesting note... Every time I compile a game, it gives two warnings. It says TELLER and PRINT(?) is undefined. Other than that the COMPILE seems to work fine. When I RUN the game, it core dumps or ignores all my input; it will say things like "I dont understand you". I have set up the adltypes.h correctly (to my knowledge). We have had no problems porting most other SYS 5.2 programs to our machine, so I would tend to believe other people are having this problem. Any clues? Thanks, Dean Brooks +========================================+===================+ |Dean Brooks @ Copper Electronics, Inc. | Gravity is a myth,| |4200 Produce Road, Louisville Ky. 40208 | The earth sucks. | |AT: (502)-968-8495 |=-=-=-=-=-=-=-=-=-=+ |UU: ihnp4!think!bloom-beacon!coplex!dean| Eat at Joes | |DO: dean@coplex.UUCP |=-=-=-=-=-=-=-=-=-=+ +========================================+===================+
greim@sbsvax.UUCP (Michael Greim) (08/09/88)
In article <438@coplex.UUCP>, dean@coplex.UUCP (Dean Brooks) writes: < < Let me clarify a few of the problems I have had with this. It seems < that ADLRUN does weird things (like core dump or ignore all input) whenever < I compile ANY adventure. This includes EVERY sample game released with < ADL (let alone any I would write). < < One interesting note... Every time I compile a game, it gives two < warnings. It says TELLER and PRINT(?) is undefined. Other than that Really STRING and TELLER are undefined. See the manual for their meaning. < the COMPILE seems to work fine. When I RUN the game, it core dumps or < ignores all my input; it will say things like "I dont understand you". < < I have set up the adltypes.h correctly (to my knowledge). We have had < no problems porting most other SYS 5.2 programs to our machine, so I < would tend to believe other people are having this problem. Any clues? Sounds like you came across some compiler bug. Or in adlrun there might be some assumptions like "pointers are the same size as ints" or "NULL is all bits zero". ADLRUN works on the computers I have available here, which all run some kind of UNIX(TM). I have tried it on VAX 11/780 (4.3BSD), SUN 3/160 (SUN OS 3.5), SIEMENS PC-MX2 (SINIX 2.1). I have not yet tried it on our VAX 86000 (ULTRIX). What machine do you have? -mg -- +------------------------------------------------------------------------------+ | UUCP: ...!uunet!unido!sbsvax!greim | Michael T. Greim | | or greim@sbsvax.UUCP | Universitaet des Saarlandes | | CSNET: greim%sbsvax.uucp@Germany.CSnet| FB 10 - Informatik (Dept. of CS) | | ARPA: greim%sbsvax.uucp@uunet.UU.NET | Bau 36, Im Stadtwald 15 | | Phone: +49 681 302 2434 | D-6600 Saarbruecken 11, West Germany | +------------------------------------------------------------------------------+ | # include <disclaimers/std.h> | +------------------------------------------------------------------------------+
greim@sbsvax.UUCP (Michael Greim) (08/09/88)
In article <5400002@hpfcdc.HP.COM>, cunniff@hpfcdc.HP.COM (Ross Cunniff) writes: > In article <579@sbsvax.UUCP> greim@sbsvax.UUCP (Michael Greim) writes: > >I played around a bit with adl. When I wrote my first dungeon I tried > >to get some demon running. I got a lot of core dumps until I > >figured out that I had specified too much brackets "(" and ")". > > What flags (in adltypes.h) did you compile with? If you compiled > without the error checking code, errors WILL cause core dumps. The > error checking code will catch most problems, but will cause the > adventures to run more slowly. Or course I did not compile with error checking code :-) > > >The code for "adlrun -h" is buggy. I had some problems to get it > >running, and it still does not look very nice. Maybe if I have the > >time someday I will try to rewrite it. > What bugs have you found in it? What kind of terminal are you using? > It's been tested on HP terminals and on vt100's. I am using a mostly vt100 compatible (sounds like "half pregnant" :-}) terminal with lots of more features. Thus I am using TERMCAP. I just checked, it seems I have set up the variables correctly. But of course I don't know if the program uses them correctly :-) I had to change some things. I don't know what the results were, but looking at the code they could be the reason for the problems of the original poster. The bugs were in adlscrn.c. Apply the following context diff: *** adlscrn.c.old Tue Aug 9 12:43:24 1988 --- adlscrn.c Tue Jun 7 17:46:22 1988 *************** *** 77,83 **** --- 76,85 ---- /* Initialize termcap */ if( (value = getenv( "TERM" )) == (char *)0 ) error( 29 ); /* Bad termcap */ + /* mg,7.jun.88, was if( tgetent( bp, value ) <= 0 ) + */ + if( tgetent( BUFF, value ) <= 0 ) error( 29 ); /* Bad termcap */ /* Get the number of lines on the screen */ *************** *** 89,96 **** (void)mygetstr( "se", STANDEND, 0 ); if( mygetstr( "cd", CLEAR, 0 ) == 0 ) (void)mygetstr( "cl", CLEAR, 1 ); ! (void)mygetstr( "ml", LOCK ); ! (void)mygetstr( "mu", NOLOCK ); #endif #if AMIGA --- 91,99 ---- (void)mygetstr( "se", STANDEND, 0 ); if( mygetstr( "cd", CLEAR, 0 ) == 0 ) (void)mygetstr( "cl", CLEAR, 1 ); ! /* mg,7.jun.88 : the third parameter from the next two calls was missing */ ! (void)mygetstr( "ml", LOCK, 0 ); ! (void)mygetstr( "mu", NOLOCK, 0 ); #endif #if AMIGA *************** *** 168,174 **** --- 171,180 ---- } } else { + /* mg,7.jun.88, was : *temp = '\0'; + */ + *where = '\0'; retval = 1; } return retval; My biggest complaint with adlrun is that is does not use the termcap capability CS to split the screen in two pieces. The top line is used to hold room name and score but it is scrolled off the screen every time when the rest of the screen scrolls. I had too much to do to fix this. Maybe you could look into it. > Likewise. If you've written a dungeon with ADL, I'd be *GREATLY* interested > in seeing a copy of it. Post it to comp.sources.games, or e-mail me > a copy. Hm. I have written a small test dungeon with 5 rooms, 2 problems and 1 dragon to try some of the features of adl. I am planning with some friends to write a big dungeon. Maybe on the AMIGA, maybe on UNIX, well we will post if anything comes out of it. Now something different: ADL is really quite nice, I enjoyed playing aard (What the heck is an "aardvark" anyway ??), and I am really amazed that adlcomp and adlrun are so *small*. So here's a big hand for the authors. ------------------------------------- (Even if the programs have bugs. What big program doesn't ??:-) -mg -- +------------------------------------------------------------------------------+ | UUCP: ...!uunet!unido!sbsvax!greim | Michael T. Greim | | or greim@sbsvax.UUCP | Universitaet des Saarlandes | | CSNET: greim%sbsvax.uucp@Germany.CSnet| FB 10 - Informatik (Dept. of CS) | | ARPA: greim%sbsvax.uucp@uunet.UU.NET | Bau 36, Im Stadtwald 15 | | Phone: +49 681 302 2434 | D-6600 Saarbruecken 11, West Germany | +------------------------------------------------------------------------------+ | # include <disclaimers/std.h> | +------------------------------------------------------------------------------+
cunniff@hpfcdc.HP.COM (Ross Cunniff) (08/11/88)
In article <589@sbsvax.UUCP> greim@sbsvax.UUCP (Michael Greim) writes: > In article <438@coplex.UUCP>, dean@coplex.UUCP (Dean Brooks) writes: > < > < Let me clarify a few of the problems I have had with this. It seems > < that ADLRUN does weird things (like core dump or ignore all input) whenever > < I compile ANY adventure. This includes EVERY sample game released with > < ADL (let alone any I would write). > < > < One interesting note... Every time I compile a game, it gives two > < warnings. It says TELLER and PRINT(?) is undefined. Other than that > Really STRING and TELLER are undefined. See the manual for their meaning. Correct. STRING is the NOUN used when the player enters a string in a sentence. TELLER is the VERB used when the player enters a sentence like 'Robot, go east then south'. If these are undefined, nothing BAD happens, you just don't get access to these features. > < the COMPILE seems to work fine. When I RUN the game, it core dumps or > < ignores all my input; it will say things like "I dont understand you". > < > < I have set up the adltypes.h correctly (to my knowledge). We have had > < no problems porting most other SYS 5.2 programs to our machine, so I > < would tend to believe other people are having this problem. Any clues? > Sounds like you came across some compiler bug. Or in adlrun there might > be some assumptions like "pointers are the same size as ints" or > "NULL is all bits zero". ADLRUN works on the computers I have available > here, which all run some kind of UNIX(TM). I have tried it on VAX 11/780 > (4.3BSD), SUN 3/160 (SUN OS 3.5), SIEMENS PC-MX2 (SINIX 2.1). I have not > yet tried it on our VAX 86000 (ULTRIX). > What machine do you have? It's unlikely that there's any code assuming that pointers are the same size as ints, since ADL has been ported to IBM-PC's running MS-DOS. It's quite likely that there's code assuming that "NULL is all bits zero", although I haven't run across it. Could you e-mail me a copy of your modified adltypes.h as well as a brief description of your machine (i.e. byte order in long ints; what does NULL look like; number of bytes in an int, a short, a long, a pointer; what is the operating system like (BSD, SysV))? ADL itself has been ported to the following computers and operating systems (as far as I know): Hewlett-Packard 9000, series 300 (68020 based workstation running a BSD, SysV hybrid) Hewlett-Packard 9000, series 800 (RISC-based computer running a BSD, SysV hybrid) VAX 11/780 running 4.2 BSD Microvax II running VMS IBM PC running MS-DOS 2.0 Amiga personal computer (68000 based PC running a custom O/S) > My biggest complaint with adlrun is that is does not use the termcap > capability CS to split the screen in two pieces. The top line is used > to hold room name and score but it is scrolled off the screen every > time when the rest of the screen scrolls. I had too much to do > to fix this. Maybe you could look into it. Well, that's sort of a feature, since not all terminals have memory lock. I suppose that I could have some flag for if the terminal have memory lock and use it if so. ADL version 4.0, anybody? > > Likewise. If you've written a dungeon with ADL, I'd be *GREATLY* interested > > in seeing a copy of it. Post it to comp.sources.games, or e-mail me > > a copy. > Hm. I have written a small test dungeon with 5 rooms, 2 problems and > 1 dragon to try some of the features of adl. I am planning with some > friends to write a big dungeon. Maybe on the AMIGA, maybe on UNIX, well > we will post if anything comes out of it. That would be interesting to see! > Now something different: > ADL is really quite nice, I enjoyed playing aard (What the heck is > an "aardvark" anyway ??), and I am really amazed that adlcomp and adlrun > are so *small*. > So here's a big hand for the authors. (*blush*) Thank you. Oh, an aardvark is a funny animal that eats ants. > (Even if the programs have bugs. What big program doesn't ??:-) Bugs? What bugs? :-) > Michael T. Greim > Universitaet des Saarlandes > FB 10 - Informatik (Dept. of CS) > Bau 36, Im Stadtwald 15 > D-6600 Saarbruecken 11, West Germany Ross Cunniff Hewlett-Packard Colorado Language Lab ...{ucbvax,hplabs}!hpda!cunniff cunniff%hpda@hplabs.ARPA
greim@sbsvax.UUCP (Michael Greim) (08/19/88)
In article <5400003@hpfcdc.HP.COM<, cunniff@hpfcdc.HP.COM (Ross Cunniff) writes: < In article <589@sbsvax.UUCP< greim@sbsvax.UUCP (Michael Greim) writes: < < [stuff deleted] < < < It's unlikely that there's any code assuming that pointers are the same < size as ints, since ADL has been ported to IBM-PC's running MS-DOS. Were the bugs fixed which I have mailed you in my last posting or did they just never occur? < It's quite likely that there's code assuming that "NULL is all bits zero", < although I haven't run across it. Could you e-mail me a copy of your < modified adltypes.h as well as a brief description of your machine < (i.e. byte order in long ints; what does NULL look like; number of bytes < in an int, a short, a long, a pointer; what is the operating system < like (BSD, SysV))? ADL itself has been ported to the following computers < and operating systems (as far as I know): < < Hewlett-Packard 9000, series 300 (68020 based workstation < running a BSD, SysV hybrid) < Hewlett-Packard 9000, series 800 (RISC-based computer < running a BSD, SysV hybrid) < VAX 11/780 running 4.2 BSD < Microvax II running VMS < IBM PC running MS-DOS 2.0 < Amiga personal computer (68000 based PC running a custom O/S) < I assume you mean the original poster and not me. Add SIEMENS PC-MX2 (SINIX 2.0 [SYSIII/Xenix derived]) and SUN 3/160 (OS 3.5) to your list. Adl is alive and kicking here. < < My biggest complaint with adlrun is that is does not use the termcap < < capability CS to split the screen in two pieces. The top line is used < < to hold room name and score but it is scrolled off the screen every < < time when the rest of the screen scrolls. I had too much to do < < to fix this. Maybe you could look into it. < < Well, that's sort of a feature, since not all terminals have memory lock. < I suppose that I could have some flag for if the terminal have memory < lock and use it if so. ADL version 4.0, anybody? You need not memory lock (ML/MU), but CS (change scrolling region). Normally this feature is not entered in Termcap specifications, because vi and (standard) curses don't use it. Maybe I will add it if I have the time. < < Ross Cunniff < Hewlett-Packard Colorado Language Lab < ...{ucbvax,hplabs}!hpda!cunniff < cunniff%hpda@hplabs.ARPA -mg -- UUCP: ...!uunet!unido!sbsvax!greim | Michael T. Greim or greim@sbsvax.UUCP | Universitaet des Saarlandes CSNET: greim%sbsvax.uucp@Germany.CSnet| FB 10 - Informatik (Dept. of CS) ARPA: greim%sbsvax.uucp@uunet.UU.NET | Bau 36, Im Stadtwald 15 voice: +49 681 302 2434 | D-6600 Saarbruecken 11, West Germany # include <disclaimers/std.h>
ajw@donk.UUCP (ajw) (08/30/88)
A while ago, dean@coplex.UUCP (Dean Brooks) wrote: > Let me clarify a few of the problems I have had with this. It seems > that ADLRUN does weird things (like core dump or ignore all input) whenever > I compile ANY adventure. This includes EVERY sample game released with > ADL (let alone any I would write). I had just the symptoms you described when porting ADL to the Atari ST, which is 68K-based. Eventually, I found the bug causing the problem; it might work for you too. In .../adlcomp/routcomp.c, change the last statement of getglob() from newcode ( CALL, 2L ); to newcode ( CALL, (int16) 2 ); -- Alan Waldock ...uunet!littlei!ihf1!mdt!ajw ajw@mdt.hf.intel.com Opinions individual author's. Read before breaking seal. No warranty implied.