Additional screens

I updated my work-map today with a more recent one and still in the process of fixing up missing objects. I think I have half of a city missing. The cockpit is now in it's own world space resting at the origin and no longer effected by floating point error, but I did leave in some rotation 'noise' to give the cockpit a vibration effect.

I pushed the tree LOD out a bit more which you might see in the following screens. If you have an uber PC you'll be able to render some really sweet scenes. The ETADS has a temporary green tint because I've not yet added the desaturation filter, it's on the to-do list.

Some of the systems such as the helmet mounted display are not operational as it thinks the power is off. I only just found the ground radar mode from September. It's amazing some of the things you forget you added.

One day soon there's going to be ZSUs in those tree-lines.

I'm missing a chunk of city here. There should be rows of stores and back alleyways around the urban compounds. I have the models installed so I don't know what's going on yet, I suspect they are missing from the SBX.

Gets awful lonely out in the plains. Stopped for a photo-op.

With the cockpit rendering modification almost complete it's back to core systems.

Compounding a problem (child object counts)

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.

Out-takes, when cockpits go bad

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).

Bored in Camp Bastion? Crazy Brits

I just thought this was crazy funny. Chinook crew showing off what they do best :)

Command Tent - wip

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.

Drivers again

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.


*edit*

As an aside, started fleshing out the steerable ETADS. I'm going to put in a visual "beam" for debugging. Also it needs to be horizontally stabilised so when the aircraft rolls the image doesn't. And it needs a ground track mode, together with the field of regard which I'll borrow from the HMS functions.

Smile, you're on ETADS.

World of Warcraft - Blizzard has internal leakage

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.

Baked AO, ambient occlusion

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.

Mipmaps caution light. Check your drivers, sir!

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?

TrackIR Pro-Clip, shreded

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.

Wipers and material updates

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.

More Apache work

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.

Adding audio for AI helos part 2

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(...)
 class.soundcompressor = LoadSound("abstract::ch47_compressor_loop.ogg")
 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
  object.source_compressor  = object.model:EmitSound(class.soundcompressor,75,1,1)
  SetSourceVolume(object.source_compressor,0.5);
 end
 if class.soundrotors~=nil then
  object.source_rotors  = object.model:EmitSound(class.soundrotors,250,1,1)
  SetSourceVolume(object.source_rotors,1.0);
 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[i]~=nil then
    RotateEntity(object.bladehinge[i][0], Vec3(flapangle,0,0))
    RotateEntity(object.bladehinge[i][1], Vec3(flapangle,-offset,0))
    RotateEntity(object.bladehinge[i][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.

Adding audio for AI helos

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.

Blade flapping and hinging

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.

Engine start-up and event system

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.**

Rotor heads will like this...rotor head

More detailing on the rotor head, details on the flap, pitch link and coning hinges.

Assembled audio for the CH-47 today in addition to implementing the Apache cold-start procedure.

CH-47F and updates from the last few days

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.

Bug fixes for today...

• 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.

Windows 7 upgrade

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.

SimHQ CH47 Chinook progress pics

Dave has put up some more preivew pics of the CH47 at SimHQ and on our Facebook page.
SimHQ CH47 Chinook progress pics

CombatHelo on Facebook

World clocks now in sync

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.

** update **

More testing with the network raised some points. My wife likes to chat a lot, console input buffer isn't long enough to accommodate all in one entry. The flashing Cursor sucks isn't very good.

Clock sync every 2 seconds works just as good with forced update on time-advance.

Issues with keeping track of current client/host connection were resolved. Status bar now shows connection status and number of connected clients as (H:n) as a suffix.

Using GUIDs instead of IPs to map clients.

Sent first goldspam message in Combat-Helo, which doesn't even use gold.