Announcement

Collapse
No announcement yet.

Confused by my own bp.. ship roll

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

    #16
    Show everything. The BP too!

    Comment


      #17
      Hey sorry and ok
      Attached Files

      Comment


        #18
        Look at the setup I posted last day , I've already mentioned " ship mesh is attached to a collision sphere" and I pointed it with the arrow.

        With your setup Ship mesh is the root component so it will not work !
        Website [ LINK ]
        Twitter [ LINK ]
        Support ! [ LINK ]

        Comment


          #19
          Hi and im sorry i can tell your getting annoyed with me Lol i did notice the collision sphere thing you pointed out but was not quite sure what you meant . As i said before i am a bit of a dunce .However it is now working flawlessly ..I would however love to know WHY it works ..If anyone has the time i would love a brief explanation of what the new blueprint is actually doing . I am very grateful to you guys for your help .

          Comment


            #20
            Originally posted by mr_starfire View Post
            ..I would however love to know WHY it works ..If anyone has the time i would love a brief explanation of what the new blueprint is actually doing . I am very grateful to you guys for your help .
            I'll have a go and maybe Mhousse1247 will correct things later... BTW: Disclaimer - I've never used Floating-Pawn-Component / Add-Movement-Input / Add-Controller-Input before, so there may be some guesswork here...

            The new BP is split into 2 branches (Sequence node). The top or first branch corrects the roll... I'd suggested doing this before in tick, but InputAxis has an auto-tick. The code gets the rotation of the ship and breaks off the roll (Break Rotator). This is then passed to FInterpTo, which is a common node for interpolating between two points to generate a smooth transition (to flatten out the roll of the ship). In short, if you don't have this, the return to a flat roll might seem jumpy or jerky etc. Delta-secs helps as well to compensate for varying frame-rates etc. We need to rebuild the rotation (Make Rotator) in order to pass it to Set-Relative-Rotation, which actually does the movement (everything else is just calc-work otherwise)...

            The second branch.... I believe it does what you had before only better as it seems to scale the degree of roll based on the value of 'input axis'... First, the code checks if Player Input is greater than zero, as you don't want to flip the ship mesh to the side if there's no input etc. BTW: I was curious if these two key branches would conflict / fight each other. But the fact that you confirmed it works perfectly, means that a separate check in the first branch for Input = Zero isn't necessary. That's the difference between reading code and deconstructing something that works....

            Anyway, normally you get the Forward-Vector to move the ship forward in the X direction (x is forward in unreal). But here we need to change the roll so the code gets the side-to-side or the Right Vector (Y) and captures the Sign too. I believe its done this way to encapsulate the code into just a single-section (but you could also have separate Left-flip / Right-flip code branches based on whether the InputAxis is leaning left or right). The last part is Clamping, a common way to restrict invalid values being supplied to a movement node. You can imagine on a car, you wouldn't want the steering wheel to be able to turn the wheel so far it gets stuck or damages the chassis etc. So I assume that's why its here too, to stop the ship mesh flipping over on itself, if the player input is too extreme etc.

            Note, I haven't dealt with the use of 'Relative' at all. In general you use relative when you want co-ordinates or rotation of a mesh relative to something its attached to etc. Might be easier to think in character terms. Imagine in-game a player is told to put their hands up by a cop. If you had to animate that you could describe the movement in absolute World co-ordinate / rotation terms. But you could also describe it relative to the character's body the arms are attached-to, which is more useful because then whether the player is standing or lying down the info is the same. That's how I visualize it anyway. Note, in my own ships movement code I only use ever use World, so Mhousse1247 will have to advise why Relative is essential here...

            The Event tick at the top I assume you're fine with... But if not it looks like its the code that propels the ship forward continuously - no brakes, infinite-runner type... The key node is AddActorLocalOffset which solely takes a speed var (again x is forward in unreal)... I'm assuming there's no need to do more calc-work like getting a forward-vector here because the code works in local or relative terms once again...

            Comment


              #21
              Thank you . And yes the "code" at the top is my own. Originally it was controlled by the player but i decided to just lock the boolean throttle on. But leave the option to use a button press available for future ideas . I am toying with the idea that the ship uses solid rocket fuel and hence the burn cant be controlled and the player simply has to survive until the fuel is spent. Lol anyway I am extremely grateful to you for taking the time to explain the bp to me . Visual scripting is very new to me as i have only ever coded in gml . Im pretty sure i have some kind of dyslexia when it comes to reading nodes . Anyway im rambling .Thank you

              Comment

              Working...
              X