SRL Archive - Jr. Member General Help and Discussion

Greets -

So, I'm using the dtm editor to make some dtms of the new interface. I made one for empty inventory slots in the backpack tab. When I clicked 'Show matching dtms', things got a little crazy. This happens every time I do this, so it is not just a fluke.

The editor itself freezes and I have to close it, but Simba also gets nuts and starts consuming memory like crazy. I have to use the task manager to close it. I am using Simba 1.0 (even though the error logs say 992) and SRL-5. Here are some screenies (sorry they are kinda big) from before telling it to locate matching dtms and after:

Before: [ATTACH=CONFIG]22083[/ATTACH]

After: [ATTACH=CONFIG]22082[/ATTACH]

Notice the differences in memory consumption for both java.exe and simba.exe

And here is a sample of one of the 469 error logs generated:

Program exception! 
Stacktrace:

Exception class: Exception
Message: ReceivedError not available for this target
  $006FE1C4
  $00506E85
  $00506DEF
  $00510AF5
  $754962FA
  $75497B16
  $754979C7
  $7549788A
  $005115A5
  $00421D09
  $0042214F
  $004334F3
  $0042210A
Simba Version: 992

I know the obvious answer to this is "Don't do that." But, I think I should be able to do this.

The DTM editor and Simba will crash if you click show matching DTMs and there are a ton of DTMs that match. Try adding more points or lowering the tolerance.

From: BMWxi
The DTM editor and Simba will crash if you click show matching DTMs and there are a ton of DTMs that match. Try adding more points or lowering the tolerance.

Thanks for the reply. The tolerances were set at 5 for the primary point and 15 for the 8 supplementary points. I know there were 20 open inventory slots, so I'm sure that would have been a problem. But the memory consumption was incredible.

From: loragnor
Thanks for the reply. The tolerances were set at 5 for the primary point and 15 for the 8 supplementary points. I know there were 20 open inventory slots, so I'm sure that would have been a problem. But the memory consumption was incredible.

I had this problem as well, i found that when the points are black or dark brown in color you get a f**k load of matches all over the inventory. I usually find it more beneficial to have my main point with a higher tolerance and my supplementary points of a lower tolerance.

Its also best to 'Show Matching Colors' periodically to make sure your tolerance isn't so high that its flagging the majority of the screen >.<

From: GREEN GIANT
I had this problem as well, i found that when the points are black or dark brown in color you get a f**k load of matches all over the inventory. I usually find it more beneficial to have my main point with a higher tolerance and my supplementary points of a lower tolerance.

Interesting. I will give that a shot and see what difference it makes.

From: loragnor
Thanks for the reply. The tolerances were set at 5 for the primary point and 15 for the 8 supplementary points. I know there were 20 open inventory slots, so I'm sure that would have been a problem. But the memory consumption was incredible.

If the DTM is of an item, I have the mainpoint to have a tolerance of 15 or 20, and the subpoints have a tolerance of 0. I do this because I always make my subpoints be on the black outline of the item, and this color is static afaik.

From: BMWxi
If the DTM is of an item, I have the mainpoint to have a tolerance of 15 or 20, and the subpoints have a tolerance of 0. I do this because I always make my subpoints be on the black outline of the item, and this color is static afaik.

Well, I appreciate the tips, but even this doesn't help. I will just have a care to save my scripts often and not put too much of a load on the editor. Hopefully, this can be addressed at some point in the future once most of the dust has settled with SRL-6 and etc.

For static applications, graphics in designated areas like inventory, prayer/curses, spell icons, etc.; are bitmaps better to use than dtms?

From: loragnor
Well, I appreciate the tips, but even this doesn't help. I will just have a care to save my scripts often and not put too much of a load on the editor. Hopefully, this can be addressed at some point in the future once most of the dust has settled with SRL-6 and etc.

For static applications, graphics in designated areas like inventory, prayer/curses, spell icons, etc.; are bitmaps better to use than dtms?

I don't know, I've never used bitmaps for finding anything before. Also how many points do you have? If it's an item then have 1 mainpoint with 15 tol, and as many mainpoints on the black border as you can fit with 0 tol.

From: BMWxi
I don't know, I've never used bitmaps for finding anything before. Also how many points do you have? If it's an item then have 1 mainpoint with 15 tol, and as many mainpoints on the black border as you can fit with 0 tol.

I was making a dtm of an empty inventory spot. I used 9 points, 20 tol for center, 0 tol for each of the 4 corners, and 0 tol for points nearer to center that would preclude any items. Since there are 8 items in my inventory, it should have marked 20 empty slots. However, I don't know how many times a dtm would have been selected given some standard variance.

As for bitmaps, I know that the old (pre-RS3) login system uses bitmaps to locate some icons. The FindSymbol function uses bitmaps to locate symbols on the minimap. And the bitmap.simba file has 111 bitmaps of various things like ores, bars, etc. So, bitmaps are used fairly extensively.

I was just wanting to create a library of new icons used with the new interface and started with dtms. I may fold and use bitmaps instead. Just wasn't sure if locating dtms is quicker than locating bitmaps.

The main issue you're having is that you're searching for emptiness in the inventory. If your inventory is empty then you'll have literally tens of thousands of matches (if not, then more).

The typical method for how we currently handle this in SRL is to sort the inventory into evenly sized boxes (28 of them as that's the size of your inventory). I'm less certain on the check within each box, but I'm pretty sure it's either a bitmap of the size of the box, or it's a dtm of the same size as the box to ensure it only tries to match once.

From: Kevin
The main issue you're having is that you're searching for emptiness in the inventory. If your inventory is empty then you'll have literally tens of thousands of matches (if not, then more).

The typical method for how we currently handle this in SRL is to sort the inventory into evenly sized boxes (28 of them as that's the size of your inventory). I'm less certain on the check within each box, but I'm pretty sure it's either a bitmap of the size of the box, or it's a dtm of the same size as the box to ensure it only tries to match once.

I'm pretty sure the check within each box is just if there is any of the black outline color.

From: Kevin
The main issue you're having is that you're searching for emptiness in the inventory. If your inventory is empty then you'll have literally tens of thousands of matches (if not, then more).

The typical method for how we currently handle this in SRL is to sort the inventory into evenly sized boxes (28 of them as that's the size of your inventory). I'm less certain on the check within each box, but I'm pretty sure it's either a bitmap of the size of the box, or it's a dtm of the same size as the box to ensure it only tries to match once.

K. In looking at inventory.simba, the method is to look in an inventory slot, then use FindColor to look for srl_outline_black. If the color is found, then something is there, otherwise it is empty. I'm chasing a red herring. Thanks.

Still, it would be nice at some point to put a limit in place for how much memory the dtm editor can consume. I am loath to let it run it's course to know what that limit may be now, but it would seem nearly insatiable under the right conditions.

Thanks all.

From: loragnor

Still, it would be nice at some point to put a limit in place for how much memory the dtm editor can consume. I am loath to let it run it's course to know what that limit may be now, but it would seem nearly insatiable under the right conditions.

Yeah, it would be nice to be able to set a maximum amount of DTMs or something similar. And if it finds more then that number it would give you a "Found more than X DTMs. Stopping DTM search to avoid a crash." message or something like that.

From: BMWxi
Yeah, it would be nice to be able to set a maximum amount of DTMs or something similar. And if it finds more then that number it would give you a "Found more than X DTMs. Stopping DTM search to avoid a crash." message or something like that.

I would support something like this (with a possibility to change what 'X' is perhaps) as opposed to trying to allow it to find them all. It's a vast cpu waste to allow it to find thousands and thousands of a dtm, when it's better to have simply made a more accurate DTM with better search parameters.

From: BMWxi
Yeah, it would be nice to be able to set a maximum amount of DTMs or something similar. And if it finds more then that number it would give you a "Found more than X DTMs. Stopping DTM search to avoid a crash." message or something like that.

From: Kevin
I would support something like this (with a possibility to change what 'X' is perhaps) as opposed to trying to allow it to find them all. It's a vast cpu waste to allow it to find thousands and thousands of a dtm, when it's better to have simply made a more accurate DTM with better search parameters.

Rather than an arbitrary limit, using some algorithm to not show duplicate or nearly duplicate dtms. If it finds dtms at (300,200) and (302,201) and (303,201), it should be able to discard some of these points in favor of a representative point. Instead of 'Show all matching dtms', would say 'Show representative dtms' for a case where there may be a large number of returns.

From: loragnor
Rather than an arbitrary limit, using some algorithm to not show duplicate or nearly duplicate dtms. If it finds dtms at (300,200) and (302,201) and (303,201), it should be able to discard some of these points in favor of a representative point. Instead of 'Show all matching dtms', would say 'Show representative dtms' for a case where there may be a large number of returns.

I think it would be more useful show all DTMs or tell the scripter that their DTM isn't good enough. If you discard some DTMs then that wouldn't be a good representation of what FindDTM would give ingame.

Also an arbitrary limit is fine, because what if you only want say, 28 of a DTM? Then you set the limit to 100 and if it finds more than that you know instantly that your DTM is not good enough.

From: loragnor
Rather than an arbitrary limit, using some algorithm to not show duplicate or nearly duplicate dtms. If it finds dtms at (300,200) and (302,201) and (303,201), it should be able to discard some of these points in favor of a representative point. Instead of 'Show all matching dtms', would say 'Show representative dtms' for a case where there may be a large number of returns.

But that would remove the option for the truly matching dtms. In any given case I can imagine, the solution can be done scripter-side simply by making more accurate DTMs and limiting the search area the area actually requiring a search.

From: BMWxi
I think it would be more useful show all DTMs or tell the scripter that their DTM isn't good enough. If you discard some DTMs then that wouldn't be a good representation of what FindDTM would give ingame.

Also an arbitrary limit is fine, because what if you only want say, 28 of a DTM? Then you set the limit to 100 and if it finds more than that you know instantly that your DTM is not good enough.

From: Kevin
But that would remove the option for the truly matching dtms. In any given case I can imagine, the solution can be done scripter-side simply by making more accurate DTMs and limiting the search area the area actually requiring a search.

K. You are much more savvy about simba and the ins and outs of scripting with these resources than I am or will be. I can't argue the truth of responsible scripting while searching for dtms and such. No doubt mine was too limited to more specifically identify what I was looking for and I caused this issue.

My concern in making this thread was with the dtm editor and the possibility of a computer crash, the loss of perhaps hours of scripting (depending on the person's habits), and whatever other kind of mayhem could be caused by this extension chewing up memory at a rather fast pace. However, I will leave this go and trust that if it needs to be looked into it will.

Thanks for your help and instruction.

From: loragnor
K. You are much more savvy about simba and the ins and outs of scripting with these resources than I am or will be. I can't argue the truth of responsible scripting while searching for dtms and such. No doubt mine was too limited to more specifically identify what I was looking for and I caused this issue.

My concern in making this thread was with the dtm editor and the possibility of a computer crash, the loss of perhaps hours of scripting (depending on the person's habits), and whatever other kind of mayhem could be caused by this extension chewing up memory at a rather fast pace. However, I will leave this go and trust that if it needs to be looked into it will.

Thanks for your help and instruction.

Oh, as for crash safety and script recovery, I believe @Turpinator threw out a tutorial on recovering lost scripts somewhere, right turp?

From: Kevin
Oh, as for crash safety and script recovery, I believe @Turpinator threw out a tutorial on recovering lost scripts somewhere, right turp?

Thats only if your simba is hung.

Buuut… you should have Crov.sex enabled in the extension menu already.