HorridModz

Fricking magic what the hell. Can you explain where that came from? Did you download the game yourself?

@Xwl522How did you get this value? Depending on how it was obtained, it may actually be a different data type and that is just the first byte. Try editing the value as dword instead of byte (click the value, hit goto address, then hit it again and select edit - this type it should ask you which data type you want to edit it as). However, if that byte does reflect the value in the game and editing is as dword doesn't work, then it is indeed of byte type. If this is the case, then you simply cannot exceed 255. Just like you can't edit a dword value past the integer limit. Instead of asking how, you should be asking why. If a value is of byte type, that means the game will never need it to be greater than 255. So why do you need it to be? For example, currency will never be stored as byte (unless that type of currency happens to be extremely rare, and in that case, editing it to 255 should be more than enough of it). So if it is of byte type, then no, you can't make the value greater than 255 - but you shouldn't need to.

What the heck YOU'RE BACK? You were gone for two years! Did you Discord get hacked or something?

@EnybyHello, I am reporting a behavior that appears to be a bug in gameguardian. It seems that the "Copy as group search", when used with "UTF-8" and "UTF-16", assumes that the values are consecutive, i.e. one byte apart. However, this is not always the case, causing group searches to sometimes fail. This is best illustrated by examples: Let's search the string "abc" in UTF-8 and save the first 3 results, but leave out the second one: gg.clearResults() gg.setRanges(gg.REGION_ANONYMOUS) gg.searchNumber(":abc", gg.TYPE_BYTE) gg.addListItems(gg.getResults(1)) -- first result - "a" gg.addListItems(gg.getResults(1, 2)) --third result - "c" Now, we have two results: 97 byte, representing the character "a", and 99, representing the character "c". These results are a byte apart - so they do not directly form the string "ac" and would not be searchable as ":ac"; rather, they would be searchable by a group search that accounts for the byte in between: 97B;0~~0B;99B::3. However, the Copy as Group Search function, when I select UTF-8, gives ":ac". This is not the right group search and seems to be a bug. In order to show why this is wrong, here is the situation where I discovered the bug. I had a script that writes a string to memory, like this: function Write_String(mystring) --[[ Allocate memory in Anonymous region and write string to allocated memory ]]-- address = gg.allocatePage(gg.PROT_READ | gg.PROT_WRITE, gg.REGION_ANONYMOUS) values = {} for i = 0, #mystring do values[#values + 1] = {address = address + i, value = ":" .. mystring:sub(i, i), flags = gg.TYPE_BYTE} end gg.loadResults(values) -- must load results before we can edit with setvalues gg.setValues(values) end Write_String("Here is my special string!") If I run this script, I get the string written in consecutive byte values. I use Copy as Group Search for UTF-8, and it gives me the correct search: ":Here is my special string!". But now let's revert what we just did by refreshing the game, change the address spacing to every 2 bytes, so the string is no longer consecutive, and copy it as a group search again: function Write_String(mystring) --[[ Allocate memory in Anonymous region and write string to allocated memory ]]-- address = gg.allocatePage(gg.PROT_READ | gg.PROT_WRITE, gg.REGION_ANONYMOUS) values = {} for i = 0, #mystring do values[#values + 1] = {address = address + i*2, value = ":" .. mystring:sub(i, i), flags = gg.TYPE_BYTE} end gg.loadResults(values) -- must load results before we can edit with setvalues gg.setValues(values) end Write_String("Here is my special string!") We copy it as group search again, and get the exact same thing: ":Here is my special string!". However, now that the addresses are 2 bytes apart, this is wrong and will not work. If we try to search it, nothing comes up. So, this is definitely not working right. I'm pretty sure that it's a bug. My suggestion for fixing this would simply be displaying an error message if the addresses were not consecutive, like this: "UTF-8 [or UTF-16] group search only works for consecutive addresses. Please use a different type of group search." If there's any other information anyone would like, feel free to ask.

I'm wondering if there's some way to do it by seeing the highest address in the game. Like if I can somehow find the base address of the game, then I do an address search for base address + 0x1AD27480 (450000000) - equivalent to 450 million, or 450 mb. Then if the search comes up with a result, game process size is at least 450 MB. Could that work?

Sorry, I no longer maintain that script. That sucks, looks like pixel gun 3d is detecting gameguardian. This is device-specific, it seems, and not an issue with my script. So I can't help you - sorry! Perhaps you can ask around and see if anyone else has managed to circumvent this detection.

Okay, that's what I figured. You're right about the block not being continuous; sorry. @CmPprovided actual code which solves that problem by trying to allocate continuously, but I have no idea how often that would work and the tendency of it to fail (I'm unaware of how the kernel decides where to allocate the memory). A solution to that might be to allocate the first block in an obscure region (maybe an unused memory region, like c++ heap, would work? This is a gray area for me, so I wouldn't really know.) where you are sure there's enough consecutive space. If I were you, I would first take CmP's code and play around with it, seeing if you encounter any issues.

Hi, I have a hex patch that must be run when the game's process size is before approximately 450 MB. After this point, the game has gotten to the point in its initialization where the function I am patching has already been called. So, if you patch it when the game's process size is over around 450 MB, it will not work. I'm trying to write a script to do this patch. I want the script to detect if the game's process size is below 450 MB, and if not, tell the user to restart the game. However, I couldn't find anything for this in gg.getTargetInfo() or any other functions. So, I'm stumped on how to do this. I've given up with gameguardian and, as a workaround I'm now just trying to locate some kind of value in memory or function in the game that can give me a hint on the process size or initialization progress. My best guess right now is to see how much the game has loaded by finding the function that reports the % loaded. Is there any way to do this natively in gameguardian? Or is there any easy workaround I can use? Thanks!

I don't believe that's directly possible, but you can allocate as many pages as you need and chain them together. To do this calculate how many pages you need by dividing by 4KB, and in a loop allocate a block and add the return address of the allocated block to a list. You can then combine all of your memory into a table of values by looping over the list and adding the 1000 values (taking the start address and adding 4 each time, 1000 times) to the table for each address. If you don't understand, I can code that for you - it's pretty simple to do. Though I wonder what you're writing to memory that takes so much space? An image or save code, or something?

Do you just mean multiplication? Or do you want to add the value N separate times, with a pause in between? For the latter, you could write a simple script, like this: N = 10 -- how many times add = 100 -- value to add on every time timebetween = 1000 -- how long to wait between times (milliseconds) values = gg.getResults(gg.getResultsCount()) for _ in N do for i in values do values[i].value = values[i].value + add end gg.sleep(timebetween) end