CmP

Since you have already created separate topic for your question, provide the details there. Include region log, address of the value and the value itself.

Lua also allows to implement custom iterators to be used with generic "for", so one can implement traversal from 0 that way and use it like ipairs/pairs functions: -- Modified function from http://lua-users.org/wiki/IteratorsTutorial function ipairs0(t) local function iterator(t, i) i = i + 1 local v = t[i] if v ~= nil then return i, v else return nil end end return iterator, t, -1 end -- Usage example for i, v in ipairs0(t) do print(string.format("[%d] = %s", i, v)) end

It's not more complicated than to print table elements starting from key 1. Looks more like the question is about how to print table elements at all. In the most basic case to print elements with integer keys starting from 0 and without printing contents of any nested tables it's enough to have one loop: local t = {[0] = 0, 1, 2, 3} print("{") local index = 0 local element = nil while true do element = t[index] if element == nil then break end local representation = string.format(" [%d] = %s", index, element) -- implement custom type-dependent converion of value to string if needed, this one uses default conversion, i.e. string "1" and number 1 will result in the same output print(representation) index = index + 1 end print("}")

For readability of the code or the output with table representation? If for the latter, one can simply create custom function to print table contents. There are no regular arrays in Lua, only tables that are associative arrays and can be used to implement many different data structures. Tables in Lua don't have starting element by themselves, but length operator and functions from "table" library operate only on part of table with consecutive integer keys starting from 1. Your interpretation is wrong, because tables don't have defined order of traversal, it's implementation-specific. In fact official Lua doesn't include table contents in it's default procedure to convert table to string. So instead of relying on default table to string conversion in GG implementation of Lua, implement custom function that will perform conversion the way you need.

Note that metatable-based solution suggested above doesn't work as expected in all cases when key used in indexing access or indexing assignment exists in table, because "__index" and "__newindex" events are used only when key is not present in table. Though, XEKEX is right that it's not a good practice to have 0-based arrays in Lua. What is your use case for that and why 1-based arrays don't suffice?

Because string concatenation produces new string and there are multiple usages of it in the code. Mostly yes, but format strings don't need to be passed as parameters in this case and instead of separate call to format address, do it in the same one.

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

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

Just presence of two base64url-encoded parts separated by dot is not enough to conclude that string is JSON Web Token. In fact, your string isn't valid JWT as per step 4 of "Validating a JWT" section of RFC 7519 (https://www.rfc-editor.org/rfc/rfc7519#section-7.2).

And loading saved list with option to set values can't really be faster than setting values directly by definition, since loading list in this case includes setting values. Also what makes loading saved list significantly slower than directly setting values is not setting values part, it's everything that needs to be done before that: reading and parsing saved list file, populating saved list with items.

Then I can do it for you, since it turns out that you are not only wrong about performance of loading saved list and setting values, but are terribly wrong. Code that has been used for test: local savedListFilePath = "/mnt/windows/BstSharedFolder/com.cxinventor.file.explorer.txt" gg.clearList() local clockStart = os.clock() gg.loadList(savedListFilePath, gg.LOAD_VALUES) local loadListTime = os.clock() - clockStart local values = gg.getListItems() clockStart = os.clock() gg.setValues(values) local setValuesTime = os.clock() - clockStart print("gg.loadList time: " .. string.format("%.3f", loadListTime)) print("gg.setValues time: " .. string.format("%.3f", setValuesTime)) Saved list file that has been used for test: com.cxinventor.file.explorer.txt Result of the test: Interpretation of result: Loading list of 8192 4-byte values with option to set values with "loadList" API function took around 100x more time than setting the same values with "setValues" API function. So it's not a question of which method works faster. The question that remains is why did you, @zolotov_official0, post nonsense results instead of doing proper test.

Do you even understand yourself these "results"? They are beyond nonsense. Loading list with 100000 values took less than a millisecond? Setting 100000 values took 5699 seconds? At least include the code that has been used for "testing".

Only because it's a suitable name for the variable, could have been any other suitable name with the same success. As for the reason of having the variable, it's a small optimization to not have to get the same value from table two times.

Is this opinion based on facts or your subjective preferences? Almost all claims don't correspond to reality. 1. "ancient methods of patching". Restoring saved list has been there before scripts, so it's clearly the other way around. 2. "loadlists are faster". Based on what? Where are the results of performance tests? What's obvious without tests is that both methods are "instant" for editing hundreds or even few thousands values. 3. "loadlists are easier to update". Nothing prevents one from writing script in a way to be as easy updatable as possible, for example, with configuration table. And format of saved lists is far from being comfortable to work with manually. 4. "loadlists take less code". They do, at cost of losing all flexibility. How to restore only some of patched values with saved lists? To keep saved list for each desired state of values? What if there are tens of such states? And for some reason one of the most obvious disadvantages of saved lists isn't mentioned. It is required to (at least temporary) have a file for each one. So instead of directly patching values you suggest to create a file with saved list data and load it only to accomplish the same. If that isn't highly redundant approach, then I don't know what is.