This site requires JavaScript, please enable it in your browser!
Greenfoot back

Comments for Reusable UserInfo Support Classes

Return to Reusable UserInfo Support Classes

bournebourne

2013/12/30

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); }
shrucis1shrucis1

2013/12/30

Thanks for pointing that out bourne, I'd written a longer response to this, but I seem to be having troubles with posting comments.
shrucis1shrucis1

2013/12/30

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.
shrucis1shrucis1

2013/12/30

It seems my comments are getting posted delayed... Maybe it's just my internet connection.
bournebourne

2013/12/30

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...
shrucis1shrucis1

2013/12/30

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.
bournebourne

2013/12/30

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.
shrucis1shrucis1

2013/12/30

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?
bournebourne

2013/12/30

Correct, well the range of values [0, 55295]. I ran my test above with the modification: for (int i = 0; i < Math.pow(2, 16); i++)
shrucis1shrucis1

2013/12/30

I assume you get character overlap, right?
bournebourne

2013/12/30

Oh but not 13
bournebourne

2013/12/30

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).
bournebourne

2013/12/30

The value range [57344, 65535] did work
shrucis1shrucis1

2013/12/30

Really? So you can store 250 numbers between 0 and 65,535 (Excluding certain numbers mentioned above) using only the strings?
bournebourne

2013/12/30

Yes (though I was certain I tested this perhaps a year ago now, and it didn't work past like 128 or so)
shrucis1shrucis1

2013/12/30

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.
shrucis1shrucis1

2013/12/30

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).
bournebourne

2013/12/30

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
bournebourne

2013/12/30

All values in range [55296, 57343] were mapped to 63 (after storing and retrieving through UserInfo) - which is the character: '?'
A new version of this scenario was uploaded on Mon Dec 30 02:54:03 UTC 2013 Expanded limit to 50000, not yet sure if all numbers in this range work or not. Remapped the value of 13 to 50001, so setting a value to 13 would no longer fail.
shrucis1shrucis1

2013/12/30

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
shrucis1shrucis1

2013/12/30

If any further bugs arise, I'm pretty sure I have more than enough values to remap to.
bournebourne

2013/12/30

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.
shrucis1shrucis1

2013/12/30

That's odd... I loaded my own colors and got all red...
shrucis1shrucis1

2013/12/30

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.
bournebourne

2013/12/30

Sounds good
A new version of this scenario was uploaded on Mon Dec 30 03:16:10 UTC 2013 Remapped the value of 92, fixed a bug where your colors were overwritten every time you refreshed the scenario.