I’m struggling to get what I hope is a fairly straight-forward thing to do, but only when you know the answer, of course! I’ve tried various things out, but now I’m stuck and no further forward.
I’m trying to align m character in the correct place and orientation to play his animation of him swinging across the bars, when he enters the trigger volume. I know the animation doesn’t line up. yet. One step at a time, though.
The MonkeyBar_BP has two volumes to start and stop the swinging animations.
When the character enters the START_TriggerBox volume, it casts the ‘swing’ boolean to the Character_BP which, in turn, sends to the Animation_BP.
I want to align him to the position of the blue (test) object.
I still haven’t got my head around casting and whether a ‘Cast To’ is pulling information from another BP or pushing it to a BP; so, the variable can be read?
“Cast to” is just a check to see if the blueprint you are communicating with is actually the correct type of blueprint.
Imagine if your character blueprint has an inventory variable. You want to access that variable. But then, for whatever reason, the reference you are using to access the player character contains a different type of blueprint instead. Maybe a gun or enemy or something else that doesn’t have an inventory.
So if you try to get the “inventory” variable from the gun blueprint, you will get an error that crashes the software. You tried to get a memory address that does not exist.
That’s why casting is a thing. It’s used to make sure that you are actually accessing the variable from a blueprint type that contains the variable.
It can also be used as a nice “if, then” cascade, where you check if your reference is blueprint type X, then type Y if it isn’t and then type Z if it’s not Y. And each path will lead to a different set of instructions.
Anyway, casting allows you to directly interact with the properties of the other blueprint. You can read their variables or set them, unless they are set to private.
I hope the explanation wasn’t too wordy.
As for your actual problem, there is apparently a way to connect characters to splines and force them to follow the spline’s route. However, I’ve only found people asking how to do it but not people explaining it.
This guy shows how to do the splines and showcases movement along the splines:https://youtube.com/watch?v=kJyWSzfwEk8However, he forgot to explain how he’s doing that movement. You’d also need to find out how to make it interactive instead of automatic.
I hope this makes your search easier, at least.
If it was just a check I’d assume that you could leave it out, but you can’t.
The following youtube video has got me a bit closer, but it’s working on the Level BP and I’m trying to get something similar working from my MonkeyBar_BP > Character BP. It’s a lot harder than I thought it would be. I’ll keep chipping away at it, though.
You can, actually.
The cast can be dropped whenever it’s clear which type of blueprint you are referencing. You even get a compiler warning if you use cast anyway.
These are two variables. The first is of type “PlayerPawn”, the second of type “Pawn”.
Both contain a reference to a “PlayerPawn”, but because only the former is guaranteed to be of class “PlayerPawn”, it’s the one that can access “Current Health” without a cast.
The second one needs the cast because the editor cannot be sure that it’s a “PlayerPawn” in that variable.
So do you want the character to move automatically or do you want to have actual control over the movement?
The approach in that video is more for something like a grappling hook.
I used a “on hit” node on the spline, which calls a function on “other actor”, by casting to the actor. It sends over a reference to itself so that the player pawn can access data from the spline.
I’m not 100% sure on how I want it to work. I have a few ideas, but not sure on the best approach. I’m an animator by profession and the scripting part of it is quite alien. Though, I know a fair bit of 3ds Max MAXScript and Arduino sketches.
My thoughts on the overhead ‘monkey bars’ is this: -
Idea 1: Run the player into the trigger volume. This aligns the character with the first rung, in the correct orientation. Pushing forward on the joypad swings him from rung to rung, until he reaches the end. The second trigger volume returns him to his normal idle/walk/run Blend_1D.
The problem I have here is that the controls are set up so that if I pull down on the joypad, the character runs towards the screen… and not backwards. i.e. it’s not an over-the-shoulder 3rd person control mechanism. I would need to change the way the camera works and also lock any lateral, side-to-side movement.
Idea 2: Have the camera swing round to turn the swing into a “side-scroller”. So, only left and right on the joypad work and lock any other movement.
Idea 3: Have the whole swing set up as a ‘Montage’ and have the player do button presses for each swing, checking for Notifies in the Montage animation loop.
I have VERY little knowledge about setting up Quicktime Events and Notifies. Though, I know how the Montage system works a little.
I knew nothing about curves/splines until today. Thanks for letting me know about them. I’ll do a little digging. It’s all a learning experience for me. Games I’ve worked on, in the past, I never went near the coding/level design scripts, but I’m really interested in it all. I don’t have to know it for my current job, but I always like to learn something new.
I’ve managed to get the player moving to a spot when he enters the trigger volume, but he’s moving to the BP’s root location and not the location of the component ‘Start Point’ within the MonkeyBar_BP. Any ideas?
Got it working as needed. The GetWorldTransform on the Start Point seemed to be the problem. I changed it to a GetInstanceTransform and toggled the World Space boolean (or the player would just fly off to 0, 0, 0).
Hopefully, I can use this to align to my other obstacles.
I’ve tried various things out, but now I’m stuck and no further forward.
I’ll keep chipping away at it, though.
