Use decompiled buggy which comes with SourceSDK, if you decompile a car yourself note that mdldecompiler makes a mess. You can find it here: <drive letter>:…\Steam\steamapps<acc_name>\sourcesdk_content\hl2\modelsrc\Buggy
$attachment wheel_fl "Dummy04" 0 0 0 rotate 0 0 0
wheel_fl is name of attachment and its best if you leave it like this, Dummy04 is name of the bone this attachment is “attached” to, its name can be anything (you name it while rigging the vehicle), but in this case (since its wheel_fl) its obvious it has to be attached to the bone of front left wheel. The numbers 0 0 0 are offsets (x y z), if you want to move the attachment without moving the bone it is attached to you change these.
The three bones you see are named: FL_Suspension (the long one), FL_Steer (the middle one) and FL_Rotate (the one marked). If you wrote $attachment wheel_fl “FL_Steer” 0 0 0 rotate 0 0 0 the attachment would be almost at the center of the wheel, maybe moved a little bit to the inside. That would be a good position for this attachment. Attachments are usually used to mark something (a position) so that the game engine will know where it is. For example, there is an attachment called engine. You position it where vehicles engine is so that when car is destroyed flames will be coming out of the engine. If you put this attachment for example in the cabin flames would come out of the cabin.
What do bones actually do?
Bones control movement and rotation of an object. For everything on a vehicle that will be moving independently (wheels, dashboard pointers, …) you have to create at least one bone (in addition to the root bone). Why at least one? Because you also have to create a bone for every type of move the object is supposed to make and then link them together. By every type of move I mean, if we take a wheel for example: suspension bone will move the wheel up and down, steer bone will rotate it left and right and rotate bone will rotate (spin) the wheel. Thats three bones for one wheel. (In game wheels are actually represented as spheres: http://shrani.si/f/40/pc/3NV5Y5Yg/countryside0007.jpg and that wheel_fl attachment marks where the sphere will be, thats why you want to put it as close to the center of the wheel as possible and a little inwards - why a little inwards? because when you hit a wall sphere will bump into it which is not natural - wheel in real life isnt spherical).
Bones are usually in hierarchy. That means that you create one bone called “frame” which will be the root. You usually connect to it every object that wont be moving independently, like carrosserie. For objects that will move independently, you have to use a new bone and that new bone will be linked to the frame bone, and the object itself will be linked to this new bone - the bone you created acts like some sort of intermediary between your object and frame bone. That means that you link to it the suspension bone because suspension holds entire wheel. Then you link steer bone to suspension bone and rotate bone to steer bone. You have to think logically here - which movements are higher in hierarchy than others. For example, it doesnt matter how the suspension bone will move, frame bone will always be its parent and if parent moves - child moves too. The hierarcy usually looks like this:
Note: that these bones arent necessary for your starting vehicle: sitpos, enter1, enter2, view, brake, engine, tachometer, speedometer. So why are they there? Well for brake, tachometer and speedometer I think its pretty obvious, but theres a trick for the rest. You see, for each of these thigs you will have to create an attachment in the qci file:
$attachment "wheel_fl" "FL_Rotate" -1.00 0.00 0.00
$attachment "wheel_fr" "FR_Rotate" -1.00 0.00 0.00
$attachment "wheel_rl" "RL_Rotate" 0.00 0.00 0.00
$attachment "wheel_rr" "RR_Rotate" 0.00 0.00 0.00
$attachment "vehicle_driver_eyes" "View" 0.0 0.0 2.0 rotate 0 0 0
$attachment "vehicle_feet_passenger0" "Sitpos" 0.0 0.0 0.0 rotate 0 0 0
$attachment "vehicle_engine" "Engine" 0 0 0 rotate 0 0 0 //fire goes out when destroyed
$attachment exit1 "enter1" 0 0 0 rigid
$attachment exit2 "enter2" 0 0 0 rigid
$attachment enter1 "enter1" 0 0 0 rigid
$attachment enter2 "enter2" 0 0 0 rigid
Now, attachments HAVE to be linked to a bone, and if there is no bone to link them to (linke engine, sitpos, view, …) you have to attach them to the frame (root) bone and move them around manually. Now that is a pain in the ass because for each mistake you make you have to recompile again and again to see if its in good position. Well you can make your work half easier by making bones for each of those attachments and its MUCH easier to move the bones around in 3d modelling program than moving the attachments around. Those bones dont do anyting, they just sit there to mark position for attachment they were created for.
Btw Cannonfodder’s Studio Compiler has an updated version of mdldecompiler integrated in it I think, try your luck with that.
Sorry if I made a mistake in my speedy writing. Please anyone who knows this stuff correct me if im wrong or if anything could be explained in a better way.