mimamema

Well in that case I would suggest you try any good Ribera del Duero from Spain, my home country, and then let me know what kind of inspiration it brings to you . Thank you for answering, it´s good to know that it was already in your mind ^^

hi @cfrag !, here another great admirer of DML, you always manage to surprise us with new and amazing functionalities. Have you ever thought about making a logistic system? I´m not refering to use the warehouses but something a bit more "simple" as with Pretense missions, were the logistic bit easily regulate the way a zone is able to create units or repair itself, something that I could see added to your Factoryzone module or any other zone with similar behaviour. Or maybe you have any other idea in mind that could work better?, or not any interest at all, which is fair enough .

It´s a script, nothing that can be installed in the game, it has to be "embedded" individually in every mission by adding it to the mission editor.

Skill issue

Question, I was suffering from the same problem and realized that the problem in my setup was the sharpening configured to Quality, in normal or disabled I stopped suffering from those micro stutters. Could you give it a try and see if that´s your problem as well?

Try to enable the safe mode and follow what it says to delete all settings and start again with OXRTK and see what happens. Anyway since I saw your post, I managed to see a lot more people reporting things like this and it is being looked at. If you are able to reproduce it maybe it would be worth reporting on OXRTK discord. I could do it for you if I´m able to reproduce it. null

Regarding this topic, some of us notice that the issue is even worse now. So I started to test it again and realized that the problem happens when the convoy is spawned after the mission has started. Here is a track and a mission with a convoy that spawns with the mission start, and another that spawns 10 seconds after the mission starts. Even the late activation one has waypoints in front and after the bridge but fails to go over it. At some point, the LA convoy gets stuck anywhere in its path to the final waypoint (even tries to go over the rail bridge many times in my tests). I think this shows better what is the issue, and is not actually the "bridges" itself, it´s more that the AI ground units are not able to stick to the "on road" command when they are late activated or spawned through scripts so they start to mess up with the statics around like bridges, trees and building till they got stuck, notice that they try to do shortcuts all the time. So maybe this should be moved back to Ground AI bugs? Hope this can help @BIGNEWY. Edit: After some more testing, it´s the command/perform task "go to waypoint" the problem here. If you just leave the waypoints without this command, the convoy goes straight away on the road. But when using the command is when the convoy just gets crazy and kind of forgets about the "On Road" condition. But actually, if you add it to the "command" conditions --> land.SurfaceType = 4 ( 4 is on road) it actually works as it should. bridge bug 6.trk test ground units-bridges.miz

just to confirm what is has already being said, from Razbam discord, Mirage Chat

Was this happening in the Persian Gulf map by any chance? Just read about a bug related with that map that is quite similar.

I was coming to report about the HUD brightness binding not working and I saw this post. It´s still not working with buttons (encoder) but works if set in an axis. If you can have a look at it please

Sorry, but my lack of knowledge of software coding doesn´t make me able to explain why it happens, I know there was a bug related to the new implementation of OpenXR hand controllers in DCS that when being deactivated were causing a crash when used at the same time of Quad Views Foveated. The way to avoid it was by activating the controllers in the VR tab, then a fix was released and now it works perfectly without that option being active. The day after I kept testing without using QVF and realized that every time I wanted to activate Turbo mode during gameplay DCS was crashing, Guess what, I turned off the hand controllers after that fix. So I turned it on again and voila! I could switch on Turbo mode without a CTD in the main menu, but not during gameplay. At least that´s something. This could be related or just a coincidence in any case it works for me, and I don´t think it could be harmful at all to try on your side. I don´t think many people explain here the insights of their advice, people like me try different things and sometimes they work without us knowing exactly why. So it´s up to you to "trust me bro" or not. In any case, it took you longer to write your constructive answer than the time it would take to try the workaround that I proposed. It´s just ticking a box, not jumping from a bridge...

Have you checked if any other controllers have been assigned to those axes without you noticing? a gamepad maybe? I saw that happening to me in the past and that was the reason.

Guys, activate "hand controllers" in VR tab in DCS and change the "turbo mode" to ON when you are in the Main menu screen of DCS. If you have already loaded a mission it could CTD as well, so try to re-open the game and then use OXRTK to activate Turbo mode again. "use Hand controllers" is the option you have to activate to make this work. Give it a try and let me know ;). Edited, it actually works during gameplay.

This sounds related to this topic so we are kind of expecting a fix sooner or later.

Our experience with Pretense is more about every bridge then, but no, it´s an AI thing that only happens, as far as I could see when the mission loads the persistence file and spawns and gives commands to all of the convoys that were on their way at the saving point. That is where we have found that the convoys get stuck on the bridges, usually, the first unit crosses it and then the 3 rest ( there are usually 4 in each convoy) stop before the bridge and that is it. The problem is that we cannot provide a track as we give the saved state it will start just after the issue has happened and the convoy will spawn just after the bridge, and without the saved state the mission will be empty of convoys, so the only way to see it happening is by playing the mission for a while, letting it create the persistence file, stopping it and then loading the mission again where you left it before and waiting for it to happen. As far as I have tested, the issue happens quite more often in MP than in SP as it only happened to me twice in the 4 times I tried to save a track to upload here. But I remember perfectly how I had to use Combined arms in our MP server to give a path again to all the convoys as all of them were getting stuck in the bridges every time we restarted the server. So it´s a bug that is not easy to reproduce in a fast way. If a video could help to see what is happening I could try to record it and post it here. But I know a track is preferred to see what is actually going on in the background.

As far as I could test these are the potential CBUs affected by this effect. All from modern aircraft, if anyone knows of any other CBU missing please reply to this post. I´m actually wondering if this script could modify the damage of the submunitions of the CBUs, mainly because the script is not reporting the model of any of the submunitions when they hit any unit as missing in the script. RBK_250 RBK_250_275_AO_1SCH RBK_500AO RBK_500U_OAB_2_5RT BKF_PTAB2_5KO BLG66_BELOUGA BELOUGA CBU_103 CBU_105 CBU_97 CBU_87 ROCKEYE CBU_99

I will try to make it for you then

How easy would it be to set a filter in the script to exclude some weapons from the effect of "larger_explosions"? As if it is ON, the first explosion that deploys the submunitions of CBUs like Belouga or MK20 damages the aircraft deploying them as in the screenshot.

For that you need a cable like this, not trying to promote any brand, but it is the one I´m using and my Quest Pro stays at 99% without any problem Amazon.com: Kuject Design 18W Fast Charging Link Cable for Quest 2/Pro/Pico 4 16FT, with Separate Charging Port for Unlimited 120HZ PC/Steam VR Playtime, USB 3.0 Type A to C Cable Accessories for VR Headset : Video Games Any cable like that should do the job

Yes, but as @SkateZillasays, you wouldn´t need to edit the file every time you go into the options menu. Yes, I guessed so, but it´s better than editing the file whenever you go into the options menu for other reasons. It´s just a temporal solution before they activate it officially (hopefully soon) like your upscaling (DLSS) greyed-out menu .

Maybe we could ask @SkateZilla to be able to enforce this option in the DCS Updater app?

That´s a well-known bug by Varjo users using Mbucchia´s quad views as well, I think there´s a mod somewhere that makes all your FOV have the night vision on. Ok, I had a look and apparently is this one Tacca's NVG mod 1.2 for 2.8* (digitalcombatsimulator.com)

To be honest, just before I started testing the foveated rendering I cranked it up to 4x and never looked back. I will make some tests with different values to observe the effects that it has on the game and if it is noticeable or not.

hahaha that was me trying to change something in the wrong window

The settings that are in the attached image below. And in regards to supersampling, the idea is that this meta-foveated layer is doing that supersampling where you are looking at and downsampling where you are not looking at, that is where you gain the performance. If you use supersampling you are adding more resolution and then you have to lower your settings in meta-foveated. When I suggested that way of configuration is with the idea of creating a base where we all can test from. If you start mixing up Oculus app supersampling, ODT/OTT one, and then Meta-Foveated it all becomes crazy and unnecessary as the numbers in the end are going to be the same at some point to gain the same performance.null