Updated some bits to make it less unbearable, but it's all just a mockup for testing a physics system.  It's definitely not going to be 8 widely spaced launch pads.  It would look better if the 8 rockets were on a single pad.   The real goal is a scratch built physics system which allows the BFR to push itself down the track with no user input.

Upgraded to Godot 3.3.2 which changed the behavior of a lot of functions but didn't materially improve anything.  Old bugs were swapped for new bugs.  look_at no longer reset the scale to 1, but itself became erratic.  Particles changed direction.  Various math operations no longer worked.  Operations on the basis of the transform didn't work anymore.

Godot has had several rewrites of its physics system.

https://godotengine.org/article/godot-30-switches-bullet-3-physics

https://godotengine.org/article/camille-mohr-daurat-hired-work-physics

They have implied the existence of bugs in the physics system without actually saying there are.  The lion kingdom is convinced the infinite velocities & angular rates which tended to happen after a collision were bugs in its physics systems.

The lion kingdom is convinced Asphalt 9 doesn't use any real physics system.  It's all baked keyframe animations.  High level parameters like the number of barrel rolls are based simply on player position or player speed.  No matter where godot goes, a scratch built physics system has gained favor.

Finally discovered the KinematicBody3D node.  Its movement is all user defined rather than physics defined, yet movement is restricted by collisions with other objects.  Its key method is move_and_slide which adds a velocity to the current position & slides along any barriers.  Then, to figure out where the kinematicbody contacted a barrier, call get_slide_collision.  It returns a KinematicCollision, which contains the global coordinate of the collision.

move_and_slide finally made it slide down the track instead of bounce erratically, but it no longer turns to point down the track & it still quickly gets stuck.  move_and_slide gets to oscillating between 2 points, then eventually starts going backwards the same way physics did.  The problem is when move_and_slide collides, it doesn't return the velocity after applying the collisions.  The input velocity keeps increasing in all directions until movement becomes erratic.  The true velocity has to be derived by reading back the change in position.