BattleLuck is a server-side BepInEx IL2CPP plugin for V Rising dedicated servers. It provides configurable competitive and cooperative game events, managed player sessions, rollback-safe player state and loadouts, NPC and boss control, progression and death-prevention systems, teleports, zones, schematics, and an ECS-backed action pipeline.
Event behavior is defined through configuration and validated before execution. Optional local AI tools can assist with verified action discovery, event authoring, runtime announcements, and approval-gated configuration changes. Network-based AI work runs asynchronously, while ProjectM and Unity ECS mutations are dispatched to the server main thread.
- Install BepInEx for V Rising on the dedicated server.
- Install the package with a Thunderstore-compatible mod manager, or copy the package files into the server's
BepInExfolder. - Start the server once.
BattleLuck.dllextracts missing default config files and optional helper tools toBepInEx/config/BattleLuck/andBepInEx/config/BattleLuck/tools/. - Edit files under
BepInEx/config/BattleLuck/, including event definitions insideBepInEx/config/BattleLuck/events/<eventId>/. - Use
.helpin game to see the commands available to your permission level.
Extraction is additive: the DLL never overwrites an existing config, event, prompt,
or tool file, so upgrades preserve server-owner changes. Provider credentials and
.env files are not embedded in the DLL; configure those locally on the server.
AI is server-owned and local-first. Every installation includes the .ai command
surface, but no model weights or provider credentials are bundled. A server owner
can run a local Llama/Ollama-compatible endpoint or explicitly configure a hosted
provider; without one, BattleLuck uses its simple local fallback for basic help and
catalog guidance. Live actions and event edits still require admin approval.
- Install BattleLuck on the dedicated server; players do not need a separate AI client or model download.
- The server reads
BepInEx/config/BattleLuck/ai_config.jsonand starts the configured provider or local fallback. The owner can run.ai.statusor.aistatusto see the active provider and health. - Players can use
.ai <question>for server-side advice. Player chat is advice-only and cannot change events, NPCs, inventory, or world state. - Admins use catalog search and preview commands. Only an explicit approval sends a validated operation to the server main-thread runtime.
- Hosted AI, Discord, MCP, and sidecar integrations are opt-in. If enabled, the configured provider receives the prompt; conversation history remains off by default and no credentials are stored in the mod package.
🚧 BattleLuck AI Chat channel is planned for next week. It will be a new,
dedicated channel in the existing BattleLuck chat/server, so players can keep AI
questions and responses separate from match play without joining a second server
or installing another mod. It will use the same .ai permissions, provider, and
approval pipeline already described above.
The channel remains part of the same chat integration, but uses a separate route so messages can be filtered independently. Planned message markers start each message and make the channel easy to scan:
📣 [ANNOUNCE]— server and event notices.🤖 [AI]— questions, guidance, and approved AI previews.⚔️ [EVENT]— match starts, phases, and results.🛡️ [ADMIN]— approval and rollback status (admin-only details).
This is a roadmap item, not a current command or configuration option. Until the
channel ships, use .ai in the normal game chat and .aistatus for provider
health.
- An action-driven event runtime framework with configurable example modes. Unified modes without explicit legacy flows use the managed snapshot, kit, team, teleport, death, and restore lifecycle. Shipped locations, prefabs, spawns, and cleanup still require live-server validation before production use.
- NPC control, boss commands, generic actions, and safe action reachability checks.
- Player event sessions, loadouts, progression, death-prevention charges, native-backed rollback snapshots, and restore-on-exit flows.
- Teleport services, spatial points, borders, schematics, and verified data catalogs.
- Optional local LLM prompts for event and mod authoring with approval gates and main-thread-safe execution.
In BattleLuck, a mode is an event definition. The identifiers modeId and
eventId refer to the same configuration concept, such as bloodbath,
colosseum, or trial_of_all_actions.
The name modeId is retained in models, JSON files, commands, and APIs for
backward compatibility. A running instance of an event is identified separately
by its sessionId or event run identifier.
ModeId / EventId = bloodbath
SessionId = a specific run of bloodbath
ZoneHash = the zone used for that run
BattleLuck is V Rising-first and can run entirely on your own server. The plugin, event files, action catalog, rollback state, and optional AI provider stay under the server owner's control; there is no required hosted control plane.
- BepInEx + Harmony — plugin loading and safe game-system patches.
- VampireCommandFramework — V Rising chat commands used by BattleLuck.
- Ollama or llama.cpp — private local LLM hosting for
.ai. - Docker Compose — optional one-command local AI runtime from
docker-compose.ai.yml. - BattleLuck action catalog — V Rising events, NPC control, sequences, ticks, approvals, and native-backed rollback in this repository.
git clone https://github.com/usstunlab1/Battleluck.git
Set-Location Battleluck
dotnet restore
dotnet build .\BattleLuck.sln -c Release /p:DeployBattleLuck=falseDeploy directly to a server after installing BepInEx and VampireCommandFramework:
dotnet build .\BattleLuck.sln -c Release `
/p:DeployBattleLuck=true `
/p:ServerPluginPath="C:\Path\to\VRising_Server\BepInEx\plugins\BattleLuck" `
/p:ServerConfigPath="C:\Path\to\VRising_Server\BepInEx\config\BattleLuck"For a private AI provider, run docker compose -f docker-compose.ai.yml up -d,
confirm http://127.0.0.1:11434 is reachable from the V Rising server, then use
.ai.reload in game. 127.0.0.1 is correct when Ollama is installed on the same
server as V Rising. If Ollama runs on another host, set llama_api.base_url to
http://<AI-SERVER-PRIVATE-IP>:11434 instead and allow that private network
connection through the firewall. Players never need to connect to this endpoint.
See the self-hosted operations guide for
provider, packaging, and release details.
V Rising is the only shipped game adapter today. The action/catalog boundary
is intentionally separated from game-specific ECS code so future adapters can be
added without changing the .ai, approval, task, sequence, and rollback workflow.
Unity ECS/BepInEx games are the next planned adapter family; Unreal, Source, and
other games are roadmap ideas only and are not supported by this release.
BattleLuck is cloud-provider-neutral: deploy the same plugin, event configuration, action catalog, and AI approval pipeline on a Windows or Linux V Rising dedicated server hosted by any cloud provider—or on your own hardware. No cloud SDK is required in the plugin, so moving providers normally only changes the server path, network rules, storage backup, and optional provider credentials.
Snapshots, event definitions, custom sequences, and integrations remain portable
files under BepInEx/config/BattleLuck/. Keep those files and the server's backup
policy under your control; do not copy secrets or active player data into a public
repository. See the self-hosted operations guide
for the deployment contract.
.ai is the primary BattleLuck interface. All commands use the . prefix, and
.help is the live permission-aware source of truth. Other commands are optional,
admin-only tools for servers that enable the corresponding event, NPC, schematic,
roadmap, or integration features.
Permission labels: public commands are read-only/advice-oriented; admin commands create previews or perform approved runtime/config operations.
.help Show available commands [public]
.ai <message> Ask for advice; player chat cannot mutate state [public]
.ai end End the four-reply AI conversation [public]
.ai history [items] Show your in-memory AI history from the last 24 hours [public]
.ai tasks List your recent AI planning tasks [public]
.ai tasks <goal> Create a catalog-backed plan (preview only) [admin]
.aistatus Show provider/runtime status [public, read-only]
.ai catalog search <text> Search the verified action catalog [admin]
.ai action <catalog action> Preview one runtime action [admin]
.ai create <eventId> [template] Clone an event, default Bloodbath [admin]
.ai event deploy <id> <gist> Stage, validate, back up, and register an event [admin]
.ai event status [id] Show deployment/file status [public]
.ai event audit [id] Summarize deployment outcomes and recommendations [admin]
.ai event rollback <eventId> Restore the latest known-good event backup [admin]
.ai event request <change> Draft a validated event edit [admin]
.ai event review <mode> Review an event without writing files [admin]
.ai event preview <id> Inspect a pending proposal [admin]
.ai event approve <id> Apply an approved event proposal [admin]
.ai approve [id] Execute an approved live-action proposal [admin]
.ai event rollback <operationId> Roll back a pending event proposal [admin]
.ai rollback [id] Discard a pending live-action proposal [admin]
.ai.status Show detailed AI provider status [admin]
.ai.reload Reload AI configuration [admin]
Process: search the catalog, request a preview, inspect the operation id, approve
it, then let the server execute approved actions through its main-thread pipeline.
An interactive .ai <message> conversation allows up to four AI replies; use
.ai end to close it early. .ai history [items] shows transient conversation
items from the last 24 hours, while .ai tasks <goal> stores a planner proposal
for admin review without executing it. Rollback/discard only applies to pending
proposals; it cannot undo an action that already ran. Use .help to discover the
full .ai surface for the installation.
config/BattleLuck/actions_catalog.json is the action source of truth. It contains
registered names, metadata, parameters, examples, categories, and reusable
sequences; the runtime also adds verified aliases from the live system registry.
Use .ai catalog search <text> before proposing an action. Actions may come from
any catalog category or verified ProjectM/Unity system reference, but every action
must have a runtime handler, pass validation, and remain approval-gated. A
system.* alias records a verified system reference; it does not invoke arbitrary
native ECS code through reflection.
The current catalog includes 202 registered action names, 34 example categories, and built-in sequence definitions. The live catalog/search result is authoritative when the server is running.
Developers can build reusable action sequences from catalog actions. Sequence steps
may include wait:<seconds> and tick:<event-second> markers; the unified event
runtime schedules them on the session clock. The server tick drains queued AI and
ECS work on the main thread, and runtime_inject entries are checked on the next
event tick.
.ai.sequence.gather <name> <search text> [admin]
.ai.sequence.create <name> <action; wait:5; tick:30; action> [admin]
.ai.sequence.preview <name> <steps> [admin]
.ai.sequence.execute <name> [admin]
Use .ai.sequence.show/list/add/delete to maintain named sequences, then invoke a
validated sequence with sequence.custom.play:sequenceId=<id>|schedule=true from
an event phase, timer, trigger, or approved live action.
These managed custom sequences do not depend on the native ProjectM
SequencerUpdateGroup Harmony hook. That telemetry hook is disabled for the
current game API until a stable patch target is verified on a live server.
These are not required for the primary AI workflow and may be unavailable to non-admins or when a feature is disabled:
.toggleenter [modeName] Join an event zone
.toggleleave Leave an event and restore your state
.exit Force-exit the current event
.score Show the current scoreboard
.elo Show Colosseum rating
.reload Reload all BattleLuck configuration (admin)
.start Force-start a prepared event session (admin)
.rollback <operationId> Roll back a pending operation (admin)
.swapteam [closest|balance] Balance or move event teams (admin)
.swapteam.ai [options] Balance teams + AI announcement; NPC AI coming soon (admin)
.event.create <eventId> Clone Bloodbath into a custom event (admin)
.event.start <mode> [force] Start an event; high-load windows require force=true (admin)
.event.end <mode> End a mode's active sessions (admin)
.event.status Show active events and player counts (admin)
.modelist List registered modes (admin)
.bstatus Show live runtime status (admin)
.npc.near [radius] [limit] List nearby controlled NPCs (admin)
.npc.spawn <prefab> [count] Spawn controlled NPCs (admin)
.npc.follow <npcId> [target] Make an NPC follow a target (admin)
.npc.goto <npcId> [x y z] Move an NPC (admin)
.npc.despawn <npcId|all> Despawn controlled NPCs (admin)
.boss.spawn <prefab> [id] Spawn a controlled boss/NPC (admin)
.boss.list List controlled bosses/NPCs (admin)
.roadmap.status Show roadmap milestones (admin)
.roadmap.prompt <llm|developer> Show the active prompt contract (admin)
.schematic.list List loaded arena schematics (admin)
.schematic.capture <name> Capture a nearby schematic (admin)
Admins can create a complete editable event without adding C# code:
.event.create shadow_hunt bloodbath
The command creates config/BattleLuck/events/shadow_hunt/, copies
flow.json, zones.json, kits.json, and prompt.txt, assigns a unique zone
hash, and registers the event with the live runtime. Customize the copied zone
center, kits, actions, phases, timers, and prompt, then run:
.event.start shadow_hunt
Creating the folder is a hot file-and-registration operation. Starting an edited
event executes its actions in the V Rising server, so invalid JSON, prefabs,
actions, or native ECS operations may hang, crash, or restart the server. Back up
the server, run .ai event review shadow_hunt, and test in a private arena before
inviting players.
While the process is alive, BattleLuck records the AI operation/approval trail in
BepInEx/config/BattleLuck/ai_operations.log; the AI can use that context to
recommend a safer alternative. The one-day .ai history and .ai tasks views are
in-memory and may be lost by a hard crash. Before event mutations, BattleLuck
writes each player's pre-event state to
BepInEx/data/BattleLuck/snapshots/<steamId>.json. Normal exit or an explicit
restore uses that snapshot. A hard crash can stop cleanup before it executes, so
after restart inspect the logs and restore affected players before retrying;
automatic rollback during an abrupt process termination is not guaranteed.
For a busy server, copy the template and edit the four files while the server is
offline or in a low-load/standby window. Review the event with .ai event review <eventId>, keep a backup of config/BattleLuck/events/, and use the server's
controlled reload command only after the files pass review. This keeps risky
registration and native action execution out of peak player traffic.
Any player can ask .ai for guidance or use the read-only status request. Only
admins can deploy or roll back files; no admin needs to write C#:
.ai event deploy shadow_hunt https://gist.github.com/owner/gist-id
.ai event status shadow_hunt
.ai event audit shadow_hunt
.ai event rollback shadow_hunt
deploy downloads flow.json, zones.json, kits.json, and prompt.txt from
an HTTPS GitHub Gist, validates the declarative actions, prompt policy, JSON, kit
references, and zone hashes, backs up the current event under
BepInEx/config/BattleLuck/backups/<eventId>/, then stages and registers it. It
does not start the event. Each backup contains manifest.json with file sizes
and SHA-256 hashes. status is read-only and available to all players;
rollback verifies that manifest before restoring the latest known-good
deployment. .ai event audit [eventId] summarizes the JSONL audit trail and
suggests deterministic fixes from recurring error codes. A rollback restores
files, not a live action that already executed.
The offline validator is available at tools/validators/validate-json.sh and
the matching schemas are in config/BattleLuck/events/schemas/. The plugin
performs these dependency-free checks itself when the event is staged. These
deployment, status, audit, and rollback commands are deterministic and do not
require an external LLM provider to be online; the optional LLM only helps
admins draft or explain changes.
Use .ai event deploy <eventId> <https-gist-url> --dry-run to validate a bundle
without writing a backup or registering it. The audit record reports
deploy_dry_run, registerOk=false, and exit=0 when validation passes.
.ai event rollback <eventId> # event definition backup
.ai rollback player <name|steamId> <timestamp|runId> # exact snapshot selector
.ai rollback server status # count online/offline event snapshots
.ai rollback server players confirm # restore all online event snapshots
.ai rollback server purge <eventId> [backupId] confirm # delete a BattleLuck backup
The player/server commands restore BepInEx/data/BattleLuck/snapshots/ state;
offline snapshots remain on disk and are reported as pending. A full V Rising
world/server-save rollback is owned by the dedicated server's SaveFileManager
and host backup tooling, so BattleLuck does not pretend to restore or delete it.
The purge command can delete only a named BattleLuck deployment backup after
the explicit confirm token; it never deletes the host's world save.
KindredExtract remains a developer reference tool: use .dump p/.dump eq to
verify prefab names and queries before publishing the Gist. BattleLuck does not
execute arbitrary KindredExtract code or treat a Gist as trusted native code.
Maintainer: coyoteq1 — Ahmadtllal
Discord support: https://discord.gg/uJ2ehWv4gR
BattleLuck is licensed under the GNU Affero General Public License, version 3 or any later version. See LICENSE and THIRD_PARTY_NOTICES.md.
