14 July 2018 Tagged: eulorac++

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).

Add a Comment