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
    Compounds, the Herat map contains approx 500 of them. Each one consisted of a number of walls and out buildings. Turns out, these sub objects chewed through a bit of processing time. In effect there were 7500 objects getting worked through. That's a lot and it was reflected in the performance in LE 2.31 on a fully dressed map.
     
    By collapsing the compound models into a single object for the lower LODs we saw a large increase in fps in LE 2.31. Although LE 2.32 shows not much difference (it's a better performer anyway) due to it's quad-tree culling system. Even so there lots of fine tuning to do, cockpit switches to be instanced, general code trimming. Entity view ranges, material combining and a dynamic detail function to add.
     
    Today I've been working on fixing the lighting buffer for the cockpit entity but I'm having problems copying the cockpit buffer into the main view buffer. Much strangeness, it's some alpha/blending issue I can't quite get a handle on but I'll get there.
     
    I spent some time looking at Open-flight as a specification for storing lots of scene data. It's not really designed for high efficiency 3D engines. And not surprising that other engines that use it have adopted some conversion process. Initially the idea was sound but on closer inspection it's just plain awful. Maybe I'm missing something in the organisation and construction of individual objects.
     
     
    Here are some random shots from today.
     
    Cockpit interior now moved to it's own world for rendering lighting. Materials are not happy but it's steady as a rock. You can see the GPU terrain mesh with it's 10 meter resolution rendering a DEM of mountains in the NW of Afghanistan.

     
    Not much to say about this. Pre optimisation and post debug slowdown. Not happy at all. It was just this slow on my dev machine. My laptop is much happier.

     
    The saturation and contrast levels adjusted on the "fly" can change the look of the game.
     

    I like heavily saturated games which is probably due to my first colour computer, a Sinclair ZX Spectrum which was a train-crash of colours, all eight of them. I still have one of the later models hanging around my desk (see photo I just took below). This one has an Interface 1 for Microdrives. If you don't know what they were, have a bit of fun and look them up. Strange to think that that kind of technology is still used as a backup system today. In the 80's my first games didn't get very good reviews, we had a laugh looking them up on the internet last week. They would make good mobile games today I think....hey I just found my keys.
     

     
    Source
  2. Flexman
    My Dennis Norden bit. Out-takes from today. Most programmers we have a few wilco tango foxtrot moments from time to time. Here's a few from today. Starting with "How not to render lights to a buffer."
     

    The canopy glass makes for an interesting effect. Next, an interesting effect you REALLY don't want to see....ARRRRGHHHH....
     

    This is me getting a transform wrong. You can almost see the join between the high detail cockpit and the Apache exterior model. Mind the gap? I did fix this by correcting the TForm and resetting the camera back to the origin. Still have the lighting to correct but it's almost ready. The cockpit is rendered after the world, the zbuffer cleared and the pit is drawn at the world origin so zbuffer and floating point error is nil. All games have hacks to make them work, didn't you know?
     
    Speaking of hacks I highly recommend "Game Coding Complete" by Mike McShaffry. Full of funny developer anecdotes and a brief history of Ultima which is fascinating. As well as many best-practice approaches to game programming.
     
     
    Moving on, Dave was back to polishing the textures and models. More AO baking, backfaces, specular tweaks. Here's a selection of views from today. (Leaving out the rude England footy twitter jokes, some of which were priceless).
     
     

     



     
    Source
  4. Flexman

    Command Tent - wip

    By Flexman,

    We're not trying to re-create Armed Assault, or even build some form of Helicopter MMO. Our plan is to take the old school 2D interfaces of military bases and create 3D analogues. Mission assignment and planning is done in the command tent. This is still exploritory, we have a number of office furniture elements planned, some of which we have tried in the editor to get a feel.
     
    There's more furniture to come. A mil-spec laptop/terminal, interactive map on a board (that's a copy of your personal map - will use the same buffer).
     
    And eventually we hope to have various AI pilots sitting in on briefings that you might want to converse with Wing Commander style. Romeo 1 from the intro mission will be hanging around. Along with WO J Petersan and others from time to time.
     
    I don't have much time to decorate, just placing these objects around my test-map to check how they look and function but it should give you an idea.
     
    With a couple of AI guys and a co-op friend there should be enough room to keep it looking busy. It's possible we might make AI crewman choices ala Gunship 2000 available in this manner if it works.
     
    We need some flooring I think. Hexmesh or some other plastic matting.
     
    Using a projected texture for mission briefings on the OHP. Interacting with a screen set 5 meters away is problematic, once at the projector you'll get to interface which will allow you to view available missions and annotated map, with a "close up" option (position a 3rd person cam up close to the screen).
     
    Like with other parts of the game, such as arming, the player interfacing with the projector will have their data shown to everyone else. Allowing you to give briefings. If there's time we might add a laser pointer for mouse control.
     
    We're using a 1024x1024 buffer for the projector which is a material assigned to a special spot_light entity parented to the OHP model. Objects/avatars walking in front of the projector have the image mapped over them in a realistic manner. So you too can act like a right tit in front of the C/O making shadow puppets with your head.
     
     
    Additional objects in the command tent will operate on a private level, mission planning and editing will work on a laptop type screen and a wall map will be copy of your pop-up map. There may also be a Sierra Hotel score board, I think that's required by tradition.
     
    So this the the start of the important ground office in Combat-Helo. We tend to have about three different project elements on the go at any one time, rather like making a series like Star Trek, planning, filming and pre-production.
     
     
    Finally a recent ETADS screen-shot, taking a peek at a sign through the trees some distance away (it's way off to the left out of sight so don't bother trying to spot it). Some folks will be well pleased with the corners. This coming week I'll be working on the event system (delayed due to PC technical problems, see earlier blog posts) and more of the TADS elements.
     

     
    Source
  5. Flexman

    Drivers again

    By Flexman,

    Seem to be having performance issues with the new nVidia drivers 257.21
     
    I noticed the reported OpenGL version has done up from 3.2.0 to 3.3.0
    Repeated launching over an hour will sap the frame rate to around 1, yes one. No apparent memory leakage. But other games are fine. Also the editor will remain unaffected unless importing the Apache model where it will sometimes exhibit a black skin.
     
    So there's some combination of factors I need to understand, the current Apache model with it's recent material updates and animated wipers and the new nVidia drivers.
     
    I wouldn't mind so much except it's keeping me of adding new content right now.
     
    I also spawned an LE 2.32 build to test, which on a small map runs 50% faster, on the full sized Afghan theater it actually runs slower. I'm at the point where I'd like to take a shotgun to my PC. The laptop has almost double the performance of my desktop PC which makes no sense, same build, engine and 257.21 drivers.
     
    *sigh*
     
    Source
  6. Flexman
    Just wanted to report this to the blogosphere. I'm not a Wow player (I have an account but I don't play very often) but my wife friends across several raiding guilds play from time to time.
     
     
    They've all been subjected to hacks. And I think the leak is at Blizzard.
     
     
    Over the past few weeks, everbody we know, including friends of friends have had their accounts hacked. Including mine, which was inactive, but had an "authenticator" (a hardware device that generates a new 6 digit number every minute). I presume when my account (that was inactive as it wasn't used) was hacked, they didn't take anything as I guess they didn't want to pay money to reactivate it. But they did attach one of these authenticators to it. And I'm not the only one.
     
     
    Once again, this morning a friend had his entire account hacked and cleaned out the family guild bank. In the years I've know people who play there's been a slow increase of attempts and successful account hijackings, but just in the last few months that rate is off the scale. I've never know so many, so fast. And there's no commonality in the people I questioned, everyone I've talked to knows someone who has been effected recently.
     
     
    On this scale I can only conclude that Activision Blizzard has someone working in the organisation leaking account details or a client list has been compromised in some way.
     
     
    You only have to check out YouTube about GM hacks to see how bad things are.
     
    So I'd recommend deactivating your wow accounts or use an authenticator until they decide to do something about this.
     
     
     

     
    Source
  7. Flexman
    Today we looked at a neat little program called SMAK which is a neat little program for generating normal maps for low poly models by using high poly models. It also can bake ambient occlusion shadows onto your diffuse textures.
     
    This is also a feature of 3DMAX so Dave tried a little experiment.
     
    Before, no baked AO
     
    After, with baked AO
    You might want to click on those images to see the full sized renders. Certainly the cockpit area could benefit, and the buildings we have with ground proximity shading for compounds and city blocks. Best of all, no fps impact. There's still work to do to improve normal maps.
     
    We started an audit of game textures and will extend this to include QA for each texture layer, ensuring it's as good as we can make it and optimise memory usage into the bargain.
     
    There are subtle things, such as the DXT5 compression that results in acne. Using a different DDS format and reducing the resolution can result in a better image and smaller memory footprint. See pic below.
     

     
    We made some material changes to the cockpit, specular, glow maps. I'm not sure the grips should be backlit but it makes them easier to read in the dark.
     

     
    Source
  8. Flexman
    Periodically I'll create a debug build to see if any OpenGL errors popup and sure enough one did. Tthe MFD buffer mip-maps are created after rendering the contents with a call to buffer.GetColorBuffer().GenMipMaps()
     
    Not much had changed except some additional meshes, animations, all the specular maps, actually quite a lot of material changes to the interior and exterior this past week. But the debug ran fine after building and running it on the laptop. My desktop wasn't having any of it.
     
    EF2000, EECH Enemy Engaged Comanche Hokum and others, not working right? Please update your drivers. So what did I fail to do on my desktop that I did recently on the laptop (due to installing a Windows 7 upgrade). Yup, update my drivers. And lo, all is now well and good.
     
    The moral is, always heed ones own advice. Check your drivers.
     
    Still a little curious as to what was wrong with mipmaps in those drivers. I wonder how well auto-generation of mipmaps are supported across cards and is there a safer way to test it?
     
    Source
  9. 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
  10. Flexman
    Another "gravy" feature which I wouldn't have spent time on had David (part man, part 3DSMax) hadn't made it so easy. He detached the existing low res wipers from the exterior model and created a single 100 frame animation cycle of both wipers complete with slight wobble. The two blades operate at different speed ratios too.
     

    The cockpit wiper control was set to send it's setting as a key to both the exterior and interior cockpit model. Allowing for dual speed wiper control and a park mode (turn off and wipers return to stop position at end of the next cycle).
     

    The ETADS display had it's round inner bevel reduced and is much more square, you can make that out as the bright green screen in the above image. Also the cockpit instrument normal maps were edited to remove raised lettering and other markings that were out of place.
     
    My project planner has me working on the generic event system (GEST) for the next four days. This is a new dependency for completing the start-up procedure and mob animation.
     
    Source
  11. 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
  12. Flexman
    We're going to edit the LUA script for the CH47. Helicopters are somewhat complex and incredibly noisy machines, you thought your XBOX 360 was loud?
     
    Yesterday we trawled through some online video, ripped the soundtracks and used Audacity to get some loops of the compressor, and rotor beat. That's two discrete sounds that when mixed together should give a good representation of helo noise. Using Audacity it's possible to mark a region, and use that as a 'sample' to remove that noise from another. So we took some of the compressor/engine noise and removed (or reduced) this by around 16db from the rotor noise.
     
    Next task is to add these two looped audio sample sources to the CH47 model script. As we want all instances of the CH47 to use there we'll add them at class level....
     
    local class=CreateClass(...)<br style="font-family: Verdana,sans-serif;" /> class.soundcompressor = LoadSound("abstract::ch47_compressor_loop.ogg")<br style="font-family: Verdana,sans-serif;" /> class.soundrotors = LoadSound("abstract::ch47_rotor_loop.ogg")
     
    The compressor noise can get on your nerves. We want to emphasise the rotor beat so we have set a volume ration of 1:2 between them. Setting the volume of the rotor loop to 1.0 and compressor to 0.5
     
    function class:CreateObject(model) if class.soundcompressor~=nil then <br style="font-family: Verdana,sans-serif;" /> object.source_compressor = object.model:EmitSound(class.soundcompressor,75,1,1)<br style="font-family: Verdana,sans-serif;" /> SetSourceVolume(object.source_compressor,0.5);<br style="font-family: Verdana,sans-serif;" /> end<br style="font-family: Verdana,sans-serif;" /> if class.soundrotors~=nil then<br style="font-family: Verdana,sans-serif;" /> object.source_rotors = object.model:EmitSound(class.soundrotors,250,1,1)<br style="font-family: Verdana,sans-serif;" /> SetSourceVolume(object.source_rotors,1.0);<br style="font-family: Verdana,sans-serif;" /> end
     
    Note, LoadSound() returns a source which we need to store for later when we change volume and pitch. When the Rotor Speed is increased either by the AI pilot or engine/entity update, the blade flap function is called to update the relative positions of each blade. And here is a good place to update the audio for the blade thumping. It seems better to place it here than in the update/render which is called every frame. Here it only is updated on changes to the rotor state.
     
    function object:BladeFlap()
    local flapangle = 7 - (object.rotorspeed*0.6) + (object.bladeangle * 0.08)
    local offset = 120
    for i=0,1 do
    if object.bladehinge~=nil then
    RotateEntity(object.bladehinge[0], Vec3(flapangle,0,0))
    RotateEntity(object.bladehinge[1], Vec3(flapangle,-offset,0))
    RotateEntity(object.bladehinge[2], Vec3(flapangle,offset,0))
    offset = -offset
    end
    end
     
    -- CHANGE AUDIO PITCH
    SetSourcePitch(object.source_rotors,object.rotorspeed * 0.045)
    end
     
    We added additional code to turn on/off audio for static and parked helicopters. We can improve on this by introducing a "start-up" and "shutdown" state that will wind-up/down the compressor noise whenever the aircraft is flagged as "live" or "dormant".
     
     
     
    Such a simple method that greatly adds a sense of weight and presence to an object. Here's a video of the result.
     

     
    Source
  13. Flexman
    Sound is an impressive tool. And something I worried a great deal about from the start. Just adding various audio sources to the Apache, from the Betty, to various computers tones, compressor noise, all adds to a sense of cockpit space.
     
    The Chinook needs similar attention, as a non-hero aircraft (currently a non-flyable). The game engine uses OpenAL, which employs a system of 3D positional audio. In the Apache most of the noise is behind your head, looking left and right appears to pan the audio. Externally the engine and compressor sound sources are attached to a helicopters engine positions.
     
    The difference between the hero-ships such as the Apache and AI units is the way audio is initialised. Apache audio is split between interior and exterior sounds; interior sounds are built during the player boarding process which initialises the cockpit and switch status, the exterior audio is created as soon as it enters the 3D world.
     
    Our CH-47 Chinook like the Apache, will have engine sound sources attached upon the object creation process, and the LUA update function, called every frame will swap in and adjust the volume and pitch of various audio files.
     
    Getting really good audio requires at a number of digital recorders positioned around the aircraft. As we don't have local access to a Chinook and a bank of digital recording equipment, the modern internet age comes to the rescue with numerous video web sites rich with source material of variable quality.
     
    After auditioning a few choice videos, using a Firefox web-browser plugin that downloads the video files from these sites, the process of ripping the audio for processing can begin.
     
    VLC Media Player is a free video player with a number of conversion features. And allows you to batch export audio from a video files using the Convert option.
     
    Selecting the video we want to convert and the destination file then choosing the export format. We want audio only and in OGG format.
     
     
     
     
    I have the Audacity
     
    Don't leave home without it. Audacity is in my price range (free) and works well with OGG format audio files.
     
    It's reasonably easy to find and build audio loops but before you can do that you need to turn it onto a mono audio file. OpenAL's 3D positional audio requires a mono-sound source, it will split the sound to different channels depending on the source and listener position. So having flattened the audio file, the work of finding and snipping loops can begin.
     
    In the next blog update I'll detail the processing of adding and loading the sound files in the model's LUA script.
     
    Source
  14. 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
  15. 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
  17. 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
  18. 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
  19. 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
  21. Flexman
    The game world clock is now synced across network clients, time advance and day-night cycles locked. Accuracy is down to round-trip packet times plus a few milliseconds. More than enough to keep entity spawn times and waypoint navigation in close sync.
     
    I'm as yet unsure how often to send clock updates, currently it's every half-second which is quite aggressive, it's easy enough to tweak. Clocks run on client and frame-rate independent so they don't need to be updated often. They just need the occasional time sync from the host or when the host is changing the time-of-day.
     
    Chat channels work well, need to add the player name to the prefix. We have a player profile set in the game config but this carries no player name or any other data as yet.
     
    Almost ready to test that NAT punch-through.
     
    Source
  22. Flexman
    Dave's been busy building the unsung hero of Afghanistan and other operations around the world.
     
    Rolf: Can you tell what it is yet? ;-)
     
    It's a non-flyable but will feature prominently in the game as you'll be tasked to provide armed escort for supply, insertion and extraction missions.
     
    Much time has been spent correcting smoothing errors. Brilliant work. We'll be adding the same functionality to the rotors and rear door using LUA scripts. This morning we were looking at the various flavours of cockpit, of which there are many. Never the same cockpit twice. I thought the Apache tandem cockpit was complex. The amount of work required to make this a flyable is out of the question right now. It's a level of complexity rivalling the Apache and a candidate for future expansion.
     
    Source
  23. 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
  24. 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
  25. 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
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...