CmP

Possibly that the bytes are simply reversed. 0x64 is 100. Try "00 01" to see the result. 256 to be expected.

Incorrect search string for type "Dword". "searchNumber" function returns string in case of failure so it is possible to check whether function completed successfully: local ret = gg.searchNumber("1.000", gg.TYPE_DWORD) if type(ret) == "string" then print("Error: " .. ret) else print("Success") end

If there are results in results list, "searchNumber" function performs refine search. For new search don't forget to call "clearResults" function before calling "searchNumber" function. Second search happens instantly after the first one and only results from the first search are used to search in, that's why you get 0 results after both searches.

Demonstration of work.mp4

Then just use "value" field of one structure as "address" field of other structure. For example: local ptr = {{address = 0x11223348, flags = gg.TYPE_QWORD}} ptr = gg.getValues(ptr) -- Getting value of a pointer local val = {{address = ptr[1].value, flags = gg.TYPE_DWORD}} -- Using pointer value as address val = gg.getValues(val) print("Pointer at address " .. ptr[1].address .. " points to the value " .. val[1].value .. " at address " .. val[1].address)

@MonkeySAN you probably forgot to end the loop before calling "setValues" function. It doesn't need to be called in loop, just once after it instead.

Since "searchNumber" function expects a string as it's first argument, numeric value is converted to string before it is used to determine what to search for. Test code for your case from the video: local value = 0.1 for i = 1, 9 do print(value) value = value + 0.1 end Code execution result: The problem should be obvious now. The solution is to not rely on automatic number to string conversion unless you are sure that it's result will be equal to what you expect.

Just as @MonkeySAN mentioned, you don't need to guess whether anything was found and replaced. Instead it is enough to add logging to the code to find that out: loop = 0.1 for i = 0, 98 do print(string.format("Searching: %.15f", loop)) gg.searchNumber(loop, gg.TYPE_DOUBLE) local found = gg.getResultsCount() print(string.format("Found: %d", found)) gg.getResults(found) local edited = gg.editAll(500, gg.TYPE_DOUBLE) print(string.format("Edited: %d", edited)) gg.clearResults() loop = loop + 0.1 end This way you would see how many results were found and edited and it wouldn't be needed to guess anything.

Strangely enough, it seems that the instructions are still read from process memory after they have been executed once, but after some more executions of the instructions, they are indeed "cached" and are no longer read from memory. I figured that out from several observations, but I don't know how this mechanism of instructions "caching" really works in libhoudini or other translation solutions.

Firstly, since we are dealing with bitwise operations, it is reasonable to convert all values to hex: Anti-cheat 1 = 0x50D00B6E Anti-cheat 2 = 0x120B5C6E Real value = 0x428C0000 Now let's define new values that are derived from these "anti-cheat" values: Key1 = Anti-cheat 1 = 0x50D00B6E Key2 = Anti-cheat 2 with 2nd and 3rd bytes swapped = 0x125C0B6E Real value can then be calculated from previously defined values like this: Real value = Key1 XOR Key2 Real value = 0x50D00B6E XOR 0x125C0B6E = 0x428C0000 Following the same steps for this example: Anti-cheat 1 = 0x50015F1D Anti-cheat 2 = 0x135F511D Real value = 0x43500000 Key1 = 0x50015F1D Key2 = 0x13515F1D Real value = 0x50015F1D XOR 0x13515F1D = 0x43500000

Variable "lastIndex" indicates index of the last element of the table that will be edited, meaning that up to first 5 values will be edited. It can be less than 5 when saved list has less values, but it won't be more than 5. The approach is same, just little modification to the code is needed. For example, code of the second example from my previous post can be modified this way: local items = gg.getListItems() local count = #items local firstIndex = 3 local lastIndex = 7 if lastIndex > count then lastIndex = count end local newItems = {} for i = firstIndex, lastIndex do local item = items[i] newItems[#newItems + 1] = {address = item.address, flags = item.flags, value = "12345"} end gg.setValues(newItems)

There are multiple ways to achieve the same result. Either you can use table returned by "gg.getListItems" function and modify required fields before calling "gg.setValues" function with this table as argument or you can create a new table based on values from returned table, but with required fields having different values on your choice and then call "gg.setValues" function passing the newly created table to it as argument. Example of implementing the first way: local items = gg.getListItems() local count = #items local lastIndex = 5 if lastIndex > count then lastIndex = count end for i = 1, lastIndex do items[i].value = "12345" end for i = lastIndex + 1, count do items[i] = nil end gg.setValues(items) Example of implementing the second way: local items = gg.getListItems() local count = #items local lastIndex = 5 if lastIndex > count then lastIndex = count end local newItems = {} for i = 1, lastIndex do local item = items[i] newItems[i] = {address = item.address, flags = item.flags, value = "12345"} end gg.setValues(newItems)

But there is no need to load saved values as search results in the first place. The same can be accomplished without such redundancy using "gg.setValues" function: local items = gg.getListItems() for i, v in ipairs(items) do if v.flags == gg.TYPE_FLOAT then v.value = "0.10000000149" end end gg.setValues(items)

has which data type? If this is known of course. Can you get encrypted value (interpreted as dword) that corresponds to real value in game being 0?

Even if encrypted value is interpreted as float by the game, one still needs to know exact values to be able to analyze how values in the pairs you provided are related. That's why you were asked to provide the values interpreted as dword.

Alternatively to the solution above by ItsSC, the following function can be used to swap endianness of a string that represents 4-byte hex value: function swapEndianness(str) return (str:gsub('(..)(..)(..)(..)', '%4%3%2%1')) end

Check if the following solution suffices for your case: How to goto a pointer in a script? (#7hphwlq4)

In "offset" function: And right after the call to it: Instead of adding table of tables to "vPool" table, add just tables that contain info about a particular memory item. For example, in your code instead of addItem(vPool, r) do addItem(vPool, r[1])

To fix what? You forgot to describe the problem. From the screenshot you attached it is in no way obvious what the problem is. If you wonder why second and third elements of "vPool" table are references to the same table, that's because your code calls "addItem" function with the same arguments twice.

In case of modifying value by freezing it to a new value "addListItems" can be used, but in case of just changing value without freezing it "setValues" function is the one to use. Generally, you shouldn't use "addListItems" on values that you don't want to be added to saved list. Values that are needed to be frozen is exception, because in GG a value can't be frozen without it being added to saved list.

That's because you use "setValues" function. "addListItems" is the one you need to use to freeze a value.

You don't need a loop here. Extract the code from loop body and change all references to "v" to "vPool" and it might work as you expect.

The answer above from @SAGEPAPI is exactly what you wanted to know. 5th and 6th parameters of "searchNumber" function are used to set lower and upper bound of range of addresses to perform search in. This is written in the documentation to the function which can be found here. Don't hesitate to check the documentation when you have GG API-related questions.

Just check if table returned by "getListItems" function contains any elements. local t = gg.getListItems() if #t == 0 then print('Saved list is empty') else print('Saved list is not empty') end

This way the values won't be frozen. Need to call "addListItems" function after the loop that sets "freeze" field to "true".