TinyMUX

Decompile and Portability

Softcode

Decompile and Portability

Moving softcode between objects, between databases, or between entirely different MUSH servers is a routine part of development. TinyMUX provides several built-in commands for extracting, copying, and editing code, and understanding their behavior is essential for anyone who maintains non-trivial softcode.

@decompile

The @decompile command outputs the sequence of commands needed to recreate an object. Rather than showing the internal database representation, it produces human-readable @set, @lock, @describe, and attribute-setting commands that, when pasted into a client, would rebuild the object from scratch.

@decompile <object>[/<attr>] [=<newname>]

If you specify a <newname>, the output uses that name instead of the object’s actual name, and the @create line is omitted. This is useful when you want to load attributes onto an existing object. If you specify <object>/<attr>, only matching attributes are shown; wildcards are accepted, so @decompile me/cmd_* dumps only attributes whose names start with CMD_.

The /dbref switch causes output to reference objects by dbref number rather than name, which is useful when names contain special characters or when precision matters more than readability.

Using @decompile for Backups

A decompiled object is plain text. You can paste the output into a text file, store it in version control, email it, or feed it back into any MUX session to recreate the object. This makes @decompile the standard mechanism for:

  • Personal backups. Before making risky changes, decompile the object to a local file.
  • Code sharing. Post decompiled output on a wiki, forum, or code repository so others can install it.
  • Migration. When moving to a new server or rebuilding after data loss, decompiled text is the portable format.

Because @decompile only shows attributes you have permission to read, wizards typically perform the dump to ensure nothing is missed.

@cpattr: Copying Attributes

@cpattr copies one or more attributes between objects without the intermediate step of decompiling and re-entering text.

@cpattr <obj>/<attr> = <obj1>/<attr1> [,<obj2>/<attr2>,...]
@cpattr <obj>/<wild> = <obj1> [,<obj2>,...]

Wildcards in the source attribute copy every matching attribute to each destination. For example, @cpattr codebox/*=newbox duplicates all visible attributes from codebox onto newbox, preserving their names. If you omit the destination attribute name, the source name is reused.

@mvattr: Moving Attributes

@mvattr renames an attribute on an object and optionally copies it to additional names in a single step.

@mvattr <object>=<old>,<new>[,<copy1>]...

The original attribute <old> is removed and reappears as <new>. Any additional names receive copies. If you lack permission to remove the original (for example, it is a system attribute), a copy is made instead and the original remains.

@wipe: Clearing Attributes

@wipe removes attributes from an object. Without a pattern, it removes all user-settable attributes. With a wildcard pattern, only matching attributes are affected.

@wipe <object>[/<wild-attr>]

Protected and read-only attributes are not removed. Use @wipe with care; there is no undo.

@edit: Modifying Code In-Place

@edit performs search-and-replace on one or more attributes without retyping them.

@edit <object>/<wild-attr> = <search>,<replace>
@edit <object>/<wild-attr> = ^,<text>
@edit <object>/<wild-attr> = $,<text>

The first form replaces all occurrences of <search> with <replace>. The ^ form prepends text and the $ form appends text. Wildcard attribute names are supported, so @edit me/cmd_*=%r,%r%t can fix indentation across an entire command suite at once. Enclose <search> or <replace> in curly braces if they contain commas.

Porting Code Between Servers

MUSH softcode is broadly similar across TinyMUX, PennMUSH, and TinyMUSH, but dialects differ in ways that break code silently. Common portability issues include:

  • Function availability. TinyMUX has functions like strcat(), lattr(), and objeval() that may behave differently or be absent on other platforms. PennMUSH offers functions such as regedit() and json() that TinyMUX may not support in older versions.
  • Delimiter conventions. TinyMUX generally uses commas as default list delimiters. PennMUSH uses spaces for many list functions. Code that omits an explicit delimiter may produce different results on different servers.
  • Flag names. Flag names and letters are not fully standardized. ANSI exists on TinyMUX but not PennMUSH. WIZARD vs. ROYALTY permissions differ. Always check flag availability on the target platform.
  • Substitution syntax. TinyMUX uses %q0-%q9 and %qa-%qz for registers. PennMUSH supports named registers with %q<name>. Code using named registers will not work on stock TinyMUX.
  • Lock syntax. Lock key expressions have server-specific extensions. Test locks after porting.
  • Side-effect functions. Functions like set(), create(), and pemit() are available on most platforms but may have different argument orders or permission models.

When porting, decompile on the source server, review the output for platform-specific constructs, and test on the target server before deploying.

Version Control Strategies

Storing decompiled output in a version control system (Git, Mercurial, or similar) provides history, diffing, and collaboration. A practical workflow:

  1. Decompile each code object into a separate text file named after the object.
  2. Commit the files to a repository.
  3. After making changes in-game, re-decompile and commit the updated files.
  4. Use diffs to review what changed between versions.

This approach is manual but effective. Some developers write automated scripts that connect to the game, decompile a list of objects, and commit the results on a schedule.

Client-Side Tools for Code Management

MU* clients provide features that make code management easier:

  • TinyFugue (tf) supports /quote to upload files line by line, macros for automating decompile-and-save workflows, and logging for capturing output. The /tf switch on @decompile (where supported) formats output for direct use with TinyFugue’s /quote command.
  • MUSHclient offers scripting in Lua, triggers for capturing @decompile output to files, and plugin support for building more elaborate code-management pipelines.
  • Pueblo, BeipMU, and other clients generally support logging and paste-from-file, which covers the basic decompile-edit-upload cycle.

The general pattern is the same regardless of client: capture @decompile output to a local file, edit with a text editor, and upload the modified commands back to the game.

Summary

@decompile is the bridge between the live database and portable text. Combined with @cpattr, @mvattr, @wipe, and @edit, it forms a complete toolkit for managing softcode. For cross-server portability, always review decompiled code for platform-specific constructs before loading it on a different server.