-
Notifications
You must be signed in to change notification settings - Fork 0
Advanced Tools
Named sets of mods that should be active together. A mod being assigned to a profile is
opt-in — a mod not assigned to any profile is never touched by switch.
gtavmm profile create <name>
gtavmm profile list
gtavmm profile add-mod <profile_id> <mod_id>
gtavmm profile remove-mod <profile_id> <mod_id>
gtavmm profile switch <id>
gtavmm profile export <id> <output.json>
gtavmm profile import <path.json>
gtavmm profile delete <id>
switch disables other profiles' active-only mods and enables this profile's disabled mods,
reusing the same enable/disable mechanism as Managing Installed Mods
— it isn't a separate deployment system. export/import only share the profile name and mod
names, never the mod files themselves — importing matches against what's already installed
locally, since this project never auto-downloads mods.
Off by default. You choose a provider explicitly before anything runs:
gtavmm ai enable ollama --model llama3.1
gtavmm ai enable cloud --model gpt-4o-mini
gtavmm ai set-api-key # reads the key from stdin, never as a CLI argument
gtavmm ai status
gtavmm ai disable
-
Ollama: local,
localhost:11434. Nothing leaves your machine. You install and run Ollama yourself — this tool doesn't bundle it. - Cloud: you supply your own API key (stored in the OS credential manager — Windows Credential Manager / Linux Secret Service — never in a plaintext config file), pointed at an OpenAI-compatible endpoint.
gtavmm ai diagnose --file path/to/log.txt
Read-only advice — nothing is changed automatically. Every request is de-identified (your home directory path is stripped) before it's sent to whichever provider you configured.
A small, reviewed rule library for patterns the community (or the tool's own structural checks) recognizes as likely problems:
gtavmm ai list-known-fixes
gtavmm ai plan-known-fix <rule_id> # preview only, changes nothing
gtavmm ai apply-known-fix <rule_id> --yes # executes the plan
Every rule expands to an explicit Plan (which mods, which actions) that you review before
anything runs. Low-risk, reversible action kinds (disable_mod/enable_mod) can be
whitelisted to skip the --yes prompt:
gtavmm ai show-auto-approve
gtavmm ai set-auto-approve disable_mod enable_mod
Nothing outside that whitelist can ever be auto-approved — the CLI itself refuses to accept other action kinds, not just the UI.
gtavmm translate-config path/to/mod.ini zh-TW
Scoped to external config files (.ini/.xml) only in the shipped CLI — never touches the
original file, always writes a new sibling (e.g. mod.zh-TW.ini). Requires ai enable first.
Note: .NET DLL embedded-string translation was previously considered out of scope, but a
2026-08-29 technical spike found a viable (if involved) binary-patching approach — see the
gtavmm-core design notes for the dll_translate module if you're interested in where that
stands; it isn't wired into the CLI yet.
Your own reusable prompt text — not automated, not an Action Schema, nothing runs on your behalf. Just storage for prompts you want to paste into a diagnosis or your own AI tool of choice:
gtavmm prompt create <name> <content>
gtavmm prompt list
gtavmm prompt update <id> <name> <content>
gtavmm prompt delete <id>
gtavmm fivem-resource-order path/to/resources
gtavmm fivem-apply-load-order path/to/resources path/to/server.cfg
Resolves a correct load order from each resource's declared fxmanifest.lua dependencies —
unlike txAdmin's manual ensure-order CFG editor, this is computed automatically (topological
sort). fivem-apply-load-order writes the result into server.cfg as a clearly-marked,
idempotent block; everything else in the file (hostname, maxclients, unrelated ensure lines,
manual edits) is left untouched, and re-running it updates that block in place instead of
duplicating it.
gtavmm check-components
Confirms ScriptHookV / ScriptHookVDotNet / OpenIV / OpenRPF are present, without installing anything.
gtavmm check-update
Checks GitHub Releases for a newer version. Does not download or apply anything automatically — applying updates is deferred to the desktop app shell.