FSX:SE – How to get Plan-G Flight Tracking Working on OS X / Wine

One cool feature of Plan-G is the ability to connect to FSX and track your flights, even remotely.

Since my laptop uses OS X, I thought I’d install Plan-G via wine to track my flights.

Here’s what I did to get Plan-G working with wine:

  1. Download wineskin on OSX, download Plan-G
  2. Install Samba. Yes, really. I downloaded SMBup, but had to manually deactivate OSX’s samba, and manually activate “real” samba.
  3. Run wineskin and create a new blank wrapper
  4. Launch the wrapper and install .net
    1. Click on “Advanced”, “Tools”, “Winetricks”, and install msxml3
    2. Install dotnet40
  5. Run regedit, and add the following registry key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-0-0-0-1000
  6. Install Plan-G within the wrapper.

Plan-G should now load with wine, although it may be pretty buggy. Here’s how I set up Plan-G for remote access:

  1. Build the navigation database. There are two ways to do this:
    1. Share your FSX directory via samba. Point Plan-G to your /Volumes/sharedrive/FSX directory, and build the database
    2. Install Plan-G on the same computer as FSX, and build the database there. Then, copy your Documents\Plan-G Files\Data directory into your ~/Documents/Plan-G Files/Data directory on your mac
  2. Load Plan-G. Note that the following was pretty buggy for me; I had to hit alt and navigate via keyboard to avoid a crash. In File->Options->FS Connection:
    1. Connect via simconnect, IPV4
    2. Enter in the IP Address of your FSX computer
    3. Set the port to 4506
  3. Now go to your FSX computer. Make sure you have simconnect installed. If you don’t already, google it 🙂
  4. Follow the Plan-G manual, section 20.3 on how to create the simconnect XML on your FSX PC. Make sure that the IP address in your XML is the IP address for your FSX PC, not your remote PC.
  5. In Plan-G, and with FSX loaded, hit “Connect”

 

FSX:SE – My favorite free addons

Out of all of the addons that I’ve tried FSX, here are the best free ones I’ve found to date:

  • FreeMeshX. Updated terrain information from NASA for the entire world. Essentially makes mountains, hills, and so on look more realistic. This should be the first thing you install if you plan on flying outside of the USA.
  • The Just Flight Boeing 757-200. Free British Airways and American Airlines liveries.
  • The Basler BT-67. A super cool retrofitted DC-3
  • World of AI ATC. Adds AI aircraft from real airlines to your airports.
  • Plan-G. A vastly superior alternative to the default FSX flight planner
  • Simbrief. Makes flight plans based on real commercial routes.
  • Flightaware. Not an addon, but you can see real commercial flight plans, and flightaware can also propose realistic flight plans for you. Also has approach plates for most airports.
  • FSX Navdata update. The defaults with FSX are old.

Honorable mentions:

 

 

Flight Simulator X: Steam Edition w/ Xen 4.5, an i7-4770 CPU and AMD R9 270X

FSX is the game that I play the most in my Xen gaming setup. So after upgrading to Xen 4.5, I was completely bummed that FSX started stuttering and became unplayable. It wasn’t that my frame rates were low, but more like the simulation would cut out frequently.

Unfortunately, I didn’t just upgrade Xen, so I couldn’t make a direct cause-effect link. I also increased the available RAM pool and upgraded my AMD Catalyst driver. But I knew that Xen changed schedulers and the Xen wiki indicates that Hyperthreading might cause problems.

I already knew that FSX is very finicky; apparently it’s a 32-bit program and can only take advantage of 2GB memory, and apparently doesn’t handle multiple cores or hyper threading very well. It also doesn’t play well with AMD video cards.

I used this guide form help with FSX settings: https://kostasfsworld.wordpress.com/fsx-software-and-hardware-guide/

After experimenting with schedulers and Dom0 and DomU priorities to no avail, I reduced my DomU vcpu count to 2, and that fixed things.

Mystified, I ran the following experiment varying domU VCPUs, hyperthreading, and the AffinityMask setting in my fsx.cfg. I qualitatively measured my FSX results as either “Good” or “Bad”, since there was no middle ground, and I used the PassMark CPU benchmark as a second point of comparison. Here are my results:

DomU VCPUsHyperthreadingFSX AffinityMaskFSX PerformanceCPU PassMark
2Off14Good4510
4Off14Bad7024
2On14Good4528
4On14Bad6884
4On15Bad6884
4On84Good6884
8On14BadNo data

So in conclusion, I decided to go with 4 cores and AffinityMask of 84, since I want hyper threading to be on.

There are still two open mysteries, in my opinion:

  1. The data indicates that Xen had nothing to do with my poor FSX performance… but my gut tells me Xen has something to do with it, since I see some weird things. For example: changing the number of VCPUs influences windows boot time. During windows boot, qemu uses 99% CPU on one core on dom0. Also, I can’t consistently get windows to boot with 8 cores; only 4 cores are recognized,and the other 4 are paused.
  2. When I run FSX, task manager shows all of the CPU load on only one core. I don’t really understand this, but I didn’t bother to follow up since FSX now runs perfectly for me.

Upgrading from Xen 4.4 to Xen 4.5 on Arch Linux

UPDATE 4/26/15: After upgrading my system with pacman -Syu, xen quit working due to incompatibility with gnutls and nettle, among other things. 

Attempting to load xen gave me a confusing error message about failure to load a device model. My /var/log/xen/qemu-dm-*.log files showed that qemu was looking for outdated libraries.

I downgraded the packages with: pacman -U /var/cache/pacman/pkg/pkgname-olderpkgver.pkg.tar.gz

About two months ago, Xen 4.5 was released. Since I’ve had a few nagging problems with Xen 4.4, namely the inability to reboot my Windows guest without a crash, and the inability to assign > 2GB memory to my system, I thought I’d give things a shot. Plus, this post from tritron4 indicates upgrading to the Xen 4.5 git tree worked for him.

Unfortunately, the Xen 4.5 release isn’t available on AUR yet, and when I tried the xen-git and xen-4.5-git AUR packages, neither one worked for me.

UPDATE 4/26/15: Xen 4.5 is now available on AUR, but some users are reporting compatibility problems with gnutls, and a patch is not yet included in the PKGBUILD.

So I decided to do things the old-fashioned way, downloading the source from xen.org and compiling it myself. I was a bit  apprehensive, since I know that the Arch Xen packages include a lot of patches, and testing notes from kantras and others indicated that some changes had to be made to make things “perfect” for Arch, whatever that means.

But in the end, I threw caution to the wind, and was rewarded with a working Xen 4.5 distribution, without too much difficulty. Aside from following the instructions in the Xen source archive, Here’s what I had to do to upgrade Xen, overwriting my 4.4 installation. Most of this is taken straight out of the xen-git PKGBUILD:

  1. I had to set PYTHON=/usr/bin/python2 for all configure and make lines.
  2. I used the following configure options – not even sure if this was necessary:
    ./configure --prefix=/usr --localstatedir=/run --disable-multilib --enable-spice --enable-usb-redir --enable-stubdom  --enable-debug  --enable-xen-pci-passthrough --enable-bluez --enable-libiscsi --enable-vhost-net --enable-linux-aio --enable-vde --enable-nptl --enable-libiscsi --enable-smartcard-nss --enable-targets=X86_64-pep
  3. I had to update GRUB.
  4. After rebooting, I wasn’t able to load my DomU because Xen couldn’t access my windows partition. I had to manually enable these services in systemctl:
  5. systemctl enable xen-qemu-dom0-disk-backend.service
  6. systemctl enable xen-init-dom0.service

 

After these steps, I was able to load my Windows 8.1 guest just as before; except that now, I was able to assign 8GB of memory without the system freezing, and most of the time, I can shut down/restart/reset windows without having any problems.

All my games worked great, just like before – except for one: Flight Simulator X. In the next post, I talk about how I fixed this.

 

Creating a Xen Gaming System – Hardware Setup

The first rule of making a Xen gaming system:

Whenever possible, COPY A WORKING SETUP EXACTLY.

You will encounter quirks and roadblocks; so why not let someone else solve them for you?

That said, the barebones requirements for a Virtualization gaming setup are  VT, VT-d, and multiple video cards. Determining whether your system supports VT and VT-d is tricky. Not only do you need the right CPU, but your motherboard must have the correct PCH,  and your BIOS must correctly implement both features.

My hardware is as follows:

  • Asus Z87-DELUXE motherboard
  • Intel I7-4770 CPU (note: the I7-4770K supports VT, but not VT-d, so it will not work)
  • Radeon R9 270x graphics card (Gigabyte R9 GV-R927XOC-2GD)

Then, I have the following accessories:

  • 2 USB Keyboards (1 generic, 1 Razer DeathStalker)
  • 2 USB Mice (1 generic wireless, 1 Razer DeathAdder)
  • 1 XBox 360 Wireless Receiver + XBox 360 Controller (both are official)
  • 2 Dell Ultrasharp 2412m monitors
  • 1 TV with HDMI ports

I considered adding the following accessories to my system, but ultimately decided not to:

  • A USB add-in card
  • A USB switch
  • A spare sound card (either PCIE or USB)

Creating a Xen Gaming System – Motivations

Are you a gamer?
Tired of your main Windows machine needing periodic windows reinstalls?
Have you ever been frustrated by having to dual-boot to Linux?

 

These are a couple of great reasons to make a Xen gaming system.

In my case, I wish I could just do everything within the Apple / OSX ecosystems, and to boot into virtual machines for Linux.

But as we all know, video games ruin all of this. Some of the best games just don’t run under Windows (or even Linux), and even if they did, Apple hardware isn’t easily upgradeable, so your machine can quickly end up out of date.

So this, plus the “wow” factor of having a successful virtualization setup is a large part of what led me on my Xen journey, and my goal is the following:

dom0 – Arch Linux / Xen 4.4

  • Windows 8.1
  • OSX [WIP]
  • Chrome OS [WIP]
  • A home cloud server [WIP]
  • Various Linux test machines

Cloud @Home 0.1 – Draft

These days, it’s common to store data on the cloud, using services such as iCloud, Dropbox, and Gmail. It’s a convenient way to remotely access and synchronize your data across multiple servers.

It’s also pretty common to own a NAS, or to have some other home file sharing setup.

So why not combine the two?

I propose a home cloud server, that allows users to access their data efficiently whether at home or on the road. Unlike other NAS/cloud projects, this is a collection of servers, so that you can use whatever devices or applications they want to access their data.

Why have a Home Cloud Server?

Aside from DIY-cred, there are lots of good reasons to have your own cloud server:

  • You are in control of your data
  • All your photos, videos, and music are stored locally, without monthly fees
  • You want to share your files both on the road and at home among multiple devices, without being locked into one ecosystem

Components – Basic Cloud Server

There are five fundamental components that a basic cloud server should have; their operation should be transparent to the user:

  • SMB Server – For file sharing on the local network
  • Zeroconf – For local network device discovery
  • WebDAV – Remote file sharing and synchronization for photos, music, and videos
  • SSH/SFTP – Remote access and file sharing
  • CalDAV/CardDAV – Calendar, Contact, and Reminder Sharing

Components – Advanced Cloud Server

  • Mail – either a mail server or mail downloader
  • Web Cache
  • DNS Server / Cache
  • Offsite backup and/or interoperability with web cloud
  • A web interface