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
    Making notes on discussions of blade flapping.
     
    Definite gravy but easy to add. Currently blade flexing is done via blended animation controlled by the simulation sending key values to the model. The CH-47 has quite a large blade system (almost doubling the length of the helicopter to 100 feet) and low ground clearance.
     
    Most of the droop comes from the flapping hinge Dave has indicated in white (adjoining the red highlights). These pivots allow the blade to horizontally move upward when the blade is advancing, and down when retreating.
     
    Additionally the blade model hierarchy to allow for visible blade pitching and the Apache blades retro-fitted to do the same.
     

     
    Source
  2. Flexman
    David posted up some more CH47 pics around SimHQ and Facebook and possibly elsewhere. Lot of detail work has gone into the engines, rotor head and trying to get the smoothing correct at the rear of the aircraft.
     
    Looking forward to getting those blades turning, the sound thumping and the dust is flying.
     
    I've been doing a lot of logic work in the Apache in the past day or so. Also full of a head cold which tends to make me cranky.
     
    Sat in the cockpit, the APU sounds like a vacuum cleaner in the next room. Adding moving cockpit parts such as power levers, flashing lamp indicators and other one shot elements that require animation in a periodic update function suggests that maybe it would be better to place all of these things in something more general purpose.
     
    Rather than having a spider-web of update calls, updateCockpit, updateUnitWaypoints, updateEventTrigger etc. popping a function onto a stack when it's needed seems like the thing to do.
     
    I'm proposing to add a simple event system that can take an entity and perform a chain of moves, rotations, material or colour changes, and remove from the stack when the sequence is completed or removed. Then augment this to perform function calls for mission events, to be fired as offsets from mission start time or absolute world time.
     
    Initial thoughts suggest something like the following would cover most needed cases:

    eventID = EntityID, action, blend, userdata (e.g material, colour, vector) as csv eventSequence = ID, eventID[], deltatime_ms, cycle_ms, repeat_count, start-time_ms (absolute world time or zero for mission start time) Where a sequence to cycle a material between two states would need two eventID entries, one for each material and the entity to apply this to. And the eventSequence would contain the reference to both eventIDs. It's then up to the eventProcessor to handle the action. Which could also be SetKey() or SendMessage() but it should be generic enough to handle a lot of common situations.
     
    Event is performed [repeat_count] times, a value of zero implies loop. [cycle_ms] is time between each repeat cycle in milliseconds.
     
    Some checks may be required before injecting an even into the eventSequence. To prevent duplication, for example, hitting reload to trigger a reload animation repeatedly would have the effect of triggering the animation to play before the previous playback has ended. Therefore a parameter to test the uniqueness of the eventSequenceID before pushing it onto the stack should suffice.
     
    **edit: some of this doesn't make sense, seems it got screwed up in posting. Text has been mistaken for tags.**
     
    Source
  4. Flexman
    The CH-47F has had a lot more work done in the cockpit area. The seats are looking remarkably clean, I just need to get a child to play inside with some squeeze boxes and a can of 3in1 oil.
     
    The Chinook is smaller than you might think, with a fuselage approx 50ft long, it's shorter than the Apache which is 58ft long (approx). I was surprised by that.
     
    Networking
     
    Today saw successful Combat-Helo net connection between the Leeds UK and Bangkok in Thailand. Getting the link to work through two routers involved the same port forwarding process as is required for BlackShark. Enabling NAT punch-through requires an external service to act as a matchmaking partner. Since the onus is on the host, we'll assume they know what they are doing anyway.
     
    The address-book had some problems with the XML save/update, now fixed. More changes to the colour scheme. A tidy into bar at the bottom rather like the in Falcon3+ and LockOn displaying connection status, camera, mode, fps etc. General tidy work to polish what's been completed already.
     
     
    Apache HMD
     
    I corrected the Helmet Mounted Display to show the pitch ladder and horizon line as fixed instead of being locked forward (as seen in the YouTube VRCockpit First Look video). Much better for the pilot, now I can comfortably look around and make corrections to the aircraft.
     
    There's more work to do in the cockpit to make front/rear/solo seat modes work. This is my focus for the coming week which will sees that engine start-up procedure working at last.
     
     
    Game Engines / iPhone
     
    We pre-ordered Unity 3.0 last week since it was on offer. We can squeeze the Combat-Helo PC campaign into a stripped down iPhone game. Fans of Combat-Helo can support PC development and have a little fun pretending to be an Apache gunner for 3 minutes at a time.
     
    I still haven't migrated the PC Leadwerks engine to 2.32 yet. So many issues with the cockpit and camera-picking still. Some surface switches in our pit have a tolerance of 0.05 units and were not being recognised. This tolerance is perhaps too small anyway given floating point inaccuracies. These shouldn't be a problem when I move away from rendering the cockpit in the main world (still on my to-do list). Speaking of which here's the current priority list...
     
    To-do
     

    Electrical power system and engine start-up Master Arm and weapon selection Cubic spline interpolation for client character controllers Landing gear dynamics (still makes landing difficult)
     
    Combat-Helo : Operation Ouroboros
     
    Operation Counter Insurgency was noted on shots of a splash screen posted a while back. As remarked by one soldier, "It's not very military". This harks back where we didn't have a clue for a project title, it didn't seem to be a priority. For months it remained "Unnamed Helicopter Project" or UHP. Operation Counter Insurgency (OCI) came out of that as something to fill a splash screen. In keeping with the military tradition of using really obscure names (British operations have some really odd ones), Operation Ouroboros represents the endless cycle of conflict in the region. As an ancient symbol of a dragon or serpent that swallows itself, it's unlikely to be trademarked. Above all, it makes the game sound like a sneeze "CHOO".
     
    Bless you.
     
     
     
    A photo that sums up a fairly typical start to a Combat-Helo escort mission.
     

     
    Source
  5. Flexman

    Windows 7 upgrade

    By Flexman,

    A need to test Combat-Helo on Windows 7 resulted in a TESCO purchase of the Windows 7 Upgrade and 1kg of bananas (a rich source of potassium).
     
    Running any Leadwerks program on a fresh OS install results in an EXCEPTION on launch, only two steps required to get it working. Run the OpenAL install then update video drivers. Simple. Everything worked as it should.
     
    Source
  6. Flexman
    Spending time working on my laptop here, which now has some reliable memory from Kingston has proved to be a fantastic little work platform for developing with Leadwerks.
     
    The FFD or Free flight dynamics physics engine is still a little rough around the edges for putting into Combat-Helo proper so I'm working on a small test platform which hooks into the Leadwerks entity update callback and calls the FFD update.
     
    I'm not sure if this is a good method of doing it, FFD is just a flight model and doesn't handle ground collisions. Originally intended for Microsoft Flight Simulator it releases control when the object is on the ground. Which serves me well, switching over to Newton physics at that point.
     
    I've been going through correcting some type assignments and now the FFD engine seems to be working except for some unexplained force in one direction so I'll have to go through it with Fred and see if we can't find out what's up with that.
     
    Thanks for all the offers and suggestions with regard to my dead motherboard (it truly was gone).
     
    Source
  7. Flexman
    Spac3Rat sent in a nice new game icon as well as two editions of his Rotorwash magazine from 2006 to read. Fascinating look at building helos for FSX, one thing we learned about FSX models, they don't work too well for our kind of real-time work. But fascinating all the same.
     
    Dave is busy in 3DMAX building something that looks very much like a Chinook. I'm making incremental improvements to the GUI system, panels can now be roughly dragged around without risk of "mouse droppings" (the window/item being dropped off the mouse during aggressive mousing). Buttons and input fields are getting focus and their classes respond to events OK. Running two Combat-Helo instances side by side isn't recommended but doable, solves the logistics problem for network testing until I can persuade my wife to maybe set-up a virtual machine with 3D acceleration like she has on her desktop.
     
    The gui system is linked list of active TGUIPanels (base type) which maintain their own linked list of user controls (TGUIItem), each control having a simple drawing function. They keep track of what's got focus, what's been clicked on and dragged around. It's only going to be used for a few things but it makes it easier to add checklists if needed. And they just make use of a couple of base textures and existing game fonts (of which there are about 5).
     
    The IHADSS or HMD has a problem that has been bugging for some time since the early flight tests and a recent personal message confirmed it. Look over your shoulder and how the hell can you tell which way up you are when the artificial horizon vanishes? So we're going to fix that to work as it should as soon as we can. It's also supposed to be quite low resolution but that would look really ugly when it's constantly in your face, I can't bring myself to reduce it to VGA res.
     
    Dave has learned that Chinooks are round, very round. I learned how to pronounce it correctly (Shin-uk) thanks to my Canadian wife who repeatedly laughed at my attempts.
     
    Finally, Red Dead Redpemtion has been a fantastic game, the open-world and amoral nature of Grand Theft Auto games applied to the old West (USA, 1903 era) fits perfectly. And you get to play a protagonist you can like. Amazing inverse kinematic system meaning character movement seems quite natural compared to traditional baked animations. A world that is just fun to roam around in, a magnificent achievement. I spent an hour in a saloon just playing Blackjack. Which reminds me, I'm out of Whiskey.
     
    Source
  8. Flexman
    I wasn't going to add a complete gui system, we don't need anything complex. The address book needs to accept input from mouse and keyboard and when I thought about it, the planned map viewer/editor will require it too.
     
    It had to be a simple gui system with input focus and keyboard entry. Since the chat console had functions for filtering keys and the input mapper directed keyboard input into it when active it was simple enough to change it to send to a gui class and whatever control input had focus.
     
    GUI drawing and input handling is as far as I got this evening. Should be functional by late evening tomorrow. Address book will store entries as XML, not sure if passwords should be stored or not. My professional hat says no, my lazy hat says yes. It's non-critical so it seems reasonable to store the last used password no?
     
    Source
  9. Flexman

    Monday update

    By Flexman,

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

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

     
    Source
  10. Flexman
    We finally sourced a a reasonably good infantry soldier, low poly model, rigged, animated and exported. We can fill the screen with dozens of these guys, falling, shooting prone, grenade tossing. We'll give them a couple of weapons they can swap between and a range of helmets swapped in by setting an entity key.
     

     
    To initially test animation sequences I populated a drop-down control for the editor dialog with the following LUA, chopped up for readability. But lets you pick which frames to loop by name (or number). This is quite compact for AI troops which need to be lightweight in processing terms, this means non-use of character controllers.
     
     
     
    class.anim = {
    {"Idle",0,49},
    {"Stand and Fire",50,89},
    {"Running",90,111},
    {"Walking",112,147},
    {"Grenade Throw",148,187},
    {"Take Cover",188,213},
    {"Stand to Squat",214,241},
    {"Fire from Squat",242,291},
    {"Squat to Stand",292,313},
    {"Go Prone",314,359},
    {"Fire from Prone",360,379},
    {"Stand Up",380,425},
    {"Death Forwards",426,532},
    {"Death Backwards",533,568},
    {"Jump",569,614}
    }
     
     
    function class:InitDialog(grid)
    local choices = ""
    local total = table.getn(class.anim)
     
     
    for i=1,total do
    choices = choices .. class.anim[1]
    if (i < total) then
    choices = choices ..","
    end
    end
     
     
    self.super:InitDialog(grid)
    group=grid:AddGroup("Animation")
    group:AddProperty("sequence",PROPERTY_CHOICE, choices , "Animation")
    group:Expand(1)
    end
     
     
     
    function object:SetKey(key,value)
    if key=="sequence" then
    object.framestart = class.anim[value+1][2]
    object.frameend = class.anim[value+1][3]
    end
    return self.super:SetKey(key,value)
    end
     
     

     
     
     
     

     
    Source
  11. Flexman

    Comms console

    By Flexman,

    Today I added the ubiquitous chat console complete with 4 colour coded channel presets, Global, Side, Group, Vehicle. Complete with command parsing (/setkey lets you send keys to any object you're standing before which is handy). The console also has a command history using the UP/DOWN cursor keys.
    Chat entry toggled by hitting the ENTER key ala Warcraft. Be aware that the primary action key has moved from the ENTER key to the "P" key (P for primary and also handily close to the square brackets used for menu navigation.
    Clipboard paste is supported via..
    Extern "Win32"{ Function OpenClipboard(hwnd%) Function CloseClipboard() Function GetClipboardData:Byte Ptr(Format:Int)}if(OpenClipboard(0)) String.FromCString(GetClipboardData(1));
     
    Console text entry mode also disables all input mapper KEY_DEVICE inputs to avoid conflict. It was important to Flush the keybuffer on exit otherwise all those spaces translated into SUPER JUMPS after entering text. Besides, you should always flush before you leave.
    Network comms chat is working fine except an occasional (Not Responding) display "freeze" only when the server was active. I thought was a problem with my Raknet interface but logs show packets still being processed by the game. The problem seems related to not wearing the TrackIR pro-clip device when the network is active. As soon as I put on the head tracker device the display responded normally as if nothing had happened, even chat catches up. Most odd as I've not experienced this with TrackIR before.
    Commands for server control are working including IP ban/unban. I do need to harden the user interface for network connections, the menus need to change to show the connection is already active and offer a disconnect. And the client needs a suitable connect-time period before giving up and allowing a re-try. We will begin NAT testing when I've got that sorted.

     
    Last night I made a DLL into which I was able to pass a structure containing flight data. It did nothing beyond reading it back but will be handy for exporting game data to third party programs.
     
    My TrackClip Pro has fallen apart. Only glue is holding it together.
     
    Source
  13. Flexman
    All actions relating to the AH64D go though a message receiver. Player mount, dismount, ground crew arming, lights, AI commanding and (getting to the point) virtual cockpit interactions.
     
    The MPD button naming convention of "MPD_1_17" refering to MPD 1 (pilot left) and key 17 (counting from top left) that gets sent to the input handler for that MPD.
     
    Key messages can originate from the client or network. I had to add a source ID to account for situations where one person in the same vehicle has authority over some function.
     
    The keys and knobs are all working well, interacting with the avionics. I've removed some of the more obscure items and checking authenticity of some elements. Had to simplify a few things just because it's not intuitive. CTRL-G (default mapping) will switch to guns. ALT-G cycles gun round burst mode between 10, 20, 50, 100 and full. Burst is the number of chain gun rounds fired with each trigger pull.
     
    MODE is the method of gun tracking. It cycles between
     

    HMD (helmet mounted display, this is TrackIR or mouselook, where you are looking) FXD is fixed forward TADS is the current TADS position.
    This is a fairly important mode distinction, particually in co-op play as the pilot controls gun/rockets and the the co-pilot/gunner operates TADS and other weapons such as the AGMs (air to ground missiles).
     
    This I think neatly simplifies operation and easy to understand. For most situations you will want to leave it in TADS mode so you can quickly deploy cannon or AGMs against ground targets.
     
    MAN RNG adjusts the ballistics trajectory. Cycles between fixed ranges given in meters. It's there for completeness without adding complexity. It's a candidate for removal.
     
    AGM sub mode coming next unless something really cool happens
     
    Source
  14. 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
  15. Flexman
    Spent the day working on the Helicopter entity and the sub-classes that handle all the pylons and stores. It's worth spending time automating these things as much as possible now to simply things later.
     
    I broke out UMLet, a nice fast Java based UML editor to look at my structure. What's missing is the store-jett which needs to be a function of [TStore], pass it the pylon number and it will be required to generate the physics object, parent the rail/pod/fuel cell, detach it from the pylon and let Newton take over, thus letting the pod/rail complete with ordnance fall to earth.
     
    And by moving the [selectedZone] property to the [Pylon] from the [Avionics] class, it allows for the ground-crew loading system to simply add rockets and let the [Pylon] advance the zone so all 3 zones are populated in three clicks. That way it's not dependent on a playing crewing the Helicopter (as [Avionics] are only instantiated when you board a vehicle and destroyed on exit).
     
    This is all part of the process of adding the WEP MFD page which needs access to stores data and it gets it from the [stores] class, which can be thought of as a black box into which each pylon (4 of them) send signals about what is loaded where. And how to re-load of course.
     
    I'm torn about creating the whole WEP page graphic as a vector, I'd rather do that as textures scaled up can look a bit blurry. Cockpit builders might want a stand alone OpenGL client that doesn't require the 3D engine for displays so going native OpenGL makes adding it a cut and paste job.
     
    Source
  17. Flexman

    XML Database lookups

    By Flexman,

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


    All weapons come with suitable entries by entering the ground crew mode from proximity to any Apache helicopter. We can re-use this for tutorial pop-ups, optionally adding a tag to the XML entry that points to an audio file thus triggering playback. If that makes any sense.
     
    I mention it here as it just occurred to me and don't want to forget it.
     
    Source
  18. Flexman
    It's been a blissfully quiet weekend.
     
    The Combat-Helo configuration files are now in an easier to use XML format and I added a lot of extra options too. Player profile name, host IP, graphics filters etc. Fullscreen and Windowed modes having their own settings.
     
    Also experimented with light scattering, we'll be adding per time-of-day lighting and retiring the old LB2 style skybox. That's not a priority item just something that's nice to toy as a little break.
     
    Arming system which should have been completed already (lots of interruptions this week) has had some GUI elements added to it to improve feedback, just have to write the descriptions for all the ammo. The Apache is receiving the arming messages fine but not visibly showing the loaded rounds. On the whole, not too happy with all the GUI as it is. I made something that was easy to fit to multiple resolutions but it could use a little polish.
     



    I ran another test with the Autopatcher and it's still a bust. The file it's wanting is created server-side but the client patcher can't reach it. So another email exchange with tech-support tomorrow.
     
    Source
  20. Flexman
    hehe well the XPatcher2 software worked great for the upload, but the client program doesn't seem to want to work at all, requesting a file that wasn't supplied or exists.
     
    Might have to look at other some other software.
     
    Converting all config files to use XML format, this will make editing control inputs a bit easier later. They are rather messy atm and adding new options should be a lot easier.
     
    Source
  21. 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
  22. 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
  23. Flexman
    I've just moved on to doing research into co-ordinates and floating point accuracy.
    Going to make a few test projects to try different ideas. Dave has been posting updates on the greenzone development.
     
    Welcome to Afghanistan
     
    Source
  24. Flexman

    Arming almost done

    By Flexman,

    Not convinced this a a great way of arming the Apache. But what we will do I think is provide some quick defaults, option A and option B.
     
    Only the client sees the weapons appear on the ground ready for selection. The crewman loading the weapons clicks the weapon which is then sent to the highlighted pylon. Internally the helicopter entity receives a message to load pylon x with missile y.
     
    To do: Tooltips for the pods to say what they are and I think highlighting the selected pylon might be a good idea.
     


    I can optimise memory usage a little by pre-loading the Apache stores and instancing then missiles which I meant to do earlier. Pre-caching some of these objects will reduce that awful machine lag that occurs when it needs to show a model for the first time.





    TrippleHead2Go vision


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


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


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


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



    DOF blending the horizon.


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