Patch notes

FutureMUD Engine 2.17.0

Adds stacked world-building, flexible item and spell policies, new combat and NPC capabilities, and improvements to descriptions and emotes.

ยท engine · release · building · gameplay · reliability

Requirements: .NET 10 and MySQL 8.0. Framework-dependent packages target Windows x64, Linux x64 and Linux ARM64.

Build across multiple levels

The new terrain stack autobuilder imports complete Terrain Planner maps, including underground levels, terrain, tags and vertical connections. Builders can configure ordinary up/down exits, climbing difficulty, falling and suppressed connections. Compressed exports support editor-based pasting for larger plans.

Use Engine 2.17.0 with Terrain Planner 2.2.0 for complete-stack imports. Planner levels create separate connected rooms; they do not replace elevations within one room. Existing rectangle masks remain supported.

Descriptions and emotes

Character descriptions correctly preserve empty conditional branches, match exact bodypart counts and apply tattoo/scar overrides. Out-of-range count bounds no longer throw during rendering, nested branches preserve obscurer settings, and helper names work consistently regardless of capitalisation.

Optional-target emotes retain their selected branches through saving and loading, including absent targets. Output copies preserve recipient-specific wording and independent assignment dictionaries. Parser improvements reduce repeated work while keeping rendering specific to each viewer.

Configurable items

Item interaction permissions

The new itempermissions component independently restricts pickup, dropping, giving, container placement, sheathing, ordinary room listings and one-handed wielding. These controls retain the item's normal Holdable, Wearable and Wieldable capabilities. Preventing dropping does not prevent putting an item into a container; hiding it from room listings still permits explicit keyword targeting and inventory inspection.

Admins create a component with comp edit new itempermissions, then use comp set restrict <pickup|drop|give|put|sheathe|roomlisting|onehandedwield> to toggle each restriction. Submit and approve the component through the usual review workflow, then attach it to an editable item prototype with item set add <component ID> and submit and approve that item revision. Existing items without the component retain their behaviour. A FutureProg can change a configured live item's saved permissions with setitempermission(@item, "Drop", false); true permits the interaction again.

Pickup-attempt callbacks

An Item Permissions component can run a boolean FutureProg accepting a character and an item when someone makes an actual visible, reachable pickup attempt. Returning true allows the attempt to continue; false stops it. This supports authored reactions to touching or trying to take an object without firing during feasibility checks or silent scripted loading.

While editing the component, use comp set attemptprog <prog|none> to bind or clear the callback. comp set attemptonce toggles a one-shot callback whose used state is saved with each item.

Temporary-item retirement

The new transientitem component removes configured items at lifecycle boundaries rather than after a timer. Admins start with comp edit new transientitem, configure it, then submit, approve and attach it using the same component workflow. New components retire items on database reload and inventory logout by default; comp set reload and comp set logout toggle those settings. Initial item creation does not trigger reload retirement.

Use comp set trigger <BulkDrop|EtherealTransition|TransientBodyDeath|HostBodyChange> to toggle explicit retirement events. comp set plane <name|ID|any> can limit ethereal-transition retirement to a destination plane. BulkDrop applies to drop all. The supernatural body-death and host-change events require an authored retirecarrieditems(@character, "TransientBodyDeath") or retirecarrieditems(@character, "HostBodyChange") call; ordinary deaths and body changes do not invoke them automatically. Those calls affect eligible carried items, excluding worn and wielded equipment.

Applying saved item effects

The glow, hum, magical aura and detection controls below are saved effects on individual items, applied through FutureProg. They do not require an Item Permissions or Transient Item component.

For example, create a prog with one Item parameter and an Effect return type:


prog edit new item_glow
prog set parameter add item item
prog set return effect
prog set text

Enter this body in the editor, then finish with @ on its own line:


return applyitempresentationeffect(@item, "glow")

Use prog execute <prog> <item> to apply it to an existing item. To apply it when instances of an item prototype load, edit that prototype and use item set onload <prog>, then submit and approve the revision. Substitute the function call described below for another effect. Reapplying the same glow, hum or magic mode reuses the existing effect rather than stacking duplicates.

Descriptive glow

applyitempresentationeffect(@item, "glow") adds a glowing description and short-description marker. It supplies no illumination, so it does not brighten a dark room or replace a light-source component. Admins can use it for an object's visible presentation independently of its actual light output.

Audible humming

applyitempresentationeffect(@item, "hum") adds a humming marker and audible description for viewers able to hear it locally. It respects hearing restrictions, including deafness, and does not propagate sound between rooms. Multiple humming items carried or worn by a character can also produce a combined humming description, with covered equipment contributing less.

Intrinsic magical aura

applyitempresentationeffect(@item, "magic") classifies the item as intrinsically magical for magic-detection systems without attaching a sustained spell. It does not grant spell powers or make the item glow. Admins can remove this classification with clearitemmagicaura(@item) without dispelling other active effects; this removal function returns Boolean rather than Effect.

Detection-dependent visibility

adddetectionvisibilityeffect(@item, "VisualMagical", 0) hides an item visually unless the viewer has the specified native detection capability. The sense argument can contain alternatives, such as "VisualEthereal, SenseEthereal"; any listed capability satisfies that requirement. Replace 0 with an existing plane ID to also reveal it to viewers present on that plane.

These controls affect visibility without moving the item to another plane or changing physical reach, container rules or handling permissions. Different detection requirements compose, so applying several distinct requirements can make an item harder to reveal.

Spell materials and summons

Casting plans support materials that must be present but remain unconsumed, optional materials and conditional requirements. Named summoning choices can specify templates, tokens, casting grades, control checks and temporary lifetimes. Existing item and casting definitions retain their defaults until these policies are configured.

Combat and NPC behaviour

Ranged weapon types can define separate pain and stun bonus expressions. A saved, configurable effect provides flat physical damage and stun absorption for reusable profiles.

NPC disposition memories support liking, hatred and fear during the current server session, alongside pursuit-focused tracking behaviour. Stable services can also represent stays with an unknown depositor and an opening balance.

Separate content products

Stock item catalogues are installed through the optional FutureMUD Item Seeder. Armageddon setting content and the historical Worldfile installer have moved into their own separate product. Interested parties should contact Japheth for information about the Armageddon product.

Upgrading

MySqlConnector is updated to 2.6.1 to address GHSA-473q-m89c-ghf8, a password-disclosure issue in certain TLS authentication configurations.

This release includes database migrations for stable stays and ranged-weapon secondary damage. Back up the database, configuration and external files, stop the old engine, and rehearse the normal managed upgrade and a cold restart against a copy of the world before reopening it.

The upgrade serializer audit also recognises saved item presentation, intrinsic magical aura and detection visibility effects. Their payloads are preserved, including plane IDs that must not be treated as historical room references.

Use Database Seeder 3.9.0 for the matching schema and foundations. New optional gameplay policies require configuration; upgrading alone does not enable them throughout an existing world.

Use /downloads for packages and checksums and /getting-started for installation requirements.