Dangerzone

This is untested, but you could iterate through each unit in the group - check what is still alive, and then use a combination of: UNIT:GetDamageRelative() and UNIT:GetAmmo() ... to check the damage to each unit and to get the ammo count, and come to a conclusion from those values. I'm not sure how to check however (or even if it's possible) whether a group is now tasked for RTB (which is probably what you're wanting to check to see if it's retreating).

Is this the same request as the one asked 4 weeks ago? If so - you may have missed the replies after your comment, but there are already a few solutions to what you need that might be worth you checking out, including importing files as templates or scripts.

I'm seeing a lot of enthusiasm for the Kola map - which is fantastic. As someone who doesn't really know that part of the world well at all I am curious - what are the features of this map that people are looking forward to that other maps don't give? Are you looking forward to it for Air to Air / Helicopter work / A combination, etc, and what are you expecting from this map that will add to your current DCS experience?

Preparing for new napalm weapons maybe?

Hi Bailey, Thanks so much for the work you have put into this! Just wondering with the above comment, does this make DiCE compatible with IC - or does it simply just remove DICE from being active in DCS - thus allowing DCS to connect to IC activated servers - at the cost of not being able to use DiCE while being inactive?

Hi Shagrat, I've had some issues with s_event_dead since 2.18 IIRC that hasn't been resolved, so I don't think it's you - I think there's been some features removed from these events. As a sloppy workaround - if you able to get the position from event-hit you could add (or update) a table for the unit that is hit so that on unit lost - you could scan that table for the unit name and get the last known coordinates that were saved by the hit command. (I haven't tested this, I just throw it out as a potential workaround to consider if you get desperate). Cheers DZ

Fair question - coz I get the same results. My understanding is that the limit of the performance/frames is due to the CPU hitting it's limit (as opposed to the GPU). So the CPU has reached it's maximum potential in this instance. Whether the CPU can do more with BIOS settings changed, some windows services turned off, etc I don't think DCS would have a way of detecting. That would be up to you to optimize your PC. DCS is simply saying "I can't do any more because I've it the CPU or GPU limit - depending on which one is bound). As for changing graphic settings dropping frames but still being CPU bound - yup - that happens with me too. My understanding is that the CPU still has to do a certain amount of work for GPU changes. I get the same thing. I can increase my graphic - such as the PD because my GPU is underutilized but I push it to a certain level and the frames will drop as a result, but it still says CPU bound. I'm guessing whatever work I'm asking it to do - the CPU is having to work a lot harder too (maybe shadows, or something that requires CPU resources?).

Aaah - my apologies. I was thinking of a different setting. (I don't have my gaming rig available atm so couldn't double-check). That makes more sense.

Thanks for the confirmation. I'm going to have to recheck my configuration to find out what is going on. I tried the other day changing reprojection to off and it went stuttery, and back on and it switched between 30 and 45 frames so I assumed it was reading the "In Game" OpenXR toolkit settings, so I must have something strange going on then, or I'm running on an older version that hasn't updated. (Quite possible - because I'm pretty strict with my firewall - even windows doesn't get to update unless I give permission). How will it work in the future if automatic isn't an option? Do we have to set a single target frame? If I set 45 and it drops to 30 am I just going to get stutters again? Is it recommended to set it to the lowest possible frame likely to hit?

Before going to that level can you try this: With DCS closed: Go into your saved games directory. Rename your DCS folder to DCS.old. (This way you can revert it back to DCS if it doesn't resolve your issue because what you're basically doing is relocating ALL your settings/bindings/etc). Relaunch DCS and see if this resolves the issue? DCS will automatically create a brand new config (like a new reinstall without going to the full nuke effort). If this fixes the issue, then you can go and move back just the things that you really need. (The most common would be the config/inputs directory for your keybinds) and just change only the settings you need to change again. If in changing those settings you get crashes again - you can repeat the procedure until you nail down which setting is causing the crash. Sometimes some things just get corrupt in the config section. We don't know why or what - but doing this can be a quick easy way to resolving the issue. If this doesn't resolve the issue, or there is another solution, simply deleting the new DCS directory and renaming the other DCS.OLD back to DCS completely undoes what you just did.

Thanks for the clarification. In regards to the automatic function... are you sure? I run a G2 at the moment and have reprojection frames set to Automatic. It will switch between 45, 30 and if really bad 22 and back again depending on what it needs and how much load it's under - so from what I can tell, automatic appears to be working. (Unless I'm misunderstanding or we're talking about two different options maybe)?

Pixel Density (in DCS I'm assuming you mean) is used to super sample. Basically what it does is render DCS in a greater or lesser resolution to your native VR headset. Going less reduces the workload on the GPU, but will produce less resolution images. Going greater increases the workload on the GPU but can produce even sharper images in your headset as your headset will scale back to it's native resolution. DCS's PD is similar to Resolution in steam - however it differs in that DCS is a x resolution in both directions, where steam is % of pixels. Thus a PD of 2 is double the width and double the height, so don't mistake it for 200% - it's not. It's really 400% IIRC. The best option is one that gives you the best visuals without overloading your GPU causing stuttering. I personally have left mine at 1.0. As for the settings in OpenXR - I'd suggest start with the defaults and bit by bit try different settings until you get what you want. The main one for me was to turn on motion reprojection (in OpenXR Tools from within DCS - not from windows), and set it to automatic. Some like it on, others like it off. Because I can't hit 90fps in VR consistently I prefer the smoothness even if there's some ghosting compared to the stuttering. There will be more qualified/experienced people that will probably give you a better indepth understaanding than I can - but hopefully that will get you started.

I know many will probably disagree but all I can say mate is good on you for being honest and willing to contact them and work through a solution instead of saying nothing and keeping it. I have no love for Amazon, but it shows extra character when a person doesn't change their values because of another's lesser values. Good on ya mate!

To be fair - trying to see 2 sides here... the change that has been made has only been made so far on the BETA version of DCS... so there is still time for ED to consider community feedback on this issue (which is what OB are normally about) - and apply the best option for the stable release to come. However I agree that it's concerning that the response so far seem to be focused on a single issue (ie, the dots) and not the greater problem. ED has made a fantastic product, and I appreciate it's existence. For me - it's the only reason I have a 'gaming machine'. Passionate community members have added to this product to make it even better still. However in saying that - the above quote is IMO an underrated comment - and I think is deserving of a bit more attention. I would really like to encourage ED to have a slight change in mindset to consider with more weight what contributing community members are doing and how the changes ED does affects them - because for people to take so much time and effort into creating these and distributing them means that these are no small details that should easily be overlooked. There will always be the entitled, where what ED does is never enough - and will always find something to whine about. I'm sympathetic to NL and BN who really wear the brunt of this. But I'm talking about ignoring the noisiest to consider the bigger issue here & those who have put serious time and consideration into finding solutions that improve DCS for so many others - which the above poster has touched on and I'd like to elaborate further. Things such as optimized textures (Taz) that as literally saved numerous VR users from abandoning DCS, the new upcoming Mission Editor with some basic features people have requested for years, the Data Catridge Mod, Dots, as well as things such as Simple Slot Blocker, DMSC/Simple Save Groups, etc that make possible the severs we enjoy today. People have been waiting on these features, optimizations or improvements for a time significant enough that mods have been developed by users to fill these holes because there's no small need for them and there was no sign of these being looked at on the horizon, and it really hurts when ED undervalue the contributions made. Are we asking too much too soon of ED? I don't know. I'm sure ED dev's aren't sitting there twiddling their thumbs doing little... and that's where these community mod's really help everyone. It helps to give ED some breathing space in some areas, and give the community some solutions. But being involved with server management, mission designing, script designing, etc and working with others in this I can honestly say that there is a real feeling of frustration and even despair by a number in the community as to whether ED even appreciates the contributions made or would prefer if we gave up and just let DCS be what it is on it's own. The situation leading up to RuroniJones's all but abandoning Overlordbot has raised to the surface what a number have been feeling behind the scenes and we now are at a point where an incredible feature for MP servers is now being abandoned due to the lack of appreciation and support from ED, and I know he is not alone. I don't make this post to bash ED or to find fault. Rather I am sympathetic to problems I can only imagine that ED are facing and my desire is for the community to worth with them instead of finding blame. Going through COVID and now the current global situation - it's not great at all - and ED are still putting out great modules with more on the way, the final implementation of multi-threading is here, Vulcan being developed on, etc. I am very appreciative of the work that ED is doing. I acknowledge that it's very much likely that in a similar way that the community feels underappreciated by ED that some in ED may feel just as underappreciated by the community, which brings me to my main point: I just can't help but feel that DCS is being held back by a certain level of separation of understanding between them and the community that supports them as to what really matters to a lot of their customer base, and is underestimating the benefit of supporting those that support ED during these times or how the changes ED makes impacts them. My plea would be for ED to reconsider with more weight the needs of the content creators that support them. (And I don't mean youtube 'content creators'- I mean real content - those actually contributing to the development of DCS freely with their own time and what holes are currently being filled by community). I'm not sure what more we can do our end but plea. RJ approached ED, and then as requested - took the time to consult many of the leading dev community as to what is important and provide information directly back to the top (to Kate) and then waited patiently... for 2 years.... for nothing. I'm not sure where to go to from here? It would be very timely for ED to show a greater level of support at the moment for the community dev's to ease some concern and bring some focus to these matters. I would suggest how this particular issue of IC is addressed is going speak a lot louder than many probably realise in the community as to ED's broader attitude towards the community - whether things are changing, or whether they remain the same. I would really like to encourage ED reach out to RJ to see if some of this damage can be undone and see if the relationship between the dev community and ED can be improved. This would be no small gesture. Likewise my encouragement for the issue here (which is not just about dots but is about more community contributors having their work 'shut out' and underappreciated by ED) would be considered in it's entirety.

Yes - but not native to DCS. If you use Voice Attack you could issue a command such as "Pilot Source" or similar, which could do the keypresses for you. It's not realistic - so if you want full authenticity - it's going to be the manual presses - but if you're after something to assist you in-game for quicker acquisition - this might be suitable for your needs. I know when I'm in flight and I have my hands busy voice attack can be a real help - especially since it's not just reaching forward and pushing a button - but having to go to mouse, try and find where in the space time continuum the mouse really is (in VR - which is probably the longest step), then doing the button clicks.

I don't believe there is unfortunately. If your concern is players 'cheating' by using this when they're dogfighting, a better approach I could see would be for ED to give mission writers the ability to enable and disable this feature on a per client basis than just to say whether someone has done this or not. Then through an checks could be done to see if the client is within x miles from an enemy aircraft and if so disable this option otherwise enable it. But as for how to achieve either what you're requesting, or what I've suggested - to the extent of my knowledge I don't believe either is possible in DCS at this time sorry.

Guys, you're being trolled. You can't reason a troll and you're just wasting time. Your responses are just feeding more of the same. To ignore - move your mouse and hover (don't click) over the name to the left of the post. A dialog will appear which you can click an IGNORE button. As for the IC check - I believe this might also destroys all Taz's wonderful work that allows many in VR to get the performance they need with optimized textures, etc, so I really hope that ED's response to this isn't just to fix the 'dot' visibility.

The one time I started seeing that problem was when my cable was starting to go faulty. Not saying that that's the case with you (I hope not), but maybe check your connections, etc. If your head position is changing randomly - I doubt it will be DCS - it will be the headset tracking itself.

Slingloading a camel. Love it! While we're at it, we better have an elephant crate so we can do a "Dumbo" drop from the C130 when it's released.

Oh - and just to confirm - did you buy through steam, or DCS World/ED Directly? If directly: Can you log onto the dcs website and look at your account and confirm that you have the module there? If so - can you then go into DCS, log out from your account (Top right icon if I recall correctly - I'm not at my DCS PC right now). Close and then restart DCS. You should be asked to log back in. Make sure you log in with the credentials you used on the website, and advise if this fixes the issue? If steam - I'm not sure if Steam has a repair function but you may need to run that separately. IDK how steam works

Oh absolutely - but your first post was about HB mode, and I agree - that sliding left/right, or forward/backwards for a bit shouldn't case the problems to the extent we're seeing at the moment. Hopefully the problem will be acknowledged as reported.

Before replying.... please don't take this too seriously! It's just a thought if ED team were looking for ideas for the next easter-egg/haloween/etc tweak/ silly gift - might be worth considering since we have the Persia Gulf and Syria (The further eastern area), plus Sinai and Australia coming - which I believe all have camels. The suggestion is for a camel UNIT (not a static object). One were paths could be set to have them walking around through the desert. It could give a bit more immersion (especially for the low flying helicopters) to come across either a caravan of these, or just wild ones out in the option - especially on those longer flights where there's not much but sand about. Consider it sort of a 'one upmanship' on the cows that we have - and I mean... who doesn't like the cows! (Couldn't hurt those cinematic videos either). As mentioned, please don't take this too seriously - I recognize there are far more important things that are needed in DCS, just throwing a random thought out there for a bit of a fun discussion.

I have experience the same thing recently - there's definitely a problem here. Thanks for providing the track files. FWIW - I don't recall having as many problems in HB when it first came out, so I don't know if it's an introduced change with continual work on the FM because I used to be able to slide left/right without issues. At present I now have to treat George like he's suicidal. Keeping one eye on everything he's doing and ready to reach for the controls at a moments notice. It's not ideal for high stress environments (certain missions or MP) at the moment, so hopefully there's a fix in the works. Not seeing an rep of ED respond to this thread yet is a bit of a concern - so hopefully it's been reported internally and is already been looked at and responding to this thread was an overlook. Confirmation of this would definitely be appreciated. The workaround I am using at present is not to get George to make changes unless I absolutely have no choice. Instead, I'll take control - I'll change the attitude/altitude/airspeed of the aircraft and once stable I'll give back to George. Not ideal, but the best I can recommend is accept that these flaws currently exist with George, and don't try to fight them but work with them and around them for now. It's WIP and early access so I really have no other choice, except to get frustrated or leave it until it's resolved. The other night I had to fly from the front seat while also trying to lead-follow a moving unit with the laser while a hellfire was in flight. Talk about a high-workload situation. Mind you - it was a feeling of great accomplishment when the (second) missile hit and destroyed the target. The new Radar guided hellfires may help to reduce a bit of this workload when they're released if George isn't fixed by then.

From a VR pilots perspective - if this is to be implemented can it please be done as an option and not as a permanent change. (I understand the OP's desire to do this, but for VR users this could greatly increase the risk of headaches or motion sickness). As far as simulations go - I'm not keen on having 'real' sickness (headaches or nausea) added to the experience of DCS and I'm fairly confident most other VR users wouldn't want this either.

But Taz says in his original post they won't pas IC? But people are saying that they will/do? Is this only for some, or are all of them OK to use?