Flexman

What was the solution, or what was the problem anyway?

I apologise for lack of updates, long time since the last one (weeks it seems although I have two unpublished ones which are no longer relevant). I've been avoiding online spaces during this time, work has been bogged down with the multitude of tasks not just relating to the Combat Helo game. I'm working on the flight model again this week so don't expect any updates in a while. I did get started on an updated FAQ and will publish that ASAP. Lots of things happen around this time of year with concerts and church services, when you have a musical family there's a lot of evenings taken up with those. So I don't know when we'll have something to show for all this work. It'll happen when it happens, there's no budget to finish and I've got huge debts that require me to stop at some point and take time off to do other work. On the plus side I did get a nice pressie from one of my brothers which is going to buy a nice cheap car (sensible, used K car but importantly has a working HEATER, a nice to have feature for UK winters). Something to be said for being happy just by virtue of being in a car that's warm. "Do you know what’s killing Western democracy, George? Greed, and constipation. Moral, political, aesthetic. The economic repression of the masses institutionalized." - Bill Haydon from John le Carré's Tinker Tailor Soldier Spy 1974. Source

Last week I identified one issue relating to UserEntityData introduced with the last engine update which prevents consistent update of Enity data due to some change in the hierarchy and no documentation on what was changed. So I'm faced with having to re-factor (meaning to changing code but same behaviour) core sensor code. It's the sort of thing that is utterly frustrating and makes one want to throw everything out of the window. It's not as if there aren't enough things to do. There's 4 major issues I'm not happy with: Flight Model bridge refinement Ground dynamics Horizon gapping and other asset problems (licences/legal, audio) Events / Triggers I know I can rush some of these things and end up with something I'm not happy with. And if I'm not happy with it I don't see why anyone else will be happy. The majority of potential customers don't follow this blog, they don't care about how much work or team sizes, finds and lack-of, how or why, and often they don't care about the word "beta". To do what's right in the long term means having to not cut corners and do what needs to be done. Sucks though. Who would have thought building a stand-alone study sim of the most advanced attach helicopter on the planet would be so difficult? What gives? Source

11/11 Source

Some pics of the day. Battlezoneesque - eerie (debug stuff) Shadow puppet time. Planning terminals awaiting attention This is how I start every day Source

I'll give it a go and if it's stalling the pipeline too much I'll have to fake it, I don't think there's another way to get feedback on partial image contrast. Unless I can fake it using the AABB and lighting conditions but the idea is to be able to look at a texture of a window and have it able to "step outwards" till it either has bounded the window or fails from poor image contrast or image instability. Cheers

I need to read the pixel intensities in a TBuffer, only a small number as I need to simulate how a sensor looks at the centre of the image and works out where sharp changes of contrast occur (to create a tracking box around a moving image based on visual information only). I see it only needing to s looking at 4 pixels ever other frame and step outwards until it finds an intensity of more than 20%. I wonder if anyone has any caveats I should look out for with regard to video cards and pixel formats in Leadwerks engine. Would HDR muck this up given that I'm reading from a buffer I created using just COLOUR0?

US Army released video showcasing the new Block III Apache in a virtual training environment. The video covers in a nutshell... Weight reduction Improved software upgrade pipeline Increased engine power 701-D engines and improved drive system Better digital battlefield intergration UAV commanding IFR certified instruments Reliability and servicing improvements RFI range triangulation Maritime classification Awesome new logo Further reading Source

Did you see the report in the bug tracker? http://www.leadwerks.com/werkspace/tracker/issue-219-joint-stiffness-newton/

While Dave is away hopefully keeping his head above water (all those Bear Grylls survival videos should come in handy) I've got not much else to do except worry and get on with my to-do list. C-SCOPE was something I remember saying wouldn't make it but turned out to be a freebie since everything was available to simply drop it in. [C-SCP] button on the FCR page overlays FCR target symbols on TADS video and HMD. Makes finding those hard to see vehicles a piece of cake. C-SCOPE FCR symbols presented on the HMD ref: http://www.fas.org/man/dod-101/sys/ac/docs/ah-64-mfp-1-33.htm The High Action Display is currently getting an update for the ACQ interaction (I've tried really hard to work through what this does and how I can gamify it to make something both usable and understandable by normal people). Also I'm overjoyed at getting news of our ATC audio recordings and looking forward to playing with that. Source

Dave who is the artist on Combat-Helo is currently in the process of evacuating his home in Thailand as the floods in Bangkok have made living difficult. With no fresh drinking water for days, no supplies in the shops and place of work closed, services breaking down it's time to jump ship. Blue indicates server flooding (clearly) Red=flood defence BBC carries the story here Dave's last act before evacuating was uploading the latest Chinook work to our server alas there was no time to upload the PSDs. Good luck and fingers crossed we'll hear from you in a week or a month... Source

Yes Panic. When you're rushing to get a reasonable build ready for hammering out problems I'm finding I'm making all new problems. Going over the HMD code I realise how badly it needs rebuilding, there are existing elements that need updating, a few new ones that require adding. There's no way to rebuild the HUD in time. Another problem. LUA in the Apache entity. Works in the first instance, but fails in subsequent entity spawns resulting in the inability to mount the aircraft. It's an issue relating to LUA accessing keys stored in the model. I want to rip out all the LUA code from models except for the model initialisation that puts on pylons and attaches the rotor models. Not much time to deal with that either. Dual Seat configuration. The interaction between front and rear seat was not well thought out early enough, instead I opted for a 'duality' where all features could be operated from either seat with just some interface differences. I should have opted for a strict seat A can do xxxx and seat B can only do yyyy. This was a mistake in my attempt to simplify control but ended up introducing more complex logic. It's not too late to undo this but a difficult process to start. If I have to design this game all over again I think I would probably nail down all of these problems from day one. Hindsight being wonderful. TrippleHead - lot more pixels to post process, looks great but a GPU strain Source

Not a Combat-Helo post. I'm engaged in a spot of design and research but was looking for some old material online and found I had left a digital trail pre-dating commercial internet use. 28 Years ago I drew this. I was in high school. Shocking really. I used Z80 machine code to generate the 'impressive' sound and visual effects in this game. *wince* A lifetime of programming and tinkering, stacks of hard drives of unpublished projects ranging from Spanish school time-table generators to a Black Shark snapshot campaign generator. Some material I doubt will ever be revived, the Memotech MTX 500 version of Next War was stored on cassette tape, probably oxidised beyond recovery. However the code lives on in other forms, the dynamic campaign system was enhanced and put to some use in a PC build. Some of which will form the backbone of the Combat-Helo campaign. One day I hope to merge the big war game with the Apache simulation and revisit the forgotten Fulda Gap scenario. More unreleased WWIII fun and games NATO vs Warsaw Pact at the Fulda Gap Even my own attempt at producing a self-indulgent comic based on our exploits in the Star Wars Galaxies MMO...(PDF dug out of the old SONY Online game forums). Even though the game will soon have the plug pulled the footprints we leave behind in the digital space will live on...for a bit. I've rescued the original PDF and made it available here... Orion Outpost Chronicles part 4 - PDF Anyway back to work. Source

Cool. I spent an evening trying to keep wheels on a helicopter. It was impossible, they kept falling off when you put any sizeable mass on them. I thought it was just me (being a bit tubby these days through sitting all day and eating comfort food).

AD has started some great work on the armaments of the CH47 that will form the first major DLC pack for the full release of Combat-Helo. Each door position will offer a fun interactive activity, usually in the form of throwing out obscene amounts of virtual lead. For more pictures please see: ADs SimHQ CH-47 blog update thread Mini-gun, I don't get the mini part though. Source

Oh my, I want some of THAT. That's an incredible level of customisation. How the hell do they do that?

[NTS] Left Upper button. Next To Shoot is the ubiquitous video game cycle through targets. Or TAB target if you play MMOs. I've touched upon how radar works in this blog entry from August - Radar - A Discussion The Apache can automatically selecting priority targets based on some sort of criteria. This short blog post touches on how I've elected to do this. Again if you're familiar with the 1996 classic, Janes Longbow 2 there's nothing unfamiliar here. The TSD (tactical situation display) collects data from visual cues (look at object), radar and TADS (again look at and store). A linked-list of 3D entities is stored and sorted by range. The list is re-sorted by what type of object it is. Target object sorting as follows: Fast Movers Helicopters Air Defence with Radar Air Defence Armour Wheeled Aircraft normally only show up in air targeting modes. The image above has one on the GTM Radar which is a BUG but that helicopter (another Apache) is on the ground. Then these are sorted by range. The [Cycle Target] key (default: TAB) steps through the list. This is different to the [Padlock Cycle] key (default: LCTRL F4) which applies to your head view and steps outward through visual targets sorted by range only. Sometimes the nearest isn't closest to the centre of view. I'll touch on how I've programmed the game internally. A linked list of objects that are picked up in the FCR footprint are added to a TSDcontact list if the entity pointer (an entity is a vehicle) is not already present. The game maintains separate lists from sensors and a Tactical(Situation Display) list which is used for referencing entities on the TSD. It also allows for messages received by the THelicopter message handler to add entities to the TSD when the player presses the 'ABCC download' button to download shared targets from a shared digital battlespace (fancy name for a simple array). To upload your TSD list you press the 'ABCC upload' function. I will think about expanding this to work on several channels in later versions. Tactical Sensor Lists The TSD used in our Apache vehicle is simply an instance of the TacticalSensor class which is used for all AI but the inputs are wired up differently. These inputs are updated when in use, typically triggered by a player pushing keys. I've colour coded the inpus accoring to type. FCR is radar type area scan, high volume, Orange (HMD) is using the Mk1 eyeball, TADS in blue is an optical sensor (longer range eyeball) and Red is known data from external source, which you can imagine as a radio or some data modem. As potentially there might be a hundred active AI vehicles in close proximity having all of these using all kinds of sensors, doing lots of volume searches and entity queries is woefully inefficient. Fortunately the natural hierarchical structure of unit can be simply used to make things much more efficient. Since entities are grouped into Formations which share waypoints and mission targets, they share a common awareness. The same TacticalSensor class we use in our Apache. Only this time the inputs come from the different entities in the formation. Some will have an active sensor system, some are unable to supply input. They periodically perform a sensor scan (interleaved to spread the load) to refresh their group TacticalSensor list. Oh NO! The MIG! Target Priority I'm sorting the linked list when updated based on criteria that I want based on experience from other games of this type. Worked for them, works for me. In LB2 a Mig was triggered at random if flying over 250 ft. If not spotted quickly it was almost certain virtual death. To give these a high priority I added a Priority field to the SensorClass and arranged the icon IDs (1,2,3,4 etc) so by default the Priority value can be taken from the icon ID then modified later. Now the most dangerous entities can be simply sorted on this field but we could for example assign an entity as a "Primary Target" and add +10 to the Priority to have it automatically sit at the top of the TAB target list. Very handy for scripting tutorials and the like. For example we can now spawn a virtual waypoint marker on a target range and command the avionics to give top priority. So whatever the first entry on the linked list is, that's the NTS object, the second in the list would be the ANTS. PFZs Another often asked about feature in Combat-Helo is the ability to create PFZs. Which is something that only applies to the Hellfire missile system which is coming in a later update as we've not yet implemented it. However our Tactical list makes this a trivial matter to implement. We have a static list of entities, mouse input on the TSD map and mouse driven events. Everything needed to add PFZs and NFZs. Correct weapon symbology coming soon Whole HMD needs a going over. Source

Starting to feel the pressure now. Both the financial and stress factors are weighing in. Doesn't stop me working but it's hard to switch off. On the business side there's a ton of things on the to-do list, it all eats time taken from production. Spooky, ok so the lip light isn't actually on his mic. If it was you wouldn't see this. Boeing sent me a poster back in 2002, this is a homage to that. This time with the rear seat. Taking out bad guys without damaging the good guys is a challenge. Experimenting with simple TSD display and labels. On top of this I'm studying some Unity material and shader programming. I could use a beer, a real one. Source

Thanks Ken for taking time out to make those and put them up for the community. I have been using quite large CASE statements myself but easier on the eye with careful grouping. I like the code Rick posted, that's quite useful and not too dissimilar from a special FX system. Never considered it for networking.

Quadtree software has released the 3.1 update to Grome. Grome is a fantastic terrain editor I've been playing with for future enhancements and rolling out a larger terrain systems in the future. If you play flying games and RPGs on consoles chances are you've probably already seen a Grome edited terrain. It's used by nearly every major player in the simulation industry. Incorporating a plug-in system, OpenSceneGraph and now new improved Unity integration. What's new in 3.1 I'm quite keen to see how it works in the up and coming Leadwerks 3(D) engine which is looking to sport threaded streaming of assets. If this could be incorporated alongside the vegetation system it would be perhaps the most powerful and complete 3D engine for less than 1,000 USD. Source

Sweeet. We like it very much.

Well I hope you don't take it as a slight. It is a testament to your quality and should you be persuaded to publish a whole collection no one will be more pleased than I. I like what YouGroove suggests, a coherent character system that's uniform and integrated would get people up and away moving custom characters around. Clothing packs sell quite well for other systems that are infuriatingly locked away by license restrictions from indie game developers. That's one of the better, if not best Unity add-ons, the character builder system they just started. Mix and match skins, buy an animation and plug it in. Leadwerks has the TController, it would be awesome to have that combined with a TCharacter to deal with all the animation matching for clothing, walking and other animation. Pick a skeleton, pick your animation to fit it, add the clothing/body mesh, bake as necessary, add to scene.

Remember the spinny radar thingy in Longbow 2? Scan sectors sizes and off-axis settings for the Longbow FCR (Fire Control Radar)? No? If you look at the heading tape of the screen-shot you'll see in the heading tape the "butt-cheeks" (two Ds back to back) on a heading of 225, off axis by 45 degrees. This indicates the direction the radar is pointing, as the FCR display is 'always up' in GTM mode. This can be a little disorientating and the radar footprint is mirrored on the TSD, this paints a clearer picture of where it's pointing. Failing that you can see the radome outside the aircraft turning as it seeks out the designated offset. (And why are all our aircraft IDs Z666? We shall never know. If you have a TrackIR and explore the cockpit nooks there's even a Clint Eastwood reference in it). Radar offset angle is set by clicking on either of the two LEFT RIGHT arrow buttons on the MPD or your designated sensor left/right control input when the FCR is your selected sensor. (If TADS is selected the sensor control steers TADS instead). NOTE: The offset can not be moved while the FCR is active, although you can queue movement by hitting the offset control then quickly cycling the FCR burst key. Got it? It will be in the manual. Promise. Vectors - all vectors, no bitmaps In the front seat, TEDAC view of the FCR Source

I used to actively do model rail-roading as you american chaps call it few years back, good thing to do with the lad. It was very expensive in terms of materials. Recently Steam had a special on the Railworks 2012 simulation which was great fun if a little buggy at first. The total cost of all the DLC available comes to something like 900+ UKP. As a simulation product it's done quite well, selling over 40,000 units according to the BBC. I guess deep down some of us still want to be train drivers. Consistency is the problem with buying lots of off-the shelf components. You buy Hornby products and your layout looks like a Hornby layout. It will lack that hand-crafted look but still looks quite good...as a toy. When started our project the intent was to buy in as many assets as we could to reduce the workload. How naive I was (I'm a programmer, not a 3D artist). The reality was that the quality was so variable even the ones we did buy and kept required some level of remodelling or at least re-texturing. Sometimes the amount of work would have been the same as building from scratch. We bought a lot of veg from Pure3D and the vegetation packs were too good. Nothing else we had matched the quality. We needed to re-work the trees, dress them down to fit but unable to do that we switched to using our own "Elwynn Forest" (World of Warcraft) like trees which fitted our more simple, less natural looking feel. And quite often in a particular game title some smoke-and-mirrors are used to fool the player. Bushes the size of a house for example. Ground clutter that fills screen real-estate to give an overall impression rather than adhering to an artists attention to realism. If you bought most of your stuff from Dexsoft or Pure3D you need to good pick-list to choose from. Of course if it's just hobby programming it doesn't matter at all. Unity is happy to sell you loads of rubbish that doesn't quite fit in a multitude of script languages. One of the attractions of the Leadwerks engine is the restrictive nature of the assets you can use. DDS and GMF may seem like an awkward addition to the conversion process but it means you don't have JPGs, BMPs and GIFs littering your project and streamlines internal handling. I recall someone from one of the now "free" SDKs giving a keynote speech, "You can make any game you want, so long as it's our game." And sure enough, most games made with that SDK look and play the same (to me). If think once a store has a critical mass of content that comes from the same source, or at least built to the same specs and style, and offers multiple styles then it has potential to really take off. Look at Ricks board game WIP, his characters come mostly from the same source and looks all the better for it. That's what's needed IMO.

It's commercial software but has been more reliable with .X import export than other things I've used. http://www.fragmosoft.com/