SRL Archive - SRL Archives

I just noticed it wasn't working and decided to make a fix for it quick.


Original function:

{*******************************************************************************
function ShopScreen: Boolean;
By: ZephyrsFury
Description: Returns true if a shop interface is opened.
*******************************************************************************}
function ShopScreen: Boolean;
begin
  Result := FindTextTpa(2070783, 0, 226, 305, 340, 320, 'Player', StatChars, Nothing);
end;

Fix's:

function ShopScreen: Boolean;
begin
  Result := (CountColor(2070783, 58, 303, 85, 317) = 63);
end; 

or

function ShopScreen : Boolean;
begin
  Result := FindTextTPA(2070783, 10, 58, 303, 85, 317, 'Right', StatChars, Nothing);
end;

Both fix's search the same area for the same word, just using two different methods.

Cool, replace the countcolor with a FindText and I, or someone else, will commit it. The reason it needs to be OCR based is so there is no chance of failure; but I'm sure you knew that already :)

OCR no chance of failure?

LOL

From: IceFire908
OCR no chance of failure?

LOL

Im gonna guess s/he ment no chance of false negatives

^ He.

From: Dgby714
Im gonna guess s/he ment no chance of false negatives

Yup, false positives.
And Ice, we're talking about SIMBA's flawless OCR;).
I'd rather it be a text function, seeing as most of the ones in SRL are.

From: Naum
Cool, replace the countcolor with a FindText and I, or someone else, will commit it. The reason it needs to be OCR based is so there is no chance of failure; but I'm sure you knew that already :)

Yeah I figured that was the case. I'll let you know when I've switched it.

I don't think the OCR is just as accurate as using a proper countcolor. But that's just me

From: Blumblebee
I don't think the OCR is just as accurate as using a proper countcolor. But that's just me

I agree to an extent. I use CountColor variations for near everything and they work extremely well.
However, it does leave a possibility for a false positive as Naum pointed out. Though unlikely, it's still possible.

As long as the text's remain updated I have no problem using a FindText function.

Use countcol…

From: IceFire908
Use countcol…

In that case the one already posted works.

When I get home tomorrow I'll add a FindText one and let Dev's decide I suppose.

From: IceFire908
OCR no chance of failure?

LOL

Sure. It hardly gives false positives, and since the text is already known in this case, it is even better.

From: Wizzup?
Sure. It hardly gives false positives, and since the text is already known in this case, it is even better.

Exactly :):

Function ShopScreen : Boolean;
Begin
  Result := FindTextTPA(2070783, 10, 154, 3, 435, 35, 'Store', UpChars, Nothing);
End;

Did it myself, see if it works.

I can test when I get home today. I'm at my moms with nathan right now but I should be home in 4 or 5 hours.
That's why I hadn't done it yet ;)

From: Wizzup?
Sure. It hardly gives false positives, and since the text is already known in this case, it is even better.

Sure the odds of it giving a false positive are about equal to that of someone typing in the chatbox the text to be detected and it being picked up in the right location so that the script thinks a shop screen open, but probably less than instances of the color 2070783 being found exactly 63 times in the small box of 58, 303, 85, 317. So… false positives it's debatable really, but lets think about this… how many times has OCR failed for no apparent reason? Lets think about this… we are searching for Text… why we already know what's it's going to say? CountCol just checks for pixel points.. plus it's many times faster and less laggy than any OCR. So false negatives, there's really no debate there, CountCol in comparison the OCR in false negatives is nonexistent… when OCR could fail as much as 10% or 1% of the time.

From: IceFire908
Sure the odds of it giving a false positive are about equal to that of someone typing in the chatbox the text to be detected and it being picked up in the right location so that the script thinks a shop screen open, but probably less than instances of the color 2070783 being found exactly 63 times in the small box of 58, 303, 85, 317. So… false positives it's debatable really, but lets think about this… how many times has OCR failed for no apparent reason? Lets think about this… we are searching for Text… why we already know what's it's going to say? CountCol just checks for pixel points.. plus it's many times faster and less laggy than any OCR. So false negatives, there's really no debate there, CountCol in comparison the OCR in false negatives is nonexistent… when OCR could fail as much as 10% or 1% of the time.

No, you're completely wrong. As I have stated before, this is searching for known text. It has nothing to do with identifying text. There is a BIG advantage to use OCR, because if the fonts change, all we will have to do is update the fonts, and when we have the correct fonts, it is 100% accurate. When you use CountColors, you will have to update the amount of colours for every instance. It's primitive and stupid. Use it only when you can't use anything else.

Simba's OCR is not laggy, and I doubt it is much faster than the way we use to find text.

Speed comparison?
FindTextTPA is basically FindColors + TPAInTPA
CountColors is a FindColors too. There is hardly a difference in speed.

From: Wizzup?
No, you're completely wrong. As I have stated before, this is searching for known text. It has nothing to do with identifying text. There is a BIG advantage to use OCR, because if the fonts change, all we will have to do is update the fonts, and when we have the correct fonts, it is 100% accurate. When you use CountColors, you will have to update the amount of colours for every instance. It's primitive and stupid. Use it only when you can't use anything else.

Simba's OCR is not laggy, and I doubt it is much faster than the way we use to find text.

Speed comparison?
FindTextTPA is basically FindColors + TPAInTPA
CountColors is a FindColors too. There is hardly a difference in speed.

What are you basing these facts off of? You obviously do not use scripting for practical uses in runescape… with OCR you will get an occasional error using this, as in it will be open and say it isn't.

Just want to state here that OCR has nothing to do with Text finding.. OCR is recognizing characters out of a piece of color.. Whilst Text finding is just searching for a set of colors known beforehand.

E: So yes, text finding is just like DTM finding… Which should be pretty fast + accurate, no matter what.

From: mastaraymond

E: So yes, text finding is just like DTM finding… Which should be pretty fast + accurate, no matter what.

Results and experience say otherwise.

I also find it interesting why Wizzup used CountCol in his essence miner if he thinks FindTexTPA is more reliable.

From: IceFire908
What are you basing these facts off of? You obviously do not use scripting for practical uses in runescape… with OCR you will get an occasional error using this, as in it will be open and say it isn't.

Pardon the language, but what the fuck? I do not use scripting for practical uses in RuneScape?

Just because SCAR's OCR is laggy and you only want to use SCAR doesn't mean OCR is general is laggy.

What I am basing these facts off? Source code! See for yourself.

From: IceFire908
Results and experience say otherwise.

I also find it interesting why Wizzup used CountCol in his essence miner if he thinks FindTexTPA is more reliable.

What experience? You don't even know how FindTextTPA works.

Several reasons:

• > Just because SCAR's OCR is laggy and you only want to use SCAR doesn't mean OCR is general is laggy. (There was only SCAR when I made that script)
• Aside from that, FindTextTPA was invented rather late by Raymond and me. Do you know why it was invented? Because SCAR's was so damn slow.
• I probably even had it in my script before FindTextTPA was invented

Keep it out of SRL 4, then.

Regardless of what you compare the accuracy of counting colors to, you can decrease the amount of false positives for counting colors by dividing the area into smaller areas and doing multiple counts.

Whatever I'm not hear to discuss the ethics of this, I'm just simply stating the CountCol has yielded more reliable results from first hand experience while using it for runescape text, and it has. You can ignore my opinion if you want, it doesn't really matter.

From: IceFire908
Keep it out of SRL 4, then.

Actually, since you use SCAR it would be in your advantage to use the FindTextTPA ray and I wrote. Since it doesn't use SCAR's findtext stuff at all, it is just as stable as in Simba.

Yes, CountColors has served its uses, but I don't see why we should use it in this case.

From: Wizzup?
Pardon the language, but what the fuck? I do not use scripting for practical uses in RuneScape?

Just because SCAR's OCR is laggy and you only want to use SCAR doesn't mean OCR is general is laggy.

What I am basing these facts off? Source code! See for yourself.



What experience? You don't even know how FindTextTPA works.

Several reasons:

• > Just because SCAR's OCR is laggy and you only want to use SCAR doesn't mean OCR is general is laggy. (There was only SCAR when I made that script)
• Aside from that, FindTextTPA was invented rather late by Raymond and me. Do you know why it was invented? Because SCAR's was so damn slow.
• I probably even had it in my script before FindTextTPA was invented

not to be a douchebag but Simba's OCR needs work if it's going to be relied on. I continually get Sa''?on instead of Salmon, Po,,ta? for Portal, etc. I think using countcolor() negates the chance of that happening. However if the OCR is working 100% then it would be far more accurate I suppose.

From: Boreas
Regardless of what you compare the accuracy of counting colors to, you can decrease the amount of false positives for counting colors by dividing the area into smaller areas and doing multiple counts.

I sure hope no one is going to do several FindColors as that would be quite a few API calls…

better off getting all the colors and checking it line by line, which I suspect becomes very similar to FindTextTPA…

Plus, if there's such a huge discussion between Simba and Scar just use defines. All more of a reason to work on SRL 5.

~RM

From: Blumblebee
not to be a douchebag but Simba's OCR needs work if it's going to be relied on. I continually get Sa''?on instead of Salmon, Po,,ta? for Portal, etc. I think using countcolor() negates the chance of that happening. However if the OCR is working 100% then it would be far more accurate I suppose.

It's a bit off topic; but are you talking about Uptext? If so, I'd like a screenshot of it failing, or where it fails. (But start a thread somewhere in Simba forum)

From: Wizzup?
It's a bit off topic; but are you talking about Uptext? If so, I'd like a screenshot of it failing, or where it fails. (But start a thread somewhere in Simba forum)

uptext and blackchatmessage. Black chat message is a bit more reliable but it does fail still. I'm just assuming that because those two are failing that the rest of the text finding would be failing somewhat. But who knows, I'll start a thread sometime in the near future here.

Naum I couldn't get yours to work so here:

Function ShopScreen : Boolean;
Begin
  Result := FindTextTPA(2070783, 10, 58, 303, 85, 317, 'Right', StatChars, Nothing);
End;

Tested with:

program New;
{.include SRL/SRL.scar}
Function N_ShopScreen : Boolean;
Begin
  Result := FindTextTPA(2070783, 10, 58, 303, 85, 317, 'Right', StatChars, Nothing);
End;

begin
SetUpSRL;
ActivateClient;
if N_ShopScreen then
  Writeln('yeeuhh');
end.

Output:

New client targeted
Successfully compiled (2062 ms)
SRL Compiled in 15 msec
yeeuhh
Successfully executed

Commited.

~RM