Discussions

If you were to put a comment on the 'canSee' method, it should read: <Code Omitted>The center being the location gotten from '(getX(), getY())'. So, the 'shootPlayer' method will need to use something else to determine when to fire. It will also need another condition to limit how often a projectile is fired when the player is in range. This can be a random chance thing or a regular or randomized timer.

Thankyou Super_Hippo and nolttr21

Got it working -thank you!

This is before your moving things around. What I see here is that you move and then check for collision. But the 'originalX' and 'originalY' are acquired after moving; so, it is like -- good luck moving back. That is, they acquire the new coordinates of the actor -- not the original ones.. Now, with the new code, I see you checking collision before moving. How is this to work if the actor is

I would, first off, think that line 4 would show an error and the project would therefore not compile. Also, line 15 looks like it may produce some errors during specific circumstances. It also looks like a single sheep could produce an abundance of new sheep when eating grass. Insufficient code was given to determine why you are getting your current behavior. Please show the code for the entire Sheep class.

right after the "int a = 0;" line add this line without the quotes: "public boolean clickedOnce = false;" then use this code in place of your Click() method <Code Omitted>

You can click the buttons along the bottom of the window while running the scenario to view the codes used.

Constructors, in general, do not have anything to do with any actors in the world. I do not understand what you mean by "movement is done in a constructor". Certainly, the object being created is not yet in any world; so, "movement" is meaningless for it at the time the constructor executes. The turrets need to keep a reference to the hull they belong to so they can move with them.

The size of an actor is defined with its image. So if you change the size of the image, the size of the actor changes as well.

One way is to make the field 'static'. But you must ensure that you zero the field in your initial world constructor or the value will carry over from game to game. However, if all soldiers are removed from the world when they die, you do not have to keep track of how many are still in the world. You can simply use the following in your World subclass act method: <Code Omitted>

Thanks, I think I'll use this approach. Have you seen my other post about retrieving stacked objects being non-deterministic? I have trying to come up with visualization scenarios for a Stacks using actors and these guys appear to be randomly selected from the list of objects at the same location... I'm wondering what performance improvements are gained by hashing (?) the actors into the set/list vs adding them either FIFO or FILO orders. Any way to specify a different collect class at runtime? Thanks again, Mr Bradley

ah that was it. the sounds folder had a copy in the desktop. the scream was saved into that one. thanks

The detecting of 'space' being down will be triggered multiple times during a single press of the key. You would need a field to track the state of the key to determine the moment that the key goes down:

thank you for the solution

I see. So that means i have to use the Greenfoot.mousePressed(), Greenfoot.mouseClicked(), etc to determine what happened. Thanks for the reply!