Ok I don’t get this, have read a lot of docs and seen many videos. I have 2 Actor BP in my level. I want the first ‘HANDLER’ to trigger the second ‘LISTENER’ every once in a while.
HANDLER Has an Event Dispatcher called ‘B_Sender’ (Pic Below)
The second LISTENER (pic below) Has a BIND EVENT to B_SENDER with a custom event to Print String. It wont compile because it wants something connected to Target. What do I connect here? I’m assuming a reference to the Actor? I can pull off and create a variable with the same name as the ActorBP, and it compiles but Print String never gets fired (either one)
Currently you do not have a problem with Dispatchers. You have a problem with passing object references - your missing pin. [HR][/HR]
Since you have both objects in the Level Blueprint, you can use the LB as glue between them. Consider the following:
Actor A has an Event Dispatcher happy to send the data to whoever is listening:
Actor B has a Custom Event that is waiting for that data:
Currently those 2 objects do not know about one another’s existence. But the Level Blueprint knows about both so you can use it as glue:
You can, of course, provide Actor B with a direct reference to Actor A. In Actor B, create a variable of type Actor A and use the LB to set the variable:
Now you have the missing object to plug in but this completely defeats the purpose of using a dispatcher in the first place… The whole idea here is not to create direct references and simply not worrying about them returning null values.
Even though the explanation from Everynone is good and precise what you were missing in those pictures, you wrote that you have two ACTORS. My point is that in order to use input event like you input “P” you need to have a pawn that is possessed by your controller. That being said, your actor will never receive an input P event, hence the not printing P_Pressed and the rest. If you want to use that only for testing I suggest to create a custom event instead that input and set it as call in editor. With that you can just click on that actor in either scene or world outliner and there would be a button named as that custom event.
Besides, any actor can have its input processed, not only pawns. A controller will happily process input from various sources even though it’s not possessing anything itself. Processing is done in a very specific order, too.
Input in unpossessed pawns is not processed, of course. That’s a different story altogether.
Huh that’s new, thanks for clarification. But still he wrote that even the first print string is’t fired so there must be at least problem with that input catching otherwise it would show up unless he suppressed those on screen messages, no?
I see what you mean. I focused on the dispatchers only.
Most likely, yeah. Regular *actors *are not registered to receive input by default, it has to be enabled per actor -> *Auto Receive Input (Player). *So that would solve pressing P and not seeing the Printed String. [HR][/HR]When it comes to suppressing prints string (or debug string?), there’s something I can never remember - but it has something to do with not having a custom HUD class in the Game Mode. Not sure.
Ok, the thing is one of my blueprints is a sort of ‘handler’ which spawns the second BP, which has a few different versions. I want the spawned one to listen to the ‘handler’ for messages and act on them. That means that second won’t be always in the persistent level. In order to send messages from one BP to the other seems wildly complicated??? At the moment I’m having to use global variables in a Game instance and do loads of casting, I was hoping to simplify this…
Below is my second BP, I’m going to spawn a bunch of these and make all of them listen to a broadcast (event dispatcher) of an object that created them. All you need is a Custom Event (or a function). Do note the inputs list *(bool & int) *of the event - it’s going to be vital later on:
Every time you call SendData in this handler, all Spawned Things will get the message (and the data). [HR][/HR]
I mentioned the input list at the beginning. In order for this to work both the *Listening *event (I am all ears) and the *Broadcasting *dispatcher (Send Data) must match their signatures. Highlighted here in delicious orange.
