Pikey

It's rotated and zipped during normal usage when DCS starts up a new file is created. So, given this we know you want to do that during runtime, which is not possible because the file is locked.

incredibly underrated mod. Want to see more people landing props in the pitch black.

Chinese Asset Pack. Its an example of an addon developed outside ED that is permanent I'm only speaking from the position of common sense when I say that the reason you don't see ED incorporating things like statics is that if it is used in the base game and becomes a part of something that DLC is sold with it invites the concept that ED own the maintenance perpetually for those assets. The idea that in 2018 we have a static house and in 2021 after 3 years of being included in missions, no one has updated the textures to add the new FLIR tech and the items becomes unusuable, rendering 3 years of campaigns getting complaints, well thats something that bears thinking about, a static brick is a static brick for life, not just christmas 2018. For every asset included there is a cost attached. If assets never disappear and keep growing its one thing, but then to expect ED to hold the baby after kids grew up and made a nice house during their summer off, that's not happening. So that's why basically, I think anyway.

You could probably write a server side script that forces the client into a slot when one dies of either plane. That would make the mission require 4 slots, two each side and when one dies both are abruptly forced into a new slot, but honestly that quite forceful on people and just hitting escape and picking a slot isn't such a hardship that could give a VR user a trauma.There aren't any mission side API controls to do this from a Mission script. You could make the cockpit unuseable by shoving a picture up that blcoks the view, or destroy the other plane too, none of it is elegant. Also depends on what you really want to achieve.

Just to help out the explanation because the problem wasn't immediately fully understood. Ground units at least, possibly more kinds are substituted for a "static type unit" when they recieve terminal damage, i.e. when they are on flames, no health and 30 seconds later explode. A lot of scripts rely on knowing when something has died so it can be respawned or an activity takes place as a result. This is a fundamental scripting trigger and one of the most obviously used. It has been used for over a decade, and over these years many scripts are created to leverage the fact that something 'died' in the mission. Due to the change of the type of unit that explodes, DCS creates a dead event but its not the same unit type and is missed because it is a static. Depending on the coding, a script can hit or miss this, but at least as far as I know any script created with Moose prior to today (5/6 years worth) will fail to recognise something died in game. We implemented a workaround where we have to examine a static dying and check it wasn't a unit and all sorts of messy and un hygenic workarounds to get it going, but the impact post today remains the years of work people have created using Moose will fail to recognise a dead unit as a result. I dont have an assement for the AGME or Mist or custom SSE scripting related scripts. What the ask is, is to have things as they were before, that when a unit dies, it doesn't change its type, in order to preserve the thousands of published player scripts that are downloadable on the forums and web site. Thanks.

For the record, the MOOSE community were not consulted in this request. Rather than derail the ask, I intend to aggregate the votes of the 1900 active members on the MOOSE Discord and summarise what people are asking for, since everyone will always have their own wishes and I've long since given up assuming I know what people actually want. I doubt any of them will have considered ways of identifying a forest though.

No way is it a cheat! Us simmers are deprived of body feedback! We are instrument gods. Could you imagine flying with right rudder in a real plane feeling squashed up against the left wall uncomfortably. In the sim, we look for a slip indicator... sometimes. Natural G force being absent makes it much harder, but flying a plane to it's limits is 'felt.' It's even used in teaching manuals, the USN use the phrase taking a bite of the buffet and include trying to understand the literal feeling of a plane at various AoA's. In dogfighting, with a small view space, when padlocked onto an enemy plane in the roof of your cockpit, you have almost no sensation of what slow is, in the context of AoA. A haptic replacement only partially meets what is available to the bodies sensation when flying vigorously.

Hi, I didn't go much further but its great to see people expanding upon this hobby and anything you add is no less than awesome. So, it's true what you say, you don't "need" to have a 1:1 signal to make something more immersive. For example any signal to any part of the body almost that something is happening in game adds something. The closer it is to real world, the better. I haven't stalled an aircraft to feel buffet but its well documented. The issue is perhaps more from plane to plane. Some planes show a lot of buffet before they stall, others snap a single wing quickly without warning. Each AoA for each plane will be different. But they should exhibit common signbs, which is a vibration, its basically disturbed airflow over the wing at too high alpha so its bumping throughout the airframe. Rmemebering you can stall one wing you can have uneven feelings irl, but not somehting I think the exports can handle in DCS. It's easy to imagine uneven airflow, everyone has been in a jet liner when it goes through turbulence. https://www.youtube.com/watch?v=yFl6I_a3njg This one is more stall related, but a good example of stall without buffet. So, the TLDR is that it may be very complex to assess the buffet amount and strength for each moment of AoA for each aircraft as its attached to the FM. For haptic arms what about rollrate and yaw? might be soemthing that can be done. HTH good luck making something!

Thank you for your suggestions I tried them. I feel like changing my Facebook status with OpenXR to "it's complicated" The settings at 80% you provided did get MP into the 40's and workable, so that's a thing. Frames are enough, even tested on Blue Flag Syria with an Apache and its high 30's (but not into 20's) which with OpenXR is better behaved than SteamVR by a large amount. So this is a bottom line, with the tracking enhancement I'm keeping it with the following issues. - Water to medium is a hard sell - it makes sense to look at Baileys startup shortcut maker to have that launch on demand. It's a big loss for me for when I look at it. - Cockpit Global illumination I really miss and it also causes some oddities in the game - I've had bright lights - that's not VR's fault, but its a less tested config and I'm going to be busy reporting some horrid lighting bugs for a while, including "Bright white ocean", and "Cockpit under a spotlight" - There's a small distant shimmer, especially with complex clouds at Medium visibility. I need more pixels on screen to resolve that, it's where this is. I'm using NIS and unlocked frames. - pixel detail is bang on minimum acceptable for cockpit reading, but I get high textures, so its give and take. - Chimney and clutter - somewhat irrelevant once completely gone, so a good saving. - AA is x16, I always thought that was fairly cheap, but ED's stock VR has it reduced to 4. Any lower and the runway end turns to mush FPS comparisons for OpenVR and SteamVR are like trying to convert GBP to EUR. A little less OpenXR is equivalent to higher SteaVR FPS, but the tracking and comfort are light years apart. My brain has become so tolerant of all the jerky shaking and stuck moments in WMR ,that putting OpenXR on was like a bandage to the senses. It reminds me of Occulus Rift tracking actually. The Rift had this ability to handle low frames way better than the HPO Reverb with its stations. WithRrift you could have 10FPS but your head still tracked. I don't understand the technical detail, but the tracking for Reverb is dogsh1p - you build up this tolerance to discomfort and just put up with it because you have to. Developing an immunity is no substitute for a gentle experience. I might never reach the pixel density on this card to give me a good horizon for spotting, but it should make me less exhausted. I hope this project continues, if its me, I could trade some of that tracking for some CPU and the end result of more pixels, as it is, I think after a very long battle with settings I will keep OpenXR. Thanks.

sorry to interupt, but I get dead events for the instant kills and slow burners. Is there a more concrete type testing to perform to accept this as officially fixed?

Yeah its close... I think my conclusion is that if you have the system to support it, its superior, with the lack of steamVR items like fpsVR included in that statement, but for MP and lower specs it's ending up losing out on the grunt to carry it up to minimum FPS play. It definitely tackles texture related nonsense, i've even found it more stable with an old bug/thread where swapping cockpits would eventually break SteamVR and cause a black screen. It's really killing me, but the actual result when trying to play on Blueflag is that the overcompensation on smoothness ends up looking like your HMD turned into an eel swimming through jelly. Super sad about this because it tackles nearly all the basic issues with SteamVR. The irony is that if you take down the quality settings it doesn't really affect OpenXR like it does SteamVR. OpenVR remains very stable on frames, both up and down. For example I cant get it over 55/60 FPS and Steam would hit 90 in game, and going lower, SteamVR recovers quickly from troughs of poor performances, where OpenXR seems stuck in the mud. It's like SteamVR took a chill pill. Long wait until 3xxx series GPU are acceptable price for me. But people should really ignore the noise in the thread and just follow the instructions - it's one quick default install and swap three files into your DCS directory, how that can be screwed up I just don't know, also the OP didn't do any favours with the conversation, people don't read that, apparently over 4 lines and you are passive-aggressive these days...

I'm so torn by OpenXR. It gives and takes and I think its just having not enough hardware that's letting me down. i5 10600K and 2080S. I reinstalled things and spent more time using it than benchmarking it and I warmed to it. The way I have found it is that the tracking is the most amazing improvement. Soft in turns, doesn't stop if turning your head fast or at extreme angles like looking down and to the side, the actual tracking issues solved from SteamVR, never have to recentre at the start. But the loss is pure frames and CPU frametime. I cannot explain it. This means that going into MP I get the frames descend into the danger zone and things start to go wrong from then on. Offline, I think its better than SteamVR and in MP it wont get up high enough to guarantee 30FPS all the time. A lot of 3xxx series owners claimed this is just scoring points needlessly as if frames don't matter, but when you are clear of the low frames the benefit of the tracking without loss becomes way more obvious. Pros: Tracking is awesome, smoother turning, get rid of Steam, can change settings with Dev tools on the fly, better offline compraritive performance, easier to play with, starts faster, popular community effort. I think (and its impossible to benchmark) it behaves much better for low texture memory usage. I found the F14 which was notoriously heavy and juddery was smoother and mor eenjoyable to fly. Cons: FPS is lower, it struggles worse at low FPS than SteamVR at the same FPS, can't use fpsVR, its a mod and resets with updates, appears to be more CPU bound and performed badly in MP, some of the settings in the Dev tools dont seem to work well or at all Whatr I do know is that you cannot compare them well, I thought I could, but I cannot.

Just for a point of clarification. You use saturation to change the sticks limits versus the in game one, meaning that there is no 1:1 for real position to game position, but you want that "reset" to neutralise at the point of the trimmed state every time the stick is trimmed so that the accelerated coordinate provides the same accelerated feeling at the new trimmed position? Let's call this, "Dynamic saturation". Makes sense to me if i understand well enough. I'm not sure how simffb works as I read it it sounds like its to do with the forcefeedback rather than the acceleration. Would this work with curves too? For exmple if you have curves allowing precision at the stick center, do these then travel with the force trim too? I can definitely see how making any changes to the stick curves that break from 1:1 would mess up the feeling of trim, but I feel that its a bit of a crutch, since a real stick doesn't gain precision every time it is moved. but since its so artificial anyway, why not. Unless I completely misunderstood, in which case, please correct and explain

Can you see anything in the mirror or is this all derived from in headset comparisons? I don't see the difference. What is actually changing? To be precise I see the same thing but with the OpenXR I get up to 30 frames less than with SteamVR and I can literally see the stutter in the mirror. I don't understand how I seem to be th eonly person who gets worse performance?

it's literally an OVGME double click on/off once the OpenXR dev tools are installed. It backs out and in perfectly. I also tested DCS repair, it removes to the original also and takes less than 45 seconds to do one on NVMe. Simplest thing to add, but obvbiously you have to readd it each DCS update. Classic gotchas are running SteamVR, or a repair afterinstalling. Will cause a Black screen. That's it. I still don't understand the benefit yet, in the HMD i'm not seeing the difference. I wonder if the placebo is caused by the DCS repair?

PD and SteamVR Super Sampling are not the same code but they are the same thing, more pixels/resolution. Community has swung on when is more performant, the only consensus I recall is lower PD and use higher SSS. I use 1.0 and I can go to 130% on Steam, depending on mission. SInce DCS is in open development this can change. The only way you can get a juddery mess in the menu system is by wrecking something outside of DCS. In the menu system most people will get 90 fps until maps and such get loaded in. If you meant something completely different with the word "menus" then please be more detailed, since you can get issues joining servers in MP if they are struggling under certain circumstances. Target frames sub 30ms. outside of MP you should have a lower CPU frametime, inside a MP mission the CPU will begin to overtake and thats when performance bottlenecks elsewhere. You target what you play in consistently. The main change is what you play, not so much your settings unless you do something crazy to the supersampling. Aim to keep CPU and GPU frametimes together. Often to rescue VR performance restart the PC, fo some reason, it can sometimes go into a mess for no reason. Can be affected by latency to the server even, I've seen people mass join servers, server starts to drop frames, players start to drop frames and its nowt to do with the graphics. One of the worst offenders people moan about is on patch day when their shadres recompile and there's a juddery mess. Can watch that in the dcs.log The simple solution to that is allow your PC to run some heavy unit missions offline in 2D until it stops ebfore trying to run that in VR.

Sure, except I benchmarked a track file offline. With the Steam VR I could measure framteimes in the baseline and the Cpu was all green from fpsVR. Am I supposed to see an improvement in frames, I felt from the OP I should? I can say I saw less peaks when I drew out the graph. Has anyone in this thread done before and after benchmarks?

Hi thanks for your response. The loss of 20 FPS when you can dip lower than 45 is damaging to me since the screen is a juddery mess at the 22.5 fps mark which can be reached quite often in big MP servers. For everything not data related It will remain my opinion which is unaffected by your own. VR with DCS is about headroom. MP requires it. I spend most of my time sub 45 frames. The benchmark I used for the tests is offline so the headroom illustration is important. Offline players have less to concern themselves with as they tend to stick to optimised playing configurations. We aren't talking about negligble performance gains, I am citing a recorded straight up loss of 33% against SteamVR. WHere I had 90, it was 60. That theme continued when frames dipped to 30 and I got 20. If this doesn't bother anyone then my post shouldnt be of interest and can be safely ignored.

I spent a great deal of time benchmarking this and I can find no benefit and only loss of FPS. For sure it is working, and I dont have stability issues or black screens. SteamVR remains off and the game actually loads a lot faster. (in one test, 45s faster) I've used two builds of DCS to test and finally I get consistent results with them, using PD 1.0 and the VR preset. Only FPS is recorded, it's taken directly from the game programmatically in the same way for each test. As well as testing on two builds, I have reverted changes backwards and forwards on the same build and obtained the exact same figures before, and after removing the changes and then after again. It's entirely consistent. The scene I use to test is a track file, so there is almost un affected GPU frametime by CPU bottleneck. The scene is 5 minutes and covers some cockpit, external, city and woodland shots across the Caucasus. Frames are reecorded via script from the game. The Headset remains motionless on the desk throughout. I was quite disappointed since I wanted this to be a magic fix. I am very happy someone is working on this technique. I don't know the developers and have no reason to contradict them. I have not done this work in any official cpactiy as a tester, just as a curious individual. I remain open to tweaking and looking at this in the future if ther eare substantial changes, however at this point I find the changes quite damaging to DCS performance and will not be using them. It's possible that something isn't correctly configured, however the files replaced clearly do something to get it working without SteamVR, good luck with you own findings!

8GB RAM will make the game chunter a bit these days, not sure about the graphics card but the minimum specs are below As said, its a free download and there are free planes, so the word free, should make it clear you have nothing to lose except time And by that I mean most of us, as in, the last decade I have lost to DCS Start here: https://www.digitalcombatsimulator.com/en/support/faq/ Minimum system requirements (LOW graphics settings): OS 64-bit Windows 10; DirectX11; CPU: Intel Core i3 at 2.8 GHz or AMD FX; RAM: 8 GB (16 GB for heavy missions); Free hard disk space: 120 GB; Discrete video card NVIDIA GeForce GTX 760 / AMD R9 280X or better; requires internet activation. Offline play has very basic pilot and roster with awards. Some people built addons for that. You can play with keyboard and mouse badly, and better the more you spend on peripherals For anything with a propellor it will be very hard without a twist stick at least, but for jets like the Viper you are good for Z and X ont he taxiway. Documentaiton is included for the product and for each module and Training missions are supplied and begin quite basic during Early access and can become quite in depth once the module matures.

There's way too much info already out there, makign a guide will bury it in this weeks videos but feel free. 1. Launch your VR via steam 2. Launch DCS. 3. Go to settings (cog) 4. On SYSTEM tab, click VR preset 5. Go to VR tab 6. settings, Click enable Virtual Reality Headset. (This setting will be persistent, you can use shortcuts or a launcher to switch directly in the future) System restarts in VR (Put facemask on). Play and adjust for your own FPS comfort level. What I know is that people are not the same and they will choose to give up more for FPS or want more for this setting or that, but that's entirely up to you, there is some guides out there for each one, but there is no fixed method or certainty that X feature removes Y FPS, it depends mostly on the mission, then the resolution/supersampling (Steam Super Sampling in Steam VR) and Pixel Density (PD) in game. Remember you do not use MSAA or SSAO. Start with the VR setting and a quickstart mission. For 2 bucks get "fpsVR" which will give you access to performance information which can be used to tune further. You can't escape tuning because there is a simple fact. You are not allowed to have all of the frames, you have to give up some in exchange for the pretties. Pretties vs frames is the endless choice. With fpsVR tune based on multiplayer since the CPU usage is higher compared to the offline which you will bottle neck the GPU first. Use a baseline that makes sense. Typically there is an element of degradation when the frametime reaches red. Frametime can go from 12 to 30 to get from green to red. Adding settings usually adds one or two milliseconds frametime per feature. Anything else is past beginner level.

I saw this a couple of times. The most interesting was one of my own servers. I updated it for Apache and changed a lot of things, but it's sub 1 FPS on joining. I noted that a local player didn't have the issue, in VR. WHen I had it running locally, it wasn't the same behaviour either. This means something is network related as that is the only change, but it doesn't really give much data. There is nothign in the logs, when I added a FPS count it only showed the server had OK FPS and I didn't. I don't use warehousing.

Thanks ED, this was a new benchmark in EA quality.

Hold my beer...

it is slower. Yet its the only helicopter module I've managed to fly with KB and mouse due to that nice stable movement. What you can't do is move the stick fast to recover something you didn't react to in the first place. It could probably do with a bit more sensitivity, esp the collective.