godot_recipes
godot_recipes copied to clipboard
kidscancode
[Discussion] Arcade-style Car
I'm struggling with getting the raycast working on this. I don't have the track like you have, just a cubemesh and cubecollisionshape on a staticbody and my raycast.is_colliding is always false.
I'm struggling with getting the raycast working on this. I don't have the track like you have, just a cubemesh and cubecollisionshape on a staticbody and my
raycast.is_collidingis always false.
Surprise, right after I created the comment I found a fix. I moved the raycast up 1 unit and extended the cast from (0, -1, 0) to (0, -2, 0)
Hey there, great tutorial! I was wondering if there was a good way of adding a larger collision shape to the car model itself. I tried a variety of things but nothing really worked. One weird thing is that I added a kinematic body as a child to Vehicle/Mesh and then a square collision shape as a child to the kinematic body but this caused the car to fall through the race track mesh and keep falling into infinity. Did not expect that. That a bug perhaps?
The kinematic body was probably colliding with the sphere. It's generally not a good idea to parent a kinematic to some other moving object because then the collisions won't work well. Kinematics are designed to be moved manually in code.
I'd say your best bet would be ty try using a RigidBody in Static mode for this.
Yeah I actually ending up getting it to work by assigning the world, vehicle ball and car collision mesh on three different layers and then masking.
If this helps anyone, I realized that the scale of the car needs to be kept at 1, otherwise the orthonormalize call will set the car mesh back to scale 1 (which I believe is the point of normalization), and your car will be massive when you turn it. The track and the cars have very different scales, so it gave me an issue for a while.
I'm struggling with getting the raycast working on this. I don't have the track like you have, just a cubemesh and cubecollisionshape on a staticbody and my
raycast.is_collidingis always false.Surprise, right after I created the comment I found a fix. I moved the raycast up 1 unit and extended the cast from
(0, -1, 0)to(0, -2, 0)
Yes, I was having the exact same issue and I couldn't understand why. Then I downloaded the project and randomly looked at the transform of the RayCast and saw that it was translated 0.25 units in the Y axis.
Even though the car is a rigidbody, it always clips into or through other staticbody nodes, besides the one directly under it... Anyone know ant fixes for this?
I've done a brief attempt to get this running on Godot 4, there is a few trivial things like shadowing variables and update() getting renamed to queue_redraw()
But a few issues remain that I don't know how to solve:
E 0:00:01:0232 Invalid render mode: 'depth_test_disable'. <C++ Source> :2 E 0:00:01:0232 set_code: Shader compilation failed. <C++ Error> Condition "err != OK" is true. <C++ Source> servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:137 @ set_code() W 0:00:01:0234 instantiate: Node './mergedBlocksClone' was modified from inside an instance, but it has vanished. <C++ Source> scene/resources/packed_scene.cpp:178 @ instantiate() E 0:00:01:0302 version_get_shader: Condition "!version" is true. Returning: RID() <C++ Source> ./servers/rendering/renderer_rd/shader_rd.h:140 @ version_get_shader()
There is also broken paths, like: E 0:00:01:0234 BallCar.gd:9 @ _ready(): Node not found: "CarMesh/tmpParent/truck/wheel_frontRight" (relative to "/root/TestScene/carTruck"). <C++ Error> Method/function failed. Returning: nullptr <C++ Source> scene/main/node.cpp:1364 @ get_node() <Stack Trace> BallCar.gd:9 @ _ready()
I don't know much about godot yet, so I don't know how these can be fixed.
That first error is with the shader. There are some changes to shader language in 4.0 that need to be made.
I'm nearly done with the 4.0 version of this, which I'll be posting soon.
If you're new to Godot, I really wouldn't recommend trying to translate things from 3 to 4 - while most of the changes are minor, there are subtleties that you're not going to have a way of knowing. To be honest, I'd still recommend sticking with 3 for now, as there are a lot more learning resources. There's nothing substantially different at the beginner level, and moving to 4 later will not be difficult. It's not a matter of "unlearning" things, it's just some changes that will be easy to handle once you have some experience.
I was looking into conversion to godot 4 as I haven't found a code-driven menu system for 3.5 but only godot 4 and porting that back to 3.5 seemed like more work.