ET Member Popular Post RNGesus Posted December 14, 2025 ET Member Popular Post Posted December 14, 2025 Preview video contains NO REAL HUMANS Omni-bots only video is NOT focused on good game play by me but showing what it can do If you’ve ever loved Omni-Bot but wished bots played the map more like real players do, this is it. Omni-Bot 2.0 Next (ML) takes the classic Omni-Bot framework and adds a machine learning “coach” on top — not to turn bots into laser-aim robots, but to make them smarter about movement, timing, positioning, and objectives. This is the upgrade that makes bots feel less scripted and more like a team that learns. 🧠 What Machine Learning actually does for Omni-Bot Traditional bots mostly rely on rules and routing: “Go here, do this, follow this path, repeat.” That works… until the match gets chaotic. Players flank. Teams rotate. The “best route” changes. Timing matters. Pressure matters. ML changes that. It helps bots learn the big picture of winning a match: ✅ 1) Smarter objective choices (not just “run to the flag”) ML helps bots decide: Should we plant now or regroup? Should I escort, defend, or hunt the disarmer? Is it smarter to rotate to the next objective instead of dying on this one? When should we commit to a push vs hold ground? Result: bots that stop wasting lives and start making plays. ✅ 2) Better routes and rotations (adaptive movement) Instead of always taking the same obvious path, ML can learn: safer routes when pressure is high faster routes when time is critical rotations that match what’s happening in the match positioning that supports team flow Result: bots that don’t feel like they’re on rails. ✅ 3) More natural map control and positioning Humans don’t just “go to objective.” They take control: hold angles set up near chokepoints rotate early when something feels off pull back when they’re outnumbered ML helps bots learn those patterns — the “why” behind movement. Result: bots that feel like they understand space, not just waypoints. ✅ 4) Team behavior gets better over time The biggest difference you’ll feel is that bots start behaving like a team: pressure and distraction plays better escort timing defending the right areas more often less random wandering and indecision Result: matches feel more like real ET games instead of target practice. ⚔️ The best part: combat stays classic Omni-Bot This is important. Omni-Bot 2.0 Next (ML) does NOT replace combat with ML. No weird “AI aim.” No robotic tracking. No “cheater bots.” ✅ The existing Omni-Bot combat system stays intact — aiming, firing, combat movement remains the trusted, battle-tested logic. 🛡️ Combat Gating (the secret sauce) When combat starts, the ML layer can automatically step back so bots stay responsive and fight like normal Omni-Bot. When the fight ends, ML takes over again to handle strategy and movement. Result: smart strategy + classic combat feel. 🎛️ Total control for server owners 🚫 Zero-impact disable If you turn ML off: ml_enable 0 …it has absolutely no effect on gameplay. No residual hooks. No behavior changes. It becomes classic Omni-Bot. ✅ Great for: testing vs baseline bots running “ML nights” / events keeping competitive servers consistent slowly rolling ML into your community 🧪 What you’ll notice immediately in-game You’ll see bots that: commit to objectives more reliably rotate with purpose instead of looping waste fewer lives on bad pushes take smarter routes depending on the match feel less predictable and more “player-like” Not perfect gods. Not aim demons. Just better ET brains. ⚙️ The Tech The ML layer uses reinforcement learning (PPO / Proximal Policy Optimization) to learn high-level decision making: where to go, what to prioritize, when to rotate, how to move more effectively. It’s basically training bots to optimize for winning outcomes while preserving what Omni-Bot already does well. ┌─────────────────────────────────────────────────────────────────────────┐ │ GAME ENGINE (ET) │ │ │ │ ┌─────────────────┐ ┌──────────────────────┐ │ │ │ Game Server │◄────── mod interface ───►│ Omni-Bot Library │ │ │ │ (qagame) │ │ (DLL/SO) │ │ │ └─────────────────┘ └──────────────────────┘ │ └─────────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────────┐ │ OMNI-BOT INTERNAL SYSTEMS │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ IGame │ │ GoalManager │ │ Navigation │ │ Script │ │ │ │ Manager │ │ │ │ Manager │ │ Manager │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ │ │ │ │ │ └─────────────────┴────────┬────────┴─────────────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────────────────┐ │ │ │ CLIENT (Per-Bot) │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ │ │ │ │ │ Sensory │ │ Targeting │ │ State Machine │ │ │ │ │ │ Memory │ │ System │ │ (High/Low Level) │ │ │ │ │ └──────────────┘ └──────────────┘ └──────────────────────┘ │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ │ │ │ │ │ Weapon │ │ Steering │ │ Path Following │ │ │ │ │ │ System │ │ System │ │ │ │ │ │ │ └──────────────┘ └──────────────┘ └──────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────┘ Key Components IGame / Game Manager The IGame (Game Manager) acts as the central coordinator and is responsible for: Managing overall game state (e.g., round start/end, match time) Handling bot spawning and removal Dispatching events to bots Coordinating with the game engine through exports/integration points Client (Bot Instance) Each bot runs as a Client instance composed of multiple subsystems: Subsystem Purpose Sensory Memory Tracks what the bot has recently seen or heard Targeting System Selects and tracks enemies to engage Weapon System Chooses appropriate weapons and handles firing logic Steering System Controls low-level movement and obstacle avoidance State Machine Drives high-level behavior (e.g., attack, defend, patrol) Goal Manager The Goal Manager controls objective-driven behavior and map goals: MapGoals: Capturable flags, dynamite targets, construction sites, etc. Goal Queries: Bots request goals based on team, class/role, distance, and context Priority System: Goals are weighted and gated by availability/conditions Navigation Manager The Navigation Manager provides pathfinding and movement planning: Waypoint System: Pre-placed nodes defining walkable/navigation areas Path Planning: A* routing between waypoints Navigation Flags: Movement constraints and actions (jump, crouch, ladder, water, etc.) Bot Decision Loop Each frame, every bot executes the following update sequence: Update Sensory Memory Processes visible entities, audio cues, and recent damage events Target Selection Selects the highest-priority enemy target (or none) High-Level State Machine Combat states (when a valid target exists): Engage, take cover, retreat Objective states (when no target exists): Attack objective, defend, patrol Low-Level State Machine Executes the current action (e.g., move, shoot, use/interact) Steering Performs obstacle avoidance and path-following adjustments Output Sends final movement, aim, and fire commands to the game engine Waypoint Navigation Bots navigate using pre-authored waypoint files (.nav) and move through connected waypoint chains. Example waypoint chain: Waypoint A → Waypoint B → Waypoint C A: Jump flag (jump action required) B: Crouch flag (crouch action required) 😄 Ladder flag (ladder interaction required) Waypoint Data Model Each waypoint typically includes: Position: 3D world coordinates Connections: Links to neighboring waypoints Flags: Special movement requirements (jump, crouch, ladder, water, etc.) Radius: Arrival tolerance used to consider the waypoint “reached” ML Architecture The Omni-Bot ML system is composed of two primary components: the game-side ML adapter (Omni-Bot) and an external Python ML server. These components communicate over TCP using JSON messages. High-Level System Diagram ┌─────────────────────────────────────────────────────────────────┐ │ OMNI-BOT ML SYSTEM │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ┌───────────────────────┐ ┌──────────────────────────┐│ │ │ Game (Omni-Bot) │ TCP │ ML Server (Python) ││ │ │ │ JSON │ ││ │ │ ET_MLAdapter │◄───────►│ PPO Agent ││ │ │ ├─ MLController │ :27970 │ ├─ Policy Network ││ │ │ ├─ MLNetworkClient │ │ ├─ Value Network ││ │ │ └─ MLCombatState │ │ └─ Training Loop ││ │ │ │ │ ││ │ └───────────────────────┘ └──────────────────────────┘│ │ (C++ DLL/SO) (Python 3) │ │ │ └─────────────────────────────────────────────────────────────────┘ Game-Side Components (Omni-Bot) The game process hosts a native C++ adapter module responsible for collecting state, maintaining ML-related control logic, and issuing decisions back into Omni-Bot. ET_MLAdapter Primary integration layer within Omni-Bot. MLController Orchestrates ML-driven decision flow and determines when ML control is active. MLNetworkClient Manages TCP connectivity and JSON message exchange with the ML server. MLCombatState Tracks combat context and supports gating/disablement logic during firefights (where applicable). ML Server Components (Python) The ML server runs out-of-process in Python 3 and hosts the learning agent responsible for inference and training. PPO Agent (Proximal Policy Optimization) Reinforcement learning agent used to select actions based on game state. Policy Network: Produces action selections (movement/goal decisions) Value Network: Estimates expected returns for training stability Training Loop: Updates the model using collected experience data Communication Layer Protocol: TCP Encoding: JSON Endpoint: :27970 Flow: Bi-directional request/response (state → inference → action, plus optional training telemetry) 💻 Cross-platform support Built for: Windows Linux macOS (Intel + Apple Silicon) 🔥 OMNI-BOT 2.0 NEXT (ML) Old-school roots. Next-level brain. If you run servers, love ET, or want bots that finally play the game like it matters — this is the next era. 5 3 4 Quote
Lorenzo Battistutta Posted December 18, 2025 Posted December 18, 2025 I am interested for my LAN server Quote
ET Member RNGesus Posted March 20 Author ET Member Posted March 20 What if omni-bot without a ML server could Live generate a navmesh of any map outside of the game process to not lag server? What if it could read the map file it doesnt know and figure out the goals for each side dynamically and their order? What if scripts were no longer required for omni-bot to work on anymap? What if it could do all this in the warm up of 15 seconds so bots are ready to roll on unknown maps before it starts? Well its possible. 6 2 1 1 Quote
RendeL Posted March 21 Posted March 21 Another solution I had on my etpub server long time ago was a lua that made all players including bots "transparent" so you could just run through them. Solved alot of spawn blockages. 6 1 2 Quote
tipsy Posted March 22 Posted March 22 (edited) 10 hours ago, RendeL said: Another solution I had on my etpub server long time ago was a lua that made all players including bots "transparent" so you could just run through them. Solved alot of spawn blockages. Good 1, I remember seeing it, but I don't remember where. Edited March 22 by tipsy 2 Quote
TomekKromek Posted April 16 Posted April 16 On 3/21/2026 at 7:59 PM, RendeL said: Another solution I had on my etpub server long time ago was a lua that made all players including bots "transparent" so you could just run through them. Solved alot of spawn blockages. Transpatent for as long as you have spawn protection or was it more complex? Quote
Armagedonyx Posted April 17 Posted April 17 (edited) The player transparency with spawn protection on is, from memory a thing on Hirntot server as well. Edited April 17 by Armagedonyx Quote
ET Member RNGesus Posted April 17 Author ET Member Posted April 17 (edited) 50 minutes ago, Armagedonyx said: The player transparency with spawn protection on is, from memory a thing on Hirntot server as well. Yes it’s done via LUA and I believe both silent and jaymod expose the ps.powerups so any of our servers can do this. So you can grab via whatever mods API ps.powerups[PW_INVULNERABLE] I’d suggest grab once then cache off of level.time so server doesn’t need to grab every frame then set r.contents NONSOLID for players with that power up and now no more spawn mess 😁 Edited April 17 by RNGesus 2 Quote
.thumb.png.5a3eeca736d04c3fca62c7ba1687930a.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.