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.