Discussions

Default key-binding is Ctrl+Space. You can change it in the settings.

yes i think i was a bit blind with my code ive just seen it, ill change it to more a appropriate wording , thank you :) ill come back if it still isnt working.

Scale down your images in the files themselves. Also, remove any excess transparencies around the outer edges (top, left, right and bottom) of the images.

The question is a little bit difficult to understand. So, I will give you answers to some questions and hope that one of them is helpful for you. 1. How to change the current(-ly shown) world (while the scenario is already running)? Call the method Greenfoot.setWorld with the new world as parameter, e.g. <Code Omitted> 2. How can I set a different world to be the start world (=the current world at the start of the scenario)? Right click on the World class that you want to be used for the start world (e.

Awesome! Thanks for helping :)

I am sorry to hear about the circumstances and hope that at least my answer is helpful: There are two ways that I see likely to be successful: 1. Download an old version of Greenfoot (the version with which the scenarios had been created 10 years ago) and run the scenario in this old version. or 2. Adjusting the scenarios to the current version. Details: 1) === Download old version === If you click on the "Download" button above, you get to the Download section. There, on the bottom, there are links to the "version history" and "old versions of Greenfoot". "version history" will

Rotations pivot at the middle of the image. Make the center of rotation the middle of the image of the flipper.

Decreasing "world.interval" would cause stars to spawn more quickly.

In Mikey class fall method, you set velocity to zero prematurely (at line 38). The value is needed (at least, the sign of the value is) to determine if bumping head or landing on platform as well as in setting the location the actor should be relocated at if a collision does occur. Also, using didBumpHead and isOnSolidPlatform after moving vertically won't work as the platform could be anywhere with respect to the actor. I see no use for didBUmpHead at all. On the other had, isOnSolidPlatform is useful as far as a condition to jump provided

I guess the problem is that BOTH if blocks are executed if the player collides with the wall from the left. Let's have a detailed look at that scenario (colliding with a wall with velocityX > 0):

ohh sorry dint see this <Code Omitted>

Thanks Danpost! I ended up changing it up while I was waiting for a response but I have a new question now, for which I'll post as a new discussion. Please check it out whenever you can! :)

Another way is to place multiple bricks at the same location (to act as "one brick" with multiple hit capability) -- one actual brick for each time the "one brick" is to be hit. Then, simply (in Ball class): <Code Omitted>The first line is to "reduce the health"; the second line is to rebound off a still existing brick (though, just not the same one). The code for bouncing off a brick is to be put in the new method, bounceOffBrick. This will actually require nothing but

There are two ways to make your actor stay in the air longer. One is just to make it jump higher. The other is to lower the effect of gravity while maintaining it as a positive value. Here, you will have to decrease the jump force to compensate for the change in height achieved. Since you cannot keep gravity positive by decreasing the integer value of one, you will need to start using partial pixel values. This is done by tracking and using the location coordinates of the actor as ei