Happy New Year Everyone

Here's looking towards big things this year. *sip*

Here's to absent friends. And my friend Gary, thanks for the present you sent me at Christmas. Cheers David, I owe you big time for your great work.

Here's to Banckrupt Stock, the Piman and Automata UK. We miss you. Here's to all those still born and deceased computing machines.

And thanks to the guys who made Gravity Crash, I enjoyed that.

Happy New Year.


Richard, aka Flex.

Merry Christmas

UFD - Up Front Display

Things you really don't want to see outside of a lamp test...

I've wired up the PlayerHelicopter > Avioncs > Radios to the UFD. All the radios are initialised to default frequencies based on their band (UHF, VHF, FM). Here all warning flags are switched on for a display check, too many to show at the same time.

And this raises and interesting point. This is far too complicated for average Joe gamer. 

Options include parking this module and saving it for the "pro" edition. Then replacing it with an easy radio; simple left<>right channel cycling between: ATC - FARP - Wing - Ground. 

When using 'augmented' controls (such as when playing with a joypad) the radio should be handled for you anyway (by not having any logic checks for tuning etc).

Checkpoints

Started making a few sets to get an idea of what other objects we could use. Assume we place checkpoints to mark boundaries of security zones. Roads approaching to forward bases should be controlled and a semi-permanent road checkpoint established using handy materials, which is a couple of Hesco buckets, wire and an APC or two. There should probably be a small compound or a few small buildings, such a checkpoint is too exposed to be manned in such a manner 24/7.

Could use some wire and road barrier, improvised but clear intent. Still trying to source a soldier model.

These may be subjected to a coordinated attack across several locations during patrols.

Objects to do....

• Power lines
• Telephone lines
• Afghan compound walls
• Afghan compound buildings
• Crop fields
• Concrete blocks
• Concrete bridge
• Mosque
• Flags and poles
• Water Tower
• Spiral Wire Fence
• Road block pole with "stop" sign
• Satellite Dish array
• Dome Tents
• Wooden barracks

Hey Corona

Thanks to a little help from Macklebee Coronas are now working on my models. My scripts used the AABB bounding box dimensions for positioning objects, but there's an issue using those so hard-coding the position in each model will have to do, not a problem.

Next stage is to modify a models LUA code to have Coronas 'blink' at specific frequencies.

Coronas are "glows", halos (well, corona), that are billboards (always facing the camera). Typically used as fake lights or positioned on top of light sources to indicate the source, as lights themselves are not visible.

This radio tower model should have about five lights but due to budget cuts...

Dark brooding skies today. Reflecting my mood.

Duststorms cont..

Two new screens from Combat-Helo.

The 3D effect works better, using a "cloud" type texture with some shading, A couple of emitters parented to a pivot and you can fill half a kilometre of a valley with a functional mini dust-storm. A couple of these following a path up dusty valley floors should make for a pretty scary flying experience, if you're foolish enough to try and fly through one.

Next video will show this better but you can hardly make out the farp ahead even though it's only 50 meters away. No flying this afternoon. Too bad we can't make the tents bellow.

Enough of this idle diversion, back to programming the upfront display (UFD). The new radios need some work.

The script has had it's third pass and been signed-off.

Dust Storms and Rotor Wash

Dust storms are constant hazard and often so bad they not only ground aircraft they can cause a good deal of damage, especially to any exposed aircraft or unprotected aircraft intakes. Occasionally even tied down Apaches in the Gulf  were tipped over.

I created a new particle emitter in the editor for dust-storms and rotor wash. Dust-storms would be a nice to have if they look OK. The reference pictures I have (taken by Michael Yon) show visibility dropping sharply to about 50 feet.

Improvements could be made if the particle material could be illuminated from above, like clouds. From a distance it looks like a brown smoke cloud, it needs lighting to give it a more 3D appearance.

Experiment painting desert tracks using the editor. Needs more softening of the edges. At ground level it works but at low altitude you can see the terrain tile resolution. Painting in the editor to get it right will be time consuming. Should be possible to do something in Photoshop.

Radio sets

The TAvionics class is a single instance, one client, one avionics suite. If you leave a vehicle, this class is dumped (along with all the MFDs, HUDs and everything else it hosts followed by a good garbage collection). Enter a new vehicle and it's re-loaded, along with all the memory required for the instrument display buffers etc.

A radio has two channels, a main and a standby, (an AH-64D Apache Helicopter has several radio sets which we will go into later). We will use the ActiveChannel field to index these. If you're familiar with Microsoft Flight Simulator or have any of those RadioStack hardware panels you will be familiar with the "Active" and "Standby" principle of the radio set.

In Sandbox, now Leadwerks Editor, any models of class "radiosource" have keys for two frequencies and file for a radio source. The scene loader populates a TMap of radio-sources. The TRadio class by default loads in a sound file of radio static, turn on the radio and all you hear is shhhhhhhhhhhhhhhhshhhhhhshhh.



Fortunately each can be squelched independently. Using units of 0.0 to 1.0 we assume a background noise has a weak strength, say 0.3 and we'll set the default squelch to 0.2, so we can hear something when we turn the radio on.

And using Audacity we generated two radiohiss.ogg files simply using the "generate noise" function of the program. We used a low-pass filter to give it a more radio set feel. We'll adjust the pitch of the hiss pseudo-randomly when we step through frequencies and no other signal source is present.








Type TRadio


Field Enabled:Int;
Field Band:Int;
Field ActiveChannel:Int; ' 0 = FREQUENCY1 1=FREQUENCY2
Field Frequency:Float[] {hidden}; ' CHANNEL INDEX
Field AudioFile:TSound[] ; ' CHANNEL INDEX
Field Strength:Float[] ; ' CHANNEL INDEX
Field Squelch:Float[] ; ' CHANNEL INDEX
Field Volume:Float;
Field source:TSource; ' SET EXTERNALLY, NORMALLY BY TAVIONICS


Method New()
Self.AudioFile = New TSound[2] ;
Self.Frequency = New Float[2] ;
Self.Strength = New Float[2] ;
Self.Squelch = New Float[2] ;
Self.Enabled = True;
Self.Volume = 1.0;
Self.AudioFile[0] = LoadSound("abstract::radiohiss.ogg") ;
Self.AudioFile[1] = LoadSound("abstract::radiohiss2.ogg") ;
Self.source = Null;
Self.ActiveChannel = 0;
Self.Squelch[0] = 0.2;
Self.Squelch[1] = 0.2;
Self.Strength[0] = 0.3;
Self.Strength[1] = 0.3;
End Method


Method SwitchOn(audiosrc:TSource)
If audiosrc Then
Self.source = audiosrc;
Self.source.SetVolume(0.4) ;
Self.source.SetPitch(Rnd(0.2, 0.9)) ;
If (Self.Enabled) And (Self.Strength[ActiveChannel] > Self.Squelch[ActiveChannel]) Then
PlaySource(Self.source) ;
End If
End If
End Method

Method SetFrequency(tuner:Float, channel:Int = 0)
Frequency[channel] = tuner;
UpdateRadioSources();
End Method

End Type

This is enough for an example. The Update method periodically steps through the TMap of radio-sources, and if they are in range; 

• Sets the signal strength in the radio class
• Loads the sound file specified in the entityclass info into the appropriate AudioFile channel.
• Sets the volume of the sound file based on strength.

The TSource is created in the parent class (TAvionics). We only want one source to listen for radio transmissions so we pass this to each radio we create.

Our Apache has two radio sets for voice communication (a total of four channels), in addition there is a radio used for navigation. The Band field indicates if the radio UHF, VHF or NDB, VOR. Radio instruments used for navigation will query the NavRadio reciever for signal strength and bearing (bearing comes from the entity position of the radio-source relative to the player_vehicle entity).

What can I say. It works well enough. Our cockpit does not yet have any radio controls except for a few key-presses to turn the active channel and set vol. and squelch.

Finally, it is with deep regret that my wife's father passed away this morning at the age of 79 in Victoria BC. A survivor of the atomic bombing of Hiroshima, he was sponsored into the United States and became an influential scentist shaping our understanding of deep ocean currents and many years later, fibre-optics. He had a most interesting life and a devoted Quaker spending much of his time helping others. Mike, you will be missed.

Ground vehicle automata - Boragh APC

Ground vehicles are important in any combat simulation. So far our vehicles (lovingly built by David) are static placements except for a couple of vehicles we converted for the vehicle test program.

Our vehicles will be grouped together into "formations" (squads if you want to use a less technical vernacular) consisting of up to 12 different kinds of vehicles. Each formation will follow a set of instructions, waypoint>action  and each vehicle within that formation will attempt to maintain it's relative position.

That's the general idea. Now to turn static models into war machines with a purpose. I turned a tracked Iranian Boragh (a BMP-2 APC with a peculiar turret) into a tracked/ten wheeled vehicle. Using the LE Scout example as a template it was easy to extend this to work on a more complex vehicle. Even drive it around in the editor.

Density of the particle smoke effects (now matching the terrain colour thanks to new shaders) is based on vehicle speed. The vehicles turn and have full suspension however the tracks are static, this is hard to spot with all the smoke, grass and movement of the vehicle.

They drive independently in a straight line, what's needed now is some logic to follow a point relative to the current lead vehicle in the formation. This is an exercise for later.

Implementation of tracked vehicles using Newton vehicle physics may prove too resource hungry. Worst case scenario is 12 x 10 wheels per formation and formations should be spread out to have a few km between them but that's not always going to be the case when people build their own missions. The current Vehicle command set is not complete and does not allow (as far as I can tell) any method to make vehicles "sleep".

An alternative idea is to make a single "sliding block" for each track and apply enough force to move the vehicle along. This would work better for a tracked vehicle and this is how it is done for a Locomotive using Newton physics.

More work on the Apache Computer, my first "Hello World" program on it. No, it's not a real functioning computer but a message queue display device with some event timers behind it...and yes, a working clock. Last five cautions and warnings are displayed at the top. So when you hear your pilot or gunner yelling "We got some caution and warning lights, check your panel!", this is where to look.

The time is from PC clock, you can see when I take these screen-shots now. The time will eventually come from current theatre time (based on mission start time). I managed to fudge a slight fuzzy look not by using a shader but adding a brown pixel outline to the font. Simple duh.

Caution, warnings, computers and fonts

Back into the THelicopter class today, with a new refined TAvionics class that will pretty much act as a container for all things related to the helicopter systems.

A new instrument today. The computer panel located upper right in both cockpit areas is a general all purpose display of radio channels, transponder, time and in Longbow 2 it had the magic ability to tell you if you were locked onto the pirmary target. It also maintains a list of current cautions, warnings and alerts. Typically you see a long list of these during startup.

In our game we're going to maintain the authentic scale, 35x10 characters, and track the current radio frequencies. I've added a stack that various systems (such as the powerplant) will be able to send messages to for the display of cautions and warnings.

I'm using a pre-rendered computer panel texture from the original Combat-Helo high-detail cockpit made by Joao and a Fixdsys font. This is a close approximation of the real Longbow cockpit. I tried adding a "glow" shader to this to make the alphanumeric characters 'bleed' visually (simulating my now crappy eyesight) but it doesn't have the desired effect. I'll try a bloom later.

In the absence of a cockpit I needed something to give visual feedback on systems before I work on the startup procedures. Hence this panel. There will be a simple "on" button just like Longbow 2.

I did start on the controller mapping too, there's some things I need to think through as it was not as easy to deal with all possible axis and different devices which the implementation I was using before.

And speaking of Jane's Longbow 2, I came up with a logo to test out...it's a bit cheeky. I used that styling all over the place years ago, the font is Impact, italicised, with an outer-stroke, gradient filled. Interior also gradient filled.

The name implies different helicopters may be coming, think, BlackHawk Combat Helo, or HIND. But as we're having difficulty getting the bloody Longbow sorted out it's kind of moot. I'm not sure if I want to laugh or cry about it.

More updates on the computer as we go. If it's all looking nice and blinky at the end of the week it might be worth a video. Which reminds me, I forgot to add a check for bus power to all these systems.

Note to self: Add checks to THUD, TMFD for power status in PlayerHelo.PowerPlant.

600k polys and still > 25 fps

Doing some performance testing using an Apache model I got for "Poser" (Poser Apache). It's a nice helo from a distance if a bit scrappy. Few holes here and there, a pseudo cockpit. But it has all the required hierarchy and joints for a working real-time model.  Poly count it a bit high but about right for what I'm after.

This is the model I used for the blade-flex function. Which I also augmented for sound. This pad is a wee bit noisy.

Blade flex in LUA

This is one example of implementing behaviour using model level LUA scripting which doesn't require adding re-compiling your main project source code.

Rotor-blades are flexible surfaces that generate lift. When stationary or at very low RPM they appear flaccid. Once the rotors are turning fast enough to generate lift, they flex upward.

The Apache at rest (model is an old experimental one that has a highly restrictive usage license).

In the editor, the rotor speed is set by adjusting the SpinSpeed parameter, much like the Windmill example. Each frame update, the LUA program rotates the rotor hub.


The model has 4 rotor blades, each blade is made of 5 segments and named "topblade"
The inner segment is attached to the hub, the outer is the blade tip. We don't want to bend those, just the segments in the middle. This is enough to provide enough visible flex in the rotors. Here is our model in the editor (rotors are turning at a lick here, but appear stationary as it's a still screen-shot).

Here is the LUA code in the model script that takes the spindspeed value and turns it into a bend value. Note that the AppSpeed() is not used in computing the amount of flex, we don't want any blade flap caused by inconsistent frame rates. It's also important that the model rotors are constructed correctly, the segments are parented to it's hub-ward neighbour and the pivot of the segment located at the join between the two.



function entity:Update()
local bend=math.max(5-tonumber(self.model:GetKey("spinspeed")*0.4),-2.5)


--Although these limbs should always be present, it"s a good idea to add a check to make sure they exist before using them
if self.blades~=nil then
self.blades:Turnf(0,0,tonumber(self.model:GetKey("spinspeed"))*AppSpeed(),0)
end


if self.tail~=nil then
self.tail:Turnf(-tonumber(self.model:GetKey("spinspeed")*5)*AppSpeed(),0,0,0)
end




if self.topblade12~=nill then
self.topblade12:SetRotationf(bend,0,0,0)
end
if self.topblade13~=nill then
self.topblade13:SetRotationf(bend,0,0,0)
end
if self.topblade14~=nill then
self.topblade14:SetRotationf(bend,0,0,0)
end


if self.topblade22~=nill then
self.topblade22:SetRotationf(0,-bend,0,0)
end
if self.topblade23~=nill then
self.topblade23:SetRotationf(0,-bend,0,0)
end
if self.topblade24~=nill then
self.topblade24:SetRotationf(0,-bend,0,0)
end


if self.topblade32~=nill then
self.topblade32:SetRotationf(-bend,0,0)
end
if self.topblade33~=nill then
self.topblade33:SetRotationf(-bend,0,0)
end
if self.topblade34~=nill then
self.topblade34:SetRotationf(-bend,0,0)
end


if self.topblade42~=nill then
self.topblade42:SetRotationf(0,bend,0,0)
end
if self.topblade43~=nill then
self.topblade43:SetRotationf(0,bend,0,0)
end
if self.topblade44~=nill then
self.topblade44:SetRotationf(0,bend,0,0)
end




end

Almost done with ENG page....

But I seem to have spent the day programming three penises. >>>

But that's how it's supposed to look. I think.

The bottom angular section of Nr (Main Rotor RPM), that's the fat penis in the middle, is the RPM < 94% region. Which is bad. The auto-throttle should keep this in between the normal 94%-104% region.

Most of the flight it will be in the green zone.

Just have to wire-up the remainder of the digital read-outs and EGT temp gauges.

Alpha Mike Foxtrot

oday I took delivery of the first audio samples from mike meister Jim. Jim and his assembled team of voice talent are doing a fantastic job of bringing the AI characters to life and providing voices for the game.

Hopefully I can bring you some samples when we have the fully finished recordings, they really are fantastic and they don't even have all the audio layers in place.


Now hand up if you thought a torque instrument was just a bar and a number? Hmmm???

Well it's about a thousand times more complex and subtle than that. It's not linear. It's a series of ranges with flags and alerts for different engine and power regimes. But it looks like a boring old bar. You could fill two pages of a manual to cover it. What seemed a simple enough instrument escalated into a a new class for simulating the power-train, from compressor, power turbine and through to the main rotor...then a caution and warning system class. And it's pretty impressive for two bloody green bars that sometimes turn yellow then red. I suppose I'll have to do the rest of them now.

Even the transient timers are in place which inform you how long you're engines have been operating out of limits. There's more detail to add to the caution and warning system. It needs to send messages to the MPD engine panel to auto-show and switch the HYD/OIL panel to the caution and warning engine panel.

We own the night

This is a sneaky taster of why LE is such a great choice for our combat sim. Lighting. We can have more lights, individual rockets and tracers to light up the ground and surrounding objects.

New LE Editor on Matrox TrippleheadToGo

Combat-Helo code ported without too much trouble. Some of the undocumented vegetation commands were changed but the big surprise was automatic billboard generation for vegetation. Obscene numbers of trees are now possible with the suggestion of a collision system in the engine in a later update. Roads are not functional on the terrain scale I'm using, they need some tweaking I think.

The new editor is something of a knights move. Two forward and a side-step. It's easier, a bit more robust and in about 20 minutes I was able to get some of our custom vehicles wired up with LUA scripts and actually running around in the editor. This is going to save a lot of work in the long run as each object can be assigned code to generate necessary joints, emitters and lights without the need to re-compile the game source code.

Here are two more screen-shots of the new editor in widescreen. Here is the familiar Camp Zero, the numbers of trees and view range has quadrupled.

Status Tags and more MPD

Added status tags that float over mission aircraft with distance fade to reduce clutter.

 They show vehicle type, unique ID and will later include AI status, crew and other special flags (such as service status). These are only visible in ground mode when labels are turned on.

Should complete the engine page this weekend. I end up doing fiddly things like boxes with rounded corners, traffic light number fields. Little touches to make it look authentic. I've never seen this block before so I'm not clear how the bars are supposed to look at different ranges.

If you look at this photo of the real page you'll see three red hats in a line when the engines are powered down. Some dots and twin yellow bars. Not sure how these are supposed to work beyond indicating normal flight parameters.

I'll fix up the bars later when I can check how they work with someone currently flying this block.

MPD Engine page, MMD and LE2.3 next Monday

MPD Class added. New co-ordinate system working. Started building new ENG (engine) page and moving map display functions. All MPDs have independent brightness controls.

Moving map display function is similar to original Combat-Helo code (i.e very basic). The terrain height which is currently shown in the popup (right) isn't anywhere near detailed enough. I shall run this through a contour shader I think, that might pick out enough detail. Plan B is a custom made map for each region or...simulate radar returns from the height-map which I wanted to leave for the pro-version.

Leadwerks Engine 2.3 is going to be released next Monday. Looking forward to getting cracking with the new editor.

HUD and MPD/MFDs now updated

Fighting for screen space, the HUD and MPDs were getting out of hand. You can now set the scale of both elements by key presses or in the external .CFG file.

IHADSS (HUD) brightness controls also included. It just looked really good when you turned on the power.

I need to re-do all the OpenGL drawing for the MPDs as I move to use the same (-1.0 to 1.0) co-ordinate system that I used for the IHADSS. This makes scaling and multiple resolution support much easier to do.

The Linear filtering is not as clear as I would like when shrinking the MPDs down, to offset this you can increase the screen-resolution which helps a lot.

And for Christmas I would really like an extra shadow-stage for distant terrain shadow features. On a 10 meter per tile terrain, the existing 3 stages are too abrupt.

LE 2.3 Preview Video - LUA Scripting and Editor

After a bit of a break I started working on cramming in avionics, beginning with the MPD class (MPD is Multi Page Display). Initially I made the mistake of adding the class to THelicopter. Each helicopter has five MPDs (two rear, three front), that's 5x512x512 possible image surfaces, and multiply that for each helicopter in the mission file (typically 8 atm)...opps. A few too many. It's the natural thing to do, helicopters have HUDS and MPDS, therefore they should posses these classes? It's common sense, no? Except it doesn't quite work out that as these classes deal mostly with drawing and you only need one of them, you the player only want to see your HUD and MPDs, you have no interest in drawing them for every single helicopter. Maybe I shouldn't be allowed breaks.

So like the THUD class, TMPD is a client specific class updated only when required. Assigned on mounting a helo and removed on dis-mounting.


In the meantime, here is the recently posted video showing off the integrated object scripting with LUA in the new 2.3 LE Editor.




That's looking quite fun.

Weather reporting....

Hard at work on the script second draft, sound-meister Jim has been helping to develop the formatting of the in-game ATC weather reporting. This will give the game a fairly realistic radio environment around bases and FARPS, much better than what you're used to in current combat simulations.

It's such an effort to work through a lot of detail that its stopping me from writing any code. Which is not a bad thing right now as I feel I need a bit of a break from it. Once the script is finalised it's back to the MPDs.

We still don't have an Apache. The clock is ticking.

And now for something completely different...when Video Games go BAD!!!

This is the first non-project related post. To explain, I'm a gamer dad, Zelda (the Legend of) is a staple part of gaming for me and my kids. And then I saw this...it's so horrific I had to share.



Some things should just be left alone.

More vehicles and sample gui elements

This week was spent experimenting with vehicles but mostly the unfortunate task of re-converting various game models, mostly the vehicles. The new engine update that restored vehicle functionality required changing the format of the physical models. A time consuming process when you have a lot of models that require them.

We're using the vehicle test program to quickly let us inspect the vehicle models, test weight and wheel parameters and materials. Some good observations came out of it. Some not so good.

The screen-shot  right shows the children's charity truck, or "We Care" pick-up, crashing into a stack of large explosive barrels. Accidents can and do happen.

It allowed me to experiment with animating GUI elements. The slide-out drop-down gadget is styled in black and yellow. Themed after the classic Longbow 2 and now adopted by the new Operation Flashpoint Dragon Rising.

The vehicle selector lets you quickly load up any of the vehicles found, assuming they are built with the appropriate wheels and working physics model you can take it for a test drive. Any problems are quickly apparent.

Mission editing, and how to assemble the data necessary for AI behaviour is now at the stage where I'm building GUI elements which will make the transfer into the main project. Key to rapid building of missions from a players point of view, coincides with rapid development of content from our point of view. Rather than build missions in a seperate editor or off a menu option. Stealing a great idea from the recent Golden Joystick 2009 winner "Little Big Planet", you will be able to pause the simulation, flip into "editor mode" make changes  and switch back into simulation mode. The editor is part of the game, the game is part of the editor.

No loading or wait times while experimenting with object placement or trigger logic. The next week will be more work on UI and editor elements. The terrain system doesn't easily allow for decals but I managed a rudimentary terrain hugging poly which only glitches (z-fighting) on small bumps on the terrain as the resolution of the disc and terrain don't match up. There are shapes that deal with this better. I feel a bit stupid in that, in typical programmer fashion, I spent two hours on a code solution to this, when I could have easily made shapes in a 3D editor :) and used the grass shader which contours the mesh to the terrain.

Live and learn.

I'm not sure how live-editing will work out in multi-player. Player objects have states as do all non-static objects for recording and playback. Being able to "rewind" states to make edits to a scene is an offshoot of  the requirement to send them over the network and provide VCR like playback. It can be a lot of data but not all of it is critical. In multi-player, it could get badly out of sync. Back in 1996, with Longbow 2, editing a mission was problematic, sync was a real issue over dial-ups. Broadband lets us get away with a lot. We'll just have to wait and see how it plays out. But if it doesn't work well in multi-player it will have to go as a feature. There's nothing stopping you from mission editing in solo play and connecting up when edits are complete. There's only about three thousand steps between here and there. So I'll worry about it later :) My brain tends to work holistically, seeing everything at once so it's hard not to think about these things in relation to any one aspect.

Until later.

Vehicle test program

Vehicles seem to work fine. I'll be completing a small test program to cycle through all the cars and armored units to check each model, all of the LOD variations and wheel placement. The Toyota ammo truck bounces around just fine, full suspension and steering.

Radio towers, beacons and navigation

Just completed the [TRadioBeacon] class. the following in the objects INI file are used to initialise a new radio source in game.

id="TV1"
frequency1=127.00
frequency2=137.00
strength=100
sound1="abstract:radiostation1.ogg"
sound2="abstract:radiostation2.ogg"
type=1
maxrange=50000
action=LADDER



The ID is the radio beacon/station identifier used for NDB/VOR navigation. You can attach two sound files which are played upon tuning in the frequency. Some radio towers have a ladder for climbing up so I added an action called...."ladder" which will invoke a climbing mode (although it's all too easy to fall off the platform.).

Additional fields in game permit rotating/pulsing sources, directional or beam sources and signal decay over distance. The Apache radio and ADF will permit you to tune in a variety of sources to aid navigation or listen to some funky tunes. Due to the abstract file system of Leadwerks which permits the inclusion of HTML sources, web sites can host new content, although only OGG format is supported.

Strength is a percentage of maxrange. The class supports messaging, turning off the transmitter is as easy as sending it a message to set the strength to zero.

TrackIR now working

TrackIR now works in Combat-Helo. Hooray. The screen-shot below shows the raw output. Other things I added, TADS turret tracking of head position. When we get our working Apache model, the PNVS will be slaved to the pilot head position etc. But I'm glad this is now working, the 'fix' was simple as it happens, I was initialising the DLL before the window was created. The TrackIR wrapper needs a handle to the window.

The region around Herat has some reasonably good SRTM (Shuttle Radar Topography) available. I've imported some of this (again shown in screen above) to get a sense of scale. The boxed area in the image below shows a 40x40km area, one map 'page' of our AO centred on east Herat. The border with Iran is to the west. Kabul is along the narrowing valley that runs east and is the main supply route for the region.

David the robot modeller has been building ZU-23-2s. He felt one wasn't enough. So he built a whole family. All of these are based on actual mounts.

The Toyota mounted ZU-23 close up...

And the real deal...

I bet you have more respect for Toyota trucks now. Speaking of Toyotas...we have a whole family ready for deployment in the region...

As well as a number of Safir, the Iranian clone of the classic Jeep.

Nice one David.

Updates are in-frequent this week and the next. Busy schedule combined with research and documentation, researching audio elements and mechanical systems means little hands-on programming is done.

Scripting for combat

Struggling to find a suitable introduction for new WO pilots in the region, it has to impart some information, set a scene, give you some clue as to further action. And do that in around a minute.

Assuming you've completed the tutorial flight and done the walkaround, listening to your mentor with the mid-Texan drawl. It's time to spawn your new career pilot in the game world.

"Welcome to the sweat box pilot. We have laundry and air-con now so it’s not as bad as used to be. The NAAFI shop is right over there, your bunk is in there and the en-suite facilities right over there. You can’t miss ‘em. The o-club you can find for yourself but it’s not always open.


Air-power out here is vital, it is a hostile environment.


We get mortared daily. It’s not a matter of if we make contact but when. When we do come under fire, take cover as best you can, make your way to the command tent and await instruction. Our birds are kept ready and so should you. I recommend you get some sleep when you get a chance; it’s the one luxury we can’t fly in.


Get to know your way around the base and I’ll catch you later."

Currently scripting for 5 roles:

• ATC
• BETTY
• FAC
• PILOT#1
  
• PILOT#2

As I was writing for the crewmen, it struck me how similar it sounded to another helicopter game when I released that I helped script that one too. I don't think it counts as plagiarism is you copy from yourself?

I'd love to add more story elements for some scripted missions but I don't think we have the resources to do that. I'm not sure we have the resources for the above. It seems like a huge effort. If we can pull it off, it will sound fantastic.

Gratuitous screenshot of the day

I kept working on the 3D pitch ladder and I have a version I'm reasonably happy with. But there's something that bugs me about it. It exhibits the same behaviour as it does in Longbow 2, you need to bank at around 45 degrees and slew the view around. Hey, it works.

Work on voice scripting begins this week, more on that in a few days.

Some performance improvements by better management of material options and I'll be paying more attention to hierarchy Groups for improved visibility checking.

Now here are two screenshots for the sake of having something pretty.

And one more as I like it.