Here, screenshot, just because:

Yap, every If that uses a and or a or or any other operation like this requires parentheses in all the ones that aren't the first.

Just like Ashbad said and calc84maniac proofed.

An update on my progress today:

Something I thought would be useful, but not requested yet, was to made rand dereferencable.  So now ^orand returns the pointer to the seed.  One use is to use {^orand}^r to return the most recent number generated from a rand call.  Another unintended consequence which I was at first about to fix but decided to keep is that you can use rand as the variable in a for loop!  so For(rand,0,10) will actually work and use the seed as the location to store the counter.  This is great for programs that don't use random numbers and want an extra variable.  Just beware that any call to rand will change its value (which would screw your for loop)

Another thing I added was the ability to stack Fix commands.  So "Fix 135" is the same as "Fix 1:Fix 3:Fix 5".  Also, there is now a fixed jump table built into the app so hopefully applications like DoorsCS and zStart can take advantage of using some useful Axe features externally once I release the API.

getkey(key1,key2...)
This would check all of the keys with the corresponding getkey numbers and return the getkey number of the one that was pressed.

getkey(key1,key2...)
This would check all of the keys with the corresponding getkey numbers and return the getkey number of the one that was pressed.

I can't really think of a use for that, it seems to me like plain old getKey would do what you want. Although perhaps I'm not quite understanding your suggestion. Could you give me an example of how it might be used?

I don't feel great about bumping my own suggestion because I don't want to make it seem like I think my suggestion is more important than others. But in reality, it sort of is. I know you (Quigibo) have been leaning away from adding new commands and instead implementing parser and general application improvements, leaving new commands for Axiom programmers. I think this is a great idea, leaving the deep down technical stuff to the person who knows it best and leaving the job of writing commands to the general assembly programming populous. But it would be useful if Axiom programmers had a programming tool that currently only you have. There are commands that I'm literally just waiting for this ability to finally implement.

The Axiom system is great. Things like automatic jump and call replacements and manual 16-bit load replacements are great, which even the hard-coded Axe commands cannot do. But there's one thing that internal Axe commands can do whereas Axioms can't that I would love to be able to do. Would it be possible to add a new internal Axiom compiler feature that allows calls to be made with offsets? Perhaps a new macro like ld b,b \ .db BYTE \ .org $-2? Because this would be incredibly useful for calling a command in slightly different ways, like you often use with an optional buffer argument for drawing commands.

There are a few other command-adding abilities that only you have that would also be useful. For instance custom token replacements would be nice, even if they had limitations such as requiring Axioms to be at the very start of the program or only loading token replacements upon opening the program editor. The closer that Axiom programmers come to your ability to add new commands, the less we would have to bug you about adding commands.

Runer, how do you suggest I do the token replacement?  The first problem I had was that you have to know ahead of time what Axioms are being used in the program so it knows what to replace.  That can easily be solved with your first suggestion of always requiring the Axioms to come first, but this does remove a possible convenience, however its probably worth it.  The next problem is that for each token the Axioms have to be searched for in the symbol table to find their pointers, which could be costly with a large number of programs.  Then, when finally found, each Axiom would have to be scanned completely to find if the token matches by transversing the offset list (again, for each token).  So if you had 2 Axioms with 25 new commands each, and about 20 tokens on the screen, that's 40 symbol table searches + 1000 checks + the built in checks.  I could definitely see this causing lag in the scrolling.  There might be another way of caching the data in ram somewhere, and maybe setup a binary search, but this would greatly complicate things.  The token hook is only called when tokens are being printed and I don't want to use other hooks so its difficult to have some sort of "pre-parsing".  I am however still open to suggestions of what to name the rest of the custom override tokens.

Your other suggestion, If I'm reading this correctly, is a static offset to optimize doing ld hl,dynamic_ptr; ld de,offset; add hl,de; correct?  This might be an option in the future.  There are other useful features I can think of too, like adding the ability to create Axioms that take a label as their first argument, like how the current interrupt setup command works.