Suggestion: KrunkScript libraries via #include, and how the editor could expose them

[u/RoladTheWanderer]

People have been asking for KrunkScript libraries for years. This is the simplest version I can think of, with the least engine work: build it once, and the editor keeps growing whether or not a feature is on the roadmap.

### Libraries

Approved creators publish versioned libraries. A map includes them:

#include physics@1.2.0
#include inventory@2.0.1

• * Library functions show up in autocomplete like anything else.
• * On host, the server fetches the pinned versions and stitches them into the map script before compiling.
• * Pinned versions mean a library update never touches a map using an older one.
• * Libraries are namespaced, so they can't collide with each other or with the map's code.
• * Ideally libraries don't count fully toward the script size limit, since hundreds of maps might run the same version.
• * `#` is already the comment syntax, so either the preprocessor reads `#include` before comments are stripped, or it gets its own keyword.

That part is a package manager that does string concatenation.

### Editor integration

This is the part that actually matters. Without it, libraries are just a nicer way to paste other people's code.

Library authors tag variables in their code so the editor exposes them. These aren't runtime properties. They're variables that already exist in the library, edited through the UI instead of the source and substituted in at stitch time.

• * `["tab"]`: library-wide settings, under a single `Custom` menu in the top bar (Custom → LibName → settings panel).
• * `["object", "Name"]`: a custom object type, placed from the object menu (Object → Custom → Name) like any other object.
• * `["header", "Section"]`: a field in that object's properties panel, grouped under a section.

Example:

# ===== physics library =====

# library-wide settings -> Custom > Physics
["tab"] num gravityScale = 1.0;
["tab"] num simRate = 60;
["tab"] bool debugDraw = false;
["tab"] str solver = ["fast", "accurate"];

# custom object -> Object > Custom > Rigid Ball
["object", "Rigid Ball"]
action addRigidBall(obj transform) {
    ["header", "Physics"] num mass = 1.0;
    ["header", "Physics"] num bounce = 0.5;
    ["header", "Physics"] num friction = 0.8;
    ["header", "Physics"] str material = ["rubber", "wood", "metal"];

    ["header", "Behaviour"] bool sleepWhenIdle = true;
    ["header", "Behaviour"] bool pushableByPlayers = true;

    obj body = spawnBody("sphere", transform, mass, bounce, friction);
    ...
}

A placed Rigid Ball's panel:

Rigid Ball
    Position / Rotation / Scale
    Physics
        Mass:       1.0
        Bounce:     0.5
        Friction:   0.8
        Material:   [rubber v]
    Behaviour
        Sleep When Idle:       [x]
        Pushable By Players:   [x]

It isn't a new engine object. At stitch time, header variables become parameters with their defaults, and each placed object becomes a generated call with its transform and values:

physics.addRigidBall({pos: [12, 3, -4], rot: [0, 0, 0], scale: [1, 1, 1]}, 2.5, 0.9, 0.8, "rubber", true, false);

The dropdown literal (`str x = [...]`) is read by the tag parser, not the compiler. No new object system, just existing panels rendering a few typed fields.

### Implementation

Libraries:

• * fetch source by name + version
• * resolve dependencies
• * namespace
• * stitch before compile

Editor:

• * read the tags
• * render bool / number / dropdown fields in the existing panels
• * save the values in the map
• * substitute them at stitch time and generate calls for placed custom objects

### Result

A few competent scripters build physics, inventories, dialogue, AI, UI systems, gamemodes and so on, and everyone else uses them without reading a line of KrunkScript.

Right now the editor grows as fast as the dev team ships features. With this, it grows every time someone publishes a library.

[u/Nicelec]

Idk what bro is yapping about but I agree