Auto splitters work by reading live game memory to determine when in-game events have occurred — things like level IDs incrementing, a health value reaching zero, a completion flag flipping toDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/CryZe/asr-assemblyscript/llms.txt
Use this file to discover all available pages before exploring further.
true, or a position crossing a threshold. The asr-assemblyscript/process module is the bridge between your WebAssembly code and the game’s address space, providing functions to attach to a running process, look up module base addresses, and copy raw bytes out of memory into AssemblyScript ArrayBuffers you can then interpret as typed values.
Core Types
The Process module defines two type aliases that appear throughout the API:ProcessId— an opaque handle to an attached process, returned byProcess.attach. A value of0indicates no valid handle.Address— a 64-bit memory address within the target process’s address space.
Attaching to a Process
name (for example 'MyGame.exe' on Windows). Returns a non-zero ProcessId on success, or 0 if no matching process was found.
Always check the returned value before using it:
Checking Whether a Process Is Still Open
true if the process identified by process is still running. You should call this every tick — games can close at any time, and using a stale ProcessId will cause memory reads to fail silently. When isOpen returns false, discard the handle and re-attach on the next tick.
Detaching from a Process
Resolving Module Base Addresses
Most games load their main executable and one or more.dll files. Memory offsets found with a tool like Cheat Engine are typically relative to the base address of one of these modules, not absolute addresses. Use these two functions to resolve module bases:
getModuleAddressreturns the baseAddressat which the named module is loaded in the process’s address space. Add your known offset to this value to get the final address to read.getModuleSizereturns the size of the module in bytes. This is useful for sanity-checking that a module has loaded to the expected size.
Reading Raw Memory
buf.byteLength bytes from address in the target process into buf. Returns true on success and false if the read fails (for example, the address is unmapped or the process has closed). Always check the return value before interpreting the buffer contents.
Reading a Typed Value
To read a specific type, allocate anArrayBuffer of the appropriate byte size, call Process.read, then use a DataView to extract the value:
DataView getter is the littleEndian flag. Nearly all modern games run on x86/x86_64 hardware and store values in little-endian byte order, so true is almost always correct. Verify with your memory tool if you get unexpected values.
Common DataView Methods
| Method | Byte size | Notes |
|---|---|---|
getInt8(offset) | 1 | Signed 8-bit integer |
getUint8(offset) | 1 | Unsigned 8-bit integer |
getInt16(offset, le) | 2 | Signed 16-bit integer |
getUint16(offset, le) | 2 | Unsigned 16-bit integer |
getInt32(offset, le) | 4 | Signed 32-bit integer |
getUint32(offset, le) | 4 | Unsigned 32-bit integer |
getFloat32(offset, le) | 4 | 32-bit IEEE float |
getFloat64(offset, le) | 8 | 64-bit IEEE float |
Reading from a DLL Module
If the value you want is in a loaded.dll rather than the main executable, pass the DLL name to getModuleAddress instead: