[SOLVED] Two events trigger one

Hi, completely new to blueprints and would highly appreciate your help.
I have one collision trigger/switch that, when entered and pressed E, will set a custom event active. This works.

  • I want the player to to push two switches in order for this action to be set active.

Could you please let me know how you would go about this?

Custom Event BP

Switch BP

The easiest method to accomplish what your looking to do would be to use a multigate. basically each switch would call the bridge open as you have it now, but you would only connect the second output pin (out 1) to the rest of the script.

you could also solve the issue using bool variables, or by incrementing a int variable. in these cases you would still need to call an event to check if the requirements to open have been met.

1 Like

There’s definitely more than one way to accomplish this, and mine is not the quickest solution, but I decided to take this answer a bit further to provide some additional benefits. Here’s how I’d go about it.

My approach uses booleans like ThompsonN13 briefly mentioned, and relies on two blueprint classes: one for the bridge, and one for the switches that will control each bridge. I think this is mostly the way you have things set up already, which will hopefully make things easier for you. Here goes.

  1. In your bridge actor blueprint, create a variable, and make it an array. Then set its type to your switch actor blueprint. Simply put, you’re making an array of switch actors. The idea is, the bridge is controlled by all of the switch actors that end up populating that array. (This will enable you to have any number of switches controlling a bridge: two, three, one, or whatever you want!)

  1. Also on your bridge actor blueprint, create a custom function, and call it ‘RegisterSwitch’ or something like that. This function will need to take a switch blueprint actor as an input, and needs to be public (which it should be by default). Inside that function, take the switch blueprint actor that is passed in as a parameter and add it to the switches array. The point of this function is to allow switch actors to ‘introduce’ themselves to the bridge actor when each switch is spawned. We’ll set up the other half of this behavior further below.

250133-bp-bridgeactor-registerswitch.png

  1. Create another function in the bridge actor blueprint. This one can be named something like ‘OnSwitchTriggered’. This function will get called whenever a controlling switch gets activated by the player. As for this function’s behavior, hold that thought — we’ll come back to it after we set up some other stuff.

  2. Next, open up the switch blueprint, and add a variable called ‘ParentBridge’ or something like that. Set the type for this variable to the bridge actor blueprint. (In other words, you want this variable to store a reference to the bridge actor that the switch is controlling.) This variable also needs to be public so you can set it from the details panel in the editor.

  1. Add another variable inside switch blueprint graph, and make this one a boolean called something like ‘bTriggered’. This variable also needs to be public so it can be accessed by the bridge actor.

  2. Still inside the switch blueprint graph, pull a pin off of BeginPlay and call up the RegisterSwitch function of ParentBridge. Use a ‘Get Reference to Self’ node to set the input parameter to self (this switch actor). This will make it so each switch actor will ‘introduce’ itself to the bridge it controls as soon as the game starts. (The next image shows how this is set up.)

  3. Next, add some more logic to the switch blueprint graph so that the bTriggered variable gets set to TRUE when the player interacts with it. It looks like you already have this logic figured out, so you just need to adapt it a little. Then, immediately after setting the boolean to true, call up the OnSwitchTriggered function for ParentBridge. This way, every time a switch has its bTriggered value changed, its parent bridge actor will run a function that reacts to this change. (This setup allows us to avoid running the bridge function every tick, which would be less efficient.) You can also perform other work from here, like changing the material of the switch so the player sees that it was activated.

  1. Now for the trickiest bit. Go back to the bridge blueprint and open up the OnSwitchTriggered function so you can add some behavior to it. You want to check each switch in the switches array to find out if any of them have not yet been triggered (by looking at each switch’s bTriggered variable). I recommend a for-each-break loop. The Break pin gets executed if any of the switches are not yet triggered, stopping the loop early. The Completed pin leads to a Branch node that continues execution only if all of the switches have been triggered and if the bridge actor hasn’t already been activated. (I created a local boolean variable with a default value of TRUE to track whether the loop discovers any un-triggered switches.) Anyway, you’ll want to pull off of the Completed pin to run your ‘Bridge Open Close’ function and any other functions you need. Take a look at my example image and adapt as needed.

  1. Last but not least, back in the level editor, make sure you select each switch actor in the level and, in the details panel, choose the bridge actor you want to control with it by assigning a bridge to the ParentBridge variable. If you want a bridge to be controlled by two switches, first place the bridge, and then drag two switch actors into the world, and set both of their ParentBridge variables to the bridge you want controlled. If you later want that bridge to be controlled by three switches, just drag in another switch actor and set its ParentBridge variable the same way. If you want to reduce from three to two, just delete the switch you no longer want. Easy and flexible.

And that’s it!

I know that this approach requires more setup and modification than you probably had in mind, but the advantages are you can have as many bridges as you want in the same level, and you can also have as many trigger switches controlling each bridge as you want!

Again, this is not the only way to make this work, and it’s not necessarily the easiest, but it offers more flexibility and reusability than some other approaches. I think it’s worth the effort.

Hope this makes sense and helps you out!

I use a simple Int variable. Set it to 0, when a lever is activated, you increase Int by 1, if deactivated - decrease by 1. After activation of each lever and Int increase you check if Int == 2 and launch your event if it is.

Here’s the example.

The door itself checks if it’s open and launches the Close Door function only if it is, because there might be some sound involved and you don’t want to play it every time you unpush any button.

I believe this solution is the easiest one, and easily scalable to any number of buttons.

Trouble is, with that setup the player could just activate the same button n times and cause the door/bridge/whatever to open that way. You’d have to also run a check within the button/trigger blueprint to make sure it doesn’t get activated more than once (causing the the integer-incrementing function to be called more than once by the same trigger). Still, that would also be really easy to do.

So long as there isn’t a need for more than a couple configurations of door/bridge/whatever — some doors needing one trigger, some needing two, some needing three, etc — because each configuration would require its own blueprint implementation using your example. Sure, it’s easy to set up each one — just duplicate the blueprint, add the additional events, and change the value in the integer comparison node — but with more than a couple implementations of nearly the same exact thing, the project would start to feel a little messy, at least to me. Plus swapping out a door that’s using, for example, two triggers with one that uses three triggers would require replacing the door actor in the level with a totally different blueprint. That’s not completely terrifying, but it could cause issues depending on level complexity.

On the other hand, in the event that each door/bridge/whatever actor never needs to use more than two triggers (actually very likely), then your approach is definitely a lot easier and more appropriate.

Leave it to me to design an infinitely scalable door-trigger system while ignoring the fact that making any player activate more than a handful of door triggers is a simply awful idea, regardless of how technically easy I’ve made it to implement.

In my case, you can’t activate the same button multiple times, because in order to activate it for the second time you have to deactivate it first, which decreases the integer. If a button can be activated multiple times, then yes, that would be an issue.

The second thing — no, they do not require different implementations. The nods in my screenshot are used in the level blueprint, and you only send the Open command to the door once the requirements are met, the door/bridge blueprint is one and the same.

for anyone whos curious the below pictures show the basic setup of the integer door system when implemented as actor components. by having it as actors and not in the level bp it becomes scaleable and reusable.

the basic idea in the below pictures is that you have one bp for the switch and one for the door, there can be many switches associated with one door. the switch would be setup to where there is a editable public variable of the type of the door, this allows us to get a reference to the specific door once placed in the level. then the basic script is a input to activate the switch (everything up to the gate in the picture), a do once so the switch can only be activated once (this is just one example of flow control), and the calling of the open door in the door bp.

the door will have two variables switches activated and switches required. this will function basically just like the classic do you have enough keys or coins to open the door. each time the open door script is called the switches activated will be incremented, then the script will check to see if the activated equals the required number, if yes open the door, if no do nothing. i should also note that the required variable is public as well so it can be changed on a per instance basis.

so infinitely scaleable and all you need is to have the correct number of switches and a matching switches required number.

Thank you!

Thank you!

Thank you!

Can I use the same BP/Actor for the switches and place in the level (as long as the amount is equal to the SwitchesRequired on the bridge actor?
I add the value up to 2 and drag 2 switches in the level. The events doesn’t go any further than the Gate. I do see that you have a function for Open Door and not a custom event like I do, is that the issue? After the ‘Do Once’ I call on the custom event

Many thanks!

sorry, it works now - just needed to uncheck ‘start closed’ on ‘Gate’

yes you can reuse the switch actor and add as many as you like to the level, you just need to set the variable for each one to tell it which door it is associated with.

if the script doesnt go past the gate that means that your character was not overlapping the switch. you may run into input issues later on so i put the overlap in as a way to control which switch is being interacted with. for example if there was no gate and there was multiple switches then the game may just activate the switches in the reverse order of placement, that would be bad. so you just need some kind of flow control and the overlap is a first step in that direction, the second would be that you may need to uncheck consume input for the input event in the details panel.

im my example i was actually using a custom event but the event was in a separate actor. i had a switch actor and a door actor, the event was in the door actor. the reason for having two actors is so that you can have many switches associated with a single door.