Announcement

Collapse
No announcement yet.

Projectiles - which actor should destroy them?

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

    #16
    RobMeade Yes, I just checked, I can see all the variables in my player from a widget. So you can just bind them...
    Check out Zof ( puzzle game ) on Steam:

    https://store.steampowered.com/app/1414480/Zof/

    Comment


      #17
      Hi ClockworkOcean, thanks for the reply and the info - appreciated.

      Regarding the HUD, I was going to bind it initially, but I had some difficulties, I can't actually remember what now, it was quite a while ago. I saw in an online tutorial this evening, from a senior dev at Unreal, it mentioned that the bind on the HUB would be firing every tick, and as such, doing that for player health/ammo/lives etc isn't a good idea, better to just have the HUD respond when something changes. I can dig out the link if you're interested, video was 2 hours 22 mins long, it was a Zac someone, I forget his surname, he was talking about the 3 main communication methods for Blueprint.

      Regarding the pickups, thanks, I'll get some paper and a pen out and outline this and see what it looks like. I'm apprehensive about changing anything at the moment as it is all working, I would just like to improve it, but not at the cost of breaking it all

      Naming wise, I was trying to follow the kinda standard you'd see for C# and the like, I've seen "iComparer", "iEnumerator" etc, so I was trying to find a phrase/word that was suitably descriptive and "fitted"... (I do appreciate it doesn't matter hugely at the end of the day).

      One other thing... so with the above, where the message goes from the pickup to the player... I have components on my player for both the health and the ammo... but I believe I would need to implement the interface on the main player BP, these would then inherit it. The actual function though, I'd kinda like to have that "in" the relevant components, rather than in the main player itself. Any reason you can think of why this wouldn't work, or isn't suitable? Where I can I'm trying to have these component just add behaviour that could be added to something else and still work, so not having any little trailing ends in the parent BP would be kinda tidy...

      Thanks again for the reply

      (this was the Live Training session : https://www.youtube.com/watch?v=EM_HYqQdToE)
      Last edited by RobMeade; 11-27-2019, 08:24 PM.

      Comment


        #18
        RobMeade HUD on tick, didn't know about that. Not a big HUD person, don't really need it. So dispatchers probably the way then.

        As far as pickup responders as components of the player: Thinking about it, it should be fine, but the programming may be a little more messy in the pickup. You can have an interface on the health component ( for instance ) and then make it part of the player, but then you can send the message to the player, you have to get a handle on the component and send the BP message to it.

        Or... like you say, the health responder inherits the interface from the player, but you still have to access the component before you can send the message. It's just a couple more nodes. best thing it to give it a go

        Like I say, haven't actually tried it, but the concept seems ok.

        Naming wise, I think you can change it later anyway, again not sure without trying...
        Check out Zof ( puzzle game ) on Steam:

        https://store.steampowered.com/app/1414480/Zof/

        Comment


          #19
          Many thanks again, I'm going to give it a whirl tonight and see where I can get to. I wanted to try to make sure the approach was valid/clear in my head before adding more functionality, as a lot of things will invariably use the same approach, so I didn't want to have to change a load of other things later

          Thanks for all the help

          Comment


            #20
            RobMeade You're welcome. I think you'll get a feel for it, if it's not working...
            Check out Zof ( puzzle game ) on Steam:

            https://store.steampowered.com/app/1414480/Zof/

            Comment


              #21
              Citation from somewhere in the thread

              "3) Dispatchers. Again, very specific use case. Basically when you want to broadcast to a lot of actors and don't want to have to find them and talk to them all. The use dispatchers, because you can just say 'My event!' and they all see it. You didn't have to send it to them, you didn't have to find them and tell them. It's a broadcast."

              I just found that somewhere in this thread, looking for some other stuff. And I think, that it is important to mention, that THERE IS NO BROADCAST in UE4 - full stop. You can use the Event Dispatchers mentioned above, but it is important to understand, that these require all receivers first to register to the events using Bind Event. This requires a Target to be set (the sender), so every potential receiver needs a reference to the actual sender first to do that bind in order to register to receive any dispatched events. So NOT EVERY actor will receive the event, but ONLY THOSE, THAT HAVE REGISTERED before. In the end, this is actually a MULTICAST.

              I just wanted to point this out, because there seems to be a lot of misconceptions around with blueprint communications, especially the event dispatchers.

              Comment

              Working...
              X