Dungeon Master Forum

Hello,

Is it possible to add the "party facing" check to trigger_controller ?

I know this is redundant with the trigger option, but I see at least one interesting use for this:
- If I have a lot of triggers, with effects depending on the direction, I can set them to fire for any facing, and go through 4 trigger_controller, instead of having 4 times as many triggers.

In this vein, most is_opby(...) checks could be added to the trigger_controller in order to let more freedom to the design of mechanics in ESB.

I don't know if this really makes sense.

Joramun wrote:Is it possible to add the "party facing" check to trigger_controller ?

Yes, I'll do this.

Another interesting use is if the trigger isn't activated by the party at all, but you still want to check the party's facing for some reason or other.

Joramun wrote:In this vein, most is_opby(...) checks could be added to the trigger_controller in order to let more freedom to the design of mechanics in ESB.

Sort of. Trigger controllers are activated by messages, not by clicks etc., so they aren't really opby anything, you know? It might not make a whole lot of sense in practice. I guess I could put in some stuff related to the operating instance, if that would help.

Resurrecting this old thread to ask a simple question: are there any docs/examples on how the trigger controller actually works? I've been studying some of those in the DM DSB dungeon, and I don't fully understand them. In particular, how are the initial/target bits used?

For example, on level 6, in the grave of King Filius, explorer of combinations, there are four buttons, each of which have an exvar of "data = x" where x is 1-4. How do these values relate to the function of the trigger controller?

The bits for a trigger_controller emulate the AND/OR gate from FTL DM. Zyx explains AND/OR gates here.

The big difference between DM and DSB is that all that hacky positional stuff is gone. You can simply choose which bit(s) to set or clear directly, which is what the exvar of "data = x" does; it is telling the trigger_controller which bit to set or clear.

Ah. OK. I never really understood logic gates. I will have to read up once more and really try to understand them. Thanks for the pointer

In other news though, I was very pleased to use a single trigger_controller to completely replace the extremely weird boulder-teleport-pad mechanism for the two flashing teleporters on level 6, near "Test Your Strength".

EDIT: I still don't understand what "data = x" actually does? Is it setting initial bits, or target bits? I'd appreciate if you could expand on this in a bit more detail?

There is a third set of bits for each trigger_controller, which is the current bits.

When the player first enters the dungeon, the current bits for every trigger_controller are set equal to the initial bits. Messages to the trigger_controller with an appropriate data parameter will modify these current bits: an activate message with a data value of 1 will set the first bit, while a deactivate message with a data value of 3 will clear the third bit, and so on. When the current bits match the target bits, then the trigger_controller sends its message.

(I should add: since this is Lua, internally it's all done with an array of bools, not actual bits. However, it works the same in practice so the DM terminology works better in the context of the DM dungeon)

Right, thanks, I understand better, but still missing something:

The trigger controller has two columns for bits, initial bits, and target bits. You discussed a third set of current bits, managed separately.

I thought I understood that the current bits need to match the initial bits for the controller to send its message.

But you instead said "When the current bits match the target bits, then the trigger_controller sends its message."

I'm thoroughly confused about the initial bits and target bits now!

Should I just set initial bits for my condition and ignore target bits completely?

The initial bits are simply that: they are the starting state of the trigger_controller's bits. After the game has actually started, aside from a reset message, they're completely ignored.

For example, let's say a trigger_controller has initial bits of {true, false, false, false} and target bits of {false, true, false, false}. When the game starts, its bits (i.e., the current ones) will be set to {true, false, false, false}, to match the initial bits.

Suppose it gets an activate message from somewhere with a data parameter of 2. Its current bits are now {true, true, false, false} because the second bit is set by that message. The initial bits are still exactly the same, and irrelevant at the moment. DSB now compares the current bits to the target bits: {true, true, false, false} does not match {false, true, false, false}, so the trigger_controller does not send any messages. (Unless it's set to send reverse messages, but that complicates things, so we won't worry about that now)

Another message now comes in: a deactivate message with a data of 1. This will clear the first bit, so the current bits are now {false, true, false, false}. DSB will then compare the current bits to the target bits; they now match, so the trigger_controller sends its message.

Aha! Thank you so much for this detail, I get it now.

I think I was confused because I've been looking at the controller for "King Filius". The buttons that send messages, send M_TOGGLE messages, and for whatever reason I had a mental block about that.

With your explanation, I now understand that each press of a toggle button is either setting or clearing the current bit because of the toggle message. The "King Filius" controller has target bits of {0,0,0,0} vs initial bits of {1,1,0,0} so it just needs a single toggle on bit1 and bit2 which will clear the current bits and result in a four cleared bits which match the {0,0,0,0} target.

Phew, makes sense now! Thanks for your patience

Sort of connected to this discussion: I just want to thank you for the sequencer object. It is brilliant.