CmP

gg.setVisible(false) gg.searchNumber('123;4567;8901', gg.TYPE_DWORD) local results = gg.getResults(100) -- may return a string with error in some cases for i, v in ipairs(results) do if v.value == '123' then v.value = '545454' elseif v.value == '4567' then v.value = '998877' end gg.setValues(results) -- may return a string with error in some cases -- script will be ended when user opens GG interface by clicking on the floating icon while true do if gg.isVisible() then break else gg.sleep(100); end end os.exit()

Then you simply need to search it right after performing group search. There is a function called "gg.setVisible" for this purpose. See API docs. https://gameguardian.net/help/classgg.html#a4ad04f38598e00a393edc274e38b2009 Here is the example of applying these things to your script: gg.setVisible (false) gg.searchNumber ('123;4567;8901', gg.TYPE_DWORD) gg.searchNumber ('123', gg.TYPE_DWORD) gg.getResults (100) gg.editAll ('545454', gg.TYPE_DWORD)

That's amazing, because I usually face similar situations that NoFear described. I understand that implementing such feature won't be easy, just wanted to show that it may be helpful for anyone who is familiar with the app. Keep up the good work!

You don't really need to buy anything in order to learn programming. There is no problem if you want to and prefer it. I just try to tell you that internet is full of any kind of information, so it may be reasonable to google what you need at first. Good luck with learning, by the way ?

Can't help you with this as I don't play the game. Read the comments above.

I fully agree with this, but there is one little misunderstanding. I am not the author of the script nor have any relation to the real one. So that guy stole someone's else work. I just did little reverse-engineering job to get the soure code, then removed all redundant parts, because I think that members of this forum have the right to get good-quality content and not scripts with bunch of useless code which does not help in any way. For example, useless encryption of the source code (it's useless because password that let's user run the script also let's him to get the source code) caused the file to be insanely large (88 kb), while decrypted version of that file has the size around 11 kb. That's why I am not sure about being the author of file here, cuz it may look like I am one of those guys who leech scripts somewhere and upload here.

Here is this script, but without: useless encryption of the source code; checks for passwords; check for time of script launch; check for some non-existing version of the app (see below); annoying (I assume) credits everywhere; some useless function for hiding UI and killing game process if you try to check what is being searched (see below); some_script_reworked.lua P.S. Don't fool yourself by using such scripts.

You may try editing it to "-1" which corresponds to ~4 bil if the value is unsigned.

Editing value at corresponding address to 10 bil as qword cause such result as the game, like you said, considers only 4-byte integer value for the amount of bet. Before: Not best way to edit dword value ?: After:

This is online game -> amount of gold and gems is stored on the server. Likely, it is not possible to hack them by editing process memory.

Which game is it? Post it's name or link to it on Play Store.

That's because you use very old version of the app. Download and install latest version. You will be able to choose qword and double types there.

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!

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.

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

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?

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. 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. 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?

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: 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. 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. 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.

Little misunderstanding, it's clear for me now, thank you for spending time on this.

Did a quick test. Had 8.56.0 version, changed some settings as well as floating icon position on the screen. Then installed 8.57.0 version. 2 shortcuts for the new version have been added to the main screen (shortcuts of the old version remained, because, as you have written, GG can't detect old versions in no root mode). Unfortunately, settings from the old version weren't copied - default settings have been applied.

Nice! One question about working without root. What is the proper procedure to update GG in this case? I assume that old version needs to be uninstalled before or after installing the new one.

@Enyby, it works really well in root mode, thanks for that! And what about no root mode, any chances to restore app settings after udpating the app?

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).

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.

Because it was a joke... No "Magic edition" will be released, wasn't this obvious for you? By the way, you provided wrong screenshots once again As I can see, Enyby asked for GG start screen pics (where "Start", "Fix it", "Verification" and other buttons are located).