Bukkit

Hi Cybran,

first of all thanks for the plugin and your great work! You put really good ideas in there. I was playing around a bit and tried to create a simple random walk for a Creeper and observed some unexpected behavior as explained below.

What steps will reproduce the problem?
1. Spawn a Creeper, make it an controllable mob with myCreeper =  ControllableMobs.putUnderControl(LivingEntity, true)
2. Create a new location (adding random int values to the X and Z coordinate in the range [2,..., 5]), assign a moveTo action with the new location with myCreeper.getActions().moveTo(newLocation, true)  (=> this is implemented as run() of a class that implements Runnable)
3. Adding a callback action that repeats Step 2.

What is the expected output? What do you see instead?
The expected output is that the Creeper walks around more or less randomly and that the callback action calls run() after the Creeper has finished the current moveTo action.
Instead the Creeper executes a couple of moveTo actions successfully, but stops after a while. Then, when I push him slightly around he starts walking again. This can be continued forever. Remark: it seems that the callback action does not call the run()-method and that's why the Creeper stands still.

What version of the API and CraftBukkit are you using?
I am using API version 5 and CraftBukkit 1.6.4-R2.0.

Do you have an error log of what happened?

Please provide any additional information below.
I tried another solution in which I implemented an eventListener and created a custom event that is thrown by the callback action as shown here:
myEntity.getActions().callback(new MovedEvent(myEntity.getEntity()));
The event is then caught by the listener and a new moveTo action is added to the queue. Though being slightly different from the implementation above, it shows the same behavior.

Thanks a million, I appreciate your work!!

Hi Cybran, I just checked for another scenario and let the Creeper walk in a square with 9 points (where the 9th point equals the 1st one) => please find the picture.

The mob always stopped at the same two waypoints (#6 and #8) when I told it to follow all waypoints from 1 to 8 in regular order.

When just using only those two "broken" waypoints and deleting the other ones the mob can walk from #8 to #6, but stops at #6 on the way back to #8.

Then I added waypoint #1 to this scenario and told the mob to walk as follows: #8 => #6 => #1 => #6 => #8 (and repeat) The mob stopped at #6 in both cases: when trying to walk to #1 and #8.

As a next step I took this scenario and replaced #1 by #5 so we have: #8 => #6 => #5 => #6 => #8 (and repeat) The mob stopped at #6 but only when he tried to walk to #8. From #6 => #5 worked well.

As the sketch below (hopefully) shows #1 and #8 lay in similar direction when being approached from #6. #5 lays in the opposite corner. Maybe it's got something to do with that, but that's just a wild guess.

Any ideas?

Thanks a lot! - Sam

Are you sure that the creeper can actually reach the randomly generated target locations? If not (like when there is no passable terrain), the entity might stop (and the action's state will be set to BLOCKED). I quickly made up a runnable to reproduce the behavior, and my entity sometimes stopped on unpathable terrain. However, it sometimes proceeded to move anyway (don't know what the minecraft pathing algorithms are doing there, exactly...)

So, this leads to multiple conclusions: a) We need a better pathing algorithm. I'm not an expert on this topic, so I won't be able to create this on my own ;) b) If your problem is related to a BLOCKED path, you might want a callback or other way to handle it, right? I have had a look at my code again and I think there is no such thing yet. Possible solutions: 1) option to skip blocked paths, remove the move action and invoke your runnable 2) option to add an event listener

Please report back what you think about the suggestions. Also, you might want to inspect whether the action is actually blocked (since the lack of a callback, you could register a sync task in the scheduler that repeatedly checks this). And it would help me if you could provide the actual code (and maybe world, if necessary) to reproduce the issue.

@DevCybran: Go

Hi Cybran, thanks for your answer!

The creeper should be able to reach any of the defined locations, but stops anyway. To see it yourself I've added the code and the world in the links below.

https://www.dropbox.com/s/nrp3u61qryxvpdj/com.realcraft.AI.zip https://www.dropbox.com/s/bzcsefgqzc4qmdq/world.zip

Your conclusions are totally right, I agree. I wish I could create another pathing algorithm anytime soon, but as you, I need some time to dive into the topic and thinking about detecting blocked paths (at best in advance) ... aaargh! ;-)

I'm still hoping that I might have made some mistake in my implementation and since your random walk worked, my implementation seems like the nearest source of error. If you like, you can send me your code as well, that might save you some work.

Nevertheless: I keep your suggestion in mind and a better pathing algorithm is definitely a great thing, but right now I see this as the last resort, since this probably needs much work.

Best