Extending the macro variable space

[rld]

One of the issues that larger ACK games tend to bump up against is the limited variable space which can be used by macros. Right now, there are only 52 general-purpose variables: A through Z and A2 through Z2.

I would like to see this expanded somewhat with a patch feature that would allow macros to access an extended variable space stored in a separate file. This would be implemented in a similar manner to the 'quest flag' dialogue settings that are stored in the .DQT/.DQS files.

The extension would allow up to 32767 additional word-sized variables that would be accessed using a raw numeric index. These extended variables could not be used directly in other commands; they would have to be copied directly to a standard ACK variable first.

Basically, there would be two new DRAW command hooks; something like:

DRAW 999 200 TO <index> <value> OF 0 0
DRAW 999 201 TO <index> <variable> OF 0 0

The first command (200) would set the extended variable at position <index> to the value <value>. The extended variables would be word variables, able to hold the same range of values (0-65535 unsigned or -32768 to +32767 signed) as the standard ACK variables H-Z and H2-Z2.

The second command (201) would retrieve the extended variable at position <index> and store its value in the standard ACK variable <variable>. This is required for the extended variable's value to be used in other commands, conditional tests, etc.

For simplicity's sake, all the extended variables will be kept in a single file, and that file will be saved/restored along with the rest of the game data in the same manner as .DQT/.DQS. The variables would be stored in a simple binary format, making the extended variable file a total of 32767*2 = 65534 bytes in length.

If anyone is interested, let me know and I will take a crack at implementing this for the next patch release.

[Heather Harrison]

This would be very useful for my Ultima II remake. If I had access to a larger variable space, there are a number of things I could do.

I currently have some variables that keep track of progress on various quests, and they are mostly accessed by macros. Since those are only used in localized parts of the game, they would be a great candidate for this. With more variable space, I would likely add a number of optional side quests that would reward the player with money, items, and/or experience.

(Of course, now the limitation in the number of macros and the 100-line maximum length could start to become a problem.)

Another use for these would be to handle bookshelves. I have been wanting to add a feature to search the shelves and find books, but determining which books are on which shelves could be a problem. Perhaps with these additional variables I could set a few for each town or dungeon, and these would govern which books are found on the shelves.

Your existing patches have been quite useful. Right now, I'm in the process of implementing the changes in tilesets. I'm using this to give different locations a different look to provide some variety. In a game as large as this, having the ability to change out tilesets is very useful.

Thanks.

Heather

[Tdarcos]

One of the issues that larger ACK games tend to bump up against is the limited variable space which can be used by macros. Right now, there are only 52 general-purpose variables: A through Z and A2 through Z2.

I used to use MU-Basic, which ran in 56K on a PDP-11. You could use the variable space they used. Make it simple on yourself, implement A-Z and A0-Z9, that's 286 variables. Probably be easier and simpler, and less trouble to implement.

If you think that's not enough, create named arrays, say A() to Z() and use those. These should be easy to scan and easier to implement than your proposed solution.

[Garth's Equipment Shop]

@rld: Can't thank you enough for your continuation of work on ACK during Chris's absence and for sharing your work with us.

@Tdarcos: Chris could possibly impliment that since he is the author of the code, though I think his own code from so many years ago was a bit hard for him to look at on a regular basis. He obviously got burned out on it.

Anyway, if Chris had some difficulty pouring over this old code and implimenting compatible updates which didnt break anything, just imagine how difficult it is for fans to hack the code like rld has been doing! And mind you, he hasnt even touched the main game engine as so far all attempts at doing so have broken it.

Correct me if im wrong rld. Im just recalling your disclaimer you were using at the beginning of all your old posts introducing the first mods you made. rld can better explain the limitations he is forced to work within right now.

[rld]

And mind you, he hasnt even touched the main game engine as so far all attempts at doing so have broken it.

Correct me if im wrong rld. Im just recalling your disclaimer you were using at the beginning of all your old posts introducing the first mods you made. rld can better explain the limitations he is forced to work within right now.

You have it right. I don't know if it's an issue with the build package, or something I need to configure differently in DosBox, but I haven't had any luck rebuilding any of the other game modules (other than the player module) from source.

The source package that Chris provided included automatic make files which allow either 'player', 'editors', or 'all' to be rebuilt. The 'player' setting rebuilds only ACK02 (the EXE and overlay), while the 'editors' setting rebuilds all the other modules (the map editor, macro editor, creature editor, etc, etc.).

'make player' works fine, and is what I have been using to do all the patch mods up to this point. However, trying to rebuild any of the other modules results in a 'Code segment is too large' error.

I'm pretty sure that I tried this on the original source package before making any changes, so I don't think it's due to my edits causing the compiler to run out of space. It's probably a configuration issue, but I'm not familiar enough with the compiler to dig into it any further.

Of course, there are advantages to only rebuilding the player module. This keeps the data files compatible between the official ACK build and the patched build, and it also reduces the amount of code that I have to understand. However, it does mean that many of the new features are more 'hacky' than I would like.

I had hoped that Chris would roll some of the patch features into upcoming ACK releases (cleaning up things in the process), but it looks like he is taking a (very well deserved) break from ACK at this point.

[Garth's Equipment Shop]

Any progress with this variable extension patch rld?

[Admiral Ackguh]

I have two tips that might help make the most of ACK's limited variable space.

1) Use the HELLO variables / pseudo-array.

There are 256 of them, one for each dialogue, fully usable by macros, and they work even if not all dialogues are used. For a dialogue exclusively used by a character, the HELLO variable makes a good state variable. If the dialogue is unused, or used for many characters - that frees up a HELLO variable for other uses.

2) Overload variables.

This requires knowledge of binary arithmetic.

Variables H-Z and H2-Z2 are 16-bit, storing values 0 to 65534. I rarely need all 16 bits of a variable, and a 16-bit variable can be used as two 8-bit variables, or 4 4-bit ones.
It is even possible to map out which bits in which variable are used for different purposes. To store and recall certain bits, use a bitmask, and the binary AND or OR operators (& and |). ACK has no logical shift functions, but multiplying and dividing by a power of 2 works just the same (but slower).