Python Guide

Write what should actually happen across the network.

XL Logic uses Python as its in-game automation language. Scripts can read devices, feed shared or individually named screens, move items and fluids across Material I/O endpoints, react to world state, and keep running across repeated ticks without requiring external tooling before the player can experiment. The runtime is sandboxed, so Python executes against the XL Logic API surface rather than the host OS, JVM interop layer, or server console.

world screen network devices
Mental model

What an XL Logic computer really is.

  • The computer executes Python on the server.
  • The runtime only exposes exported XL Logic objects such as world, screen, network, devices, and output.
  • world gives live data about dimension, time, weather, and moon phase.
  • screen and output make results visible on both the computer and linked screen blocks, and named screens can be addressed individually.
  • network and devices operate on the visible local cable segment.
  • Long-running programs must yield between ticks.
Safety model

Python can reach the game, not the host machine.

  • Scripts do not get direct access to the host OS, local files, spawned processes, threads, environment variables, or raw sockets.
  • Java and polyglot imports are blocked, so Python cannot tunnel back into host APIs or JVM-side escape hatches.
  • There is no direct scripting bridge for op, restart, shutdown, System.exit, or arbitrary server command dispatch.
  • The intended path is the XL Logic runtime surface: world, screen, output, network, devices, Material I/O, crafting, and XLAPI helpers.
Quick start

Three typical entry examples.

These examples mirror the beginner guide and show the mod the way an actual player is likely to use it.

hello_world.py
screen.print("Hello from XL Logic")

screen.show("World", {
    "day_time": world.day_time(),
    "raining": world.is_raining(),
})
device_table.py
rows = []
for name in list_device_names():
    current = device(name)
    rows.append([
        name,
        current.type(),
        current.network_scope(),
        current.remote_policy(),
    ])

screen.table("Devices", ["API", "Type", "Scope", "Policy"], rows)
rain_watch.py
last_rain = None

def tick():
    global last_rain
    raining = world.is_raining()
    if raining != last_rain:
        screen.print("Raining: " + str(raining))
        last_rain = raining

yield from repeat(tick, 20)
API surfaces

The most important objects available in the runtime.

screen

For visible output in the editor and on linked screen blocks. Named screen devices expose the same show and table style helpers once you fetch them through get_device(name).

  • screen.print(text)
  • screen.show(title, fields)
  • screen.table(title, columns, rows)
  • screen.plan(title, fields)

network

A beginner layer for device lookup, without immediately dropping to the lower-level API.

  • network.names()
  • network.find(device_type)
  • network.get(name)
  • network.types()

world

Live world state straight from the server context.

  • is_day(), is_night()
  • is_raining(), rain_level()
  • is_thundering(), moon_phase()
  • day_time(), game_time(), real_time()
Device example

Drive named screens and material flow directly from Python.

devices.py
source = get_device("source_io")
left_panel = get_device("left_panel")

if source is not None:
    moved = source.transfer_item_to("sink_io", "south", "south", 0, 16)
    screen.show("Route", {
        "source": "source_io",
        "target": "sink_io",
        "moved": moved,
    })

if left_panel is not None and world.available():
    left_panel.show("World", {
        "day_time": world.day_time(),
        "raining": world.is_raining(),
    })