Announcement

Collapse
No announcement yet.

Using Traces for Weapon Bullets

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

    Using Traces for Weapon Bullets

    Hey guys,
    I've been slowly learning a lot while building my game prototype. I have projectile's spawning towards the mouse cursor, but that's not terribly practical or pretty, and I need a new system. So I've been trying to use a trace for that "instant hit" style gun. I've got some issues though...

    My trace results are weird... It's almost like it's going from the camera/mouse to the character/model or vice versa. I'm not sure, but they're definitely not going from the character to where the Crosshair is pointing. I've posted a blueprint and screen shot of my trace results. I'm not sure what other information to provide at this point.

    Any help is greatly appreciated!

    edit, if I remove the "rotate vector" from Get Actor Location, and plug "Get Actor Loc" into "Start single line trace" I basically get the same thing.
    Attached Files

    #2
    So I found another post that linked me to here: http://creategamesfromscratch.blogsp...il-weapon.html (another forum user's site, sorry I forget your forums name right now).

    I think that works because it's first person and the socket rotation is always in line with the screen and crosshair, so there's less variables. I know I'm missing or misunderstanding something about how the vector, trace, and mouse all work together to get what I'm looking for, I just don't know enough to know what I'm missing, if that makes sense.

    Anybody have this problem or know how to point me in the right direction?

    Comment


      #3
      I'm willing to pay a small-ish fee if some blueprint master can help me. Just respond to this thread with your contact info.

      Comment


        #4
        Doing this actually requires TWO traces.

        The reason is because the crosshair is not in a 3D space, it's in a 2D space, its coordinates only exist in 2D space. What the crosshair is "looking at" is dependent on how far away it is from the screen; you have to project the 2D screen coordinates forward until you hit an object which can be "looked at" to get the 3D location of that object.

        What you need to do is trace outward from the center of your screen for some extremely long distance (say 15% or so further than the trace you'll do for firing your gun, to account for the angle introduced by the camera) and then that hit point will determine "what I am aiming at". This, incidentally, is how many games do it; you'd be surprised how many TPS games simply fire outward from center screen, rather than from the gun/player character itself.

        If you want to instead trace from the gun barrel to the center of the screen (so that the player's shots can be obstructed by walls or other obstacles that are between him and the target, even though the offset camera can see past them), you need to FIRST trace from the center of the screen outward, then perform a SECOND trace from the gun barrel location to the hit location of the first trace.

        I do something similar in my game (though instead of a second trace, I launch a projectile from the gun barrel toward the "looking at" location using the LookAtRotation function). Here's a screenshot of the set-up.

        Click image for larger version

Name:	TraceOutward.png
Views:	1
Size:	251.3 KB
ID:	1053795

        Note that I get the screen size and divide it in half across both dimensions to get "center screen", which is my reticle position. Then I convert the screen space to a 3D vector, which takes "center screen" and tells me where it exists in the world (based on the camera position), and then projects outward to determine what the reticle is laying on. If you use a different aiming system than standard TPS (for example, a freed cursor which is not locked exactly to center screen) you could do something similar by taking the cursor position, BUT REMEMBER! The 3D world position has a horizontal and vertical position, and its depth is equal to the CAMERA! The game is trying to trace to a place on the camera itself, not what that camera sees. If the camera is behind the player, as in your project, tracing from the player actor to a camera position will trace backward to the camera itself. This appears to be what your project is doing; spawning traces that run from the player back toward the camera and hit where the camera is.

        Also note that I spawn an actor with projectile movement; where I spawn my bullet, you would instead perform a second trace, with the start location being your player (or gun barrel socket, whatever) and the end location being THE HIT RESULT OF YOUR FIRST TRACE.

        Comment


          #5
          And here's an example of the trace in action with debug drawing. The only reason the trace line in the first image is slightly off-center is because I have a camera recoil attached to my shot firing; by default you essentially cannot see the trace, since it goes straight out from the camera. It's only from another angle that you can see how the trace is being drawn, from where the center of the camera is in 3D space outward in a straight line to what the reticle is over. It's this trace that determines what the bullet projectile is launched at (or the end of your second trace).

          Click image for larger version

Name:	TraceExample.png
Views:	1
Size:	548.9 KB
ID:	1053796

          Comment


            #6
            Man you are a life saver. I've been going nuts trying to figure this out! Thank you so much.

            Comment


              #7
              Here is an easy way to trace to the crosshair at the center of the screen.
              Click image for larger version

Name:	traceHit.jpg
Views:	1
Size:	150.5 KB
ID:	1053798

              Comment


                #8
                Thanks for the response, could you explain a little bit about the camera player manager? Is it basically the same as getting the view port?

                Comment


                  #9
                  Hi zlspradlin,

                  Did you figure this out, if so can you pls, pls post a screenshot of your blueprint here, i am still having problem make it work

                  Thanks

                  Comment


                    #10
                    Originally posted by RhythmScript View Post
                    Doing this actually requires TWO traces.

                    The reason is because the crosshair is not in a 3D space, it's in a 2D space, its coordinates only exist in 2D space. What the crosshair is "looking at" is dependent on how far away it is from the screen; you have to project the 2D screen coordinates forward until you hit an object which can be "looked at" to get the 3D location of that object.

                    What you need to do is trace outward from the center of your screen for some extremely long distance (say 15% or so further than the trace you'll do for firing your gun, to account for the angle introduced by the camera) and then that hit point will determine "what I am aiming at". This, incidentally, is how many games do it; you'd be surprised how many TPS games simply fire outward from center screen, rather than from the gun/player character itself.

                    If you want to instead trace from the gun barrel to the center of the screen (so that the player's shots can be obstructed by walls or other obstacles that are between him and the target, even though the offset camera can see past them), you need to FIRST trace from the center of the screen outward, then perform a SECOND trace from the gun barrel location to the hit location of the first trace.

                    I do something similar in my game (though instead of a second trace, I launch a projectile from the gun barrel toward the "looking at" location using the LookAtRotation function). Here's a screenshot of the set-up.



                    Note that I get the screen size and divide it in half across both dimensions to get "center screen", which is my reticle position. Then I convert the screen space to a 3D vector, which takes "center screen" and tells me where it exists in the world (based on the camera position), and then projects outward to determine what the reticle is laying on. If you use a different aiming system than standard TPS (for example, a freed cursor which is not locked exactly to center screen) you could do something similar by taking the cursor position, BUT REMEMBER! The 3D world position has a horizontal and vertical position, and its depth is equal to the CAMERA! The game is trying to trace to a place on the camera itself, not what that camera sees. If the camera is behind the player, as in your project, tracing from the player actor to a camera position will trace backward to the camera itself. This appears to be what your project is doing; spawning traces that run from the player back toward the camera and hit where the camera is.

                    Also note that I spawn an actor with projectile movement; where I spawn my bullet, you would instead perform a second trace, with the start location being your player (or gun barrel socket, whatever) and the end location being THE HIT RESULT OF YOUR FIRST TRACE.

                    Man. I know this is an old thread but it just helped me immensely. I should have read your text instructions more clearly. I just took your example pic and tried to modify it on my own... not realizing you specifically said what to do in the text below. Coulda saved me an hour or so... silly me. Trying to get the gun to fire at crosshair, instead of just at the centre of screen and then start the trace from the gun rather than the camera.... didn't realize it was a two trace approach. This worked perfect once I read more clearly.

                    The converting 2d space to 3d is a huge missing piece (obviously). Thanks for the knowledge!

                    If you're trying to do this... here is the part to really pay attention to from RythmScript's post/pic. "Also note that I spawn an actor with projectile movement; where I spawn my bullet, you would instead perform a second trace, with the start location being your player (or gun barrel socket, whatever) and the end location being THE HIT RESULT OF YOUR FIRST TRACE."

                    Use the pic up until the FIRST trace... then create a second trace from the sequence 1. The hit result of your first trace location should connect to the END location of your new trace node.. the start of your new trace node is simply your gun socket or whatever.. (Get Socket Location...etc.)

                    you should see two lasers when you have the debug thing on.. one from the camera behind the character and one from the players gun.... this is fine since the first doesnt do anything other than find a location.. the second is where the "bullet" stuffs would happen. (once you make it so)
                    Snap-In Systems: <<< CLICK
                    | Inventory (Battle Royale) |Smart Select Box | Ready Game Modes | Handy Macros | Gun Weapon System |Simple Mesh Outliner |

                    Comment


                      #11
                      Actually, since making this post, I've updated my system.

                      You may notice, if you're observant, a Magic Bullet flaw with this system; if an enemy or object is BETWEEN the gun barrel and the camera (say, standing immediately next to the player), the bullet will actually fire BACKWARD out of the gun and hit the enemy!

                      What I've done now is modified the start location of my Reticle-Finder first trace to share a local-space X coordinate with the gun barrel socket. So when you trace outward to find what the reticle is on top of, that trace's starting "into the screen" depth is not where the camera is, but where the gun barrel is. This way, objects behind the gun barrel cannot ever be considered what the reticle is resting on.

                      Comment


                        #12
                        I'd suggest the weapons blueprint system on the Marketplace. That's what I used as a base to make my own projectile system

                        Comment


                          #13
                          It seemed like people were complicating a very simple act, but then I found out GetActorEyesViewPoint() isn't callable by the Blueprint scripting system.
                          It returns all the info you want for a basic trace like this.
                          No mess, no fuss.
                          But again, for some reason, its not setup to be blueprint callable
                          Rule#21: Be polite, be professional, but have a plan to kill everyone you meet.

                          Comment


                            #14
                            Originally posted by RhythmScript View Post
                            Actually, since making this post, I've updated my system.

                            You may notice, if you're observant, a Magic Bullet flaw with this system; if an enemy or object is BETWEEN the gun barrel and the camera (say, standing immediately next to the player), the bullet will actually fire BACKWARD out of the gun and hit the enemy!

                            What I've done now is modified the start location of my Reticle-Finder first trace to share a local-space X coordinate with the gun barrel socket. So when you trace outward to find what the reticle is on top of, that trace's starting "into the screen" depth is not where the camera is, but where the gun barrel is. This way, objects behind the gun barrel cannot ever be considered what the reticle is resting on.

                            hmm.. yeah i see what you mean. its hard to catch without the laser on to see the start and end... because otherwise one would just assume the character is aiming that way but theres no animation for it pointing that close or something. I couldnt get to actually hit another character in the scene since the crosshair is always too forward from the player.. as seen here

                            Click image for larger version

Name:	2015-03-29_142913.png
Views:	1
Size:	499.7 KB
ID:	1071489


                            but i could finally recreate it against an object here

                            Click image for larger version

Name:	2015-03-29_142957.png
Views:	1
Size:	135.2 KB
ID:	1071490

                            How do you make it share same local space on x as the gun barrel. I tried forever yesterday making the start point integrate with the gun barrel socket when i was trying with a single trace. I kept getting either it would hit the crosshair properly but start from the camera(top right behind) or it would hit the centre of the screen (not always the crosshair depending on distance) and originate from the gun barrel. Here is my current blueprint.

                            Click image for larger version

Name:	2015-03-29_142024.png
Views:	1
Size:	243.4 KB
ID:	1071491




                            Next step is figuring out how to make this cause damage and kill something... right now I just have explosion particle playing where it lands to see it. It doesn't actually affect anything. If you have a good starting point for this for me here you dont mind sharing... it could save me another day of learning... lol

                            Thanks.
                            Attached Files
                            Snap-In Systems: <<< CLICK
                            | Inventory (Battle Royale) |Smart Select Box | Ready Game Modes | Handy Macros | Gun Weapon System |Simple Mesh Outliner |

                            Comment


                              #15
                              Originally posted by Dealman View Post
                              I'd suggest the weapons blueprint system on the Marketplace. That's what I used as a base to make my own projectile system
                              Does it use line traces?

                              I initially set up a projectile system using the FPS projectile tutorial.... but it seems like its more resource intensive to spawn a bullet every time and launch it when its just going to be invisible anyway.
                              plus the gravity/physics and speed weren't lining up right for me.. but I don't know if I was doing it all correct. Seemed like the line trace method was the most practical for the speed of a gunshot. Figured Id use the other method for something like a grenade or whatever where you actually want to see the item flying through the air and bouncing around.
                              Snap-In Systems: <<< CLICK
                              | Inventory (Battle Royale) |Smart Select Box | Ready Game Modes | Handy Macros | Gun Weapon System |Simple Mesh Outliner |

                              Comment

                              Working...
                              X