A game like ours with multiple view points needs to track where the camera is, the current view might be interior or exterior, might require motion, probably some kind of offset or time based animation. Rather than having multiple cameras and having to do a lot of hiding and showing, parenting and unparenting an abstract camera class was made that took updates, offsets and only applies the end result to the active camera.
I totally forgot about parenting and disobeyed some OO basics (accessing fields outside the class which were supposed to be private). That's now corrected and VirtualCamera properties are updated through the proper member functions. Inline documentation has been added. Slap on the wrist for me. In my defence it's the only class I've done this with and was very much re-written on the fly unlike other elements.
Another thing I did which caused issues was parenting cameras. Parenting objects can cause problems if you have models that use different scales or axis of orientation, or are parented to child objects that have different orientation from it's own parent. It's better I think to set the camera position to the desired object position with and added transform or offset.
Reason for all this camera fiddling was expanding the view system to have a more 'physical' camera that responded to g-forces and clipped against cockpit interiors (rather than passing through geometry). A bit like wearing a helmet.
Research and (some) Development
Going through old papers I found the mass of research (now mostly out of date) for Enemy Engaged Comanche Hokum. In particular the old Ka-52 and Mi-28 helicopters. The Mi-24N and Mi-28N now has glass cockpit features including a modern TADS like system with high-contrast symbology suitable for use with night vision goggles.
![]() |
Mi-28N 'Havoc' cockpit with, 6x8 function display |
![]() |
Havoc's night fighting capability, new avionics |
The Mi-24 Hind got some love too. I mentioned last year, Farnborough had a Polish Mi-24 on display and it was noted that a more modern cockpit was available (not on that aircraft but in general). Anyway the new glass cockpit looks like it uses the same MFD unit as the Havoc, below is a photo of the Mi-24N layout. Note the all black finish for night operations.
![]() |
Mi-24N with night capability and new avionics |
None of this means Combat-Helo will have a Russian helicopter anytime soon. It was mostly to see how much of existing avionics code I have can be adapted for helicopters like the Mi-24 (which is a personal favorite).
Things I'm doing this coming week....
It's my birthday on Sunday, I share(d) it with Ronald Regan, perhaps the funniest and best US president I can recall. I'm pushing 42, my youngest daughter keeps saying "You're not getting old, you're turning into an adult." When she first said this I laughed out loud then abruptly stopped as I had to think long and hard about that one.
What is best practice for exporting animated troop models? I've been looking to the Leadwerks community for ideas. The requirement is having a standard set of animations that can be used for all humanoids and documenting the pipeline for an artist. Animating characters in Leadwerks is quite fiddly, it requires authoring a high level function to manage blending different animations for a typical humanoid character. For example, the upper torso might fire a weapon while running, or walking. What I did earlier was create a standard set of strings for animations and have the frame range for a 'walk' defined in the model LUA file. I'll move this out to an XML datafile to facilitate editing. But I want to use the same animations for different models, e.g civilians, pilots, troops.
![]() |
"Does my bomb look big in this?" |