Requests for GG

[Eduardo28]

I looked for a topic for this subject but did not find it, sorry if I put it in the wrong place.

I have two suggestions for the GG API.

1) A function in api GG that updates the analyzed process memory (eg game)

Some games have memory allocated dynamically, in other words, loads data into memory only when needed. When the GG is run it will analyze the memory of the process allocated at that moment. It is necessary later to have to update the analyzed memory manually in the GG.

Anyway, there comes my need / request, I want a function in the GG API that updates the memory analyzed by the gg of the game process.

2) Colors in api prompt menu

If possible add the "Choice" and "multiChoice" functions as well.

More for a visual effect and having a better user interface, I need to replicate the use of the colors present in the "SpeedHack: functions" menu (example in the screenshot below)

Many thanks to the GG team for the excellent work!

Edited January 4, 2019 by Eduardo28

[BadCase]

It would be nice to be able to use colors like in the Speedhack Functions menu

[Enyby]

1. Run search again if you need update found data.

2. It is not important feature.

[CmP]

8 hours ago, Enyby said:

1. Run search again if you need update found data.

He probably meant info that GG receives when it is attached to the process.
For example, list of memory regions, total "size" of process in memory, etc.

[Enyby]

https://gameguardian.net/help/classgg.html#a8bb9745b0b7ae43f8a228a373031b1ed

getRangesList

[CmP]

53 minutes ago, Enyby said:

https://gameguardian.net/help/classgg.html#a8bb9745b0b7ae43f8a228a373031b1ed

getRangesList

Well, this function is indeed very useful, but the question is: does it return updated information about process memory regions (because this is what author of the topic has written about, I suppose). I tried to find an answer to this question and got the following results.

Script that was used for testing:

local function calcTotalSize(ranges)
  local total = 0
  for _, v in ipairs(ranges) do
    if v.state == 'Jh' or v.state == 'Ch' or v.state == 'Ca' or v.state == 'Cd' or v.state == 'Cb' or v.state == 'A' then
      total = total + (v['end'] - v.start)
      --print('start: ' .. v.start, 'end: ' .. v['end'])
    end
  end
  return total
end

local t1 = gg.getRangesList()
print('Start')
print('Count:', #t1)
print('Size:', calcTotalSize(t1))

gg.setVisible(false)
while not gg.isVisible() do
  gg.sleep(100)
end

local t2 = gg.getRangesList()
print('\nFinish')
print('Count:', #t2)
print('Size:', calcTotalSize(t2))

Testing strategy:

1. Select targeted process (to get updated info about it's memory regions).

2. Launch the script.

3. Perform something in targeted process to "trigger" memory allocation/deallocation.

4. Click on GG floating icon.

5. Analyze info from the script output.

Script execution result:

Spoiler

Script ended:
Start
Count: 2328
Size: 99520512

Finish
Count: 2328
Size: 99520512

Conclusion:

Apparently, if I am not missing something, "getRangesList" function does not update info about process memory regions.

[Enyby]

Ranges list update on every new search from scratch.

It is answer your question:

2 hours ago, CmP said:

He probably meant info that GG receives when it is attached to the process.
For example, list of memory regions, total "size" of process in memory, etc.

 

[CmP]

6 minutes ago, Enyby said:

Ranges list update on every new search from scratch.

Got it, thanks for the answer.

I assume that this information will be helpful for other forum members as well, since the question is not so trivial.

[Eduardo28]

Thank you very much for your attention.

9 hours ago, CmP said:

He probably meant info that GG receives when it is attached to the process.
For example, list of memory regions, total "size" of process in memory, etc.

Yes, that's exactly what I meant. Is that for ordinary users using scripts it would be necessary to exit the script to perform the update manually.

To streamline the process and ensure that errors would not occur in the searches because of user failure in not updating the memory. I had the need to have an internal GG function that would update the analyzed memory in an autonomous way.

 

I had not referred to the regions themselves but the size of them. For after the GG append the process any data loaded into RAM after this it ignores.

To save GG processing by constantly analyzing the process in order to update the memory when needed. I thought of a more practical, such a function in class GG that would update the parsed memory only when the programmer set it needed just like it is done in the hack in manual form.

[Enyby]

1 hour ago, Eduardo28 said:

For after the GG append the process any data loaded into RAM after this it ignores.

Wrong.