*NOTE/CORRECTION:* I realized this after, but it is important that your test_move functions should use the self.global_transform and not the local self.transform. This because the physics server uses all GLOBAL coordinates. This will still work as long as your player is on the top layer with no parent. But it will break if you have your player as a child of a spawner or other node which has been translated. github.com/majikayogames/SimpleFPSController/commit/5a4e09d3ab9eff9be9e7c5fff68966ec38da53a9
Hey, quick request/question! I'm wondering if you would be willing to add multiplayer support into this project at some point? Would be interesting to see how you would handle all the movement and everything across two clients.
@@oscarishino5883 however i removed a bunch of things like moving physics props, as my game isn't gonna focus to much on moving physics, but if you were to handle something like that you would handle it serverside. My advice is to do little by little, I'm almost done with syncing the movement script and I'm gonna add the weapons manager soon
Such an elegant way of testing for overhead collision when crouched. I hate to admit, but until today I used a ray cast for that :) What I did was take your script file on the git, and rewrite my PC script manually while going through yours on the second monitor. Hopefully some of the good stuff you implemented sticks under the dome. Thank you for your continued work.
Glad you found my code useful and were able to incorporate it into your own! Wasn't sure if most people would follow the tutorial the whole way through or if people would want the individual components so I tried to do a mix of both. The raycast for crouch, that's not a bad solution, I think it would actually be cheaper/slightly faster than running a body test move every time, but I prefer this method as it's less error prone, as we are using the actual shape of the character body to 100% know it won't clip into anything.
@@MajikayoGames That's exactly why I find your method betther - it uses the shape of the body. There is one less thing to fiddle with in case of changes, so one less item to break and debug..
I've been working on my own source/valorant inspired project for the last couple of months and your channel is exactly what I've been looking for. You've covered everything I could ask for and more, even had the same idea for portals that I did a while ago. Can't wait for more videos!!
I wanted to add my crouch as a state in the state machine but it was just TOO much code. I would have had to add ground and air physics to the crouch state and that would have been the biggest headache and also my character transforms weren't reverting back when releasing the button. So I decided to make my crouch a single function instead, the way yours is. And it works great! But I did have to edit some values. Even though my nodes are practically identical to yours, my camera kept clipping through the floor. The game would start with my $Head height at 0 instead of 1.79 and when crouched it would move down to -0.7. So I changed my head movement to: %Head.position = Vector3(0,(CROUCH_TRANSLATE if is_crouched else 1.79),0) and now it works. But I don't know why it was different for me.
It sounds like your nodes are positioned differently. What I showed here is dependent on all head/camera nodes being positioned at 0,0,0 and only the HeadOriginalPosition node being moved (to 1.79)
When you say floor height, do you mean like way below the player, clipping below the ground like 20 feet? Or do you just mean the camera lags a little too much toward the ground? I assume you mean you followed my stairs tutorial too? If it's the latter, it would just be a case of adjusting the smooth speed a bit to your use cases. The way I found the particular values in the tutorial was just by fiddling with it and trying a few different speeds, making it dependent on velocity/constant speed, etc. So I would say just fiddle with the speed and try a few different things till it fits your needs/level. If you're talking about the camera clipping way out of bounds, that sounds like a bug and not how the camera smoothing function or crouch head translate should work. I haven't ran into that myself so first thing I would do is compare your code to mine exactly to check what is different, and also compare the node structure of your character. This depends on the head/camerasmooth/camera nodes all starting at 0,0,0 with the HeadOriginalPosition being the only one moved. this is because all those nodes drift back towards 0,0,0 with crouch/smooth/headbob.
@@MajikayoGames By floor height i mean that the camera goes to the player character's feet, which should be the local origin of the playercontroller node. I did follow the stair tutorial too and if i recall correctly, the issue only started appearing after finishing that video
@@raminkuntopolku8636 that sounds like it is due to the positioning of you head nodes. take a closer look to how i positioned them, i go over it at 1:30 in this tutorial. it smooths to (0,0,0). this is assuming you have a separate HeadOriginalPosition node at (0,whatever_your_head_height_is,0). so the local 0,0,0 on the camera/smooth/head should be at head height as it is a child of HeadOriginalPosition at (0,1...,0) or whatever
It's possible I simply have an error in my code, but I wanted to ask about a bug I am seeing. When auto_bhop is true and jumping on stairs, I can sometimes get the player to launch high into the air. I think this is because in the physics process, if the player is holding "jump" while snapping to the stairs, the velocity.y can be increased for multiple frames in a row. if is_on_floor() or _snapped_to_stairs_last_frame: if Input.is_action_just_pressed("jump") or (auto_bhop and Input.is_action_pressed("jump")): velocity.y += jump_velocity _handle_ground_physics(delta) I am thinking about adding a jump cooldown timer that would prevent this behavior.
Interesting, mine doesn't have this issue because I'm using self.velocity.y = jump_velocity rather than +=. I guess it is still "jumping" multiple frames in a row, but sticking to the stairs and preventing character from going up. You did make me realize this was the cause of another very mild bug I was having, where I stuck to floor when walking up ramps and was unable to jump. Thanks for your comment. Added a fix for this. You should be able to use this in _snap_up_stairs_check or use = instead of +=. I'm doing both. github.com/majikayogames/SimpleFPSController/commit/129db8820437cbed70744bbaad4e16fc69bb75c8
@@MajikayoGames Thanks for the quick reply. I updated my _snap_up_stairs_check and _physics_process functions and I no longer have the launching behavior. I also wanted to thank you for taking the time to make these videos. The explanations you provide are useful to understanding what the code is doing and I have learned many new features of the engine that I did not know before. Keep up the great work!
@@davidledeboer7870 Awesome! Appreciate the comment! Super glad they are landing. That was exactly my intention. Providing people code to use for free/tutorials on practical topics that many use but maybe aren't covered, and try to sprinkle in as many explanations and useful tips as I can in each one. If someone watches them all, hopefully more and more/some of the more advanced ideas will start to click.
*NOTE/CORRECTION:* I realized this after, but it is important that your test_move functions should use the self.global_transform and not the local self.transform. This because the physics server uses all GLOBAL coordinates. This will still work as long as your player is on the top layer with no parent. But it will break if you have your player as a child of a spawner or other node which has been translated.
github.com/majikayogames/SimpleFPSController/commit/5a4e09d3ab9eff9be9e7c5fff68966ec38da53a9
Hey, quick request/question! I'm wondering if you would be willing to add multiplayer support into this project at some point? Would be interesting to see how you would handle all the movement and everything across two clients.
@@oscarishino5883 It's not so bad, I'm doing it right now with the source movement code implementing networked splitscreen, might do a template soon!!
@@oscarishino5883 however i removed a bunch of things like moving physics props, as my game isn't gonna focus to much on moving physics, but if you were to handle something like that you would handle it serverside. My advice is to do little by little, I'm almost done with syncing the movement script and I'm gonna add the weapons manager soon
Such an elegant way of testing for overhead collision when crouched. I hate to admit, but until today I used a ray cast for that :)
What I did was take your script file on the git, and rewrite my PC script manually while going through yours on the second monitor. Hopefully some of the good stuff you implemented sticks under the dome. Thank you for your continued work.
Glad you found my code useful and were able to incorporate it into your own! Wasn't sure if most people would follow the tutorial the whole way through or if people would want the individual components so I tried to do a mix of both. The raycast for crouch, that's not a bad solution, I think it would actually be cheaper/slightly faster than running a body test move every time, but I prefer this method as it's less error prone, as we are using the actual shape of the character body to 100% know it won't clip into anything.
@@MajikayoGames That's exactly why I find your method betther - it uses the shape of the body. There is one less thing to fiddle with in case of changes, so one less item to break and debug..
I've been working on my own source/valorant inspired project for the last couple of months and your channel is exactly what I've been looking for. You've covered everything I could ask for and more, even had the same idea for portals that I did a while ago. Can't wait for more videos!!
This series is so great for someone with coding experience who's new to godot (me 😊) Thank you!
Thank you so much!!! Great tutorials!
I like these advanced tutorials
Another great video.
Keep going on.
Have a wonderful day.
Adding sliding would be epic like titanfall. I wonder how would you add it into this movement system.
I wanted to add my crouch as a state in the state machine but it was just TOO much code. I would have had to add ground and air physics to the crouch state and that would have been the biggest headache and also my character transforms weren't reverting back when releasing the button. So I decided to make my crouch a single function instead, the way yours is. And it works great! But I did have to edit some values. Even though my nodes are practically identical to yours, my camera kept clipping through the floor. The game would start with my $Head height at 0 instead of 1.79 and when crouched it would move down to -0.7. So I changed my head movement to:
%Head.position = Vector3(0,(CROUCH_TRANSLATE if is_crouched else 1.79),0) and now it works. But I don't know why it was different for me.
It sounds like your nodes are positioned differently. What I showed here is dependent on all head/camera nodes being positioned at 0,0,0 and only the HeadOriginalPosition node being moved (to 1.79)
@@MajikayoGames Holy crap you're right. That was the only thing I forgot to change.
Good video, love your progress. I also got the bug fixed on the random gen code so we’re in business! Will be following anything you post.
Good to hear you got it fix and thanks I appreciate that :)
я весь день пытался понять и воспроизвести прыжок как в hl2 это было кошмарно, спасибо за видео
i have an issue where while going up stairs will set the camera to floor level. It also seems to happen if i hit the edge of an object while jumping
When you say floor height, do you mean like way below the player, clipping below the ground like 20 feet? Or do you just mean the camera lags a little too much toward the ground? I assume you mean you followed my stairs tutorial too? If it's the latter, it would just be a case of adjusting the smooth speed a bit to your use cases. The way I found the particular values in the tutorial was just by fiddling with it and trying a few different speeds, making it dependent on velocity/constant speed, etc. So I would say just fiddle with the speed and try a few different things till it fits your needs/level.
If you're talking about the camera clipping way out of bounds, that sounds like a bug and not how the camera smoothing function or crouch head translate should work. I haven't ran into that myself so first thing I would do is compare your code to mine exactly to check what is different, and also compare the node structure of your character. This depends on the head/camerasmooth/camera nodes all starting at 0,0,0 with the HeadOriginalPosition being the only one moved. this is because all those nodes drift back towards 0,0,0 with crouch/smooth/headbob.
@@MajikayoGames By floor height i mean that the camera goes to the player character's feet, which should be the local origin of the playercontroller node.
I did follow the stair tutorial too and if i recall correctly, the issue only started appearing after finishing that video
@@raminkuntopolku8636 that sounds like it is due to the positioning of you head nodes. take a closer look to how i positioned them, i go over it at 1:30 in this tutorial. it smooths to (0,0,0). this is assuming you have a separate HeadOriginalPosition node at (0,whatever_your_head_height_is,0). so the local 0,0,0 on the camera/smooth/head should be at head height as it is a child of HeadOriginalPosition at (0,1...,0) or whatever
It's possible I simply have an error in my code, but I wanted to ask about a bug I am seeing.
When auto_bhop is true and jumping on stairs, I can sometimes get the player to launch high into the air. I think this is because in the physics process, if the player is holding "jump" while snapping to the stairs, the velocity.y can be increased for multiple frames in a row.
if is_on_floor() or _snapped_to_stairs_last_frame:
if Input.is_action_just_pressed("jump") or (auto_bhop and Input.is_action_pressed("jump")):
velocity.y += jump_velocity
_handle_ground_physics(delta)
I am thinking about adding a jump cooldown timer that would prevent this behavior.
Interesting, mine doesn't have this issue because I'm using self.velocity.y = jump_velocity rather than +=. I guess it is still "jumping" multiple frames in a row, but sticking to the stairs and preventing character from going up. You did make me realize this was the cause of another very mild bug I was having, where I stuck to floor when walking up ramps and was unable to jump. Thanks for your comment. Added a fix for this. You should be able to use this in _snap_up_stairs_check or use = instead of +=. I'm doing both.
github.com/majikayogames/SimpleFPSController/commit/129db8820437cbed70744bbaad4e16fc69bb75c8
@@MajikayoGames Thanks for the quick reply. I updated my _snap_up_stairs_check and _physics_process functions and I no longer have the launching behavior.
I also wanted to thank you for taking the time to make these videos. The explanations you provide are useful to understanding what the code is doing and I have learned many new features of the engine that I did not know before. Keep up the great work!
@@davidledeboer7870 Awesome! Appreciate the comment! Super glad they are landing. That was exactly my intention. Providing people code to use for free/tutorials on practical topics that many use but maybe aren't covered, and try to sprinkle in as many explanations and useful tips as I can in each one. If someone watches them all, hopefully more and more/some of the more advanced ideas will start to click.
👍
is it intended to press jump first then crouch?
yes this is how crouch jump works in source games