AIgot | Fixing The Engine, Not Hiding

What is it?

AIgot — PaperSpigot 1.8.8 Performance Fork

AIgot is a hard fork of PaperSpigot 1.8.8 focused on real engine optimization, long-term stability, and structural correctness.
It is built for servers that need consistent performance under load — not temporary gains achieved by unsafe async patches.

Instead of moving core systems to asynchronous threads and hoping nothing breaks, AIgot focuses on fixing performance problems at their root: data structures, tick execution flow, memory usage, and internal server mechanics.

Most forks attempt to solve lag by pushing logic into async threads without addressing the root cause.
AIgot follows a different philosophy:

Fix the engine first. Optimize architecture. Preserve correctness.

This approach ensures predictable behavior, stable TPS, and reliable uptime even under heavy load.

This diagram illustrates a fundamental architectural limitation of Minecraft 1.8.8:
the entire game engine is built around a deterministic, single-threaded tick loop.

Core systems such as:

entity ticking
chunk logic
block updates
redstone simulation
world state mutations

all depend on strict execution order and shared mutable state.

When asynchronous threads are introduced into these systems, they do not remove the bottleneck — they simply move parts of the workload outside the main thread while still relying on the same shared data.

This creates several critical problems.

AIgot’s Approach

Instead of breaking the engine model, AIgot focuses on:

reducing per-tick workload
optimizing hot paths
refactoring expensive subsystems
improving memory behavior
simplifying execution flow

This keeps:

deterministic behavior
data integrity
plugin compatibility
long-term stability

While delivering measurable performance improvements.

Why This Exists

This image represents a reality most projects avoid saying out loud:

AIgot is not made for small servers.

If you’re running a private survival world for a few friends, vanilla or standard Paper is more than enough.
You don’t need engine refactors, tracking optimizations, or memory tuning to host five players farming carrots.

But that changes completely when scale appears.

What Changes at Scale

Once you start dealing with:

hundreds of concurrent players
PvP-heavy activity
entity spam
TNT usage
redstone automation
large plugin stacks
long uptime requirements

the bottlenecks stop being “hardware problems”.

They become engine problems.

At that point, performance is no longer about CPU clocks — it’s about:

tick execution cost
memory behavior
entity tracking efficiency
chunk pipeline performance
synchronization overhead
garbage collection pressure

This is the environment AIgot is designed for.

Feature Overview — What Was Actually Reworked (much more actually)

This image summarizes one of the core goals of AIgot:
not adding features on top of a broken foundation, but rebuilding the foundation itself.

Every highlighted system represents a part of the Minecraft 1.8.8 engine that traditionally becomes a bottleneck at scale.

These changes are not surface-level tweaks.
They represent structural improvements across the most critical server subsystems.

This is what allows AIgot to scale cleanly while preserving correctness and stability.

AIgot includes patches for but not limited to:

all publicly known dupes
multiple engine-level exploits/hot-paths
additional vulnerabilities discovered through AI-assisted analysis

Plugin Compatibility — Designed to Stay Compatible

One of the main design goals of AIgot is to improve the engine without breaking the ecosystem around it.

All structural changes were made with strict attention to preserving:

Bukkit API behavior
Spigot/Paper event flow
packet interaction patterns
plugin hooks and callbacks

This means that, from a plugin perspective, AIgot behaves exactly like a standard PaperSpigot environment.

What Works Out of the Box

AIgot is designed to remain compatible with:

AntiCheat systems
ProtocolLib-based plugins
Citizens and NPC frameworks
Permission systems (LuckPerms, PEX, etc.)
Protection plugins (WorldGuard, WorldEdit)
Disguise and packet-level plugins
Placeholder and API-heavy integrations

In most cases, no plugin configuration changes are required.

Issue Handling Philosophy

Even with careful design, edge cases can exist.

If any plugin incompatibility is discovered:

it will be investigated
patched properly
and resolved without introducing unsafe behavior

The goal is not just performance — it’s long-term maintainability.

EntityTracker Demo

This demo visualizes the core scalability win behind AIgot’s 1.8.8 EntityTracker rewrite.

Vanilla tracking is effectively a brute-force broad-phase: every tick it considers every entity for every player → O(P · E) candidate checks before running the expensive stuff (updatePlayer logic, metadata/attributes, packet building/sending).

AIgot adds a real game-engine style broad-phase:

Entities are bucketed by chunk (persistent spatial index)
Viewers that need a rescan iterate only the chunks intersecting their tracking range
A cheap AABB/box check culls most candidates before any deeper work

Result: candidate checks drop from P · E to roughly P · (visibleChunks) · (entitiesPerChunk) — which is why AIgot keeps scaling when entity/player density climbs.

Important: this benchmark is conceptual (browser-side), but it mirrors the same asymptotic behavior the NMS code exploits. The real server-side win is even larger because each avoided candidate also avoids heavier NMS work and packet traffic.

send me a dm on discord: aegontargaryen-dev

COMPLIANCE

GPLv3: Everyone that got access to AIgot is entitled to a copy of the source code. You can ask on Discord.
Credits to PaperSpigot and Spigot/CraftBukkit.

AIgot | Fixing The Engine, Not Hiding v1.0

Overview History

What is it?