#5220Requested

endless procedures

Requested by @xDovos
Energy Committed28,096TeVfrom 6 boosters

procedures have a very high potential for server side computation that takes longer than a ms or needs data that is heavy to calculate/build from the tables. be it physics, npc path finding and behaviour tree updates or other stuff that needs to be updated often with large base data.

the problem currently is that procedures don't have a way of checking if they should stop for a publish, wasm rebuild or other stuff like moving of the module from one machine to another.
the idea is that we need a st_ table for the procedures that keeps track of all the active procedure instances and that they have a column that the procedure can check with a ctx. function for it to stop and all the data the server requires to forcefully stop the procedure if needed (timeout no response and so on).
an example code of the wanted setup would be:

#[procedure]
pub fn run_physics_loop(ctx: &mut ProcedureContext, _row: PhysicsLaunch) {
    let mut world = ctx.with_tx(|tx| {
        build_world_from_db(tx) // computation/time/size expensive build process
    });
    while not ctx.check_stop(){  // check the st_table if it should stop
        let inputs = ctx.with_tx(read_pending_inputs);  // get input data
        apply_membership(&mut world, /* ... */); 
        run_substeps(&mut world, &inputs, /* ... */); // do math that takes a while
        ctx.with_tx(|tx| {
            write_tick_outputs(tx, /* ... */);
        });
        ctx.sleep_until(procedure_runtime::next_tick_target(ctx.timestamp, PHYSICS_INTERVAL));
    }
}

this setup can speed up physics by over 1000x compared to rebuilding the physics world each tick inside a reducer and the expensive calculations don't block other reducers while it is running.

  1. website-features added the feature-request label Jun 4, 2026

Boost this Request

Reopen this request?

The request will return to its prior live status.

Mark as Duplicate

Pick the request that endless procedures is a duplicate of. Energy rolls up into that request and GitHub closes the linked issue as a duplicate with a timeline reference to the canonical.

Unmark Duplicate

Restore as an independent request. The linked GitHub issue will be reopened and its duplicate-of relationship cleared. The original timeline entries stay as history; the note below is posted as a follow-up comment.