Did anyone managed to port Minebot to +1.9?

[ghost]

So I ported AimBow some time ago and now since I got a lot of freetime Im planning to work on Minebot. Im hoping that someone already did the job making core methods to work.

[michaelzangl]

I don't know any ports yet. But you won't be the first one to try to migrate Minebot to a newer Minecraft version - it will not be easy.

[ghost]

Yea I saw one guy working on it but stopped 3 months ago, probably gave up. Its a shame that awesome mod like this is left behind. I got more experience in java and would love to improve it. However, need to migrate its core methods to never version. All the awesome mod functionality makes it even more difficult to migrate.

[Hury999]

It would be nice if someone just make something similar to minebot, with just few functions.. for example just farming.. everything else is not that really needed and others functions can be added later if that someone has time..

[jaideepheer]

I am working on a similar mod called BotAPI. Currently it can only control basic movement but it has a nice framework and should be easier to keep up to date. You can check it out here https://github.com/eileen12/MinecraftForge-BotAPI

[ghost]

BotAPI is way too far from achieving atleast half of minebot functionality. Would be faster to work on this mod core methods trying to migrate it to new version..

[michaelzangl]

Regarding BotAPI: I had a short look at your project. For writing a real bot, you need much more than the ability to move to a given position:

• Pathfinding
• World simulation (e.g. you destroy a block, what will happen then)
• Pathfinding in this simulated, future world
• Fast pathfinding (you need to do a search in ~100 Block radius in every direction, need to destroy/place dirt blocks to reach some places, ...)
• Interruption events - what if the server lags, what if the bot controller wants to abort, what if you are attacked
• Control your hunger
• Control your inventory - allow to get and put things
• Check for environmental safety - avoid cactus, don't stand below falling gravel
• Automatically select the right tools
• Use a world abstraction layer to not have to change every class whenever Minecraft updates (Yes, Minebot has one. But due to the amount of things you need to check to make a real, working bot, the things you need from Minecraft are still a lot).

And tons of other things I don't remember but that are in this code somewhere. But I like the way you code this. In your style, Minebot would have had twice that many lines...

[michaelzangl]

... since there are so many people asking for it and it, I just upgraded to forge 1.11.

I did not have time to test much but updating only took about 2h. /minebot mine works, the other things might, too. New blocks and entities are completely missing. I'm not enough into minecraft to add them anyway, so feel free to add them (the BlockSets file may be interesting for you, but some are handled in other parts of the mod)

[ghost]

Well, this was unexpected. If core strategies works then we will test and fix what we can

[michaelzangl]

Doing it myself takes less time than to explain how to do it. But feel free to experiment with any bugs that are still there. Fishing is probably broken because the splash resource is missing ;-)

[michaelzangl]

@eileen12 Your synchronization in the script engine is wrong.

Have a look at e.g. how Minebot scripts wait for the next game tick, how Minebot synchronizes world access, how Minebot updates the active strategy

(Note that strategies can be implemented in Java or in JavaScript and JavaScript). Minebot has 22k lines of code, only 880 of them are for the scripting API.

[michaelzangl]

1.12 is the newest one I could find.

[couldbejake]

you're amazing bro, this is great work. 👍

[jaideepheer]

@michaelzangl Thanx for taking a look at my code and providing feedback, however I do not understand why my synchronization in the script engine is wrong.

According to the code you pointed in minebot it seems to me that minebot uses a separate Object called tickHelperMutex as the sync lock. However BotAPI uses its the current Bot object(this) as the lock and hence is kind of similar as the Bot object mainly only executes its Algorithm on every iteration and then waits for the next onTick event.

Note that the goal here is to allow simultaneous execution of different Bot threads as there can be multiple Bots in game.

If there is anything I could not notice, please do tell ;-)

Edit : I found some sync problems when changing the Algorithm for a Bot. If this was the bug thnx ;-D

---

Oops... didn't read "script engine" :P But I can't find any sync problems here... o_o

[michaelzangl]

@eileen12 It does not matter what lock object you use.

• A notify is no good style. It is better to always use a notifyAll() together with an action that should be taken by the waiter, or even better - a wait queue. scheduleNextAction() is not called reliably: What if an error happens? You may need to track the scripts status to see if it has continued or if it was blocked indefinitely. And you need the ability to get a clean state when you kill the script.
• You use both notify and wait in multiple places. This makes it hard to debug.
• Check your access to Minecraft things: They may only happen while the script is paused.

[jaideepheer]

@michaelzangl I have had doubts about the efficiency of my style, my current style creates two separate new threads. One is the Bot thread that executes the Algorithm containing Actions and Responsibilities. And the other is the BotScript thread which hosts the JavaScript engine and executes the javascript. Hence you see a wait and notify in Bot and BotScript. Also scheduleNextAction() is only called if the previous Action executed successfully or there is no current action to perform but thanx for pointing that out as I can check if the script needs to be stopped...

• The idea is to have a Bot thread for every Bot, JavaScript controlled or not.
• Since every bot uses itself for a Lock, under normal conditions there should not be any other thread waiting on it except the bot thread itself.
• If under any condition a different thread waits on the bot object, then we will need notifyAll() which has been implemented thanx to your suggestion ;)

Now since this will result in a lot of threads in-game, I don't know if I should make a separate thread for each bot or just one father thread for all bots. O_o

As for monitoring for errors and infinite loops in the script, I can't seem to find a way to handle those other than inserting a custom func. call at many places in the script TT Also I'm still working on the security aspect of the JavaScript engine but probally will implement inventory controlling and other stuff first. **

[Eyremba]

So I ported AimBow some time ago

Could you share this port please? :)