Announcement

Collapse
No announcement yet.

Event dispatcher between 2 blueprints

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Event dispatcher between 2 blueprints

    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)

    Click image for larger version

Name:	AEvent01.PNG
Views:	739
Size:	58.7 KB
ID:	1527833
    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)

    Thanks

    Click image for larger version

Name:	BBSender.PNG
Views:	712
Size:	109.2 KB
ID:	1527835



    Attached Files

    #2
    The target is the "handler". Your going to need to get a pointer to it somehow when you bind events to it.
    YouTube channel: https://m.youtube.com/channel/UC1qaQM1VnY441J5lCLCPMwg

    Comment


      #3
      Currently you do not have a problem with Dispatchers. You have a problem with passing object references - your missing pin.

      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:

      Click image for larger version  Name:	ActorA.PNG Views:	1 Size:	50.7 KB ID:	1527855

      Actor B has a Custom Event that is waiting for that data:

      Click image for larger version  Name:	ActorB.PNG Views:	1 Size:	41.8 KB ID:	1527856

      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:

      Click image for larger version  Name:	LB.PNG Views:	1 Size:	76.4 KB ID:	1527857

      Or, you can use less glue like so:

      Click image for larger version  Name:	LBwithLessGlue.PNG Views:	1 Size:	57.4 KB ID:	1527858

      Regarding your original query.

      It wont compile because it wants something connected to Target. What do I connect here?
      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:

      Click image for larger version  Name:	WhatsThePoint.PNG Views:	1 Size:	40.0 KB ID:	1527859

      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.

      Hope it makes sense.

      Comment


        #4
        That is great and a very clear explanation i will try those solutions, thankyou

        Comment


          #5
          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.

          Comment


            #6
            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.
            Somehow I don't think that's the issue here.

            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.

            Comment


              #7
              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?

              Comment


                #8
                I see what you mean. I focused on the dispatchers only.

                But still he wrote that even the first print string is't fired so there must be at least problem with that input catching
                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.
                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.

                Comment


                  #9
                  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...
                  Last edited by Gibson_Martelli; 09-18-2018, 09:32 AM.

                  Comment


                    #10
                    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:

                    Click image for larger version

Name:	listener.PNG
Views:	702
Size:	64.3 KB
ID:	1529383

                    And here is the Handler, it's spawning 6 SpawnedThings and makes them listen to the SendData dispatcher:

                    Click image for larger version

Name:	sending.PNG
Views:	702
Size:	199.5 KB
ID:	1529384

                    Every time you call SendData in this handler, all Spawned Things will get the message (and the data).

                    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.

                    Comment

                    Working...
                    X