Monthly Archives: July 2014

Of VGA Adapters and Sods Law

So, my shiny new MacBook Pro has an advantage over my old one insofar as it’s got an HDMI input. This means when I’m using it connected to modern and civilised projectors I can just use an HDMI cable and be done with it. Still, it’s not guaranteed that people have projectors with HDMI inputs so I normally pack my Mini Display Port to VGA Adapter just to be on the safe side. I also normally head to talks direct from the office so I keep it in a drawer there to be packed when I head out.

Tomorrow I’m doing a talk at Cromer Academy. Since it’s free of direct government control I’m going to give it a 50/50 chance of a brand new, state of the art projector with every port known to man, and an old projector that accepts VGA as an advanced input. These odds will, of course, be affected by certain factors; like me forgetting my VGA adaptor. I remembered at 9:50 this morning on a day where my wife is at work, I don’t have access to the car, and I have my daughter to look after. We were heading to the Zoo for the morning.

What resulted was categorically not me cutting short zoo time and making a Herculean dash for the office on rural public transport on a Sunday. No, that would result in tantrums. Instead we went on a fairyland adventure with trains, river walks and a castle (hurrah for Norwich’s historic architecture) resplendent with a hastily bought picnic on the train. Spin at its absolute finest.

I am now armed with my VGA connector, the child has fallen asleep from all the excitement and I’m in desperate need of a shower having charged round Norwich with a pushchair in a heat wave. I expect fate will repay me with some fancy 8K 3D projector that wirelessly displays images without the need for any adapters.

Elite Dangerous and CH Products HOTAS

Not the most inspiring of titles, but then it’s deliberately anti-linkbait 🙂 If you are not playing Elite Dangerous you may want to go find something more interesting to read… no, seriously 😛 For everyone else, this is very CH Product centric, but may provide some ideas for other HOTAS setups.

Step 1: The Joystick Map

Download the Joystick map and CMS file and put them in your documents folder under a directory called CH Control Manager (you many need to create this if you haven’t used the CH Control Manager before).

Plugin your Fighterstick and Throttle, then launch the CH Control Manager and load the The click the Download button to enable the map. This basically combines the stick and throttle into a single DirectX control. Due to limitations on the number of buttons available some buttons are mapped to key presses.

Few notes about the map:

  • I don’t use joystick modes, so it doesn’t matter what colour LED is lit on either the throttle or stick
  • The throttle control on the stick is mapped to a CMS scrip that disables the HOTAS Throttle when it’s fully back, and enables it when it’s fully forward. If your HOTAS throttle axis doesn’t seem to work then move the throttle wheel on the joystick to the other extreme.
  • I use the pinky button on the stick as shift and the map makes heavy use of shift.

You can use the Keycheck and Test/Calibrate options from the CH Control Manager to test the button and axis mappings.

Step 2: Mapping the game controls

Next up you want to copy the custom bindings for the above map into your Elite Dangerous data folder under C:\Users\USER\AppData\Local\Frontier Developments\Elite Dangerous\Options\Bindings\Custom.binds. Change USER to be your username. AppData is a hidden directory so you’ll need to enable Show Hidden Files.

I should point out that I’ve not actually tried this, I’m just assuming it’ll work. Worse case scenario you’ll need to go in game and just map the actions from the layout guide to the in game controls.

Step 3: Learn the map

Ah, the fun bit. Basically you can run the joysticks in a number of different modes depending on the situation at hand. So that you’ve still got access to all the controls you’re going to need some controls are duplicated elsewhere, albeit using the shift button to get to them. I’ve provided a layout guide for the map which shows which button maps to what action. It’s split over 3 pages depending on the mode you’re in.

Normal Operation

Page 1 of the joystick layout shows the default buttons configuration for the sticks with the ships gear up and without the shift pinky button pressed. They joystick is mapped to Pitch and Roll with the Throttle Wheel being used to engage (fully forward) and disengage (fully back) the main HOTAS Throttle Axis. Pressing button 3 on the throttle (middle of the three buttons on the throttle handle) toggles the joystick Y axis between roll and yaw.

The HOTAS Throttle Axis is mapped across the full range, so fully back gives you full reverse throttle, fully forward give you full forward throttle. The exception is when in Supercruise where this is no reverse so fully back on the throttle is minimum Supercruise speed and fully forward is maximum Supercruise. Under normal flight modes zero throttle is somewhere roughly in the middle of the axis range. If you need to stop set the Joystick Throttle to fully back to disengage the HOTAS Throttle Axis and set it to 0.

The Thumb Stick on the joystick is uses for Lateral and Vertical Thrust. The dead-zone is quite large on these as I find the stick doesn’t tend to centre as well as it could. If you find yourself thrusting vertically or laterally with no input check the stick is centred and possibly increase the dead zone.

The Joystick Hat Switch is usually used to provide digital inputs for Pitch and Yaw, making small adjustments in Supercruise and while docking easy. Pressing the shift (pinky button) on the joystick and button 2 on the throttle at the same time (shift-b2) toggles head look. The Joystick Hat Switch is used to look around the cockpit when head look is enabled. Press shift-b2 again to disengage head look and return the Joystick Hat Switch to Pitch and Yaw.

firing and Targeting is performed on the joystick with the Trigger performing primary fire and button 3 (the side button) used for secondary fire. button 2 toggles hard points, although they will automatically deploy if not already deployed when trying to fire.

A digital roll control is mapped to side 4-way Switch on the joystick, as is Engine Boost and Reverse Throttle.

Navigating the ships systems is done using the two 4-way Switches and the Hat Switch on the side of the throttle. The top 4-way Switch is used to bring up the Target Panel (left), Systems Panel (right) and Radar Panel (down). Pressing up returns you to the normal forward view. The direction you move the 4-way Switch matches where the panels are in relation to the cockpit. The Throttle Hat Switch is used to move between the various tabs on the UI windows (left and right) and to highlight items on the window (up and down). Use the bottom 4-way Switch to increase (right) and decrease (left) highlighted values, or button 4 on the throttle to select the currently highlighted entry. For example, to request docking you might press left on the top 4-way Switch to bring up the Target Panel, press right on the Throttle Hat Switch to select Contacts on the Target Panel, press down on the Throttle Hat Switch to select the station, then press button 4 on the throttle to bring up the interaction dialog, then down on the Throttle Hat Switch to request docking permission, then button 4 on the throttle to confirm.

Power management is performed using the forward 4-way Switch on the throttle with the directions matching that on the UI (left for Systems, forward for Engines, right for Weapons and back to reset).

You can see the other assignments on the layout diagram.

Shifted Operation

Page 2 of the joystick layout shows the button assignments when the joystick shift (pinky) button is pressed. The greyed out assignments are the same as the unshifted assignments. Under shifted operation the joystick Hat Switch changes to a digital lateral and vertical thrust and the digital roll control that is mapped to side 4-way Switch on the joystick becomes yaw controls. There’s also access to additional targeting and sensor options on the stick.

Shift controls on the throttle allow you to toggle and reset head look, plus toggle/deploy various ancillary functions on the ship.

Axis mappings remain the same in shifted operation.

Landing Overrides

Page 3 of the joystick layout show the button assignments when the ships landing gear is deployed. This overrides basic targeting, fire group control and FTL drive control functions to provide all axis of motion via the two 4-way Switches and the Hat Switch on the top of the joystick. While docking (and especially while undocking) it’s recommended to disable the HOTAS Throttle Axis by moving the joystick Throttle Axis fully back. You can then use the thumb stick, joystick axis and the various digital controls to effectively land.

The greyed out assignments in this mode are the same as when the landing gear is not deployed. Sifted operation remains the same with the exception that changing fire groups is now mapped to Roll.

Watching it in action

There is a youtube video that goes over some of these layouts, and a thread on the Beta Discussion forum for those who are in the beta.

Feel free to mess about with the maps, and tweak them to your needs – or just to use them as an example of how to do some (very) basic CMS scripting with the CH Products HOTAS.

Google sucks… battery

I think it’s safe to say I use my laptop a lot. Not only is it my primary work machine, but it also comes home with me each night. 5:151 isn’t the end of the working day so much as time to relocate to my “office on the train”. Once I get home, should I have anything else I need to catch up with3, I have the option of heading into my home office2, or sitting with the wife while she watches her TV.

Last night I noticed my laptop battery was near dead (31 minutes left) which was odd because the 13″ MBPr’s are supposed to have insane battery lives of something like 7 hours. I know battery life diminishes with age, but this machine is still quite new and I was looking like I was only going to get 4 hours off a full charge. Something was not right.

Turns out the 7 hour charge is only attainable if you’re not spanking the CPU constantly, which it seems I was. Admittedly I do run an awful lot of applications and processes in the background, but they should all be in idle wait loops, delicately sipping power until called upon.

Some quick investigation showed that Google was at fault, although surprisingly not Chrome4. Google Drive was chewing up huge swathes of CPU, apparently updating the “synchronising” status, and halving my battery life. Restarting it caused the meagre 20% power I had left to start heading back towards the 1 hour mark.

Since restarting it it’s played nicely, and (after a recharge and some minutes on the train on battery power) I’m back to a project 8 hours 15 minutes battery remaining with Google Chrome now listed as the only app using significant energy.

1 My working day is dictated by trains, and the next one is an hour later. I don’t doubt stupid o’clock will feature during my time at Rainbird, but we’re trying to run things so that the mental startup hours are the exception rather than the norm.

2 slash spare room – by home office I mean I’ve got a thunderbolt display on the desk where my gaming rig lives. It means I can plonk my laptop down there and wheel my chair over to work comfortably on two screens.

3 I said mental startup hours, long hours are to be expected, and most of the stuff I do at home is lightweight admin stuff, or writing presentations, which hardly constitutes work anyway.

4 Although one result of the investigations into power usage is that I may be returning to Firefox or Safari given Chromes is getting to be a bit chubby and heavyweight.


One of the talks I do explains how ‘simple’ in the K.I.S.S.1 principle is not the same as ‘easy‘. Sometimes the easy option can introduce complexities into the system that become detrimental and actually introduce complexity. The simplest example is testing. Not testing is the easy option; but it introduces uncertainty and complexity into your system that will be difficult to pin down at a later date.

That said easy and simple are not mutually exclusive, which is an important thing to remember, especially when you’re caught in the throws of trying to fix a supposedly simple problem.

I spent far too many hours yesterday trying to write an install script for one of our components. The underlying issue is simple: “As someone installing the component, I want the configuration files to reflect the idiosyncrasies of my setup so that I can compile the code”. Or, if you prefer BDD format: “Given I am installing the component, when I perform the compile step, then the compilation should work”.

It all boils down to a bindings file which specifies the location of a couple of libraries and includes. The defaults specified in that file don’t work on everyones system, although they do work on live2.

My salutation was to write some code that iterated through the files, check if any were missing, and if so, prompt the user to give the correct locations. Great, except the format of bindings.gyp is such that I needed to take a complex structure, flatten it, inject extra details so the user prompts made sense, and then reconstruct the complex structure from the flat one. Not wanting to hard code the format I then disappeared up my own backside with specially crafted config files and mappings from that to the format used by bindings.gyp.

nearly 200 lines of code in, deep in callback hell with grave concerns about whether my script would even pass code review I discovered some pretty nasty bugs that meant that minor configuration changes to a live server would cause an automated deploy to suddenly require user input, which we didn’t want. Adding logic to provide an override to this would make things even more complex and my nice, simple solution was disappearing out of reach.

It was then that it hit me that I was providing the wrong solution. This is something that really needs to be set once per environment and then left. It’s not going to be used a huge amount of time, it doesn’t need to be gold plated. With that in mind I wrote a simple shell script that checked for the presence of an environment variable. If the variable existed, use the bindings file it points to, if it doesn’t, use the default; simples.

All told, with error handling and everything, the script is 21 lines long. Not only that, but it provides a nice way to handle upgrades to the environment in live without having to redeploy.

1 Keep It Simple Stupid – in a nutshell, don’t overcomplicate things.

2 Something we wanted to maintain.

The Joy Of Development

It would appear someone has stolen my week. It’s Thursday afternoon already and I left the office wishing I could stay for another hour or two as I was on a roll and wanted to finish what I was working on. While I do have the ability to work on the train it’s offline for most of the journey, and interjects a 30 minute delay which is enough to derail any train of thought. Instead I need to wait until I get home to finish off.

It’s been a long time since I’ve been caught up in The Joy of Development at work. Too long in fact. I’d almost forgotten how much fun it is to take a complex problem and provide an elegant solution. I’d also forgotten how much of an arse it is to get OSX to play nicely as a web server – something the Apple make even harder when you’ve got OSX server running on the box. Still judicious amounts of Googling and sudoing have fixed that issue so shortly we shall have beautiful reports and pretty graphs coming from our CI builds which we can proudly display in the office on our dashboard screens.

Next job is to take the rather meta PostIt note from the whiteboard1 saying “build Kanban board” and turn it from a makeshift board with a few things stuck on it into a work of functional art. Then we can take the newly purchased PostIt notes, write down everything that needs to be done between now and the 21st2, panic at the size of the backlog and then wish we hadn’t visualised it.

All of which is a nice segue-way into a weekend of learning about continuous delivery into the cloud and blue/green deployments; although I could quite happily handle several more working days in this week before the weekend. I’ve missed enjoying work.

1 Actually, there’s two of them, and this one is on the left, so technically it’s the wheftboard, not the whiteboard… anyone? … no? … One is on the wheft, one is on the white? … really? No-one? Fine, forget it.

2 Release date for our open beta; sign up if you haven’t, it’s rather cool stuff. Also the date of my next talk, which I really need to get finished.