This guide contains affiliate links — we may earn a commission at no extra cost to you. Verdicts are written before affiliate status is checked for any product.

Ask a long-time vJoy user about their worst sim moment and it is rarely a crash in DCS. It is the Windows reinstall, the driver update, the new PC — followed by the discovery that forty hours of Joystick Gremlin curves, UCR mappings and per-game profiles are gone, and that rebuilding them from memory takes weeks of ‘why does this axis feel wrong?’ This guide is the boring, essential fix: know where your profiles live, back them up properly once, and never rebuild from scratch again. The tool we recommend for the job is pCloud, and we explain that choice — and its free tier — honestly at the end.

What exactly you stand to lose

• Joystick Gremlin profiles. Your per-game profile files hold merged-device layouts, axis curves, response tuning, macros and mode logic. This is usually the single most valuable file set in a vJoy user’s setup.
• UCR profiles. UCR stores its configuration — profiles, plugin setups and device mappings — in its own config data alongside the application. Losing it means re-teaching UCR every device and every remapping rule.
• vJoy device configuration. The number of vJoy devices and their axis/button counts, set through the Configure vJoy tool (vJoyConf), determines whether your Gremlin and UCR profiles load cleanly at all. Note your configuration before any reinstall.
• The sims’ own controller settings. DCS keeps per-aircraft input profiles in its Saved Games configuration; MSFS stores control profiles in its own settings and cloud sync, which has not always restored perfectly. A local copy is the version you control.

Where the profiles live — the honest version

Exact folders vary by version and by where you installed each tool, so treat any guide that prints one universal path with suspicion — including this one. The reliable method is: in each app, use its own save/export or open-file-location behaviour to find where your active profile file actually sits, and check the app’s profile and config folder next to the application itself for UCR. For DCS, look in your Saved Games folder’s DCS configuration for the input profiles. Write the paths you find into a note inside the backup itself; future-you, mid-reinstall, will be grateful. What matters is not memorising locations but having one verified copy of each app’s profile and config data, plus a screenshot of your vJoyConf device setup.

The backup workflow

• Step 1 — Gather. Create one folder, for example ‘Sim Profiles Backup’, and copy into it: your Gremlin profiles, UCR’s profile/config data, your DCS input configuration, and the vJoyConf screenshot and notes file.
• Step 2 — Date it and zip it. Rename the folder with the date, then compress it into a single archive. One archive is trivial to store, verify and restore, and the date stops ‘final-v2-REAL’ confusion.
• Step 3 — Put it somewhere that is not this PC. A cloud folder that syncs automatically, an external drive, or ideally both. The failure you are protecting against — reinstall, drive swap, dead SSD — takes every local-only copy with it.
• Step 4 — Refresh after big changes. Finished a new aircraft’s profile or rebuilt your HOSAS layout? Re-zip and re-upload. Thirty seconds now, or thirty hours later.
• Step 5 — Test the restore once. On a calm day, load a backed-up Gremlin profile and confirm your axes respond. A backup you have never restored is a hope, not a backup.

Why we point readers at pCloud for this

Affiliate link: the pCloud link below is a sponsored affiliate link — we may earn a commission at no extra cost to you. See our affiliate disclosure.

The job has modest needs: automatic sync of a folder between your sim PC and the cloud, enough room for profile archives (they are small), and a restore experience that does not fight you. pCloud fits that job well, offers a free tier that is genuinely sufficient for profile and config backups of this size, and adds the option of lifetime plans for readers who dislike subscriptions — we are deliberately not quoting plan prices here, because they change and because the free tier covers the workflow in this guide. If you already use another cloud drive, use it: the recommendation that matters is the workflow above, not the logo. Where pCloud earns its place in this guide is that profile backup is a real, recurring need in this niche, and its sync client makes Steps 3 and 4 automatic once set up.

Restore order after a reinstall — do it in this sequence

Restoring in the right order saves a second round of troubleshooting. First, install vJoy itself from our download page and set your device count and axes in vJoyConf to match the screenshot in your backup — Gremlin and UCR profiles expect the same virtual devices they were built against. Second, install Joystick Gremlin and UCR, then copy your backed-up profile and config data into place before launching them for the first time, so the apps greet your old profiles rather than generating fresh defaults. Third, restore the sims’ own input configuration — for DCS, that is the input folder inside your Saved Games configuration — and only then launch each sim and confirm, device by device, that axes move the right surfaces. If a profile loads but an axis is dead, the cause is almost always a device-count mismatch from step one, not a corrupt backup.

One last discipline separates a backup from an archive: keep the last three dated versions, not just the newest. Profiles evolve as you add aircraft and re-tune curves, and the version from two months ago is sometimes the one that works after a tool update changes how a current profile loads. Storage is a non-issue — these archives are tiny — and the habit costs nothing. Combined with the way this site handles recommendations, it is the same principle applied to your own setup: boring, documented, and verified before you need it.

A final pairing note: the same backup habit protects the rest of your sim investment. The curves you tune after reading our first joystick guide, the twin-stick layout from the Star Citizen HOSAS guide and the tracking profiles from the head-tracking hub all live as files on the same PC as your Gremlin profiles — back them up together, and make sure vJoy itself is one quick visit to the download page away after any reinstall.

This guide contains affiliate links — we may earn a commission at no extra cost to you. Verdicts are written before affiliate status is checked for any product.

Every simmer reaches the same moment: the F/A-18 UFC, the A320 MCDU, the truck’s retarder and beacon switches — the controls that live on a keyboard, three menus deep, exactly when you cannot afford to look away. Button boxes exist to bring those controls back under your fingers. This guide compares the three honest routes — a Stream Deck, a ready-made sim button box, and a DIY build — and explains where vJoy fits into each, because on this site the virtual-device side of the story is half the fun.

What a button box actually buys you

Not immersion points — time and errors. In DCS, punching coordinates into a UFC or flipping through a checklist under pressure is measurably faster and less error-prone on physical, labelled controls. In MSFS, a box of toggles for lights, pumps and autopilot modes keeps your mouse free for the view. In ETS2 and ATS, the gains are everyday ones: engine brake, retarder stages, hazards, trailer attach and camera controls on real switches instead of key combinations you forget between sessions. If your sim time is relaxed GA touring with everything mouse-clickable, you may never need one. If you fly study-level aircraft or trucks seriously, the box quickly becomes the upgrade you touch most.

Route one: Elgato Stream Deck — the flexible favourite

The Stream Deck was built for streamers and adopted by simmers because its per-key screens solve the labelling problem completely: every button shows an icon or text label, pages fold hundreds of functions behind fifteen or thirty-two physical keys, and the community has published deep profile ecosystems for DCS and MSFS in particular. It is the best choice for complex aircraft, where the set of controls you need changes per module and per phase of flight, and it doubles as a general desktop controller the rest of the week.

The honest weaknesses: the buttons are identical, untextured keys, so true eyes-off operation by feel is weaker than on a box of real toggles and rotary encoders; it is a USB HID device whose sim integration often runs through plugins or keyboard emulation rather than appearing as a native joystick; and the per-key screens, while brilliant, make it the least ‘cockpit-like’ option here. None of that stops it being the recommendation for most DCS and MSFS readers — flexibility wins.

Route two: a ready-made sim button box — real switches, zero building

Dedicated sim button boxes — the generic USB boxes sold for racing and flight sims — give you what the Stream Deck cannot: chunky toggle switches, rotary encoders, push-buttons and sometimes a starter knob or gear lever, most presenting themselves to Windows as a standard game controller. That last part matters on this site: a device that appears as a joystick can be merged, curved and remapped through the vJoy ecosystem, and in truck sims a physical box of toggles is simply the most satisfying way to run lights, brakes and beacons. Quality across the generic market varies widely, so buy from listings with clear photos of the internals or strong community reviews, and prefer standard USB HID boxes over ones needing obscure proprietary drivers.

Route three: DIY with Arduino — cheapest, and it teaches you the stack

The third route is the one this site’s readers are unusually well placed to take. A cheap Arduino-class board, a handful of switches and encoders, and a feeder approach can turn a home-built panel into axes and buttons a sim can use — and the vJoy ecosystem has a purpose-built tool for exactly this: vJoySerialFeeder takes serial data from a microcontroller and presents it to Windows as a vJoy device. Our vJoySerialFeeder guide walks the chain end to end, from wiring a first button to mapping the finished panel in DCS or ETS2.

DIY is the cheapest route per button and the only one that gives you exactly your layout — a UFC replica, a truck dash panel, a bespoke switch row for one aircraft. The cost is your time: basic soldering or Dupont-wire assembly, some configuration patience, and a panel that will look homemade unless you invest in enclosures and labels. For many readers that process is the hobby, and the resulting box pairs with a Stream Deck surprisingly well — physical toggles for the fixed switches, screens for the changeable ones.

Which route for which sim

Our verdict

Buy the Stream Deck if you fly complex aircraft in DCS or MSFS — nothing else matches its labelled flexibility. Buy a ready-made button box if your sim life is trucks and racing, where the controls never change and real switches feel right. Build the DIY panel if the making appeals to you at all: it is the cheapest route, the most personal, and the one that will teach you the most about the vJoy stack you already use. Start from the download page for the driver, pair the box with a stick from our first joystick guide, and you have the control setup most simmers end up with — just arrived at deliberately.

This guide contains affiliate links — we may earn a commission at no extra cost to you. Verdicts are written before affiliate status is checked for any product.

Star Citizen is the sim that broke the old HOTAS assumption. A throttle quadrant makes sense when your ship mostly flies forwards like an aircraft; a space sim with full six-degrees-of-freedom strafing rewards something else — a second stick. That is why the community splits into HOTAS (hands on throttle and stick) and HOSAS (hands on stick and stick) camps, and why vJoy, Joystick Gremlin and HidHide became part of the standard Star Citizen control stack. This guide explains the twin-stick logic first, then the setups worth buying at each level.

Why two sticks work in space

In atmosphere, thrust is roughly one-dimensional: a throttle lever is the natural control. In Star Citizen you strafe up, down, left and right as much as you surge forwards, and those translation axes want spring-centred, instant, proportional control in your left hand — exactly what a stick gives and a throttle lever does not. The typical HOSAS layout puts strafe and surge on the left stick, pitch, roll and yaw on the right, with boost, brakes and coupled-mode toggles on the grips’ buttons. Pilots who switch from throttle to twin-stick for dogfighting rarely switch back, though many keep a throttle too for cruising, mining and salvaging, where a set-and-forget lever is genuinely more relaxing.

Whichever hardware you choose, the software stack matters as much: vJoy provides the virtual devices, Joystick Gremlin merges and curves them, and HidHide hides the raw hardware from the game so it sees one clean layout. Our Star Citizen setup guide in the games section walks that chain step by step, and the download page has the vJoy build you need.

The enthusiast answer: twin VKB Gladiators

Ask the HOSAS community what to buy and the twin VKB Gladiator setup is the consensus answer — most famously a right-hand Gladiator NXT EVO paired with the left-hand Omni Throttle variant, whose angled grip is shaped specifically to work as a space throttle-stick hybrid. Contactless sensing, a grip dense with hats and buttons, and a gimbal that stays precise under dogfighting loads make it the setup competitive pilots standardise on. Two of them cost real money, and VKB stock comes and goes by region.

The disclosure, again, because it is the point of this site: VKB has no public affiliate programme. We recommend twin Gladiators because the community’s best pilots fly them and the hardware earns it, not because the recommendation pays. Buy through VKB’s official regional stores or a marketplace listing at a sane price, and be wary of marked-up resellers.

The complete-kit answer: Logitech X52 / X52 Pro

If you want one box, one purchase and a classic HOTAS layout that Star Citizen fully supports, the Logitech X52 remains the default recommendation, with the X52 Pro as its sturdier, all-black sibling. You get a separate throttle unit with a detent feel that suits cruising and quantum travel, a stick with plenty of buttons and modes, and — underrated — more community-shared Star Citizen profiles than for any other device. The trade is the one described above: a throttle lever is a weaker strafe control than a left stick, so committed dogfighters outgrow it, while explorers, haulers and miners may never want anything else.

The budget twin-stick answer: dual T.16000M

The cheapest credible HOSAS setup is two Thrustmaster T.16000M sticks. The ambidextrous grip design is the enabler here — the same stick genuinely works in either hand — and the contactless main-axis sensing keeps precision respectable at a pair price well below the enthusiast tier. The known caveat is the twist axis, which is the wear point on this model; in a twin-stick layout both twists carry yaw and strafe duties, so heavy users should budget for the possibility of an early replacement or a future pedal addition from our pedals guide. As a way to test whether HOSAS suits you before committing to VKB money, nothing else comes close.

A note on the VelocityOne Flightdeck

Turtle Beach’s VelocityOne line is the name MSFS yoke pilots know, and its Flightdeck HOTAS is the part of that range Star Citizen players ask us about. It is a legitimate single-stick-plus-throttle option with a modern, button-rich throttle unit, and readers already inside the Turtle Beach ecosystem will find it the coherent choice. For a dedicated Star Citizen dogfighting build we still rank twin sticks above any HOTAS here — that is a layout judgement, not a quality one — but as a mixed Star Citizen and flight-sim HOTAS, the Flightdeck deserves a look at Turtle Beach’s own store.

Our verdict

Decide the layout before the brand. Pure dogfighting and full 6DOF control point to HOSAS: twin VKB Gladiators if the budget allows, dual T.16000M if it does not. Mixed play — hauling, mining, exploration with occasional combat — is honestly better served by the X52’s throttle-and-stick comfort and its ocean of shared profiles. And whichever you buy, leave room in the budget and the desk for the unglamorous parts of the stack: the software chain is free via our download page, and head tracking from our head-tracking comparison will change your Star Citizen situational awareness more than the jump between any two sticks in this guide.

You have merged your stick and pedals into one clean vJoy device — and the game is still misbehaving, because it can also see the original physical controllers sitting next to the virtual one. That is the double input problem, and HidHide is the tool that ends it. HidHide hides your physical devices from games so that only the virtual vJoy device reaches them, while your feeder software keeps full access. This guide explains the problem, the hiding concept, and the setup order that keeps everything working.

The double input problem

Consider the standard merged setup. Joystick Gremlin reads your physical stick, throttle and pedals, and writes the combined result into vJoy. The game now has two views of your hardware: the physical devices, reporting their raw inputs directly, and the vJoy device, reporting your curated, curved, merged version. If the game binds or reacts to both, the symptoms are unmistakable — an axis that fights itself because raw and curved values arrive together, buttons that fire twice, menus that scroll on their own, and bindings that seem to change between sessions as the game picks a different device to listen to.

You cannot fix this inside the game, because from the game’s side both devices are legitimate joysticks. The fix has to happen one level down: the physical devices must become invisible to the game, while remaining visible to the feeder that reads them. That is precisely HidHide’s job.

What HidHide does

HidHide is a device-hiding tool from the same ecosystem of virtual-controller software that sim players already rely on. You select the physical devices to hide, and applications no longer see them — with one crucial exception: applications you explicitly allow keep their access. That allowlist is what makes the whole pattern work. Joystick Gremlin goes on the allowed list, so it still reads your real stick and pedals and keeps feeding vJoy. The game is not on the list, so for the game the physical hardware simply does not exist — the only controller it can find, bind and react to is the vJoy device. One input path, no doubles.

This is why HidHide appears in the documented Star Citizen community stack — vJoy plus Joystick Gremlin plus HidHide — and in DCS merged setups: the hiding step is what turns a merge from ‘mostly works’ into ‘the game sees exactly one device, the one I designed’. It also shows up in Microsoft Flight Simulator discussions, where every vJoy device is named identically (‘vJoy Device’) and hiding physical clutter is one of the documented workarounds for keeping binding screens manageable.

Setup order and core steps

1. Build and verify the merged setup first: vJoy installed from our download page, Gremlin merging your devices, and the vJoy device moving correctly in the monitor. HidHide hides problems as happily as it hides devices, so the setup must be right before anything is hidden.
2. Install HidHide and restart if it asks — it works at device level, so a clean start matters.
3. In HidHide, select the physical devices to hide: the stick, throttle and pedals that Gremlin is merging. Do not hide the vJoy device itself; that is the one device the game must keep seeing.
4. Add your feeder application — Joystick Gremlin — to the list of applications allowed to see hidden devices. Skip this step and Gremlin goes blind along with the game, which presents as ‘my merge suddenly stopped working’.
5. Launch the game and open its controller bindings. Moving each physical control should now produce exactly one response: the vJoy device. If a control produces nothing, check the allowlist; if it produces two responses, check that the device is actually ticked for hiding.
6. When you play a different game that should see your physical hardware directly, remember the hiding is still in place for non-allowed applications — unhide, or allow that game, before concluding a controller is broken.

Best use case

HidHide is not a standalone improvement; it is the finishing step of a merged-device setup. Its best use case is exactly the Star Citizen and DCS pattern: multiple physical devices, one Gremlin profile, one vJoy device, and a game that must see only the result. If you use a single physical stick with no feeder and no merge, there is no double input to fix and HidHide has nothing to do. Judge it by that rule and you will never install it unnecessarily.

Limitations

• Hiding is application-wide, not game-by-game magic. While a device is hidden, every application that is not on your allowed list cannot see it — including other games and tools you might open later. Managing the allowed list is part of using the tool.
• The allowlist step is easy to forget and hard to guess. A feeder that cannot see the physical devices produces no output at all, and the symptom points at everything except the real cause. If a working merge dies after installing HidHide, the allowlist is the first place to look.
• It fixes visibility, not mappings. Wrong curves, swapped axes and bad merges stay wrong. HidHide only decides which devices an application can see; the quality of what vJoy reports is still your profile’s responsibility.
• It depends on the stack beneath it. HidHide assumes vJoy and your feeder are installed and working. It is the last piece fitted, never the first.

Next steps: start from the download page if the driver is not in yet, see where HidHide sits among the feeders in the vJoy feeder tools hub, and read the sibling guide it completes — Joystick Gremlin — since hiding only makes sense once something is merging your devices.

This guide contains affiliate links — we may earn a commission at no extra cost to you. Verdicts are written before affiliate status is checked for any product.

Head tracking is the single upgrade flight and truck simmers describe as transformative, and it is also the one with the widest price spread in all of sim gear: the same job — looking around by moving your head — can cost nothing at all or several hundred dollars. This comparison walks the ladder honestly, starting with the free rung, because a large share of readers should stop there. vJoy readers meet head tracking through OpenTrack in particular, since OpenTrack setups often sit alongside vJoy and feeder apps in community configurations, so we cover that chain carefully.

Rung one: OpenTrack with a webcam — free, and better than you expect

OpenTrack is free, open-source software that turns head movement into sim camera movement. Paired with its neural-network face tracker and an ordinary webcam, it needs no hardware purchase at all, and for MSFS touring, truck sims and general DCS flying it is startlingly capable. The costs are your time and some tolerance: you will spend an evening tuning curves and smoothing, lighting in your room affects tracking quality, and very fast head movements in a DCS dogfight can lose the lock where dedicated hardware would not.

Before buying anything, run this setup for two weeks. Our head-tracking hub links the OpenTrack setup guides, including how OpenTrack output chains through FreePIE and vJoy in community setups. If free tracking satisfies you — and for many readers it genuinely does — you have saved the full price of the hardware below and lost nothing.

Rung two: Delanclip — the OpenTrack-native paid upgrade

Delanclip is a small UK shop that sells infrared LED clips and modified PS3 Eye cameras built specifically for the OpenTrack style of tracking. Where face tracking infers your head position from an image, an LED clip gives the software three bright, unambiguous points to follow, which translates into tracking that stays locked through fast movements, works in dim rooms, and feels noticeably more precise in a fight. For readers who have already chosen the OpenTrack path, this is the recommendation we make most often: it fixes the free setup’s real weaknesses without abandoning the software you have learned.

Full disclosure: Delanclip has no public affiliate programme and we earn nothing from recommending them. The link below is a plain link to their shop. They are in this guide because, for OpenTrack users, they are the right answer — the trust-anchor pick of this comparison.

Rung three: TrackIR 5 — the dedicated-hardware standard

TrackIR 5 from NaturalPoint is the long-standing dedicated standard: a small camera on your monitor tracks reflectors (or an active LED clip) on your headset or cap, with mature software, high update rates and a profile ecosystem built over many years. Its strengths are consistency and polish — it behaves the same in every supported sim, sips system resources, and simply disappears into your setup. Its weaknesses are the flip side of its age: it is a wired, wear-something solution at a premium price, and its value depends heavily on your sims supporting it natively, which the major flight titles do.

NaturalPoint runs no public affiliate programme, so TrackIR reaches this guide through Amazon. If you want the set-and-forget dedicated option and your main sims are DCS, MSFS, IL-2 or the truck sims, this remains the safe, boring, correct purchase.

Rung four: Tobii Eye Tracker 5 — nothing on your head

Tobii takes a different technical route: a bar under your monitor tracks your head and your eyes, with nothing worn at all. In sims with official Tobii support, gaze-aware camera behaviour feels remarkably natural — you look toward a target and the view leans with you — and for glasses wearers and readers who hate wearing a clip, it removes the main friction of the other paid options. It is the premium rung of this ladder, and the price reflects that.

The honesty notes matter here. Tobii’s experience depends on per-game support more than TrackIR’s does: where a sim implements Tobii head tracking well (Star Citizen, MSFS and Elite Dangerous are the showcase titles), it is superb; where support is partial, you may fall back to head-only behaviour or community workarounds. Check your main sims against Tobii’s supported-games list before buying. Tobii also needs reasonable seating position relative to the bar, which very deep-desk or multi-monitor-arc setups should verify.

Per-game support, honestly

Two cautions apply to the whole table. First, support changes with sim updates, so confirm your exact titles before spending on the premium rungs. Second, OpenTrack’s flexibility is also its caveat: because it can output through several protocols, a route that works today may need re-tuning after a sim patch, whereas the dedicated devices’ native support is the publisher’s problem to maintain.

Our verdict

Start free with OpenTrack and a webcam — no exceptions; it is the correct first step for every reader of this site. If you love the software but want it locked-in and precise, buy a Delanclip setup and stay on OpenTrack. If you want dedicated hardware that every major sim supports natively with zero tinkering, buy the TrackIR 5. If wearing anything is a deal-breaker and your main sims officially support it, the Tobii Eye Tracker 5 is the premium pick. Pair whichever rung you choose with a stick from our first joystick guide, and keep vJoy from the download page underneath it all for the axis merging and mapping your setup will inevitably need.

This guide contains affiliate links — we may earn a commission at no extra cost to you. Verdicts are written before affiliate status is checked for any product.

Rudder pedals are the most postponed purchase in flight simulation, and often the most misunderstood. A twist stick already gives you a yaw axis, and vJoy can map almost anything to rudder — a racing pedal, a second stick, even keyboard keys smoothed through Joystick Gremlin. So do you actually need dedicated pedals? Sometimes yes, sometimes honestly no. This guide answers that question first, then compares the four pedal sets worth your money if the answer is yes.

When a twist stick is genuinely enough

If you mostly fly modern airliners in MSFS, your rudder workload is taxiing, the occasional crosswind correction and coordinated turns the flight model largely handles for you. A twist grip covers that comfortably, and your money is better spent on head tracking or a throttle. The same is true for relaxed GA touring and for space sims, where the twist axis is usually repurposed entirely. Plenty of long-time simmers never buy pedals and miss nothing.

When pedals change the experience

• Taildraggers and warbirds. DCS warbirds, the Spitfire and Mustang especially, demand constant, fine rudder work on take-off and landing. A twist grip couples rudder into your pitch and roll hand at the worst possible moment; pedals separate the axes and make ground handling learnable.
• Helicopters. Anti-torque control is a continuous, precise foot job in DCS and MSFS helicopters. Pedals are close to mandatory for enjoyable rotor flying.
• Crosswind landings and slips. Holding a forward slip or de-crabbing in a gusty crosswind needs independent, sustained rudder deflection that a springy twist axis makes exhausting.
• Toe brakes. Differential braking transforms ground handling in warbirds and GA aircraft. Only pedals with toe-brake axes give you that — a real functional difference, not a luxury.

One more honest route before you spend: if you own racing pedals, try them as rudder first. Using vJoy and a feeder app you can combine the clutch and accelerator into a single yaw axis, and many readers discover that is all the pedal they need. Our setup guides linked from the download page explain the merging concept, and it costs nothing to test for a weekend.

Logitech G Flight Rudder Pedals — the default recommendation

For most buyers, this is the set to get. The Logitech G Flight Rudder Pedals combine a wide, stable stance, adjustable pedal tension, smooth self-centring rudder action and — critically — proper toe brakes on both pedals. They are heavy enough to stay put on most floors, the axis resolution is more than adequate for warbird work, and the enormous user base means profiles and fixes exist for every sim. Build is mostly plastic, which is the fair trade at this tier: you are paying for correct function and toe brakes, not for metalwork.

Thrustmaster TFRP — the budget option, with clear limits

The Thrustmaster Flight Rudder Pedals (TFRP) are the low-cost way into dedicated pedals, sliding on rails with toe brakes included, and they pair naturally with the T.16000M ecosystem many first-time buyers already own. The compromises are real: the rail mechanism is narrower and less smooth than the Logitech set, the pedals sit close together, and carpet grip is mediocre without a mat or stop. If the price gap is small, buy the Logitech pedals instead. If the TFRP is substantially cheaper where you live, it is a legitimate budget buy that still unlocks proper warbird and helicopter control.

VKB T-Rudder — the precision single-axis specialist

The VKB T-Rudder takes the opposite approach to almost every rival: it does one thing — the rudder axis — exceptionally well, with an all-metal mechanism, contactless sensing and a compact up-down pedal motion that works beautifully under a desk and even with an office chair. There are no toe brakes, and that is a deliberate design choice, not an oversight: VKB expects braking to be handled by a button or a combined axis in the sim, which DCS supports well. Helicopter pilots and warbird purists who value axis quality over toe brakes rate these among the best pedals at any price. VKB runs no public affiliate programme, so the link below is a plain link to VKB’s official store — we recommend these because they are excellent, not because they pay.

Turtle Beach VelocityOne Rudder — the ecosystem pick

If you already fly with Turtle Beach’s VelocityOne Flight yoke system, its matching rudder pedals are the tidy option: they were designed to complete that ecosystem, with toe brakes, swappable pedal styles for GA versus airliner flying, and a wide, planted stance. As a standalone purchase for stick-and-throttle users they are harder to single out over the Logitech set on value, but VelocityOne owners get a coherent, well-matched setup, and the pedal feel is a genuine step up from the budget tier.

Our verdict

Start by not buying anything: test your twist stick, and if you own racing pedals, test those through vJoy for a week. If dedicated pedals earn their place, most readers should buy the Logitech G Flight Rudder Pedals for their balance of toe brakes, tension adjustment and price. Choose the TFRP only at a clear discount, the VKB T-Rudder if axis purity matters more than toe brakes, and the VelocityOne Rudder if you are building inside the Turtle Beach ecosystem. Then finish the control picture with our first joystick guide and the head-tracking hub — pedals, stick and looking around freely are the three upgrades that together make a sim feel real.

Every feeder you have ever used, from Joystick Gremlin down to a twenty-line script, talks to vJoy the same way: through vJoyInterface.dll, the interface library the vJoy SDK documents and ships. If you can write a little code, you can write your own feeder, and the Python wrapper pyvjoy makes that first feeder an afternoon project rather than a systems-programming expedition. This guide explains what the SDK actually contains, how pyvjoy relates to the DLL underneath it, the one version-matching rule that decides whether your code works at all, and a sensible first project that proves the whole chain from your script to a game.

What the SDK ships

The vJoy SDK is the developer side of the same releases everyone else installs as a driver. It provides the vJoyInterface library in forms for C, C++ and C# developers, headers and documentation describing the interface functions, and demo feeder programs that show a complete, minimal write cycle: check the driver is present and enabled, acquire a device, write axis and button values, then relinquish the device cleanly. Those demos are the most valuable part of the package for a beginner, because they are known-good callers. When your own code fails, running the demo feeder separates a broken installation from a broken program instantly, which is the same diagnostic discipline as testing in joy.cpl before blaming a game.

The interface model in plain terms

Conceptually, vJoyInterface.dll exposes a small set of jobs. You ask whether a vJoy driver exists and which version it reports. You ask whether a specific device ID exists and whether it is free. You acquire that device so no other feeder fights you for it. Then you write values: axis positions across the device’s enabled axes, button states, and POV hat positions, either field by field or as a complete position block. Finally you relinquish the device when your feeder exits. Everything a feeder does, including respected tools like Joystick Gremlin and UCR, reduces to variations on those jobs. The virtual device itself, its ID, axes, buttons and POV count, is still defined beforehand in Configure vJoy. Your code writes values; it does not design the hardware.

pyvjoy: the Python wrapper

pyvjoy is a Python wrapper around vJoyInterface.dll. That sentence carries the two facts beginners miss. First, pyvjoy does not replace the DLL or the driver: it needs a working vJoy installation underneath, with the DLL available, because every call it makes lands in that native library. Second, because it is a wrapper, its programs follow the same model as the SDK demos, expressed in Python: create a device object for a chosen device ID, set axis values with the library’s expected value range, set and reset buttons by number, and let the object clean up on exit. The result is that a Python script can feed a game from sources Python is good at: serial data, network messages, sensor boards, computer vision output, or your own automation logic.

1. Install vJoy itself first and configure a device in vJoyConf with the axes and buttons your script will write.
2. Verify the device exists in joy.cpl and responds to the SDK demo feeder or another known feeder.
3. Install pyvjoy in your Python environment and run a minimal script that acquires your device ID and moves one axis.
4. Watch that axis in JoyMonitor while the script runs. Only extend the script once that single movement is reliable.
5. Add buttons, then further axes, testing each addition, and make sure the script relinquishes the device when it ends.

The version-match rule

One rule governs all of this, for SDK code and pyvjoy alike: the driver and the DLL must come from the same release. The classic vJoy error, driver version does not match DLL, exists because a feeder shipped or loaded a vJoyInterface.dll from one release against a driver installed from another, such as a 2.1.8 DLL against a 2.1.9 driver. When you develop, be deliberate about which DLL your program loads, keep it with your project, and record the driver build it was tested against. When you distribute a feeder, ship or reference the DLL that matches the driver you tell users to install, and state that build in your instructions. Most support pain in this ecosystem is this single rule, ignored.

A sensible first project

Build a feeder that does one thing observably. A good first project reads a single real input you already own, perhaps a slider, a serial dial, or simply your script’s own slowly sweeping value, and writes it to one axis of device 1. Run it beside JoyMonitor and watch the axis track your input. Then add a button toggled by a key press. That tiny program exercises acquisition, axis writes, button writes and clean release, which is ninety percent of what larger feeders do. From there, realistic growth is obvious: read an Arduino over serial and you have reinvented the idea behind vJoySerialFeeder; add curves and merging and you are walking toward Joystick Gremlin’s territory with a proper appreciation of what it does for you.

Common mistakes

• Treating pyvjoy as the driver. Import errors aside, pyvjoy cannot work without vJoy installed and a device configured. Install and configure first.
• Acquiring the wrong device. Your code, vJoyConf and your test game must all agree on the device ID.
• Writing to axes that are not enabled. The device shape comes from vJoyConf. Enable what you write.
• Never relinquishing the device. A crashed or careless feeder that keeps a device acquired blocks the next feeder. Handle exit cleanly.
• Mixing SDK and driver versions. Same release for driver and DLL, recorded in your notes and your readme.
• Testing first inside a game. Test in JoyMonitor. The game is the last witness, not the first.

Frequently asked questions

Which language should I use? Use what you know. The SDK serves C, C++ and C# directly, and pyvjoy makes Python a first-class feeder language for scripts and hardware experiments. Can my feeder create devices? No. Devices are defined in Configure vJoy. Your feeder acquires and writes to existing devices. Can two of my scripts share one device? They would fight over values and one may fail to acquire it. Give each feeder its own device ID. Is vJoy an XInput device for my game code? No. vJoy devices are DirectInput. If your project needs an Xbox-style virtual pad, that is a different layer entirely, and recognising the boundary early will save your design a rewrite.

Keep going

Start from the vJoy download page if you need the installer again, and use the vJoy Setup hub as the index for this whole cluster. Two guides that pair naturally with this one are How to Use vJoy: Feeders Explained and Configure vJoy with vJoyConf. Read them in that order if you are building a setup from scratch: download choice first, installation second, configuration third, and only then time inside a game or simulator. That order prevents the most common wasted hour in this niche, which is debugging a feeder or a game for a driver problem that was visible in Windows all along.

Searches for a GameCube controller on PC often assume a single driver will do the whole job. The vJoy reality is more specific, and understanding it first will save you a frustrating afternoon. vJoy is a virtual joystick driver for DirectInput. It does not read any physical controller by itself. For a GameCube controller to reach a game through vJoy, two other pieces must exist: an adapter that connects the controller to the PC and presents it to Windows in some readable form, and a feeder application that reads that controller state and writes it to a vJoy device. If either piece is missing, vJoy has nothing to carry.

Why route a controller this way at all? Usually because the target game or emulator setup expects a standard joystick device, or because the player wants remapping, curves or button changes that a feeder provides on the way through. UCR is the feeder most readers use for this pattern, because its job is exactly that: take an input device, remap it, and output to vJoy as its DirectInput provider. When the adapter presents the GameCube controller as a readable DirectInput device, that chain can work well. When it does not, no setting inside vJoy will rescue it, because the problem sits before vJoy in the chain.

What you need

• A GameCube controller and a PC adapter for it. Adapters differ in how they present the controller to Windows, so the adapter’s own documentation and mode settings are part of this setup, not an afterthought.
• vJoy from our download page — BrunnerInnovation 2.2.2.0 first on Windows 10 and Windows 11, with 2.1.9.1 as the fallback if the feeder misbehaves on 2.2.x.
• A feeder that can read your adapter’s output and write to vJoy — UCR is the documented pattern here; see our UCR (Universal Control Remapper) guide for its vJoy output provider setup.
• A game or application that accepts a DirectInput joystick, since the vJoy device at the end of the chain is a DirectInput device and does not emulate XInput.

Setup, step by step

1. Connect the adapter and controller, then check how Windows sees them before installing anything else. Open joy.cpl and any adapter utility the maker provides. Move the sticks, pull the analogue triggers and press every button. If Windows shows no device, or a device whose inputs do not move, stop and fix the adapter layer first — try its alternate mode if it offers one, a different USB port, and its documented driver steps.
2. Install vJoy and create one virtual device in Configure vJoy with enough buttons for the controller’s face buttons, shoulders, Start and D-pad functions, plus axes for both sticks and the analogue triggers where your mapping plan needs them. The per-device ceiling of up to 8 axes and up to 128 buttons is far beyond this controller’s needs.
3. In UCR, create a mapping from the physical controller to the vJoy device: main stick to X and Y, the C-stick to a second axis pair, triggers to axes or buttons according to what your target game handles best, and face buttons one to one. Keep the first mapping literal; clever remaps come after the plain one works.
4. With the UCR profile active, open joy.cpl, select the vJoy device, and press everything again. Every physical input should appear once, on the virtual device, in the place your mapping says. Ghost inputs at this stage usually mean the game will later read the physical device as well as the virtual one, so note which inputs duplicate.
5. In your game, bind the vJoy device and, where the game allows it, ignore or unbind the physical controller to prevent double input. Bind movement first, test in a menu or safe area, then add the remaining buttons.
6. Play-test something you know well. Familiar timing exposes input problems that a test screen hides: a trigger that engages late, a stick with a dead centre, or a button that fires twice will all show up within minutes in a game your hands already understand.
7. Save the UCR profile and note the adapter mode you used beside it. The adapter mode is part of the setup; a profile that works in one mode may read nonsense in another.

Latency, stated plainly

Every layer adds some delay: adapter, feeder, virtual device, game. In a correctly working local chain the added delay is small, and for most games most players will not find it the limiting factor — but this page will not promise a number we have not measured on your hardware, and players of timing-critical games should test honestly rather than trust reassurance. If inputs feel late, shorten the chain before tuning it: check whether your game reads the adapter directly just as well, because the best vJoy setup is the one you actually need, and sometimes the direct connection is the right answer.

Alternatives if the chain does not fit

If your adapter presents the controller cleanly to Windows and your game binds it directly, use the direct path and skip vJoy entirely. If your target expects an Xbox-style XInput controller, understand that vJoy does not emulate XInput; a separate XInput-emulation layer such as x360ce is the tool family built for that translation, which is a different chain from the one in this guide. And if your adapter only works inside one specific emulator’s native support, that native support will usually beat a general feeder chain for that emulator.

Browse the vJoy setup guides by game hub for the simulator-focused guides, work through the UCR (Universal Control Remapper) guide before remapping, and see our vJoy for Assetto Corsa setup for another feeder-driven device project.

Which vJoy build should you download is the first real decision in any vJoy setup, and the internet makes it harder than it needs to be by treating three different releases, from three different maintainers, as if they were interchangeable files with the same name. They are not. This page lays out the lineage honestly, gives you a decision table based on your operating system, force feedback needs and feeder compatibility, and lists the verified file sizes and SHA-256 hashes for all three builds so you can prove the file on your disk is the file this page is talking about. Decide here once, then install with confidence.

The lineage in one paragraph

vJoy began with Shaul Eizikovich. The original line ended at 2.1.9.1, attestation-signed for Windows 10, with the same file distributed through SourceForge and the jshafer817 GitHub asset. Benjamin, known as njz3, then forked the code to work on force feedback, producing the signed 2.2.1.1 release with multi-device FFB fixes. BrunnerInnovation followed with 2.2.2.0 in December 2023, the newest release of all, signed with an EV certificate and attestation signing, and the only build that explicitly claims both Windows 10 and Windows 11 support. Newer number does not automatically mean right for you, but now you know who made each build and why it exists.

The decision table

Two rows deserve emphasis. The Windows 11 row is not a preference: njz3’s own README directs Windows 11 users to BrunnerInnovation 2.2.2.0, which tells you how the maintainers themselves see the tracks. The fallback row is equally real: at least one feeder vendor, TJoy, documents 2.2.x as only partially supported, so a feeder that works perfectly on 2.1.9.1 and misbehaves on 2.2.x is giving you information, not an error to fight. Choose the build your feeder supports, and let operating system decide only among the builds your feeder tolerates.

Verified files and hashes

These hashes were verified from the actual upstream files. Download from the vJoy download page, compare the size first because it is instant, and compare the SHA-256 when the choice matters, which for a kernel driver is always. A mismatch means the file is not the release in this table, whatever its name claims. Replace it rather than installing it. Note also what no build in this table does: none of them emulates XInput, and all of them present DirectInput devices that a feeder must write to. Build choice changes signing, vintage and force feedback work, not that fundamental model.

Not this vJoy: the Headsoft disambiguation

One confusion poisons search results and must be separated out. Headsoft VJoy is a different product by a different author, Ben Baker. It is version 1.2, it ships alongside FaceTrackNoIR, and it offers a much smaller device, described as 2 devices with 32 buttons. It shares a name with the vJoy this site covers and almost nothing else: different author, different code, different capabilities, different purpose. If a guide mentions FaceTrackNoIR bundles or a 1.2 version number, it is talking about Headsoft’s tool, and its instructions, downloads and limits do not apply to the Shaul-lineage vJoy in the table above. Check which product a page means before following it, especially when a download is involved.

Licence, stated carefully

You will see confident one-word licence claims about vJoy around the internet. Resist repeating them. The sources conflict: SourceForge lists the project as Public Domain, while the GitHub repositories carry MIT tags. The honest statement is that qualified picture, and it is what this site publishes. Anyone who tells you a single tidy licence label for every vJoy distribution is simplifying past the evidence. For practical purposes the builds above are free to download and use from their upstream sources, and the hashes in this guide let you be certain you have those exact releases.

Frequently asked questions

I am on Windows 11 and my feeder is old. Which risk do I take? Install 2.2.2.0 first because it is the signed Windows 11 build, test the feeder thoroughly in JoyMonitor, and fall back to 2.1.9.1 only if the feeder demonstrably misbehaves. Can I install two builds side by side? No. One driver is installed at a time; switching means uninstall, reboot, install. Is 2.2.1.1 newer than 2.1.9.1 but older than 2.2.2.0? Yes, that is the order, and the middle build exists for its force feedback work rather than as a general stepping stone. What about even older versions? The 2.1.8 line served Windows 7 through Windows 10 version 1803 and belongs in an archive, not on a current machine.

Keep going

Start from the vJoy download page if you need the installer again, and use the vJoy Setup hub as the index for this whole cluster. Two guides that pair naturally with this one are How to Install vJoy on Windows 11 and How to Install vJoy on Windows 10. Read them in that order if you are building a setup from scratch: download choice first, installation second, configuration third, and only then time inside a game or simulator. That order prevents the most common wasted hour in this niche, which is debugging a feeder or a game for a driver problem that was visible in Windows all along.

IL-2 Sturmovik players run into a counting problem. A warbird cockpit wants a stick, a throttle quadrant with several levers, rudder pedals, perhaps a button box — and the simulator’s willingness to juggle many separate controllers becomes the bottleneck long before the pilot runs out of USB ports. The vJoy answer is merging: read the physical devices with a feeder such as Joystick Gremlin or UCR, combine the controls you need into fewer virtual devices, and let IL-2 bind those. One vJoy device can carry up to 8 axes, up to 128 buttons and up to 4 POV hats, and vJoy supports up to 16 virtual devices as a documented limit, so a merged layout has real headroom when it is planned instead of improvised.

Merging also buys consistency. Instead of remembering which quadrant lever landed on which device number after a hardware change, you document one virtual layout and keep it stable while physical gear changes underneath. Gremlin handles curves and button logic on the way through, which suits IL-2 aircraft where a softer pitch centre and carefully placed radiator, mixture and trim controls make long flights calmer.

What you need

• vJoy from our download page — BrunnerInnovation 2.2.2.0 first on Windows 10 and Windows 11, 2.1.9.1 as the fallback if a feeder misbehaves on 2.2.x.
• Joystick Gremlin for merging and curves — see our Joystick Gremlin guide — or UCR for remapping, covered in our UCR (Universal Control Remapper) guide. Choose one feeder for the merge and stay with it.
• All physical devices tested in Windows first, with a written inventory: device, axes, buttons, and the IL-2 function each will own after merging.
• For head tracking, the OpenTrack chain described in our OpenTrack and FreePIE head-tracking chain if you plan to look around the cockpit through a vJoy-linked setup.

Setup, step by step

1. Install vJoy and, in Configure vJoy, create the first virtual device with the axes for your primary flight controls: stick X and Y, throttle, and rudder are the usual starting four. Keep a second device in reserve rather than creating it on day one.
2. In Gremlin or UCR, map the physical stick to vJoy X and Y, the main throttle lever to a vJoy axis, and the pedals to another. Activate the profile and confirm every axis in joy.cpl, full travel, both directions.
3. Add the secondary quadrant levers — propeller pitch, mixture, radiators where your aircraft and your hardware support them — to the remaining vJoy axes. Write the final virtual layout down; this document is now the source of truth for binding.
4. Shape pitch and roll curves in the feeder for a calmer centre. Warbird flying involves long periods of small corrections, and a curve you trust reduces pilot-induced oscillation on approach. Shape in the feeder only, not in both feeder and game.
5. Decide on visibility: if IL-2 also reads the raw physical devices, duplicate inputs can fight the merged ones. Where needed, use the hiding approach described in our HidHide guide so the game binds the virtual layout you documented.
6. In IL-2, bind the vJoy device controls group by group — primary flight controls, engine controls, then buttons for gear, flaps, brakes and weapons systems. Test each group in a quick mission before binding the next.
7. If you hit the practical device ceiling again as the cockpit grows, add the second vJoy device deliberately for a defined group — for example all button-box functions — and document it the same way. Planned devices stay understandable; accidental ones do not.
8. Back up the feeder profile and export or photograph the IL-2 assignments. A merged cockpit represents hours of decisions, and the backup is what makes a Windows reinstall a nuisance instead of a disaster.

Head tracking through the OpenTrack chain

Looking around is half of warbird situational awareness, and community setups commonly run head tracking through an OpenTrack chain in which FreePIE and vJoy can carry the resulting axes. Our OpenTrack and FreePIE head-tracking chain explains that chain link by link, including the honest point that OpenTrack does not require vJoy in every configuration. Treat tracking as a separate subsystem from the HOTAS merge: get the flight controls bound and stable first, then add tracking, so a problem in one system cannot masquerade as a problem in the other.

Limitations

Merging concentrates risk as well as controls. If the feeder profile is not running, IL-2 sees quiet virtual devices and the cockpit appears dead, so build a launch order habit: feeder first, game second. Device numbers also matter — if Windows enumeration changes after a major hardware swap, check the feeder mapping before rebinding the game. And a merged setup cannot extend a device that is physically worn out; test raw hardware in joy.cpl with no feeder active when an axis misbehaves.

Return to the vJoy setup guides by game hub for the full list, and read our vJoy for DCS World setup — the merging discipline transfers directly between the two simulators.