API (org.osbot.rs07.script.API)
When should you use this class? Well, when you're planning to build that stunning API. Think of it like this: you've got a bunch of thingy-bobs, such as bank, inventory, widgets, players, npcs, objects, etc etc, but there's always something missing! When you're working on something that has a bunch of moving parts that are all kind of related together, then it might be time to build yourself an API. For example, if I were to build a Duel Arena script, I would write an API to handle the bothersome bits of the staking and setup process, and even the duel itself. That way, I keep all my Duel Arena logicy-stuff out of my main script. Other benefits include:
SOLID!
Your API will have direct access to all those bank, inventory, widget, and other stuffs!
Reusable and maintainable. Your upkeep will be down to minimal changes here and there...unless the game goes through a drastic change again.
Also, this handy-dandy class has one thing I really like: an abstract method! When you use this class, you have to complete the initializeModule() method. So when might you use this? Well, if you're hooking up listeners (such as MessageListener) to the bot, or if you need to setup some CachedWidgets, and even initialise stuff.
"B-but why not initialise on the constructor?!" I hear you ask. Well, there's a chance you may wish to re-run that initialiseModule function twice in the same script. It'd be unusual, but it means you'd be resetting a bunch of stuff. I wrote a hunter tracking API and I frequently recalled that function, because the tracks change entirely and so the API needed 'cleaning'. If you do this, then be sure your second call clears lists and maps, and doesn't add duplicate listeners. Otherwise, things could go wrong.
Here's an example:
DuelArenaAPI
Admittedly, not everything in this API snippet is best practice. That's because my original Duel Arena API is based on the old interfaces and setup. This was an last-minute-adhoc-scrape-together. But it works!
However, one thing you should not do is to extend an existing API, like bank. Why? Because OSBot already has an implementation of it. If you're expanding upon the bank API, then make it a separate API and name it accordingly (such as "ExtraBankAPI" or something). This also makes sure you're keeping inheriting to a minimum, so your objects are fine-gained. This is good, because inheriting an inherited inherit can get inheritingly messy!
Example Script
MethodProvider (org.osbot.rs07.script.MethodProvider)
MethodProvider is very similar to API. In fact, API inherits it! So, why not just API? Because MethodProvider is a method provider. If you're not looking to build a custom API but you still need all those juicy methods, then use MethodProvider. For example, if your script design is based on a task/node system, then those tasks and nodes could extend MethodProvider. Your task/node are likely going to have a generic structure whereby no new methods are exposed to the public scope, and all instances of tasks and nodes are treated the same.
DuelArenaTask
ChallengeZezimaTask
Example Script
Bot (org.osbot.rs07.Bot)
Bot is basically the robot playing the game for you. That "context" can be used in instances where neither an API nor MethodProvider are required. For example, you may want to save a bunch of game data to a file. In this case, we can use a static method, pass the bot through as a parameter, and then extract the values from the bot, and store them.
Example Script
This isn't the best example and I can't think of a more relevant one, but it's an example nonetheless.
If you recall, the exchangeContext for API and MethodProvider requires Bot to be passed in as a parameter so that these objects have access to the current 'robot' playing the game on your behalf. You could do something similar to that and perhaps have a class that doesn't expose any public methods you did not write yourself.
I really hope this guide has helped you. Thanks for reading!
Note: I may edit this multiple times, especially if the format f**ks up.