I’m working on a car chassis, which is intended to be simple using mostly Roblox’s constraints, and it works so far (I’ve only gotten the car to go forwards and backwards as I haven’t implemented steering yet), except for the parts within the car going to sleep whenever the player walks too far away (only about 5 studs) from the car. This can cause issues because for some reason, while the player is sitting in the seat to drive it, they are unable to drive the vehicle because the car is practically anchored. I decided to use the “Highlight Awake Parts” option and… sure enough, the car becomes highlighted when near it, but when walking too far away, or above it, the highlighting goes away. Any suggestions as to what is causing this or how it can be fixed?
I found a slightly hacky solution. The parts start sleeping if they are on the ground to begin with, so they need to start slightly in the air.
Funny enough, I’ve just finished working on a car chassis from scratch that relies on Roblox’s constraints (albeit with my own scripts and not the generic VehicleSeat). Roblox delegates the physics system to players that are in distance of nearby physics parts, so your client would simulate the physics when you’re nearby. When you’re far away, I’d guess it either reverts to the server or stops simulating altogether, which is probably what the awake parts thing shows. So the hinge constraints going to sleep when you’re far is perfectly fine, but this shouldn’t impact the ability of the car to drive since it should be in load distance when the player is in the seat.
Since lifting the car in the air solved the problem for you, my guess is that the car was automatically welded to the ground, as is the default option when moving stuff around. It would therefore make sense that you couldn’t move it, as the weld prevents movement. I ran into a similar issue recently with welds. Always make sure whatever you need to move is not welded to things it shouldn’t be!
When confronted with problems like these in game development (and im guilty of doing this too), it’s helpful to make sure that you’re asking the right question. In this case, the problem you perceived wasn’t causing the main issue and was working as intended, while the real question was, “why is my car not moving?”
I hope I helped you today, best of wishes with whatever you’re trying to accomplish 
I’ve actually already disabled this, long ago, so this wasn’t the problem. My guess is that the car was on the ground so no sleeping checks ran. Now when a player moves nearby, the car does become awake.
My cars all start on the ground and there are no issues with sleeping, even when they start far away, so it would be very strange if that was causing issues in your game and not anyone else’s. Either way, it’s good you found a solution.
Update: I’ve started to have the same problem with my vehicle system, but it can’t be that its due to starting on the ground, as it always starts mid-air. Additionally, it only happens sometimes, say around 10% of the time, and seems to appear and disappear completely every second or so, with tweens being reset and playing again too. Could be a physics bug in the engine. Have you had any more problems? Are you using HingeConstraints that are misaligned/snap on play, or any constraints made during play? Do you have any betas enabled?
Update 2 on the vehicle freezing and solution: Seems like the issue is with network ownership of the vehicle parts (which could easily disguise itself as an issue with sleeping parts, as it would only show those parts are active if the client has network ownership!). I believe this is the case because when the bug doesn’t happen and I call network ownership of the base part of the vehicle on the server, it shows the player, but when the bug happens, it shows “nil”, which means the server has physics network ownership, and is further confirmed by using the “Are Owners Shown” studio setting, which shows the vehicle as being owned by the server when the bug happens, and owned by player when it doesn’t. After messing around for a while with setting network ownership (even on every frame) to no avail, I found a solution which is just inserting a wait(1) into the script after the player sits down in the seat, and before all the script insertion, parenting, and relevant instances are done. I tested over 50 times with this method and the bug wasn’t present anymore. Assuming around 1/10th of the time it happened previously (which seemed to me to be the number), the chance of it not being present due to chance would be ~0.5%, so I’m confident that this is a solution.
I believe this may have to do with the transitional physics state as shown below, where the client doesn’t own the part, but can physically simulate it, which could understandably mess up replication if the client attempts to say, apply a torque to a part it doesn’t own but simulates: