In the process of sweeping changes to how the game loads vehicles and other data. A lot of data the describes how the virtual cockpit works, where you sit, angles of views etc. was not available early on and since my long term plan is a system in which we can serve you new vehicles down the wire, even adding the Chinook was going to need a bit of fiddling around. Some data was in the object LUA, some in an external file, some embedded. It wasn't the original intention to build vehicles this way, but it was expedient at the time.

Now it's time to put things right and make a nice neat all-in-one package that's flexible (after all that is my middle name).

Another thing I wanted to do was allow the ability to tie entities to simulation variables, so a cockpit altimeter needle can be assigned to the vehicle.baroaltitude parameter. Hey does any of this sound familiar? If it does then you've done aircraft/gauge development for Microsoft FSX. While this isn't anywhere as deep, it's enough for us to be able to bundle new helicopters and even ground vehicles later on. I'll publish a list of available parameters later when I know the scope myself. MPDs and HUDs can be copied to specified entities using the name of the glass instrument output and the name of the surface you want it displayed on.

* edit*

This is pretty neat, I've now added a bit more flexibility to what we can do with the cockpit inputs. Each individual switch position may now have a delay (hold at this position n seconds before firing) and fire an additional command at that position.

* end edit*

The FFD (dynamics) data could be added too to describe how it flies/drives, that's to be look at later.

There's still a quantity of code required to determine message priority, client/server authority. but at some future time if we want to add "user roles" as a message filter to any control, this is flexible enough for us to drop that in and not rely so much on coded game logic. Filtration and authority of incoming messages are important for multi-crew vehicles in multiplayer, you need to be as lean as possible (I bake state flags into bit fields as much as practical). Not all switches need to be recorded or sent, some are vital (crew helmet positions need fast updates for the HUD and sensors), some (wipers/lights) can be delayed.

The "command" string in the cockpit switch data is sent to the messaging system, if it's a network level command it's forwarded to any needed clients via Raknet.

As our vehicles are 'portals' there isn't much physics going on for attached crews. As a gunner, your helo position comes from the pilot and interpolated, your sensor position is based this, and that in turn is relayed back to the pilot. So there is room for some weirdness but not too much I hope. The way the Apache works actually works in our favour. Since each weapon system has a designated 'crew in command', the game logic knows who's the shooter and the positional data from the client in authority is used. And if you're not targeting a visible entity (e.g tank) then you're aiming at an invisible one (a pivot). This reduces oddities caused by differences of position reported by actual and interpolated crew positions.

Source