Foxybot Enhancements Part 15: Build 32 Release

Build 32

This release makes craft bot pull materials from a craft-table instead of inventory, and puts output into storage.

Feedback is welcome, please use #eulora.

Features

The craft bot no longer looks in inventory for bundles and ingredients, it looks in a spare craft-table. Therefore, you must have a spare craft-table in addition to the crafting container named in your bp. The full requirements are as follows:

  • You must have a bp equipped (as before)

  • You must have the container named in your bp on the ground within reach and it must be empty

  • In addition to the above container, you must have a craft-table on the ground within reach holding your craft ingredients.

  • You must be within range of the NPC for training and storage of outputs.

The bot looks first for a bundle and then for ingredients. It looks in the table slots from left to right, top to bottom. You can have your ingredients and bundles in multiple piles, if one pile runs out it will move on to the next. However, it will never pull from multiple piles for the same ingredient in a single round. It will pull from the first pile that meets the quantity requirement.

You can have as many or as few bps equipped as you want. The only technical requirements are that you have at least one but not so many that you are over weight. If you run out of bps in your mind slot during the run, the bot will equip more from your ingredients table. It will equip them from the first pile it finds (again in slot order) with a name matching what you had equipped to start the run. It will equip the number needed to finish the run, or the number of bps in the pile, or 100, whichever is smallest. Therefore, you can have multiple piles (presumably with different qualities) and they will be consumed in order.

During each round, a /takeall is done of crafting output and then each new pile in inv is sent to storage via the NPC. If the full output of one round puts you overweight, the bot is not yet smart enough to deal with this, and will get stuck.

The requirement to target your craft container has been lifted. Just drop it on the ground and the bot will handle the targeting. If it is not within reach, the bot will complain and fail to start.

The bot will train you when you rank up, as before.

If a crafting round yields items that drop to the ground, the bot has been programmed to notice and stop. However, this has not been tested since I can’t really do this myself. Maybe the bot stopping for this condition is not really needed, since those items will be under your guard. Possibly you got enough items in the same round to put you overweight and stop the bot anyway. I wasn’t sure what else to do here, and I don’t have a way to test it.

Misc

Some miscellaneous additions snuck in also. Precision bot step size while exploring has been added. By default the bot moves 1.0 game units each round in either walk or run mode. Distance is parameterized, however, and is used by the code that makes the bot dance toward tardy claim markers to hasten their arrival. The bot now dances the full distance to the spot in one step and then immediately dances back to where it came from. This happens so quickly that it has the pleasing effect of appearing to not be happening at all. The bot log claims that bot is stepping toward marker, it appears to stand still, and the marker appears and bot continues to build it.

I added the stepping back as part of the precision movement, to avoid drift that tends to accumulate over time and ensure that the bot is within reach of all the tables at all times. I’m very happy with the dancing now and with how quickly it causes claim markers to appear. But there is a bot glitch that still needs to be ironed out in this regard, as the bot has become a victim of its own success. It makes the claim marker appear so quickly that sometimes it will try to build the claim before the server has fully registered its movement back to the original spot. Thus when the build begins the server will notify the client that its position is back at the marker, and client will comply! and so the dance back is unhappened, and drift continues.

The solution, yet to be implemented, is to wait a proper amount of time before attempting to build the claim for the bots movements to be valid. Yet bot has already become so slow at my hands, I hate to slow it further!

Also added was some hygiene with reading server messages. I didn’t even know this was needed until its lack started choking multiple bots feeding from the same trough!

Warning

I consider this release experimental for both crafting and mining. The few mining changes could impact reliability over time and I haven’t tested for that. Also this is a first release of this crafting stuff and could be well fubar. Enjoy!

Tags: ,

Leave a Reply