Dangerzone

I'm confused by the poll. Is this a question about: - what you'd like to use? (ie - what interface you like the most), or - what you have to use to get the best performance for your headset (ie, some are best to use OpenXR because that's all that will give them decent performance, others have headsets native to steam, so they will probably go with something that gives better performance with steam), or Because from my perspective it seems like the answer for each person will be dependent on what headset they have and what gives them the best performance. I was running SteamVR on a G2 up until I'm guessing a year or so ago where I almost gave up on VR and came across OpenXR which literally saved DCS. I didn't use OpenXR because I wanted to - it was a necessity. As such - it seems like it's more a popularity contest on which headsets are the most popular? (Although I admit - I am still confused about VR implementation even after using it for years so it's probably my confusion and not the poll?)

Not seeing the contradiction. VR requires rendering twice for the same frame. What I see he's saying is that if he can go to 2D where the same render is used in both eyes and you've got to be cutting down a significant portion of the processing, thus allowing better graphics on older hardware. The logic appears sound to me.

There may be more than one way to skin a cat, but for most of what I've experienced with lua - I don't use triggers. Instead I use event handlers (which I'm assuming might be a lower level of what is used for the trigger side of things anyway). As for tutorials, there's a number on the internet. I don't really have any off the top of my head that stand out. It's probably a matter of having a bit of a dabble and see how you go. The first thing that I had to learn was that running some files don't actually "Do anything" - all they do is load additional functions that you can use after that into memory. (MIST and MOOSE are classic examples of this - you can add them to your mission and nothing changes until you actually start calling the functions). These are basically a library that needs to be utilised before they do anything. Other scripts aren't libraries as such - but active scripts. If we go back to talking about events, a simple example of this is EVENTS.Dead. You can hook the EVENTS.Dead event so everytime something becomes dead - it will trigger your function. This is an example of hooking EVENTS.Dead: evh1 = EVENTHANDLER:New() evh1:HandleEvent(EVENTS.Dead) function evh1:OnEventDead(EventData) if EventData.IniDCSUnitName and string.match(string.upper(EventData.IniDCSUnitName), "HVT") then MESSAGE:New('Mission Complete', 30):ToAll() trigger.action.outSound("win.ogg") end end --OnEventDead / evh1 In the above - everytime the EVENT.Dead is triggered it will run this script. It checks the unit name. if the Unit name starts with "HVT" it will consider the mission a success, and play the win.ogg file (provided it is loaded into the mission editor) and display a message. (The message above uses MOOSE, but you can change this to use something else if you want). That same event handler can be expanded, so you can have multiple checks in the one event (or trigger) instead of 2 different triggers the one event is used to compare 2 different scenario's. ie: evh1 = EVENTHANDLER:New() evh1:HandleEvent(EVENTS.Dead) function evh1:OnEventDead(EventData) if EventData.IniDCSUnitName and string.match(string.upper(EventData.IniDCSUnitName), "HVT") then MESSAGE:New('Mission Complete', 30):ToAll() trigger.action.outSound("win.ogg") end if EventData.IniDCSUnitName and string.match(string.upper(EventData.IniDCSUnitName), "DONTKILL") then MESSAGE:New('Mission FAILED', 30):ToAll() trigger.action.outSound("failed.ogg") end end --OnEventDead / evh1 This now does 2 checks - the second if the unit name starts with DONTKILL - and if so - it will fail the mission instead. The beauty about doing it this way is that I can have a whole bunch of these created in a single .lua file - and have it load on all of my missions. I don't have to redo any custom scripting - provided I use the unit names above, it will trigger. If I don't want certain things to trigger in one of my missions - I just don't name any units with that naming prefix. CFRAG has designed some cool stuff that doesn't require any lua coding at all that's probably worth checking out as well. I come from a programming background so I much prefer to type out all my code in a text editor rather than use a GUI with a bunch of checks and stuff so LUA fits me much better, but YMMV so before you get too invested, check out the different options that are available. The more you get comfortable with LUA, the more functions you can just dump in your "loader" on your misisons. There's some really good stuff out there including a disembark script (that basically once a vehicle is hit may have some troops jump out of the vehicle), CSAR (when an aircraft goes down it will auto-SPAWN pilots that can be rescued using helicopters, etc') - that are basically like the above, just hundreds more lines - but the beautiful thing is you don't need to know it - just load it in your mission and the functions just 'work'. Like the basic script above - many of these can be done just by running the script and it's fully automatic. (such as the original CSAR by Ciribob). Others are incorporated into MOOSE were all you do is run the MOOSE command, and then add a couple of extra lines to your mission just to 'start' certain functions that you want for that mission. I hope this is helpful.

The missing tail on the aircraft seems to have been introduced with a patch since my original posting (at least from my experience). I have experienced the 'invisible tail' bug as well more recently in Open Beta but the original incident that I had a month ago the tail was definitely attached so I believe we're talking 2 different issues. Mine is with repairs, that worked completely except for the APU / engine desync. I haven't done any repairs since this last one so I don't know if the APU issue still exists as a bug or not. No one from ED has confirmed it as a known bug so I guess we'll just see what happens in the future.

That's why I posted this in the AH64 thread. I agree there. I think the Apache for the most part has been a really good experience of early access. The flight model and SAS was probably the biggest hiccup. It seemed fine at release, but then went through a period of stability issues with extreme rolls. However I was able to work 'around' these issues at the time but they were probably the most annoying that I came up with. Compared to some other module's releases the Apache seems to have definitely been one of the better ones. (At least from my limited experience).

I know YMMV et al - but I am really enjoying early access of ED's modules - probably more-so than if I had access to the full module immediately. I was thinking about this last night. If ED had released AH64 in it's full module - would I have had as much entertainment with the Kilo's - or with the Lima's with the range target and fire, or would I have gone full FCR and pretty much stuck with that? Having the features creep in over time allows me to get the hype on the Apache when it was first released, then get the hype again as more features are added to it - instead of just a single bit of excitement. The challenge of trying to take out a 'veteran Tunguska' with laser guided missiles instead of just switching straight to Lima's for a year or so too. It also gave me time to more thoroughly learn the different systems so I'm not as overwhelmed. I'm convinced that I'll have far more use from all the systems by the time it completes early access than just getting access to the entire ship straight up. Seems like my $'s go further this way. I acknowledge that not all people would be in the same boat - heck I may be unusual and unique like this for all I know - but the concept of early access definitely works for me. I also acknowledge that EA isn't without it's pitfalls (bugs, early flight module issues, who would forget the 'SAS Saturated' beeps , etc) - but the gain definitely outweighs the pain. Thanks for making Early Access a thing ED.

I don't have an answer for you but I too am very interested in this too. I'm guessing it would give you more a feeling of being in a 'Simpit' with a curved projector wall around. I can also imagine it would be great for working on video recordings too (given that in 3D VR your eyes will be left and right of the HUD and the mirror only mirrors left or right so will be offset - whereas with this approach 100% of the GPU is dedicated to the 2D rendering giving better recording plus it would be easier to work the 'camera position'. Basically Track-IR on steroids.

There's not much difference between using the blocks and a lua file to be honest. A lua file simply makes it easier to edit/read what you're doing as opposed to doing it in the mission editor blocks. Likewise, doing it in a file - you could have a menu in DCS that is a 'dofile' for your script, so you run it through the F10 menu, and if it fails, instead of having to go out, back to the mission editor, change, and then relaunch - you simply edit your file while DCS is running, save it and re-do the F10 menu again - giving you an instant 're-run' option of your script. But either way - unfortunately what you're trying to achieve is going to be difficult. There's no native way of doing it, and even with that lua stuff - there's no clear path I can see - it would be a matter of spending a number of hours trying stuff to see what works.

Oooh - this has peaked my interest. Does that mean there's certain days of a year that can be programmed in where the sun will be 'setting' on the horizon for a 24hr period. I ask because one thing I've always wanted in DCS was to be able to freeze the time of day to make things easier for videoing / cinematics - to give all the time in the world to get angles, and pictures, etc. This may be one way that this could be achieved - by using this map instead.

You will have to edit the .lua yourself and put in an if command - checking for the unit name using something like string matches and only add that to the table if the string starts with Groupsave_. The way it's currently written there is no variable to set - you'll need to make the change yourself.

If you mean using the script to import templates, then yes. The script that was provided in that post does work - although you may want to strip the UnitID out of the table before spawning. I use the script quite a bit to inject various scenario's into running missions in real time. If you mean to 'import templates' using the mission editor - yes, I have done that too. (Saved an existing .miz file as a tempalte in the mission editor, and then opening up another and importing the saved 'tempalte'.). I tend to just call it 'Temp' or similar and overwrite the previous one saved in the mission editor so I don't get a huge list of templates I'm not interested in keeping for once-off's. What you could do is create the original mission (with neither sides units) as the base mission. When saving it - zoom right in to the top right corner of the map when saving (and have the other designers do the same), so then when you go to import the other missions - the person that's doing the compilation of all the missions into a single mission doesn't get to 'see' anything else accidently. Obviously there's a bit of an honesty system here - but you're only talking about one person who's merging the files into a single mission at this point. Alternatively - the script to import the templates will work as well - saving anyone having to even go in or use the mission editor. Obviously though it's lua scripting, so requires a bit of knowledge (including desanitizing the server so it has access to "require" as well as the LFS/OS stuff). The benefit with this though is that you don't have to merge stuff. Once you set up your base mission you can just update the .miz files (copy them over) and have them re-load the new ones in if this is something you will be repeating on a weekly basis making short work of it once it's setup. So I know both solutions will work as I've used both. It's just a matter of whether you want to mess around with scripting to import/spawn the stuff on the fly in the mission editor, or whether you want to just do it manually prior using what DCS already has to offer.

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.