Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?
You are not logged in.
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.
Current project: Thinking of/finding/requesting projects...
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. Every feature that violates these is not included in BotBits** and can be implemented in an extension.
**: Exceptions are: BlockChecker, Player Metadata API
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:
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.
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.
The extension API unifies the way extensions are loaded in BotBits in a style that is familar to BotBits users.
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.
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.
[ Started around 1487604341.118 - Generated in 0.024 seconds, 10 queries executed - Memory usage: 1006.91 KiB (Peak: 1.06 MiB) ]