Official Everybody Edits Forums

den3107

Member

From: Netherlands

Joined: 2015-04-24

Posts: 1,025

Re: [SDK] BotBits!

What I understand from this post Is that a library is something functional (connect to this, do that (eg bitmap manipulation)) while an SDK is an extension with helper tools, like methods that contain (complex) calculations, or (taking botbits) methods to draw in EE through a bot, without having to worry about all the underlying problems.
Correct me if I'm wrong.

That's where I stop being (slightly) off-topic here.

Processor

Member

Joined: 2015-02-15

Posts: 2,246

Re: [SDK] BotBits!

Android naming conventions aside, an SDK is a software development kit, a library is, in C# terms, an assembly with useful types. These two attributes can coexist.

BotBits.dll on its own can be defined as a EE bot framework, while BotBits as a whole, including its official extensions, make up the BotBits SDK. These extensions tightly work together in the ecosystem. Some extensions are even tools for extension developers, such as BotBits.Diagnostics.

There are two reasons why I believe BotBits.dll is a framework and not just a library:

1. It does a lot of things. Don't get me wrong, BotBits has had a clear purpose set from the beginning.* However, this purpose has intentionally been pretty broad. Today, BotBits consists of an extension framework, an event system, login and connection management, message parsers and serializers, message throttling and block checking, classes for storing world data and players, etc. All these could in theory exist as their own smaller libraries. (I actually did this with CupCake, people weren't so happy with adding CupCake's 15 or so dlls!)
Most of these independent tools are useful for every bot in development, so they are bundled together in BotBits.dll. Similar to how a ton of features are bundled in the .NET Framework for your convenience.

*: BotBits' purpose is: a) to implement the EE protocol and suitable helper classes/functions b) to implement an extension framework with reasonable flexibility. c) detect and fix missed blocks Every feature that violates these is not included in BotBits and can be implemented in an extension.

2. Writing bots for BotBits, much like using any other framework, has a unique feel to it. Things such as the ".Of" syntax or "[EventListener]" are exclusive to BotBits. BotBits adds its own set of conventions to the language. BotBits is not the only library to do this, WinForms, WPF, ASP.NET, and others do so too.

Here's a list of these inventions that are only available when you use BotBits SDK:

- LoaderBase
This is a class that EventLoader and CommandLoader (from BotBits.Commands) use to load your [EventListener] and [Command(...)] functions. Load, LoadModule and LoadStatic are its functions.

- Package<T>.Of(bot)/Event<T>.Of(bot)/SendMessage<T>.Of(bot)
The .Of syntax, as opposed to bot.EventName allows extensions to add their own classes to the BotBits environment in the same way as standard classes do.

- Extension<T>.LoadInto
The extension API unifies the way extensions are loaded in BotBits in a style that is familar to BotBits users.

- Event<T>/SendMessage<T>
Although events already exist in C#, it is not possible to easily influence their execution order, bind to them in bulk or let extensions add new events. RaiseIn/SendIn function styles fit in well with other BotBits conventions.

- IConnection/ILogin<T>/IPlayerIOGame<T>/IChat<T>
In place of PlayerIOClient.Connection, IConnection allows you to use something other than PlayerIOClient for BotBits. Today, there are three types of IConnection available: PlayerIOClient.Connection, FutureProofConnection and BotBits.Old's Connection.
Other interfaces listed are used by BotCake, ChatExtras, BotBits.Old, etc. to change the way these BotBits components work.

---

I have never thought of programming for reputation and honor. What I have in my heart must come out. That is the reason why I code.

Processor

Member

Joined: 2015-02-15

Posts: 2,246

Re: [SDK] BotBits!

BotBits 220.2 is here!

Changelog:
- Fix a few bugs in Rectangle class
- Add new chat commands

Major changes:
MessageSender
Starting from game version 220, there is no message trottle for world owners. BotBits will now automatically disable BlockChecker and increase its sending frequency to 500 blocks per second.
You or your players may experience disconnects, if that is the case, you can easily change the speed in the new MessageSender API:

MessageSender.Of(bot).SendTimerFrequency = 300; // send 300 messages per second

This is still an experimental feature and subject to changes soon.

The reason for disconnects is the following: PlayerIO wants to make sure that everyone receives every message sent from the server. Not everyone can receive messages as soon as they are ready to be sent, so if a user can't keep up, playerio stores the messages for that user in a queue. This queue has limited memory (because playerio doesn't have infinite RAM), so if a player can't keep up with the new messages over longer periods, this queue gets full and playerio is forced to make a decision: either ignore (drop) new incoming messages (which would mean that two users in the same world could potentially see different worlds, which would be a nightmare to fix) or disconnect the user.

BlocksSnapshot
This class is pretty exciting. For one, it acts as an "ExpectedWorld", which is a new feature in BotBits 220. Instead of waiting for the server's response, ExpectedWorlds update immediately when you try to change them.

var snapshot = new BlocksSnapshot(Blocks.Of(bot));
Blocks.Of(bot).Place(0, 0, Foreground.Basic.Blue);

var liveBlock = Blocks.Of(bot).Foreground[0, 0].Block.Id; // returns Foreground.Empty
var expectedBlock = snapshot.Foreground[0, 0].Id; // returns Foreground.Basic.Blue

// You can also directly access the Expected API
var expectedAPIResponse = Blocks.Of(bot).GetExpectedForeground(new Point(0, 0)); // returns Foreground.Basic.Blue

BlocksSnapshot is also a fully functioning IWorld (Blocks is IReadOnlyWorld and cannot be edited). Changes to BlocksSnapshot are not immediately sent to the server, you must instead call snapshot.Sync() on your object to send the changes to the server.

Snapshots track your history, and even support snapshot.Save() and snapshot.Restore(), which can be useful for adding undo / redo functionality to your program.

Or to make animations! For example, this is how you make a rectangle that moves to the right.

var snapshot = new BlocksSnapshot(Blocks.Of(bot));
for (var i = 10; i < 30; i++) {
    snapshot.Save();
    snapshot.In(i, 10, 5, 5).Set(Foreground.Basic.Blue);
    snapshot.Sync();
    snapshot.Restore();
    
    await Task.Delay(50);
}

Whenever snapshot.Restore() is called, the rectangle is undone and the changes required to clear the rectangle are applied to the snapshot. Note that the rectangle is not cleared in the real world, because .Sync() is not called. When the next rectangle is drawn, some clear messages are discarded, so our rectangle will not "flicker" as it would if we didn't use BlocksSnapshot.

The save and restore functions are very efficient as they only store the changes made, they do not copy the whole world at any time.

---

I have never thought of programming for reputation and honor. What I have in my heart must come out. That is the reason why I code.

Processor

Member

Joined: 2015-02-15

Posts: 2,246

Re: [SDK] BotBits!

BotBits 220.3 is here!

- Fixed a bug Blocks.FinishSendAsync()
- Added Size, a new class that specifies a size.
- Renamed CreateOpenWorldAsync to CreateJoinOpenWorldAsync
- BotBits now attempts to capture the SchedulingContext during room connection instead of EventLoader.Load
- Improved LoginClient Version API

PlayerIOServices
This new class gives you access to some lower level features that BotBits uses to communicate with EE.

- PlayerIOServices.GameId returns the EE game id
- PlayerIOServices.BotBitsGameVersion returns the version of EE the current BotBits was made for. (this is internally used for FutureProof)

In some programs, especially those that offer BigDB APIs, you'll need to store a PlayerIOClient.Client to use across your API. BotBits now offers this feature out of the box. The static PlayerIOServices.DefaultClient can be set or retrieved at any time. If you just need a guest player, you can call PlayerIOServices.RefreshDefaultClient().

Notice that DefaultClient must be first set before you can access it (it doesn't automatically Refresh itself):

// When first accessing PlayerIOServices.DefaultClient
if (PlayerIOServices.RefreshRequired)
    await PlayerIOServices.RefreshDefaultClientAsync();

// Use PlayerIOServices.DefaultClient here!

Database API

BotBits now can load PlayerObjects and many other objects from BigDB. The API is located in DatabaseHandle class.

// How to get a DatabaseHandle:
var defaultHandle = DatabaseHandle.Default; // Uses PlayerIOServices.DefaultClient. To use, you must first refresh the DefaultClient.
var clientHandle = Login.Of(bot).WithEmail(...).Database; // Uses the LoginClient.Client to access BigDB.
var connectionHandle = ConnectionManager.Of(bot).Database; // Uses the Client that was used to create the current Connection.
var customHandle = new DatabaseHandle(myClient); // You may of course use your own PlayerIOClient.Client to create a handle.

Here is an example:

var staffRoles = DatabaseHandle.Default.GetStaffRoles();
foreach (var staff in staffRoles)
    Console.WriteLine($"{staff.Username} is {staff.Role}.");

Because BotBits loads PlayerObject and ShopData for its own use, you should access the cached versions of these objects to avoid making unnecessary requests.

var clientPlayerData = Login.Of(bot).WithEmailAsync(...).GetPlayerDataAsync();
var connectionPlayerData = ConnectionManager.Of(bot).PlayerData;

Diagnostics API

90% of the time, when people message me about their bot not working, it's because of these things:
- They forgot to declare their event listener static
- They are loading EventListener after joining the room (so they don't receive JoinCompleteEvent)
- They are sending messages before receiving init
- They are trying to access Blocks or Players before receiving init

Diagnostics API runs in the background and checks your API calls for common mistakes like these.
It only runs when you are debugging and will throw exceptions when you break the rules above.

---

I have never thought of programming for reputation and honor. What I have in my heart must come out. That is the reason why I code.