CmP

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.

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.

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

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.

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"

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.

This is correct approach, use range search, but make the range smaller. For example, for 1.2 search for "1.199999999~1.200000001".

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.

Try setting new ranges before the call to "loadResults" function.

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).

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.

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

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

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