Luki Hackwell

Systems, automation, game-server engineering, security-minded development.

Focus

  • Game server plugins (uMod / Oxide, FiveM)
  • Linux servers & automation
  • Configuration-driven systems
  • Security-aware development
Why config-driven systems?

Hardcoded logic tends to scale linearly in complexity as features grow. Good configuration design often scales better because it makes assumptions explicit and testable.

Projects

Selected work. I prefer small tools that are easy to audit, deploy, and maintain.

  • SmeltAndCookSpeed — configurable furnace tick control for Rust servers
    C#uMod/OxidePerformance
  • SmartWipe — scheduled wipe automation with safety controls
    C#AutomationOps
  • Server Tooling — small scripts for backups, deploys, and hardening
    BashLinuxInfra
What I optimize for
  • Reproducibility: clear steps, minimal surprises
  • Observability: logs and measurable behavior
  • Safety: secure defaults and least privilege

Current Experiments

Server Tick Manipulation

Testing per-entity tick scaling instead of global multipliers to reduce desync in mod-heavy Rust servers.

Working theory

Global multipliers increase mutation frequency everywhere, which can amplify shared-state issues. Per-entity scaling may contain side effects and simplify debugging.

Config vs Code Complexity

Measuring how JSON-driven systems affect long-term maintenance compared to hardcoded logic.

What I track
  • Number of “special cases” added over time
  • Time-to-change for a feature request
  • How often configs become “footguns”

Notes

Mini thought experiment

Most “performance plugins” optimize symptoms, not causes. My approach is to trace state mutation frequency before touching multipliers.

Failure log

Increasing furnace tick rate can cause desync when inventory state is shared or updated too frequently. Mitigation: isolate per-entity timers and validate side effects with measurable counters.

(If you publish real failure logs later: keep them short and factual—no excuses, no drama.)

Security stance (short version)
  • Prefer static sites when possible (lower attack surface)
  • No secrets in repos (ever)
  • Least privilege for services and plugins
  • Measure before changing performance-critical behavior