Flexman

Another great addition to the tutorials. I wish I knew why my LUA loaded emitters occasionally crash.

I think this thread was eaten by the web monsters. But I had a lot of problems shopping around here in the UK. The helpful advice given by all was taken on board. Many of the machines suggested were either not available over here or had some strange UK Pound = US Dollar relationship that blew prices into orbit. In the end I settled for a Toshiba Qosmio X300 with an nVidia 9800GTS which was around 800 UKP (didn't want to spend much more than that) and runs my helo project at around 40 fps when sat in the cockpit complete with second TADS camera which is pretty impressive for a portable. So thank you Lum, Josh and others for the tips.

Our Apache received more love today, the cockpit panel textures suffered a little from DDS compression acne. But by increasing the bits-per-pixel to 24 and using DXT1, we get better quality results using a texture half the size as a larger one using 8bpp compressed. And smaller texture memory footprint too. This only works for some textures. Additionally specular maps were added to the cockpit, now it reacts to light in a much more dynamic way and the scratched glass blast shield and canopy really adds to the sense of enclosure in a cockpit space. A few major systems are not currently fitted to our Apache, the TADS (or ETADS) was initially removed due to rendering problems. I've re-instated the TADS class and rewrote the rendering function. It's still quite primitive and there's post0processing to add to the tads_buffer as well as overlaying the symbology. As expected the performance hit is around 20% when drawing at full frame-rate. I'll add a frame-skip value to adjust performance for users. The good news is that it's not worse that I thought it would be plus there's still lots I can do to improve performance. The ETADS display is using the same Fullbright shader as the other MPDs so it's a little overbright. When I'm done it should look the part. Over the test-map testing the TADS camera. Rest of the week might be a little quiet as we're rushing to complete the startup and caution/warning system to go with it (keep getting side-tracked and doing other things). The dual-seat multiplayer mode throws up some interesting logic problems with the messaging system when generated messages don't have a source. It has resulted in front-seat controls sending signals to back-seat controls which in turn trigger front-seat controls and so on. This is why messages have a source ID so remote control messages don't trigger a local message transmission thus continuing the cycle. Yes, all I need is a message filter. Little update*** You have control. Source

We're going to edit the LUA script for the CH47. Helicopters are somewhat complex and incredibly noisy machines, you thought your XBOX 360 was loud? Yesterday we trawled through some online video, ripped the soundtracks and used Audacity to get some loops of the compressor, and rotor beat. That's two discrete sounds that when mixed together should give a good representation of helo noise. Using Audacity it's possible to mark a region, and use that as a 'sample' to remove that noise from another. So we took some of the compressor/engine noise and removed (or reduced) this by around 16db from the rotor noise. Next task is to add these two looped audio sample sources to the CH47 model script. As we want all instances of the CH47 to use there we'll add them at class level.... local class=CreateClass(...)<br style="font-family: Verdana,sans-serif;" /> class.soundcompressor = LoadSound("abstract::ch47_compressor_loop.ogg")<br style="font-family: Verdana,sans-serif;" /> class.soundrotors = LoadSound("abstract::ch47_rotor_loop.ogg") The compressor noise can get on your nerves. We want to emphasise the rotor beat so we have set a volume ration of 1:2 between them. Setting the volume of the rotor loop to 1.0 and compressor to 0.5 function class:CreateObject(model) if class.soundcompressor~=nil then <br style="font-family: Verdana,sans-serif;" /> object.source_compressor = object.model:EmitSound(class.soundcompressor,75,1,1)<br style="font-family: Verdana,sans-serif;" /> SetSourceVolume(object.source_compressor,0.5);<br style="font-family: Verdana,sans-serif;" /> end<br style="font-family: Verdana,sans-serif;" /> if class.soundrotors~=nil then<br style="font-family: Verdana,sans-serif;" /> object.source_rotors = object.model:EmitSound(class.soundrotors,250,1,1)<br style="font-family: Verdana,sans-serif;" /> SetSourceVolume(object.source_rotors,1.0);<br style="font-family: Verdana,sans-serif;" /> end Note, LoadSound() returns a source which we need to store for later when we change volume and pitch. When the Rotor Speed is increased either by the AI pilot or engine/entity update, the blade flap function is called to update the relative positions of each blade. And here is a good place to update the audio for the blade thumping. It seems better to place it here than in the update/render which is called every frame. Here it only is updated on changes to the rotor state. function object:BladeFlap() local flapangle = 7 - (object.rotorspeed*0.6) + (object.bladeangle * 0.08) local offset = 120 for i=0,1 do if object.bladehinge~=nil then RotateEntity(object.bladehinge[0], Vec3(flapangle,0,0)) RotateEntity(object.bladehinge[1], Vec3(flapangle,-offset,0)) RotateEntity(object.bladehinge[2], Vec3(flapangle,offset,0)) offset = -offset end end -- CHANGE AUDIO PITCH SetSourcePitch(object.source_rotors,object.rotorspeed * 0.045) end We added additional code to turn on/off audio for static and parked helicopters. We can improve on this by introducing a "start-up" and "shutdown" state that will wind-up/down the compressor noise whenever the aircraft is flagged as "live" or "dormant". Such a simple method that greatly adds a sense of weight and presence to an object. Here's a video of the result. Source

Sound is an impressive tool. And something I worried a great deal about from the start. Just adding various audio sources to the Apache, from the Betty, to various computers tones, compressor noise, all adds to a sense of cockpit space. The Chinook needs similar attention, as a non-hero aircraft (currently a non-flyable). The game engine uses OpenAL, which employs a system of 3D positional audio. In the Apache most of the noise is behind your head, looking left and right appears to pan the audio. Externally the engine and compressor sound sources are attached to a helicopters engine positions. The difference between the hero-ships such as the Apache and AI units is the way audio is initialised. Apache audio is split between interior and exterior sounds; interior sounds are built during the player boarding process which initialises the cockpit and switch status, the exterior audio is created as soon as it enters the 3D world. Our CH-47 Chinook like the Apache, will have engine sound sources attached upon the object creation process, and the LUA update function, called every frame will swap in and adjust the volume and pitch of various audio files. Getting really good audio requires at a number of digital recorders positioned around the aircraft. As we don't have local access to a Chinook and a bank of digital recording equipment, the modern internet age comes to the rescue with numerous video web sites rich with source material of variable quality. After auditioning a few choice videos, using a Firefox web-browser plugin that downloads the video files from these sites, the process of ripping the audio for processing can begin. VLC Media Player is a free video player with a number of conversion features. And allows you to batch export audio from a video files using the Convert option. Selecting the video we want to convert and the destination file then choosing the export format. We want audio only and in OGG format. I have the Audacity Don't leave home without it. Audacity is in my price range (free) and works well with OGG format audio files. It's reasonably easy to find and build audio loops but before you can do that you need to turn it onto a mono audio file. OpenAL's 3D positional audio requires a mono-sound source, it will split the sound to different channels depending on the source and listener position. So having flattened the audio file, the work of finding and snipping loops can begin. In the next blog update I'll detail the processing of adding and loading the sound files in the model's LUA script. Source

Making notes on discussions of blade flapping. Definite gravy but easy to add. Currently blade flexing is done via blended animation controlled by the simulation sending key values to the model. The CH-47 has quite a large blade system (almost doubling the length of the helicopter to 100 feet) and low ground clearance. Most of the droop comes from the flapping hinge Dave has indicated in white (adjoining the red highlights). These pivots allow the blade to horizontally move upward when the blade is advancing, and down when retreating. Additionally the blade model hierarchy to allow for visible blade pitching and the Apache blades retro-fitted to do the same. Source

David posted up some more CH47 pics around SimHQ and Facebook and possibly elsewhere. Lot of detail work has gone into the engines, rotor head and trying to get the smoothing correct at the rear of the aircraft. Looking forward to getting those blades turning, the sound thumping and the dust is flying. I've been doing a lot of logic work in the Apache in the past day or so. Also full of a head cold which tends to make me cranky. Sat in the cockpit, the APU sounds like a vacuum cleaner in the next room. Adding moving cockpit parts such as power levers, flashing lamp indicators and other one shot elements that require animation in a periodic update function suggests that maybe it would be better to place all of these things in something more general purpose. Rather than having a spider-web of update calls, updateCockpit, updateUnitWaypoints, updateEventTrigger etc. popping a function onto a stack when it's needed seems like the thing to do. I'm proposing to add a simple event system that can take an entity and perform a chain of moves, rotations, material or colour changes, and remove from the stack when the sequence is completed or removed. Then augment this to perform function calls for mission events, to be fired as offsets from mission start time or absolute world time. Initial thoughts suggest something like the following would cover most needed cases: eventID = EntityID, action, blend, userdata (e.g material, colour, vector) as csv eventSequence = ID, eventID[], deltatime_ms, cycle_ms, repeat_count, start-time_ms (absolute world time or zero for mission start time) Where a sequence to cycle a material between two states would need two eventID entries, one for each material and the entity to apply this to. And the eventSequence would contain the reference to both eventIDs. It's then up to the eventProcessor to handle the action. Which could also be SetKey() or SendMessage() but it should be generic enough to handle a lot of common situations. Event is performed [repeat_count] times, a value of zero implies loop. [cycle_ms] is time between each repeat cycle in milliseconds. Some checks may be required before injecting an even into the eventSequence. To prevent duplication, for example, hitting reload to trigger a reload animation repeatedly would have the effect of triggering the animation to play before the previous playback has ended. Therefore a parameter to test the uniqueness of the eventSequenceID before pushing it onto the stack should suffice. **edit: some of this doesn't make sense, seems it got screwed up in posting. Text has been mistaken for tags.** Source

More detailing on the rotor head, details on the flap, pitch link and coning hinges. Assembled audio for the CH-47 today in addition to implementing the Apache cold-start procedure. Source

The CH-47F has had a lot more work done in the cockpit area. The seats are looking remarkably clean, I just need to get a child to play inside with some squeeze boxes and a can of 3in1 oil. The Chinook is smaller than you might think, with a fuselage approx 50ft long, it's shorter than the Apache which is 58ft long (approx). I was surprised by that. Networking Today saw successful Combat-Helo net connection between the Leeds UK and Bangkok in Thailand. Getting the link to work through two routers involved the same port forwarding process as is required for BlackShark. Enabling NAT punch-through requires an external service to act as a matchmaking partner. Since the onus is on the host, we'll assume they know what they are doing anyway. The address-book had some problems with the XML save/update, now fixed. More changes to the colour scheme. A tidy into bar at the bottom rather like the in Falcon3+ and LockOn displaying connection status, camera, mode, fps etc. General tidy work to polish what's been completed already. Apache HMD I corrected the Helmet Mounted Display to show the pitch ladder and horizon line as fixed instead of being locked forward (as seen in the YouTube VRCockpit First Look video). Much better for the pilot, now I can comfortably look around and make corrections to the aircraft. There's more work to do in the cockpit to make front/rear/solo seat modes work. This is my focus for the coming week which will sees that engine start-up procedure working at last. Game Engines / iPhone We pre-ordered Unity 3.0 last week since it was on offer. We can squeeze the Combat-Helo PC campaign into a stripped down iPhone game. Fans of Combat-Helo can support PC development and have a little fun pretending to be an Apache gunner for 3 minutes at a time. I still haven't migrated the PC Leadwerks engine to 2.32 yet. So many issues with the cockpit and camera-picking still. Some surface switches in our pit have a tolerance of 0.05 units and were not being recognised. This tolerance is perhaps too small anyway given floating point inaccuracies. These shouldn't be a problem when I move away from rendering the cockpit in the main world (still on my to-do list). Speaking of which here's the current priority list... To-do Electrical power system and engine start-up Master Arm and weapon selection Cubic spline interpolation for client character controllers Landing gear dynamics (still makes landing difficult) Combat-Helo : Operation Ouroboros Operation Counter Insurgency was noted on shots of a splash screen posted a while back. As remarked by one soldier, "It's not very military". This harks back where we didn't have a clue for a project title, it didn't seem to be a priority. For months it remained "Unnamed Helicopter Project" or UHP. Operation Counter Insurgency (OCI) came out of that as something to fill a splash screen. In keeping with the military tradition of using really obscure names (British operations have some really odd ones), Operation Ouroboros represents the endless cycle of conflict in the region. As an ancient symbol of a dragon or serpent that swallows itself, it's unlikely to be trademarked. Above all, it makes the game sound like a sneeze "CHOO". Bless you. A photo that sums up a fairly typical start to a Combat-Helo escort mission. Source

Connection time-out now resets the connection status to "disconnected" Apache canopy glass, lighting issue fixed GUI input controls that receive key-presses still occasionally hogging the keyboard. (fixed) Some speed improvements to OpenGL DrawCurve function. New GUI style as submitted by Spac3Rat in place. See Facebook image Next week: Back to weapons and more multiplayer functions. Source

A need to test Combat-Helo on Windows 7 resulted in a TESCO purchase of the Windows 7 Upgrade and 1kg of bananas (a rich source of potassium). Running any Leadwerks program on a fresh OS install results in an EXCEPTION on launch, only two steps required to get it working. Run the OpenAL install then update video drivers. Simple. Everything worked as it should. Source

Dave has put up some more preivew pics of the CH47 at SimHQ and on our Facebook page. SimHQ CH47 Chinook progress pics CombatHelo on Facebook Source

The game world clock is now synced across network clients, time advance and day-night cycles locked. Accuracy is down to round-trip packet times plus a few milliseconds. More than enough to keep entity spawn times and waypoint navigation in close sync. I'm as yet unsure how often to send clock updates, currently it's every half-second which is quite aggressive, it's easy enough to tweak. Clocks run on client and frame-rate independent so they don't need to be updated often. They just need the occasional time sync from the host or when the host is changing the time-of-day. Chat channels work well, need to add the player name to the prefix. We have a player profile set in the game config but this carries no player name or any other data as yet. Almost ready to test that NAT punch-through. Source

Cheers Joh

So...after searching through the Wiki, how does one set entity view distance to infinity in your program?

If you look carefully at the full size image just behind the cockpit, you can see the z-buffer error, the interior partition which is welded to the cockpit interior has shadows that bleed-through the skin of the model. Won't be noticeable when it's painted but it's fairly typical and by no means the worst example.

Blades will be like the Apache when completed, boned, 10 animation frames with the entity LUA script blending frames according to rotorspeed. It doesn't take collective into account but it's enough. LUA also lets us have animated doors, on the apache both the pilot and co-pilot canopy hatches smoothly swing up. That's about as much LUA as I'll allow, I don't really trust it beyond simple stuff. These things in dry environments create their own duststorms, a CH47 crewman sent me some photos he took out of the back of one over Afghanistan of another Chinook on the ground delivering supplies. The cloud of dust it kicked up would cover a small town. Quite impressive.

Nice cave modelling too. Looking sweet. Nice beam effect. Is that a billboard with a fullbright shader? It works really well.

I thought it was a drop-shadow. Thanks for the logos.

:+1

I sense some dissenters in the ranks I've still not migrated to 2.33r5 and wont for some time till more of the niggles get sorted out. And I need to upgrade as this version introduces a key feature I've been waiting for. But it has been a lot of work in the past, especially when documentation isn't changed to reflect new behavior, so you can't even go and look up why something isn't working anymore. A large chunk of problems come from having to reserialise assets (an acknowledged PItA) and mixing /duping old shaders/mats/models. That latter I don't see as LE's fault, just another PItA. But I hesitate to upgrade as I don't know how long it's going to take, and if it's going to change in the next week or two. I think a calendar with fixed update/publish dates with more stringent doc updates would go a long way. Just a matter of personal discipline which is hard when (like me) you have a brain that fires in different directions at any given tim...ohh shiny thing. All I can do is sympathise with Pixel and Red who have done really cool things and have been able to borrow ideas and inspiration from. Although I'm not sure if you're going to find anything more suitable. Everything else I've looked at has problems of it's own. That navmesh/ai path editor is smart Pixel. The topic name is wonderfully fitting though.

Dave's been busy building the unsung hero of Afghanistan and other operations around the world. Rolf: Can you tell what it is yet? ;-) It's a non-flyable but will feature prominently in the game as you'll be tasked to provide armed escort for supply, insertion and extraction missions. Much time has been spent correcting smoothing errors. Brilliant work. We'll be adding the same functionality to the rotors and rear door using LUA scripts. This morning we were looking at the various flavours of cockpit, of which there are many. Never the same cockpit twice. I thought the Apache tandem cockpit was complex. The amount of work required to make this a flyable is out of the question right now. It's a level of complexity rivalling the Apache and a candidate for future expansion. Source

Shrug. I'm almost ready to add a scrolling map to my GUI, so I'll just flail around till I find something that works.

You should add to your sig what version of LE and language you're using. Maybe there's a problem with the alpha and mipmaps? Can you try a version of the texture with generated mipmaps?

Combat-Helo presents a persistent world, day-time / night-time mission capability where you can stand around your base with your thumb up your rear-end. The game's heartbeat is the day cycle clock from which all missions, AI entity start/stop times, spawn times. All operate as offsets from mission start time. This presents the issue of real-time vs game time. To offer variety of day/night operations in a real-time game could be tedious. I want to fly a night mission, but it's noon, I can't. If mission clocks are running there's two options, kill the mission and advance time, or interpolate mission outcome as if they proceeded (can you open this can of worms for me please?) The alternative is to adopt MMO time where game-time has no parity with real-time. 4 hours of real time = a full day-night cycle. In a military game, I don't think so. So faced with real-time, how do you ensure everyone gets to play some day and night missions within a reasonable time-frame? Time advance, with constraints. No mission clocks can be running. This means everyone will need to be within the base compound with no active missions before a time advance option can be used. I can't think of any other easy way around it. The time-advance could be applied to your base tent or in the command HQ tent command terminal. Source