fisadev

Hi! I've been working on a tool to manage DCS and SRS servers. It lets you start/restart/stop, edit configs, upload missions, download tracks, and even configure automatic health checks that keep your server up and restart it when it crashes, etc. All with a very strong focus on making things simple: installation is just running an exe, configuration is just there in the ui, etc. It started as a simple script for myself, then evolved into a nicer web ui, and then I decided to share it with the world and so put some effort into making it super easy to use. It has some overlap with the DCS Server Bot, obviously. But I really don't like the idea of administering servers via Discord chat, and wanted something far more simple than what the bot provides (too many extra things to install, configure, maintain, etc). Downloads, documentation and more: https://github.com/fisadev/dcs_server_manager/

Oh! Thanks for the info, I didn't know the real thing wasn't roll corrected. Sorry for the noise then, marking your answer as solution

The more the head is rotated in the Apache, the more the icons marking stuff in the ground get misaligned (waypoint, radar targets, shots markers). This short 15s video demonstrates the issue very clearly. It happens on all missions and settings, under VR (can't test it in 2D), and as far as I can tell to everyone (seen on youtube videos, friends, etc). Couldn't find a reported issue about it, sorry if it's been reported before. I can also provide a sample track, but it's super easy to reproduce: you just have to fly with a waypoint and tilt the head, and the alignment clearly breaks.

fisadev

Hi! I wanted to share a very useful discovery that at least in my setup, helps me fix the F10-map-related FPS drops when they happen. This doesn't prevent the FPS from dropping when using the map, but fixes it when that happens. Most of you are probably already aware that doing alt-tab can get your original FPS back, but it's unreliable at best, and sometimes it just won't fix it at all no matter how many times you do it. Well, I think I found out why: even if you alt-tab, if any screen (including the VR headset) is showing any pixels from DCS, there's a high chance the drop in FPS isn't fixed. So you have to make sure absolutely no screen is showing any part of the game at all, including the VR headset if you are using one, to get your FPS back reliably. In my case, that means doing two steps: 1) Alt-tabbing to another full screen app. Not just any app, but a full screen one. I just use a cmd.exe window in full screen mode with F11, which I always have opened anyway when flying because of some home made scripts I use for a button box. 2) Switching to the desktop mode of Virtual Desktop (which I use for the VR headset), getting out of VR mode, so DCS isn't rendered in the headset anymore. In the case of VD, you can do that with a VR controller or with the Shift+Windows+D keyboard shortcut (while DCS isn't in focus, otherwise DCS "eats" the key presses. But after step 1 DCS is already out of focus, yay). Those two steps guarantee that no screen, desktop or VR headset, is trying to show any pixels from DCS at all. And that seems to do the trick, I get my high FPSs back every time when doing this, 100% reliable in my case at least. Hope that's the case for others as well!

I found this bug today too. I was trying to record a tutorial video for the radar, but all targets were jamming me, even an I-16. It made no sense, until I realized it was the active pause that was causing the jamming.

FTR is good enough alternative to something 99% of the players can't simulate (a force feedback stick). Not even close to asking for something to be less realistic just because the realistic version is too slow for someone's taste, man.

Not useless, he's right. If everyone starts just posting stuff they "feel" could be different, the real bug reports will get lost in an ocean of noise. It's in the best interest of everyone to prevent that.

Happened to me too, can confirm that it was after hitting a wake.

If I set my shadows to "Medium", they are all over the place and really broken like it can be seen in this video. Please notice that they are also broken inside the cockpit (basically no shadows), not just outside in the world. If instead I set them to "Low" or "High", they work fine as far as I can tell. I'm with the MT open beta, in VR with native OpenXR (using the command line argument to force it), with an HP Reverb G2, a RTX 3080 and an i7 9700. Nvidia drivers version: 531.18 Track and mission attached. Also screenshots of the rest of my settings. area51_demos.miz shadows_problem.trk

Not even close. A heat issue wouldn't be instantly solved by alt-tabbing out and back into DCS, nor would it happen in the menus were the GPU load is super low.

Awesome! Didn't know that. And now I envy them for being able to do that too, hehe. Thanks

Hi! This is a well-intentioned question, not a rant or anything like that, I love the module and want to know more just out of curiosity How much realism and how much guesswork is there in the Ka50 module? Are stuff like the pages in the ABRIS known to be just like that in real life, or were they informed guesses? What about the functions of non obvios cockpit controls, like all the datalink and stargets storage stuff? Did ED have real life manuals or access to SMEs to get that info? I've seen posts over the years specially with discussions about the changes coming to BS3, but I'm talking about the current BS we have. Has ED published details on this before? I couldn't find anything aside form an old post from Wags highlighting that they only want to do aircraft that they have access to good info, etc, but not details on what's real and what had to be guessed in the BS module. After flying the Apache and seeing videos of real pilots commenting on how real it is, and also comparing what we see of the systems vs real life videos, I started to wonder if the stuff in the Ka50 is at that same level, given how obscure the real life thing is in that case. And I love realism, it's the single most important thing that makes me want to fly stuff in DCS: the possibility of interacting with these machines, which I would love to but won't ever fly in real life. I'm not looking to "validate" the module or anything like that, and I'll keep flying it anyway. But I would really love to know more about this

I would rule out the reprojection part, as I have your exact same symptoms and I always have it disabled. Even the weird stuff like the frame drop continuing in the menu and alt-tab fixing it. Also, today I tested enabling the hardware accelerated GPU scheduling, but I still got one occasion of frames dropping and continuing to be at 45 (instead of the normal 90) in the menu. So it didn't solve it

@muelchinteresting, I want to try that. Where does that setting live? Edit: found it, will test it today

I'm having exactly the same issues the initial post describes: the drop in fps persisting to the main menu, the alt+tab sometimes fixing it, etc. I'm using a RTX 3080 too, with a Reverb G2 and OpenXR, and disabled motion reprojection.

This isn't a direct response to the original question, people already answered the "how much can I control" part, but something related: I once asked on the Razbam discord F-15E channel how common it was to fly the bird alone (only one crew) in real life. There are a few real strike eagle pilots there, and their answer was something like: never in combat, sometimes to travel.

Let's take the radio 1 from the hornet: right now, we can map a button to transmit with it, which opens a menu of comm messages to send with that radio. The new voice feature will also require a mapping to use as push-to-talk with that radio 1, similar to how we have a key mapped in SRS to do that. Many people (me included) use the same button for both: if I press a certain button in my throttle, it opens the comms menu for that radio (menu on DCS), and if I keep holding it, it transmits voice over that radio (ptt on SRS). That makes sense: that's the "radio 1" button. Any comms via radio 1 are done with that single button, as you would in the real hornet. If the new voice feature requires a different mapping for the radio 1 compared to the mapping that shows the menu, then we will need 2 buttons for each radio we use, and that's quite problematic. Most throttles won't have enough buttons to duplicate the radio mappings. And even if we have enough buttons, it also makes less sense and is more cumbersome: we would need to use a different "radio X" button depending if we want to talk to humans or to bots. So please, let us use the same button if we want to (not mandatory, because of course there will be people who prefer to use separated mappings).

Steps to reproduce: 1. Acquire a point track with the pod over a moving target 2. Wait some time (with the target moving and the point track lock maintained) 3. Press TMS aft short to go back to INR mode What should happen: The pod should stop following the target, and it should be left pointing at its current position in INR mode. What happens instead: The pod stops following the target (good!) but it slews backs to the initial position at which you started tracking that target on step 1. This is specially annoying when dealing with convoys moving at speed, for instance in missions like the rolling SMRs one, where there's a lot of tracking of moving targets. Track file attached. Video of this happening (same mission than trackfile): https://youtu.be/NFErW_mNaQE DCS version: 2.7.2 (Steam version) Tested on single-player only, on all the maps. Sorry if this was already reported! Did a quick search and couldn't find any similar reported issue. f16 pod point to inr bug.trk

I just tried and can confirm that the bug is probably some of these penalizing factors being incorrectly applied to the IR mode when they should only apply to the TV mode. Took a mission that was at 8am where I couldn't for the love of god lock the pod into a tank, modified the time to 12:00, and now I can lock everything without any issues. Back to 8am, and again can't lock anything unless I'm practically touching it with the pod, hehe. It makes sense for the TV mode, but most probably shouldn't be the case with the IR mode.