multisource
acts as an AND gate. It only triggers its targets if all entities targeting it are in the 'ON' state. It can also be used as a master (instead of actively triggering something when the conditions are met, events or entities using it as a master will only be able to function when the conditions are met).multisource
can be used in 2 ways:
multisource
, and when those buttons get activated, the multisource
will activate a door (this is an example of course, the possibilities are endless).multisource
, then that door will only unlock once that multisource
gets activated in some way. Be aware though: If just 1 of those X amount of entities gets disabled (such as a button turning off), the multisource
will turn off and the door (or anything else you have) will now be locked once again.env_global
) that can be used to control the state of the multisource
.multisource
has to be able to be activated by some other entity in some way, otherwise it will not work. That can be anything, from buttons to triggers, but always make sure that something triggers it.multisource
, pressing both will make the multisource active, until either one resets (pops back).multisource
, do not call it "multisource". It will not function properly. Give it a helpful name that relates to your entity set-up.multisource
registers up to 32 entities as its clients capable of affecting its state. These include only entities that have the multisource's targetname in the target
parameter and multi_managers pointing to the multisource in the trigger list. It means that other triggers like TriggerTarget
(in monsters) won't correctly affect the state of the multisource. You'll need to place an intermediate trigger_relay
between monster and multisource (e.g. if you want to track whether the all marked monsters have been killed).trigger_changetarget
), the multisource
won't recognize this entity as a suitable client. It also won't recognize if the target of some client has been changed (doing so will effectively remove the ability to change the state of the multisource).multisource
doesn't actually look at the state of the entities that trigger it. Instead, it stores its own 'on/off' flag for each entity (initially set to 'off'). Whenever an entity triggers the multisource (no matter the use type), it simply toggles the 'on/off' flag for that entity. Auto-resetting func_buttons
have special behavior when targeting a multisource
: they normally don't trigger their target when they reset, unless the target is a multisource
, so the button state automatically matches the multisource
's 'on/off' flag for that button.multisource
doesn't recognize the input use-type, you can use a mapping trick to force it to the off or on state (and ensure that if it's already in the needed state, nothing will happen). The trick relies on the button_target
behavior trait that makes it to trigger its targets only when the button_target
changes its state. Put your multisource as a target for a button_target (or multiple button_targets), and use two trigger_relays (per each button_target) to send an 'on' or 'off' signal to the button_target. This allows you to enable the multisource with the trigger_relay that sends the 'on' signal, and disable it with the trigger_relay that sends the 'off' signal. In this case button_targets are used as intermediate state holders and you should make sure they're not reachable by players.func_button
with its 'Toggle' flag set targets a multisource
, it will fail to trigger the multisource
once every 4 times (the third time out of every 4 times that the player uses the button). To work around this bug, make the button target a trigger_relay
which then targets the multisource.multisource
, use an intermediary trigger_relay
as above, and add a trigger_auto
that triggers the trigger_relay
when the level starts (be sure to set its 'Remove On fire' flag to prevent problems when loading savegames). This results in a button that can disable other entities when pressed. This is more difficult for auto-resetting buttons, because they won't trigger the intermediary trigger_relay
when they reset, but one workaround for that is to make the button target a multi_manager
that then triggers the trigger_relay
twice (first with a delay of 0, then with a delay that matches the buttons auto-reset time).multisource
.
# | Setup | Odd-th triggering | + wait | Even-th triggering | + wait | Remarks |
---|---|---|---|---|---|---|
1 | Buttons | |||||
1.1 | button (w/wait) → ms | 🟢ON | 🔴OFF | 🟢ON | 🔴OFF | Turns off when button resets ("pops out"). |
1.2 | button (toggle) → ms | 🟢ON* | 🟢ON | 🔴OFF | 🔴OFF | See note about bug every 3rd of 4 triggers. |
1.3 | button (toggle) → relay → ms | 🟢ON | 🟢ON | 🔴OFF | 🔴OFF | The above bug fixed with a trigger_relay . |
1.4 | button (toggle) → ~relay* → ms | 🔴OFF | 🔴OFF | 🟢ON | 🟢ON | trigger_relay triggered with trigger_auto at start of map. |
1.5 | button (w/wait) → mm ⇉ ~relay → ms | 🔴OFF | 🟢ON | 🔴OFF | 🟢ON | ditto + multi_manager triggering the relay twice, with interval the same as the button's reset time. |
2 | Direct relays | |||||
2.1 | relay (ON) ⇀ ms | 🟢ON | 🟢ON | 🔴OFF | 🔴OFF | trigger_relay 's trigger state is ignored. |
2.2 | relay (OFF) ⇀ ms | 🟢ON | 🟢ON | 🔴OFF | 🔴OFF | ditto. |
2.3 | relay (Toggle) ⇀ ms | 🟢ON | 🟢ON | 🔴OFF | 🔴OFF | ditto. |
3 | Relay + button_target | |||||
3.1 | relay (ON) ⇀ button_target → ms | 🟢ON | 🟢ON | 🟢ON | 🟢ON | Explicitly set value via button_target which only fires target when it itself changes state. |
3.2 | relay (OFF) ⇀ button_target → ms | 🔴OFF | 🔴OFF | 🔴OFF | 🔴OFF | ditto. |
3.3 | relay (Toggle) ⇀ button_target → ms | 🟢ON | 🟢ON | 🔴OFF | 🔴OFF | ditto. |
You must log in to post a comment. You can login or register a new account.
Master properties expect a multisource name. A multisource acts as an on/off switch that you trigger to toggle your entity. If two entities target the multisource, both must be active at the same time for the multisource to work. (e.g.: two buttons).