Declaring static data that doesn't take up dynmem space

Because we’re limited to unsigned integers (BTW, please please please at least let us have signed integers someday!), and things like tangents and square roots are Right Out, I’m having to use lookup tables to enable a part of a game that involves ranges and bearings. So I’ve got this:

(global variable (bearings table [[45 63 72 76 79 81 82 83 84 85]
		 		                  [27 45 56 63 68 72 74 76 77 79]
				                  [18 34 45 53 59 63 67 69 72 73]
				                  [14 27 37 45 51 56 60 63 66 68]
				                  [11 22 31 39 45 50 54 58 61 63]
				                  [ 9 18 27 34 40 45 49 53 56 59]
				                  [ 8 16 23 30 36 41 45 49 52 55]
				                  [ 7 14 21 27 32 37 41 45 48 48]
				                  [ 6 13 18 24 29 34 38 42 45 48]
				                  [ 5 11 17 22 27 31 35 42 42 45]]))

…which is taking up 200 bytes worth of dynamic memory, but it isn’t actually a variable, and should be able to sit in static memory. (And would do, if I were writing this in ZIL.)

If I drop the “global variable” bit and do

(bearings table [[45 63 ...] ... [ ... 42 45]])

that would be a predicate with one parameter, which becomes a per-object flag, and the list isn’t an object, so that should barf.

If I write

(bearings table $Table)       ($Table = [[45 63 ...] ... [... 42 45]])

…is that the pattern that I’m supposed to be following? (A short section in the manual on how to do this would be a spiffy addition.)

well, I’m actually a Naval Historian, and coding this type of thing is part and parcel of my research, but I use proper languages (C, Fortran, Pascal, and for those frequent quick’n dirty work, python, perl, even old interpreted basic) and not IF languages.

If you’re writing a parser-based Naval IF, count me as potential ßtester… at your risk ! :wink: )

Best regards from Italy,
dott. Piergiorgio.

2 Likes

If “naval” includes outer space, I may take you up on that. :slight_smile:

(I also have an idea for doing “serious” training games for cruising sailboats at some point, which might be of interest if outer space isn’t.)

Oh, hang on, that second pattern,

(bearings table [[45 63 ...] ... [ ... 42 45]])

…actually works. Which, I guess, makes sense, since the third pattern should unify to the second. (It’s taking me a little while to start to wrap my head around what’s going on under the covers.) So is that the recommended pattern for declaring static data, then?

And now that I’ve filled out the table to 20x20, I get

Error: trek.dg, line 251: Rule too complex. Try breaking it into smaller parts.

…but it worked just fine when the table was partially filled out with zeroes. Is there some hard-coded limit that I’m exceeding? Reintroducing the third pattern of

(bearings table $Table)  ($Table = [[45 63 ...] ... [... 42 45]])

…fixes it, interestingly.