Skip to content
Documentation

Events and Actions

An Event describes when a Logic handler runs. A Mode owns the connected Action sequence. Follow the connections when reading the order, even after moving blocks. An unattached Action stays outside that sequence.

Choose the Right Trigger

Event Use it to
Create Initialize a newly created live instance.
Step Update a live instance’s ongoing behavior each frame while the game runs.
Command Pressed or Released Respond when a Button Command matches its press pattern or is released.
Collision Enter or Leave Respond when contact starts or ends.
Alarm or Recurring Timer Run an Alarm once, or repeat work with a Recurring Timer.
UI Activated React to UI activation.

Choose Command Pressed for a Button Command’s configured press pattern. Use Step for ongoing checks. The Event reference describes each trigger and its filters.

Check One Connected Handler

Attach the 2D Logic Component Event Wiring Diagnostics to one active World Marker placement for this example. Keep one enabled attachment for this check.

Keep the playtest stopped while editing, then start a fresh Debug Play session after saving, so the running instance receives the newly authored Action sequence.

  1. In the Logic Editor, search the Action List for Create. Click the Create Event. The canvas shows a Create block connected to Mode 1.
  2. Click Mode 1 to select its sequence. Search the Action List for Print Debugger Message and click the Action. Right-click an unattached block to open its context menu, then choose Connect to Sequence to add it.
  3. Click the Message slot, enter First native diagnostic, then press Ctrl+Enter. Set Category to Event wiring the same way. Choose Warning in Type.
  4. Select the first Action, then add another Print Debugger Message after it. Set Message to Second native diagnostic, Category to Ordered actions, and Type to Info.
  5. Follow the connections from Mode 1 through both Actions to End. Save the project.
  6. Choose Debug Play, then open Console in the Debugger. Expect First native diagnostic as a Warning in Event wiring, followed by Second native diagnostic as Info in Ordered actions. Choose Stop afterward.

Check the selected Mode before adding Actions to another Event. Its toolbar identifies the Event. Selecting a new Event while an older Action remains focused can leave additions in the older sequence.

Use the matching Message and Category together to identify each diagnostic, since the Debugger also reports startup information alongside messages printed by your authored Actions.

Check Console filters for missing entries.

Extra entries can come from repeated Events, additional owners, or duplicate attachments. Check the Event and attachment before changing the Action values. The Console messages establish execution order; they do not display a live instance identifier.

Event Wiring Diagnostics
Owner: World Marker
Create → Mode 1

  1. Print Debugger Message
    Message
    First native diagnostic
    Category
    Event wiring
    Type
    Warning
  2. Print Debugger Message
    Message
    Second native diagnostic
    Category
    Ordered actions
    Type
    Info

End

Logic card made from the saved project. The saved sequence runs from Create through these two Actions to End.

Target the Running Owner

Self is the live owner of the running Logic attachment. For an Action with Applies To, choose Attached Object > Self to address that owner.

The same Logic can be attached to different Objects. Each attachment runs for its own live owner. Test one attachment first. Add other owners after the expected messages appear.

For a named message sent to several owners or one selected owner, see Custom Events.

Read Typed Event Fields and Action Results

Build the broadcast check in Custom Events first. Keep both receiver attachments enabled and the sender on World Marker. Stop the playtest before editing.

The receiver can read who sent the Event. Another Action can check whether its own owner exists, then pass that Boolean result to a later Action.

Read the Sender’s Object

  1. In Custom Route Receiver, select the docsPulse Mode. Change its existing Print Debugger Message: enter Participant {event. in Message, then press Alt+Down Arrow. Choose otherName, labelled Other Object, from the typed list, add the closing }, then press Ctrl+Enter.

Read a Named Boolean Result

  1. Add Check Exists after that diagnostic and connect it to the sequence. In Applies To, choose Attached Object > Self.
  2. Name this result existsProof in Variable Name on the producing Action.
  3. Select the same Mode, then add and connect another Print Debugger Message after Check Exists. Enter Named Boolean {existsProof. in Message, then press Alt+Down Arrow. Choose value, labelled Value · Boolean. Add }, then press Ctrl+Enter.
  4. Follow the connections from the participant diagnostic through Check Exists and the Boolean diagnostic to End. Save, then start a fresh Debug Play.

Expect two Participant World Marker messages and two Named Boolean true messages. The docspulse receiver stays silent. Choose Stop afterward.

Other Object identifies the sender’s reusable Object definition. The participant fields distinguish Other Instance from the authored Placement ID, which can be blank.

Keep the producer earlier on every applicable path. Results from another Event or an unattached block are outside this sequence. Store a needed value in a declared Variable when you want to read it during another Event.

See expressions for typed field entry and control flow for branches and loops.

Read Optional Fields Separately

An optional blank has the meaning defined by its Action. Read the field description first. In Set Velocity, a blank axis preserves its current velocity. Entering 0 stops that axis.

For example, set X to 4 and Y to 6 on Self. In a later connected Set Velocity, leave X blank and enter 0 for Y. After the second Action runs, X is still 4 and Y has become 0 on the same owner.

Myth Engine Documentation