For the other error, there should not be any line of sight checking in the 'obstructedMovement' method. It should only contain the code for the actions of the enemy when we already know that the view is obstructed. If you want that the enemy move randomly, you might just try removing the 'obstructedMovement' method and changing the call to it at line 64 to 'randomMovement'.

Well actually there are two things that I want the enemy class to do which involve line of sight being obstructed; one of them being that as you said for when line of sight is obstructed the enemy will execute the randomMovement method. The second mechanic that I want to use is that if the player line of sight becomes obstructed during the pursue method the enemy will move forward for x amount of seconds which if during the forward movement if the player is within range and has no objects obstructing its line of sight it will pursue the player, else the enemy will proceed to do randomMovement method. Also I tried to add some classes to which would be considered obstructions however the Enemy AI ignores those walls and proceeds to pursue the player regardless of there being a wall class there.

The obstructedView class returns true when there is something between the two checked objects, so the pursue method should execute if false is returned. So remove the '!' in lines 36, 53 and 60. Btw, the extra '&& pursued.getWorld() != null' I suggested to add last time (line 32) is not needed anymore with the new beginning of the act method.

Thanks, fixed part of the problem. However I have tested that add some classes to which would be considered obstructions however if there are 2 or more Enemy_Test3 classes that are within range and have a wall class obstructing their view, they will ignore those walls and proceeds to pursue the player regardless of there being a wall class there.

You might want to create a subclass of Actor called Obstruction and then have all your wall classes extend it. That way, you only need place the one class name in as a parameter for the 'obstructedView' method. In your 'persue' method, you do not need to get the actor to pursue. It is already assigned to the 'persued' field. So, lines 122 through 130 can simply be this:

Thanks, however the issue of my Enemy_Test3 class pursuing the player if there are 2 or more Enemy_Test3 classes in the world that have the player in range but have obstructions in the way still ignore those obstructions and proceed to attack the player and sometimes even go through the walls

As far as going through walls, that code is part of the movement and should be dealt with in the 'randomMovement' and 'pursue' methods (or in methods they call). As for the other thing, what exactly is the issue of your Enemy_Test3 class pursuing the player?

The issue is that if there is 2 or more Enemy_Test3 objects in the world they will still pursue the player if the player is in range and have wall classes obstructing their view. If you would like I could try and upload my scenario so that you can better understand what I am talking about.

That might be best at this point.

I tried to publish it, apparently it is too large. How else could you see it?

Chances are that you have multiple large sound files. Create a copy of the scenario (use "Save as") and reduce it by eliminating any and all sound files. Then, remove all code relate to those files (you can let the error checking lead you to those). Then, upload was remains. Btw, you will have to go to the "sounds" folder of the scenario to delete the sound files.

Sorry for the late reply. Here it is http://www.greenfoot.org/scenarios/17690 If you move the player towards the wall the Enemies will still "pursue" the player if there are more than one Enemy_Test3 objects that have obstructedView to the player

Are all three Enemies from the same class? Well, they also move through the wall. To avoid this, you should put line 106 through 116 at the end of the act-method, line 111 at the beginning of act method and remove 132 through 141. As it is right now, it reads like 'if it touches a wall, do nothing'. Btw, I am not sure if line 108 is what it should. Right now it is the same as: But shouldn't it be the following? Maybe this problem will be fixed then. Even the player can move into the wall...

After changes suggested the Enemy class completely ignores the walls (note that the enemies did turn if they reached a wall if the player was not in range). As for the player moving through the wall is partially true, what I mean by this is that the Player class is attached to a Movement class (so it follows the Movement class) that is solid and cannot go through walls; so essentially the player goes through the walls partially. This was done to avoid the player being caught in walls if the player was changing the direction it was facing while up against a wall class (player would've merged with the wall class if I did not separate the movement code to another class). The values at line 108 were just arbitrary values except for the negative values which would allow the enemy to turn in both directions. Also a final note is that I am not having trouble with the Enemy class detecting walls during randomMovement, it is when the player is being pursued is when it ignores those wall classes.