Very cool. I remember you saying you were going to come out with this. Glad it is being worked on early

I haven't implemented any of it yet I'm debating what I wanna do in terms of using this stuff.

Congratulations you guys!

Ok, sorry. I'll try to explain. I'll use part of my actual map as the example. So my original map data goes as shown:

111111111111111
100300020000000
100305020000000
100300020000000
100344420000000
So the actual sting looks like:

"111111111111111100300020000000100305020000000100300020000000100344420000000→Str1
When I was going to compress the data the first time I ran into that issue you were saying, how like the first part will say "151." So instead of setting a limit, which I thought about, I decided I just wanted to compress this thing in whole without a limit to see how much memory I could save. But with the map being in numbers it was to hard to read so I came up with that second program:

"_"+Str1→Str2
For(A,2,1+length(Str2
sub(Str2,1,A-1)+sub("SATRWHM",expr(sub(Str2,A,1))+1,1)+sub(Str2,A+1,length(Str2)-A→Str2
End
sub(Str2,2,length(Str2)-1,Str2
So since each number represented a different tile I just matched the number up with a letter that represented the tile.

0=Space=S
1=Border Tree=A
2=Mid-Map Tree=T
3=Rock=R
4=Water=W
5=House=H
6=Mart=M

That program just replaces each number with its respective token turning the map into:

AAAAAAAAAAAAAAA
ASSRSSSTSSSSSSS
ASSRSHSTSSSSSSS
ASSRSSSTSSSSSSS
ASSRWWWTSSSSSSS
Therefore making the string now:

AAAAAAAAAAAAAAAASSRSSSTSSSSSSSASSRSHSTSSSSSSSASSRSSSTSSSSSSSASSRWWWTSSSSSSS→Str1
Using that string there is no issue reading "16A2S1R3S..." So now if I can get the decompression to work correctly you don't run into the issue of it reading three numbers in a row or only two or something. Does that make more sense?

Well just from looking at it it looks like those are all valid. Thanks. I didn't think about using u to store sub(Str1,B+1,1, though that is still a new thing for me. I'm testing it all right now. As for the set A to zero first thing, I thought of that but didn't wanna bother with adjusting things if it needed to be done at the time but I can look at it. It looks like you're right though, I think the only change would be to change row seven to Repeat u≠(Str1,B+A+1,1. As for the limit thing I'm not sure. I mean I know what you mean, since my original string was just numbers, but that's why I provided that second set of code to replace the numbers with a different token so it can be read easily.

So, as I was writing this it finished compressing and those changes did work. Though it took a little longer because, I think, it has to solve u each time it comes up. Which isn't a big deal though. I'm currently testing the changes with A.

As for a decompresser, I am still working on it. I'm close, I think. I got something to work but I don't think it worked properly because the final string ended up being like 200 bytes less than it normally is The weird part is that the beginning and end both match up just fine though, so I don't know what is going wrong with it (unless someone else can explain a loss in bytes).

And again, while writing this the changing A program finished and it seemed to work as well. I'll make these changes to the first post though. Thanks again, nemo.

I believe its the String>Equ( command that is the useless one.  But for some reason it doesn't go both ways.  You need Equ>String() to transfer an equation to a string, but you dont need String>Equ() to transfer a String to an equation o.O

Ya, Builder, I think you're right. That is yet another thing that TI failed upon Thanks for clearing that up

Oh, sorry, I didn't explain that right about the error. You get the error when it's being displayed since you are adding C to B you will end up with a 95 and 96 as your x-coordinate therefore causing the error. I didn't mean when going through the string.