Posting the code to your initial world class would be a start. Btw, there are ways to avoid closing out totally and restarting greenfoot. Commenting out the code in your initial world class (except for the constructor 'super' call') and using the debugger to 'Terminate' the project will usually do the trick.

I'll put in two bits of code. I'll put in the initial world class as you requested, and I'll also include the class that has the bit that I suspect is clogging the software. Here's the initial world class: (first time posting code. I hope I followed all of the guidelines :3) And here's the class containing the part I find suspicious: If need be, I can also put in the superclass of the Trajectory object, but to save space, I won't include it unless requested.

I'm kind of just throwing ideas here, but would the fact that an act() method is being called from within a while loop (and thus faster than it was intended to be called) have any sort of contribution to the problem? I mean, if so, I can just have it call a different method that virtually does the same thing as super.act(), but without actually calling another act() method.

Indeed! Calling 'super.act()' from within a while loop will have the one actor acting (without any other actions taking place) until that actor (the Trajectory object) is removed from the world. If it is never removed from the world, your project will appear to freeze. What is your reasoning for attempting to place the 'super.act' call in a while loop? What were you attempting to accomplish with that?

Well, in my scenario, I have an abstract Projectile class that handles all flying objects (including their precise movement, ricochets, etc.), and I made this Trajectory object a subclass of that Projectile superclass. The reason for this is because I want the enemies to know where their projectiles are going to end up going BEFORE they shoot, otherwise they end up being stupid and often shooting themselves or their fellow enemies. My solution to this would be to have a no-texture object "scout out" the trajectory that a hypothetical projectile would follow if fired along that path (if that makes any sense). This object (the Trajectory object) would have to move basically instantly in order to quickly feed the enemies the trajectory information they need. So I figured that I'd have it follow its whole path in one act-cycle as opposed to over several act-cycles. In order to save myself having to copy and paste the movement and ricochet methods from the superclass to the subclass, I figured I'd let the super.act() method handle all of that. Apparently this causes major problems when the conditions you described roll out. Sorry for long post :3. I wanted to thoroughly answer your question.

Two things you should know: (1) methods in a superclass, unless declared 'private', are automatically available for use in a subclass through inheritance; (2) the 'act' method of a superclass (which is also inherited) will run for a subclass if that subclass does not override it; In other words, by removing lines 15 through 20 in the Trajectory class, all objects of that class will be controlled by the act method in the Projectile class (its superclass).

There are two things that are puzzling me. The first is the use of all the List object for the different type actors and the boolean array seem to be quite extravagant. There is no need for the List fields as fields are for thing that need to be retained between act cycles where you are continuously re-assigning the contents of the lists immediately upon entry into the act method (their previous references are ignored entirely). With the array, a simple int field can be used to assign an 'id' and its value bumped upon assignment; thereby assigning a unique value to each of whatever is being identified. Finally, I am not sure about the 'prepareLevel' method. If it is removing ALL actors from the world (which is difficult to determine with the currently given code), then you could just use:

I see. I have some responses to your statements / questions. I'll try to go in order. 1. / 2. The reason for me putting super.act() within a while loop that is within the act() method of the Trajectory class is because I want the Trajectory to basically spawn, do its thing in one act cycle, and then disappear. If I remove lines 15-20 altogether, and let the Projectile act() method run its course, the Trajectory objects will simply move at the speed of regular projectiles, which defeats the whole purpose of me adding them. As for the lists, is there perhaps a better way to keep track of how many actors there are of each type? If so, I'd rather use that, as I understand that what I'm doing is horribly inefficient (basically re-initializing the entire set of Lists every act cycle). As for your alternative method to assigning unique IDs to each actor, I don't know why I never thought of your method myself. I suppose it was because, at the time when I first made the boolean list, I was thinking I could improve and develop the system into a more grand and overall-more-useful system. It seems that such a system is not necessary. Finally, perhaps using removeObjects(getObjects(null)) is a far more efficient way of removing (just about) everything. I will change my prepareLevel to include that instead of removing each List of objects individually. -end comments- I think I have an idea as to how I can condense the entire lifespan so-to-speak of the Trajectory objects into one act cycle: instead of calling another act cycle, I just call a series of private methods that will virtually do the same thing without having to go through the Greenfoot act() method (if that makes any sense whatsoever - probably doesn't). Do you have any thoughts / improvements for this idea?

Without the List fields, you can just replace the field names with the method calls used to assign the objects to the lists. For example, when removing line 85 (and line 7), you would then change line 97 to this: or which checks for the same thing, but is more efficient. The thing is that a List of all actors in a world is retained by that World instance and the 'getObjects' method can create a sublist containing one type of Actor or all types of actors. This suggests that what you were doing was creating a redundancy by adding all those List fields in your subclass of World. As far as the trajectory of a projectile, you can only form a "perfect world" case as to the path. How would you account for ricochets and such without having other actors moving at the same time? Maybe you can explain the aiming process that initially determines where a projectile is to go.

I have read your reply, and I now understand your first point. I will be sure to update that as soon as I can. Thank you for the clarification on that, by the way. For your second point (the question), instead of typing a ridiculously long explanation of it, I will demonstrate with a brief video (not in Greenfoot) of my idea. I'm more of a visual person, so I can probably explain it better and with fewer ambiguities and loopholes this way. I will add (or edit in) a second post to an unlisted YouTube video that will contain that video.

Here's the unlisted video. https://youtu.be/ZnlKHWdvOQA

You probably do not want any projectile to be continuously ricocheting off of the edges of the world and want to set a limit as to how far they will travel before being removed (if missing the target tank). You could set this limit in number of act cycles in the world or you could limit the number of edges bouncing off of to one or two, for example. By setting a limit, you can then use the 'super.act' in a while loop provided the projectile is positively removed from the world at some point. I think, however, that if the projectile is going to get any information from the Tragectory object, something more needs to be done after the while loop. One issue might then be that when not in the world, you cannot get the last location in that world. So, unless you have a way to determine why the Trajectory object was removed from the world (which is what I believe the parent object would need in order to determine whether to fire a projectile or not), I do not see how this setup would work.

I forgot to explain the first point of your reply. In the constructor of the Trajectory object, there is a parameter that will limit the number of ricochets the object will have. Also, using System.currentTimeMillis(), I also limited the lifespan on a Trajectory object to 250 milliseconds, which is way more than enough time for one to complete its journey, considering the relatively small size of the Greenfoot scenario world. (This was actually how I fixed the problem). As for your second point, since the movement is all done within one act cycle, the parent tank will not have moved any since it "fired" its last Trajectory object. Therefore, if the parent is returned a character as the "bumped into" object (the parent is also a parameter, allowing the Trajectory object to send information to the original tank), it will just fire wherever it is currently.

It is not the location of firing that is the issue -- it is the returning of the "bumped into" object that is of concern. There is nothing in the Trajectory class to retain that information and no call to the parent object to return it. At any rate, the way you are going about it seems a bit clumsy. I would have the parent create and add a Trajectory object into the world (at its location; giving the proper rotation) and then call a non-act method in the Trajectory class to perform the nasties and return the "bumped into" object. Something like this in the class of the enemy tank act method: Then in the Trajectory class, you would (instead of an act method) have something like this: