Archive for the ‘Uncategorized’ Category

Foxybot Enhancements Part 13: Build 30 Release

Friday, August 31st, 2018

Build 30

This release adds 4 features.

Feedback is welcome, please use #eulora.

New Features This Release

  • Explore logging

    • Suggestion to start a fresh log and get the new column name, rename existing log file ~/.Eulora/logs/$name_logexploring.csv

    • There is an additional column in the log: ItemName

    • The logging will now create one log line for each type of item in a claim

    • The count of items in the log is now correct

  • The bot will now stop when a skill is maxxed and you are no longer improving.

  • LBN on the ground will be picked up by the bot if it is within reach

  • Bot is now much less likely to be confused by other craft-tables in the area

    • The full fix for this will be part of the multi-table feature

Foxybot Enhancements Part 12: Build 29 Release

Sunday, August 19th, 2018

Build 29

This release contains further mining reliability fixes.

Feedback is welcome, please use #eulora.

Warnings

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.

Fixes

  • FIXED: multiple mining outputs in the same quality band are mis-stacked

  • FIXED: ordinary claims are skipped because the key description is parsed improperly

  • FIXED: claim marker text is parsed to include extraneous spaces

  • FIXED: craft-table is sometimes tested at the wrong time

  • FIXED: lag can cause old recipe to be used with current claim

    • Now the recipe is fully initialized between rounds, for reelz this time

  • FIXED: bot will leave mining output behind if /takeall doesn’t return promply

Daniel P. Barron - 2018-08-31 19:31:35

Been using this for a few days. Works great!

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.

Warnings

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.

Fixes

  • 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

Nuke

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.

Fixes

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

Meanwhile in Perfectly Stacked

Saturday, June 30th, 2018

The focus of my recent work has been on reliable mining automation. One missing piece is a solution to the abundance of mining outputs of differing qualities that quickly fill all available table slots.

One proposed solution is a stacking algorithm that separates resources first into bands of quality (specified by the user) and then carefully steps through a stacking procedure. A careful procedure is needed because when you stack piles of resources with different qualities the resulting quality of that stacked pile is an averaging based on quality and quantity that rounds down any decimal remainder to an integer. This rounding down amounts to lost value and so to avoid losing value you must only stack in round numbers, as it were.

This careful procedure is going to be messy to write, once I’ve wrapped each step in 1) wait time for server round trip 2) coordination between state machine code and server message handling code 3) error handling / recovery code.

Before I get too far down that road I decided to implement the lossless stacking algo independently in python to make it possible for me to get quicker feedback about the correctness of my assumptions and my understanding of the problem.

Usage

stacker.py reads lines from stdin, treats each line as a specification of a table, losslessly stacks down everything in the table to the minimum number of slots, and prints out a specification of the resulting table.

The specification format of a table is any number of slots separated by a space. The format of a slot is AxBq where A is an integer quantity and B is an integer quality. For example: 200x1000q indicates a slot that contains 200 items of 1000 quality.

Basic Usage
python stacker.py < stacker.txt

If in the above example stacker.txt has the following contents:

Stacker Test File
44x103q 101x102q 15x104q 12x105q
44x103q 101x102q 15x104q 12x105q 44x107q 11x106q

then the output will be:

Stacker Test Output
110x103q 62x102q
147x104q 80x103q

There is also a verbose mode that lists every stack movement and the table state after each move.

Verbose Usage
python stacker.py -v < stacker.txt

Assumptions

This code is based on the assumption that separating stacks of different item types, and separating items in different quality bands has already been done. Those separations are trivial to implement and orthogonal to the stacking problem. Therefore all stacks are assumed to be same-item and same-band.

Algorithm

The ordered steps for finding the next one move, at a high level, are as follows:

  • If there are two slots with items if the same quality, move all the items in the higher numbered slot onto the lower.

  • Find the pair of slots that has both even quality (or both odd), has primarily the largest difference in quality and secondarily contains an element with the minimum quantity.

  • If found, move items from the higher quantity stack to the lower quantity slot. The number of items to move is equal to the number of items in the lower quantity slot.

  • If not found, terminate.

The approach is, at worst, near optimal with respect to the number of slot movements required. It may be optimal, but I haven’t taken the time to prove it.

Ashby Gap Seriously Soaked, Dicks Dome, Confederate Ghost

Monday, June 25th, 2018

I spent this past weekend backpacking north from Front Royal. Prior to my arrival, northern Virginia received 38 hours of heavy rain and it didn’t stop just cuz I showed up. Getting there was a bit hairy. The roads had 10 to 20cm of water flowing across them in dozens of places. I mean, it was great, they had signs to warn you "ROAD MAY FLOOD" every mile or so.

It rained through the night, but stopped before dawn. We decided to save breakfast for later and hit the trail early, munching on some snacks. After a couple hours we came to a camp site with a water source and stopped to have our meal.

There we met two super happy hikers wearing clothes that were comical either by design or by irony. I enjoyed my oatmeal and hot coffee to sounds of hysterical laughter and coughing as these jokers got baked. They were actually quite funny, and to their credit, Ren and Stimpy found my jokes hilarious.

I stepped away for a minute to take a piss and this little guy popped up right in front of my face:

Little Orange Beetle
Figure 1. Little Beetle Wearing Orange Turtle Neck

We parted ways with Stimpson et al. and hiked the rest of the morning up to a peak that was covered in trees and gave us no view. There was, however, an odd wooden bench, randomly awaiting us at the top.

Summit Bench
Figure 2. Real Man, Carrot Top and Legs recline on an unexpected bench

This little guy came to get a load of me:

Orange Spider
Figure 3. A Little Spider "Sniffing" Around

The afternoon was all downpour as we climbed down into and back out of the near-flooded Ashby Gap. We then made our way up to Dick’s Dome. The rain quit right before we stopped to make camp and the sun actually peeked through. There were golden rays lighting up the fog over the creek and I thought I might get to capture a nice scene after all. But the moment passed before I could get the camera. This is what the view from camp looked like without the golden rays.

Tiny Mountain Creek at Flood
Figure 4. No Golden Rays in the Air, No Glowing Flames in the Fire Pit

The next day was rain free. We stopped for lunch at Hollow Rod Shelter. Evidently we were hiking the western edge of the forward operating base of the Gray Ghost, confederate col. Mosby.

Sign commemorating J. S. Mosby
Figure 5. One of many signs in Virginia commemorating J. S. Mosby

This section of the hike involved a sequence of steep ascents and descents in quick succession known as 'the roller coaster'. At the top of each peak was an amazing view. At least I told myself there was, using my mind’s eye, because there were so many trees that you couldn’t see a damn thing with your actual eyes.

So…​ here’s a creek:

A Creek Shaped Like an 'S'
Figure 6. A Creek Shaped Like an 'S'

And a rock formation:

A Small Rock Formation
Figure 7. It’s rocky here, good luck finding a spot for your tent.

Rock on.

Foxybot Enhancements Part 9: Build 25 Release

Tuesday, June 19th, 2018

A few errors became immediatly obvious in build 24. This build addresses them.

Place this on top of build 24. Feedback is welcome, please use #eulora.

Changes in Build 25

Fixes

  • Fixed: bot reports table is full and aborts immediately after moving resources to any previously unused slot.

  • Fixed: bot refuses to leave keys in claim when instructed.

  • Fixed: bot doesn’t always wait long enough for the build recipe from the server.

  • Fixed: bot has extra long pause after table scan before doing the first explore.

  • Fixed: the bot window log lines for resource moves are not consistently colored.

Foxybot Enhancements Part 8: Build 24 Release

Monday, June 18th, 2018

I’ve been focusing my recent eulora client work on getting the bot mining into shape. Today I’m releasing my work so far. The tar ball contains 7 source files that will lay down properly over either EuloraV0.1.2 original source or any previous patch of mine you may have used. 5 of these files contain minor edits and fixes only, while botactivity.cpp and botactivity.h carry the bulk of my work.

My ability to test this is limited by the fact that my character is a noob and doesn’t do things like get multiple quality outputs from a single mine. Feedback is welcome, please use #eulora.

Changes in Build 24

Usage

The command for explore has changed slightly

/bot explore total_times [line|grid] size [0|1] [m|M] maxDelay timeout

Using 1 will leave keys in the claim, 0 will keep keys.

Using m will use minimum build materials, M will use max.

The default maxDelay is 8000ms. Timeout default is now 30000ms.

Example
/bot explore 100 line 100 0 M 8000 8000

Fixes

  • Fixed: bot doesn’t find the craft table in inventory

  • Fixed: bot drops the wrong table when multiple craft tables are in inventory

  • Fixed: bot gets stuck in run mode and keeps going

  • Fixed: bot leaves multiple quality outputs in inventory

  • Fixed: bot ignores large stack of ingredients, instead failing on an insufficient stack earlier in inventory

  • Fixed: in some cases bot fails to change direction in accordance with movement strategy

  • Fixed: in some cases bot leaves craft table on the ground at the end of mining run

  • Fixed: in some cases bot uses movement strategy specified on prior mining run

  • Fixed: bot fails trying to swap out worn tools

Enhancements

  • Added a version string as the first line of output in the bot window

  • Enhanced table pickups and drops to stop using "/pickup" and "/drop"

  • Build 4 added 'backup mode' which caused the bot to move in the reverse direction after getting the message that the table was too far away to pick up, until it was within reach of the table again. This build adds an enhancement where the bot monitors its distance from table and only keeps backing up as long as it’s getting closer to the table. If backing up ever results in becoming more distant from the table it enters a new 'urgent' mode, turning and taking steps directly toward the table until within reach. To test this out, I encourage you to strafe or walk the bot away from the table while in the middle of building a claim to see how it behaves. Keeping the table is of the utmost importance and I’ve tried to make this part solid.

  • The management of resources in the table has been completely rewritten. I consider this to be stage one of managing resource quality. At the start of a mining run, the table is scanned and the name and quality of each item is tracked. During the mining run, each new output is stacked in the table with existing items of identical quality, or stacked in an empty slot if there is not an exact match. Multiple qualities should never be mixed and I welcome assistance in testing this. If it is the case that you get many different quality items, then your table may fill up quickly. In a future build there may be support for more advanced features. The purpose of this stage one feature set is for a solid foundation. The bot will stop if the table fills and you are able to mix qualities as needed and restart the bot.

  • Worn tool swapping works as follows: when a tool is worn, the bot searches inventory for another tool with identical name and higher quality.

  • The default timeout has been changed from 15 minutes to 30 seconds to better accommodate the new building times.

  • Table selection works as follows: at startup the bot selects the heaviest table for use. If there are multiple heaviest tables the one in the lowest numbered slot is used. The benefit of this is that it will always remain the heaviest table and so tracking the slot numbers of used and / or unused tables is unnecessary. The slot number approach seemed to be fragile in practice. Now, when the bot needs to find the table in inventory, it performs a fresh scan for the heaviest table.

Known Issues

  • Logging has yet to be fixed.

  • If you bot-mine on a slope steep enough that you slide down or can’t climb up, you will probably lose your table despite 'urgent' mode.

  • There is an occasional issue with getting a "too far away" message while trying to transfer resources from inventory to the table. I have looked at it and suspect it may be a targeting race condition, but I haven’t found the solution yet. When this occurs the table is not out of range and can be picked up / re-viewed. If the resources that failed to transfer do not put you over weight, the mining run will continue and they will be transferred the next time you mine items with the same name. If it does put you over weight, the bot will be stuck but you should be able to stop it and transfer manually.

  • Claim selection is improved but not yet perfect. Sometimes the wrong claim stick will be targeted and either a transfer to it will fail, or the build will fail. I’ve not yet written the code to reacquire the proper stick. When this happens you will lose the durability on your tool from the dig, but the bundle should be returned to you. This appears to only happen rarely when mining fresh ground and ever more commonly as you retrace the same ground with much spent claim clutter.

  • Table ghosts persist even though I’ve added code that specifically deletes them. It may be that the timing of the deletion is not yet right. They seem to be much more common in certain areas like the sides of hills. This does not seem to hurt the functioning of the current build of the bot.

Foxybot Enhancements Test Sample

Friday, June 8th, 2018

I pulled together some of the fixes so far with some new table dragging fixes into a patch for testing out, primarily the mining.

A link to a patch to the Eulora src based on version 0.1.2 eulora-foxybot-mocky1.patch

A link a tar ball of the 0.1.2 src plus my additions EuloraV0.1.2-foxybot-mocky1.tar.gz

Foxybot Enhancements Part 6: A Quick One

Thursday, June 7th, 2018

I had an issue a while ago mining small claims with the bot that got the slap-on-a-bandaid treatment. The problem was that small claims took 5 minutes for me to build, while tiny claims took less than 5 seconds. And I couldn’t figure out the right parameters to pass for the result I wanted.

If I passed a timeout value less than 5 minutes, then the bot got impatient and walked away in the middle of the build. But when passing a value long enough for the build, whenever the bot got hung up on any other situation, it would idle for the whole 5 minutes until the eventual timeout.

I tried a couple code changes that didn’t work. So I just auto-locked the small claims and moved on to more pressing issues. But all of a sudden since yesterday, I can build small claims super fast. Time to revist.

I don’t have the crafting table sorted out completely for exploring yet, so I can’t have the bot table walk with small claim output. So I made the following quick change so that the bot will build the small claim and then lock it after, instead of looting it. It seems like the empty locked claim gets swept quickly but with something in it, swept much later.

src/client/foxybot/botactivity.cpp(648)
void ExploreActivity::DoTakeResult()
{
	worldHandler::TargetEID(markerID);
	worldHandler::TakeAllFromTarget();
	spentClaims.Put(markerID, markerID);
}

That’s the code to loot the claim after building it. I added a conditional to instead lock the claim if it’s a small, otherwise loot as normal.

src/client/foxybot/botactivity.cpp(648)
void ExploreActivity::DoTakeResult()
{
	worldHandler::TargetEID(markerID);
	if (claimType.CompareNoCase("Small"))
		worldHandler::PicklockEID(markerID);
	else
		worldHandler::TakeAllFromTarget();
	spentClaims.Put(markerID, markerID);
}

So that’s that. It’s not a big deal and it didn’t take much time, But I thought I’d give you this quickie. How was it for you?