CmP

The idea is to read enough bytes at once and then trim the string to first occurrence of quote character instead of reading one byte at a time until quote character is encountered. Generally, first approach should be better in terms of performance, because each read from memory takes significantly more time than several Lua operations, even if just one byte needs to be read. I thought to add 12 to get position of first byte of the answer that is the next one after last quote character in searched string. I don't immediately see why it doesn't work as expected, but it seems that there is a mistake somewhere and it's fixed by your correction to use "+ 11" instead of "+ 12".

You should also consider refactoring the code to make it simpler and cleaner. For example, your "MENU1" function can be refactored to something like the following: function MENU1() gg.setRanges(gg.REGION_ANONYMOUS) gg.clearResults() gg.searchNumber(':","answer":"', gg.TYPE_BYTE) local count = gg.getResultsCount() local results = gg.getResults(count) local answers = {} for i = 1, count, 12 do local address = results[i].address + 12 local maxLength = 1024 local answer = readBytesToString(address, maxLength) answer = answer:match('[^"]*') -- match part up to first quote character table.insert(answers, answer) end for number, answer in ipairs(answers) do print(string.format("Answer #%d:", number), answer) end gg.alert("Answer See [ON]") end Let me know, if the code above works for you.

To output a string Lua implementation in GG treats it as UTF-8 (by themselves Lua strings are just byte arrays), so reading bytes from memory to Lua string and passing the string to a function that outputs it ("print", "gg.alert", "gg.toast", etc) should be enough to achieve desired result in your case. Here is an example of function for reading bytes from memory and constructing string from them: function readBytesToString(address, length) local values = {} for i = 0, length - 1 do values[i] = {address = address + i, flags = gg.TYPE_BYTE} end values = gg.getValues(values) local bytes = {} for i, v in ipairs(values) do bytes[i] = v.value & 0xFF end return string.char(table.unpack(bytes)) end Call it with address to read from as first argument and amount of bytes to read as second argument, for example: local startAddress = 0x12340000 local bytesToRead = 20 local result = readBytesToString(startAddress, bytesToRead) print(result)

Relevant explanation from StackOverflow answer: https://stackoverflow.com/a/6389082

It's because of fundamentals of how Lua is implemented. The implementations (official one and LuaJ) are single-threaded, therefore only one operation can be performed at a time. Nothing can be done about it without changing the implementation.

How does that achieve the goal though? Original "searchNumber" function needs to be called anyway to actually perform the search. When it's called, it will only return after the search is finished (successfully or by cancellation). So how would a coroutine do anything when Lua executes native (i.e. not Lua one) function?

Can you explain how would coroutines make that possible? How would you pass execution to a coroutine after calling "searchNumber", when it is doing it's job? Coroutines don't make it possible to execute code in parallel.

"Aarch64 = arm64" statement is correct. AArch64 is the name of 64-bit ARM architecture. Both names refer to the same thing.

To add to discussion of this suggestion: Lua strings by themselves are encoding-agnostic, so desired conversion is actually from bytes that represent string in one encoding to bytes that represent the same string in other encoding (utf-8 in this case, it seems). Input and output bytes of a hypothetical API function for such conversion can be in the form of strings or tables with values of bytes, but strings seem to be more reasonable option, because internally they are represented as array of bytes (as opposed to table with 8-byte integers). It's also worth to mention that GG API already has bytes function that converts bytes from utf-8 encoding to specified one, so it may be not a bad idea to extend the function by adding new parameter for source encoding (how to interpret string that is passed to the function) instead of creating a new function. As for what can be done currently, without such function: Since there is "utf8" library with functionality to construct a string from list of character codepoints, to be able to convert bytes from, for example, UTF-16LE encoding to UTF-8, it is enough to implement parsing of bytes that represent string in UTF-16LE encoding to list of character codepoints. The list then just need to be passed to "utf8.char" function and it will return desired string in UTF-8 encoding.

This understanding is based on fundamental misconception that GG automatically updates anything in tables that have been returned with "getResults", "getValues" or other GG API functions. GG not only doesn't do that, but also wouldn't be able to do that without significant performance impact (just imagine having to read values from process memory for all elements of all tables that have been returned by GG API functions every N milliseconds). So changes in process memory "automatically" don't affect anything in script anyhow. To get updated data from process memory, corresponding GG API function ("getValues") needs to be called, but even it doesn't change anything in table that is passed to it as argument, instead it returns new table that has new values in "value" field of it's sub-tables.

There is one other detail regarding the comparison to "0" (string). Behavior of comparison operators for this case is described in the manual as follows: For our case it means that the following condition _x[i].value ~= '0' will always evaluate to "true", because "value" field has value of number type. Correspondingly, correct comparison to check for value being not equal to zero is: _x[i].value ~= 0

This code is equivalent to your previous version. You don't make a copy of tables with this line: local xValue, yValue = x, y Instead you create new variables that refer to the same tables, so it doesn't make any difference. Lua reference manual explains this pretty clearly:

No, that's because all values of the table are explicitly set to value of first element when the following code is executed: for i = 1, #x do x[i].value = x[1].value end If, for example, "x" has 3 elements, the loop is then equivalent to: x[1].value = x[1].value -- value of first element is set to itself x[2].value = x[1].value -- value of second element is set to value of first element x[3].value = x[1].value -- value of third element is set to value of first element And then, when next loop is executed: for i = 1, #x do x[i].value = x[2].value end "x[2].value" no longer has it's original value, because new value (of "x[1].value") has been assigned to it during execution of previous loop. This is why only first loop works as intended and all subsequent ones don't. And this is why copy of values needs to be created before the first loop (to have access to original values after table values have been overwritten).

The issue is in the code that needs to be repeated. When the code is executed for the first time, "value" fields of all sub-tables of the table ("x", for example) are set to "x[1].value", so that when the code is repeated and should set all values to second value, "x[2].value" is already modified to the value of "x[1].value", that's why each time the code is repeated, it sets all values to first value. To actually set all values of a table to value of different table element each time, make sure that there is a copy of values that doesn't get modified and in the code that gets repeated just use values from the copy to set "value" field of sub-tables. To make copy of values, construct a table in which indexes from original table (1, 2, 3, ...) are mapped to values of "value" field of corresponding sub-tables of the original table (x[1].value, x[2].value, x[3].value, ...), for example, like this: local xValues = {} for i, v in ipairs(x) do xValues[i] = v.value end Then use values of constructed table in inner loop of the code that gets repeated (slightly modified version of the loop from @TisNquyen's post above): for loop = 1, #x do for i = 1, #x do x[i].value = xValues[loop] y[i].value = yValues[loop] end gg.setValues(x) gg.setValues(y) gg.sleep(500) end

For GG you should only use optimized versions of virtual space applications from this forum. Parallel Space: Parallel Space + 32-Bit Support + 64-Bit Support (#rjx0v91) Parallel Space Pro: Parallel Space Pro + 32-Bit Support + 64-Bit Support (#4doyid1r)

Current capabilities of GG are more than enough to find values that meet this condition. There are 2 main approaches for this case: - ordered group search with "placeholder" values; - searching for target value and checking whether found results meet the condition(s) (like whether value at offset X is equal to Y). So the task is to find all float values equal to 15.0 for which float value at offset -16 (-0x10) is equal to 2.0. With the first approach the code may be next: gg.clearResults() gg.searchNumber("2.0F;0D~~0D;0D~~0D;0~~0D;15.0F::17") gg.refineNumber("15.0", gg.TYPE_FLOAT) And the second approach can be implemented, for example, like this: gg.clearResults() gg.searchNumber("15.0", gg.TYPE_FLOAT) local results = gg.getResults(gg.getResultsCount()) local checkValues = {} for i, v in ipairs(results) do checkValues[i] = {address = v.address - 0x10, flags = gg.TYPE_FLOAT} end checkValues = gg.getValues(checkValues) for i, v in ipairs(checkValues) do if v.value ~= 2.0 then -- exact comparison of float values should be avoided in general, but for particular case of value "2.0" it will work results[i] = nil end end gg.loadResults(results)

I haven't found any records that would help with understanding the problem (what and why happens) in the log, so there may be 2 main possibilities: either they are present in the log but haven't been noticed or recognized as being related to the problem or log doesn't contain them. However, it seems worth to note that around 2 minutes and 17 seconds have passed between the moment when process has been selected in GG: 12-22 13:05:18.975 14480 14480 E AndroidService: used: ProcessInfo [cmdline=com.fungames.sniper3d, name=Sniper 3D, packageName=com.fungames.sniper3d, icon=android.graphics.drawable.BitmapDrawable@8ef34cd, pid=10179, uid=10275, isSystem=false, isGame=true, weight=0, main=true, order=0, x64=false, rss=359392, getTracer()=0, getTrace()=-1] and the last record in the log: 12-22 13:07:35.649 20370 20370 I SoundAlivePolicyManager: isGlobalEffectSupportCurrentAudioPath, currentDeviceType : 2 This doesn't quite correspond to your description of steps that you do to reproduce the problem. Was process selection really the last action that you performed in GG that caused device to become unresponsive and to reboot after ~10 seconds? One thing that would greatly help with analyzing recorded logcat is to specify when certain actions have been performed. For example: 11:04:32 - "Start" button in GG's start screen was pressed 11:04:38 - Process selection dialog was opened 11:04:41 - Target process was selected 11:04:55 - Device automatically initiated it's restart Time moments don't have to be exact, since it's not easy to precisely check when something is done, but even if it's +- 5 seconds, that's still significantly better than having no such information at all. For example, to illustrate, the log you provided is ~27 MB, but only ~2 MB from it is most likely to contain any information of interest, since other records are from before the moment of time when you initiated recording logcat in GG. And with information about when actions relevant to the problem have been performed, only, for example, ~200 kB of log records are most likely to contain any information of interest.

Whatever compression method was used, it is not supported by 7-Zip, so the file can't be decompressed. Which software did you use to create the archive?

I meant to attempt to check folder contents with file chooser, but there is no need anymore, since the situation supposedly became clear enough. GG doesn't use root to access file, path to which is provided by user in input field of "Execute script" dialog (nor does it for file chooser functionality in general). In most cases it works fine: just place script file(s) that needs to be executed in a folder that can be accessed without root and it will work. However, if target file is located in folders that require root to be accessed, GG may not be able to access it. In Android 11, as part of it's privacy-oriented changes, applications have been restricted from accessing other applications' data on external storage, i.e. contents of "/Android/data" and "/Android/obb" folders (source). So when GG runs on device with Android 11, it doesn't have access to those folders (with exception of it's own folder in "/Android/data"). For GG to be able to access files without restrictions, it most likely needs to delegate this functionality to it's daemon that runs with root, but there are security concerns related with such solution, so there need to be solid reasons to implement it. Actual question that needs to be asked in current case is why you need to be able to access contents of "/Android/data" with GG. For most use cases there should be alternatives that don't require accessing restricted folders, so it's not unlikely that there is an alternative for your case as well.

@CheatTester record logcat from attempt to access "/storage/emulated/0/Android/data" folder with GG's file chooser.

Better to just use gg.EXT_STORAGE.

Let's not forget what scripts for GG are. They are automation of methods for certain modifications in games via process memory editing. Authorship of scripts essentially boils down to authorship of methods implemented in them, since value of scripts lies exactly in them. If methods are public, particular scripts that implement them in most cases aren't important, because methods can be applied manually and/or can be implemented in other scripts. So for authorship of scripts to be relevant, methods need to be not public, but this leads to contradiction: public release of scripts for GG fundamentally can't co-exist with keeping implemented methods private. Therefore, authorship of scripts for GG the way you want it to be can't exist. However, it can (and does) exist the same way as authorship of methods for using GG to achieve certain result in certain game that get published at this forum or anywhere else. It doesn't matter whether methods are published in form of text, video or script, their authors most often get the popularity they deserve (even though some of them don't even care about it). But popularity/recognition by themselves is a wrong goal, instead one should strive to become better at activities of one's interest.

Thanks for the details. With them it appeared to be quite easy to find the answer. The value is tagged pointer that actually points to valid address in process address space. Top byte in tagged pointers is "implementation defined tag" that needs to be ignored to get the real address that pointer holds. More information about tagged pointers is present in Android documentation: https://source.android.com/devices/tech/debug/tagged-pointers So when you encounter such pointers, discard the top byte of their hex value (or replace it with "00") when navigating to the address to get to the correct address.

I don't have any explanation for described behavior, but it may help, if you provide details regarding finding the value in problematic region. Which game/application is that? What is the algorithm to find any value from problematic region?

My guess is that the values are actually from this region: 6e36d4b000-6e36dcb000 rw-p 00000000 00:00 0 [anon:scudo:primary] but for some reason the address in GG starts with "B40000" instead of "000000". You should be able to check this assumption by navigating to presumably correct address (that starts with zeros) in GG's memory viewer.