[OGL Methods] clostest, extractIDs, etc

[Obscurity]

vDebug() is DemizeGLZ, yes. But it simply calls glDebug() from GLXCore:

procedure VDebug(S: String);
begin
  case S of
    'N': glDebug(GL_MODE_NONE, 0, 0, 0, 0, 0, 0, 1350, 670);
    'T': glDebug(GL_MODE_TEXTURES, 0, 0, 0, 0, 0, 0, 1350, 670);
    'M': glDebug(GL_MODE_MODELS, 0, 0, 0, 0, 0, 0, 1350, 670);
  end;
end;

[Patriq]

But where can I find DemizeGLZ? Cant seem to find it anywhere!

[Obscurity]

I'll have to prod @Clarity. He sent it to me months ago. I don't believe we use it for much, though. We're in the process of fading it out.

Clarity, do you still have the download link for Demize?

[Obscurity]

Thought I'd update everyone, since I'm constantly asked in PM and on Skype...

Firstly, the tutorial. Clarity and I have been hard at work on this. We were going to release it before this weekend, but ran into some unexpected changes. See below.

The obscurityLibrary will not exist shortly. I'm getting rid of it. Instead, and I'm sure @Brandon won't mind, I'm redesigning it and the OpenGL includes (fazing out the DemiseGL). As he mentioned in his post in the OpenGL Plugin thread, it's old and needs updating. That way, we'll hopefully take a load off him and @Clarity and I will be happy to handle the includes.

That said, OpenGL will be formatted very similar to SRL. Take the following example:

actionBar.getCurrentBar(); //~ OGL
TRSActionBar.getCurrentBar(); //~ SRL

This is to aide people who are currently familiar with SRL with using OpenGL.

Other functions will be changed to:

ogl.getChars();
ogl.getColourTolerance();
ogl.setColourTolerance();
ogl.setDebugMode();
//~ Etc...

We've also got an auto-updater, thanks to @Kevin, so you won't have to come to this thread every time you want to update... Especially since it will be split into core.simba, type.simba, etc.

I'm very happy with the changes. I've noticed much better performance and hope you will all be just as pleased once it's released. .

[Ross]

Thought I'd update everyone, since I'm constantly asked in PM and on Skype...

Firstly, the tutorial. Clarity and I have been hard at work on this. We were going to release it before this weekend, but ran into some unexpected changes. See below.

The obscurityLibrary will not exist shortly. I'm getting rid of it. Instead, and I'm sure @Brandon won't mind, I'm redesigning it and the OpenGL includes (fazing out the DemiseGL). As he mentioned in his post in the OpenGL Plugin thread, it's old and needs updating. That way, we'll hopefully take a load off him and @Clarity and I will be happy to handle the includes.

That said, OpenGL will be formatted very similar to SRL. Take the following example:

actionBar.getCurrentBar(); //~ OGL
TRSActionBar.getCurrentBar(); //~ SRL

This is to aide people who are currently familiar with SRL with using OpenGL.

Other functions will be changed to:

ogl.getChars();
ogl.getColourTolerance();
ogl.setColourTolerance();
ogl.setDebugMode();
//~ Etc...

We've also got an auto-updater, thanks to @Kevin, so you won't have to come to this thread every time you want to update... Especially since it will be split into core.simba, type.simba, etc.

I'm very happy with the changes. I've noticed much better performance and hope you will all be just as pleased once it's released. .

This is awesome! Any idea on ETA to sate some appetites?

[Obscurity]

Well it depends... Would y'all be happy with a very basic release - ie. able to get chars, models, textures, and some of what the obscurityLibrary has now - or would you prefer to wait until we have something a little more advanced?

[Patriq]

Well it depends... Would y'all be happy with a very basic release - ie. able to get chars, models, textures, and some of what the obscurityLibrary has now - or would you prefer to wait until we have something a little more advanced?

Give us a taste please

[Obscurity]

Alright. :-). Sent it to a few people over Skype last night and it got amazing reviews so far, so will throw it on Github later tonight.

There's not a whole lot in it so far in terms of interface interactions, but it has actionBar, inventory, etc. actionBar.clickAbility('slice'), actionBar.setRegenerate(true/false), actionBar.setAutoRetaliate(true/false), actionBar.clickFamiliarAction(), actionBar.setActionBar(1-5), y'know. You'll see, and I don't think you'll be disappointed. ^^.

It also now supports the vertical actionBar.

[Obscurity]

https://github.com/ObscuritySRL/ogl

Just threw some up quickly, as I have company coming soon. It'll be moved to another later, once I get things set up with Kevin - that's whn it'll have the auto-updater/etc.

To create an OpenGL client, include lib\core\core.simba and use:

ogl.setup(clientWidth,clientHeight);

If no width or height is specified, it'll use the defaults which are found in core.ini, if it exists. If not, it defaults to 800x600.

Something else to be found in core.ini is the default colour tolerance. This is used for things like finding characters and textures by colour. It can be changed by:

ogl.setColourTolerance(someNumber);

The default is 4. If you'd like to change the default colour tolerance, by saving it to the ini, use:

ogl.setDefaultColourTolerance(someNumber);

To save the current dimensions and colour tolerance, use:

ogl.save();

If you want to debug models or textures or such:

ogl.setDebugMode('2');
ogl.setDebugMode('m');
ogl.setDebugMode('model');
ogl.setDebugMode('models');

For example.

Other then that, just check out the includes. The ones like actionBar and inventory have examples provided. If you need help with anything else, or using the library, let me know.

We have a bit more, but that's all I'm comfortable releasing until I recreate an OGL library thread and have the walk-through finished. :P.

[Ross]

[Obscurity]

Haha, just give it to Clarity - since he's my partner. :-P. Appreciate it though, mate.

[Obscurity]

A quick update for y'all.

Though the plugin is undergoing a massive update, I wasn't happy with the current speeds of glxFonts(), glxModels(), and glxTextures(). Running tests on multiple machines, these functions, which are used to grab the data relevant to the specific function, were very slow. They averaged 3.5s on newer machines, and 4.7s on older machines per 100 calls!

That said, if in a single loop you had it watch health and prayer, make sure auto-retaliate is enabled, check to see if your fighting, check overload and other buffs, etc... You're looking at dozens of calls. That's why previously I had functions like obsGetLifePoints() accept a glTextureArray. That way, you could grab all relevant fonts, models, and textures at the beginning of the loop and use that data.

Well, I dislike that approach. It's sloppy and requires duplicates of each function, method, or procedure. So, I added caching. Let me explain.

How often do you really need to grab data off screen? If you're watching your prayer, do you really need an accurate number to the 1-2ms? Unlikely. Keeping that in mind, I rewrote glx...() functions to glFonts(), glModels(), glTextures().

These functions save the data returned for 60ms by default. This is customizable with ogl.setCacheTime(int32). To change the default time, the time loaded with ogl.setup(), use ogl.setDefaultCacheTime(int32).

To give you an idea of the increase in performance bonuses, I was able to execute 1000 calls of bank.getTab() in under 15ms on an average machine. Previously, this would have taken well over 50s. While rapidly monitoring the results, the change wasn't noticeable the the human eye... Or mine at least.

Anyways, I've added some more interfaces and some other things to the Git. The library is lacking the most important function, menu.clickOption() (right click > select option), but that's taking a fair bit of time for me and I just get annoyed and move on to something else.

Cheers guys! A lot more to come! Got a lot in the works, but have to test and fool-proof it. .

[the bank]

A quick update for y'all.

Though the plugin is undergoing a massive update, I wasn't happy with the current speeds of glxFonts(), glxModels(), and glxTextures(). Running tests on multiple machines, these functions, which are used to grab the data relevant to the specific function, were very slow. They averaged 3.5s on newer machines, and 4.7s on older machines per 100 calls!

That said, if in a single loop you had it watch health and prayer, make sure auto-retaliate is enabled, check to see if your fighting, check overload and other buffs, etc... You're looking at dozens of calls. That's why previously I had functions like obsGetLifePoints() accept a glTextureArray. That way, you could grab all relevant fonts, models, and textures at the beginning of the loop and use that data.

Well, I dislike that approach. It's sloppy and requires duplicates of each function, method, or procedure. So, I added caching. Let me explain.

How often do you really need to grab data off screen? If you're watching your prayer, do you really need an accurate number to the 1-2ms? Unlikely. Keeping that in mind, I rewrote glx...() functions to glFonts(), glModels(), glTextures().

These functions save the data returned for 60ms by default. This is customizable with ogl.setCacheTime(int32). To change the default time, the time loaded with ogl.setup(), use ogl.setDefaultCacheTime(int32).

To give you an idea of the increase in performance bonuses, I was able to execute 1000 calls of bank.getTab() in under 15ms on an average machine. Previously, this would have taken well over 50s. While rapidly monitoring the results, the change wasn't noticeable the the human eye... Or mine at least.

Anyways, I've added some more interfaces and some other things to the Git. The library is lacking the most important function, menu.clickOption() (right click > select option), but that's taking a fair bit of time for me and I just get annoyed and move on to something else.

Cheers guys! A lot more to come! Got a lot in the works, but have to test and fool-proof it. .

Have you pushed this update?

[Obscurity]

It's in my GitHub, yes.

Keep in mind, obscurityLibrary (referred to from now-on as obsLib) is entirely separate from this new OGL library (oglLib). The obsLib was just me beginning to venture into OGL. After countless hours of OGL scripting and researching, I had compiled a list of things that needed changed or updated. Thus, the obsLib was no longer enough, leading to the oglLib project with Clarity and myself.

The oglLib lacks several of the functions the obsLib has. As mentioned, things like right clicking options and such. These will be added as I get time.


Also, slightly important, I have a bet running with a friend - that mouse movements will never affect ban rates. Because the oglLib isn't officially published yet and is only in testing, there are no mouse movements. Though, I've botted over 50M ranged XP on one account, got a 200M skill on an account, etc with no movements... So if you'd like mouse movements added, you'll have to do them yourself, for now anyways. Easy enough, as it's a simple copy and paste.

[3Garrett3]

It's in my GitHub, yes.

Keep in mind, obscurityLibrary (referred to from now-on as obsLib) is entirely separate from this new OGL library (oglLib). The obsLib was just me beginning to venture into OGL. After countless hours of OGL scripting and researching, I had compiled a list of things that needed changed or updated. Thus, the obsLib was no longer enough, leading to the oglLib project with Clarity and myself.

The oglLib lacks several of the functions the obsLib has. As mentioned, things like right clicking options and such. These will be added as I get time.


Also, slightly important, I have a bet running with a friend - that mouse movements will never affect ban rates. Because the oglLib isn't officially published yet and is only in testing, there are no mouse movements. Though, I've botted over 50M ranged XP on one account, got a 200M skill on an account, etc with no movements... So if you'd like mouse movements added, you'll have to do them yourself, for now anyways. Easy enough, as it's a simple copy and paste.

"No mouse movement" meaning "the mouse doesn't move to the target, it just clicks" or "afk everything because the mouse doesn't do anything"? I assume the first one? If so, it would be neat to know that the mouse doesn't have to move, Jagex only logs where we click. I thought the general consensus around here what that ClickMouse was a pretty bannable thing. Interesting indeed.

I know I bug you too often on Skype probably, but what kind of ETA do you have before the oglLib is ready for public consumption?

[Obscurity]

You can start using it now, TBH. A lot of people already are - I help them on Skype. :P. It's already capable of advanced bots - especially if you copy over obsClickOption(). All you really need is to be able to get fonts, models, and textures - the rest is really just a bonus. .

But yes, none of my bots that I run use mouse movements now - literally just clickMouse(). As Clarity will tell you, I'm running Pest Control, gold farmers, GWD and sometimes TD bots 24/7... So I'm pretty much convinced that it's nothing to worry about.

I don't expect people to take my word for it though - I wouldn't risk it if I'd heard it from someone else. But you have to consider things like touch-screens (I play on my touch screen laptop), TeamViewer (I'll occasionally play through it at work), mousekeys, etc. Ever been banned for using those? :P.

My thoughts on the matter closely match Brandon's - Why waste time tracking and monitoring movements and such... If it became a big enough problem, detect the client.

[3Garrett3]

You can start using it now, TBH. A lot of people already are - I help them on Skype. :P. It's already capable of advanced bots - especially if you copy over obsClickOption(). All you really need is to be able to get fonts, models, and textures - the rest is really just a bonus. .

But yes, none of my bots that I run use mouse movements now - literally just clickMouse(). As Clarity will tell you, I'm running Pest Control, gold farmers, GWD and sometimes TD bots 24/7... So I'm pretty much convinced that it's nothing to worry about.

I don't expect people to take my word for it though - I wouldn't risk it if I'd heard it from someone else. But you have to consider things like touch-screens (I play on my touch screen laptop), TeamViewer (I'll occasionally play through it at work), mousekeys, etc. Ever been banned for using those? :P.

My thoughts on the matter closely match Brandon's - Why waste time tracking and monitoring movements and such... If it became a big enough problem, detect the client.

I'm going to have to get some of this Skype help someday soon, I'm dying to try making a few crazy scripts that color would be harder to use for.

[the bank]

Just something small but

if glxMapHooks(smart.ID) then
    writeLN('glxMapHooks was successful.')
  else
    writeLN('glxMapHooks was successful.');

[Ross]

Just something small but

if glxMapHooks(smart.ID) then
    writeLN('glxMapHooks was successful.')
  else
    writeLN('glxMapHooks was successful.');

Doesn't look like will solve anything :P

[the bank]

Doesn't look like will solve anything :P

That's the point I'm making. That is code from his setup function.

[Clarity]

Guess we forgot to push that typo fix. Thanks for the reminder

[nero_dante]

Mouse movement shouldn't increase ban rates, because I'm very sure you have one random person i the world playing Runescape on a touchscreen.

[Obscurity]

I play a lot on my touchscreen laptop. It's fantastic once you get the hang of it. I'd actually prefer it to playing normal. :P.

[Obscurity]

Added some interfaces, like combat, some very basic GE functions, and such. Also finished production.

function production.clickMake():boolean;
function production.hasChooseATool():boolean;
function production.hasProduction():boolean;
function production.getProduct():int32; 
function production.getProgress():int32; 
function production.hasProgress():boolean;
function production.setProduct(funcProduct:int32):boolean;
function production.setTool(funcTool:int32):boolean;

Etc... Cheers. .

Edit: Suppose I should explain what each does... So I'll just quote my Skype message to Clarity:

production.setTool(1);

Would chose the knife.

production.setProduct(2);

Would chose the wooden stock.

production.getProduct();

Would return 3 (Shieldbow [u]).

production.clickMake();

Would click the Fletch button.


With the progress screen:

production.hasProgress();

Would return if a progress window currently exists.

production.getProgress();

Would return 0-100.


Click/Set functions return true if any action was taken. For example:

production.setProduct(2);

Would return true if it was needed to set the 3rd product. It would be false if no 3rd product was found or the 3rd product was already selected.

[Ross]

...

Good stuff.

I know that starting at 0 is a very code-y thing to do and OGL is supposed to be for intermediate coding, but SRL-6 typically either starts at 1 for most things (i.e. backpack slots) or uses variable names. Just tossing that out, dunno if it's something worth changing.