Blog

Latest  2014  2013  2012  2011  2010  2009  2008  2007  2006  2005  2004  2003  2002  2001

This personal blog comprises whatever I feel like saying on any given day, which often involves topics like new media, journalism, Web technologies, Racket/Scheme/Lisp, Free and open source software, societal issues, cinema film, Boston, frugality, and humor. Many things noted here are solely for the benefit of future Web searchers trying to solve particular esoteric problems, and are not of general interest. This blog is largely insulated from my professional life, and vice-versa. I attempt to provide full disclosure of potential conflicts of interest. Last time I checked analytics, my site was getting over 1000 unique visitors a day.

Thrustmaster T.Flight Hotas X Flight Stick and Ace Combat Infinity for PS3

 [Photo of Thrustmaster flight stick in front of screen displaying Ace Combat: Infinity video game.] Here's how to program the Thrustmaster T.Flight Hotas X flight stick for Ace Combat Infinity (AC:I) on the PS3. (Not that I recommend Ace Combat Infinity, but it's a free download for the PS3, and I could use it to test the new cheap controller hardware for a work project before some other necessary hardware arrived.)

Initially, I was going to use the instructions found at ftp://ftp.thrustmaster.com/accessories/pc/joysticks/presets/THOTASX/HOTASX_AceCombatPS3_Mapping.pdf, but then I found the instructions appeared incorrect. The instructions were inconsistent in the ordering of the programming arguments. For my instructions below, I assume that the programming order is the original control action, followed by the new control action.

First, before plugging the Thrustmaster into the PS3, make sure that the mode switch on on the front of the Thrustmaster is set to PS3 rather than PC. Then plug the USB cable into the PS3.

Then use the sequence of programming codes in the table below. As you're programming, actuate the controls in the Programming Codes column in sequence, top to bottom, left to right. The general pattern (after the initial press of the Preset button, which turns on the LED by the Preset button), is to press the Mapping button, actuate the original/undesired control, observe that the Preset LED is blinking rapidly, and actuate the new/desired control for that function. In the case of the throttle control action, since it is not a momentary control like the others, I added additional steps in the table below to return the throttle to the middle position.

In these instructions, a number in parentheses denotes a solid-circle label on the Thrustmaster. The solid-circle labels are intended for the PC mode of the Thrustmaster, and the the other labels are for the PS3 mode. The reason I used the PC labels is that some of the buttons are missing PS3 labels.

The instruction table starts assuming that the Preset LED is off. The initial actuation of the Preset button in the instructions turns the LED on.

+----+--------------------------------------------------+---------------+
|    | Programming Codes                                | Function      |
+====+==================================================+===============+
|  0 | Preset                                           |               |
+----+--------------------------------------------------+---------------+
|  1 | Mapping ThrottleUp   HatUp        ThrottleMiddle | View Up       |
|  2 | Mapping ThrottleDown HatDown      ThrottleMiddle | View Down     |
|  3 | Mapping TwistLeft    HatLeft                     | View Left     |
|  4 | Mapping TwistRight   HatRight                    | View Right    |
+----+--------------------------------------------------+---------------+
|  5 | Mapping (1)          ThrottleUp   ThrottleMiddle | Accelerate    |
|  6 | Mapping (2)          ThrottleDown ThrottleMiddle | Decelerate    |
+----+--------------------------------------------------+---------------+
|  7 | Mapping (6)          (1)                         | Gun           |
|  8 | Mapping (7)          (2)                         | Missile       |
| 10 | Mapping (5)          (3)                         | Switch Weapon |
|  9 | Mapping (8)          (4)                         | Switch Target |
+----+--------------------------------------------------+---------------+
| 11 | Mapping (9)          TwistLeft                   | Yaw Left      |
| 12 | Mapping (10)         TwistRight                  | Yaw Right     |
+----+--------------------------------------------------+---------------+

That should do it. The programming should then remain in effect in non-volative memory within the Thrustmaster, used whenever you're in PS3 mode and the Preset LED is on.

When you need to use the PS3 colored-shape controls for AC:I menus, the mapping is:

Cross    = (1)
Circle   = (2)
Square   = (3)
Triangle = (4)

Personally, for Ace Combat Infinity, I find the PS3 controller easier to use well than the Thrustmaster, in most respects. I wonder whether the flight stick and throttle controls are better if you're a pilot pulling Gs in a fighter jet, but the fine-motor control of many individual fingers on a PS3 controller is generally superior when you're playing a video game.

GnuCash and Leaf Account Names

In GnuCash, I've found that changing ledger preferences to show only leaf account names is a win, but it gets problematic with all the GnuCash accounts involved in a single brokerage account, so I have a measure to mitigate that.

GnuCash accounts are organized into a tree (hierarchy), and by default, a transaction in a ledger for one account will refer to the corresponding account using a name that is an absolute path to the account in the tree. For example, "Assets:Current Assets:Bank Deposits:BofA Checking 1234". This looks ugly in the ledger, takes up lots of horizontal space or gets truncated, and is tedious to enter with text autocompletion. The leaf name "BofA Checking 1234", however, is short and unambiguous.

Fortunately, GnuCash has a user preference setting:

Edit → Preferences → Register Defaults → [X] Only display leaf account names

Enabling this is generally a win, and probably most of your account leaf names are already unique. One place where unique leaf names is problematic, however, is investment accounts. Let's say you have an IRA with Broker Investment Trust Co., with an account number ending in 2345, and the IRA is split between two investments, so the account hierarchy looks like:

Broker IRA 2345
    BRK.B
    IVV

(You include the last 4 digits of the account number in the name because you have multiple IRAs at Broker, or because you've found that over time including the number helps as accounts come and go, and when you get statements and such.)

Later, because the money in your savings account is being devalued like crazy, you open an investment account with Broker, invest in a few funds/stocks, and that hierarchy looks like:

Broker 7890
    Cash
    Open Orders
    Positions
        BRK.B
        IVV
        FCNTX

Now your account names are no longer unique, and you're asking for an error, such as crediting a BRK.B purchase to the wrong brokerage account, or crediting cash to the wrong account. Which could result in expensive financial mistakes.

So, what I'm doing currently, when using leaf-names-only in ledgers, is appending the brokerage account name to the brokerage subaccounts, in square brackets:

Broker 7890
    Cash [Broker 7890]
    Open Orders [Broker 7890]
    Positions [Broker 7890]
        BRK.B [Broker 7890]
        IVV [Broker 7890]
        FCNTX [Broker 7890]

This looks ugly in the Accounts hierarchy view, but when leaf-name-only in ledgers, it's readable and unambiguous. "BRK.B [Broker 7890]" does not get confused with "BRK.B [Broker IRA 2345]".

This also works well with autocomplete. When entering the name in a ledger field, you start by typing, say, "brk" and then, when that's ambiguous, you see a list of the the options, and can pick the right one.

For reports, I'm coding to have the qualifier be hidden when appropriate, so that my hierarchy views and such don't show the qualifier at all. For example, here's a modified version of a procedure from balsheet-ng.scm:

(define (account-link account)
  (let* ((name                   (xaccAccountGetName account))
         (name-without-qualifier (cond ((string-match " *\\[.*\\]" name)
                                        => (lambda (m)
                                             (regexp-substitute #f m 'pre "" 'post)))
                                       (else name))))
    (if opt-use-links?
        (string-append "<a href=\"gnc-register:acct-guid="
                       (gncAccountGetGUID account)
                       "\">"
                       (escape-html name-without-qualifier)
                       "</a>")
        (escape-html name-without-qualifier))))

Which means, in my report, the hierarchy looks like this (no qualifiers), but I still get the qualifiers in the GnuCash GUI when they're helpful (and sometimes when they're not):

Broker 7890
    Cash
    Open Orders
    Positions
        BRK.B
        IVV
        FCNTX

Prior to delimiting in square brackets, I tried separating with an at-sign (which was too ugly), and using colon with the ancestor name in front (potentially confusing when GnuCash convention is to use colon for hierarchy paths, and ancestor-first is less readable in ledgers). The main thing I don't like about the square brackets is that some conventions use parentheses for negative values.

Other than brokerage accounts, leaf-name-only seems an obvious win so far. The workaround for brokerage accounts seems OK. Ideal would be for GnuCash to have some kind of disambiguating qualifiers be built-in, but I think that's a low priority, and probably also would be controversial.

Earlier to... 2014-09-15

© Copyright Neil Van Dyke      Contact