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
    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.
  2. Flexman
    Added a simple frame-skip to MPD draw method, they don't need to be updated every single frame and it squeezes out a little extra. Found a "toob" video in which you get a couple of frames of the UTIL page. Anti-ice and FMS options, presumably this is where you can toggle pitch roll and yaw augmentation. Well seems like a good place to add that and we will need to flag some FMCS values for HTR which can auto-trim. Turning that off in the UTIL page will be handy. Looks like "NOE?" at the bottom too. No idea what channel that's supposed to be.
     
    Got some strange problem with my matricies with the new vector glyph render, fixing that this morning. Will update with a screen-shot when fixed.
    Noooo, a totally numb-nutz error. My old OpenGL line macro uses integer verts, switching to floats. Oh man, how dumb.
    PC froze unexpectedly this morning. It hasn't done that in ages.
     
    Source
  3. Flexman

    Some more architecture

    By Flexman,

    I think these have been on the SimHQ forums for a couple of days but I've been too busy to post any updates. Here AD has been adding some gardens to the Friday Mosque and adding it to the city.
    To overcome scale/zbuffer issues of having a large scene, AD has buried the the tiled gardens into the terrain, just like the river sections. The gardens sit on a large slab that is quite deep, this also accommodates uneven terrain.

     

     
    No paved road surface currently. While Leadwerks supports roads that are baked into terrain geometry they are not efficient for our large scale map. One of the reasons we're looking to build our own terrain streaming system after Combat-Helo is released. We might be able to squeeze in another texture layer to splat a paved surface in.
     

     

    A high altitude view of the city shows the west side is still waiting to be populated. This was the area most damaged during a previous regional conflict.
     
    Source
  4. Flexman
    We've been using the black and orange diamond logo for some time, it needed to reflect the game colour palette. As a 90's homage to sims of that era, a saturated colour scheme with the GUI elements using 90'-45' angles, black and orange. Two contrasting colours that are visible against most backgrounds.
     
    It wasn't until after I had designed and coded a number of elements that I noticed other military games using the same colours.
     
    Why bother with stuff like splash screens at this stage?
     
    They set a tone and expectation when showing demos, fix the colours and facilitate feedback on identity early on when things are still fluid. In our case, we have possible issues of copyright and licensing, issues that came about through the process of establishing identity. Matters that are hardly trivial.
     
    Plus the above vignette style works much better on multi-screen monitors when centred than the old one which was stretched. This has better overall presentation. Logo is still in flux but overall colours and shape are there and reflected through the whole game in every interface element.
     
    Source
  5. 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
  6. Flexman
    Swimming was one.
     
    Setting up controllers in XPlane is another.
     
    Yes the things you thought were going to take a few days which turned into a week and a bit (you could almost say 'two weeks'). Josh at Leadwerks gave me a leg-up on how to put an MMO style launcher together and I've almost done wrapping up all the security for the necessary database, key code generation, CVS style updates and all the stuff we need to match individual content to clients. We'll make available downloadable content (DLC) such as new maps and the occasional helicopter (the planned CH-47D), not to mention the odd mission pack.
     
    No, this key won't work, it's a fakeSo there was a lot to do to make a simple one shot MMO style launcher. The back-end server stuff had to be built from scratch. The launch .EXE calls home, applies on-demand updates and preps game settings for launch. For simple security sakes I layered server-side scripts for handling the updates, admin and audit. Auditing is handled by triggers, SQL injection is futile since only one procedure is exposed to clients.
     
    Any DBA will tell you Auditing is an important part of any security. If you build any kind of database exposed to the internet and you don't build your own layer on top of any default transaction logging then you're kind of asking for trouble. The database engine used here is not known for keeping detailed logs so it was necessary to build one anyway. Things you might want to think about if you ever need to create systems like these are making log indexes suitable for frequency analysis (this one method Twitter uses to spot spamming), fake open doors and keys and silent alarms. My favourite trick in the past was a fake database that gives the intruder a high and makes them believe they have walked away with the crown jewels while evidence is collected. That sort of none-sense is not required here, I kept this one functional with a tiny footprint.
     
    The Pilot ID we'll be sending out is the key to your content; install once, play as you like. If you share copies around on your network you can launch 'offline' no worries, no need to be connected to the internet until you want to update. It's nice if you want to buy multiple copies for your network and support the effort put into this project but I'm poor too so I know how it is.
     
    Little bit of script consolidation and testing to do before we let this loose in the real world.

     
    Source
  7. Flexman
    All the things we want to show but can't. Still making some final hour changes to get a robust demo working that can be operated by Joe Public (I'm told he's coming along). A simple flying demo that will show the technology, Afghan map, lighting and cockpit. It has the mark 1 flight model I keep tweaking. sounds could be better. I wish I had time to do the landing gear joints, it's hard to land without wheels.
     
    Better stop with the bloggin and get back to writing.
     
     

     
    Source
  8. Flexman
    I want to thank Komodo Simulations for inviting me down for Summer Sim 2010, even though it didn't go according to plan we all learned a lot, I certainly did and this was really a chance to meet people and forge connections.
     
    Rich was clearly deep in thought and concerned about hardware performance. I was lost in deep thought and concerned about software. Everyone else didn't seem to mind very much. What happened was, early in the day while I was re-compiling the demo to fix a stupid inverted axis problem, FSX was running a helo demo and a visitor came and stomped on the left pedal, ripping out the weld and smashing the Hall sensor. We had to make do with alternative hardware (thanks to Flightstore for the loaners etc.)
     
    The "Virtual Blade", but nothing virtual about it, very real.
    What you would have seen today.
    If you came along, thank you very much to coming up and saying hi, I'm really sorry you didn't get a chance to see (much) of the game. Things just conspired against us from the start. But we'll get a new movie done showing some of the things we wanted to show this weekend but didn't. Oh, please email me if you were there as I'd like to get your names for future reference.
     
    Laptop demo, not a flying toy
    I came away with a Saitek X62; a stupidly knobbly joystick that has more buttons and hats than you thought was possible to put on a joystick. And also a Saitek Instrument Flight Panel which are those little LCD panels with VGA resolution (320x240). This morning I installed the Saitek OpenOutput SDK on my laptop (which continually gave me a memory errors after compiling till I rebooted *grrrr*) and got the 512x512 MFDs in Combat-Helo supersampled down to 240x240 to fit Saitek's panel. It was readable, not great, but certainly readable. The SDK is quite nice, a lot of callback hooks and functions for sending JPGs, BMPs and text to the screen. It's actually a good resolution for the Upfront Display, some nice chap at the show asked about (sorry I forget your name, even though I asked I'm pretty terrible with them). I'll post a pic later when I get a chance.
     
    I'm going to have to get a new stick of RAM for the demo laptop, it was one more thing letting me down. Yesterday it was crashing randomly when trying to run the demo and same again today when compiling. What's more the changes I made to fix one issue caused enough which I didn't notice till later (collective at 230%??), silly typo.
     
    The Komodo team comes equipped with a deadly "nice-guy", a chap so full of charisma he could (with apologise to Douglas Adams) charm all four legs off an Arcturan mega-donkey except perhaps the manager of a local restaurant who insisted it was perfectly normal to wait two hours for your starter. But at least the conversation was good and I learned fascinating things about horses.
     
    Thank you "Cyclic" (aka Rob) for being my point man again, have a good trip back to Saudi. Phil, I know you couldn't make it but the photo you sent of the Blackhawk Down fish pond decoration was a real ROFL. Every pond should have a crashed helo in it. (Rob, can you send it to me?)
     
    Day two and the chair was fixed, sorry I couldn't stick it out the whole day but there was a lot of interest in the chair and it was a really busy Sunday. We'll be looking to have a special Combat-Helo software/hardware package with a replica Apache control system consisting of a cyclic with magnetic force trim and full length collective. Unless it all goes pear shaped of course. How much will it cost? We'll you know but estimates sounded reasonable and not far off a certain A10 replica stick soon to arrive.
     
    Actually we all had a long chat about the Thrustmsater A10 and while Rob in particular voiced how nice it looked, the fear is that they will drop the ball again like they did with the Cougar. The trust isn't there anymore. A scary thought.
     
    *edit* The X65 force sensors are amazing, apart from the **** plastic HAT2 and POV (also plastic) it's pretty slick. Most of it's metal including one of the HAT, so why skimp on the rest?
     
    Sunday: the Komodo Simuations camo tent "FARP"(Rich, forground left looking pensive)
    (and YES I finally got my bloody PC Pilot subscription, can you spot where?)
    Thank you to my hosts, Rich, Mac and the nice lady who needed chocolate. Good luck at Duxford next week (it's also Battle of Britain weekend there so it's going to be mental). Take a spare
     
    Source
  9. Flexman

    TADS/PNVS Stow

    By Flexman,

    I wasn't sure about the STOW angles so I set the PNVS to 165 inboard (0=along the nose) and TADS 180' inboard. Activated via the NVS mode switch in the cockpit (or CTRL S). The CPG station doesn't seem to have the noeswheel/NVS panel unless we missed it. You'll just have to play as the pilot if you want to flip the switch by hand.
    Switch has 3 position, off (stows the sensors for transitional flight), normal for tracking head movement and fixed for boresight (straight ahead).

    The NVS Mode switch is located forward of the engine power levers, left side panel.
     
    Source
  10. Flexman
    Currently testing the autopatcher software. Broadband upstream speeds being what they are, don't make this a fast process. The project core files are currently around the 300mb mark spread over 1300+ files. This will come down when we package them.
     
    The benefits of having an autopatcher is the ability to push updates for CombatHelo on a regular basis without too much hassle and players having to negotiate versions when playing with friends. Just run the updater and everyone should be in sync.
     
    Source
  11. 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
  12. Flexman
    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
  13. 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
  14. Flexman
    Actually the rotor brake system. I'm not really clear what would happen if the rotor brake is off when you move the power levers from the Idle to Fly position. Procedures say DONT, return the switch back to on until the engines are at flight speed (approx 100%). Once the engines are happily settled at flight speed flip the brake off and the rotors begin to turn. Watch the rotor RPM gauge on the MFD until it's in the yellow close to 100% then you're good to go.
     
    Conversely, I'm not too clear what damage might occur when then rotors are at 100% and the rotor brake switch is is turned on. A lot of heat and grinding metal noise? A nasty letter from the Boeing company? Currently I just have it decay the RPM to zero under a constant until I get a better answer.
     

     
    I added more realism options to the config.xml for control over individual items like startup, targetting, flight model.
     
    OOOH, I just remembered why I was really happy today. AD fixed the road physics problem by using displacement mapping in 3DS MAX. So no hacky hacks may be required for road driving afterall. Well done sir. I knew I was feeling buoyant for a reason. If you want to know what the hacky hack means, the road surface was aligned to the terrain with a vertex shader which moves each point on the model level with the ground (relatively) but physics engines don't know what vertex shaders do to geometry, as far as they are concerned the model is unchanged. So there's a disconnect between what the physics engine updates and what the 3D card renders on screen. Using displacement mapping with our heightmap as source, the road meshes are baked at the right elevations to fit, the physics model and visual model are now united and traffic may now use the roads without any problems.
     
    So, way to go AD. Another cracking solution.
     
    Source
  15. Flexman
    After close checking of memory usage when boarding and exiting the Apache there's feedback saying that objects are getting freed and memory dumped, except it isn't. Only a small percentage. There are object references that are keeping the cockpit and avionic entities alive and preventing them from being released.
     
    Going to take a little time to track each one down.
     
    *edit*
     
    The large memory leak located, was the TADS camera world not being released. It's been removed for now.
     
    Source
  16. Flexman
    The 3 active IR-LED head-tracker clip was never made of study stuff, constantly falling apart as soon as you put it down on the desk. Now it's finally disintegrated, I might have to resort to super-gluing the tattered remains.
     
     
     
    Microsoft Kinect apparently shoots out hundreds of IR beams in a grid pattern and uses that to build a set of data points from which the software can pull out a skeleton, track body motion. It's a motion capture studio in a box. Brilliant, for indie game production I like the idea of using it for creating motion capture files.
     
    Source
  17. Flexman
    Formally announcing the foundation of the legal entity Tricubic Studios Ltd. developers of Combat Helo, associated content and iPhone/iPad games / applications.
     
    This doesn't change very much, it grants us a recognised identity for trading, taxation and investment. Plus we get a chance to develop an insipid company website. We plan to have our first mobile platform release ready for the summer. More details on that in a few weeks. Blog updates will continue at this location.
     
    Source
  18. 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
  19. 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
  20. 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
  21. Flexman
    I'm putting together specifications on the mission side of the game. To me, the bit that you 'play' is every bit as important as the simulation side, and while it's taken a back seat for now, things are getting to the point where it's time to get on and make it all work. Going through some of my older material on this, it needs to play like Longbow 2, have the crew management elements from Gunship 2000 and strategy elements from tactical board games on guerilla warfare and a bit of a story element that wouldn't be out of place in a Chris Roberts game.
    So where do we start? Units, missions, events and triggers.
    Units perform missions, missions contain waypoints, events and triggers. So lets start at the top and work our way down.
    Missioneering
    Not many will remember the last iteration of my mission planning tool and generator, Missioneer Delta pictured below, circa 2000, seems like almost 10 years ago :/

    The plan is to put in something similar onto the command tent terminal you can operate to change waypoints and assign untasked airCREW to helos to carry out listed missions. In some ways this is not unlike Enemy Engaged. Missions are not necessarily assigned to aircraft (they can be), but we'll assign them to the player, AI pilot or crew. Like the arming system, it will be possible for a player to take the role of a commander and assign missions to aircraft that pilots execute.
    You can walk around and choose an aircraft that's not already assigned (see it's info plate when on foot for status). In future we hope to have a selection of helicopters/vehicles (CH-47) but we're focused on the Apache.
    When the player boards the aircraft, this is like loading a data cartridge with your mission detailed into the aircraft's avionics. The TSD will be updated with waypoints, times and mission page populated accordingly. First man in sets the mission.
    The mission ID# key is set in the vehicle entity. This is reset on one of two conditions, the player has exited the aircraft for 5 minutes or the master zeroise guarded switch in the cockpit is operated. In the case of the latter, a new mission profile can not be loaded until all crewmembers have exited the aircraft.
    Mission ID# is just a key reference to the hosts list of active missions which can be viewed on the command tent terminal (connected to the projector).
    But we're getting ahead of ourselves. Missions and units need a detailed specification which is the point of this blog entry and my current task.
    Running under the surface of the simulation will be the all important campaign engine which iterates through units. We'll take the term UNIT to mean a collection of vehicles, a "group entity". Lets look at an old user editable unit form, take from Missioneer. Nothing really remarkable about it, just happens to be handy.

     
    So we can see some of the basic parameters of a unit. There's a list of entities than make up the unit, a 'formation' which is a list of relative positions that each member of the group will attempt to follow (we'll have some behavioural exceptions to this). An orientation, direction to face when at rest. A name, something fancy and military. Skill level, agression and some factional information.
    There are also some timers, our game runs in a real-time 24 hour clock cycle (with time advancement). So unit timers might be relative to an absolute time (world time) or mission time (from dust-off). Timers have an enabled/active status too in case they need to be activated by triggers.
    For example, if we want a group of insurgents for player assigned patrol mission to spawn when a player has taken off, the mission engine will assign a MT (mission time) of "00:00:00mt Active", but we might want them 5 minutes into the mission, or not spawn at all except by some trigger, such as a player entering the engagement area.
    Or we can set the unit destruction time (just means the de-spawn time). For example, a rescue against the clock, get to them before they are discovered by encroaching insurgent forces. Once depawned, that would trigger a unit removal message which another event trigger can listen for, signalling a mission fail.
    So timers are simple unit level events that require no special handling by an event system. But for our game to handle recognition of a "win" or a "fail" situation we'll need to add a basic "cause and effect", a "cause" being destruction of unit "x" with the "effect" being "mission complete".
     
    Mission Events
    SpawnUnit (unitID) DestroyUnit (unitID) SetUnitWaypoint (unitID, waypointID) SetUnitFlag (unitID, active|weapons_free|godlike|formation|state, param) SetUnitFaction SetMissionResult SetWorldFaction( factionID, delta) SpawnObject (objectID, parameters) CreateWaypoint (unitID, waypointID, location, speed, altitude) Play Audioscript (script or audio filename)
    Mission Triggers (in any active combination)
    MissionRating (percent, win|loose|draw) MissionTime (+ - secs, MT|LT) UnitDistanceFrom (unitID, targetUnitID, distance_meters) UnitDamage (unitID, damage_percent) UnitWaypoint (unitID,at|before|after, waypointID) UnitStatus (not_in_combat|combat|flee|panic|landing|takeoff) UnitInZone (unitID, zoneID) FactionDelta (factionID1, factionID2, + -value) DiceRoll (percent)
    These are enough for the campaign and mission system to generate pretty much most situations.
    Now the tricky part is to build the logic to generate seemingly intelligent behavior and entertain missions using this small command set. And here is where we can have a lot of fun.
    We could extend the complexity of the logic further by adding a LUA Get/Set interface for the event system. Then user made missions can apply some complex logic. Even creating whole missions from a LUA script. This is not something we want to do at this time. But for the future, it could be done.
     

     
    Source
  22. Flexman
    My wife reminds me that it takes typically two weeks after each engine upgrade to get things working as intended.
     
    There's the odd "caps sensitive" issue in some of the LUA source. And a quick change of fw.Main to fw.main in Renderer to get ll the helo/sky scripts working. Rebuilding the lua-gluefunctions and making sure not residue from the previous version was causing problems.
     
    All that's left is handling changes of appearance and shaders....and re-serialising all of the 3D work.
     
    Performance is fantastic almost doubling frame-rates in our vegetation heavy scenes. The vegetation rewrite has been well worth the effort, with collisions and lighting changes. More varied lighting does a lot to reduce the uniform appearance at range. At least I hope the lighting variations are intentional and not some shader problem. The evening skies came out purple in the new version for some reason, now I really like this colour. It reminded me right away of the
    . Nailed the colour palette. 
    The downside is the need to re-export all the 3D work. The cockpit simply doesn't work anymore except for a couple of buttons. Interestingly the weapon arming only 50% works too, that uses linepicks also. And the upfront controller material has a normal map smeared over it. I'll have to look at the materials for these, make sure it's not using one.
     
    And the occlusion culling is a little problematic. Half of the cockpit vanishes at certain angles and the helipad and radio towers vanish, and when they do other objects tend to go with them. Those are typically large objects, the helipad is often positioned so it intersects the terrain. It's all very strange and interesting doing these updates
     
    I'm hoping a lot of problems are just down to the need to fix up the 3D assets. Some behaviours have changed, Coronas, I used as hazard lights are so dim they are hard to see. Also the sun as represented by a Corona, now seems to have been flung from the heavens and lets you 'walk' around it. But is still rendered in the background world.
     
    In the mean-time while I go through those assets I'll continue work on the current 'stable' build. I've added config options to set the server and port address with an 'auto join' flag to start the client mode after game load. The 'radar' dish (pictured above) is another interactive object that gives access to multiplayer options. Start Server / Client Connect and an as yet unimplemented address-book.
     
    I'd like to thank AndyGFX for his posts on migration issues past and present that helped enormously, and also Macklebee, Red Ocktober and others that have also been posting their issues and solutions.
     
    Source
  23. Flexman
    I know it's a little late for Valentines Day. Excessive flapping, bumping and separation is discussed in this priceless US Army video from 1980. If only they had "RotorCam ™". The Apache has a fixed rotor, mast bumping isn't an issue but it's all part of helicopter theory.
     

     
     
    I've been forced to continue hunting for other employment to deal with a mounting debt crisis. As a result work was put on hold the past two weeks (hence the lack of updates). I apologise for letting my post slide, the project really is taking a toll. I've been ordered to get back to Combat-Helo ASAP (taxes and all that business stuff needed to be done too), I'll be updating as well as I can. There's an engine update to finish rolling into the project (I started on that earlier in the week, this fixes a problem with terrain and I hope the EntityUserData and hierarchy problem).
     
    A Twitter follower suggested I post some Gun Cam footage, I had a look at that and found vegetation range/LOD issues in the MTADS camera need dynamic adjusting (not sure what the most efficient method will be yet).
     
    I'll just round this entry off by stating that raising funds in the UK for technical entertainment projects is very difficult if not near impossible. Bank staff/accountants take one look at video of Apache cockpits and give you funny looks like you're some kind of gun nut (that actually happened).
     
    In the meantime, enjoy the technical detail of the above video.
  24. Flexman
    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
  25. 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
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...