Unblock chains

How to set up complex chains of events

Chain of events

Hexen II offers a wide range of powerful entities, allowing mappers to express all their creativity, build complex mechanisms and obtain spectacular in-game outcomes. The vanilla game is packed with diplays of bravura: the opening of Loric's tomb, the giant statue falling down in tower - Tower of the Dark Mage, the initialy empty room in keep1 - Eidolon's Lair suddenly filled with a mezzanine, stairs and columns, etc.


Youtuber Degorram disconcerted by the fancy tomb opening scripting

Such settings may not necessarily be as complex as they seem (the best advice I can tell is study them and study them again — Bsp2mph2 is there to help you decompile Raven's maps). Yet as you'll try to script some nice looking sequences on your own, you may end up with many small parts and wonder how to tie them together.
This article is all about getting started with the basics...

Nota bene Whenever words like "script", "scripted", "scripting", etc. are used on this page, they each time refer to something made out of Hexen II entities in TrenchBroom. No writing of any code (HexenC) is required. So here "scripting" things just means putting entities in the map and setting their properties.

Trigger_relay

If there's only one to remember it's trigger_relay. Its job is pretty simple: when it's triggered, it triggers its own targets in turn. Simple but essential because it's how one single action can trigger a whole set of entities with different targetnames.

E.g.:
  • An initial trigger points to target "t1".
  • 3 trigger_relays share the targetname "t1" and point to targets "t2", "t3" and "t4" respectively.
  • So when the initial trigger is fired, thanks to the relay mechanism "t2", "t3" and "t4" are fired.
The technique allows targets to be pointed at by several relays and take parts to more than one events chain if needed. You can also have relays calling relays calling relays, etc. like the feature image on top of this page demonstrates.

A few interesting properties:

trigger_relay
delay Once the trigger has been fired, how long (in seconds) it waits before firing its targets
wait Once the trigger has been fired, how long (in seconds) it waits before being able to be fired again (please notice the nuance)
messageAn optional text printed in the middle of the player's screen upon the trigger's targets firing

Actually there's nothing you can do with a trigger_relay you wouldn't be able to do with a trigger_multiple entity as well. The difference revolves around the trigger_multiple being a brush entity, contrary to the trigger_relay which is a point entity. Both have their use, which is generally not the same:
  • trigger_multiple is defined by its shape within the 3D world and triggers things when the player enters its volume/touches it.
  • trigger_relay has no dimension and cannot be touched. It isn't self-sufficient and needs to be fired by something else, to start with.
Both are tailored for distinct needs. Nothing keeps you from using a trigger_multiple as a trigger_relay, provided that you either place it out of the player's reach or check its spawnflags 1 ("No touch"). But drawing a brush and remembering that spawnflags setting is an inconvenience trigger_relay saves you from.

mess Time for a digression about long sequences now... Click on the emoji to collapse this section if you prefer to pass.
Usually when the player triggers something, the triggered event is pretty simple and takes relatively no time: a door opens, a platform moves, stairs raise, etc. But on some occasions the chain of events triggered may take a bit longer because it involves several sub-events happening in sequence.
Let's have a look at that memorable puzzle in Portal Of Praevus:


Dego is awed by the scripting possibilities of Hexen II!

Obviously there are several sub-events involved here:
  1. The view switches to camera mode.
  2. The gears stop rotating.
  3. The view switches to a second camera.
  4. The Wheel of Time stops rotating.
  5. The wall's "paddle wheel" brings in the Jewel of Buddha.
Each step must be realized in due time. Failing to carefully respect the right timing/order would screw up the whole. Obviously the delay propery (not only found on trigger_relay but on many entities as well) will help positioning each action on a timeline whose zero point corresponds to the time when the player fires the initial trigger (here a sliding lever).
In a similar situation, there might be more actions to perform and each of them might take longer. If so, and if each of them is time positioned in relation to the zero point, when as a mapper you'll be testing the sequence you'll have to trigger it from start because the start is the key to everything afterwards. Unless it takes really few iterations to set up things properly, after just a few of them it might become boring and time wasting to just see the whole sequence again and again.
The trick is to define multiple "zero points" inside the sequence for each key moment with a corresponding targetname, in order to make sub-sequences. The player will trigger the initial lever only and see the whole smoothly flowing from one key moment to the next. But you mapper will also be able to directly trigger any individual key moment as well thanks to a "debug trigger" which won't be included in the final release. For example, in the sequence above you might focus on the "paddle wheel" thing without having to watch the gears and wheel stopping each time.
From the previous explanations you should see how trigger_relay allows that very easily.

· · · End of digression · · ·

trigger_message_transfer

This trigger is a tricky Hexen II innovation which is not so easy to properly figure out at first, yet is extremely handy for complex puzzles. What is does it that upon being fired, it changes its activator's target to its own target (without firing it). As usual triggers, it also supports a message property to print a text when fired, but it's a totally optional and secondary feature which shouldn't have decided the name of this trigger. Calling it trigger_transfer would have been enough, and we'll concentrate on the "transfer" part.

Let's have a last time Degorram be our guide to introduce an eloquent illustration of it:


Thysis' worst crazy-driving puzzle (dead heat with the buggy "Eyes of Horus" chessboard)

What's remarkable is that each time the button is pressed, the outcome is different. The difference here seems to be only a different text printed out, but it could be anything (for example a statue rotating on its base towards a new direction and sending the "Finger of Buddha" beam trigger a new mechanism, like in Wheel Of Karma).
What basically happens behind the scene is that thanks to relaying the button triggers both the wheel and a trigger_message_transfer (let's call it A) which changes its activator relay's target to the next trigger_message_transfer (let's call it B). Next time the button is pressed, it will triggers the wheel and B. Then the time after the wheel and C, and so on until it has gone full circle back to A.

message_transfer demo

The diagram above shows a simplified version of how it's set up at design time then what actually happens in-game. We can imagine that A issues a message about Taurus, B about Isis and C about Aries. We could also imagine a variant where not only a message is printed out but some brush entities also move. E.g. there could be 3 doors called A, B and C; the set up above would then result in door A opening upon first button press, then door B upon the next press, then door C...

Caveat The Thysis puzzle featured in the video is especially well designed as the rotation of the wheel and the message make pretty clear to the player that they advanced just one step on the zodiac... which has twelve of them, as everybody knows. Without even thinking about it, the player will naturally be prone to pressing the same button again to advance further.
So they should probably not notice how unusual it is in Hexen II that pressing the same button gives different results each time. Yet it is. And that's something you should always be careful about because if the setting is not as well-thought as the Thysis' one, players may be stuck because they have just no idea that they need to press again a button they already pressed previously. I had bad feedback for that reason about Wheel Of Karma's Pit map and that forced me to make the player spawn in front of signposted directions about multi-use buttons. I wish the map design was self-explanatory and that wasn't needed but eh.

Want to ask for clarification, report an issue with this trick or propose another one? Drop me an email If you use the trick please credit me and put a link to this website.