Well I solved the stupid "movement being a deteriorating value of inertia" bug. I wish I could post screenshots to show how dumb this was, but I'll do my best to explain in text. In my WallClimbMovement function, in the calculation of my first line trace's End vector, I had gotten the capsule radius as directed din the tutorial, and then multiplied by 2. But my mistake was that I somehow outputted a vector from that multiply node instead of a float. That went into the other two multiply nodes as vectors and the whole thing was forked in grass, as they say. Now it's working great on a slope for climbing upward, and also for side to side, but it won't go down the wall at all. Further, it's not going up the wall on a sheer vertical wall either. Only sloped ones. I suspect my line trace isn't hitting anything when attempting to check for upward movement. Perhaps I need to pull the start of the line trace further away from the wall because maybe it's firing off inside the wall or something. I suspect this since on a slope it likely has more space due to the wall sloping away, but on the sheer wall it's likely too close and firing inside the wall. I'm speaking now without having actually done something about this because I'm still not 100% sure where to add something for that. This is why I preferred the more detailed explanations from previous tutorials in the series. EDIT: Oh, duh! I turned on a persistent draw debug type on the line trace at the start of WallClimbMovement, and it was absolutely missing the wall entirely when I went downward, and was inside the wall when I went up. Now I'm realizing that it's using the forward/back mathematical values to move the start point forward/back to the character, meaning further from or closer to the wall. The reason it won't go up on a sheer wall is because every single line trace is being drawn on a perfect horizontal axis. It's not moving the line up into the Z axis when I press "forward". So yeah, I don't go anywhere.

Oh my GOD, it's always something absolutely stupid. I didn't pipe in a "get actor up vector" into my WallClimbMovement for moving up and down the wall. I mistook the built in "get forward vector" node for being the one I needed. In other words I didn't adequately understand what I was doing when translating from your UE4 to my UE5. So dumb. 😅 That being said I would almost certainly not have missed this mistake had the tutorial not been designed for the Flash. 😆 Finally back to 5:00. Also my animations are jacked up, and my own "fix" did not do the job. I just moved the pelvis lower, but forgot to move the IK objects. Should have just moved the Root or something, I suppose. Gonna have to redo them as Quinn's feet are next to his ears. 😆

Okay, I finally figured out how to fix the issue where the material wasn't applying its Phys Material to the object, and it did in fact start changing the appearance of the object like I suspected. So that was the cause. I think I failed to click "apply" on the material in the editor after adding the PM_Magnesis as its Phys Material. Glad that's sorted. But now that it's trying to change the material to highlight objects that are magnetic as it's meant to, they're just turning duller and lighter, so I still did something else wrong because it's not applying the glowing yellow material. Maybe I need to make sure I hit "apply" on all of them to be sure they're not just applying a white overlay or something dumb like that. The weird thing is that the material is just getting lighter. I had chosen a base object "M_Metal_Burnished_Steel" as my metal material, and the texture of the metal is still there, like the mottled rough look of it, but it seems to be getting a white overlay and the reflectiveness is going away, so maybe the Metallic or Roughness values are going haywire. Hard to say yet. Jonna go click "apply" and report back. Tracking all of this in case some other student comes through here having the same issue, by the way. Even if I do find the solution I like to record the bugs and how I found to solve them.

OH MY GOD! So fucking stupid... Solved, though. I had accidentally selected "M_Metal_Burnished_Nickel" in my "Select" node at the end of the line, emphasis on the "Nickel" since I was actually meant to use the "Steel" option as I had chosen for my magnetic metal objects (like I said in the last comment). Such a facepalm moment when I saw that. That Nickel material wasn't magnetic, which I suppose somehow lead to the blueprint settling on it and not trying to change it again since Magnetic =/= true anymore for the mesh meaning it ignored the object in one of the branches as it's meant to, but only because it's not meant to be that material in the first place! 😅 Edit: yeah, so I realized how it happened. I had liked the brushed steel, so I went with that, but I just realized while listening again that you had chosen the brushed nickel. So I just did it as you said it rather than switching to steel like I had in the other cases. Silly me. Didn't even need to make the change to the steel one, but I added an hour or so of debugging just for the fun of it I suppose. 😂

Yeah, getting a copy with the "Get" node worked great right off the bat. If it fails later on I'll come back and say so for the next person who has the same issue. Just wanted to say right away so I don't forget to come say it worked later on.

As if to make this silly little issue even more silly the "Line Trace For Objects" node's "Get Hit" pin can directly "Break Hit Results". Go figure.

Okay, I did have to run it at 0.75% speed, but I finished and it all worked out. I do still prefer the older slower style, but this does work. The one thing that's not working in mine is that I'm trying to get my Cryonis blocks to lift a door I made out of one of the third person template blue blocks, and the ice block won't move it. I can stand on it, obviously, but I might have missed a step when you set up the collision for the animated collision box or something, or maybe the door you had in your example doesn't function the same way as these physics object cubes. Hard to say at the moment. I'm gonna go back through the video to see if I missed something, and maybe I'll just muddle through solving it if there isn't anything there to explain. Kinda wish the door was included in the tutorial since the block interacting with environment objects is kind of half the point of the spell and it's a good starting point on those. But I'm not using Cryonis 1:1 in my game anyway. I'm gonna chop shop this thing and use it for other things like spawning in a "tanglebriar" thorn elemental and an animated snowman or something. May use this as a starting point for placing buildings in an RTS in the future too if I ever get around to making one of those.

Went through it all. I didn't miss anything. I'm wondering if you had a solution in the collision settings that you left out or if you made that door programmed to detect collision events with any ice cubes, and then move upward at the same rate of growth of the cube to the appropriate height off of the water.

Last vid in the series mentions a video that covers combat systems

@bigcharlie96 ah, I finished the series but I haven't seen that video. Or do you mean the recommendation for "code like me"? Because I did see that and have been learning from that guy. His also is adding the multiplayer element I need, so I am enjoying his tutorials. For a number of reasons Code Like Me makes me move significantly slower on my work which is a downside, but it's pretty good otherwise.

Man, I'm also going through these all these 5 years layer. I rebuilt them out of some icons online with some "off brand" style to them. Did you get yours sorted, or would you like us to link up so I can share them with you? I know KZbin won't let me just post an external link here to a folder in my Google drive since KZbin hates links in comments, but we could fine a way if you need them.

Never mind i fixed it

Great totorial though!

In the Glide function RIGHT after the function starts and before the "Line Trace By Channel" go ahead and add a Branch node. Make the condition "IsExhausted?" and lead "False" into the "Line Trace By Channel" node. On the "True" side you can then do something fun like print "I'm too tired to hang glide!" to the screen until something more final can be added. An idea for something final could be an audio queue and animation indicating you're exhausted, like maybe the character fumbling around in their pocket but being unable to produce the glider, or maybe even pulling it out and the glider rips out of their hands and flies away only to reappear next time. Something like that. Or just leave it at that and don't let the hang glider appear at all. Either way. Good luck! Also I hope you found the solution already and this was too late for you, but even if so it's good to answer your question for the next guy! 😆