OmniAPI - A super simple API that handles most things for you

[Bobrocket]

https://github.com/Bobrocket/OSBotAPI
 
Example usage: leaked green dragon killer source

getNPCFinder().findClosest("Green dragon").attack();
//OSBot version
NPC n = getNPCS().closest("Green dragon");
if (n != null && n.exists() && n.getHealth() > 0 && !n.isUnderAttack() && !myPlayer().isUnderAttack()) n.interact("Attack");

omnipocket leak

getNPCFinder().findClosest("Man").pickpocket();
//OSBot version
NPC n = getNPCS().closest("Man");
if (n != null && n.exists() && n.getHealth() > 0 && !n.isUnderAttack() && !myPlayer().isUnderAttack()) n.interact("Pickpocket");

Advanced usage: get ge/collect box/bank/poll booth close button

getWidgetFinder().findFromAction("Close", (widget) -> (widget.getSpriteIndex1() == 535));
//OSBot version
cant be fucked l0l

Super simple example script: attacks chickens 24/7

public int onLoop() throws InterruptedException {
    getNPCFinder().findClosest("Chicken").attack();
    return Constants.TICK;
}

//OSBot version
public int onLoop() throws InterruptedException {
    NPC n = getNPCS().closest("Chicken");
    if (n != null && n.exists() && n.getHealth() > 0 && !n.isUnderAttack() && !myPlayer().isUnderAttack()) n.interact("Attack");
    return 600;
}

Why use my API over the default OSBot one?

• Handles everything for you. Interacting with an NPC? Null checks, camera movements etc. all handled easily
• Streamlined, consistent API between data types
• Click accuracy increased by 5% on moving NPCs (tested against 2.3.136; will dig up test results later)
• A lot more customisation in Finders vs default OSBot methods (especially with widgets!)
• #findClosest() actually correctly returns the closest NPC/entity
• Super easy to implement - just change extends Script to extends OmniScript

Usage

• Download the latest zip
• Drag the omniapi folder into your project (delete Test.java!)
• Make your script class extend OmniScript instead of Script
• Make use of the OmniScript API

Please note the API is updated constantly, so be sure to redownload the zip occasionally!

Edited December 6, 2015 by Bobrocket

[Chris]

it dropped my items at GE? ??????

[Joseph]

it looks nice man i like it. What do you plan on adding on next?

[RDM]

fancy

[Tom]

This is nice and all, but to anyone who is serious about learning java, or another programming language, I would suggest that you try to create your own version of something similar to this

[Ericthecmh]

uhoh.

 

Inb4 scripters start copy pasting the entire API into their code

[Lemons]

uhoh.

 

Inb4 scripters start copy pasting the entire API into their code

 

At least this ones a little smaller :p

[Bobrocket]

it dropped my items at GE? ??????

Thanks for the 5m nerd

 

it looks nice man i like it. What do you plan on adding on next?

Probably better item + widget support

 

This is nice and all, but to anyone who is serious about learning java, or another programming language, I would suggest that you try to create your own version of something similar to this

>learning java

>osbot

 

uhoh.

 

Inb4 scripters start copy pasting the entire API into their code

Stop bullying me I report you

[Alek]

Handles everything for you. Interacting with an NPC? Null checks, camera movements etc. all handled easily

 

Because you are wrapping around InteractionEvent and then added checks to your method which already exist. None of the checks you have are really necessary, perhaps this is a documentation issue?

private org.osbot.rs07.api.model.NPC child;

public NPC(OmniScript script, org.osbot.rs07.api.model.NPC n) {
  super(script);
  child = n;
}

@Override
public boolean interact(String... interactions) {
  if (!exists() || !isAlive()) return false;
  if (!hasAction(interactions)) return false;
  if (!child.isVisible()) getCamera().toEntity(child);
  return child.interact(interactions);

Also you might want to check into why we didn't switch filters over to streams after we upgraded to Java 8. 

 

Edit: Not trying to pick on you, I dislike Lemons API even more. 

 

 

[Tom]

Also you might want to check into why we didn't switch filters over to streams after we upgraded to Java 8. 

 

Edit: Not trying to pick on you, I dislike Lemons API even more. 

Can't you just tell our desperate souls why you of all gods turned down streams?

[Alek]

Can't you just tell our desperate souls why you of all gods turned down streams?

 

There were a few performance concerns, here is a pretty good article that also details a bit of sequential vs parallel:

https://jaxenter.com/java-performance-tutorial-how-fast-are-the-java-8-streams-118830.html

 

The larger overlying issue was the API. It's hard enough to get scripters to change an import for a new area class, yet alone scrapping our entire filter system.

 

At the end of the day, we didn't feel as if the functionality (or performance for that matter) would be worth the complete rewrite. 

[Bobrocket]

Because you are wrapping around the InteractionEvent which I wrote and then added checks to your method which already exist. None of the checks you have are missing/not handled in IE.

private org.osbot.rs07.api.model.NPC child;

public NPC(OmniScript script, org.osbot.rs07.api.model.NPC n) {
  super(script);
  child = n;
}

@Override
public boolean interact(String... interactions) {
  if (!exists() || !isAlive()) return false;
  if (!hasAction(interactions)) return false;
  if (!child.isVisible()) getCamera().toEntity(child);
  return child.interact(interactions);

Also you might want to check into why we didn't switch filters over to streams after we upgraded to Java 8. 

In a region with no "Dwarf" NPCs...

getNpcs().closest("Dwarf").interact("Attack");

Result: (bot also freezes)

 

getNPCFinder().findClosest("Dwarf").attack();

Result:

Nothing, because it's handled.

 

You shouldn't be returning null for anything (I know this isn't related directly to the interaction method, but it's a fair point), the code for both methods listed is perfectly valid and thus should work no matter what, right? Returning null is also known as the billion dollar mistake, and is for a good reason. NPCFinder will return an instance of omniapi.data.NPC no matter what, whereas NPCS will return either an instance of org.osbot.rs07.api.model.NPC or null. We shouldn't need to null check things like this. In fact, the api docs even states it returns the closest generically specified Entity - mentions nothing about null.

 

Also, the NPC #closest() methods don't even return the correct closest NPC (even though it should be using Pythagoras' algorithm). I've highlighted this in a thread, which you have likely not read yet, and NPCFinder accounts for this.

 

Wrapping around IE is temporary, it's there to show it works and I will be writing a custom interaction method very soon.

[Ericthecmh]

In a region with no "Dwarf" NPCs...

getNpcs().closest("Dwarf").interact("Attack");

Result: (bot also freezes)

getNPCFinder().findClosest("Dwarf").attack();

Result:

Nothing, because it's handled.

 

You shouldn't be returning null for anything (I know this isn't related directly to the interaction method, but it's a fair point), the code for both methods listed is perfectly valid and thus should work no matter what, right? Returning null is also known as the billion dollar mistake, and is for a good reason. NPCFinder will return an instance of omniapi.data.NPC no matter what, whereas NPCS will return either an instance of org.osbot.rs07.api.model.NPC or null. We shouldn't need to null check things like this. In fact, the api docs even states it returns the closest generically specified Entity - mentions nothing about null.

 

Also, the NPC #closest() methods don't even return the correct closest NPC (even though it should be using Pythagoras' algorithm). I've highlighted this in a thread, which you have likely not read yet, and NPCFinder accounts for this.

 

Wrapping around IE is temporary, it's there to show it works and I will be writing a custom interaction method very soon.

 

And now we get a huge philosophical debate about the proper use of nulls, etc etc etc.

 

Tbh I wish everyone would just use the OSBot API, but I understand the compulsion people feel to making their own APIs to enhance features and work around bugs.

At least this ones a little smaller

 

Yeah lol

[fixthissite]

And now we get a huge philosophical debate about the proper use of nulls, etc etc etc.

 

Tbh I wish everyone would just use the OSBot API, but I understand the compulsion people feel to making their own APIs to enhance features and work around bugs.

 

Yeah lol

He got the null thing from me  I wrote a suggestion thread about returning Null Objects rather than null to prevent all the nasty checks, you should go approve that so all the scripters can like it

 

And there is no proper use of null. Come at me with ANY situation, I'll tell you why it's inconcvienent. It was a flaw, hence why it's called the "billion dollar mistake" - it would cost billions to reverse the damage done (code cludder)

Edited October 8, 2015 by fixthissite

[Bobrocket]

And now we get a huge philosophical debate about the proper use of nulls, etc etc etc.

 

Tbh I wish everyone would just use the OSBot API, but I understand the compulsion people feel to making their own APIs to enhance features and work around bugs.

 

Another reason I wrote this API is easier cross-bot compatibility. Means I rewrite less code, and therefore I have the same code base in case a bug breaks out.

Within this context, a null is not good. A null means that code that should work perfectly fine will not work. A null means additional checking on the users end, which can cause more problems if they forget. In my case, I pass a omniapi.data.DefaultNPC instance, which simply extends omniapi.data.NPC and is constructed to, simply, not exist. This means there is no NPE when trying to interact (my above post), but it still actually represents nothing. A new scripter is going to try the exact code I highlighted in my above post, realise it doesn't work, and panic because they wrote incorrect code (that is actually correct). I personally don't believe that the API should ever return null, especially in contexts like this.

 

Lastly, I wrote this API as this is personally what I believe the OSBot API should be like.