Jump to content
Ultra Engine Community

Flexman

Members
 View Profile  See their activity

  • Posts

    916

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by Flexman

  1. Flexman

    Astrasim Expo 2010

    By Flexman,

    If you're in the UK on August the 28th and can make it to RAF Cosford for the Astrasim Expo flight simulation show, there's a chance that one of the more haggard and tired members of the Combat-Helo development team (me) will be hanging around Komodo Simulations.
     
    http://www.astrasimexpo.co.uk/
     
    Some of my favourites will be there, Sky Blue Radio, Flightstore (who were always good at sorting out my Saitek woes).
     
    So fingers crossed we get the demo completed in good time and hopefully we can pair it up with Rich's replica Apache cyclic and collective prototypes.
     
    Fingers crossed, all being well, see you there. Did I mention the show admission is free?
     
     
     

     
    Source
  2. Flexman

    Video underlay

    By Flexman,

    Not quite there yet.
     
    What I'm trying to do is copy the raw TADS buffer into the diffuse COLOR0 buffer and render the symbology into the same bugger but into channel 2 (COLOR2). Texture channel 2 is used by the "fullbright" shader and mixes at full intensity. The net effect being a normal diffuse texture with full-bright symbology painted over it.
     
    At the moment it's not working as intended. I need to go through the shader to check it's doing what I think it's supposed to do. And see if I need to just use multiple buffers and mix them instead of trying to draw directly into different stages. I'm probably missing an OpenGL command to set the texture target correctly.
     
    It's getting late and I've had to do a lot or changes, our cockpit MPDs only have two knobs, the photos and source material I've been using to layout have three knobs. So there's a slight shift in positioning required.
     

    Non of this does anything yet except the "VID" button that toggles the current TADS buffer. This is the new vector font/glyph system in use. I've yet to add the various button "specials" such as menu nagivation arrows, but the toggles work. The FOV shouldn't be in the raw TADS buffer, need to switch that.
     
    The FMS toggles on the left will interface to the flight model.
     
    I have to say the bitmap fonts looked just as good, if not slightly better when used at the same size. It was a pain adding new glyphs though, here I can add anything I can code with GL commands.
     
     
    TrackIR remains a tangled mess of wires but I managed to assemble it to test and discovered that I'd not added the Track offsets to the cockpit cam. Quickly fixed that.
     
    Source
  3. Flexman
    Congratulations to ArtDave (AD, geddit) for scaring the poo out of me.
     
    He tells me he's been scripting the flare pen (Gyrojet), I'm so busy heads-down in game code I'm often grunting and throwing back idle comments and ideas to get his flare launching LUA code to work.
     
    Then he sends me his completed files. I'm taking a late afternoon break and thought I'd drop his new files into the project to have a look. So I pull over the gyrojet flare pen into the scene editor, I had no idea my speakers were on so loud. I thought a bomb had gone off, the almighty flash and bang/wheeeeeeeeeeee of the flare scared the **** out of me.
     

    This is just too much fun to play with. Animation, sound, lighting. Nicely scripted. Great work Dave, I suppose we're even for farmyard animal noises I put into your cockpit.
     
    Source
  4. Flexman
    In the process of sweeping changes to how the game loads vehicles and other data. A lot of data the describes how the virtual cockpit works, where you sit, angles of views etc. was not available early on and since my long term plan is a system in which we can serve you new vehicles down the wire, even adding the Chinook was going to need a bit of fiddling around. Some data was in the object LUA, some in an external file, some embedded. It wasn't the original intention to build vehicles this way, but it was expedient at the time.
     
    Now it's time to put things right and make a nice neat all-in-one package that's flexible (after all that is my middle name).
     
    Another thing I wanted to do was allow the ability to tie entities to simulation variables, so a cockpit altimeter needle can be assigned to the vehicle.baroaltitude parameter. Hey does any of this sound familiar? If it does then you've done aircraft/gauge development for Microsoft FSX. While this isn't anywhere as deep, it's enough for us to be able to bundle new helicopters and even ground vehicles later on. I'll publish a list of available parameters later when I know the scope myself. MPDs and HUDs can be copied to specified entities using the name of the glass instrument output and the name of the surface you want it displayed on.
     
     
    * edit*
    This is pretty neat, I've now added a bit more flexibility to what we can do with the cockpit inputs. Each individual switch position may now have a delay (hold at this position n seconds before firing) and fire an additional command at that position.
     
    * end edit*
     
     
     
     
    The FFD (dynamics) data could be added too to describe how it flies/drives, that's to be look at later.
     
    There's still a quantity of code required to determine message priority, client/server authority. but at some future time if we want to add "user roles" as a message filter to any control, this is flexible enough for us to drop that in and not rely so much on coded game logic. Filtration and authority of incoming messages are important for multi-crew vehicles in multiplayer, you need to be as lean as possible (I bake state flags into bit fields as much as practical). Not all switches need to be recorded or sent, some are vital (crew helmet positions need fast updates for the HUD and sensors), some (wipers/lights) can be delayed.
     
    The "command" string in the cockpit switch data is sent to the messaging system, if it's a network level command it's forwarded to any needed clients via Raknet.
     
    As our vehicles are 'portals' there isn't much physics going on for attached crews. As a gunner, your helo position comes from the pilot and interpolated, your sensor position is based this, and that in turn is relayed back to the pilot. So there is room for some weirdness but not too much I hope. The way the Apache works actually works in our favour. Since each weapon system has a designated 'crew in command', the game logic knows who's the shooter and the positional data from the client in authority is used. And if you're not targeting a visible entity (e.g tank) then you're aiming at an invisible one (a pivot). This reduces oddities caused by differences of position reported by actual and interpolated crew positions.
     
    Source
  5. Flexman
    Spending time working on my laptop here, which now has some reliable memory from Kingston has proved to be a fantastic little work platform for developing with Leadwerks.
     
    The FFD or Free flight dynamics physics engine is still a little rough around the edges for putting into Combat-Helo proper so I'm working on a small test platform which hooks into the Leadwerks entity update callback and calls the FFD update.
     
    I'm not sure if this is a good method of doing it, FFD is just a flight model and doesn't handle ground collisions. Originally intended for Microsoft Flight Simulator it releases control when the object is on the ground. Which serves me well, switching over to Newton physics at that point.
     
    I've been going through correcting some type assignments and now the FFD engine seems to be working except for some unexplained force in one direction so I'll have to go through it with Fred and see if we can't find out what's up with that.
     
    Thanks for all the offers and suggestions with regard to my dead motherboard (it truly was gone).
     
    Source
  7. Flexman
    Summer Sim 2010 is nearly here. Komodo Simulations, makers of replica helicopter controls for virtual training are sadly not going to have their replica controls ready in time but a recent news update on their web site shows the current collective at the pre-mould stage.
     
    Komodo Simulations WAH-64 collective WIP
     
    Looking good so far. Combat-Helo will be there to show a build of some kind. Although like the controls we're perhaps not going to have all the goodies ready to go into a demo build. We're still working on getting the new flight model ready, going to be a bit hit and miss that one.
     

     
    Source
  8. Flexman

    Problem with gun camera

    By Flexman,

    I like the idea of having a GunCam view. However it means increasing the texture detail on cannon as it really wasn't meant for up close viewing.
     

    Heh, I have you in my sights.
     

    Trying alternative offsets for the cam to get a good viewpoint. You can see the spotlight on but we don't yet have it deploying from the hull.
     
    Source
  9. Flexman
    Was exactly a year ago today we started work on Combat-Helo. I really don't know where the time has gone. Happy buffday team, and well done. To commemorate the occasion I dug out one of the earliest screen-shots I could find to compare with one from this afternoon.
     
    And thank you to everyone who's offered kind words of support and encouragement. It all helps.
     
    Sept 2010 - "Herat"
     

    Oct 2009 - "Camp Zero"
     

     
    Source
  10. Flexman
    Just got back home and Dave left a nasty sight in my MSN window. No, not another scene of drunken debauchery, actually I have to complain, there's been a distinct lack of that.
     
    We got to discussing visual representation of damage. Different ways we can do this. I write it here so I can remember what we discussed. We looked at some complex set-up of assets for iL2, the results of which are impressive but it hardly makes for an easy pipeline, especially if we want to quickly add more aircraft in future.
     
    After some thinking we boiled it down to two simple options.
     

    The first is application of a damage texture on parts (child objects) of the helo model that match the aircraft's damaged state. And Dave left me the following image, a simple test to check it out...

    Another technique is decals. Now I've looked at LE decals before and I don't think they will work everywhere on our map due to floating point and surface fighting in the outer regions. These are patches that positioned to be almost co-planer with the surface of a model (like the decals you stick on a model). If they work, they have the advantage in that they should work for everything.
    A more complex alternative is a new method of decals using a glyph shader. What we'd do is have a single texture upon which, in a grid patter is lots of damage and battlescar images. We pass this glyph texture into the mesh frag shader along with a damage map of the aircraft. The shader will splat areas from damage map with psudo-random glyphs of damage. This might look OK to pretty bad depending on textures. I'm quite keen to try this as I want to add such a system to give players some custom paint jobs reflecting game achievements/rank (such as earned 'shart teeth' and other hokey things).
     
    A similar shader is already present in LE version 2.40 for adding plaster-work to brick walls. Now 2.40 has some new commands for adjusting LOD ranges, we're almost goo to go to move the project to the new version of the engine.
     
    For now, keeping it simple works and I think the damage texture looks alright.
     
    Source
  11. Flexman
    hehe well the XPatcher2 software worked great for the upload, but the client program doesn't seem to want to work at all, requesting a file that wasn't supplied or exists.
     
    Might have to look at other some other software.
     
    Converting all config files to use XML format, this will make editing control inputs a bit easier later. They are rather messy atm and adding new options should be a lot easier.
     
    Source
  12. Flexman
    Yup, perhaps the most nauseating camera view is back. One that a still screen-shot and an fps hungry FRAPs recording IMPROVES. RotorCam is like having your brain ripped out by your eye-stalks and soaked in vinegar. A virtual camera is strapped to the underside of blade number 1 and everything else is a blur. Only use I can think of is a debug aid when we get to blade flapping etc.
     


    I'd like to thank Macklebee for helping me sort out the LUA object passing to get this working.
    RotorCam for all your video game torture needs.
     
    Source
  13. Flexman
    Looking at the pieces we have and project roadmap. Our game, like football (soccer for American readers), is a game of two halves. Side A and Side B. One campaign is the thinking man's approach; counter insurgency. The other game is the more familiar tank spanker; survival in a high-tech hostile environment against well armed self-sufficient mechanised infantry with air-defence units.
     
    Compounds are anchor points of the campaigns, in groups they form the villages, strategic points you're tasked to provide security for. In the side-B campaign, the role is slightly different but as important.
     


    I'm still a little bothered by LOD and shadow ranges, you can go mad tweaking these to find something that works well for different modes. Maybe I'm stupid but it only occurred to me last night to make the LOD settings dynamic. Which is ironic, as the very very first multiplayer wargame I worked on back in the late 80s used an LOD system based on view height.
     
    In the real world, at ground level the horizon is around 11km away, it's a mathematical function based on your height and the curvature of the earth.
     
    1.17 times the square root of your height of eye = Distance to the horizon in nautical miles
     


    So I'll be experimenting at some stage with adjusting the Leadwerks Engine LODs for shadows and vegetation based on player mode and viewer height.
     
    Just using a depth of field filter on the far horizon seems to greatly improve visual quality, making hills blend a better into the haze, masking the smaller details.
     
    First things first, we have to complete our Apache and it's operational systems. Arming is almost complete.
    With breaks for Easter, familiy time and re-writing internal systems for handling weapons THREE times (it got better each time). It's taken a week longer than I said originally. The menu system is in place and the visual manifestation of the ordnance is left to do. Rocket pods will require one click per zone (3 zones or 3 kinds of rockets per pod).
     


    Presently it permits arming in proximity to the Apache which is fine on the base. But we'll have to implement some object, like an ammo truck (hmm, seen that somewhere before), or some invisible object we can attach to any entity via some LUA code (much like player spawn locations).
     



    DOF blending the horizon.


     
    Source
  14. Flexman
    I was thinking over some official forum posts and one gentleman indicated that they were partly colour-blind. Accessibility issues are something I think about whenever I'm writing software or web site design work so I kicked myself when I didn't apply that to the interface. I added some GUI elements that link current selection to the tooltip, this should avoid ambiguity in the menu system.
     



     
    So that's all working as it should, just have to fix up the weapon selection system which will be based loosely around this mock-up...



    We has some debate about walking around in ground mode clicking on weapons displayed on the ground like in the above picture. Or some other mechanism involving a fixed camera that cycles through each pylon and a vertical list to choose from.
     
    On the whole, there's not much difference in workload, both are fairly trivial to implement. It's become a style choice. But I'm torn between traditional as above, or flashy console panning cam and up/down list.
     
    Either way it's a far cry from Gunship 2000...or is it?



    Which method will I implement? Stay tuned for the next thrilling blog post when all will be revealed.
     
    Source
  15. Flexman
    Last night we added rotor blade coning which resulted in realising the helo was just a little slightly off axis, now corrected. The Apache has been attacked by an angle grinder on more than a few occasions, might be showing signs of wear.
     
     
     
    Some LUA issues came up which erroded confidence in relying on it for so much. I've ditched arming through scripting. It's prone to misuse.
     
     
     
    The pylons are now ready to take the 3D models of the assigned loadouts leaving the final stage of the arming process and then the WEP page for the avionics which I can't wait to get back to.
     
     



     
     
     
     
    Dave has been working on compounds for the region...
     



     
     
    And he gave the scoop on the campaign we are featuring in what I hope is the first of many...
     
    Herat is a very pro-Iranian province and historically Iran has long believed it to be a province of their own. The local warlords are all Iranian funded. Most of the natives of the area are Tajiks, they speak Persian. When the Taliban came to power, and attacked Herat, Iran very nearly invaded Afghanistan. They had apparently massed along the borders back in 2000. They canned the plans after the NATO invasion of 2001.
     
    Our campaign follows on from the current real world conflict in Helmand province. The concept is that should the Taliban retreat, they might choose to retreat north-west into Herat. NATO forces would follow, expanding their position at camp stone south of Herat, and begin engaging Taliban positions. Local Tajik civilians get caught in the crossfire, Iran decides to move in to backup their warlords, and secure the civilian population. One too many stray arty rounds and NATO is in a full blown conflict with Iranian armoured forces.

    That's it for now.
     
    Source
  16. Flexman
    I'm in the process of adding the weapon systems; avionics and links to the stores. While that's coming along at a steady pace I often come across a bit of code and think "I could quickly do this..."
     
    So I just quickly added the third-person cam; as we don't yet have any character models I'm having to use this laughable code generated place-holder.
     


    Character height is 1.8m.
     
    We're going to require a rigged humanoid with a number of animations for sitting, prone, kneeling, aiming, running, walking, waving etc. We have a list on animations somewhere, I'll try and dig it out.
     
     
     
     
     


    This is "Marshall" from BBi collectibles range (now discontinued). He's a great model, but the wrong sort
     
    Source
  17. Flexman
    Spent the day working on the Helicopter entity and the sub-classes that handle all the pylons and stores. It's worth spending time automating these things as much as possible now to simply things later.
     
    I broke out UMLet, a nice fast Java based UML editor to look at my structure. What's missing is the store-jett which needs to be a function of [TStore], pass it the pylon number and it will be required to generate the physics object, parent the rail/pod/fuel cell, detach it from the pylon and let Newton take over, thus letting the pod/rail complete with ordnance fall to earth.
     
    And by moving the [selectedZone] property to the [Pylon] from the [Avionics] class, it allows for the ground-crew loading system to simply add rockets and let the [Pylon] advance the zone so all 3 zones are populated in three clicks. That way it's not dependent on a playing crewing the Helicopter (as [Avionics] are only instantiated when you board a vehicle and destroyed on exit).
     
    This is all part of the process of adding the WEP MFD page which needs access to stores data and it gets it from the [stores] class, which can be thought of as a black box into which each pylon (4 of them) send signals about what is loaded where. And how to re-load of course.
     
    I'm torn about creating the whole WEP page graphic as a vector, I'd rather do that as textures scaled up can look a bit blurry. Cockpit builders might want a stand alone OpenGL client that doesn't require the 3D engine for displays so going native OpenGL makes adding it a cut and paste job.
     
    Source
  18. Flexman
    It's been a blissfully quiet weekend.
     
    The Combat-Helo configuration files are now in an easier to use XML format and I added a lot of extra options too. Player profile name, host IP, graphics filters etc. Fullscreen and Windowed modes having their own settings.
     
    Also experimented with light scattering, we'll be adding per time-of-day lighting and retiring the old LB2 style skybox. That's not a priority item just something that's nice to toy as a little break.
     
    Arming system which should have been completed already (lots of interruptions this week) has had some GUI elements added to it to improve feedback, just have to write the descriptions for all the ammo. The Apache is receiving the arming messages fine but not visibly showing the loaded rounds. On the whole, not too happy with all the GUI as it is. I made something that was easy to fit to multiple resolutions but it could use a little polish.
     



    I ran another test with the Autopatcher and it's still a bust. The file it's wanting is created server-side but the client patcher can't reach it. So another email exchange with tech-support tomorrow.
     
    Source
  19. Flexman
    I can't talk about the details much as it's proprietary code. Helicopters have been (inaccurately) described as thousands of moving parts flying in lose formation. Mathematically a helicopter is thousands of interactions flying in loose formation. For Combat-Helo and future simulations we're assembling a modular version of what we call FFD (FreeFlight Dynamics), a library based on definitive engineering texts on how helicopters fly through air. Texts such as Bramwell's Helicopter Dynamics and Wayne's Helicopter Theory are the staple of many an engineer.
     
    FFD is the physics part of HTR, a freely available module for Flight Simulator X. HTR stands for Helicopter Total Realism, conceived and developed over a period of two years by Fred Naar and fine tuned by input from real helicopter pilots.
     
    At the core of FFD library is an ingenious and elegant approach that is easy to expand and simplify. Potentially capable of handling different types of power-plant, flight control systems and rotor configurations without straying from the principles of rotor-dynamics. It has a big future as middle-ware, not being tied to any particular 3D engine and totally independent makes it portable, I can compile this on the Mac. Future versions will handle fixed wing dynamics and possibly other vehicle types.
     
    I'm still on the conversion stage but progress on FFD for Combat-Helo is going smoothly.
     
    In other news, just ordered another 1TB of NAS. every backup is close to 0.3Gb. And a Corsair CPU Watercooler is on it's way to protect my CPU from heat-exhaustion.
     
    Did another job search today, bit pathetic that nobody seems interested in hiring, even for fairly trivial IT support work I don't seem able to get a bite. Can't complain though, the weather is good.
     
    Source
  20. Flexman

    Monday update

    By Flexman,

    Today was spent working on reliable interface network client/server connections. It's apparent I need to add some additional items to the top of the screen:
     

    Current world time Mission Time (as offset of world time) Connection status indicators (connecting/connected/ping status)
    These to sit alongside the current game mode, camera mode and have a suitable background image.
     
    Testing is proving difficult logistically. I would like a fairly inexpensive second PC with small form factor capable of running the Leadwerks engine at a reasonable speed. Something that can sit on top of/or next to my main PC.
     
    Password protection seems to work with servers rejecting connections appropriately.
     
     
    Facebook
     
    I'm told everyone and their app has a Facebook page so here is the Combat-Helo Facebook entry. There is something of a virtual Apache walk-around with an internal one coming later, a collection of screen-shots in the galleries so you don't have to hunt around for them.

     
    Source
  21. Flexman
    It's ridiculous, I'm seemingly unable to purchase from the UK, PC Pilot, a UK based flight simulation magazine . The only way I'm able to obtain copies is via ebay sellers in the US.
     
    Local stockists are non-existent and repeated attempts to buy them online results in emails informing me that they are unable process my details. The same details which seem perfectly fine for US ebay vendors.
     
    Two weeks now.
     
    I give up, I'll stick with US postal charges. More reliable.
     
    Source
  23. Flexman

    Weekend video

    By Flexman,

    I know I said this week but will likely be over the weekend, there were some LUA issues I needed to get my head around. As for LUA, I think I'm going to pull out some of the model features I've been putting into the model LUA scripts as it's starting to get in the way when I need to control them in game logic. Reading values and objects back seems to be a dark art, these things may have been fixed, or not bugs at all, but caught between moving engine versions and not much documentation I'm left with having to "land at an alternate airport" just to keep things moving.
     
    Also I want to fix up the cockpit ambient lighting before recording a sight-seeing tour around our version of Herat city. Here's a tasty screen-shot of the Citadel to keep you going.
     

     
    Source
  24. Flexman

    XML Database lookups

    By Flexman,

    I needed to add some on-the-fly lookups for data stored in XML databases without having them gobbling up memory. Most games of this type had a vehicle and weapon database, usually with a rotating 3D model or picture of the object. Using the TxmlTextReader function with a cache works fine. Only need to do the lookup once when examining an object.
     


    All weapons come with suitable entries by entering the ground crew mode from proximity to any Apache helicopter. We can re-use this for tutorial pop-ups, optionally adding a tag to the XML entry that points to an audio file thus triggering playback. If that makes any sense.
     
    I mention it here as it just occurred to me and don't want to forget it.
     
    Source
  25. Flexman
    Still working on the loadout system, as it happens I totally forgot to do the pylon classes. While I'm working on polymorphic classes to deal with that (lot of cases to think about). During lunch I played with some more dust effects, this time for rotor downwash. This uses the roaddust pixel shader so it picks up the colour of the terrain it's currently over.
     



    With no wind vector applied, brown-outs, where the crew can't see outside are occurring. Not sure why the canopy isn't blending as it should, it's located in the same transparency world as the dust particles. I'll have to check the shader settings in the material. Back to pylons.
     
    Source
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...