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

    More Apache work

    By Flexman,

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


     
    You have control.
     
    Source
  5. Flexman
    AD made some atmospheric screen-shots when playing with lighting and environment settings. SimHQ Diary
    Starting with the only major airbase in the region. AD is responsible for some Strike Fighter mod aircraft models, one of which is a Tornado GR1 (?). Which he's used here. I don't think these will be in the game unless we get permission from the original mod maker to use it. But it does look nice.
     

     
    This is our early version of Camp Stone complete with a half-court basket. You wouldn't have a pair of M1A1s on the doorstep but they do look interesting.
     

    Poster child..."never alone"
     

    We have been hard at work on getting a simple flying demo ready for a public showing, we've had to make it playable and gave me an excuse to put some more time into the mark 1 flight model which is a much simpler easy to fly model for general consumption. This approximates the mass of the helicopter, rotor thrust from engine power and semi coordinated turns. The landing gear desperately needs some joints to make it easier to land but I don't think I'll have time for that.
     
    Following the road north our of Camp Sone you eventually approach Herat, our version is perhaps more idyllic taxi-free version, and perhaps more green to make efficient use of geometry. Enough to fill enough area to represent a small city.
     

    No orange sunset here. Looks much more natural.
     

    Freecam mode lets you move anywhere you want to take snapshots. Contemplating broadcasting a regular call to prayer from the towers at the appropriate local game time.
     

     
    Nice choice of sky. You can see what we had to do to the rivers to prevent a lot of clipping and z-buffer fighting. Hence the "Death Star Trench" name we use.

     
    Source
  6. Flexman

    Missing lighting knob

    By Flexman,

    Dave, the kids must have been playing "pilot" again, they've gone and pulled off the knob for the standby instrument lighting, make it like the other two rotaries. I'll fix the camera clipping on the seat
     

     
    Source
  8. 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
  9. 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
  10. Flexman
    About: This is a short series for the Leadwerks community on the process of creating a simple game using procedural content.
     
    In part 01 we looked at one theory of generating random maps in the style of old school dungeon crawlers. This week we'll put that into practice to generate map data, room geometry and mesh colliders. The easy part was adding a flying physics based camera to act as our first-person flown "spaceship".
     
     
    Again I want to flag I'm not a LUA expert, this is not a LUA tutorial but like most languages they are a syntax away from common functionality. It includes examples and explanations of some LUA code to relate why I did something a certain way. What you see is what you get. All code is freely available for use and modification however you see fit.
     
     

    How to use the code and run any examples in this series
     
    After working on the code a short time I found using the Leadwerks ScriptEditor.exe better for the process rather than attempting to run and debug it as an editor script. And one last note before we get on with it, 99% of the assets are included the Leadwerks SDK media folder so please edit the "MediaDir" in the LUA source. Any other required media will be included as a download.
     
    Pre-amble over with. Lets get to it.  
     
    Map Data to 3D Geometry - first experiment
     
    The focus for this tutorial is generating map data then creating 3D geometry from it. The latter raised several questions about what would work for a tutorial and flexibility for use in different kinds of games. So I've focused more on this side for part 02. (Also I had to re-write it meaning less time to work on the map data code).
     
    My first room generator working prototype created "shoe boxes" as pictured below. With lighting, ambient sounds and the physics on a controller to fly your 'ship' around in first-person view it was a passable bit of code.
     
     


    figure 2.2 - "ShoeBox" room and corridor structure  
    "ShoeBox" was efficient in that it was a collection of flipped volumes with light sources, individually painted surfaces (6 materials) and would be good for a simple iPhone adventure.
     
    When it came to merging volumes for more complex rooms I realised there would be a lot of code needed to split up geometry and re-build it. Rather than turn it into an exploration of CSG, triangulation and mesh simplification (which is not trivial) I ditched it for another simpler approach.
     
    Going back to how 2D games work, room geometry became a collection of grids (figure 2.2) that can be thought of in terms of traditional 'tiles'.
     


    figure 2.2 - tiled room (aka a regular mesh)  
    Looking more like a terrain mesh with walls and roof, the grid structure makes it easier to merge volumes, add doors, corridors and holes traps or vertical shafts. And by increasing the mesh density and adding vertex noise you can turn rooms into caves with bumpy walls. I felt justified in presenting this method as it allows more possibilities and simplifies geometry construction.
     
    In appearance it's quite like old-school cells and tiles, similar to existing 2D dungeon map generators. In my working prototype you can't individually paint a tile but it might be possible to modify the code to allow for UV painting and save out this data. Each room can have it's own unique set of materials.
     
     
    LUA code-time. Geometry Construction
     
    Leadwerks like other engines provides tools to create solid shapes entirely in code. First you need to create a Mesh object then a Surface object attached to that Mesh.
     

    local room = {} room.mesh = CreateMesh() room.surface = CreateSurface(room.mesh)
     
    Note: For clarity this is using ONE surface, this will be expanded to use a six surfaces for each side of the room. The important part is that you add geometry to surfaces, you paint surfaces with materials, you create colliders with surfaces. It's all about the surfaces baby.
     
    All room elements such as walls, floor, lights, props etc. are parented to the room.mesh which is positioned in world space. Moving the room is as simple as calling Map:Room[id].SetPosition(x,y,z)
     
    Really evil dungeon masters might want to re-position a room with players inside. Well you can do that, even rotate it. Parent the room to the whole map (which has a pivot) and you can roll the entire map around for a marble game. All walls are solid but as they are one sided you can see right through them when viewing from outside.
     
     
    Patch Maker
     
    Let's look at a LUA code snippet for creating the roof and floor mesh, I want to draw attention to one of the cute things LUA can do and if you've not come across it before it can be confusing. So I draw your attention to it now. The assignment of (nameless) functions to a table and indexing them by string.
     
    Depending on what part of the room we are building we take care vertices are wound the correct way and the vertex normals are perpendicular. So I put the AddVertex() and AddTriangle() calls into a table and for ease of identification indexed them by string such as "roof", "floor", "north_wall" (walls not included here for clarity).
     

    addvert["floor"] = function (s,x,y,height,xsize,ysize) return s:AddVertex ( Vec3( x-(xsize * 0.5), height , y-(ysize *0.5) ) , Vec3( 0 , 1 , 0 ) , Vec2(x / (ysize*0.1), 1.0- y/(xsize*0.1)) ) end addvert["roof"] = function (s,x,y,height,xsize,ysize) return s:AddVertex ( Vec3( x-(xsize * 0.5), height , y-(ysize *0.5) ) , Vec3( 0 , -1 , 0 ) , Vec2(x / (ysize*0.1), 1.0- y/(xsize*0.1)) ) end addtris["floor"] = function (s,v,ysize) s:AddTriangle ( v-ysize-1, v , v-1 ) s:AddTriangle ( v-ysize-2 , v-ysize-1 , v-1 ) end addtris["roof"] = function (s,v,ysize) s:AddTriangle ( v-1, v , v-ysize-1 ) s:AddTriangle ( v-1 , v-ysize-1 , v-ysize-2 ) end function Map:CreatePatch( surface , width , length , height , mode ) for x=0,width do for y=0,length do vcount = addvert[mode](surface,x,y,height,length,width) -- we degenerate first row and column when making a grid if ((y>0) and (x>0)) then addtris[mode](surface, vcount , length) end end end end
     
    Our room geometry code needs to call the patch builder with dimensions and the name of the component like thus...
     

    -- example useage from the room builder Map:CreatePatch(room.surface, 8 , 8 , 0 , "floor") Map:CreatePatch(room.surface, 8 , 8 , 2 , "roof")
     
    That's the easy part. We will need to extend Map:CreatePatch to take our merged room data and generate an appropriate mesh to fit the irregular shape of our rooms and corridors as supplied by our dungeon creator.
     
    Now we have a method to generate basic rooms which is easy to modify we can look at the other problem; creating our random map.
     
    Remember the map structure we're looking for, a grid of cells into which we position at random offsets a regular set of rooms (see figure below). Each room being of variable size and can overlap. For this part of the tutorial we're going to keep the rooms small enough to prevent overlap to keep the source size down and reduce the complexity. We'll cover triangulation for a more advanced geometry function in a later part. In other words I couldn't get it to work properly in the time allotted.
     


    figure 2.3 - room and corridor structure  
     
    We'll begin with a creator function...
     

    -- function to build entire map -- params: random seed value, xsize and ysize (dimensions of map in cells) -- roomscale (is multiplier of room size in world units) function Map:Create( seed , xsize , ysize , roomscale ) math.randomseed( seed ) if roomscale == nil then roomscale = 1.0 end Map.roomscale = roomscale Map.roomheight = 2.0 Print("Creating map, dimensions " .. xsize .. " x " .. ysize) -- table to store our rooms Map.Rooms = {} ... ... end
     
    For our dynamically generated game level, we need to know a couple of things;
    How big in game cells (how many rooms across and down)
    The seed from which the random nature of all springs forth (how poetic)
    How big we want the rooms to be relative to each game cell (room scale).

    A tile is simply a value stored in a 2D array e.g. tile[x,y]
     
    Our data would benefit from being organised into a grid. A 2D tile structure which represents an overhead view of our 3D world. This makes tile arrangement makes it simple to merge rooms and corridors, flag as walls, doors, traps and anything else we might want to generate. However...(c'mon you knew that was coming)...
     
    If we want to make really HUGE levels then array mapping will be inefficient, the 400x400 grid in our example will be fine but anything larger will become resource hungry as we increase the world size. Much of it becomes empty space.
     
    To avoid unnecessary memory usage and run-time costs we will virtualise the space a little. We've done it already with our room nodes (figure 2.4)
     
     


    figure 2.4 - room nodes are virtualised rooms  
    Note: A room object simply exists at world_x, world_y and is this >< big. This is for boundary test and positioning.
     
    We will use a 2D array of tiles for each room. Each tile maps to a room_x, room_y. This way the data is available to game logic for locating objects, spawn points.
     
    After room generation is complete we run a post processing function to merge rooms, this is where the tile array comes in handy.
     
    The room merge steps through all rooms, a boundary check is performed on neighbours and merging into a new room as needed. Corridors are considered rooms (just thin), where they bend they are in fact two overlapping rooms and should be merged during the same process.
     
    After rooms have been merged, the geometry builder works on the new set of room tiles to spit out all the required meshes, lights and props.
     
    Infinite Power!
     
    In theory we can make an infinite dungeon if we move the rooms around us at the origin and use world space as a random seed for new rooms. An order of magnitude more advanced than Very Big Cave Adventure.

    10 PRINT "You are in a cave (N,S,E,W)?" 20 INPUT a$ 30 GOTO 10
     
    Out of time!
     
    Yes I've run out of time for part 02 due to code re-writes. I'll write up the room generator code as part 03 and post the example code with it. Then we'll start to see the two halves coming together and creating our procedural maps.
     
    Preview: HUD Overhead Map

    First pass on HUD to show location of rooms (with ID) within the randomly generated map complex.
  11. 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
  12. Flexman
    I've been using this for testing and making profiles for Combat-Helo since the weekend. This is a really odd stick. It's perhaps the best built joystick out of the box I've ever had the privilege of using. And quite a looker too. The textured metal feel, the metal triggers and even a couple of the HATs. Oddly this level of build isn't consistent with several hats made from what feels like a poor quality plastic. But it wasn't broken or badly assembled, and nothing has broken yet.
     
    If you didn't know, the X65 is a force sensing stick. It doesn't move and is really sensitive to tiny amounts of hand pressure along the x/y and rotation axis. The amount of pressure you apply is translated into a direction. It makes fine control a joy since there are no springs or rubber boots to interfere with your intent. Apart from the plastic hats I don't have anything to say about the stick. Just really nice to hold, use, and with no moving parts it should be reliable. Guiding the Apache in Combat-Helo around for landing can be tricky made easier by the X65.
     
    Then there's the throttle. *sigh*
     
    Again beautifully made except for the dual throttle tension adjuster, a tiny hex screw on the underside made from the softest metal on the planet designed to dissolve on contact with anything heavier than neutrinos. The dual-throttle operation set to the weakest tension setting requires quite a lot of force. More force than is comfortable or practical for a helicopter collective that might require a good percentage of travel quickly. The perfect combo would be a separate collective controller and then just use the dual throttle for the engine levers. Also it has a rather unpleasant sounding 'gloop' noise when operated, like there's a lot of grease inside being moved around. The noises are almost pornographicly sticky.
     

     
    So we have a super sensitive joystick perfect for fine control. And a near impossible-to-move dual throttle controller that needs to be nailed down (which is why it comes with a heavy steel plate).
     
    All in one neat package. A tale of two joysticks.
     
    Source
  13. 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
  15. Flexman

    Just BeCause 2

    By Flexman,

    No work will be done tomorrow. Just Cause 2 PS3 is released. The acting sucks, the actual game doesn't seem all that hot from the demo either, but the stunt playground aspect is brilliant.
     
    Source
  16. Flexman
    Check off the list, working external canopy doors, flip up/down, will indicate available crew position as well as letting you chat to your mounted team-mate while you're on foot. You could even arm the pilots chopper for him.
     
    Internal doors and wipers next followed by external lighting system. Hopefully we'll have the cold start-up sequence in a few days, we need that so we can get on with more vital systems.
     
    (I just noticed the text on the rail is reversed)
     
    Source
  17. Flexman
    I had a couple of hours with Just Cause 2 which I hesitate to recommend, it a really fun game but you're stuck playing an unlikeable character. Cheesy dialogue abounds and that's no bad thing in games, I scripted plenty of cheese for Longbow Combat Helo. Think about the lines of dialogue from old games you might remember.
     
    The Playstation 3 was needed by the children for Final Fanstasy n so Rico, Scorpio (whatever the slab of MDF you play is called) was parked for the evening.
     
    So back to doing some little things on the project. There's an expectation of standards, a language of gaming to follow. To guide players through the work-flow by implementing cues and guides, can something be too obvious? I think so. I might expect to see the following (see picture below) on an XBOX or PS3 title but not a Combat Sim. Maybe some funky looking icon suggesting "mount".
     



    The advantage of icons over text is that they don't need to be localised. English, French, German, one icon says it all, even if you don't understand apparent meaning the first time, you associate the action with the icon afterwards. So I think we'll go down that route.
     
    So what is the internationally recognised symbol for "Board Helicopter"? Agghh, just stick any old **** in there, people are smart, they'll work it out.
     
    Source
  18. Flexman
    On the whole, I'm starting to warm to using text for user options, the nineties style. Dave showed me some icon screenshots from ArmA and remembered why I didn't like them. Is that a steering wheel? Desk fan?
     
    Below is an in-game shot showing the menu and data displays for helicopters. Not unlike something you might have seen in older games using pre-rendered art. All interactive objects around the base will have these. If you don't want the floaty status text, CTRL L (for labels) is your friend.
     
    Eventually each helo flight will pull it's call-signs from a datafile (Twodogs, Ugly, Badman, Goody etc.) which will go in placed to the current auto-generated ID. Status refers to the ground crews work time to prepare the helo for it's next sortie. Fuelling and weaponeering.
     
    The play process is typically pick-mission, go to aircraft, pick weapons if default not to liking, hit the fly button. It's been the same in games from Wing Commander to Black Shark. Pretty much universal. And we don't want to break that. Reading how UK operations conduct Apache helicopter turnaround, the Apache lands, is guided into an arming bay and re-armed immediately so it's ready for the next flight whenever that may be. No hanging around waiting for a bird to be armed if you're urgently needed in a support action.
     
    To facilitate this into the traditional game flow, brief>arm>fly, the ground crew servicing timer starts after landing and shutdown. But as the player may change weapons seconds before flight and we don't want to delay, we'll let the players arming choice count as the arming done after landing. With a realism option in to have "Real-time arming" for sim pilots who love to thrash themselves with birch-twigs - metaphorically speaking.
     



     
    Source
  19. Flexman

    Player profiles

    By Flexman,

    Writing this up for reference later.
     
    Thinking about players, names, callsigns, current rank, medals, changing characters. The 3D base metaphor avoids a lot of GUI work. Using 3D lockers (since I have one to hand) is perfect. As it turns out, as easy as setting user keys on Locker entities. Simple.
     
    Source
  20. 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
  21. 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
  22. 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
  23. Flexman

    Rockets and Rails

    By Flexman,

    This entry is not about the life of pioneer George Stephenson. The pylons seem capable of configuring themselves, got some elevation in there for aim assist if/when we add that.
     
    I removed the LUA based weapon loading, it wasn't working out the way I hoped it might. There's a level of disconnect between LUA and the game-engine which added to the complexity of something that is already complex, when it didn't need to be.
     
    Can finally get started on the arming now. Got a little sidetracked with testing what I call compound entities which seemed like a good idea but don't actually work outside of the editor due to some engine bug. It would have been a great way to make villages but we've adopted a different approach. Both would give us destructible buildings.
     
    * update * Stores jettison is working too well. The whole things comes off the rail...and drops through the floor. All corrected. Rail and pod weights are effecting the centre of gravity a little too well, that's going to require a bit of tweaking to correct. I need to check my notes on stores weights and extrapolate how heavy these pods and rails are when empty. Then I had to create a custom physical shape to fit flush with the Hellfire rails as the connectors and actuator were causing collision events to trigger. And it turned out that my function to set those collisions was never called, it was removed after the 2.31 engine update. Restoring the function worked a treat. Now I need to add to the SFX required list, store jettison and stores hitting ground.
     
    Overall it's been a frustrating evening but a result at the end. Lots of fixing up to do to complete the arming, might take until the end of the weekend before it's fully functional. End of April is pencilled in as the blowing things up milestone, the campaign map is well under construction and I think we're almost at the point where the campaign data that sits on the map can start going in.
     



    It's bloody hard work, often tedious but the results make it almost worthwhile. Tomorrow however I have to face a reality I've not been looking forward to. And it might scupper everything.
     
    Source
  24. Flexman
    Most of the IHADSS modes are complete except for a couple of elements in hover and bobup, and the flight-path indicator in TRANS mode.
     
    Also added for Dave's benefit a small map which I'll use later as a background underlay for a tactical situation display (TSD) and easy nav mode.
     
    RichP has supplied an authentic start-up sequence complete with appropriate caution and warning signalling that fits our bird nicely. Once we're done with the arming set-up I'll get back on the cockpit sequencing.
     


    There will be an easy start option but you'll like the complexity of starting your own chopper. Modern helicopters with computers are pretty easy to start though.
     
    A new version of the 3D engine is in the works which has a new improved Octree, vegetation culling and I think lets us do a little more with terrain texture blending. Might lets us squeeze out higher detailed areas.
     
    So there's a lot of stuff being worked on at the same time. Not much time for big blog updates or making new videos. I suspect the next video will be the cockpit startup when it's ready followed by a short test flight



    *edit* I also made some improvements over the past day or so to lift calculations, by no means complete but much better handling during turns. Managed a roll and a loop (unloaded helo, only hit the ground once). Blade stress isn't calculated yet. But you can get sucked out of the sky if you descend too quickly.

     
    Source
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...