Suggestions/improvement proposals regarding some of GG features

[CmP]

Greetings.
In this topic I will share my suggestions about possible ways to improve GG features as well as examples of unintended behaviour of the app.
Will update the topic with new findings as soon as I prepare proper explanation for them.

Pointer search
It's a great feature which saves us time when need to find pointers to an address or a range of addresses.
However, current implementation for searchimg a range of addresses (when we specify non-zero offset) seems not best for me.
In current implementation search is performed from address - offset value to adrress value. 
Good way to illustrate this is to show a part of "pointer_scan.lua" script  (released by Enyby) where search string is being constructed:

local search = (address - offset)..'~'..address
gg.searchNumber(search, gg.TYPE_DWORD)

My suggestion is to change this feature's implementation a bit, so the search may be performed in 1 of 3 modes:

• from address - offset to address (current implementation);
• from address to address + offset;
• from address - offset to address + offset.

One possible way is to add something like "multi-choice" containing two options with offset directions. Total combinations of possible user inputs will be equal to 4 in this case (3 "modes" that were described above and the option when nothing is selected, in this case offset value may be ignored).

In my opinion, this will add more flexibility to the feature as well as making it more "understandable" for the user.
Let me know, what do you think about it. Сheers.

[Enyby]

The offset must be subtracted.
Let's imagine that we have such a structure:
 

struct {
	uint32_t health;
	uint32_t ammo;
	uint32_t silver;
	uint32_t gold;
} player;

And we also have a pointer to it.
 

player* curPlayer;

Take the gold field from the structure. The offset of this field is 12 bytes, relative to the beginning of the structure.
The pointer stores the address of the structure.
We found the location of the gold field through GG. And we know the offset - 12.
How do we find a pointer to a structure? Subtract from the address that we found, the desired offset.
It is to subtract, not add.

Therefore, this behavior is chosen.

And if you enter all the options - this will only confuse unprepared users.

If you need to look ahead, you can enter a negative offset, but there is no point in that. Why, I showed above.
Pointers always point to the previous address, not to the next one.

If you have a pointer to an array, then all elements of the array will have larger addresses than the array pointer, except for the zero element.

Therefore, a negative offset has no meaning.

[CmP]

Thanks for the reply, I understand what do you mean.
I have some gap between what I know about data structures, memory allocation etc and my "practical experience" - working with process memory.

I did not know that negative offsets have no meaning, but knew that they can't be used at all with current implementation.
Negative offset cause the app to search for non-existing interval of values where "from" value is bigger than "to" value.
Taking this into account, it may be reasonable either to change implementation a bit so that searching interval will always exist or to add the check for offset value (displaying a warning when user inputs negative number that only positive integers can be used). 

Edited May 13, 2018 by CmP

[CmP]

Search results filters (part 1)

Another great feature that GG offers to us.
Although filters do their job well, there are some cases, where the result may differ from expected one.
"Number" filters are intended for filtering results by their value. When working with the results of a same type, these filters mostly produce correct result, but if search results list contain elements of different types (auto search was used), then number filters might produce the result that does not meet user's expectation.

Here are some examples of such behaviour:

1. Values with a fractional part cause all elements of byte, word, dword, qword types to be filtered out, even if their value meets the condition of the filter.
   
   Example: input "10.8" value to "Number >=" filter leads to hiding all integer values, even those that are equal 11 or greater.
   
      
2. Values without a fractional part cause some elements of float and double types to be included in search results list after applying the filter, even if their value does not meet the condition of the filter.
   
   Example: input "514" value to "Number >=" filter leads to displaying several float values, which are smaller than 514.
    

Spoiler

Initial filter:

Search results:

Applying filter from the example's description:

Search results after applying the filter (values in the range (-infinity ; 513] have been filtered out, but somehow values in range (513 ; 514) were considered as values that meet the condition in the filter):

Cases that were reviewed in this post aren't common.
However, in my opinion, it may be worth to improve number filters, considering these examples.

Let me know what do you think about it.
Also I can provide other examples if you think that these do not illustrate the issues well.

Edited May 18, 2018 by CmP
Corrections

[Enyby]

Everything works as it should. There is no mistake.

1. If you specify a fractional value, then you know that the result will be fractional. So the integer do not fit.
This is dictated by elementary logic. If the user entered a condition greater than 10.8, then he did not take the number from the ceiling, but from the game, and all the results should be fractional.

2. You can not know how rounding works in the game. This can be a mathematic rounding, floor or ceil. Therefore, the filter takes the maximum option.
When you specify more than or equal to 514, in game 513.01 can be rounded up to 514. And the filter should show this value.

The filter is built on the basis that the user enters the numbers that he sees in the game. He does not know how it is in memory.
That's why there are such features.

When developing the filters, all these moments were taken into account. This is not an accidental behavior. These moments were realized in this way deliberately.

[CmP]

22 hours ago, Enyby said:

The filter is built on the basis that the user enters the numbers that he sees in the game.

I get the idea and admit that these solutions are really good for finding desired values in memory.

However, there is one detail regarding your reply to the second example from my previous post.

23 hours ago, Enyby said:

2. You can not know how rounding works in the game. This can be a mathematic rounding, floor or ceil. Therefore, the filter takes the maximum option.

This principle is used when user inputs integer value, but not for values with a fractional part. In the last case number filters do not consider the fact that displayed value may be rounded, showing elements which are strictly equal or greater (in case of >= filter) or equal or less (in case of <= filter). I highly doubt that this behaviour is intended because it contradicts the principle that you stated in the last post.

Let's review one example to make sure that there are no misunderstandings.

Spoiler

Imagine that user sees "10.5" value in the game. As the displayed value can be rounded (math rounding, floor, ceil), actual value in the memory can be anything from the following interval: from 10.4 non-inclusive to 10.6 non-inclusive. Now let's see, what result will we get upon using number filters on six values all of which are within possible range.

Search results without filters being applied:

Applying the filter ">= 10.5":

Filtered search results:

Looks like possibility of the value being rounded when displayed to the user is not considered.
Now let's see what happens if we apply the opposite filter.

Applying the filter "<= 10.5":

Filtered search results:

Same result here, only elements with values that are meeting filter condition are shown.

So why number filters consider that displayed values may be rounded ONLY if integer was entered?
Can't user see a value with a fractional part that is rounded when displaying?

[Enyby]

Because the user sees in game 10 and enters 10. And we do not know, 10.0 is it or just 10.
You can enter 10.0 and see the difference.
Rounding only works up to integers.
A typical situation is the distance in the runners. The screen always has an integer distance value. And in the game it is fractional.
The user will enter integers in the filter. Therefore, you need to consider all possible rounding options.

This applies only to integers. In other cases, you can not know what kind of number there is and adjust the user input.
Perhaps 10.5 is 10.50, and perhaps 10.45 rounded to 10.5. This can not be traced and recognized.

[CmP]

35 minutes ago, Enyby said:

Rounding only works up to integers.

It is most common case, there is no problem to implement rounding to tenth, hundredth of the fractional part and so on. Moreover, games that display values with a fractional part likely use not standard rounding functions/methods (which produce integer as their result).

I can name at least one example of values that are displayed with the fractional part - some of stats in RPG games like crit chance, hit chance etc.
Why this case doesn't fit to your examples with displayed values and their real value in memory?

Edited May 19, 2018 by CmP

[Enyby]

Because users do not understand what meaningful zeros are.
Because no one will write 10.500. Everyone will write 10.5. And go understand, there are further zeros or this rounding.
If the user is so clever, he will write 10.4 and that's it.

[CmP]

4 minutes ago, Enyby said:

If the user is so clever,

then he also will be able to consider possible range for value in the memory regardless of how is it displayed ?

[Enyby]

We can not make silver bullet.

[CmP]

1 minute ago, Enyby said:

We can not make silver bullet.

Indeed.

I just try to share some ideas which may somehow improve the app.
There is a possibility that you will find some useful suggestions among these posts. This motivates me to post what I discover.

[Enyby]

We can not make helpers for all cases. On the most obvious - yes.
In other cases - the user must decide what to look for. Rounded or not.

For example, if a person enters a search in 0.5, we can not know what the user meant. 0.5 exactly, or this rounding.
Therefore, the most general variant is assumed, which will allow to take into account all the nuances.
Those who need an accurate search are looking for 0.5. Those who need rounding can be called 0.45 ~ 0.59. Or 0.495 ~ 0.504.
This path allows the user to decide for themselves with what precision and how to search.
And this makes the tool more flexible.
Any assumptions about rounding make exact search impossible. And most often, it is what he is needed.

As for proposals, they are always welcomed.
Your posts are sound and sober, for which you are a special thank you. This is a big rarity here.

[CmP]

2 hours ago, Enyby said:

Because users do not understand what meaningful zeros are.
Because no one will write 10.500. Everyone will write 10.5. And go understand, there are further zeros or this rounding.

Makes perfect sense, totally forgot about this, when was trying to extrapolate your statement about values rounded to integers on values rounded to float with some precision. The matter is closed, thanks for explanation!

[CmP]

Values with "Auto" type in range search

Type "Auto" for a search is useful option when user does not know how exactly desired value is stored in a process memory.
Nevertheless, there are some cases in which search of type "Auto" won't behave as you expect it to.

The problem has been observed upon performing a search for a range with the type "Auto", where any of range borders is float number (number that contains fractional part).
In such cases GG won't search exactly for the range that you have specified.

All problematic cases, I think, can be divided into 2 types:

1. One of range borders is float number, another one is integer, e.g. "5~8.25", "11.4~22".
2. Both of range borders are float numbers, e.g. "1.11~3.33", "-20.5~-15.0".

Note: ranges, where both of borders are integers, are being interpreted correctly.

Here are more detalied review of case types with the examples:

1) Range with integer borders.

Quote

Case: perform a search with the search string "540~560" and type "Auto".

Expected behaviour: app performs a search for values of any type that fall in range [540; 560].

Observed behaviour: app performs a search for values of any type that fall in range [540; 560].

Illustrations:

2) Range with one float number border.

Quote

Case: perform a search with the search string "1400~1450.52" and type "Auto".

Expected behaviour: app performs a search for values of any type that fall in range [1400; 1450.52].

Observed behaviour: app performs a search for values of any type, not all of which fall in range [1400; 1450.52] and not even in range [6.916919e-321; 1450.52] (range that is shown in search progress window).

Illustrations:

Comments: was not able to reveal the pattern, but it look like undefined behaviour (just an assumption). Also zero values of "XOR" type were found, values of any other type were present in the results. There were very few values equal to 0 (46 from 2 421 844 results), all of them were integer (in particular - word, dword, qword types).

3) Range with both borders being float numbers.

Quote

Case: perform a search with the search string "17.1~18.9" and type "Auto".

Expected behaviour: app performs a search for values of any type that fall in range [17.1; 18.9].

Observed behaviour: app performs a search for values of integer types (except "XOR"), most of which (or even all) are equal to max possible value for their type (byte - 127, word - 32767, dword -  2147483647 etc).

Illustrations:

Comments: in this test case 14043 results were found, 13222 from which were of type "Byte" (all were equal to 127), 427 - of type "Word" (all were equal to 32767), 370 - of type "Dword" (all were equal to 2147483647), 24 - of type "Qword" (all were close to some big value, see screenshot below, and none were equal to max possible value for this type).

 

P. S. Had to use quotes instead of spoilers because consecutive spoilers (even separated by other text) were producing embedded structure of spoilers in post preview.