The throttle of my Thrustmaster T.16000M doesn't work with X: Beyond the Frontier on Windows 7. :^(
Apparently it has something to do with how Win9x considers throttle axis which has been changed in later Windows versions, according to this post. Sadly it doesn't say how to configure these programs and I have no experience with them, so I have to take some time to figure this out.

When digging through the registry I found this entry in:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\EgoSoftware\X

JOYGUID REG_BINARY 30 56 C2 19 15 1A E5 11 80 03 44 45 53 54 00 00

Maybe it could be made working by changing a value?
Does anyone know a solution?

That JOYGUID value is specifying the device itself (it's the codename that computer calls your Thrustmaster). So changing that won't work, I'm afraid.

I don't have a solution for you unfortunately, but I'm sure there are axis remapping programs out there? I had the same problem with I-War 1 but have yet to try hard enough to get to the bottom of it.

X:BTF is an old game, so it will be trying to use DirectInput. Being as you are on Windows 7 with a Thrustmaster 16000M, I'd say you are using XInput, the newer drivers that Microsoft created to replace DirectInput.

One of the downsides is that the Z-axis gets merged. It is more noticeable with a controller. For instance, I have a 360 controller, and it has two analog triggers. These are read separately by modern games that use XInput, but for old games that use DirectInput, they get read as a single Z-axis meaning that with both at rest the Z-axis is in the middle of the range, but when both are fully pressed it is still at the middle of the range as the one trigger acts negatively whilst the other postively, cancelling each other out, so they are only useful if used separately.

There are ways around this but you will need 3rd party software.

I used to use vJoy and UJR as the post you found suggested, but it couldn't solve this axis issue. I did, however, find a solution via the PCGamingWiki site.

The program I now use is called XInput Plus. https://sites.google.com/site/0dd14lab/xinput-plus
Unfortunately the site is in Japanese, but the program uses english characters and can be understood (albeit a little clunky on the field descriptions).

What this program does is take your XInput device and allows you to modify it, such as changing the circular range of thumbsticks/joysticks and mapping them to square ranges (as they used to be in old games), and splitting axes (good for the triggers). You then point it at the game executable you want to use those settings with and it creates a DLL file (there is no actual installation of the application, just extract and run and it generates the DLL). Then whenever you start the executable the DLL file takes precedent over the built in Windows DLL so the XInput device then maps to the DirectInput calls in the way you've specified. It even supports force feedback options, though the few games I've tried that with it has been a bit buggy whereby once the rumble starts it won't stop, so I tend not to use that any more (it could be the games I've used it with, though).

Bummer, thanks anyway. According to dxdiag the T.16000M is DirectInput (see attachement), to be sure I tried Humans Must Answer, a game that only supports Xinput controllers, and the T.16000M didn't work.
But I'm going to try your suggestion anyway.

Someone should write a direct input dll patch like this XInput Plus you've described. You wrote a really detailed and helpful post so I don't want so come across like an ass for correcting you on this point, but actually DirectInput is still around on modern Windows and what almost all joysticks (ie. actual sticks rather than thumbsticks) still require for reading inputs.

XInput has only replaced DirectInput in the sense that it's a more modern and simpler library to use (and 360 pads are very commonplace) but it's the game that decides which API it will use not the device (although the device can present itself to both APIs, like the 360 does albeit with the unified triggers issue you mentioned). So any game made before 2005 (or thereabouts) will only support DirectInput simply because it was made before XInput was released for the developers to use.

( There's also a third legacy joystick API on Windows called WinMM from back in the 3.1/95 days - I have to use that one for my old PlayStation controller adapter and it works fine too, except hardly anything supports it :-) )

Hmm. In that case, it might not work then, but it's still worth a try. The only other options I could think of are to map axes to buttons using something like Joy2Key or Xpadder, but then you'll lose the analog nature of those remapped axes.

If you want to try vJoy and UJR then expect some difficulties. Firstly, install the vJoy driver. Then, after rebooting Windows, connect your joystick. Then use the vJoy virtual joystick setup utility to create a new virtual device. You should now have two devices in Windows. Set the vJoy one as default using the control panel. (This step fixed issues for me).

Next, load up UJR. Set the output device as the vJoy device, then go through the device numbers for input until you find the one that works for your joystick (move axes and press buttons and when the right one is found you should see the options changing). At this point you should then be able to set up the mappings of axes and buttons.

If I remember rightly, UJR can merge axes but it can't split them (which is why I went with XInput Plus).

Well, it's how the XInput device presents itself to DirectInput, for which the axis mappings aren't great. But yes, if there were something like DirectInput Plus, that'd do it nicely in this scenario as it would map the DirectInput controller (turns out Strijkbout's joystick is DirectInput, not XInput after all) to different DirectInput mappings.

I've tried the vJoy+UJR method, I got to the point where vJoy mimmicks my physical joystick (T.16000M) in the gamecontollerpanel, but when I select vJoy in X-BTF it doesn't respond to any input. Fantastic, it works! :^D

Such a simple and elegant solution, how did you make this if I may ask?

That's great to hear!

How it works is fairly simple to explain - the real directinput is also called dinput.dll but by placing my version in the same folder as the EXE the rules for DLL loading mean the game will use this one instead.

Internally my code loads up the real dinput.dll and then every message I get from the game I directly relay (this took quite a while as there are lots of messages). This was my first step, a base that did nothing but allowed me the possibility to intercept messages and make changes.

Next I saw (by debugging my DLL in Visual Studio) that the game uses the 'enumerate device objects' feature of dinput to see what your stick can do - I intercept this as usual but feed it back a dishonest version of reality, enough to trick the game into thinking you've got a Z-axis and not a slider. From there the game was happy to work as if it was 1999 again :-)

I'm glad it works for you.

This is a well known bug of the X-series, and can be easily solved trough the launcher without installing anything.

In the launcher, select "input device" and uncheck "Use throttle"

Due the bug mentioned before, this option make the opposite of it says with most of joysticks.

In the very first X game, with my Sidewinder, I do need my patch to get the throttle to work - changing the use throttle option does nothing.

I've also just tried X:Tension but that was fine and didn't need any changes for the throttle to work 'out of the box'. So it looks like Egosoft improved the joystick code pretty soon after. (edit: X2 is fine as well)

That's interesting, because the GOG version is X: Gold, which has both X: Beyond the Frontier and the X: Tension addon, so shouldn't the GOG version run without the need for any changes, then, being as it has X: Tension?

EDIT: Ah, wait, think I just answered my own question. They are still separate installers. So is that another fix, then, to just install X: Tension over the top of X: Beyond the Frontier?

They are? But I thought X: Tension was supposed to add things to the game, like some working weapons when you first arrive in the X systems and increasing the places you can travel to (which I read as it modifying the existing BtF game and campaign)?

EDIT: Seems it is the way in which I read the X: Tension entry on Wikipedia. Re-reading it, and seeing that it is in fact a separate game, I now read the part where it talks about addressing issues like giving you weapons to begin with a little differently. Clearly it means the start of X: Tension and not the start of Beyond the Frontier. Why it gets referred to as an expansion/addon I don't know, because it is standalone and so doesn't alter the first game in any way.