Posts Tagged ‘eulora’

Foxybot Enhancements Part 18: Build 35 Release

Thursday, October 4th, 2018

Build 35

Inventory management by craft bot now uses proper 64bit types for handling stack counts and the conversion of counts to strings is done outside of csString.

In addition, the be yourself fix, originally published as a separate item, is incorporated into this bot build.

Feedback is welcome, please use #eulora.

Warning

This has been lightly tested. Further testing is expected to reveal if these changes actually fix the recurring crashes.

Foxybot Enhancements Part 17: Build 34 Release

Monday, October 1st, 2018

Build 34

Bundle bot debuts in this release.

Feedback is welcome, please use #eulora.

Bundling

First I took the existing bundle code and added it to foxybot. But evidently things have changed enough that something broke. It compiles but doesn’t succeed when you run it.

Well, I had an idea about how I wanted it to allow exact specification of ingredients and how I wanted it to use my two-table setup from craft bot so as to completely avoid needing to look in inventory. So I threw out the existing code and modeled bundle bot after craft bot. And also craft bot is fresh in my mind.

Usage

The command to use is:

/bot bundle nTimes m/M/i

m = use minimum quantity for all ingredients

M = use maximum quantity for all ingredients

i = infer the ingredient quantities

Example:

/bot bundle 2000 M

The min and max work exactly how you would expect if you have used foxybot for mining or crafting. Infer is something new that is intended to also do exactly what you’d expect given the name, but in any case is described below.

Requirements

Bundle bot has similar requirements to craft bot, but with some important differences.

  • You must have a bp equipped.

  • You must have an empty work container on the ground within reach and it must not be the type named in your equipped bp.

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

  • The craft-table holding your ingredients must have an open slot.

The work container must not be the one named in the bp so that the actual crafting can never take place mistakenly, since bundle bot only makes the bundles. Once each bundle is made, it is stored back in the storage table. This is what the required empty slot in the storage table will be used for.

Note that bundle bot does not look at quality and does not mix bundles of the current run into existing bundles or even those of an immediately prior run. At each run, it will put all the bundles into the first empty slot identified at the start of the run.

Also there is no interaction with the storage system and therefore no need to be near an NPC. You can make bundles out in the field with a single craft-table and use an exploration marker as the work container. This works provided the above requirements are met, i.e. the marker is empty, within reach and is not of the type specified in the bp.

How It Works

When in min or max mode, the moving of ingredients to the work container proceeds exactly as with mining and crafting. The bot looks for a stack of each ingredient in turn, from top to bottom, whose stack size is at least the size needed for the recipe. In this case, as with craft bot, it is the storage table that is searched for ingredients.

As such, when in min or max mode, you can have multiple stacks of the same or different quality for each ingredient and you don’t necessarily have to compute the exact number bundles to make. If you use an arbitrarily large number for nTimes , the bot will just quit when materials run out.

Infer mode works differently. It is meant to address the desire to specify exact quantities per ingredient since using the max for everything can be wasteful. When running in infer mode, bundle bot takes a moment at the beginning of the run to examine each ingredient in the recipe and compare it to the stack size on-hand to compute how many to use to to get the number of bundles you requested.

For example if the bp calls for 3 to 5 waters and 4 to 11 numina and if you typed in:

/bot bundle 1000 i

If you have 3000 waters and 9000 numina in your storage table, then the bot will infer that you want to use 3 water and 9 numina per bundle.

Specifically, it divides stackCount by nTimes using integer division to compute the quantity. The fact that it uses integer division with no decimal means that in the above example, bundle bot will infer the same 3 and 9 even if you had stack sizes 3999 & 9999.

If the quantity inferred for any ingredient is larger than the max allowed then bundle bot will use the max instead. This is meant as a convenience so that if you know you will use the max for an ingredient, you can move a large stack to your table without having to compute the exact number.

If, on the other hand, the quantity inferred is less than the minimum, the bot will abort before starting (only in infer mode), giving details of what it computed and what the minimum is.

Another difference with infer mode is that the bot only looks at the first slot (searching top to bottom) that contains each ingredient. While max and min will use all available stacks in order, again, infer only uses the first. This is primarily to keep the calculations simple. It also makes it possible to have large stacks at the bottom of your table and for any ingredient you want to limit to below max, move some specific count to a slot above and then run bundle bot.

Report

Bundle bot works quite quickly and could make many bundles before you have a chance to realize any mistake. For this reason, at the beginning of every run bundle bot prints a report of what it will make and how many of each ingredient it will use. It then waits for 15 seconds before beginning the run. This should give you enough time to type in /bot stop if the bot is about to do something that is not what you want.

Warnings

  • This has been tested a low number of times, using recipes of a single ingredient that allow a quantity of between 1 and 2, because that’s all I’m able to do currently.

  • Build 31 is still recommended for bot exploring.

Diana Coman - 2018-10-02 07:01:57

"The craft-table holding your ingredients must have an open slot." → what is an open slot?

Mocky - 2018-10-02 15:42:06

The table can’t be full. It needs at least one open space for the new bundles to be placed.

Diana Coman - 2018-10-03 08:55:47

Ah, that’s an …​empty slot! Although I can see the appeal of the vast open slots of euloran tables :P

Mocky - 2018-10-04 02:03:02

Yes, empty slot. That does sound better.

Foxybot Enhancements Part 16: Build 33 Release

Sunday, September 16th, 2018

Build 33

This release brings a craft bot bug fix and a change in the way crafting output is sent to storage.

Feedback is welcome, please use #eulora.

Changes

The previous build sends to storage any new piles in inventory after /takeall. This build changes that to send both new and changed piles. Changed piles are sent in full.

Fixes

  • FIXED: Bot stops for lack of ingredient when ingredient is in table slot zero.

Warning

It turns out that explore bot is, prior claims not withstanding, actually a victim of its own failure. Further testing has revealed that precision movement is situational at best. The situation being that planeshift tells you one thing while the reality is often a different thing. Also the new dance moves with which I was so taken initially do not always work to reveal a hidden marker, leaving bot dancing without end. Like that song you used to like but now they play it too much on the radio.

For the these reasons, build 31 is recommended for bot exploring.

Just Be Yourself

Saturday, September 15th, 2018

So there I was, just minding my own business.

Part 1

I was working this morning on making craft bot keep track and store not just new piles of loot but changed piles of loot also. The code was done, it wasn’t a big change, and it actually worked. It recognized changed piles, reported the difference as new loot in the bot window, sent the storage request and the full piles ended up in storage. But it also crashed the client. Somehow. Not in the newly written code, somewhere after.

I looked at the code, studied it. Studied the diff. No clue. I put in some debug statements and fired the client back up. But the client thought I was a different player. Known issue. Happens occasionally. If you keep playing like that the client ends up sending ever more conflicting data to the server. Stuff messes up.

So I logged out and back in. Same problem. I tried again. Several times. Then several dozen. Then I realized that I didn’t remember why I was trying to log in. Then I got pissed off.

Part 2

I have no idea how this got started, but back in the day there was this legend that my pancakes were even more delicious when I made them while 'stressed out'. When you have that many ankle biters kicking around, these things are bound to happen. Of course, they don’t tell you about it, they just whisper in hushed tones and try to intentionally irritate you while you’re making the griddles sing.

Eventually one of them tipped their hand by grinning at me and asking if I was stressed yet.

For all I know it’s actually true.

Part 3

src/client/gui/pawscharpick.cpp(154) One line to save name at auto login
//if this is the name we have requested for autologin
//choose it immediately
if(!connecting && ( requestedAutoPickId == i ||
				(requestedAutoPickId == -1 && name == lastCharName) ||
				name == requestedAutoPickName))
{
	connecting = true;
	psCharacterPickerMessage msg(name);
	msg.SendMessage();
+	psEngine::playerName = name;
}

src/client/gui/pawscharpick.cpp(374) One line to save name at normal login
    // Send the name of the character to the server.
    csString charname(1->GetText() );

    psCharacterPickerMessage msg(charname);
    msg.SendMessage();
+   psEngine::playerName = charname;

src/client/pscelclient.cpp(262) One
if statement to check the name
// Extra steps for a controlled actor/the main player:
if(!local_player || local_player->GetEID() == msg.entityid)
{
+	if (!psEngine::playerName.Compare(msg.name))
+	{
+		Error1("Ignoring Actor message. The main player Actor must be loaded first.");
+		return;
+	}
	SetMainActor(actor);

	// This triggers the server to update our proxlist
	//local_player->SendDRUpdate(PRIORITY_LOW,GetClientDR()->GetMsgStrings());

	//update the window title with the char name
	psengine->UpdateWindowTitleInformations();
}

Diana Coman - 2018-10-03 09:10:01

Yes! Hopefully this IS part of the released bot bundle, right?

Mocky - 2018-10-04 02:06:29

No, it’s separate. But I can add it to future builds.

  1. pawsButton*)FindWidget(name []

Foxybot Enhancements Part 15: Build 32 Release

Friday, September 14th, 2018

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!

Foxybot Enhancements Part 14: Build 31 Release

Tuesday, September 11th, 2018

Build 31

This release contains 2 bug fixes.

Feedback is welcome, please use #eulora.

Fixes This Release

  • FIXED: crafting bot fails to find craft-table

  • FIXED: bot window message for lbn pickup mis-reports the count of picked up items

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