All Activity

For those of us on budgets: A few ikea legs, and what look to be chain link fence brackets. https://www.reddit.com/r/hotas/comments/16erpib/diy_stowaway_mounts/ This one uses "a reclining camping chair, 2 drawer slides, a big hinge and some square tube with plastic corner you can hammer them together (storage shelving) and rivit them up" I think I also see two crosspieces at top and bottom for stability. https://www.reddit.com/r/hotas/comments/1nghiiq/more_detailed_video_of_my_stow_away_mid_joystick/

Activating turbo mode caused the game to have a constant stutter like it was running at half frames.

The transmit power setting from the mission editor is not transferred to the jet. This setting can be set in the mission editor through the 'DATALINKS' tab -> SETTING -> Transmit Power. The mapping seems to be off: None in ME results in HI in the jet Low in ME results in MED in the jet Medium in ME results in LO in the jet High in ME results in MED in the jet This is quite important because whenever one expects a High power setting to be transferred from the mission editor, in reality Medium will be loaded. Potentially negatively impacting the datalink network. tndl_transmitpower_me_transfer.trk

I'll talk mostly within the scope of the F-4E. But, usually the primary reason is money. To be clear. The APQ-120 was actually upgraded, up to a v9, I believe. But, given a certain budget, you can spend that money upgrading old airframes to fit the new radars (It's not just a matter of swapping dishes, often the radar is designed to fit the airframe not only in terms of size but things like power draw, and the weapons control systems) or you can just shove the new tech into a new airframe. Of course, you have to realize that these are old airframes that might be reaching retirement anyway, with increasing maintenance costs. The ones who continued to update the old airframes are usually the ones that can't really confidently meet the upfront cost of new ones. So, you're only left with the option of upgrade.

NOT not load any mod!I just loaded a Cold War Germany mission from the mission editor and gave up after more than six minutes without completing it.

Partially because it’s reflecting the sky in those colors too. It’s one of those challenging light effect painting madness things.

I would just mail them my credit card for the option of multi-player campaigns, be it you and a buddy in two A-10s, or me and my best buddy in our 14B or manning the Apache.

Thank you for doing their work for them. They clearly can’t.

Home Made? Wow!, you could make some great side money!

I also think the AI "bingo" response is broken, and has been for a long time. Bingo is the state at which you RTB, not ten seconds from flameout. It'd be far better if we could set bingo level for the AI. Once it hits that level, it should ignore everything (disengaging from the fight if it has to), restrict afterburner, go to max range flight parameters, and head to the nearest compatible friendly airfield, or to the nearest tanker. Yes, that'd get it killed in a fight, but so would running out of gas (a real pilot could probably keep fighting and then just try to punch out over friendly territory, but AI needs a simple procedure).

There's a surprising number of : lines in there... On your post: Is that from the ME or from a launcher? I just tried opening a(n admittedly simple) mission on the Marianas map (no previous missions loaded) & it took 9 sec to open the mission editor, and 22 seconds to get from the ME to the cockpit. Have you any mods installed?

Do you have the CC vehicle as part of the group? I fell like I had the same issue, but it’s been a while.

This isn’t a script error. This is a fault with the thrustmaster code. Either you haven’t updated the firmware or the target software or both. Search the thread for “filter”. I am not Thrustmaster support and I am not going to respond to these queries in future. If you look back through the posts you will find that all of these questions are related to the installation of the Thrustmaster software, or mismatched firmware and software. Not the script.

I would be shocked if they specifically test ANY graphics card before releasing an update (let alone "fully testing" them). Any issues that show up on whatever graphics cards the devs and internal testers or external beta testers would get caught, but there are too many possible graphics cards and combinations of cards and other hardware combos to make any specific testing of graphic cards basically impossible. There could be a problem with that particular card or combo of it with other hardware because super long load times are not common and are usually caused by having DCS on a slow drive (not your case since you're on an SSD) and/or AV software.

Hey OizO, I think these are devices that can be detected but are not as you do not have them. I get the same thing no issues tho..

Update on DCS-Anywhere Following up on my original announcement of DCS-Anywhere, I’d like to share the progress made since release and address some of the common questions raised in this thread. Major Improvements Headless/Console Mode: The HID Manager can now run entirely without a GUI, making it ideal for headless systems such as Raspberry Pi panel hubs or dedicated Linux boxes. Statistics (frame rate, bandwidth, average UDP frame size) are continuously updated in the console. Parallelized I/O Path: The architecture was refactored so USB HID reads and writes are handled by independent threads. This eliminates contention and ensures deterministic throughput even under high load. Each connected device has its own dedicated TX worker, allowing true parallel fan-out of DCS-Bios traffic to multiple devices. Proven Scaling on Raspberry Pi: In stress tests with 9 simultaneous CockpitOS devices on a Raspberry Pi 4, the system operated without CPU saturation and DCS itself kept pace flawlessly. This validates the approach for large multi-panel rigs where traditional COM-port methods struggle. Device Discovery and Multi-Board Support: The HID Manager automatically enumerates all ESP32 devices sharing the configured VID/PID. Distinct serial numbers allow unique identification and reconnection tracking. No per-device configuration is required. VID/PID Consistency: One recurring question was why some ESP32-S3 boards did not appear in the devices table. The root cause was mismatched VID/PID values (e.g. boards with dual USB ports or external bridges such as CH340). This has been clarified in the docs: simply ensure that the values in settings.ini match those defined in your sketch’s Config.h. Cross-Platform Validation: The Python HID Manager has been exercised on Windows, Linux, macOS, and multiple Raspberry Pi variants. CPU load remains negligible (<1% on ARM), and the HID/UDP bridge operates identically on all platforms. Frequently Asked Scenarios Mixed Arduinos and ESP32s: Confirmed to work without conflict. DCS-Bios multicasts its data; any component (Arduino serial, ESP32 HID, or even custom listeners) can subscribe simultaneously. Raspberry Pi as a “Panel Hub”: Fully supported. Plug ESP32-based panels into a Pi via USB, run the HID Manager, and the Pi bridges UDP traffic to DCS. No drivers, no COM ports. The Pi itself is not a cockpit device; it acts purely as a host/bridge. Headless Operation (previously requested): Now implemented. You can run the HID Manager in console mode (--console or --headless) with full statistics and logging, suitable for daily unattended use on embedded hosts. Relation to CockpitOS Some of you noted in this thread that CockpitOS was mentioned alongside DCS-Anywhere. To clarify: DCS-Anywhere is the lightweight, transport-layer bridge. It demonstrates how to run ESP32-based panels anywhere on your network using HID + UDP. CockpitOS Firmware Project (link) is the full avionics-style framework built on top of the same HID manager. It is a comprehensive firmware suite designed for ESP32-S2/S3-based panels and supports: Auto-generated mappings for selectors, rotaries, LEDs, and displays directly from DCS-Bios JSON. Unified LED control (GPIO, PCA9555, WS2812, TM1637, HT1622, etc.) under a single API. Deterministic, real-time input handling with exclusive-selector group logic and USB HID/DCS command throttling. Data-driven panel definitions that minimize the amount of C++ a user needs to write—ideal for non-programmers wiring hardware panels. High-reliability engineering practices: static memory allocation, deterministic loop execution, zero dynamic heap usage, and O(1) lookup systems. In short: DCS-Anywhere is the bridge, CockpitOS is the full aircraft-grade panel firmware environment. If you’re interested in scaling beyond a handful of devices into entire cockpits, CockpitOS is worth exploring. Closing The updated DCS-Anywhere release is available here: https://github.com/BojoteX/DCS-Anywhere Thanks to everyone who tested, asked questions, and pointed out corner cases. The feedback directly shaped the new features. I’ll continue to refine both DCS-Anywhere and the broader CockpitOS framework based on real-world use in pits. Happy flying, and keep building. —bojote

Depends on the set up. I'm using this as I have a desk mount. https://www.monster.tech/en/product/winwing-panel-holder-v2/

I think it's a bug in a DCS WORLD update, and it only affects certain CPUs or graphics cards. My graphics card is AMD 6700XTT. Others have mentioned similar issues: unbearably long game loading times My other computer has an NVIDIA 3070 TI graphics card, and I don't experience this issue. Therefore, I suspect this is related to your company not fully testing AMD graphics cards when releasing the update.

Minimal reproduction I found: start right then left reset fcs (necessary) flaps up (necessary) shutdown right then left (necessary) start right then left Leading edge flaps are asymmetric, FCS BIT won't pass. If either: flaps are down during shutdown or left engine is shutdown first or SVs are crossed out during shutdown the FCS will be ok. Some tracks w/o mods, on Caucasus buit-in instant mission to support above & debugging attached. Hope this helps to put this 6yo bug to rest. @BIGNEWY f18-rl-fup-norst-fdown-rl-rl-ok.trk f18-rl-rst-fup-fdown-rl-rl-ok.trk f18-rl-rst-fup-lr-rl-ok.trk f18-rl-rst-fup-rl-rl-asymmetric-lef.trk

I think it's a bug in a DCS WORLD update, and it only affects certain CPUs or graphics cards. My graphics card is AMD 6700XT. Others have mentioned similar issues: unbearably long game loading times.

I meant to add that I simply love this map. For me, it brings back a lot of memories of the time, the place, and the mood of that era. Flying around the map in an A-10 makes me appreciate what the real A-10s we used to see zooming around all the time on our exercises near Wildflecken.

Thank you, I just wanted a quick verification that the DLSS swapper worked (which it did) and the Nvidia Driver didn’t overwrite it somehow. (Which it didn’t). I guess there are several paths to success.

Why won't the OpenXR toolkit work? You can also use Quad Views (Quad-Views-Foveated) which enables turbo mode by default. Note, you can unselect "Quad Views" in the DCS settings with QVF installed (if you don't want to use quad views, although depending on your specs quad views may give you a performance bump) and turbo mode will still be applied.

DCS now has native support for setting the preset. You can also look in your DCS log file as it will output the preset being used.

I think the premise of the original question is not correct. It wasn't the 'obvious invasion point'. It was considered a likely and suspected invasion point. There simply was no obvious and easy invasion point for the Soviets. They had a pretty large numerical advantage in forces in the region. The theory was that the Soviets would try to overwhelm the smaller, although technologically superior NATO force. Securing Autobahn 7 speeds an attack towards Kassel. Securing the end of Autobahn 66 aids the assault on Frankfurt. A66 didn't go all the way to A7 in the 80's like it does today. This would potentially cut West Germany in two and cause NATO some significant tactical problems. I was an infantryman stationed there from 86 to 89. We trained in the Fulda area on several occasions. NATO did not ignore the northern attack option. It was also suspected as a possible invasion point. It just doesn't get the 'publicity' of the Fulda scenario. The Fulda Gap scenario is a very risky, but potentially very rewarding strategy. Luckily, we never had to deal with an actual invasion. I was part of the Pershing 2 missile brigade. That's a kiloton of nuclear pain that would have devastated Europe. One of the potential strategies at the time was to fall back to France and launch the P2s at the forces attacking through the Fulda Gap. It's a nightmare scenario, but one that stops the Soviets in Germany and potentially saves France, Spain, etc. Very scary times for an 18 year old grunt.