Reading that 0 being the end of data thing, I assume if we ever need to use those routines in a game for an item menu, for example, that we must make sure that no item ID are equal to 0, right? For example, for an empty item slot it would be 1, potion 2, elixir 3, etc?

Solution: inData(A+1,Data(1,2,3,0))

A is just whatever zero-based value you wanted to check. Adding 1 makes it 1-based so the comparison data can be null-terminated.

Don't forget that inData() only works with 8bit numbers (1-255) it won't work with 16-bit numbers.  I could add an inData()^r to take care of that but it would be slower.

EDIT: @DJ, he means that if your possibilities were 0,1,2,3 then instead of doing inData(A,Data(0,1,2,3,0)) which wouldn't work, you could do inData(A+1,Data(1,2,3,4,0)) which would work because now you are comparing values that are in the right range.

Here's the description from the commands list:

inData(BYTE,PTR) Key: inString()

Searches for the byte in the zero-terminated data. If found, it returns the position it was found in (starting at 1). If not found, 0 is returned.

The first argument accepts a byte value. Because Axe variables and math functions return two-byte values, this means that the high byte will be discarded. This argument essentially accepts whatever you enter mod 256.

The second argument accepts a pointer to data. In this data should be a series of byte values which will be stepped through one by one and checked to see if they are equal to the first argument (mod 256). The end of the data is signified by a zero so the search doesn't continue infinitely. For this reason, zero has to be reserved for the terminator and cannot be a value you want to compare.

---

Breaking down a more specific example, like: If inData(A+1,Data(2,7,17,0))

In the first argument, A represents whatever 0-based number, say an item ID, that you want to check. However, because 0 is reserved for the terminator of the data, we add 1 to it to shift all the item IDs to essentially be 1-based.

The second argument isn't really data itself. The data is defined somewhere in the bottom of the program, and this argument is instead given the value of a pointer to that data. As noted earlier, this data that is pointed to should be a list of nonzero byte values to check if the first argument is equal with, and the data should be terminated with a 0. Because 1 was added to our first argument to account for the fact that 0 is reserved for the terminator, 1 would also be added to the values we want to compare against. In this case, I wanted to compare against the values 1, 6, and 16, which turn into 2, 7, and 17 when 1 is added to them.

Finally, when the routine is run, the data is stepped through byte by byte, checking to see if a byte from the data equals the first argument (mod 256). Let's say we wanted to check if a selected item was a consumable potion, and item IDs 1, 6, and 16 were the potions present in our game. If the selected item ID (A) was 16, this value would be increased by 1, giving 17 for the first argument. This would then be checked to see if it equals 2, 7, or 17, which are the item IDs of the potions all plus 1. It doesn't equal 2 or 7, but it does equal 16. The routine would return the position of the match value, in this case 3, because the third element matched. For our purposes, all we really needed to know is whether or not a match was present, but inData() returning the match position works for this. Any match position returned will be greater than or equal to 1, which will make our IF statement true. If the item ID were 5, it wouldn't match any of the three values in our list. Once the routine hit a zero byte, it would know the searching was done and return a 0 for no match, making our IF statement false.


I hope this helps clarify things a bit

Double-clicked?

Anyway, that's a pretty clear explanation, thanks!

Whoops... someone delete the first one lol. I must've done something weird when editing it and instead created a second post instead of just editing the first one.

Either or.

As in, if A and B , then  A or B is also true. A xor B is not true

Quote from: squidgetx on November 14, 2010, 08:06:26 pm

Either or.

As in, if A and B , then  A or B is also true. A xor B is not true

So, the whole statement is true only if one (i.e. A) is true and the other (i.e. B) is not?  Or am I completely off?

Also, I was wondering about the !
Is
!If X=2 and C=3
the same as
If X=/=2 and C=/=3
or does the ! only apply to the first term?

the !If should apply to the whole statement.

The logic table for xor is:
0 xor 0 = 0
0 xor 1 = 1
1 xor 0 = 1
1 xor 1 = 0

Okay, I get it now. Thanks!

No problem.  Tis what we are here for. ;-)