Leaderboard

well done my good man, i already put the code here to my full script, it works and very efficient, can reduce more text length in my script , i hope to see you again

hello, im still new at scripting, i tried something and it works but i need simplifier scripting, heres some part of my code local posX = gg.getListItems() local posY = gg.getListItems() local posZ = gg.getListItems() for i, v in ipairs(posX) do if v.name == 'posX' and v.flags == gg.TYPE_FLOAT then v.value = 100 end end for i, v in ipairs(posZ) do if v.name == 'posZ' and v.flags == gg.TYPE_FLOAT then v.value = 1 end end for i, v in ipairs(posY) do if v.name == 'posY' and v.flags == gg.TYPE_FLOAT then v.value = 50 end end gg.setValues(posX) gg.setValues(posZ) gg.setValues(posY) gg.addListItems(posX) gg.addListItems(posZ) gg.addListItems(posY) local searchResults = gg.getResults(10, nil, nil, nil, 1, 100, gg.TYPE_FLOAT) if searchResults.name == "posX" then for i, v in ipairs(searchResults) do searchResults[i].freeze = true searchResults[i].name = 'posX' end end if searchResults.name == "posY" then for i, v in ipairs(searchResults) do searchResults[i].freeze = true searchResults[i].name = 'posY' end end if searchResults.name == "posZ" then for i, v in ipairs(searchResults) do searchResults[i].freeze = true searchResults[i].name = 'posZ' end end gg.addListItems(searchResults) gg.clearResults() do i need an arraylist / tablelist and pointer ? for my 3 float value 100;1;50 because i need to input all values more than hundreds, if i still using script code above, it will very long writing

ah so it can be like that, what about if i need to edit them again with different value at the same time the first, 3 values was 100;50;1 and the second, 3 values are 200;150;1 then the 3rd, 3 values 300;200;1 do i need to make an array? local array1 = {100;50;1} local array2 = {200;150;1} local array3 = {300;200;1}

If this happens on emulator with binary translation (Bluestacks, LDPlayer, MEmu, etc) and instructions that are modified have been executed a bunch of times before modification, then this is expected. It's not a bug in GG, it writes memory successfully, behavior will be same regardless of which external tool is used to write memory (as long as method is same, see PTRACE_POKEDATA in ptrace man page). Possible workaround is to apply modification early on, before target instructions have been executed.