Arguments, defaults, and variadic inputs

An argument is a value supplied to an operation or method. Its label describes the expected type and purpose. A destination/result slot needs a compatible Variable, not an arbitrary literal.

Required, optional, and null

Fill every required slot. Optional inputs may use a declared default, preserve a current property, or have operation-specific omission behavior. Read that operation’s reference rather than assuming all empty slots mean zero.

A supplied Null item is different from omission: it remains null and does not select a default. A non-nullable parameter rejects null. User-defined nullable optional parameters may omit a default and receive null.

For item transformations with optional Item to Change, omission reads the Item already held by the destination Variable. Assign that destination first. Metadata setters copy their source rather than consuming your configured input.

Variadic groups

Variadic means an ordered group of inputs. Copy a value into the Add bundle to append it and expose the next Add bundle. Right-click a configured value to remove it without drops. Larger groups paginate or open an ordered-input editor.

A user-defined variadic parameter must be last. It accepts 1–4,096 values of its declared element type; inside the method it becomes a fresh List<T>. Some built-in plural groups are optional and may be wholly omitted. An optional group and an empty required group are not interchangeable.

Passing mode

Shift-right-click a configured object, List, or Dictionary input to cycle Reference → Shallow Copy → Deep Copy. Ordinary right-click clears it. Replacing a configured input retains its passing choice. Passing belongs to the input, not the Variable item.

This also applies to constructor, class-field, and variadic inputs. See copying and identity before choosing a mode for mutable data.

Numeric and type checks

Integral fields floor before validating their bounds. A slot expecting a count does not round to the nearest integer. Types remain checked even when names look alike. List<Player> and List<Entity> are different invariant collection types.

String inputs may use conversion where supported, while reference bindings remain type-checked. Item-ID Strings are parsed in Item inputs; a text label alone does not construct an arbitrary typed object.