nok1a

Also like it's not ok if your doing pointer search in 3 regions. The pointer you need should only exist in one region. To be fair for what i understand accuracy is important. And putting multiple regions is just being lazy. Even using gg.searchPointer(0) is lazy i find. You don't want to deal with all the results you had so you use gg.searchPointer(0). But of course there are cases in which you have no other choice.

Because i was not sure in which regions your values would be. I knew mine. Perhaps for you could be different. So i specified all possible regions.

Probably because there was more then 1 result with a matching 1.0 float value to filter on. And that probably happened because of having no accurate memory ranges. I can't be 100% sure because i haven't encountered the issue yet. Yes, your pointer was in region anonymous. So if you know that only specify the pointer search to be in region anonymous. Do that before the results are loaded in the result list.

https://support.google.com/googleplay/thread/204717992/my-play-store-is-showing-pending-problem-if-i-start-downloading-any-app-what-should-i-do-in-oppo?hl=en

Just download the file. The link is a link to this post so it's not important

I could. To be honest i have no idea about your understanding of GG Lua scripting. But you should learn it. You would get basics quickly for write a GG script and it's user friendly. Can you send the script you currently have.

You typed some character near the brackets that's not supposed to be there or the device saved the file wrong. Happened to me sometimes and then i get that error.

Oke i understand, so the problem here is the scripting. I can't explain scripting that well compared to other members in the forum. But you should start by running the print() function to print out your tables and have some understanding of what the script is doing. Use --[[ ]] to ignore most of your code and let GG does it thing line by line. Start with doing the group search, then refine and then store the results in a new table named "t" and print it out...something like this. gg.searchNumber("-1,049,624,576A;1,092,616,192A;1,082,130,432A;1,056,964,608A;1,062,333,317A::73", gg.TYPE_DWORD) gg.refineNumber("-1,049,624,576A", gg.TYPE_DWORD) local t = gg.getResults(10) print(t) Then analyze what GG respond. Make sure GG ignores the rest of the code by placing it as a comment: Also check in the GG scripting documentation what it is that you writted

I am not sure if this makes sense?

It wasn't in the script because i was already at the right address to perform the pointer search on to get to health value. Your at a different pointer then mine using your group search. The table t contains those 4 results you had from performing a pointer search on that one address you had from your group search. You already addedan offset of 0x8 to all those addresses to get to the address that is supposed to hold the value 256 and you stored the new addresses in the table (sensitivity). use print(sensitivity) for see what's in the table. Only problem is that your doing it for all the 4 addresses in the result list while you only have to do it for the one address in region Anonymous. That's why specify the regions as accurate as possible in which you want find the pointers in in or it will already bring issues. The way you added 0x8 to do the addresses you now do the same for the table t in a loop. healthPointer[i] = {address = t[i].address, flags = gg.TYPE_DWORD} add the offset from your start address to the address on which you want to perform the pointer search on to get the health value.

You as well need to add the offset from your start address to the address that you want to perform apointer search on, the one below the 1.0 float value. Then all you have to do is add the last part of the code which was to load the table in the result list and perform a pointer search and do +0x4

Your telling GG to store the value at offset at 0x8 in data type float. This means that if sensitivity[i].value == 256 then is same as this: if 3.5873240686715317E-43 == 256 then This will return false. Change the type to dword. You should use print the print function to check out what are in those tables. For example print(sensitivity) It will print your table and then you have a bit of insight of what is happening.

Yeah when using searchPointer() you have to specify the regions before you load the results in the result list. The regions at the first line should be the region where you try finding your group search, but i am not sure if your group search is always in the same region. Then when pointer searching you have to only specify the region where the pointer is which i think was region Ca or A.

Your offset is + 0x8 of the pointer, not - 0x8. Also i not know if you saw but the memory region in which your value 256 was located was in region anonymous. So make your pointer searching more accurate by specifying the correct regions when needed...if you where sharing the scripts with multiple people i can understand you use multiple regions. But in this case it's for personal use i guess? See here the regions you can use. When comparing two values they must be of same type as mentioned. You comparing a number type and a string type here. If all the values are in dword no need to use "A" in front of each number. It slowers the search. It's better use the correct data type for each value or just remove the data type of each value and give them all same data type using gg.TYPE_DWORD. You will prevent issues by doing so. As mentioned here. The choice is up to you.

That's right. I also didn't knew about pointers first. Actually this whole GG pointer thing didn't make sense because i didn't knew what where hex, bytes and bits...should have stayed in school longer to get some basics...So i totally get you...it's a pain to come in without knowledge about all this...Was watching some YT tutorials about how or what are bits and bytes and it helped me. Then after some time i understand addresses in memory a little and then pointer concept from a GG point of view made more sense. But also importantly the members in this forum contribute to making it more easy for people like us to understand something which is most likely alien language for us. There is lot's of things to learn i guess. We can use GG and the forum and other sources to learn more.

Yeah you should. Are you sure you did it correctelly though. I performed pointer search more then once...so you have to use go to the pointer more then onces as well in order to get to the groups search.

Your script can not be same because your using different group search, and where you found your group search the structure is different. You only have to do one time a pointer search and your not using any values to filter out irrelevant results. You can remove most of the lines from it, here some example based on your group search and pointer you when't to. gg.setRanges(gg.REGION_ANONYMOUS | gg.REGION_C_BSS | gg.REGION_C_ALLOC) gg.searchNumber("17D;1,075,642,368D;1,900,544D;1,310,728D;589,828D;1,703,957D;1,703,969D;1,376,289D;1,920D;469,762,048D::185", gg.TYPE_DWORD) gg.refineNumber("1,900,544", gg.TYPE_DWORD) print("Group search: ", gg.getResultsCount()) local grp = gg.getResults(gg.getResultsCount()) for i, v in ipairs(grp) do v.address = v.address - 0x4 v.flags = gg.TYPE_DWORD end gg.loadResults(grp) gg.searchPointer(0) local t = gg.getResults(gg.getResultsCount()) for i, v in ipairs(t) do v.address = v.address - 0xC v.flags = gg.TYPE_FLOAT end gg.loadResults(t)

True, but before you can do that 0xC with a script you must first get there through pointer searches. There are some other issues with the script that need to be explained i think. When your doing a pointer search with GG all your doing is searching a value that represent an address in memory. Let's go from the start. You have your health value at address 0x022023EC and you have a pointer 12 bytes away from it, it's at address 0x022023F8 Address 0x022023F8 has the value 8B7D02E0h 8B7D02E0h is a called a pointer because the value represents an address in memory. When you press "go to pointer" it means that GG will bring you to the address 0x8B7D02E0h. I now whent to the pointer, as you can see the highlighted address is 0x8B7D02E0 and under it you have your refined value from the group search 0x8B7D02E4 And that is also the location where you came up with your group search. When you did your group search and refined you had a lot of results left but let's say that you only had one address in the result list that has the value 1,900,544 and it's the correct one it would be looking like this: The value you refined is located at address 0x8B7D02E4 We now need to work backwards to get to or health value and perform a pointer search on the pointer we just whent to. The pointer that we just whent to was 0x8B7D02E0, so it's 4 addresses above the address that holds the value you just refined to, which is address 0x8B7D02E4. So first you have to tell the script to subtract the current address 0x8B7D02E4 - 0x4 and then load it in the result list. That's what local grp = gg.getResults(gg.getResultsCount()) for i, v in ipairs(grp) do v.address = v.address - 0x4 v.flags = gg.TYPE_DWORD end was doing, instead for 1 address in the result list it was doing it for all the addresses in the result list. After it subtracted 0x4 from the address 0x8B7D02E4, so your address became 0x8B7D02E0 (it's the same address you whent to using "go to pointer"), and then you used gg.loadResults(grp) to load the new address in the result list. So now result list will look like this: Now you will ask GG to perform a pointer search on that address(0x8B7D02E0), with that i mean that your telling GG to search in memory for addresses that hold the value 8B7D02E0h And of all the address in memory, which address you know for sure holded the value 8B7D02E0h ? Right, address 0x022023F8 holded the value 8B7D02E0h. The same address of where the address that holds your health value was located 12 bytes above it. So by using gg.searchPointer(0) Your telling GG for search the value 8B7D02E0h in memory. You get perhaps a few results. Now you get a few results but between all those the results the right address is in there 0x022023F8h: You know that 12 bytes above the address the address of your health is located (0x022023EC) so you don't have any reason to perform the searchPointer(0) again because your already at the address you started from. Now you need to tell GG to subtract 12 bytes(0xC) from the address 0x022023F8h and get the value at that new address. Since you have more then one result use a loop. local t = gg.getResults(gg.getResultsCount()) for i, v in ipairs(t) do v.address = v.address - 0xC v.flags = gg.TYPE_FLOAT end gg.loadResults(t) Get the results in a table t, and subtract all the addresses with - 0xC and set the flags as float. Then when you load the table t using gg.loadResults(t) it will load the new address in the result list type float. You gone have multiple addresses loaded because there are many addresses that go to the pointer you whent to, so they all hold the same value (8B7D02E0h) In GG it would look like this if you had a more accurate group search around that address your performing a pointer search on: Since the group search is not that accurate which causes you have to more then 100 results when refining to your value 1,900,544 and you performing pointer search on each of those 100+ addresses that where loaded in the result list you probably gone get something like this, possible they are all health values for different objects but the health value of your character is of course in there at address 0x022023EC: I am not sure if all makes sense?

Why are you doing 0x0C ? Your value 1,900,544 is not 12 bytes away from the pointer you just whent to, it's 4 bytes away. If you enable byte view in the memory viewer you can see every address in memory: Or you can select both addresses and use the offset calculation to see distance from start address to destination address.

Here there was a mistake from my side but @CmP has warned me for that. When comparing 2 values they must be of same type. I tried editing it in my previous posts: but it seems you still uses the script i sended, my fault. Comparison of 2 different types in Lua will cause issues. Correct it to: if sensitivity[i].value == 1.0 then

Make sure that when you do a group search you specify it's data type. When you put Auto in front of it GG will look for all possible data types for that specific value and then needs to match it also with the other values to see if the group search can be found. You could have results you don't need. For example do this: gg.searchNumber("17D;1,075,642,368D;1,900,544D;1,310,728D;589,828D;1,703,957D;1,703,969D;1,376,289D;1,920D;469,762,048D::185", gg.TYPE_DWORD) Or you can ignore the data types next to the value and only use gg.TYPE_DWORD If your only searching 1 value you don't put a data type for that specific value aside from adding the gg.TYPE_DWORD as any normal search.

gg.loadResults({{address = grp[1].address - 0xc, flags = gg.TYPE_DWORD}}) gg.searchPointer(0) print("First Pointer search: ", gg.getResultsCount()) You also will need to change this gg.loadresults() since it only subs 0xC to one address in the result list. But you want it to happen to all the addresses in the result list before you load their new addresses in the result list. So use loop. For example: for i, v in ipairs(grp) do v.address = v.address - 0xC v.flags = gg.TYPE_DWORD end gg.loadResults(grp) gg.searchPointer(0) print("First Pointer search: ", gg.getResultsCount()) gg.searchPointer(0) print("First Pointer search: ", gg.getResultsCount())

Perhaps use the code snippet option when adding code in your post for readability. The script only performs pointer search on 1 address. You have more then 50 results left after refining and probably the first result in the result list is not the right address...but sure the right address is in there . Although it's better to have your group search as accurate as possible to prevent any kind of issues later on. Use local grp = gg.getResults(gg.getResultsCount()) so that all results are selected. Then gg.searchPointer(0) will perform pointer search on all the addresses in the result list instead of 1.

Indeed, just make sure that your using hex and not decimal. 12 bytes = 0xC

LDPlayer Make sure you deleted any installed dead trigger 2 versions from the emulator using the uninstall option in the play store. Sign in to the play store with your google account. Then create new folder in 0/android/obb/ name folder: com.madfingergames.deadtrigger2 and then store the .obb file (main.15020074.com.madfingergames.deadtrigger2.obb) from the modded apk in it. Should resolve the issue.