Reset is bugging me

That's probably something to do with how your scenario is coded. Just to be sure: you are using the latest Greenfoot version? If so: can you share the scenario somewhere?

Thank you davmac and danpost for your prompt response. To allow you to assess the problem, I have uploaded the scenario to the gallery and made the listing available. please excuse the lack of comment within this unfinished project. I await your comment.

Interesting thing. If you click on compile a few times, you will see that it will only compile every second time. So you can only compile if it wasn't compiled before. In other words, you can only compile if the scenario is not running right now. What might cause the problem is, that you create the puzzle randomly and if it doesn't have 25 solutions in it, you create it again. If you insert 'System.out.println(count);' in line 162 (so right before 'if (count<25)'), then you will see that it has to do the whole thing for quite many times. But probably not since it is working every time, when the scenario wasn't running when trying to compile. If you comment out the 'stopped' method, it works as it should. But of course this should prevent players from pausing the scenario when not finding something fast enough.

Thanks. I think there may actually be one or two Greenfoot bugs here. However, a lot of the problem is caused by this in your Reckon3 class: Basically your scenario refuses to allow itself to be stopped, which is a large part of the reason why reset doesn't work. I suggest you just take that out, it's not clear to me why you have it there anyway.

The remaining issues are caused by your use of 'static' variables in the Marker class. You should either not use static variables, or be sure to reset them to initial values when the initial world is instantiated. 'static' variables cannot be automatically reset by Greenfoot.

davmac : Thank you. The following code prevents the user from pausing the program and cheating the countdown while they work out the items to find. Is there another way to prevent this? public void stopped() { Greenfoot.start(); } I will ensure that all of the 'static' variables are reset at the end of each game before a new game is selected. However, my initial enquiry was to determine whether or not the reset could be disabled as all of the game control methods are incorporated within the program. Locking the initial screen was a problem that the user might encounter without realising unaware that the program works without having to touch the reset button at all. I thank you again for the time that you have taken to sort the problem on my behalf .

Ah, so that was deliberate. Unfortunately there's no other way to achieve the same thing; and in the meantime, that code provokes a Greenfoot bug which prevents the new world being created when you click "reset". I understand that, but the answer is basically no. You would need to modify Greenfoot itself, or do some hacky wizardry (which would rely on Greenfoot internal implementation details) to remove or disable the button.

If you need more information, here are some past discussions on the same or similar topic: http://www.greenfoot.org/topics/43 http://www.greenfoot.org/topics/1062 http://www.greenfoot.org/topics/1605 http://www.greenfoot.org/topics/2152 http://www.greenfoot.org/topics/3492

davmac: My gratitude to you for persisting with this problem on my behalf. I am no expert so hacky wizardry is probably not on the cards. In fact my 68 year old brain has had enough problems getting thus far. Added to the fact this is my the first project in java, I am indebted to Greenfoot that has guided me well to this point. I will investigate via the other topics you suggest to determine how much further I can go with this. My aim eventually was to convert it to Android. - I am persistent if nothing else. Thank You.

Maybe you should use the system clock instead of an act counter in your scenario. That way, stopping the scenario will not stop the countdown. and cheating is eliminated.