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!)

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 :-)

This is the problem: java.lang.IllegalArgumentException: Could not load image from: AurtyCast.png at greenfoot.GreenfootImage.loadURL(GreenfootImage.java:151) at greenfoot.GreenfootImage.loadFile(GreenfootImage.java:172) at greenfoot.GreenfootImage.<init>(GreenfootImage.java:75) at greenfoot.Actor.setImage(Actor.java:277) at Aurty.<init>(Aurty.java:27) at wTera.mPopulateAurty(wTera.java:502) at wTera.act(wTera.java:322) at greenfoot.core.Simulation.runOneLoop(Simulation.java:274) at greenfoot.core.Simulation.run(Simulation.java:158) It sounds like the old image case problem - it's worth checking you're referencing all of your images in the source code in the same case that they are as files - otherwise it can cause errors when uploaded to the gallery!

Not sure why google throws up those ones first, but if you search for "herman binary scenario" then it'll give you this page as the first result.

@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 :-)