CmP

local function createPhaseDisplayer(phaseValues, progressSymbol, backgroundSymbol) local phasesCount = #phaseValues local currentPhase = 0 return function () currentPhase = currentPhase + 1 if currentPhase > phasesCount then os.exit() end local indicatorFirstPart = string.rep(progressSymbol, currentPhase) local indicatorSecondPart = string.rep(backgroundSymbol, phasesCount - currentPhase) local indicator = indicatorFirstPart .. indicatorSecondPart local phaseValue = phaseValues[currentPhase] local displayMessage = string.format("phase %d\nSymbol : %s\n%d", currentPhase, indicator, phaseValue) gg.toast(displayMessage, true) end end local phaseValues = {10, 20, 30, 40, 50} local symbol1 = "=" local symbol2 = "-" local displayPhase = createPhaseDisplayer(phaseValues, symbol1, symbol2) -- Testing all phases with one extra for i = 1, #phaseValues + 1 do displayPhase() end

Not very clear description, see yourself whether the following does what you want: local function setSpeedForSeconds(speed, seconds) gg.setSpeed(speed) gg.sleep(seconds * 1000) end while true do setSpeedForSeconds(1, 15) setSpeedForSeconds(5, 360) end

From "Lua in GameGuardian" section of the documentation:

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.

@MonkeySAN modify the code to detect process bitness without relying on "getTargetInfo" (since it's not guaranteed to be available), for example like the following: local ranges = gg.getRangesList() local highestAddress = ranges[#ranges]["end"] local is64 = (highestAddress >> 32) ~= 0

View File fastmem Performance-oriented library for reading and writing memory in scripts. Refer to "examples.lua" for usage basics. Main functions: - readMemory: reads array of bytes to string - readMemoryParts: reads array of bytes in parts - writeMemory: writes array of bytes GitHub: https://github.com/CmP-lt/fastmem Submitter CmP Submitted 03/15/2025 Category Templates  

How to store that data in your code effectively depends on which interface to choose an item script needs to provide. If user input is name of item, then table item names as keys and item identifiers as values can work well. If user chooses option from list of possible items, then it can be table of tables with each inner table having name and value fields. Below is an example of tables for both of mentioned options: -- Option 1 local items = { ["dirt"] = 123, ["stone"] = 456 } -- Option 2 local items = { {name = "dirt", value = 123}, {name = "stone", value = 456} }

Doesn't and can't in principle, because Lua implementation in GG is in Java (based on Luaj).

This indicates that value consists of one or more float values that correspond to units. You might be able to find float value corresponding to currently biggest unit used in particular instance of BigNumber, for that you can try range search (for example, if displayed value is 217.58C, then search "217.57~217.59" or maybe even "216.5~217.6", which should include the target value, but may also find many unrelated ones).

You can insert code for logging amount of items in saved list before and after fragments of code to see where it works not as expected: local items = gg.getListItems() print("Amount of items in saved list is " .. #items)

To remove items from saved list GG API has removeListItems function. Below is an example of how to use it to remove all items with value 0 from the list. local savedItems = gg.getListItems() local itemsForRemove = {} for i, v in ipairs(savedItems) do if v.value == 0 then itemsForRemove[#itemsForRemove + 1] = v end end gg.removeListItems(itemsForRemove)