Announcement

Collapse
No announcement yet.

First Person Example Project - How is Event Hit being Triggered?

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

    First Person Example Project - How is Event Hit being Triggered?

    Hi all,

    I've opened the First Person template project trying to find some answers to a problem, only to be confounded by more

    In this default project the projectile blueprint has the following;

    Click image for larger version

Name:	Screenshot.png
Views:	120
Size:	69.9 KB
ID:	1690290

    If I hover over the Event Hit node it states that "Simulation Generates Hit Event" needs to be active for this to work, kinda makes sense. What I cant work out though is how neither the projectile, or any of the cubes in the scene have this enabled and yet this hit event is still being triggered? I've looked through what I can and can't work that out.

    Could anyone help with this please? Thanks in advance.

    #2
    the Event Hit node it states that "Simulation Generates Hit Event" needs to be active for this to work
    No, it says that it's required for collision during physics simulation. Neither the projectile mesh or its collision sphere use simulation here. The projectile has a highly specialised Projectile Movement Component that takes over and does all the hard work instead.
    Last edited by Everynone; 11-23-2019, 11:16 AM.

    Comment


      #3
      Hi Everynone,

      Thanks for the reply. So, its all being handled within the Projectile Movement Component then?

      The reason I was looking was because I was hoping to try and get a "how's it done" from this example. I was having some problems with projectiles and what should destroy them. Initial feeling was that the projectile should destroy itself, but, in a specific case I needed to check "what" had hit an Actor and wanted to check if it was a projectile. When I tried to check, I got errors because it was already being destroyed (pending kill).

      Now that I've changed it from the object reference, but to whether the "other actor" had a parent class of the class in question, it seems to work.

      I'd still be interested to know you thoughts though, to me it wouldn't seem right if the actor that was hit by a projectile was responsible for destroying the projectile. That should be behaviour of the projectile. In my crazy head at least

      Comment


        #4
        I saw your thread, was going to chip in but something distracted me.

        I'd still be interested to know you thoughts though, to me it wouldn't seem right if the actor that was hit by a projectile was responsible for destroying the projectile. That should be behaviour of the projectile.
        I think it will depend on the game design - you may want to go one way or another.

        - lets say you fire arrows that do get stuck in the target - you do not want the arrow to self-destroy on impact, surely. The player can keep track of the projectiles that connected and choose to destroy (or even keep!) them later on

        - or you may want to delay the destruction on impact - to allow for a ricochet

        - or you want to destroy the projectiles after x seconds - a timed sticky bomb; or after x bounces - a scatter shot of sorts

        - or you may want the projectile to hang around to do extra stuff - like in this example where it spawns additional projectiles

        I can easily imagine a situation where I'd make the target of the projectile responsible for its destruction.

        There is another way altogether - you do not destroy the projectiles at all. Imagine a game where you've got 1000s of bullets flying simultaneously. Spawning actors is computationally expensive; you pre-spawn them instead, keep them ready, use what you need and once they've served their purpose, put them away so they can be re-used. A method commonly referred to as Pooling.

        Pools can grow (if they exceed the limit) and can be trimmed to conserve memory - it's a trade off, generally speaking. Larger memory footprint vs performance.
        Last edited by Everynone; 11-23-2019, 02:50 PM.

        Comment


          #5
          Thanks again for the response and the detailed reply, pooling would be a very nice approach to this.

          With the other scenarios you've suggested I would imagine using events to effectively call back to the projectile and say "Ok, we're done with you now" - so the behaviour could still live within the projectile itself, a separation of concerns so to speak, albeit the object could be returned to the pool rather than destroy/re-instantiated.

          Comment


            #6
            Some really good work done here:

            https://forums.unrealengine.com/unre...pool-component

            https://www.unrealengine.com/marketp...ct-pool-plugin

            Comment


              #7
              Thanks for the links

              Comment

              Working...
              X