XL Logic combines several technical layers that would normally be scattered across different mods or much later milestones: server-side GraalPy execution, visible network topology, structured screen output, no-code authoring, multiplayer-safe editing, and tested session recovery. The runtime is intentionally sandboxed so automation stays inside exported game-facing APIs instead of crossing into host execution.
Computers execute Python directly in-game, but inside a server-side, cooperative, sandboxed runtime aligned to Minecraft ticks.
The project takes multiplayer seriously. An editor lock alone is not enough when viewers, disconnects, and restarts are part of the actual game loop.
Script output is not just text inside the editor. It becomes a real in-world screen interface.
XL Logic scripts are meant to automate blocks, endpoints, screens, and bridge responses. They are not general-purpose host scripts, which is why the runtime enforces a narrow execution boundary around what Python can and cannot do.
Scripts interact through exported XL Logic objects such as world, screen, network, devices, output, and bridge helpers.
No local filesystem access, no process spawning, no environment access, no native access, no raw socket use, and no Java or polyglot imports are available inside the script context.
Python does not expose a direct path to op, restart, shutdown, System.exit, or arbitrary server command dispatch. Server control stays outside the scripting surface.
Computers, screens, and endpoints are not linked through abstract menus. They hang off a real cable segment, which makes the whole system inspectable in-world and easier to debug.
Players should be able to move between visual blocks and handwritten code without landing in two disconnected versions of the mod.
Builder
Templates for discovery, live clock, rain watch, source-to-sink item and fluid routing, night lamps, thunder alerts, and evening lighting, plus guards, else branches, and world comparisons.
Python
Full access to world, devices, named screens, direct Material I/O endpoint routing, crafting, output, network, and XLAPI, while host-level access remains sandboxed away.
Shared output
Both authoring paths end up in the same shared screen system, the same named screen targets, and the same visible in-world results.
A project homepage should do more than promise cool ideas. It should also show that the hard parts are actually being verified.
Runtime regressions such as busy loops, oversized stdout or stderr output, and blocked sandbox escapes are covered with classic tests.
Network rules, named screen targeting, Material I/O routes, session reopen, recovery drafts, divergence, teleport, dimension changes, and restart reload are all covered through NeoForge GameTests.
The current green state includes 50 out of 50 GameTests passing, which makes the site useful later for release communication as well.
