CmP

The group search is not ordered, so I would prefer second approach from those Enyby mentioned. For this case it would be something like the following: gg.setRanges(gg.REGION_ANONYMOUS) gg.clearResults() gg.searchNumber('1014350479;1012202996;1083179008;1050253722;1031127695;1065353216;1065353216;1067282596:61', gg.TYPE_DWORD) local results = gg.getResults(5000) local edited = {} for i, v in ipairs(results) do if v.value == 1014350479 then edited[#edited + 1] = {address = v.address, flags = v.flags, value = 1011011011} elseif v.value == 1050253722 or v.value == 1031127695 then edited[#edited + 1] = {address = v.address, flags = v.flags, value = 1} end end gg.setValues(edited)

@Puje you need to call "getValues" function to update the values. See this example: Examples of Lua scripts (#4rb1nadf)

Because it's the .lasm file (disassembly). You get the .lua file when executing it. I have explained it in this post: Why Script Ended:Script Error ? (#cor0fe4l) From what I see on the video, official version of the launcher that you downloaded from BadCase's site finishes with an error right after you execute it. That's simply because it's not compatible with newest version of GG. Second script that you use is probably from this post. Both official version and this version contain the error of using "W" as second argument to "io.open" function, that is fixed in the file from this post. It should work properly, unless there are some other errors of which I am not aware. One thing you should understand that the launcher and a script for a particular game are two different scripts. The launcher downloads a script for some game and executes it, everything else is done by the downloaded script. If there is an error in the downloaded script, it has to be fixed and updated version has to be uploaded to the server before you can use it with the launcher. So just wait until the author of the script for your game will fix it and upload to the server. This video and screenshots clearly show that modified version of the launcher works fine for you, while the error occurs in the script for the game.

@AliceAlmony this issue is not connected with the launcher being incompatible with the latest version of GG, so I can't help you with it. You will probably need to wait for BadCase to update the script for your game (as he has written above). You can use 87.3, because fixed version of the launcher is compatible with it. Not to mention that GG is continuously improving and each new version is better than previous one.

The solution was "surprisingly" to replace that "W" with "w". I have already done it and posted the file in my previous post. Try it.

It worked for me on the video, because not latest version of GG was used. Here is fixed version of the .lasm file to work on the currently latest version of GG (87.3): BadCaseScriptLauncher_fixed.lasm UPD: Did the same actions as in my video above, but with the file from this post and GG 87.3, script worked properly.

@AliceAlmony I could not reproduce the error you are having: Make sure that you download and execute the file from my post.

@AliceAlmony little confusion happened, because the file I have uploaded in the previous post is edited .lasm file (the one GG produces when "Disassemble" feature is used). When such file is executed, GG produces .lua file that corresponds to it and places it in the same folder. That's what happened when you executed it and received this output: Likely, you did it 2 times and that's why you have 2 of same .lua files produced by GG here: The files are equal, so you can leave only one of them and name it how you like. Then, when you execute the script produced by GG from .lasm file, GG asks the following: because the script needs Internet access to work. Obviously, if you don't allow the access, the script won't work, but if you will, the script will work fine. The decision of whether to allow the access depends on presence or absence of your trust to the script author and the file in particular. Since the version above is slightly different from original version of the script, you can compare their disassembly (.lasm files) produced by GG to make the decision.

Fixed version of the script that works with currently latest version of GG (87.2): BadCaseScriptLauncher_fixed.lua All credit goes to @BadCase.

View File Search results auto backup This script is a helper tool that automatically saves previous search results list so that it can be restored later. How to use: 1. Start the script. 2. Enter maximal count of saved results. 3. Perform the searches or any other results list modifications until you need to restore previous results list. 4. Activate script menu by pressing floating button with "Sx" text. This video can help to locate the button: https://gameguardian.net/forum/gallery/image/618-900-added-ui-button-for-scripts-gameguardian/ 5. Choose "Yes" to restore saved results list / choose "No" or cancel the dialogue to continue script execution / choose "Exit" to terminate the script. Submitter CmP Submitted 10/05/2019 Category Tools  

Yes, thanks for notice, I have corrected the examples.

You need to handle the result returned by "multiChoice" function properly. According to the function documentation, returned value is either nil (in case of dialog being cancelled), or a table in which selected keys contain value "true". Therefore, proper handling may look like this: local choices = gg.multiChoice({'Option 1', 'Option 2'}) if choices == nil then -- action if dialog has been cancelled else if choices[1] then -- action if first option has been selected end if choices[2] then -- action if first option has been selected end end However, there may be tricky cases where one action prevents other action(s) from being executed. One of such cases is "goto" statement. Once it is executed, all other conditions won't be checked and therefore no actions will be executed. Consider the following example: local choices = gg.multiChoice({'Option 1', 'Option 2'}) if choices == nil then os.exit() else if choices[1] then print('Option 1') goto finish end if choices[2] then print('Option 2') end end ::finish:: Here, if user selects both option 1 and option 2, only actions related to option 1 will be executed, because after executing "goto" statement script execution continues from the specified label, "finish" in this case. Possible workaround here is to check the condition that represents option 1 being selected after all other conditions, so that other conditions will be checked first and related actions will or won't be executed depending on the result of each check. But this workaround can't be applied to the cases where there are "goto" statements in 2 or more blocks of actions related to different conditions. So don't use "goto" and there will be no need to deal with such problems. Use functions instead. There are quite little amount of cases where usage of "goto" is justified and your case is not one of them.

It's xor-encryption with the key "1 545 691 265" (equal to value with 0 coins). 1 545 691 265 xor 37 = 1 545 691 300 1 545 691 265 xor 487 = 1 545 691 494 Therefore, to get encrypted value Y that corresponds to real value X, you need to use the following formula: Y = 1 545 691 265 xor X This will work, if the key is constant. If it is not, you will first need to find it out to be able to calculate encrypted values.

That was a temporary solution for searching/replacing text (string, HEX, array of bytes). Clicking the button caused the following script to be executed: Text (string, HEX, AoB) search/replace (#6a821ivq) Latest few updates introduced a general solution for both searching and editing text (including UTF-8 and UTF-16LE encoded text). Refer to the following video tutorials to get the idea of how it works now: 80.0: Text (string, HEX, AoB) search - GameGuardian (#bvil9mxj) 79.0: Edit UTF-8 text (C String) - GameGuardian (#g2vdech) 79.0: Edit UTF-16LE text (Java String) - GameGuardian (#7itpk8ge)

"Pointer search" feature in GG will find all pointers to the value, if the offset is set to 0, or to the range of values , if the offset is set to a positive integer. There may be no results or too many results. Adjust "offset" parameter accordingly. Once you have the list of pointers to desired value/structure, according to the document, you need to filter the list "until the number of pointers will not decrease". That's how filtering is done there: Obviously, this won't work for Android. So you need to think of another way to reduce the count of found pointers or simply use all of them to keep the reference to desired value. Short conclusion (and probably the answer to your initial question): filtering of found pointers on Android can not be done as described in the document, because restarting the process causes all values to relocate.

Yes, just as I have written in one of the previous messages.

They don't stop to work, but their address will be different after every process restart. For example, you found a pointer. It's address is 0x5522AA00. Then you restart a process and check the address. There will be another value. It may be just some regular value or it may be a pointer, but different one, that points not to the structure/value you expect. And the pointer you have found before, will be located, for example, at address 0x4488AA00.

Quote from the first page: While this may be true for PC, it is not for Android. On Android there is ASLR. After the process is restarted, all values change their location. Therefore, the method described in the document won't help with finding the value after the process is restarted.

To select specific items use "getListItems" function and filter items that match condition. Example of selecting frozen items with freeze type "freeze in range": local items = gg.getListItems() for i, v in ipairs(items) do if (not v.freeze) or (v.freezeType ~= gg.FREEZE_IN_RANGE) then items[i] = nil end end To change values of the selected items use "setValues" function (if only value needs to be changed) or "addListItems" function (if anything of the following needs to be changed: freeze state, freeze type, "freeze from" value, "freeze to" value). Example of changing values of the previously selected items: for k, v in pairs(items) do v.value = '123' end gg.setValues(items)