## DOTA2 Tutorial List

Thought I’d link a heap of DOTA2 learning resources and guides for people getting to know the game.  I’m still terrible, of course – don’t get much time to play, and I only play vs. bots right now.  Anyway, these are the links I’ve found;

• Dota2 Alt-Tab Guides – A cheat-sheet of all the heroes, a suggested build and a bit of info about all of them.  This is great to use in the Steam Web Browser so you can get an idea of what you’re up against (or playing!).  I usually put these builds into the Build Editor so I can have them in-game without having to shift-tab all the time.
• Official Hero Info – This is actually the info you get ingame, just in a browser.  You can use this page to edit your hero builds and review items and stuff without being in the game.
• PurgeGamer’s Welcome You Suck – Good starting guide, gives suggestions on heroes to avoid and heroes to use when starting off.
• Comprehensive DOTA Guide – Also a great guide.  Lots and lots of info.
• DotaFire – Community website, has lots of builds, guides and a hero database.
• DotaCinema – Youtube channel features a lot of great info.  Notably, the Hero Spotlights and the Learn DOTA 2 playlist.  Worth a look.
• Creep Blocking – Quick howto about creep blocking.
• Universal Item Guide – A good guide to all the various items.

Enjoy.

## Station Building in KSP

I’ve been doing various things in KSP since I last posted about it.  Re-did the Mun landing in the manner of Apollo 11, even including doing the midflight module reorganization so that the lander was on top.  The project I’ve been currently working on has been to assemble a space platform for holding fuel and other supplies for more remote missions to stock up on once entering orbit.

Behold, the Icarus I!

The station is built up from from three separate launches as you see it there.  The first launch took the base station module, which is on the right part of the image (including the crew capsule, six-way docking port on the right and solar panels).  The second launch was the middle fuel module (the orange tank, redundant engine, RCS tank, and nosecone) and the cross-shaped docking port connector.  The third launch brought an extra fuel module into play.

With this design, I have fuel modules with lifters that can be brought up to the station and bring up RCS fuel and a full orange tank.  They can then dock up and transfer fuel onto the station.  The station can hold five such modules in the main battery, and still have docking clamps available for other vessels to dock on and collect fuel / crew.  The individual fuel modules can even be undocked and deorbited if desired, since they have a probe controller onboard, RCS thrusters, RCS tanks, and an engine.

Having such a thing in orbit should make missions to other planets far easier to sort out – no need to carry fuel for the transit, just make sure you get enough empty tanks in orbit to fill up.

## DOTA2 with SLI Graphic Corruption Fix

I’m using an NVidia GTX690, in 2d surround mode.  The GTX690 is an SLI card, and in 2d surround mode SLI is not optional.  Running DOTA2 on this system (even on just one monitor) causes all sorts of random graphic corruption.

This corruption manifests itself as flickering text, distorted polygons when hovering over menu items, that sort of thing.  Nothing terrible, but it’s annoying.  Fortunately, I found a fix!

This thread on the DOTA2 Dev forums worked perfectly for me.  I’ll summarize it here in case that thread disappears;

What I ended up doing was downloading the latest nvidia inspector. I changed my values for a few options. (see below)

‘Number of GPUs to use on SLI rendering mode’ : SLI_GPU_COUNT_TWO
‘Nvidia predefined number of GPUs to use on SLI rendering mode’ : SLI_PREDEFINED_GPU_COUNT_TWO
‘Nvidia Predefined SLI mode’ : SLI_PREDEFINED_MODE_FORCE_AFR2
‘SLI rendering mode’ : SLI_RENDERING_MODE_FORCE_AFR2

And a screenshot of my settings in NVidia Inspector follows;

The items in grey are unchanged.  Seems to have worked immediately, and performance seems fine.

## State of the Game – ZenCoffee Edition

Thought I’d write something about what games I’m playing right now, and what I have on the backburner.  Ordering of these is pretty rough and mostly by level of interest of amount I’m playing it.

# EVE Online

I’m an old-time EVE Online player, originally started in 2003.  However, over the years I’ve taken a few years off here and there, including the last break which was at the start of Incarna.  I decided to come back because some friends of mine resumed their accounts, and I read about a lot of the changes that had happened during my leave of absence.  It’s taken me a few weeks, but I’ve got myself mostly sorted out, and I’m running around high-sec doing incursions and missions and stuff like that.  Don’t know if I’ll ever get back into nullsec stuff, I don’t think I have the time.

# Kerbal Space Program

I’ve had this recommended to me, and picked it up the other day.  KSP is awesome, for people interested in that sort of thing.  In essence, you assemble rockets / space stations / landers / rovers from out of basic components, and then launch them into space.  You can plan all sorts of space missions – from orbital rendezvous through to landing on the Mun (moon), and even on other planets.  Good fun, and it never gets old when a rocket fails catastrophically.

# The Last of Us

Released by Naughty Dog, the same company that brought us the Uncharted series, The Last of Us is a post-apocalyptic third-person shooter/adventure with a great story and emotive, believable characters.  I’m only playing this in small doses.  Its R rating and high gore means it’s not appropriate for me to play this while the toddler is awake, and when she’s in bed the TV is usually appropriated for something else.

# A-10C Warthog

Previously discussed at length.  I’m not playing this a whole lot right now due to other things happening, but this is still on my list to be continued with.

# Rift

Since this went F2P, I gave it a go.  However, to be blunt, I’m not that impressed with it.  I can’t help but compare it to Guild Wars 2, and it usually comes in lacking.  I’m mostly just playing this with my wife when we feel like it, and other than that, it’s pretty low priority.  It is free though, which is a really big point in its favor.

# Defiance

I grabbed this when it was on sale on Steam a while back.  It’s supposed to be a Syfy/Game fusion experiment.  As a shooter, it’s pretty mediocre.  As an MMO, it’s also pretty mediocre.  The graphics are acceptable, and the gameplay is entertaining, in a mindless way.  The lack of a levelling system makes it very accessible, but also leaves me feeling that there’s no progression at all.  It’s OK if you want to shoot stuff for a bit and not think too much about it.

# Guild Wars 2

Played this quite extensively already.  It’s on low priority – mostly gets played now when my wife wants to play together.  I’ve got max level characters for Ranger, Elementalist, Guardian and Mesmer.  I prefer playing the Elementalist, it’s a lot of fun.

# Star Citizen

It’s not even out yet, but I’m excited for this.  If you’re a fan of the old Wing Commander / Privateer / Freelancer series and space combat in general, you have to check out Star Citizen.  I’m also interested in X: Rebirth, but EgoSoft seems to be dragging their feet terribly, and to be frank, if SC is coming anytime close to XR’s release, EgoSoft should rename it to X: Stillbirth.

# Elite: Dangerous

Again, also still being developed.  I was a huge fan of Elite back in the day, and this is being made by the same guy.  Definitely looking forward to this one, although obviously Star Citizen is the gorilla in the room for space sims currently being developed.

# DOTA2 / League of Legends

I’ve put these two together because they sit in the same genre.  I’ve wanted to learn a MOBA for a long time, but never really found the inspiration.  Now with DOTA2 having a tutorial mode, maybe I’ll get around to it.

# Starcraft II – Heart of the Swarm

Not a huge fan of the Zerg, but I’ve played through the SC2 original campaign, so was thinking of doing HotS when it comes on sale.

Some of the issue with the above two games is that I find myself increasingly unwilling to engage in PvP-only games, and particularly team PvP games.  It’s not that I hate losing or anything like that, it’s just that I want to play on my terms in my own time, and not feel that I’m letting anyone down by just dropping out because of RL concerns.

And for that reason, I tend to find myself gravitating towards games that can be played single-player or alone, or that support drop-in / drop-out gameplay.

## Kerbal Space Program!

I recently picked up Kerbal Space Program from Steam, at lots off.  Awesome game, if you’re into that sort of thing.  I first used the stock Kerbal X rocket, and tried to get it into orbit.  After a few misfires (whoops), I managed to get it into orbit and deorbit it into the sea with the crew alive.  Yay!

Next up, I went and grabbed MechJeb2, which is an autopilot / information mod.  MechJeb can be used for a LOT of data about your rocket.  In particular, I wanted it to show me delta-V data for my stages.  I’ll admit it.  I use the autopilot for launches.  I know I can do a launch, orbit and circularize by hand, so I’m not too proud to admit to using MechJeb to handle that for me.

So, I then decided to replicate the Gemini 7/6A launches, and do the orbital docking.  Built the rocket myself according to the spec in the tutorial, with the exception that I installed a MechJeb2, two solar panels, and a battery pack on the side of the capsule.  I also put some standard canards on the first stage booster.

I used MechJeb2 to handle the launch and orbit circularization (100km), and also used it to get the capsules on an intercept course.  From there, everything was done by hand.

After some time, I managed to get them within a few meters of each other…

And then slowly, slowly, slowly coming together, I had to reorient and back away because I was targetting the capsule, not the docking port, so they were inches from bumping.  Fixed that up, and…

Success!  After cheering for a bit, I detached Gemini 7 and deorbited it, using MechJeb’s landing guidance (no autopilot, just the projection).  Got it down within 3km or so of the KSC.

Then, I assembled a suitable lander for the Mun along with a transfer stage booster.  After messing about with trying to make a primary lifter that would have enough delta-V, I came up with this design…

Errm….  It didn’t go so well.  That was a staging failure – the clamps didn’t release when the rockets fired, and hitting space detached both the clamps and separated the rockets, which then resulted in the catastrophe you see.

In the end, I resorted to using the Zenith Rocket Family pre-built lifters.  I wanted to make sure that my stage would be appropriate, and make sure I could actually DO it.  When I do an interplanetary launch, I’ll probably use the Nomad Interplanetary Drive Family boosters.

I used MechJeb to handle most of the navigation.  The point here was to see just what happens, and to pay attention to how the various orbital mechanics actually work.  Then I’ll do it myself with no autopilot, since i know the rocket can do it and have fuel to spare.  Anyway, success!

I even had enough delta-V to get them back to Kerbin safely!  Great success!

Much stuff about orbital mechanics learned.  Now to to it with no navigation assistance besides what’s built-in, and once I have that down pat, plan a mission to Duna!

## SVN Version Control for Gaming

DCS World is a big, complex game.  And it gets updated a fair bit.  And sometimes, just sometimes those updates break it.  In addition, I make customizations to the game’s scripts to make it work with my setup, and so I tend to lose those changes every update.  A better solution is required.

Enter Subversion (SVN).  Subversion is a version control system usually used for managing versioning for source code.  It allows you to commit changes into a repository, roll back changes if required, and also bundle up sets of changes into branches or tags.

It’s possible to set up your own local SVN repository and use that to manage game installations like this, even if the game is already installed.  First, go and get TortoiseSVN and install it.  Then, go and edit the security settings for your game folder so you can have write access to it without needing to elevate (if you’re using Vista/7/8).

For this example, the game we’ll be bringing into versioning will be in D:\Example\Game, and we’ll be making a local SVN repository in D:\Example\SVN.  We’ll do an initial import, tag it, edit some stuff, commit a new tag, and roll back.

# Step 1 – Create the Repository

Create the folder D:\Example\SVN, however you’re going to.  Then right click on it, and click TortoiseSVN.  Click Create repository here.

Now, in the dialog box that appears, click “Create folder structure” followed by OK.

# Step 2- Importing Content

Now, right click on your game folder, then click TortoiseSVN, Import.  This will open the Import dialog;

Edit the repository URL to file:///D:/example/SVN/trunk .  This causes the folder to be imported into the trunk of the SVN repository.  Type in a sensible import message, like “Initial import of version FOO”.  Tick “Include ignored files” to make sure you get absolutely everything, and hit OK.

Wait.  This will take a while.  All the content in that folder is being imported into the repository and being marked.  Note that this will take a fair amount of disk space, but disk space usually isn’t at a real premium these days.

# Step 3 – Changing over your install to the SVN Repository

Now that you’ve imported everything, you have something scary to do.  You’re going to delete/move your entire game folder somewhere else and then check out SVN into it.

Go into your game folder, and move its entire contents somewhere else, or delete them.  You want that entire folder clear.  Then, right click on the game folder, and click SVN Checkout.

Make sure that the repository URL is the location that you imported the folder into (the trunk of your SVN repository).  Make sure that the checkout directory is the game directory you just cleared.  And check out the HEAD revision (this means the latest revision in SVN).

This will also take a while to run.  Once it’s done, you should see a green check mark on the game folder.  This means that the folder and all its recursive contents are consistent with SVN.  Congratulations.  Now we need to learn how to do some SVN housekeeping.

# Committing changes to the trunk

The trunk is where the main, currently active version of your game should reside.  This is what you currently have checked out.  Now, let’s assume you just ran a game update, and it modified files and added some new ones. The modified ones are picked up with a red cross, the new ones are missed.  In order to commit all the new files into SVN, we’ll need to do a commit.

Right click on the game folder, then click Commit.

In this box, review the list of changes made.  Make sure that ‘Show unversioned files’ is selected – this will show you files that got added to the game’s folder since the last commit.  This is vital so you can add files that may have been added by the patcher.  Tick ‘Check: All’ if you’re happy with the list of changes made, enter a reasonable message and click OK.

All the changes made will be commited into the repository you have checked out (most likely the trunk), and that version will then be the new head revision.

# Making a tag

Tags are commonly used to mark a specific revision of your SVN repository.  For our purpose, we have a perfect use for tags – saving specific versions of our game.  Let’s assume that the current committed version is version 1.1 of the game and you want to make a tag for that so you can roll back to it at another stage.

First, we’ll need to create a folder in your repository for tags to live.  Right click on your game folder, then click TortoiseSVN and Repo-browser.

In the repository browser, right click on the very top of your tree on the left, and click Create Folder.  Name the folder ‘tags’.  Run through the message box, and let it finish.  Then click on the top of the tree, right click and click Refresh.  You should now see the ‘tags’ folder.  Hit OK on the repository browser to close it.

Now, right click on your game folder, which should already have all the changes committed, click on TortoiseSVN, then click “Branch/Tag…”.

In this box, change the path to /tags/release-1.1 .  This is what you’re going to create the tag as.  Note that your source data is from the trunk.  Enter an appropriate log message, and hit OK.  Creating a tag from existing committed data is very fast, and takes very little disk space.  You can select ‘HEAD revision’ to definitely create the tag from the head revision, otherwise it’ll use whatever revision you currently have checked out to make the tag.  Or the working copy of the data (which may have uncommitted changes).

If you now go into the Repo Browser you’ll see your created tags under /tags .

# Reverting to the currently checked out revision

Let’s say you accidentally blew up some files, or a patch went bad or similar.  There’s a few ways you can revert effectively, but you need to be able to revert a few kinds of changes;

• Files that were modified
• Files that were deleted
• Files that were added

Now, by definition all files that were added will be unversioned.  So, right click on your game folder, click TortoiseSVN, then click Revert.  Check ‘Select all’ to make sure everything’s selected and review the list.  Now click ‘Delete unversioned items’ review that list, and hit OK to clear out any items that were added by accident.  Finally, hit OK on the Revert dialog box to revert back to the checked out revision.

Your install is now back the way it was.  Easy!

# Reverting to a different tag

Let’s say that you need to (for some reason) roll back to a whole different release you previously tagged.  First, make sure that your currently checked out working copy is all committed and OK, since it’s going to go away in a moment.

Right click on the game folder, then click TortoiseSVN, Switch.  Click the ‘…’ next to the dialog box, and go find the tag you want to switch to.  Hit OK, and your working copy will change to the tagged release.

WARNING!  When you switch, your working copy is no longer of the trunk revision!  It’s now of the tagged revision!  This means that if you commit any changes, they will be commited to the tag, not to the trunk.  This is probably not what you want.  Then again, it may be.  Just be aware that a switched working copy is no longer of your trunk, and that tags aren’t necessarily static.  Note that at any time, you can review the commit log for the trunk or a tag so you can review what was changed.  This is why messages are so important.

To change back to the trunk, repeat the process, but select ‘/trunk’ as the path.  Select ‘HEAD revision’ to make sure you get the latest revision of the trunk.

# Conclusions

With those basic processes, you can use TortoiseSVN to manage updates and do version control for all sorts of things – including game files which are largely binary.  The basic scenarios you’ll need to handle with SVN are;

• Saving a working game update:  Commit, then Tag the HEAD revision appropriately.
• Reverting broken, uncommitted changes to the HEAD revision:  Revert, selecting to delete all unversioned files.
• Switching to a previously tagged release:  Switch to the tag you made.  Keep in mind that your working copy is now the tag, not the trunk.

Have fun!

## DCS A-10 Warthog Tutorial Reference

I’ve been putting in some time on learning to fly again in DCS A-10C Warthog. Fortunately I seem to have had better recall of prior learning than I thought I would, but it’s still definitely not a trivial process.  So, I thought I’d link various documentation, websites and tutorial videos I came across for anyone trying to learn the same thing.

# Equipment

I’ve got a Saitek X52 Pro stick and throttle.  I can definitely, definitely recommend the Saitek, and I’d also strongly recommend using this profile.  It’s adapted from others I’ve seen around, and it works well for me.

I also use a set of Saitek rudder pedals, but I’m not convinced they are actually required.  EAC on the A-10 takes care of most of the rudder work, so you could probably get away with just the stick twist rudder on the X52 pro, and then manage wheel brakes with a key assignment somewhere instead of using the toe brakes on the pedals.

Lastly, I have a TrackIR5.  TrackIR makes a massive difference to the experience.  If you have a webcam available, you may be able to use FreeTrack or FaceTrackNoIR instead.

I would consider head tracking to be more important than pedals, to be honest, so if you’re only going to buy a couple of pieces of gear, get head tracking and a stick with separate throttle (trust me, you’ll need the buttons).

# Official Documentation

• DCS A-10C Warthog Flight Manual – This is your bible.  Every system is detailed in gory detail, and it provides all the information you need, although not really in an easily digestible form.  Keep this on-hand as reference material.
• DCS A-10C Warthog Quickstart Guide – I didn’t find this to be of too much use, but give it a read anyway.

# Third Party Repositories

There’s a whole bunch of info available on the ‘net.  Here’s some of the bigger repositories of info I’ve come across;

# Wow, that’s too much!  Just get me in the air!

Ok, I totally understand.  Let’s just do the basics.

• MemphisBelle’s Quick Start up Manual – Good picture guide for how to do a cold start.
• Lobo’s Normal Checklist – Includes some steps that are optional in a game.  Don’t try and read this thing the whole way through, just refer to the checklist for whatever task you’re doing at the time.
• Ramp Startup Video Part 1 and Part 2 – These are recordings of the ingame tutorial.  Watch it in Youtube first.
• Do the tutorials!  They’ll run you through basic operation of most systems.
• If you’ve never flown anything before, take a read of See How It Flies.
• Go and get DRAGONs Training Pack.  This is a well executed set of training missions which provide you with a playground (if you hang around the Easy waypoint) giving you plenty of room to practice without having SAMs shooting you down all the time.

After the above, and going through the ingame tutorials, you should be able to get in the air, find waypoints, shoot some stuff, and hopefully land.  From there you can hit the references above to find out how to do more advanced stuff.

Good luck!

## Triplehead FOV with DCS World 1.2.4

I did some work on getting triple-head going properly in DCS: World 1.2.4 (7680×1440 with three 2560×1440 monitors).  I’ve tested that everything seems to work fine with the A-10C Module.  Also looks fine with the F-15 (so probably everything in Flaming Cliffs 3), and the Ka-50 Black Shark. The Ka-50 viewpoint is a little buggy and will try and zoom out a LONG way when you enter, so just press * to zoom in until it looks normal.

In order to set up, you’ll need to do the following;

• Apply the diff file from here to your DCS World setup.  It’ll go and change a couple of files in minor ways.  You can also get a ZIP of these files already changed suitable for DCS World 1.2.4.12913.167 from this link:  TripleheadFOV-1.2.4.12913.zip
• Copy autoexec.cfg from here into your C:\Users\<username>\Saved Games\DCS\Config folder.
• Copy SnapViews.lua from here into your C:\Users\<username>\Saved Games\DCS\Config folder.

The diff allows use of customized snap views, and sets the default external viewing angle to 120 degrees (maths as to why this is right can be found at this link).  It also hardcodes the screen width for some UI elements to 2560×1440, and pushes the radio chatter windows across one screen so that they render on the middle screen and not on the right.  And lastly, it modifies Server.lua to allow the widened FOV for the Ka-50.

The autoexec.cfg sets the maximum fps to 60, to avoid issues that tend to happen with microstutters on SLI.  The SnapViews.lua contains recalculated viewing angles for all default snap views such that they are corrected for triple-head FOV, as per my prior post on the topic.

Enjoy.

## Triple-head with Guild Wars 2

Over the weekend I decided to go and give Guild Wars 2 a go.  I’d heard some good things about it, and I wanted to try it out since I’m after something that’s in the fantasy MMO style, but doesn’t attract a subscription fee.

Anyway, I was very surprised and pleased that it just worked with my triple-head monitor setup!  No messing about, I just selected the appropriate resolution, adjusted some of the detail settings down a little, and here we go;

 Click for full size.  It’s HUGE.

That JPEG has had its quality dropped a lot to keep it at a semi-reasonable size, so expect artifacts and such.  But it gives you an idea of what the view looks like.  The movies all play correctly (in the center monitor), the UI renders sanely, and the game plays just fine in triple-head.  There’s a few minor niggles though;

• Character creation splashes flicker.  Unknown why.  The mouse isn’t aligned properly in those screens.
• Increasing the UI size from ‘Normal’ as in the screenshot above to ‘Large’ or ‘Larger’ pushes the UI to the right and off the center monitor.

This is pretty annoying, because my 27″ 2560×1440 monitor has a vertical dot pitch of 0.0092″, so any UI elements which are fixed in a small number of vertical pixels are REALLY small.  Oh well.

In terms of graphic detail adjustments, I’ve generally found with games in triple-head you first run out of VRAM before performance on a GTX690.  Running out of VRAM is really easy when you have so many pixels on-screen.  So here’s the usual settings that I play with;

• Vertical sync.  I leave this unset, and then control it through the NVidia Control panel in ‘adaptive’ mode.
• Framerate Caps.  If a game has the ability to set a maximum framerate, I set it at 60.  No need to stress hardware when you can only display frames at 60 fps anyway.  It also seems to reduce the micro-stutters you get when you run uncapped.
• Shadow detail.  This seems to steal a fair bit of VRAM, and usually I don’t care much about shadows.  I turn this down to low, but usually not off.
• Grass/tree detail.  I turn this down a bit if needed.  Games like SWTOR seem to attract a heavy performance penalty for having these up.  Turning them down to half has very little visual effect but greatly improves performance.
• Antialiasing.  With a high resolution display with a small dot pitch, AA doesn’t really offer a whole lot.  It consumes huge amounts of VRAM.  I usually turn this right off.
• Draw distance.  If you get desperate, reducing draw distance a little can make the difference between filling up your VRAM and running smoothly.

Key signs that you’re filling up VRAM are when you move into a new area (ie, new textures), and experience a framerate stutter and then everything runs smoothly again.  In a flight simulator, it can be exhibited by stuttering when close to the ground.

Because of the way that NVidia SLI works, a “4Gb” card actually has 2Gb effective useable, because each GPU (there are two) has to maintain the same VRAM buffer set, and so you can only fit 2Gb of actual textures and other data in there.  That’s why it’s so easy to run out of VRAM.

Anyway, with a little bit of adjustment, GW2 runs at 50-60 FPS with no stuttering, and still looks really nice.  Now I’m just hoping that the vendor fixes up the UI so that I can increase the UI size and it’ll be perfect.

Many games appear to do horrible things with the viewport when you are using a display with a strange aspect ratio – such as a triple head setup.  The aspect ratio of my setup is 48:9, which plays merry hell with viewports in flight sims that are designed to look ‘normal’ with a 16:9 setup.  The usual result is that views are horrendously thin vertically.

Anyway, I did some trigonometry (which is probably a bit broken) and came out with a formula that lets you convert a FOV figure that’s intended for a normal aspect ratio and convert it to an FOV that’s appropriate for a triplehead setup.

$\displaystyle \theta = 2 \tan ^{-1} ( 3 \tan \frac{\alpha}{2} )$
Where
$\alpha =$ original FOV
$\theta =$ new FOV

Using this, the result that you get is the ‘original’ view, instead of being spread horizontally across three monitors and then the vertical component being hopelessly thin will be spread across only the center monitor.  This means that you’ll see extra stuff on the left and right that wouldn’t have been in that viewport normally, but the vertical view will be normal.

Doing this in something like A-10 with the left and right MFCD’s works great – the MFCD appears on the central monitor and pretty well fills it, which is what you’d expect.  Without adjusting FOV, you just get about 1/3 of the MFCD into the display.

A conversion chart appears below for those who don’t want to do math;

FOV Conversion Chart
Standard FOV Triplehead FOV
20 55.76
30 77.59
40 95.03
50 108.88
60 120.00
70 129.09
75 133.04
80 136.67
90 143.13
100 148.75
110 153.72
120 158.21
130 162.33
140 166.16

75 degrees is included here because that’s the default FOV for a lot of the DCS simulations.  The triplehead FOV of this (133 degrees) winds up being very close to the value that I figured out by eyeballing it (which was 135 degrees), so I’m fairly happy this is accurate.