1D String Arrays, and how to call the data in the string to print.

Using an ancient tool of the past, can have some issues. I have been looking at my older brother's books from the 80's on the topic of BASIC programing for a Text Adventure. And since the PDF's have been released to everyone I can link to the exact book itself. https://drive.google.com/file/d/0Bxv0SsvibDMTYkFJbUswOHFQclE/view Understanding that I probably will not be able to get a majority of the code from the main program working, I have been more interesting in the explanations found in it. The way that things were encoded for low memory and other useful ideas for the planning out each step of the project. Since I have seen the DIM command used in example programs and I decided to try following the book a little with adjusting the grammar. PAGE 19 has the following (with Smile Basic) adjustments

DIM O$[W]
DATA "PAINTING,RING,MAGIC SPELLS,GOBLET"
FOR I=1 TO W
READ O$[I]
NEXT I

With the code corrected to Smile Basic standards, when tested the program just says OK. I was thinking that the READ command might regurgitate the previous list of words and print the string. So I might be a little over my head because I can't tell if this worked or if I failed. My question is what command do I need to print the data included in the new 1D string, or am I just experimenting with ye oldde stuff that is not even compatible? The title of the project is "The Three Orders of the Spork" a Fantasy Text Adventure.

the DATA should be written like:

DATA "PAINTING","RING","MAGIC SPELLS","GOBLET"

You need to iterate over the array using a FOR loop, and print it out manually. READ only writes the data to the variable given (in this case, O$[I]. Also, indexes in SmileBASIC are zero-indexed, so the first element in the array is 0, and the last is W - 1. Finally, DATA in SB is like this:

DATA "PAINTING", "RING", "MAGIC SPELLS", "GOBLET"

I'd also recommend that you make I to I%, as not to waste memory.

The main changes that need to be made:

• Labels are @NAME instead of numbers (you can just add @ to the start of all the label numbers and in GOTO/GOSUB)
• arrays range from 0 to length-1 instead of 1 to length.
• arrays are accessed with [ ] instead of ( )
• use == instead of = to check if two values are equal
• use != instead of <> to check if two values are not equal
• ON ... GOTO/GOSUB starts with 0 instead of 1
• strings in DATA must be inside quotes

(you've probably figured many of these out already) Other than these changes, you can use almost all of the original code without major modifications.

Wow, thanks for all the help. this should help me move on to the next step. And I don't particularly plan to be memory friendly as the current plan won't be more then a 8x8 layout, with no more then 4 interactions per any single room. I don't really plan on using the exact formula included in the book, unless I really get stuck. But thanks for checking the source code to see if there is any major problems. However I might take the time and convert the whole thing, just out of curiosity now that I know it really might work. So the only thing left is how do I PRINT out the DATA again (in any order from the list)? Do I use...

PRINT "you see a book of ";O$[2];"."

for "you see a book of MAGIC SPELLS."

Wow, thanks for all the help. this should help me move on to the next step. And I don't particularly plan to be memory friendly as the current plan won't be more then a 8x8 layout, with no more then 4 interactions per any single room. I don't really plan on using the exact formula included in the book, unless I really get stuck. But thanks for checking the source code to see if there is any major problems. However I might take the time and convert the whole thing, just out of curiosity now that I know it really might work. So the only thing left is how do I PRINT out the DATA again (in any order from the list)? Do I use...

PRINT "you see a book of ";O$[2];"."

for "you see a book of MAGIC SPELLS."

Yep, you're good!

Okay thanks!!

You won't have to worry about running out of memory in a text adventure game, since SB has access to 8 MB of RAM

I'd also recommend that you make I to I%, as not to waste memory.

Instead of adding % to the end of all your integer variables (I assume this game was written for versions of BASIC that only supported integers anyway), you can put OPTION DEFINT at the start of your code, so that all number variables will automatically be integers. But really, none of that matters since SB has a ton of memory.

entirely unrelated to the question at hand but ok

opinions don't dictate best code practice but whatever :P i personally use % and # for semantics

DIM O$[W]
DATA "WORD","GOING","HERE"
FOR I=1 TO W
READ O$[I]
NEXT I

?"THIS ";O$[1];". A"
GOSUB @A 
?"OKAY"
WAIT 20:END

@A
WHILE(BUTTON()!=16)
 VSYNC 1
WEND
RETURN

returns an error on the 7th line (1 is the first line above.) "Subscript out of range" So I thought that would work, as posted above. (maybe I made a typo??)

Stupid question... is W defined?

Stupid question... is W defined?

Hmm... That is a good question. I'm not certain if the book enplanes that on another page or not. (Just goes to show how GREAT the Smile Basic examples in program are) When I add a line at the top that reads

W=4

The ERROR becomes OUT of DATA in 0:5 showing that it starts counting the words at 1, 2, 3 and when I searchs for the 4th string can't find anything... so OUT of DATA. If I adjust the value of W to 3

W=3

a slightly different error as before pops up. Subscript out of range in 0:5 interestingly the error points to line 5

LINE 5|||  READ O$[I]

Array indexes start at zero and not one, so the FOR loop would be from 0 to W-1. The first entry would be entry 0, second 1 etc. And yeah, W needs to be the number of data entries you have or everything screws up. You could, though, accomplish the data copy in one command:

COPY O$,@WORDS,W

Your DATA statement would have to have the label @WORDS on the line directly before though. I would recommend you put it in its own block somewhere after the main code (data and labels are compiled so it doesn't really matter where they are.)

@WORDS
DATA "WORD"," WORD",WORD"

In an attempt to supplement the test program with the COPY command, it currently looks like this:

W=3
COPY O$,@WORDS,W

?"THIS ";O$[1];". A"
GOSUB @A 
?"OKAY"
WAIT 20:END

@A
WHILE(BUTTON()!=16)
 VSYNC 1
WEND
RETURN

@WORDS
DATA "ITEMS","GOING","HERE"

When RUN it says

THIS W. A

I don't really plan to bother with keeping the value "W" if this is the problem... But the COPY command seems to ignore the @words, and only look at the "W" as the string, rather then the value "W". I am completely open to other format suggestions, but I seem to keep running into problems. I am still interested in learning how to load a 1D array with words, but alternatives are acceptable if it will speed up the current rut my game is in.

In an attempt to supplement the test program with the COPY command, it currently looks like this:

W=3
COPY O$,@WORDS,W

?"THIS ";O$[1];". A"
GOSUB @A 
?"OKAY"
WAIT 20:END

@A
WHILE(BUTTON()!=16)
 VSYNC 1
WEND
RETURN

@WORDS
DATA "ITEMS","GOING","HERE"

When RUN it says

THIS W. A

I don't really plan to bother with keeping the value "W" if this is the problem... But the COPY command seems to ignore the @words, and only look at the "W" as the string, rather then the value "W". I am completely open to other format suggestions, but I seem to keep running into problems. I am still interested in learning how to load a 1D array with words, but alternatives are acceptable if it will speed up the current rut my game is in.

It took me the longest time to figure out why this doesn't work, but now I do! You didn't do DIM O$[W] so it thought O$ was a string and not a string array. There's a lot of stuff going on that allowed this program to run without fail; it's technically doing what it's supposed to, even if that's not the desired result. I'll try to explain everything weird here without confusing you. First off, unless you set OPTION STRICT, normal variables (read: not arrays) don't need to be explicitly declared. So even though there was never a declaration of O$ in your code, SB's program parser/loader saw it and implicitly decided it was a string, not a string array. You didn't declare it, so it decided for you :P. Second off, strings are functionally equivalent more or less to arrays of characters. Many array features can be applied to normal strings, as well as a few other behaviors. One of these things is the ability to use COPY on strings as if they were arrays of characters. Finally, labels are converted to strings when in an expression. This sounds really weird, I know. But it makes sense to know that all calls to GOTO also accept a string as argument, so it's only reasonable that labels implicitly become strings. You can even do something like PRINT @LABEL and the output will be the string "@LABEL". Now that you know all this, we can understand why O$[1] became "W". As I had mentioned earlier, array indexing is zero based. The first entry is 0, second is 1, and so on ad nauseum. It just so happens that the second character (or in array talk, the 1st) of the string "@WORDS" is "W"! Why would the label string be getting into O$ though? As I had said, you didnt define O$ as an array, so the system saw it and thought it was a string. Now we get into string COPY. When the destination of COPY is a string, it doesn't care whether or not the source is a label or a normal string. Because labels become string implicitly, it copied the characters from the string "@WORDS" into the string O$, which led to O$[1] being "W". If you don't understand everything I'm saying, don't worry, you will eventually. This is a lot to take in all at once, lol.