I’m trying to do a wall-hugging system and trying to implement MostHost_LA’s wall hugging solution, or ClockworkOcean’s but I have no clue how to go about the latter at all. I was thinking of checking the angle of the sphere trace but of course it doesn’t work.
Check for corners event:
Check if currently wall hugging while moving:
Debug:
So how would I check and know what corner it is I can turn, as well as program the character to switch to that side.
Thanks to anyone who answers.
Not sure if that’s going to help much but consider adding it to your research:
And do check out this post:
If it needs to be predictive, the check needs to be done ahead of the actual position by speed * delta time.
There are a few oprions, but you can use the besic idea of what you have here if you aren’t dealing with labyrints that require precise positioning (ei a packman like level).
Since you are running a separate spehere check.
2 things to consider:
Another thing.
The way I always set things up I have booleans allowing or preventing movement.
That way, its reivial to toggle which way the movement goes to automatically turn corners…
Thank you for sending me to the links, I’m assuming those line traces are how this person’s trying to check all of the angles. Also, got introduced to a new node Stop Movement Immediately Node which is always nice, I’ll try to incorporate that somehow with what MostHost_LA said below with the checks to stop movement. I’m trying to limit context sensitivity so I’d like to just have the player stop moving when it reaches the corner and have them decide to press the button to do the turn manually.
I’ve been having this issue where I’ve been trying to keep it so that the player could only move parallel to the plane they’re constrained to and no further, unless you press to exit cover or reach a corner and press the button to turn the corner. That’s why I was checking to see if it was constantly overlapping.
Instead of having speed by delta time which is probably going to be requiring tick, could I just use my character’s velocity instead, since it is acceleration and I think it would functionally serve the same purpose. Because I already constrained my character to a plane, that means they can only move in certain directions. I’m curious, why would I need a box, and what should be the position of what I’m checking. I originally thought that I would need to be at a location where I should check where I am, then try to somehow figure out what angle the wall is compared to me, or something similar. Ah I think I see, I probably shouldn’t be starting the trace where my character is.
I’ve tried using velocity instead and it does seem to be working pretty well, it gets longer as the character accelerates ao I think it helps with the predicting.
Movement already happens every tick, out of the axis input.
For AI, I’d do it slightly different anyway. Theres probably no reason for the AI to be stuck to a wall movement wise…
I see, so why is it that I would need a box, are you talking about replacing the sphere trace with a box trace? What would be the difference? I’m actually going to test that and see how it goes now that I’m able to be on my computer, if I use velocity the trace gets longer exponentially.
I guess my question is is there a way to make it so that the trace knows where it’s not hitting anymore? Because once it realises it hits something it continues registering as hitting something. I was thinking of using a multi-sphere/box trace but I’m not sure if that’s the correct way of using it.
Box vs sphere because of the shape - a box detects precise measurements, a sphere could give false positives.
So, you got to the wall. You are snapped into it.
All you need to be tracing is when it ends.
Doesn’t seem like you are tracing for that…
I see, so if I do a box trace, it would still have to be a multibox trace and checking to see when the trace becomes false right? Because currently even with a box trace it’s still true as long as it touches the wall the player’s against, once it makes past a certain threshold it becomes false. With a box trace, would I be setting the half size of the box to be equal to the half size height of my capsule then? Originally I made the sphere trace to be as big as my capsule component attached to my player character, but basically the box trace has to be the size that will precisely touch the wall but won’t be bigger than it?
I wouldn’t even bother tracing the wall. You know it is there from the initial check.
Constraint movement along the wall cross of impact normal.
Then check a box or a line trace of where the direction is, beind the character just like represented by the graphic.
If the trace is ever false, you know it is a corner
Ah I see, so I ended up doing the trace in the wrong direction. Now it should be the right direction, however then the trace would have to be offset by speed * Δt or a specific distance based on direction of the movement?
So I’m thinking about this, I think what needs to be done is offset the start of the trace by the direction that the character’s moving in, I’m not entirely sure how to do that asides from grabbing from
I would only prevent movenet in the direction you know is a dead end.
And I’d do that by directly disabling the input with a bool branch.
Ofc, this depends somewhat on what the game should work like.
But disabling input from further processing is definitely the way to go - as it will allow all other directional inputs. Yet prevent movement in the direction you cannot go.
Can move? Proceed.
Axis > 0 & Can move +Y ? Proceed.
Axis < 0 & can move -Y ? Proceed.
All the branch falses literally do nothing (unless you have to run some code on tick or something, which you can hook into any axis input).
Theoretically, even for 3rd person, if you constrain the movement to the wall/cover axis, then the sideways input won’t matter.
But you could cause a situation where diagonal (.5y, .5x) axis values cause some movement, so you may have to disable the X or the Y entierly depending on the wall world-to-player controller angle or something.
No problem, I’ll try implementing that today, and edit this post and show my progress on that, thanks for explaining the conceptual idea, so what I’m understanding is that you basically have to check if you should disable input entirely first, then disable input in specific axis.
Could I make CheckForCornerInNextStep as a constant method returning whether the box trace hit or not, with the checks being written following a guard clause in blueprints?
So I just tested disabling inputs and it doesn’t work.
Disable movement does work, kinda.
Booleans and branches.
Keep it simple just like the pseudo code…
If a path can’t reach the movement node, thats all you need.
Also, to keep controller and keyboard input the same, you may want to manually control the axis value.
If > 0 ? 1 : 0
If < 0 ? -1 : 0
Mhm, I’m not exactly sure where to put the checks, can you somehow show me on the blueprint where I’m supposed to do that? I’m assuming it would be after the box trace but I need clarification. Thanks.
Quick example - it doesn’t have the direction check, but I think you can work that yourself after understanding where to place it…
Ah I see then, I’ll see if I can work that into my project, and edit this post when I make progress, if it lets me by the time I manage to.
Before I read your post though, I had the code that handles movement and constant method that handles whether player can move written. It doesn’t work consistently and bugs out.
While I’m trying to figure out the direction (version control exists), how would the logic for figuring out what corner to turn work? Would that require line tracing in 8 directions, but I don’t think that would be necessary because all corners would just be 90°. Or would that somehow require a check by ‘sweeping’ from 0-90° (like making a custom trace shape, just checked, you can’t do that), if there’s a hit, then there’s a corner and you can turn.
You should always know what corner it is just from the position you are in and the controller input.
Obvioulsy you have to check too, but you can just check the direction the user wants. Its less work.
If you have to automate it, then just check both possible directions.
If you want to be picky, you can use sphiel trace with the dimensions of the player capsule to see if the player can actually pass.
That’s useful for not having to worry about checking procedurally generated levels…
Hi, I’m back, so I was thinking of doing the direction check this way,
So inside CheckForCornerInNextStep, I pass that in and do the check. I don’t bother to check MoveForward’s axis value because it’s always 0 while in cover, I already tried debugging it on screen. I also tried having the checking whether this method is true or false in the `MoveRight’ event, doesn’t work.
Although I’m getting the camera’s rotation, it’s in the same direction as the default UE coordinates so I don’t think that should be the issue.
I also have to take into account of the horizontal axis being -1 though. If the axis for MoveRight is 0, then the character won’t move anyways.
There’s just one problem though,
So left and right is mapped to A and D. So I have to press A and D to determine the direction of the box trace even though I’m just moving with W/S, wish I can show you my button presses somehow but I think it’s easy to imagine.
Moving horizontally doesn’t have that issue.
I was thinking this might be the issue, but I already did constrain the movement to the cover axis.
I’m not sure if I’m not getting the axis value correctly? But I debugged it on screen.
Either that or I have to get something else to determine direction. There is a formula: velocity = speed/magnitude * direction, I think I might just have to rearrange the equation to get the direction. Question is how do you get magnitude.
Wait no, normalising a vector gives its direction, so normalising velocity should also return a direction. Specifically the unit vector. Ok, yea, it’s making a box trace in the direction of movement now. Still one problem which is that it still keeps moving even if the box trace is false.
