squidleon

I do use ChatGPT sometimes as a tool while working on the project (similar to using documentation, Stack Overflow, or an IDE assistant), but the post and the project direction are my own. So what?

Projects like UOX3 are a big part of the history of the Ultima Online emulator scene, so it’s great to hear from someone who helped maintain it.

  And funny you mention Mangos — the WoW emulation scene was a huge inspiration for UO server development back in the day. Different game, same passion for reverse-engineering and rebuilding these worlds. The
  community-driven server scene is one of the best things about MMO gaming in general.

  Thanks for the kind words and good luck with your WoW adventures! :*!

On sector sync bursts — this is something I'm actively tuning. Right now when a player enters a new sector, we sync all ground items and mobiles in the surrounding sectors (configurable radius). For busy areas that can mean a lot of packets at once. The current approach is:

  - Sector enter sync only sends the delta  sectors the player wasn't already seeing, so a simple move into an adjacent sector doesn't resync everything
  - Sectors close to the player (within 1 of center) are always resynced because the UO client silently drops items beyond its visual range (~18 tiles), so you need to re-send them when the player comes back
  - The outgoing packet queue handles the actual send, so the game loop isn't blocked waiting for network I/O

  That said, there's definitely room for prioritization (mobiles first, then nearby items, then distant items) and spreading the sync across multiple ticks instead of one burst. It's on the roadmap.

  On NativeAOT — honestly, both. The single-binary deployment is great for Docker (small image, instant startup), but the real win is predictable performance. No JIT warmup, no tiered compilation surprises
  mid-session. For a game server where you care about consistent tick timing, eliminating that variable is worth it. The tradeoff is you lose some runtime flexibility, but source generators fill most of that gap
  (packet registration, serialization, etc.).

You're touching on a real pain point. Right now the Lua boundary does show measurable overhead under load, especially with per-tick callbacks across many entities (doors, spawners, etc.). MoonSharp's interop cost adds up when you're calling into Lua thousands of times per tick.

I'm actively looking at batching script invocations per tick and capping the budget so a heavy script wave can't blow up tail latency. The goal is to keep the game loop deterministic if Lua eats too much of the tick budget, defer the rest to the next tick rather than letting the whole loop stall.

It's one of those problems where the architecture gives you a clean place to solve it (the boundary is explicit, so you can meter it), but the solution still needs work. Appreciate you calling it out — good toknow others think about the same tradeoffs.