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
    Yes were still using Notepad to edit them. Well that's not quite accurate, I'm using Notepad++
     
    What's nice about Leadwerks is being able to create a shader to add new effects or change how the engine renders something without anything getting in your way. So when Dave asks for a version of the cubemap that will blend in some particular way it was no problem to quickly put it together. He's doing terrible things to make filthy looking windshields, chrome toggle switches and this rather neat looking rear view mirror.
     
    Who needs fancy wysiwyg editors....well it would be nice sometimes.
     
    Dirty Mirror finish
    It's a double rainbow! Testing blending and reflections.

     
    Source
  2. Flexman
    AD posted more Chinook goodies at SimHQ Link here >>> SimHQ - AD Chinook Update
     
     



     



     
    What am I looking at?
     
    It's a little creepy, crew heads now reflect the pilot helmet sight (PHS) and gunner helmet sight (GHS) Vec2 offsets, so using trackIR, mouselook etc will operate the appropriate crewman head position (with suitable organic tweening). These positions are stored in the aircraft state so will work across all aircraft (AI and player) as well as multi-player. How creepy is that?
     
     
    "Everyone gets everything he wants."
    "All I wanted was a mission,"
    "and for my sins they gave me one"
     
    Shot on my iPhone. This is what TrackIR and mouse movements do to the crew head positions.
     
     
    *edit*
     
    There's a few pages in the system that are informational only, the FUEL page was one, I fleshed it out a bit tonight, adding a working cross-feed system complete with animation (yes the real one does that too). It's lacking the fuel check and bingo settings (to be added later). Setting the bingo stat is part of your start-up checklist, it would be a shame to leave it out.
     
     



     
     

     
    Source
  3. Flexman
    Now available.
     
    *edit* A few additional notes...
     
    The controller setup page shown in this video has a number of devices listed. These are just the ones I had plugged in at the time of recording. All DirectInput controllers should be available, some will have ready to fly config files (most Saitek sticks, Logitech).
     
     
     
    I forgot to turn on the post processing effects since I work without them (generates more heat). There is a LOT of changes going on to various sensors and the IHADSS won't be updated to reflect these changes until I've done the MPDs. So please no accuracy police, I'm aware of the various bits and bobs. It's all in hand.
     
     
    YouTube Link: http://youtu.be/L8AHX8uXHpQ?hd=1
    Vimeo Link: http://vimeo.com/29957378
     
     
     
    Screenshot of the day
     
    Cleanup in lanes 1,2,3,4,5 and 6 please.
     
    Padlock, shoot, padlock shoot, HMD mode
    cleans house at close range , almost too easy

     
    Source
  4. Flexman

    Two years old

    By Flexman,

    Yippe..the 18 month project is now 24 months old. Horray. Short post but I felt I couldn't let it slip by unnoticed. Especially with all the Tipex (White-Out) all over my Project Planner.

     
    Source
  5. Flexman

    KBU, FCR mode logic

    By Flexman,

    First screen-shot of a quickly put together KBU (keyboard unit). This is a flat 2D image you click on, taken from the texture used in the cockpit. I wanted to see how good/bad it looked since we don't have time to develop a 3D one.
     
     



     
    Clicking on Air Surv will abort current FCR operation
    and switch to an active air scan (air surv mode)
    The keyboard command list is looking horrible if you want full control over this. The shot cut keys work fine however. I made some tweaks to the heading tape symbols and the Air Surveillance Mode has been adjusted according to recent feedback posted. No sweep indicator is displayed (? is that correct) but the radar is still active. And not NTS or targeting is available. This mode is not available if either crew station has FCR as the selected sight. Either crewman selecting FCR or cycling through HMD/TADS/FCR will cancel this mode.
     
    I made attempts to smooth out the logic for simple joystick control so you can hot key from mode to mode.
     
     
     



    FCR Scan and FCR Scan burst will cancel each other out with immediate effect, no waiting for a scan cycle to complete (which is what it did before).
     
    I'll adjust the scale of the FOR box shortly. The dot isn't active yet, will fix that shortly and then I'll correct the cue dots in the HMD,
     
    That will be as much time as I want to spend on the FCR. I think it's not too shabby and does nearly everything it needs to do for now. Completing the command list for the sensors now means I can finish the default control setup for new installations.
     
    For full control on a joystick you need 3 hats minimum.
     

    4 Way Sight Select (HMD, TADS, FCR)
    4 Way FCR Mode Select (GTM, ATM, other to come)
    4 Way FCR Footprint Set (Zoom, Wide, Medium, Narrow)
    There are also keys assigned to FCR Mode Cycle Up/Down to keep the control count down on smaller sticks.
     
    As always if I've got it wrong then please leave some feedback however I'm unlikely to embark on any more major changes for now. Quite pleased with the detail and how it works.

     
    Source
  7. Flexman
    Particle engines are commonly used for fire and smoke effects adding a lot of eye-candy for little effort. Every frame an emitter creates a number of billboard sprites along a vector. Normally this is not an issue when movement along this vector between frames is quite small.
     
    But what if you're talking about something that moves really fast between frames? Such as a rocket launcher or space-ship? Fellow Brit and indy developer Cliff Harris of Gratuitous Space Battles fame ran into the same problem. Here's a screenshot from his blog of a rocket.
     

     
    The rocket moves too far between frames to space out the particles in a pleasing manner. By adding a line of particles between each frame update a more pleasing effect is achieved.
     

     
     
    In Combat-Helo the hero-ship is typically loaded with several 70mm rockets that accelerate to 700 meters per second in approx 1.5 seconds. Even maintaining a short smoke trail of 10 meters can't be maintained as the rocket distance between two frames might be 50 meters or more.
     
    A linked list of billboards (TMesh CreatePlane()) is being trialled. UsingMacklebees billboard shader tweak and changing...

    ... gl_Vertex.x,gl_Vertex.y to ... gl_Vertex.x,gl_Vertex.z
    ...to work for Planes a 2D billboard function was implemented which handled colour and timing properties with a deviation (waver) offsets.
     
    This creates a ribbon of 50-150 quads (TPlanes) aligned to the camera using the billboard shader. Scale of each quad is roughly double the space between them to ensure some overlap and consistency. The smoke texture has baked lighting with a normal map however a normal map is redundant since the quad is camera aligned and rendered in the transparency layer.
     
    The spacing produces a good fill between two positions each frame. In the example image below the length of the trail is 75 meters, each particle doesn't require much updating since this was written for a specific purpose. As the shader takes care of orientation only timer tests, waver and alpha-colour needs updating although some extra instruction for management could be implemented (see footnote).
     
    Don't attempt to use ScaleMesh() as that slows the whole pipeline down. If you need to change the size of a particle you'll either have to do it in the shader or delete the particle and replace it with a larger one.
     

     
    Same again showing the AABB of each TMesh/Plane.
     

     
    That's about as fast I can can come up with using LE commands. The next stage is to replace the TPlane billboards with a single entity built using a TMesh and adding triangles as needed.
     
    Other optimisations might include changing the number of particles depending on the 2D length between the head and tail. We need more 'filler' if seen from the side than head on.
     
    Worst case would be a full salvo from 4 pods (each pod carries 9 rockets), in this event the particle manager could limit them. With the Leadwerks emitter function, once created you can't change the number of particles so having this level of control is handy for all manner of effects that need adjustment over time. This is of course slower than the LE particle system.
  8. Flexman
    Fingers crossed the weather is not too bad tomorrow at Gilze-Rijen air force base. Our man in the Netherlands is prepared for a day of audio recording for the Apache and Chinook.
     
    Good luck Reck. Weather is pretty lousy here, high winds, low temps and rain, sat images and forecast is so-so. Expect wet weather and don't forget the 'dead cat'
     
    Source
  9. 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
  10. Flexman

    More HUD config options

    By Flexman,

    Completed changes to the HUD section of the config file.
    <HUD col="1.0, 0.8, 0.2" glow="0" shadow="1" breakoutfpi="1" />
     
    I'm using the TinyXML lib for config functions, it's been fast efficient and easy to use. I added a new option today that was born out of looking at videos of games projected onto huge screens giving almost 1:1 scale. Before my tripplehead PC went pop I had a problem with virtual symbology relative to HUD size. The larger the screen, the smaller the HUD relatively. At it's worst, the effect was looking through a keyhole.
     
    So I removed the keyhole, the "breakout" option in the HUD config will plot some indicators outside the HMD area and in a relative scale to the screen size. This makes it more useful at the expense of not being totally accurate, hence the option.
     
    In the screenshot below you'll note the user colour option for the HUD symbology in effect alongside the flightpath indicator outside the HUD buffer (right of the altitude bar in the hilly bits). This is easier to use on a laptop too where screens are not as bright and it's easier to pick up.
     

     
    There's been an intermittent windows exception error when launching the game (release build). I tracked this down to the old controller config loading which uses IO streams to pull in a data-file. Something is going on there. I need to re-do the controller settings anyway using XML to store response curves and other tweaks you can't do right now. Just a pain as laptop drives are a touch on the slow side.
     
    Source
  11. Flexman
    Spent a lot of time today house cleaning. No not code, literally the house. It's amazing what teenagers can do to your treasured Monty Python DVD collection, it's not funny. Stop that, it's silly.
     
    I over-complicated the map drawing and stripped it down. Added functionality to the TSD page for controlling the map scale. I'm happy that it will work with 3rd party maps too. Oh I just noticed in the screen shots the scale index is off by one.
     

    The green colour is from the low elevation range but I blend some of the terrain colour too which I should perhaps leave out since it gives a false impression. I'll add a button on the page to cycle map modes rather than have to go through a sub page perhaps. Otherwise it might get (more?) confusing. Hey, Longbow 2 had one button to cycle through NAV/ATK and BOTH....and no map unless you flew the Kiowa (I think).
     

    So tonight I'll add the aircraft datum (the helo symbol on the map focal or point of rotation) and begin adding the glyphs for the waypoints and other symbols that we want to appear on the map. Should finish adding the waypoint data while I'm at it (ETA etc). I can't work out endurance time yet as the fuel data isn't yet present. It varies with payload and altitude, there's a table in the A model dash-10.
     
    Would like to have an elegant algorithm to approximate it.
     
    Source
  12. Flexman
    Working on the tactical situation display elements, the vector font output was never quite as crisp as I'd hoped for but that's now fixed by keeping the 1:1 scale and changing the ortho projection matrix. Bigger works better than smaller when it comes to float accuracy with consumer level drivers that focus on games and performance I guess.
     
    Still have the map scale to do, that's forming part of the mission terminal code. But the rest of the TSD is coming together. I need to put an upper limit on symbols otherwise some numpty crews might get a bit happy adding symbols to spell rude words or add smiley faces to the map.
     
    Added a basic HSI rose function and added that to the TSD NAV mode. Everything seems to mask OK. Only issue so far is the pop-up repeaters, they are currently too dim/dark, see second image below.
     

     

    You can see the vector fonts are much better defined in the above image even though it's a bit feint (and oversized for the window res I use on my laptop).
     
    So far, the Apache avionics suite includes a basic navigation system, 5 radios, two almost complete HMD modes and a tactical system in progress. It's actually getting pretty fun to fly around now, some bugs notwithstanding. View system could use some love as well as the stabiliator to stop the nose-down pitching.
     
    Source
  13. Flexman
    Another little progress update but first a diversion. Yesterday I took some time-off to brush up on gaming skills and really enjoyed Disney Interactive's "Split Second", one of the few car games I keep going back to since I typically find racing games tedious (lack of skill and patience on my part). However this game is almost pure adrenaline and I find my self coming back to try and shave off 2 seconds while avoiding exploding aircraft and collapsing control towers. Split Second is actually the perfect arcade car game IMO and probably much overlooked in a busy genre. It screams for a post race replay option though.
     
    Enough digression. Not much to show yet as I've only spent an hour or two on it this morning, I hadn't put in the VR cockpit data for the TSD buttons so went and put that data in. Had some color issues down to a mix of LE and OpenGL and sorted out the MPD scale for rendering the currently loaded nav map image.
     
    TSD stands for Tactical Situation Display
     
    It is the most complicated system in the helicopter. Which I will strip down to the bone for the first release otherwise I'll be at it for months. The TSD presents a 'Gods eye' view of your helicopter and your environment. Downloaded target information, friendly unit sightings, route navigation and more is presented here. It is a moving map system that can be frozen, panned and scaled.
     
    I need to slim it down into something manageable. Also there are many functions that are desirable to use in the command HQ tent planner and also other helos in future.
     
    Our TSD will feature
     
     

    Fire zones (aka PFZs, old school but everyone will want them) Route editing Threat, target and hazard objects Nav and Attack mode (PHASE) Freeze, panning, zoom Crewman cursor acquisition, click on map and point will be made virtual in the helmet display.
     

    So there's a few things to do but also shared with the ground planning system on the HQ tent computer.
     
    For the base map, it's using the TTerrain() object on the loaded terrain entity (I needed to cast it to get access to the height and normal map data otherwise it's considered a TEntity). A shader converts the normal map into an intensity multiplier ( float intensity = dot( normal , lightdir ) ) for the colourmap, multiply the diffuse and intensity and voila you get a shaded relief map just like the one in the Leadwerks editor (except I don't need the realtime light position and colour that the editor uses).
     
    To this I'll add a colour lookup table from the heightmap and possible some contour lines. I've not used an "lut" function (look up table) in a shader yet so it will be a fun little exercise. Contour lines could be done by setting output colour if the heightmap value is a multiple of 10 (meters) or whatever value I pass to the shader. This just colours the pixel if the value is in that multiple, steep terrain might bypass that value so results will be a bit patchy depending on the source data. I'll look into a proper contour function.
     
    Keep in mind the heightmap in terrain doesn't have a flipped y axis.
     
    Source
  14. Flexman
    I was looking at the problem of glass again, reflections for cockpit instruments and improving the canopy and TADS optics. FSX manages to do so much with so little (a small 128x128 DDS) for shiny metal parts, such as chrome props it was time to look at adding cube mapping again.
     
    I know this has been added to Leadwerks 2.40 but the corona problem doesn't seem to be fixed yet. Retro-fitting cube-maps to 2.31 is an easy task and the river mesh material was updated (we don't use the single height infinite plane as it doesn't work with real-world topography). As water goes it's not fancy, real-time reflection and surface animation for high-speed machines during the polish end-phase. River surface cube-mapping matches the environment lighting and thus provides a simple and economic effect. There's only one river that runs east-west.
     


    Shiny chrome parts and subtle glass reflections should be trivial to add (when I get the alpha component sorted out).
     
    Source
  15. Flexman

    More HUD readability

    By Flexman,

    First of all, a sincere thanks for the feedback. It's not something to get too hung up about and it's easy to get the idea that we spend hours and hours on making HUDs pretty colours without getting anything else done. Yesterday was pretty intensive in terms of tweaks and adjustments to the HUD but not just in terms of colours.
     
    We've added clipping regions (using glScissor() ) so items like the pitch ladder no longer intrude into areas it shouldn't, this declutters and improves overall readability. Also the acceleration cues are no longer available on the CRUISE mode symbology, again reducing clutter.
     
    And the biggest headache which I'll come to in detail has been the flight path vector, that little circle with the stokes at 3, 9 and 12 o'clock. It presented a problem I hadn't anticipated. It's also difficult to explain but I'll try and sum it up.
     
    The idea is that the FPV is drawn in the the direction you're moving, so if you are moving directly forwards it's in front of you. If you are performing a perfect sideways slip to the left, if you turned your head to look along your left shoulder you would see the marker in front of you.
     
    The HMD or HUD represents a 30x40 degree field of view. However, the default field of view for the main 3D view at a resolution of 1024x768 is 90 degrees. The HUDs default scale is 512x512 and would need to map virtual symbols to a 45 degree field of view (512 being half of this example full screen resolution).
     
    Now, if you have a much larger screen resolution, say with a super-wide monitor, or tripplehead (worst case) you're horizontal resolution can be around 3840 pixels across, the game FOV might be 120' and therefore to match the 3D world, the HUD symbology has a field of view as little as 16 degrees. That's tiny.
     
    The result would have the flight path marker moving the HUD really quickly since it covers a smaller relative area. This would suck if you really needed it.
     
    You can't scale the HUD to match the screen resolution as you loose the top and bottom off the screen. Well, answers on a postcard please. Chewing this one over.
     
    Source
  16. Flexman
    HUDs often used in simulators adopt a green hue and use an additive or alpha blend. It can be hard to read them in some conditions and this is something I was thinking about so I tried a few experiments, non of which I like fully.
     
    First: To improving readability of heads up displays by down-sampling the HUD buffer to a smaller buffer (I called the hud_fx_buffer) with a texture filter, a poor-mans blur. Using the resulting 'fuzzy' version to reduce the intensity level of the background image.
     
    Has potential, reduce the resolution of the hud_fx_buffer too much and you get a darkend 'strobe' effect around the symbology which is akin to what you see on video tapes. It think with a Gaussian blur effect and a higher res buffer it might be a winner.
     

    Second experiment, the ubiquitous drop-shadow.
     

    Yuck. Looks like a drop-shadow. It's the same down-sampled hud buffer with a small offset. It works though, can clearly see the symbology against the lighter parts of the horizon without resorting to 'orange' or black.
     
    The hud 'clarity' will remain a user option, off by default.
     
    *update*
     
    One last toy, a twinkly hud glow. This is actually quite pretty in motion and again reminded me of some old HUD tape footage shot in old Jaguar aircraft.
     

    Good for simulating what it's like to have certain eye-conditions. Another one for the cutting-room floor.
     
    Finally, below we have hud glow mk2, a more subtle variation which is just a glow applied, mipmaps help soften out the hud image.
     




     
    Source
  17. Flexman
    The HMD of the new MTADS Apache comes with a number of 'virtual' items displayed to the pilot. The currently selected waypoint is made virtual in cruise and tranistion modes, the waypoint position is marked with a flat bottomed diamond with a dot in the centre. See the take-off point (W00) on the image below.
     
    Flying with the flight path marker inside this symbol and you should head right to that spot.
     
    Waypoint marker
     

     
    Source
  18. Flexman
    Thanks to "GrViper", bit of Russian press coverage courtesy of "Game Navigator". I think I like the intro about raining fire and brimestone? I had to have a Russian friend in Siberia read it out to me over Teamspeak after which he asked, "so you're interested in flight simulation then?"

    Work update
    Last night I added the waypoint/navigation system which is rudimentary but has the needed functions for other bits of code to insert them into an aircrafts avionics. It's a linked list with some methods for management and selection. Once the HMD and MFD gets the steering cues for the current waypoint it should make it easier to navigate around our game theater.
    Also I worked on the flight path vector which is a little confusing since it's 'virtualised' in the helmet sight (adopts real world position regardless of your head rotation), but the artifical horizon is not.
    How *I* currently made it work (which is slightly different from how it will finish) is a magnitude of vertical speed and horizontal displacement (sideslip) which is how I think it works in a 2D format for MPDs (the little square screens in the cockpit). For the HMD virtualised mode it's a matter of using angular velocities (HeloBodyOmega) to estimate where the nose is going to be in 3D space and add the pilots view position and rotation.
    Fred put it more simply, offset from nose = angular velocity * coefficient etc. Well the devil is in the detail working out what the etc. is and doing it in the right order.
    Flight path vector - circled
    Nav symbology will be done today. I'd like to thank Toshiba for the Qosmio X300, the most ugly laptop ever made but certainly a powerful machine.
     
    Source
  19. 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
  20. Flexman
    Another disaster strikes, PC wont boot at all. Strange thing happens on the BIOS screen, the moment any attempt to detect any drives (and I tried a few different drives that I know were fine), a bright underscore character appears under the circled comma (picture above).
     
    So apart from my laptop I'm now without a working PC and no means to fix it atm :/
     
    Source
  21. Flexman

    HMD flight symbology

    By Flexman,

    More flight symbology added today. Raining almost non-stop and my cars wiper motor has failed, so wasn't going anywhere.
     

    We added a couple of items that make it possible to do some precise flying.
     

    Velocity Vector Acceleration Cue The Velocity Vector is the blob on the stick that originates from the cross in the centre of the HMD. This is a representation of the direction and speed of your aircraft. Think of these as "top down" views with your aircraft in the middle, forwards movement is up, sideslip left and right. It's scaled so that the top of the HMD (below the heading tape) represents 60 knots. This scale changes depending on the mode but for now I'll stick to the TRANS (transition) which is the most used.
     
     
    Floating around the end of the "stick" is a circle, that's the Acceleration Cue which shows your helicopters acceleration. Generally the blob on the stick will steer towards the Acceleration Cue as you manoeuvre the aircraft.
     
    Using these cues it's possible to perform some precision flying and arrest unintended movement before it becomes a problem. Learning how to read these will improve slow speed manoeuvres approaches and landings.
     
    I also changed the rate of climb indicator to a solid pointer, slip ball is currently being added. And basic waypoints and steering cues will probably be done this weekend. Especially if the weather is still lousy.
     
    Source
  22. Flexman

    HMD virtual symbology

    By Flexman,

    HMD = Helmet Mounted Display
     
    Remember when Virtual Reality was going to be the next big thing? Seems odd having to re-create something virtual in a game that is virtual, the modern Apache has evolved a bit since the late 1990s. Being able to display in the pilots 3D monocle (yes that's a joke) a lot of data to the crew about targets hidden behind objects, terrain contours. These 'virtual' items are matched 1:1 with the crews head movement unlike a lot of the symbology that is static.
     
    The first one we're going to look at is the "head-tracker". This is a broken diamond that represent the nose of your aircraft. As you look left you should see the diamond maintain a relative position to the nose of the helicopter. For give my "Novalogic" terrain map.
     


    I had a bugger of a time getting the function to match up to the outside world until I worked out I was missing the aspect ratio of the window (the HUD has a scale factor too in case it's too big or small for your resolution). We're ready to add the waypoint indicators and LOAL/LOBL missile constraint boxes. The flight path indicator is another one, that represents the position of the aircraft in (I think) one second? Have to check my notes on that.
     
    You might see some alerts on the UFD that shouldn't be there, as always it's not final and I know about them.
     
    The cockpit seems slightly offset from the absolute outside world position, now the crew does seem to sit off axis but I'm checking this out. The camera positions are absolute and bang on the X axis zero line of the aircraft and not directly centred on the crew seats. It looks a bit odd otherwise. Looking into that anyway.
     
    Source
  23. Flexman
    It's a sentence I pulled out of context from the recent Unity newsletter. It relates to a Mobile Generation Education Project, a project with a $250k giveaway to help students become the mobile innovators of tomorrow.
     
    Now, when I was a student, we didn't have mobile phones, or the world wide web. And if we did, we'd have moved onto something else by now. Teachers point out that 60% of the jobs their students end up doing haven't been invented yet. I helped develop Risk Assessment software used by Walmart among others, five years later it's old technology. Everything moves so fast in this information age and it's accelerating.
     
    I wonder how much of this social web technology that is perceived to have permanence will be around in ten years or even five. I'm starting to see an effect that could be best described as Dawinism applied to digital data, a process of selection that results in the useful data being retained (at least higher up the search tree) and copied. And this process snowballing with an ever increasing amount of new data.
     
    With amazing concepts of collective information gathering such as Seadragon and Photosynth on the horizon, any guesses as to what the future holds in information mining are just that. If you don't know what Photosynth is then check the link and prepare to have your mind blown by possibilities of this and other forms of data.
     
    It doesn't take academics to come up with these kinds of ways of looking at data, it takes a creative (and ever so clever) mind. Picasso said everyone is born an artist until it's taught out of them.
     
    Right, that killed 10 minutes. I wonder if anyone will be referencing this blog entry when I'm gone from this world. I expect the URLs will have long since died
     
    Source
  24. Flexman

    ENG rebuilt

    By Flexman,

    Been pretty ill this last week, progress has been sporadic. I took time out to rebuild the engine code so it's now the same for all Apaches, AI and player alike.
     
    Pilot feedback from screen-shots and videos also allowed me to rebuild the whole engine start-up and ENG display page. Automatically switches to in-flight mode. Things blink, change colour, are boxed appropriately. Couple of bits left to do, the biggest headache was dealing with all the fiddly scale changes and adding new code to simulate power transfer which needs some attention. Here's the page with some values thrown in to show some extremes. The whole thing is worthy of a tutorial video sometime.
     

    Still have some parts to add to the engine simulation, oil, temp. Rotor speed and torque needs values from the new flight model to work properly but essentially it's just polling values from the helicopters state. Oh another thing I didn't put back in, the actual transient timers, these are counters that show how long you're flying outside of normal parameters which can shorten component life or lead to failure.
     
    The new alert system which I also had to overhaul is ready to drop the betty samples in en-mass.
     
    Will tidy this up tomorrow, look at where we are with the new flight model and see about the Leadwerks 2.40 engine upgrade. The PHY situation is not bad as I thought since we're not using LE for vehicle physics.
     
    Source
  25. Flexman

    CH-47D - work commenced

    By Flexman,

    For the record, practical work on the detailed CH-47D interior started yesterday.
     
    The CH-47D is a great machine better suited to the environment in which it will operate in Combat-Helo. The Chinook (prn: shin-uk) is a surprisingly nimble and small helicopter, not the large lumbering giant as is often perceived. What you may find surprising (I did anyway) was that it's about the same size as the Apache. See the comparison image below.
     
    Apache / Chinook size comparisonIn Afghanistan, the CH-47 usurped the role of the UH-60, having a larger lift capacity, no energy hungry tail boom, armed protection from it's ramp and door gunners as well as a range of countermeasure devices. It's range, power and speed has saved the lives of many Afghan civilians and troops in the region. Additionally, transport helicopters reduce the reliance on vulnerable road convoys and are important in maintaining remote security outposts.
     
    The AI CH47 will be included in Combat-Helo. If we hit our sales target we hope to release a flyable CH-47D with detailed cockpit and systems as an addon (or stand-alone version - to be decided), as Combat-Helo Operation Pegasus. This will add the CH47 as an option to fly on medevac, armed escorts, insertions, extractions, transport, search and rescue missions as well as a new variant of the counter insurgency campaign.
     
    We feel that this is the better choice, it lets us explore the portalised aircraft technology we started with the Apache which will enable a level of interaction between crew that hasn't been seen in any other PC simulation title to date.
     
    Source
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...