Greenfoot 2.2.0 beta

Busch2207: the getTop and getNearby methods state in the documentation that they can return null, so you should have code ready for that -- the most prominent example is that null will be returned if the user is not logged in. However, Davin is right: providing you were logged in, storage should be available. I've looked in the database, and there is some data stored for that scenario for Busch2207. The current exception I get for your code is: But without seeing the source code, it's hard to debug the problem, and hard to decide if the issue is with Greenfoot, or with your scenario. Could you either publish the source, or email it to nccb@greenfoot.org and/or davmac@greenfoot.org (if you haven't sent it to davmac already)? And, @tylers: what happens when you try to install it? Where/how does it fail?

Ok, to anyone else who wants to try out the beta: Please be ready to provide detailed information if something goes wrong or doesn't work. This means:

• actually read any error messages, and follow their instructions (if any)
• Tell us what is going wrong. Not just "it doesn't work" or "there is a bug" - *what* doesn't work, what did you try exactly, what happened.

Thanks!

I've checked my code and now shouldn't be a problem with a NullPointer Exception... But the Informations aren't saved at all... I even can't see any HighScore, by playing it on the webpage... (The Informations are a String and the Score They should be saved int the 'Save()'-method in the world class) Sorry. I forgot to publish the source Code! It was late yesterday. x) Now he's published: http://www.greenfoot.org/scenarios/4578

Yes! Of course! She is always used, when anything was changed in the PlayerData class. (I point to the Save() method in the 'world'- class.)

I believe I might have figured out the problem, and it's my fault! The storage on the server is limited to 50 characters per string. Unfortunately, I failed to mention this when writing the public documentation for the PlayerData class. What's happening is that you're trying to store 60 characters in one string (which is fair enough, I never mentioned the 50 limit until just now!) and the server is failing to write this to the database because of the length limit. So you'll need to fix your code to store less than 50 characters in each string (i.e. by splitting your 30 level scores across the 5 strings), and we need to (list for my own benefit as much as anything else...):

• Update the PlayerData documentation
• Enforce this 50-character limit locally, so it matches with the server behaviour
• Either print a message on stdout when you store data that's too long or throw some exception, to help track down this problem
• Ensure that store() returns false when you pass it something with a string that's too long (both locally and on the website)
• We could alternatively let the store succeed, but truncate the string being stored. Not sure I like silent failure, though.

Ah, ok! Good to know that! :D That don't make it easier, but it's understandable! x) I even tried to store up to 120 characters. x) But now it works! :D Thank you guys! :D

K_O_P told, since level 20 (include) are no more levels saved... I tried it, but it saves all my scores of every level... He reopened his browser and now it works... So I think, there's maybe a problem with the PlayerData-class...

I just went to the scenario again, and K_O_P says in a comment that it's now fixed :-) More generally, do you think it's likely to be useful if the scenario creator was able to view the database dump for their scenario, via the web interface? So if you went to your own scenario on the Greenfoot website, there could be a link for "view saved data", which would show a table something like: I sense it might be useful for tracking down bugs that users report with your scenarios (e.g. "my game has saved but won't load properly"). We could equally offer the download as a CSV file, which would have the added bonus that you could download it, save it as "storage.csv" in your Greenfoot scenario directory, press Ctrl+Shift+P to become user_with_bug (or whoever), and test what happens. Edit: I think I know what K_O_P's issue was, I think the socket connecting to the server times out too easily, and we don't currently attempt reconnection. Hence, re-opening the browser re-established the connection. I'll look at fixing that next week, but until then I think there might be an issue that if you go too long between communications with the storage server (e.g. user goes to make a cup of tea!), the connection might be lost until they refresh the scenario or re-open the browser (not sure which, off the top of my head).

I think it would be very useful for creators to be able to view the database dump for their scenario, both for bug testing, and also to gather statistics if they so chose.

Ah, this is great! I've just started work on multiplayer capabilities and it's going pretty well :) Also, maybe a PlayerData.get(String username) could be useful. A simple method that gets a given user off of the stored data for the scenario for specific work.

DonaldDuck: Thanks for the suggestion. So that we can better consider whether it's worth adding, can you explain exactly how you would use it -- in what circumstances would you know a username and want to get the data? Would one user's string data reference another?

In API style: PlayerData get(string username) Get the PlayerData for a specific user. Returns: The equivalent of PlayerData.getMyData() for the given username. Throws: Exception ex if the user could not be found. Also, while I remember, a PlayerData.getPosition(int position) could be useful, where the method returns the PlayerData of the user at the given place (sorted by the users score) or throws an exception if there's no user at that position. Enough complaining though, PlayerData was an awesome addition, thanks for your hard work!