jamesd@lakesys.UUCP (James Dicke) (06/15/88)
Hello,
I have been experiencing what I think may be a bug in ProDOS BASIC or ProDOS 8
(my version of BASIC 1.1 is dated 30-DEC-85 and my version of ProDOS 8 is V1.4
and is dated 17-APR-87).
I run a bulletin board that is really an adventure game. You exist in a city
that is actually a huge map of text characters. The map matrix is 160
characters wide (x) and 100 characters high (y). There is what I call a
"ground file" that goes with this map. It is simply a random access file
(record length = 70) that stores data on what is located in each position of
the map (160 by 100 = 16000 possible records). Now of course only about
50-100 records are ever actually used. The file is read as such:
1000 PRINT CHR$(4) "OPEN S.MAP.GROUND.CA,L70"
1005 R = X% + Y% * 160
1010 PRINT CHR$(4) "READ S.MAP.GROUND.CA,R" R
1015 INPUT DATA$
.
.
.
1090 PRINT CHR$(4) "CLOSE"
The ground "fill" (write) routine works in the same manner as the read. It is
common practice in the routines for searching the ground, to open and read the
file then generate an error (either END OF DATA error or RANGE ERROR if the
record number was higher then the highest record number written to previously).
The problem is (I think) with the "sparse" file routines. ProDOS dosn't
allocate space for unused records like DOS did (if I remember correctly), it
simply calculates where the data should be found. Anyway, the problems
occur when someone searches the ground at location X,Y and then moves one
square to the left (thus looking at a record # one (1) less then the one just
read, ie X-1,Y ). What happens is the exact same data is returned when an
error should have generated instead. This seems to occurs on records numbers
of all sizes, not just the very large ones. Thing is that someone can pick up
items found (like gold) in location X,Y and then shift over and have a good
possibility of finding the same items again. If they search the same spot
twice, nothing is found the second (provided they picked up the items the
first time), but something still may be found in the adjacent record.
This bug has eluded me for the longest time. It dosn't seem happen all the
time but enough to need fixing. I am an accomplished programmer (5 years
or more) and know what I'm doing for the most part. But I'd be glad to hear
all your suggestions (no matter how mundane they may seem).
Please reply in this newsgroup or send me mail!
jamesd@lakesys.UUCP
Call the infamous City of Aldimar adventure system @ (414) 527-4779
Not a BBS- but an ongoing adventure GAME in another world.