net builder detail (Net Builder)

NET Builder Authoring (Staff/Builder)

Builders can author NEW NET content -- external topology, hosts,
sections, directed passages, passive ICE, Hostile ICE, accounts, Data
Vault designation (including retention and paid storefront), software
content variants, and hardware spawning -- entirely through in-game
commands. No Python editing is required for this content. Everything
created this way survives a Server reload/restart.

STABLE IDS vs DISPLAY NAMES
    Every piece of content has a machine-stable ID (used in commands)
    separate from its player-facing display name. IDs never change
    once created; display names can be edited freely.

EXTERNAL TOPOLOGY vs HOST
    The external NET (Z-plane coordinate space, Nodes, ingresses,
    gateways) is built with @nettopo. A HOST is the internal
    section-set (Login, CPU, Data Vault, ...) attached to one Node,
    built with @nethost. A Node must exist before you can attach a
    host to it.

PERMANENT ROOMS
    Each host section is backed by one real, permanent Evennia Room --
    created (or reused) by @nethost/reconcile. Builder-authored
    configuration is just DATA; reconcile is what turns it into an
    actual walkable place.

DIRECTED BOUNDARIES -- CRITICAL
    A passage between two sections is DIRECTIONAL. A -> B and
    B -> A are two completely independent boundary records, each
    with its own required access level, passive ICE, Krunch grant,
    ICE repair threshold, and Hostile ICE. Creating one direction
    NEVER creates or affects the other. This is deliberate: a corridor
    can be wide open walking IN and heavily defended walking OUT.

PASSIVE ICE vs ICEB SOFTWARE
    Passive ICE (@netice) is the boundary's own static defense --
    a configured strength value. ICEB cyberdeck programs (Chipper,
    Rhino, Krunch, etc.) are what a RUNNER uses to bypass, disable, or
    destroy that defense. They are not the same thing.

HOSTILE ICE (HICE)
    A HICE (@nethice) is a construct that CAN spawn to defend one
    specific directed boundary -- attach it with @nethost/hice.
    Like passive ICE, it is coupled to ONE direction only; the reverse
    passage never inherits it.

HOST ACCOUNTS
    @nethost/account-add creates a real login account on a host.
    Access level 0 is a completely LEGAL authenticated account -- it
    is never treated as "no account".

DATA VAULT DESIGNATION
    @nethost/vault-set marks which ONE section of a host is its
    Remote Data Vault (where help remote/help download/
    help upload operate). The area must already exist on that
    host.

DATA VAULT RETENTION (persistent vs consume-on-download)
    Every vault has a DEFAULT retention policy set with
    @nethost/vault-retention <net>/<host> = <policy>, where policy
    is persistent (the remote file survives download -- default,
    matches every pre-existing vault) or consume_on_download (the
    remote file is removed, but ONLY after a download/purchase
    actually succeeds -- never on a failed attempt). Any single stored
    file can override the vault's default with
    @nethost/vault-retention <net>/<host> <file#> = <policy>.

PAID DATA VAULT (storefront)
    A vault becomes a storefront by giving it a seller:
    @nethost/vault-seller <net>/<host> = <economic_account_id>
    (the account must already exist -- it is never silently created).
    Then price individual files with
    @nethost/vault-price <net>/<host> <file#> = <price|free>. A
    priced file is refused by the ordinary help download command
    (which never silently charges anyone) -- players use help buy
    instead, which validates funds, transfers credits through the
    canonical economy service, then downloads. A failed purchase
    (insufficient funds, missing seller) charges nothing and never
    consumes a one-shot entry. @nethost/vault-add seeds a file
    directly (software or text); @nethost/vault-remove deletes one.

@NETSOFT -- software content variants
    @netsoft/clone <new_id> = <existing_id> creates a new software
    definition by cloning an existing one, then
    @netsoft/set <id> <field> = <value> tunes SAFE fields only
    (display_name, source_name, storage_size, base_effectiveness,
    running_speed, copy_difficulty, notes). You can NEVER invent a new
    mechanic this way -- a clone inherits its source's behavior_id
    (the stable MECHANICAL identity that selects a real runtime
    adapter, separate from software_id, the stable CONTENT
    identity) unchanged by default, and @netsoft/set <id> behavior =
    <behavior_id> may only repoint it to another ALREADY-REGISTERED
    behavior -- never an arbitrary string, path, or callable.
    Every currently implemented software mechanic in this catalog is
    now migrated to the behavior registry -- clone ANY existing
    program and it genuinely runs for its real effect, under your
    clone's OWN software_id and display name, exactly like storing/
    trading/selling it already works. @netsoft/show reports
    "Executable: yes" and "Builder Cloneable: yes" for every current
    source. New content using an already-registered mechanic is
    builder-authorable this way; a genuinely NEW mechanic still
    requires a programmer to implement and register it.

@NETHARDWARE -- hardware index
    Read-only list/show/spawn over the EXISTING donor cyberdeck
    hardware catalog and its matching Item prototypes. Never a second
    hardware system. @nethardware/list [family],
    @nethardware/show <source_id>, @nethardware/spawn <source_id>.

@NETHOST/CHECK -- validation
    @nethost/check <net>/<host> is a READ-ONLY report that flags:
    duplicate boundary IDs, boundaries referencing missing areas,
    negative access/Krunch/ICE-repair levels, out-of-range SurfStream
    difficulty, areas with no permanent Room yet, a Data Vault
    referencing a missing area, priced files with no configured
    seller, and a configured seller account that no longer exists. It
    never assumes every route must be bidirectional -- a one-way
    passage is not itself a problem.

STAFF DEBUG / RESET CONTROLS (Builder-only, never player-facing)
    @nethost/ice-state <net>/<host> <boundary_id> inspects a
    boundary's disabled/destroyed protection flags.
    @nethost/ice-disable / /ice-destroy explicitly set those
    flags for testing; /ice-restore clears both. /hice-state
    inspects whether Hostile ICE is currently active on a boundary and
    its remaining strength; /hice-reset despawns/clears it. These
    all use the existing state APIs -- never raw Attribute mutation.

VALIDATION / RECONCILIATION
    @nethost/reconcile creates any missing permanent Rooms for a
    host's currently configured sections. It is safe to run repeatedly
    (idempotent) and never deletes anything.

QUICK EXAMPLE
    @nettopo/create test_net = Builder Test Network
    @nettopo/plane test_net 1 = Public NET | 0,20,0,20
    @nettopo/terrain test_net 5,5,1 = lane
    @nettopo/terrain test_net 1,1,1 = lane
    @nettopo/node test_net/corp_test = 5,5,1 | Test Corporate Host
    @nettopo/ingress test_net/default = 1,1,1 | Test Entry

    @nethost/create test_net/corp_test = Test Corporate Host
    @nethost/area-add test_net/corp_test cpu = CPU

    @nethost/connect test_net/corp_test login_to_cpu = login -> cpu | east
    @nethost/connect test_net/corp_test cpu_to_login = cpu -> login | west
    @nethost/access test_net/corp_test cpu_to_login = 200

    @netice/create wall_2_0 = Wall 2.0 | 250
    @nethice/create queen_spider = Queen Spider 1.4 | 200
    @nethost/ice test_net/corp_test cpu_to_login = wall_2_0
    @nethost/hice test_net/corp_test cpu_to_login = queen_spider

    @nethost/account-add test_net/corp_test guest = 0 | guestpass
    @nethost/vault-set test_net/corp_test = cpu

    @nethost/reconcile test_net corp_test
    @nethost/check test_net/corp_test

For a complete step-by-step build of a small corporate host from
nothing, see help net builder tutorial.

See also: help @nethost, help @nettopo, help @netice,
help @nethice, help @netsoft, help @nethardware,
help buy

---