CmP

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

An example from the topic in "Guides" section: Examples of Lua scripts (#d2j0lrom) If you need other examples, use forum search. Similar questions have been asked multiple times, so it should not be hard to find suitable answer/example.

A review of the example above for anyone who wonders why it works and why one should not code like this. Second line contains the following code: DESTROYER = gg.makeRequest("link").content There are 3 main steps in this code: 1. "makeRequest" function from "gg" table is called with the corresponding argument. 2. Result returned by the function is indexed with the key "content". 3. Value from the step 2 is saved in "DESTROYER" variable. Then, on the third line there is the following code: if not DESTROYER then which checks the condition and executes the code after "then" keyword, if the condition is true. Otherwise, it executes the code after "else" keyword. To understand, why "one should not code like this", let's review the documentation for "makeRequest" function at GG help. https://gameguardian.net/help/classgg.html#ad020d50d3af0a36733e0cbc231055c55 In this case we are interested in the description of the value returned by the function: Now, let's get back to the second line of the example. When function succeeds, the code from the second line behaves as intended. Table returned by the function is indexed with the key "content" and the result of this operation is stored in the variable. And what happens, when there is an error? String returned by the function is indexed with the key "content" and the value is stored in the variable. By default, there is no meaning of indexing string with a key and luckily for the example, the value returned by such operation is nil. But this behavior is not obvious and not obvious behavior may often lead to errors. Then how can the example be modified to avoid non-obvious behavior? The result of the call to "makeRequest" function should be saved to a variable. Then the type of the variable should be checked. If it is "table", the function has succeeded, the variable can be indexed with the key "content" and the result of this operation can be stored in another variable. And if it is "string", then an error occurred, the contents of the variable can be printed to log (via "print" function) and/or shown to the user (via "alert" function). Example to illustrate the answer above: local functionResult = gg.makeRequest('link') local content if type(functionResult) == 'table' then content = functionResult.content elseif type(functionResult) == 'string' then -- print/alert error description end -- other actions Such modification to the code explicitly shows which actions will be performed and when (function succeeds / function fails) getting rid from non-obvious behavior.

Once again, there is a contradiction between your statement and the reality: You keep repeating that there is "execution error" in @TopGEOYT's script "when cancelling" and that your's example does not have it, but without the correction of what you have called "syntax" your example is meaningless and TopGEOYT's is not. We don't know, have you known about the mistake in your example or not before I have corrected it. Therefore, simple conclusion can be made: your example is worse than TopGEOYT's.

If "a long time ago the error was corrected", then the example that is posted less than 1-2 hours ago would not contain it, but it does. It is posted multiple times and all of the posts contain the mistake I have described. Such references to "the logic" do not show that you are familiar with it or that you understand it's base principles at all.

Don't mind him. Someone who can't admit the mistake he made, who really thinks that he is "closing everyone's mouths" when there are no replies on his absurd statements, who is sure that he "won" every discussion he participated into is not worth the attention of adequate forum members. Such behavior is typical for either kids with some kind of childish outburst or trolls.

It will work and also it will check for the value being equal to nil or false. I am not sure, if this check has a meaning (i.e. if "content" field of the table returned by "makeRequest" function can be nil), but even if it doesn't, the example (with the correction) will still work, just that line with the call to "alert" function will never be executed.