SRL Archive - Bugs

Results in SCAR:

Successfully compiled (3139 ms)
You heat the steel bar into a liquid state.
Successfully executed
Successfully compiled (1555 ms)
You remove the cannonballs from the mould.
Successfully executed
Successfully compiled (2100 ms)
The molten metal cools slowly to form 4 cannonballs.
Successfully executed

Results in SIMBA:

Compiled succesfully in 405 ms.
You remove the cannonballs>from? the mould
Successfully executed.
Compiled succesfully in 421 ms.
The m? olten metal cools slowly t? form 4 cannonballs
Successfully executed.
Compiled succesfully in 406 ms.
You heat the steel bar into a ?liquid state
Successfully executed.
Compiled succesfully in 405 ms.
The m? olten metal cools slowly t? form 4 cannonballs
Successfully executed.

First error I've come across running my script on SIMBA. Maybe has something to do with the chat, but I wasn't sure.

On a side note, dang, this thing compiles fast.

Simba isn't an acronym. :<

Anyway. There's not perfect text finding. :/

From: i luffs yeww
Simba isn't an acronym. :<

Anyway. There's not perfect text finding. :/

Well, in SCAR it's not making those mistakes. That is what I mean? This is bug reporting forum, I'm reporting it.

Whoops on SIMBA :P

You can make a function that compares several strings in that string, but i guess you already knew that :)

Well, I think this should just be fixed in Simba. ;)

The reason this happens is because we also see some pixels/text from other lines. (They overlap)
Like the J from the line above out own message, etc. Since SCAR uses pure bitmap comparisons for this(afaik), it doesn't really have this problem.

There are several solutions for this. An easy one would be to not return '?' when we can't ID a char, and instead return ''. This would probably save a lot of trouble already. But if we really want a good algorithm, we can also just do a findcolors and split some points, filter a bit (If it looks like noise, removing the points) and then pass it to Simba. (We can add that function, OCRPointsToText or alike. It's used internally anyway)

From: Wizzup?
Well, I think this should just be fixed in Simba. ;)

The reason this happens is because we also see some pixels/text from other lines. (They overlap)
Like the J from the line above out own message, etc. Since SCAR uses pure bitmap comparisons for this(afaik), it doesn't really have this problem.

There are several solutions for this. An easy one would be to not return '?' when we can't ID a char, and instead return ''. This would probably save a lot of trouble already. But if we really want a good algorithm, we can also just do a findcolors and split some points, filter a bit (If it looks like noise, removing the points) and then pass it to Simba. (We can add that function, OCRPointsToText or alike. It's used internally anyway)

Which ever uses less CPU, is accurate, and is the reading speed of an average human.

From: Diddy Kong
Which ever uses less CPU, is accurate, and is the reading speed of an average human.

I would think both programs already exceed that expectation :p

From: Diddy Kong
Which ever uses less CPU, is accurate, and is the reading speed of an average human.

Data reading speed <> inhumanity

The speed with which the program reads colors/texts should always be as fast as possible, but moving mouse/sending keys to these points/texts should be humanlike.

I fixed this issue, will commit when next binary comes out.. (It's actually a Runescape issue, but whatever).

Goto runescape and type 'ggggggggggggggggg'
Now type '|||||||||||||||||||||'.. As you can see the | will go into the line of the g's.. This is the reason why the OCR picked more pixels than it 'should', which resulted in weird letters ;).