All static pointers are distinct.  Even Str1 and Str01 are not the same.  GetCalc currently only works for appvars and programs so graph database files can not be read.

You can kind of get the Nth data pointer if all the data is the same size and declared consecutively.  If you have:
:[C0FFEE]->Str0
:[DECAFF]->Str1
:[CAFE00]->Str2

You can get the Nth pointer here by doing "N*3+Str0"

There is another way to get the Nth arbitrary pointer (not consecutive not the same size) but its a little more complicated and involves pointers to pointers.

Enjoy your stay   Hope you enjoy industrial portions of peanuts...

I am also a bit confused about what you're asking about.  A library is just a list of subroutines.  Like if somebody makes a tile mapper or physics engine or something, then you can call those routines from your main program.  Like if your program was prgmA and you said sub(prgmTM,D) this would call subroutine D (lets say that's a drawing command for the tile mapper) from the tile mapper library.

I'd like to ask about library files now.

First of all, I think they will be handled slightly differently than regular source files.  Their header will be in lowercase to distinguish them, and they won't show up on the compiling list to reduce clutter since they're never compiled standalone anyway.  The libraries will basically just be a big list of subroutines that can be called from the main program.

Next thing is how to reduce naming conflicts since the labels are only 2 letters.  Although I plan to eventually allow labels up to 8 letters, right now there is a high chance for duplicate labels, especially if there are multiple library files included in the main program.  To avoid this, I am thinking of having a prefix for the subroutines like this: sub(prgmMYLIB,DW) will call the subroutine "DW" from the "prgmMYLIB" library.

The nice thing about the libraries is that only subroutines you actually USE will get compiled into the code.  That means if a library has 25 different routines, but you're only using 5 of them, only the 5 that you use get put into the program.  There is going to have to be some slight restrictions to the subroutines however, mostly, they cannot allocate data or use regular goto's and sub's, only library subs (including itself).

I haven't written any of this yet, I want to get an opinion first.  Does anyone have any other ideas?

Actually, there is a little trick you can use extract them.  Try this:

Input: X is the 16-bit variable

:X->B
:For(A,1,16)
:If B^2
:<What to do if the Nth bit from the right is 1>
:End
:B/2->B
:End

It will iterate and read all the bits.

If you just want a specific bit, the Nth bit on the right, then do this:

Input: X is the 16-bit variable
Input: N is which bit (in range 0-15):
Output: Returns the value of the bit.

:X->B
:For(A,1,N)
:B/2->B
:End
:B^2

Same as the difference between Hex and decimal, its just the way you write the number

For instance, the number "99" can be written

Hex: 63
Decimal: 99
Binary: 01100011

Binary mostly helps when you have a lot of Boolean variables (true/false) that you want to store into a single byte to save space since you can hold 8 of them per byte.

I think this is something I'll worry about when the time comes.  I don't think anyone is currently making any massive RPGs of this nature (but correct me if I'm wrong).

I don't think there's such a thing as garbage collecting messages in asm.  I could be wrong, but I've never seen it or heard about it before.  Its possible it might ask when the program quits and hands control back to the OS though.