Icesus Mudlet Triggers: Safe Trigger Sets, Rules, and Momentums

Mudlet triggers are excellent for Icesus when they make text easier to read, preserve useful lines, and reduce routine typing while you are actively playing. They become a problem when they play the character for you. Icesus has explicit trigger and robot rules, so a good trigger setup starts with those rules, not with clever Lua.

Browser Client or Mudlet?

The Icesus browser client already has basic trigger support. Its trigger editor uses a simple pattern => command format, supports up to 25 triggers, stores/syncs them through Icesus client GMCP, and rate-limits firing. It is intentionally simple: substring matches, short patterns, short commands, and no Lua. That is enough for small active-play conveniences.

Mudlet is the better choice when you want named folders, regex triggers, highlights, sounds, mini-windows, logging, GMCP event handlers, and per-character packages. Use the browser client as the safe baseline and Mudlet when you want the larger workshop.

What Icesus Allows

The in-game trigger help lists the categories that are allowed. Keep your Mudlet setup inside them unless an admin tells you otherwise.

What Not to Build

• No unattended hunting, fishing, farming, healing, movement, or combat.
• No unidle triggers.
• No triggers that react to another player saying or doing something by sending commands.
• No corpse-looting triggers.
• No trigger that automatically uses combat momentums.
• No channel spam, party spam, or public-command loops.

If you are unsure whether a script counts as a robot, do not use it. That is not just cautious advice; it is the spirit of help robots.

Understand Combat Momentums

Icesus combat can produce short-lived combat momentums: temporary opportunities to perform a combat maneuver instantly. The combat help describes a short window where you can type a command such as use strike before the opportunity fades. The same help and trigger help are clear that using triggers to perform combat momentums is strictly forbidden.

The browser client handles this correctly: it can show manual momentum buttons from GMCP, and the player chooses whether to click them. For Mudlet, the safe design is the same. Show the available momentum. Highlight it. Play a subtle alert. Put it in a status label. Do not fire use <momentum> from a trigger.

Trigger Organization That Scales

Build trigger sets as folders. Do not keep every experiment in one flat list. A practical Icesus Mudlet profile might use:

• 00 Rules / Disabled: notes, examples, and old triggers that must not run.
• Communication: tells, says, party, guild, sales, and important channel highlights.
• Vitals and Status: hunger, thirst, drunk, bleeding, stunned, sleeping, low HP/SP/EP, magical weakness, encumbrance.
• Combat Readability: critical hits, spell success/failure, defensive warnings, enemy shape changes, combat start/end notices.
• Party Tools: party report highlights, placement reminders, leader/follower/LD/dead indicators.
• Class or Guild Role: separate folders for melee, tank, caster, healer, ranger/outdoors, crafter, or whatever your character actually plays.
• Quest Notes: copy-only triggers that send suspicious lines to a mini-console or notepad.

Class and Role Trigger Sets

Icesus classes are guild-driven, and serious characters often have different jobs in different parties. Think in role sets, not one universal "combat package."

Melee and Tank Sets

For melee characters and front-line party roles, useful safe triggers usually highlight state and danger: low HP, bleeding, stun, sleep, being unable to defend, defensive effects dropping, enemy shape changes, party position changes, and momentums. Use aliases for combat point assignment, such as ba for battle -a attack; do not make a trigger decide when to change your whole combat plan. Momentums are display-only. Do not auto-use them.

Caster and Priest Sets

Spell users benefit from clear casting feedback. Highlight spell success, failure, interruption, low SP, magical weakness, and phase-relevant messages you care about. Use aliases for deliberate spell repetition, such as a Mudlet alias as <target> that sends cast arrow of steam at <target>, using the exact spell from your guild and current setup. If you use GMCP, Char.Casting can show progress without scraping text. Do not build a healer that automatically reacts to another player's speech or damage messages; Icesus rules explicitly reject actions triggered by someone else saying or doing something.

Ranger, Outdoors, and Utility Sets

Outdoor and utility characters often care about travel, terrain, camp, tracking, skinning, inventory, and resource text. Highlight useful output and log it. Do not create unattended hunting/fishing loops. The rule text calls those out directly.

Crafter Sets

Crafting repeaters are one of the allowed trigger categories, but treat them as active-work tools. Keep them in a disabled-by-default folder, name them with the craft they support, and include a visible on/off echo when you enable them. Do not leave a crafting repeater running while you are away from the keyboard.

Party Leader Sets

Party leaders need signal, not noise. Highlight role changes, missing followers, linkdead players, stunned/sleeping/wounded flags, and party reports. Mudlet can also build a party grid from GMCP; see the Icesus GMCP guide for the cleaner way to do that.

Writing Robust Mudlet Triggers

Use substring triggers for exact, stable phrases. Use regex only when part of the line varies. Anchor regex patterns with ^ and $ when you can. Build from copied Icesus log lines, not memory.

Good pattern habit:
^You are (hungry|thirsty)\.?$

Bad pattern habit:
.*you.*

Use Mudlet's echo or replay tools to test. A trigger is not done until you confirm that unrelated lines do not fire it.

Concrete Icesus Trigger Examples

Help living documents the food and drink messages as You are hungry. and You are thirsty.. These are good examples because the wording is stable, short, and personal to your character.

In the browser client's simple trigger editor, the same ideas can be written as:

You are hungry. => eat meat
You are thirsty. => drink water

In Mudlet, create two exact-match regex triggers:

Pattern:
^You are hungry\.$

Script:
send("eat meat")

Pattern:
^You are thirsty\.$

Script:
send("drink water")

Adjust the command to the food or container you actually carry. If your character uses bread, use eat bread. If you keep water in a flask and the command differs, use that exact command. Test this while actively playing and keep a raw log so you can see what the client sent.

For combat and guild abilities, prefer aliases over broad triggers until you know the exact success/failure lines. Examples: ba sends battle -a attack, bc sends battle -a casting, as rat sends cast arrow of steam at rat, and a skill alias can send the exact use ... command your guild uses. The allowed trigger category is repeating skills/spells in combat when they go off or fail; do not turn that into target selection, movement, looting, healing, or unattended fighting.

Safe Highlight Examples

For lines beyond documented help examples, copy the real wording from your own log and match that.

• Highlight tells and party messages in colors you can read.
• Highlight hunger, thirst, drunk, bleeding, stun, sleep, and encumbrance messages.
• Highlight spell failure and spell completion lines for your current guild.
• Highlight combat start/end and enemy shape changes.
• Copy NPC speech, quest-like instructions, and unusual object text into a separate Mudlet window.
• Highlight "momentum available" lines or GMCP-derived momentum labels, but never send the momentum command automatically.

When to Use GMCP Instead

Text triggers are still useful, but Icesus now exposes a lot of structured client data. The browser client uses GMCP for vitals, max stats, character status, room info, party info, casting, cooldowns, screen reader mode, hotkeys, triggers, game time, and server status. In Mudlet, GMCP is usually better than scraping text when the data exists. Use text triggers for human-readable prose and GMCP for state.

A Good First Trigger Week

1. Session 1: no triggers except logging. Collect real output.
2. Session 2: add communication highlights and status warnings.
3. Session 3: add class-role highlights, still no command-sending triggers.
4. Session 4: add party readability tools and confirm they do not spam.
5. Session 5: decide whether any allowed repeaters are worth the complexity. Keep them disabled by default.

Maintenance Habits

• Name triggers for what they do: Highlight stunned status, not stun1.
• Put every command-sending trigger in a role folder with a clear warning in the name.
• Export your profile before large edits.
• Disable old class/guild triggers after reincarnation or role changes.
• Keep a raw log so you can audit what your client actually did.

Play Cleaner, Not Absent

A good Icesus trigger setup makes you more aware. It does not replace your judgment. If the client is deciding where to move, when to fight, when to heal, when to loot, or when to use momentums while you are not actively making the decision, you have left "quality of life" and entered rule trouble.

Related Guides

• Mudlet Setup for Icesus
• Icesus Mudlet GMCP
• In-game help: triggers
• In-game help: robots
• In-game help: combat and momentums
• Try the browser client