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. |
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. |
button: |
| |||||||||||||
first pot: |
|
|
||||||||||||
second pot: |
|
|
||||||||||||
last pot: |
|
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.