Today I started work on the VTOL system, which is going to involve hacking flying user controled vehicles into the Source engine. Technically speaking this shouldnt be a problem, it should work like any other vehicle control wise it just wont need a huge heap of physics code attached to it.
I've got the basic classes sorted out, after a spot of copy and pasting around the place, however i'm mildly annoyed with Valve for what I see as a daft design choice.
The basic class layout for a vehical is;
Entity => CPropVehicleDriveable => CPropVehicle,IDriveableVehicle
which, on the face of it seems pretty sane, until you start wandering into the code a bit and notice that CPropVehicle is hardcoded with a CFourWheelVehicle return in its GetVehicle() function and internally it uses an instance of CFourWheelVehicle (the one returned).
Now, on the face of things this isnt such a huge problem as HL2 only ever used 4 wheel vehicles via this system, however from a modding point of view its a slight pain.
What I should really do is go in and rewrite it so that it uses a common base class and make my life easier, and I dare say at some point I'll go back and do it once it becomes a bigger problem, for now I've got CPropVehicle, CPropVehicle2 (for the 6 wheel'd truck) and CPropVehicle3 (for the flying vehicles). However this doesnt answer the question as to why the rest of the code is pretty generic and only required the class names changing to intergrate new vehicle types yet the return type and instance is hardcoded to the 4 wheel'd physics objects?
oh well, I'm sure they had a good reason and if it looked like we were going to stick with Source long term I might be bothered to shout at someone, I'll fix it tomorrow so it sane instead, probably by adding an IVehiclePhysics as the virtual base class for the physics code and maybe creating an CWheeledVehicles class to handle the common wheeled vehicle cases and just speicalise out higher up.. yeah, that seems like a plan to me.