SRL Archive - OSR Help

What is the best way to call DTMs, all at the beginning and free them all upon termination or load as local integers and free at the end of the procedure?

As a follow up to this question is there any way to get the DTMs not freed to return as a name rather than an array of integers?

i.e.
This

The following DTMs were not freed: [StrangeRock, Ore, StrangeRock, Ore]

instead of this -

The following DTMs were not freed: [3, 4, 5, 6, 7, 8, 9, 10, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23]

Having some troubles working out where this memory leak is coming from, I've tried both ways of calling and freeing the DTMs but I still get a memory build up if I run the script for a long time. Fairly certain I'm freeing all DTMs that are being called.

Better to load them all at the start, and free them at the end.

Also, there is a method to name both DTMs and Bitmaps alike. The one specifically for DTMs is called SetDTMName.

Regards,
~ Daniel.

Many thanks :) Being able to see which DTMs aren't being freed should solve this once and for all!

Sorry for the double post. But, is it an issue that if you are calling a dynamic DTM with the name of the function that created it, like so:

WaitFindDTMEx(BarDTM, x, y, MCx1, MCy1, MCx2, MCy2, 10, 1000)

That it will need to be freed after every calling of the above code?

From: P1ng
Sorry for the double post. But, is it an issue that if you are calling a dynamic DTM with the name of the function that created it, like so:

WaitFindDTMEx(BarDTM, x, y, MCx1, MCy1, MCx2, MCy2, 10, 1000)

That it will need to be freed after every calling of the above code?

How does WaitFindDTMEx create a DDTM? Maybe post the script (or the part with leakages) so that we can have a better look?

I had a function called BarDTM which returned an integer. That integer was the DDTM.
Everytime I called WaitFuncEx(…) The script was re-calling the BarDTM function causing it to back-up, or so it would seem.
I since changed that function to a procedure and declared BarDTM as a global integer for the DTM to be saved as.

This has since fixed my memory leak :)

From: P1ng
I had a function called BarDTM which returned an integer. That integer was the DDTM.
Everytime I called WaitFuncEx(…) The script was re-calling the BarDTM function causing it to back-up, or so it would seem.
I since changed that function to a procedure and declared BarDTM as a global integer for the DTM to be saved as.

This has since fixed my memory leak :)

You should only call that procedure once. For what it is doing if you call it repeatedly is that it is creating a new instance of the (D)DTM every time.

From: P1ng
I had a function called BarDTM which returned an integer. That integer was the DDTM.
Everytime I called WaitFuncEx(…) The script was re-calling the BarDTM function causing it to back-up, or so it would seem.
I since changed that function to a procedure and declared BarDTM as a global integer for the DTM to be saved as.

This has since fixed my memory leak :)

Yeah every time you call DTMFromString() you are (re)loading it. If you intend to use the DTM throughout the script, you should declare it globally and only call DTMFromString() once at the very start (like somewhere after SetupSRL) then free it at the very end (eg. using AddOnTerminate). There is no need to ever recall DTMFromString() as it's stored in memory until you free it.

I still don't understand how the output from DTMFromString() is a DDTM though.

Yes, so it turns out that every time I called WaitFindDTMEx(BarDTM, x, y, MCx1, MCy1, MCx2, MCy2, 10, 1000) another instance of it was created.

Still good to know about the SetDTMName :)


@Riwu - This is the code at fault, I was created a DDTM not using DTMFromString.

function BarDTM: Integer;
var
  dtmMainPoint: TDTMPointDef;
  dtmSubPoints: array[0..5] of TDTMPointDef;
  TempTDTM: TDTM;
 begin
  with dtmMainPoint do
  begin
    x := 293;
    y := 466;
    AreaSize := 1;
    AreaShape := 0;
    Color := Bar.Color;
    Tolerance := 45;
  end;

  with dtmSubPoints[0] do
  begin
    x := 287;
    y := 457;
    AreaSize := 1;
    AreaShape := 0;
    Color := 131072;
    Tolerance := 0;
  end;

  with dtmSubPoints[1] do
  begin
    x := 274;
    y := 469;
    AreaSize := 1;
    AreaShape := 0;
    Color := 131072;
    Tolerance := 0;
  end;

  with dtmSubPoints[2] do
  begin
    x := 286;
    y := 477;
    AreaSize := 1;
    AreaShape := 0;
    Color := 131072;
    Tolerance := 0;
  end;

  with dtmSubPoints[3] do
  begin
    x := 297;
    y := 471;
    AreaSize := 1;
    AreaShape := 0;
    Color := 131072;
    Tolerance := 0;
  end;

  with dtmSubPoints[4] do
  begin
    x:= 303;
    y := 465;
    AreaSize := 1;
    AreaShape := 0;
    Color := 131072;
    Tolerance := 0;
  end;

  with dtmSubPoints[5] do
  begin
    x:= 295;
    y := 457;
    AreaSize := 1;
    AreaShape := 0;
    Color := 131072;
    Tolerance := 0;
  end;

  TempTDTM.MainPoint := dtmMainPoint;
  TempTDTM.SubPoints := dtmSubPoints;

  Result := AddDTM(TempTDTM);
end;

if WaitFindDTMEx(BarDTM, x, y, MCx1, MCy1, MCx2, MCy2, 10, 1000) then  //This line kept re-calling the above function
begin
  {$IFDEF DEBUG}
    SMART_DrawBoxEx(True, False, IntToBox(x - 25 ,y - 15, x + 25, y + 40), ClWhite);
    WriteLn('BarDDTM was found @SmithBars');
  {$ENDIF}
  Mouse(x, y, RandomRange(- 25, 25), RandomRange(- 15, 40), mouse_Left);
  {$IFDEF DEBUG}
    SMART_ClearCanvas;
  {$ENDIF}
end;

Oh, misinterpreted what you mean, cos usually ppl dont name their DDTM creation procedure as 'BarDTM'. The common practice is to name the DDTM created (assigned by AddDTM) as 'BarDTM' rather than the procedure name (eg. here). But i guess what you did is completely fine. :)

Yeah, it would have been completely fine if I didn't come back after a 90min run with my RAM usage through the roof :P

I load all my dtms and bitmaps at the start och the script and Free them with one procedure added in 'AddOnTerminate'.