System architecture
Keep the mechanics. Replace the decisions.
Hossie is deliberately modular. Every proven capability should be independently testable, freezable and replaceable without rewriting the stock Tactical Ops body.
HossieMutator
├── HossieLoadoutDirector
├── HossieWeaponDirector
├── HossieFireModeDirector
├── HossieSensoryGate
├── HossieTacticalDirector
├── HossieGrenadeDirector
├── HossieMovementDirector
└── HossieVoiceDirector
Fairness
Human-accessible information
Future sensory work is designed around observations and beliefs, not omniscient use of hidden live enemy state.
Decision quality
Professional doctrine
The point is not to make Hossie superhuman. The point is to encode what a top player notices, values and chooses.
Execution
Stock TO primitives
Wherever possible, Hossie calls Tactical Ops systems for buying, firing, movement, inventory and network behavior rather than replacing them.
Future sensory contract
Belief is not engine truth.
RAW ENGINE EVENTS
→ HOSSIE SENSORY GATE
→ HOSSIE BELIEFS
→ HOSSIE MEMORY
→ HOSSIE DECISION
→ safe stock execution
belief != Enemy
belief.position != Enemy.Location
unless valid observation justifies it
Stock decision ownership
Tactical Ops does not have one single “brain function.”
Scenario policy, orders, current UnrealScript state, movement targets, route cache and native pathing all participate. Hossie therefore targets narrow control boundaries rather than trying to overwrite the whole bot.
scenario/team policy
→ Objective / O_number / OrderObject
→ Orders / RealOrders
→ current UnrealScript state
→ MoveTarget / Destination / RouteCache
→ native pathing + latent movement