Trigger message transfer

Trigger message transfier

Classname: trigger_message_transfer
Purpose: Making something different happen each time
H2 Code: triggers.hc
Fields Required: target, targetname, message
What this entity does is cause its own target value to be copied back into the target-field of whatever entity triggered it (the copying happens after the other targets triggered by that entity have fired, but before teleport destinations are computed). So you can use it to create effects where some event, such as a button-press, causes something different to happen each time (but only in fixed seqeunce, or a loop (such as the Wheel of Time), or a sequence ending in a loop).

There are probably quite a number of ways this entity can be used, two of them are found in this example, which contains two maps in .bsp and .map formats, and also as a .qme (QuArK) project. The way these examples basically work is that for each entity that is to be targetted in turn, there is a tmt with the same targetname-value, which targets the next entity and tmt in the sequence (except in a non-looping chain, the last entity doesn't need a tmt, and for teleports, there are several complications, as discussed below.

You might also want to look at Eutectic's discussion of the Wheel of Time puzzle, although his account of what the tmt entity does is actually wrong, as also is the discussion in the hc code comments.

Fields

targetname Value is a name, targetted either by the original trigger for the sequence, or the preceeding tmt.
target Value is a name, targetting the next tmt in the sequence, and perhaps the next item to be acted upon.
message Value is a number, indicting the message to be displayed when the tmt fires (QuArK users can instead use a string-valued #message field). This field is REQUIRED, if it is missing, firing the tmt will crash the game. If you want no message to be displayed, set the message-value to one that represents a blank line in strings.txt, such as 139.

Example

Here are the entities for a series of three pots and a button; the first button-press explodes the first pot, the second the next, and the third the last. The button targets the first pot and a matching tmt, which targets the second pot and its matching tmt, which targets the last pot. The last two pots also killtarget the previous tmt's, just to keep things tidy (the Raven coders seem to be pretty consistent about removing entities that can't do any more work).

button:
classnamefunc_button
angle270
targetpot1
first pot:
classnameobj_pot1
targetnamepot1
classnametrigger_message_transfer
targetnamepot1
targetpot2
second pot:
classnameobj_pot1
targetnamepot2
killtargetpot1
classnametrigger_message_transfer
targetnamepot2
targetpot3
last pot:
classnameobj_pot1
targetnamepot3
killtargetpot2

To do a looping door sequence (each button press opens a different (re-closing) door, you would leave out the killtargets, and have the final tmt target the first, instead of having a final entity with no matching tmt.

For teleport destinations, the trigger_teleport will be the main trigger (corresponding to the button), with the info_teleport_destinations being the targets with matching tmt's, but there are two complications. First, for the message display to work right, the trigger_teleport has to be activated. Second, teleports send to the targetted destination after ordinary targets, including tmt's, have been triggered, and the tmt has therefore substituted its own target-value for the original target-value of the teleport. So the first time you go through the teleport, you wind up at the destination whose targetname is the same as the target-value of the first tmt, not the original destination of the teleport. So to keep your sanity, you might want to have the first tmt not matched with any destination, and loop-back to the second tmt.

If all this is as confusing as I think it is, you might want to collect an example, with complete maps and discussion.


Back to the list.