Archive for July, 2018

Foxybot Enhancements Part 11: Build 28 Release

Saturday, July 28th, 2018

Build 28

This release contains mining reliability fixes.

UPDATED Links now point to build 28.1 which adds the following three changes:

  1. FIXED: bot crashes client when table gets full

  2. ADDED: handling for "not successful" message from /explore

  3. ADDED: bot will now stop if loot drops on the ground

UPDATED 2 Links now point to build 28.2 which additionally fixes a key parsing defect which can cause bot to dance away from table and across map in search of non existing claim marker.

Feedback is welcome, please use #eulora.


You have to have your craft-table in inventory. It’s not smart enough to look on the ground for one. If you leave it on the ground it will proceed as if you have no table, potentially leaving your table behind.

If you have mining enumerations inside a container in your inventory while bot mining and any new enumerations auto-stack into the container, the bot isn’t smart enough to look there.

The bot isn’t smart enough to figure out if a table on the ground is yours or not. Avoid bot mining near other craft-tables on the ground as the bot is likely to get confused and halt when transfer to wrong table fails. This applies to the public craft-table as well.

I suggest you use an explore timeout of at least 30000 for reliability.

For reference the command is as follows:

/bot explore nTimes moveStrategy strategySize leaveKeys useMaxMaterials maxDelay exploreTimeout qualityBand

For example:

/bot explore 200 line 100 1 M 8000 30000 100

Which gives you a qualityBand of 100. If you do not set a quality band, a default quality band of 1 will be used which permits stacking only of identical qualities.


  • FIXED: mining outputs from a single dig requiring 2 or more new table slots are wrongly stacked into the same slot causing unexpected stacking and or bot stoppage if the items can’t be stacked together.

  • FIXED: bot breaks when mining is started with an empty table.

  • FIXED: "You were unsuccessful since you moved" while exploring.

    • The bot now tries really hard to hold still, and immediately forces client compliance with server position messages.

  • FIXED: if the bot gets "You were not successful since you moved" while building a claim it doesn’t retry.

  • FIXED: if the enumeration doesn’t land in inventory in a timely fashion following the explore success message, the bot gets confused and builds using the most recent recipe.

  • FIXED: bot stops if lacking ingredients to build claims higher than tiny and small.

    • Now the bot will stop when unable to build a small or tiny but will lock other types and move on.

  • FIXED: bot gets stuck waiting if the nearby claim markers are so dense that the new marker doesn’t appear.

    • The bot will now dance around the new claim marker’s position to elicit its details from the server.

Foxybot Enhancements Part 10: Build 27 Mangled Miner

Saturday, July 14th, 2018

Build 27

This release contains mining focused enhancements and fixes. This build can be placed on top of either of the prior builds I’ve released (24 or 25). Feedback is welcome, please use #eulora.

UPDATED Links now point to build 27.1 which has all necessary files and can sit down on a base eulora v0.1.2 client.

UPDATED 2 Links updated to build 27.2 which includes the full foxybot dir.

Primary Features

Auto stacking of mining output by quality bands.

There is a new qualityBand parameter for the mining bot. The band defines the range over which items close in quality will be stacked together during mining. If you set the qualityBand parameter to 100 then newly mined items with quality 0-99 will be stacked together and 100-199 will be likewise combined, and so on. The rules are followed for lossless stacking. If any problems arise during a restack or if the bot cannot verify that the current state matches the expected state, the bot stops.

Unfortunately the quality band parameter is an additional positional argument to the /bot command, for now. In order to set this command you will need to type all of the bot parameters as this is an optional last param.

For reference the command is as follows:

/bot explore nTimes moveStrategy strategySize leaveKeys useMaxMaterials maxDelay exploreTimeout qualityBand

For example:

/bot explore 200 line 100 1 M 8000 8000 100

Which gives you a qualityBand of 100. If you do not set a quality band, a default quality band of 1 will be used which permits stacking only of identical qualities.

Missing Features

Bot Config File

Work on support for a config file with named parameters is underway, but not yet complete, and so not in this build.

Better Logging

Work on logging bot output to a file is underway but depends on the unfinished config file support. It is also not in this build.

Experimental Features


There is an experimental new command that executes with the command /bot nuke 100 where the number you pass is the radius of the circle, centered on your player, that will be cleansed of entities. This includes tables, claim markers, and anything you can pickup or drop on the ground. This effects your client only. Ghosted items will be gone for good and the proper items will be gone temporarily but will reappear when the server decides to send you a message telling you where they are, which can often be triggered by moving around a little.

This is used by the bot to keep table ghosts at bay. It’s also useful for dealing with ghosted entities manually since dropped items snap to a grid and if you drop something that snaps to the same grid as a ghosted item, you won’t be able to pick it up manually.

When you run this command the bot outputs a line in the bot window telling you how many entities were deleted from the scene graph.

For reference, the max distance you can pickup an item from the ground is 25 units.

Request Server World

This build has an experimental new command /bot requestserverworld which I do not completely understand yet and haven’t had much time to look at. It sends a REQUEST_SERVER_WORLD message to the server which responds, at a minimum, with the coordinates of your player. I hooked it up to the bot in an attempt to deal with table and claim glitches. Most of the time it appeared to do nothing of import, but once it caused the zone loading screen to fill the screen momentarily. It is no longer hooked up to the bot but remains in as a command, for now.


Table ghosting has been eliminated

the bot pauses and then uses Nuke() to wipe out all nearby entities before dropping the table.

Table glitch 1 is handled.

"Table glitch 1" is what I call it when you (or the bot) attempts to move an item to the table and get a message saying you can’t do it even though it seems like it ought to work. Table glitch 1 goes into effect the moment you drop the table and persists until you pick it up and drop it again. It appears to occur for ~1% of table drops. My work around is to test the table immediately after every drop, and re-drop it if it isn’t working. In my testing this glitch is 100% correlated with the Planeshift / GEM entity ids (EID), where tables with EIDs values 998 and below are always glitched and EID values 1010 and above are never glitched.

There is also a table glitch 2 where the table behaves like a claim marker. You can move to and from the slots but you don’t get an option to pick it up and you do get an option to lock it. The only known work around is to log off and come back in. This seems to occur less than one in a thousand times. I see no way to handle this. The bot just gets stuck.

Claim glitch 1 is handled.

Claim glitch 1 is what I call it when you get a claim that won’t let you move anything into it, instead you get the message, "You are too far away to do that." This can be fixed by logging off and back on, but that’s outside the bots purview. I handled it by dropping the key and continuing for tiny claims and locking other claims. In my testing this glitch is also perfectly correlated with EIDs between 998 and 107.

Claim glitch 2 is handled

Claim glitch 2 is when you try to move something into a claim slot and it tries to move it into your inventory slot! It’s like a counter strike. It’s problematic when you move a key into claim slot 0 and it ends up in the hand that holds your digging tool! The move will either succeed with the item in one of your equipped slots or you get a message that, "It won’t fit there!" The work around for this is the same as with claim glitch 1, but additionally, the bot never attempts to move anything into claim slots 0-2, which, if reflected, would wind up in one or both of your hands. In my testing this glitch is perfectly correlated with EIDs 92 and below (it could be as high as 106 and below, i never got one 106-93).