@Override is an annotation - you can take it out and it'll still work exactly the same, but it tells the compiler that you intend that this method overrides another one in a superclass. If that method then actually doesn't override another method (say if you mistyped it or something like that) the compiler will generate an error, making it dead easy to see where you've gone wrong. If you miss it out and mistype it then it'll run and you'll probably have to do some debugging before you work out what's wrong. So it's not required, but it is a good habit to get into :-)

Isn't it easier just to say: public class Wanderer extends Actor { private int x, y; public void setLocation(int x, int y) { this.x = x; this.y = y; } public int getX() { return x; } public int getY() { return y; } }?

Hah, I was so (wrongly) convinced that it wouldn't work without some sort of special "empty image" to disguise it I didn't bother trying without it! Thanks for the observation, I'll post an update :-)

Why does that work? Doesn't that just override the greenfoot setLocation, so instead of moving the Actor, all you do is change some local variables?

Ah, I didn't realise Ninto's code doesn't have the call to super.setLocation in it - that does need to be there. It'll still move without it, but things like the collision checking won't work properly (or at all) when you don't put the super call in (the setLocation method in the Actor class is also responsible for updating the location of the bounding box of the actor used for collision checking.) The super method call will also cause an exception to be thrown if the actor isn't in the world, which is less important but still useful for debugging. However, it'll still move the actor since getX() and getY() are overriden correctly, and these methods are the ones used in the paintObjects method in WorldCanvas when determining where on the canvas to paint each actor. So in that sense the getX() and getY() methods in actor are kind of bypassed by the painter (greenfoot.gui.WorldCanvas around lines 114-117 if you want to download the source and have a look to see what I'm on about!)

Hi, I would like to have this Wanderer effect in my Tossing scenario that using SmoothMover & Vector class. Which methods should I override?

You just need to download the source and put the wanderer class in your scenario so it's a superclass of whatever you want to "wander." So if you put it in your project and then do something like: public class Ball extends Wanderer and then edit wanderer to extend whatever Ball was previously extending, it should work. (Obviously replace ball with whatever actor it is you want to wander outside the world!)

Sorry, I haven't had a chance to test this out yet! Is it just with actors that extend the Wanderer class? I thought it worked ok for me when I tested it... I'll have another look at some point.

I finally wrote codes to override collision offscreen! :D :D :D :D :D :D (one now can use the getOneIntersectingObject and other similar methods)

lime, I was just about to do the same thing but since you have already done it.. Where can I find your code? (I don't like reinventing the wheel - even if it does give you a pair of wheels....)

Greenfoot 2.0 has just been released and includes full support for unbounded worlds, including off-screen collision checking. As well as a bunch of other cool features! To create an unbounded world, add an additional "false" argument when you call the World class constructor, eg "super(500,500,1,false);".