Did you account for the characters that are not persistent in the string storage? I have commented about them elsewhere. If I remember correctly, the character with value 13 should be avoided, as well as the character with value 92 (when followed by any other character, so no problem when the last character of the String) Also I'm pretty sure the range of values valid for a character that was persistent was not more than 128 or so. You can do a simple test offline (specifically to test the first) like so: for (int i = 0; i < 300; i++) // chars have min value 0, and 300 is just an arbitrary max here { UserInfo userInfo = UserInfo.getMyInfo(); userInfo.setString(0, "" + (char)i); userInfo.store(); userInfo = UserInfo.getMyInfo(); if (userInfo.getString(0).charAt(0) != (char)i) System.out.println("Error with character with value " + i); }

Thanks for pointing that out, I ran a bunch of tests, and I believe that the UserInfo string storage fully supports java strings, although I haven't tested every character. Each character in java has 2 bytes reserved, I believe, but that doesn't mean any two bytes maps to a unique character. Many characters only have one byte used, so I had to use one byte per character. I'll look into values 13 and 92, but I recall 13 was one of the test values I used, and it had no problems. If character 92 represents a carriage return or something, it would make sense that it would only be able to be used at the end, If that's true, I'll probably map value 92 to a different character outside the -128 to 127 range, same for 13 if I discover it's not working. I do know that negative values appear to work, but it could be that they're overlapping with larger positive values. Once again, thanks for pointing this out, I plan on running some more tests.

character 13 is carriage return, and weird - I just ran my own test again and values past 128 work now... I wonder if that was fixed/changed. If so wow, that's good news for my projects...

Well, like I said, many characters are two bytes, so I guess larger values translate to two byte values. Anyways, on another topic, are you planning on making any more online Greenfoot games? I plan on creating one, although I'm having a bit of trouble with figuring out how to check if a user is online. If you're interested in collaborating with me on another online game, that'd be great, but it seems you also have your own projects to work on.

Actually it seems the range of values [55296, 57343] are bad. (and 13 is still bad). And sorry, you must not of saw my reply before I took down my testing scenario. I will start a new discussion in a second.

bourne, when you say the range of values [55296, 57343] are bad (is bad), do you mean that values between 0 and 55296 all work when casted as characters?

Not overlap, char: The char data type is a single 16-bit Unicode character. It has a minimum value of '\u0000' (or 0) and a maximum value of '\uffff' (or 65,535 inclusive).

Oh, 16 bit translates to a maximum value of '1111111111111111' which converted into base 10 gives 65,535. I had thought that not every two-byte value combination results in a java character? Wait, that makes sense why values higher than 57344 don't work.

Sorry, didn't see your comment, but it only doesn't work past 128 if you're casting it to a byte first. Or so my theory goes (I really have next to no idea).

Every char is 16 bits. And right, but I wouldn't of cast to a byte. I was thinking maybe the storage server some reason had only allowed for byte size space for each character, when storing the strings. But not that way anymore I guess

All values in range [55296, 57343] were mapped to 63 (after storing and retrieving through UserInfo) - which is the character: '?'

Fixed the 13 bug, and the limit is now 50,000 instead of 128. Just a tiny improvement. XD. Solved it by mapping 13 to 50,001. Going to fix the 92 bug too by mapping 92 to 50,002

You should remap value 92 as well. Also, I just noticed the scenario doesn't seem to actually save my colors when reloading it. Like loading your colors gives me all red.

OH! I just realized the bug, bourne, when you reload the scenario, to avoid loading a user that didn't set values, as soon as you start the scenario with all red I store the red values. This isn't a problem with the classes I'm provided, it's a bug in the world class I use, I'll try and fix it later, but I think I'm going to retire for the night, I'll probably work on it in the morning.