Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


CmP last won the day on January 16

CmP had the most liked content!

Recent Profile Visitors

20,506 profile views

CmP's Achievements


Proficient (10/14)

  • Problem Solver Rare
  • Posting Machine Rare
  • One Year In
  • One Month Later
  • Week One Done

Recent Badges




Community Answers

  1. This is misunderstanding from my side. Table-only solution isn't an option for this case, because of requirement to have structure number in name. So solutions can be only function-based (table may be used in the function, but there is no gain from it in this case), but there is indeed some room for performance improvement in my example above - by avoiding string concatenation and using "string.format" instead.
  2. Feel free to do that. And there is no need for any credits in this case, but you can do however you prefer. No, it shouldn't, but if you have millions of iterations, then the difference between function and lookup table might become noticeable, in which case it may make sense to go with lookup table. Yes, looks correct.
  3. It looks like you need not a table, but function that returns name for value according to two parameters: structure offset and structure count. Here is an example of such function: function getNameForValue(structOffset, structCount) local name = "Structure (" .. structCount .. ")" if structOffset == 1 then name = name .. " :Unknown: " elseif structOffset == 2 then name = name .. " :Field offset: " elseif structOffset == 3 then name = name .. " :Field amount: " end return name end
  4. What's the point of "auto-destruction" of the file that is executed, if it can be simply backed up before executing it? There are no ways (without using server) to prevent script from being executed more than one time that couldn't be easily bypassed, but if you still need to have that for some reason, basic approach is to check presence of certain file and only continue execution if the file is not present and to create that file right after the check has been passed.
  5. Sorry, the answers to the questions above are present in your video. In your locale comma is decimal separator and for your values the search range that I suggested above is too narrow. Try the following search string: "1,19999~1,20001"
  6. Could it be that you use incorrect decimal separator with respect to locale that you have selected in GG? There can be 2 options of the decimal separator: dot (.) and comma (,) . Try with dot first, then with comma.
  7. This is correct approach, use range search, but make the range smaller. For example, for 1.2 search for "1.199999999~1.200000001".
  8. Only because it has been implemented like that. This is something that could be improved/fixed from GG side, pointer search needs to use search ranges that are set when pointer search is invoked instead of ranges that are set when results list is populated first time after being cleared (loading results works by clearing results list and then adding new ones). In other words, pointer search needs to work like new search, but currently it works like refine search.
  9. Try setting new ranges before the call to "loadResults" function.
  10. CmP


    This is limitation of particular variant of LDR instruction, it doesn't mean that it's not possible anyhow. But to be able to provide you reasonable answer, one needs to know what you want to achieve, why do you need to use LDR in the first place. So provide the following information (preferably in new topic): - what you are working with (function(s) name, description and instructions that it contains); - which modification you want to implement (for example, make the function return fixed value).
  11. CmP


    Either with 3 instructions as @XEKEX has described in his post or with 1 instruction and 4 bytes for address that need to be not far from the instruction as I have mentioned in this post.
  12. CmP


    There are 12 bits in the instruction that are used for encoding offset from PC in bytes, so the limit is from -4095 to 4095. Reference: https://developer.arm.com/documentation/ddi0406/cb/Application-Level-Architecture/Instruction-Details/Alphabetical-list-of-instructions/LDR--literal-?lang=en
  13. CmP


    As other have mentioned above, such case requires more than one instruction. At least 8 bytes are required: 4 for LDR instruction and 4 for your new address that needs to be placed somewhere not far from LDR instruction. For example: Address | Instruction/Value 12345678 | LDR R0, [PC, #-4] 1234567C | 0xAFFDACA4
  14. CmP


    It can't be used, because it is a pseudo-instruction that requires more space than single instruction. Description and examples of LDR pseudo-instruction are present in ARM documentation: https://developer.arm.com/documentation/dui0802/b/A32-and-T32-Instructions/LDR-pseudo-instruction
  15. GG was unable to get information about selected process, that's why nil is returned by "getTargetInfo" function. The following isn't a proper fix of the issue, but it may allow you to try the script. Insert the following code after second line of script's code: if info == nil then info = {packageName = "unknown", x64 = false} end This will cause the script to work as if process has been identified as 32-bit. To force identification as 64-bit, correspondingly, "x64 = true" should be used.
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.