Archive for September, 2018

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