Pocket Kings

Regarding the first part, I disagree. The Allied Forces stayed in Berlin for one reason only, and it was not to bring candy to the poor kids of Berlin: International law dictates that an occupied capital by a single foreign occupant leads to the occupation of the country as a whole within the borders PRIOR to the particular war / conflict. This stems from the times when the Law of the Seas was the only international law. The Soviets knew it, and fiercly defended Moscow, and the Americans knew it too. So the first and foremost step for the Warsaw Pact would've been: Get rid of any Allied Force within Great Berlin (legal term). Did you ever wonder why the French agreed to the foundation of the Bundeswehr? Among other minor reasons while hating the idea of German troops, they had to agree, otherwise the Soviet would've been easily able to stand on the other side of the Rhine within days, literally. Whether the United States would've respected international law in such a scenario, I don't know and I doubt it. Anyhow, I don't wanna derail the thread into a history lesson, only to show that Berlin = No. 1 and Rest of Germany = No. 2 for any military strategist of the cold war era. You even see it today: The Americans could not operate in the Middle East if they didn't have the assets in Germany like they still do. Regarding the second part, that's true. I find the NTTR map very useful, but it doesn't get the attention, at least multi player wise, that it deserves. One talented mission builder could create great Red Flag scenarios there. I highlighted the magic word, Mission Editor. This thing not only looks like 90's, it performs almost as badly. But, I think that's a topic for another thread, though I believe it's general consensus. Northern Germany isn't a densely populated area, especially the GDR part. Many villages and few larger cities. From the geographic standpoint, and the strategic, Germany has everything a great mission needs: Coastlines, waters, plains, mountains (of almost every feasable size), forest en masse, loads and loads of bridges, highways and so on. The only thing that doesn't exist is a beautiful desert. While your suggestions are very appealing and sound interesting, I still believe that the first bang would've happened in Germany. The fatal bang would've for sure happened along the inner German border.

IMHO three things are inevitable within the next five years when it comes to DCS (and for the matter of the first assumption, games in general): - Mass adoption of VR, - the strive for more REDFOR units, which will be 90's and 2000's at best, - which leads to the logical consequence: A cold war turning hot = Germany. Now, if this will technically be feasable, I don't know. What I do know is the fact that graphics card companies held back technology and architechtural improvements for a couple of years now. I mean the first time I heard of Ray-Tracing it must have been 15 years ago, but definitively a good 12 years. And finally we have a somewhat working implementation for the consumer. The CPU side isn't a problem anymore. Servers with core-counts into the 40's aren't rare nor super expensive these days. And RAM: I have a server right behind me with 384 GB of RAM, nothing special. Ten years ago it would've cost a good saloon car, 40k-ish USD. These days computing power gets cheaper every minute. Whether the DCS server instance can profit from such a high concurrency in CPU cycles, I don't know. As I said elsewhere, a well controlled step towards open sourcing parts of the code, ESPECIALLY netcode, could help tremendously. We all know that a mass adoption of VR will force GPU manufacturers to revamp their current (broken) business model.

A full fledged war in the Mediterranean with a US carrier strike package and the Kuznetzov and Syria and Jordanian AF and Israels units would also not go down with 100 units, not even with 1000. I get your point, but then I could say simulators of the 80's had to get better a million times, simulators of the 90's too. Yet, we played them anyway and it was fun, as well as a little bit of knowledge regarding systems.

I think if the people in this thread alone would work on a manual, we'd had it done within a month and 10x better than the actual "piece of paper". It's not even a quick intro guide IMHO. A wiki page comes to mind. I could set up a small server and people could work on that wiki, texts, screenshots, audios etc. On the other hand, it's not our job as paying customers, so the thought of doing Dekas work annoys me. And Corona, give me a break... two years now. If I'm not mistaken: Home office is a perfectly safe place to write up a quality PDF file!

Can you be more precise regarding "laser malfunctions"? Instead of opening the 31st thread, I'm rather asking within the current one. My experience: If I select let's say a GBU10 and release one at a time (two runs), everything is perfectly fine, the laser marks the target in "AUTO". However, when automatically switched to the remaining GBU16, no more lasing, not in AUTO and not in MANUAL, nothing. I get a tone, yes, but after the first set of GBUs, my laser is dead and the bombs go stupid immediately. Caging, uncaging, on / off, nothing helps. Not even landing and repairing!

To be clear: You're over the target, press "Lock", then the target designator jumps off of your target? Or is your slew control too slow? This is what happened to me, the Warthog slew was way too slow, I couldn't keep up with moving targets, nor bank angles and so on. I'm using a PS4 style controller that registers to Windows as a XBox device.

Well, then we have to manipulate the routing table. My first thought would be a small virtual machine that acts as a "real" router that runs on top of the Windows Subsystem for Linux. vyOS would be perfect for the job. Alternatively, if available, a Raspberry Pi (any version) could act as a router. If OP tells me his subnet and the local IP of his gateway (the comcast or whatever ISP box) and the local IP of his server, I could write a quick bash script to install and setup this service. As long as his client DCS is pointed at this router, he should be rerouted via the local subnet rather than out to the WAN. Maybe there's a third resolution: Manipulate the routing table of his Windows 11 client, but I've never done that and I bet it's not persistent across reboots / Windows Updates.

Supernice overpass! Great idea, was it a P51 in the middle? My local TV station only showed it briefly, I believe I was a F-22 one right to P51. Also, great rendition of the anthem. Good luck for you team!

Good afternoon, I read your requirements regarding the safety check ride. Interesting approach, I bet it weeds out the "gamer kids" type of people, which is totally fine by me. Do you own a Teamspeak server or something like that? To be honest I had several bad experiences in the past (not DCS related) when it came to squads, ranging back to old Counter-Strike days. It often took just one bad actor within the team to destroy morale, that's why I believe in good chemistry among the members. The only problem could be 0130 Zulu, although I'm surely awake since I'm usually keeping an American sleep cycle. Most of my customers are from the US. Do you have a IP that I could ping or traceroute to? Well, maybe that's better answered in private chat or Teamspeak. Cheers guys and have a great Sunday!

It should be, or do you remember IP's by heart? I do, though I work in the field and have a mind map for every octet and every 255 variants (animals to be precise). BTW, a domain doesn't cost a fortune these days. If you want to cheap out, I'd suggest services like no-ip.com that cost only a registration, but are essentially charge free.

@zildac May I ask how you installed Barthek's Caucasus Mod 2021 together with Taz1004 Better Trees Mod? Which goes first and which overwrites the first one?

Guys, way too complicated! From what I've read it's a routing / DNS issue. So, assuming three things that are common (but I'm guessing here): 1. The server has a FQDN (fully qualified domain name), like myawesomedcsserver.com 2. The servers' local IP is 192.168.10.100 (adjust to your local subnet please) 3. The DCS server ports can be reached locally, that's LAN IP Client ---> LAN IP DCS Server instance. I mean why wouldn't they, given there's no firewalling on the WS2022 part? The firewalling takes place at the LAN / WAN gateway (that's the cheap plastic box that's infamously called router, nontheless wrong advertising). Fix: - Open up the Windows Editor as Administrator - Open File ---> C:\Windows\system32\drivers\etc\hosts - append: 192.168.10.100 myawesomedcsserver.com - save + close - cmd.exe - ping myawesomedcsserver.com - If you get the reply from your servers' local IP, you've succeeded. You could also "blackhole" sites like facebook or google with this technique, in fact we did it back in the day when memory was the main constraint. On the other hand, I could sell you a professional routing and firewall solution like vyOS or pfSense + charge hours for a crap ton of money, but no... not from a fellow DCS pilot. Have a nice weekend!

The following post is kind of offtopic, not related to the technical discussion, fell free to skip it. But maybe someone at ED reads it and hopefully it's good food for thought. I believe there are three business decisions I'd tackle immediately if I were part of ED's management: 1. Open Source part of the code. Why not profit from the very dedicated mod community? Open up the ground for programmers like fholger, why not? MS and other steal anyway, it's not that hard decompiling an exe, no rocket science. It's tedious, yes, but far from impossible. 2. Hire people to scan the forum daily for interesting ideas, suggestions and so on. I mean people being actively involved in the discussion. I, more often than not, read something along the lines of: "Acknowledged" and that's it. Nothings' really been incorporated into the beta releases. 3. Make damn sure that the VR customers are satisfied. It's easy math: Someone who spends between 3 and 5 grand on a potent VR gaming rig is likely, maybe, I'm just guessing here ;-), able to spend more on planes, maps, tech packs and so on. Why on earth do I get the impression, prior to even stepping onto the VR bandwagon myself, that VR people have to deal with the most atrocious bugs in the whole sim? At least from the visual standpoint.

Agreed, I was using AMD's Radeon Graphics Central (or how the heck it's called these days by marketing gurus) Adaptive Multi-Sampling 4xEQ (wooooooooohoooooooooo fancy stuff, must be awesome!!!), but you're spot on. I neither saw a visual difference, nor a measurable one in fpsVR.

Thank you @zildac for the constructive and helpful reply. The hint about renaming the DLL is both obvious and "hidden in plain sight" at the same time. That's the kind of thing you forget when reading through 25 pages (and countless more on hoggit and the likes). One follow up question comes to mind: By "shimmering", do you mean a) the lack of anti-aliasing, b) the fact that low-grade AA (like MSAA 2x) isn't cutting it, c) shimmering as a result of upscaling and sharpening the image, d) cloud shimmering (which is AWFUL) that can only be mitigated by cranking up super sampling to insane values?

Thank you for your reply and effort. However, I've read many times now that a mod broke because of a DCS Open Beta Update. By "breaking" I mean everything from performance degradation to crashes and something in between, like artifacts and so forth. And I stand by the statement that information on shaders dated July 2021 can very well be outdated. Given the fact that we have three major contenders (2x fholger and 1x 3Dmigoto if I'm not mistaken), many point releases within months together with a few DCS point releases + driver updates, I'm not afraid to admit that this environment confuses me. If you're not confused and know the inner workings of the "upscaling technology", great for you, share your knowledge, please. And yes, I'm familiar with github and git in general! My oldest internal git repos go back to Debian 4 days. That's the timeframe when git was the hot new <profanity> in dev ops. Problem was, I was using an Adblocker and opt-out tools (like I do on ebay and those crowded crap pages) that changed the appearance. Basically, I was missing menus and buttons, my fault clearly! Thanks for the wise words. Here's my reply: Do you really read open source code? Being a programmer I'm working with open source code on a daily basis and I can tell you: Ultimately any complex software relies on complete strangers and the assumption that they did a fine and thorough job. Why do you think everything from small programs to big ones (like OS'es) have more bugs than functions? Anyhow, I have no intention of derailing this thread further, so I'll stay quiet regarding this offtopic. What I will say: I know the hourly rate I charge. From experience I can estimate how many hours I'd expect to spend to get "up to speed". As far as I understand upscaling, shaders and sharpeners and their interactions, it's non trivial. And honestly, I can think of better ways of spending the little spare time I have currently than dealing with software bugs and outdated paradigms... like I did all day just minutes before hand. You're right about the self-solving attitude, I fully support that notion. But it's just not possible to understand everything regarding every software problem there is.

First of all, thanks to everyone for their effort to improve the VR experience, devs and commenters alike! Frankly, I'm a bit lost, though working in IT I know about the mess called github and forks of forks of forks. Problem is, most information is ages old (like July 2021) and I want to make sure not to combine legacy tools / shaders / FSR techniques. So far I'm using FSR, but I can't use MSAA, kills FPS. Flying Helos currently, meaning low, means FPS are very important in order not to crash every five minutes. Fixed wing fast movers are mostly fine above 300 feet. Here's my gameplan: a) Use a mod manager b) Try a bare metal difference between FSR and vrperfkit c) Do I really need to compile reshade myself or does anybody have a compiled package at hand for a quick tryout? For reference: 3700X @ 4.2 GHz all cores 64 GB @ 3200 MHz 1 TB SSD 6700XT stable at max OC Reverb G2 I'm at a point where I'm willing to pay someone to get me up to speed regarding the latest and greatest, and their implications. Thanks in advance guys! And yes, I've been reading at least 15 pages this thread alone and countless reddit posts. But, the more I read the more contradicting the suggestions become sometimes.

I cannot speak for the internals of FSR, you'd have to ask fholger over at github to get an elaborate answer. However, I played with the settings for days back and forth and I can only suggest to any other newbie to the topic: Begin with 100% Steam SS, Pixel Density of 1.0 within DCS and downscale with FSR. Also, play with a much smaller radius. Tried as low as 0.3 and it wasn't terrible at all. I don't see any real world, that is "IN FLIGHT" and NOT cold and dark on the ground, differences that break immersion to the extent that I want to get rid of FSR. Currently I'm struggling with the variants of anti aliasing, MSAA, FXAA and the likes. Performance is great, but power lines and fences look awful.

The GPU throttle pattern to be recognized, as far as possible with a through the lens photo, is clearly artificial. Therefore, it could stem from a power saving "feature" as well as thermal throttling of the GPU or a CPU govenor issue. I had great success with limiting PCIe to Generation 3 on an X570 motherboard. Prior to that and a few other tweaks, like disabling CPU C3 states, DCS was a stuttering mess, unplayable.

My experience (and temporary fix) goes as follows: - The screen within the G2 flashes blue or switches to solid blue. - After a few moments, the game crashes and Windows shows a BSOD, usually a FATAL_DXGKRNL_ERROR and the Windows instance resets. - After reboot, which Windows performs normally and never runs autorepair or other shenanigans on its own, I have to run 1. cmd.exe as Administrator 2. cd into the "DCS World OpenBeta" folder 3. cd into the "bin" subfolder 4. DCS_updater.exe repair (watch a nice DCS instruction video while waiting ~ 20 minutes) 5. sfc /scannow (in order to repair the corrupted filesystem) One more thing I'd like to mention for clarification. I'm running Windows as a virtual machine on top of the ZFS filesystem, which is leaps and bounds ahead of the NTFS filesystem. Funny enough, the written junk blocks from the NTFS are coming from the Windows kernel. The Windows kernel corrupts the FS and it's not a matter of dirty cache or other known phenomena. That's why it corrupts DCS files as well as Windows system files (found corrupted DLLs). After running the lengthy FS repair, DCS works without any issues, except occasional and annoying blue flickers or stutters, but nothing catastrophic.

And lets not forget the security factor here. If you visit some of these download pages, there are a couple of DOWNLOAD HERE buttons, but they're basically malware. I wonder how many people have killed their Windows install by clicking on the wrong link. With an integrated tool, we could do checksumming and cryptographical verification in order to prohibit corrupted files from entering the system.

Ok, seems like an animation bug. On the other hand, what does fixing this really accomplish? AFAIK your gear gets damaged with such a big crater anyway and most of the time the airplane is stuck and then game over, so why even driving through it? But thanks for pointing it out, I would never have found this bug.

Can you please clarify what "put in settings" means? Do you set your bindings up in the DCS settings menu or do you use an old config file? The reason I'm asking is that the settings menu has different subcategories now. I also lost some key bindings due to the new structure. Can you reset your settings manually, then press ok, quit DCS, then start up and retry your custom bindings? Further steps would be more aggressive, let's try the gentle way for now.

I didn't say it's a solution, it certainly isn't. I used the word workaround. IMO it's better to fly without the canopy, but still fly, than crash down right away. If you can't live with DCS currently, these are your options: 1. quit 2. fly stable 2.5.6 3. rant on None of the three get you or me closer to a solution. Don't forget, we're talking beta here and beta means "something wrong", I've never encountered a bug free beta in my life as a professional.

Certainly, it's DCS not MSFS 2020, the military function trumps the visual appearance. I wouldn't even care if huge areas like north of Rhine / Ruhr, e.g. Münster and above up to Bremen / Bremerhaven look like plain fields with a few roads and occasionally some villages (there aren't many anyway). The Fulda gap is important because of Frankfurt. And I'm not talking about the fairytale of Russian tanks that blast over the Autobahn and reach Frankfurt in three hours, take the gold and leave. There were only 10% of our gold reserves in Frankfurt during the cold war, maybe even less. The rest was in New York and in Kentucky. The topology of northern Germany is so flat that NATO had plans to create a nuclear bomb alley along the whole border in order to stop the Soviet advance. In the south however, it's way more complicated to maneuver with vast tank units the Warsaw Pact had. Then, Frankfurt is the last hope for anybody on the continent. NATO strategy at that time was: Stop them in Germany or don't stop them at all and retreat, they don't dare to cross the Atlantic or the Channel. If it's even remotely possible to model the Fulda gap and sourthern GDR border in detail, I'd accept the ugliest graphics in western Germany imagineable. But the way the preloading of map parts work I don't think it's a matter of user RAM, rather server RAM and of course development work hours.