Pikey

Thank you for these answers! Yes, very helpful. So typically I head to OpenXR tools for WMR and reduce the number there first to save the pixels being pushed which is the largest FPS gain, then make up the image quality in game with the upscaling toolkit. First one starts making the image jaggy, second blurs a bit? Is this roughly it for the layperson? Please correct me if I misunderstood! Cheers!

Hi, I am trying to understand the methods to tune VR scaling (everything works already) using OXR and HP Reverb 1. I need some help with some basics, specifically the interaction between: OpenXR Tools for Windows Mixed Reality | Customised render scale (as per screenshot) OpenXR Toolkit | Upscaling/Sharpening NIS | Size (as per screenshot) QUESTIONS 1. Is the render scale on OpenXR Tools for WMR applied before the OpenXR NIS upscaling? 2. Which direction of render scale does what effect? I read on Reddit that 100% is auto adjusted based on GPU RAM but is this 100% of the GPU memory adjusted figure? i.e. is 100% the same resolution for everyone? 3. In VR headset the NIS upscaling "Size" setting requires the user to increase the number to reduce the screen resolution to improve the performance. Is this AFTER the Customised render scale or does it Overwrite that scale or something else? 4. I see NIS, FSR, CAS. CAS has no resolution size. What helps me pick one, what should be better for DCS? I can't really tell easily in game as I have to restart between and it seems no different. 5. Is the DCS VR setting, is Pixel Density applied after or before any of these and does any figure other than '1.0' help? 6. How will any of this be affected by Nvidia DLSS 2? Applied before, after, in the middle somewhere or not at all? 7. When either tool says to Restart VR to take effect, does this mean you need to close WM Portal mirror screen? I'm sorry for these questions, good answers will help choose which slider to set before another and save hours of testing

nullThe OP asked about the core game files, without conflating module and game files, which are seperate for good reasons Note that I never said 'lazy'. Don't put words in my mouth. I said 'didn't look'. Let's look then: https://www.digitalcombatsimulator.com/en/support/faq/ It's the fifth question. https://www.digitalcombatsimulator.com/en/downloads/documentation/ Beautiful tiled wall of module documentation ready for selection. From Google, its got the answer right there, it's even got a video with 5400 views. I maintain, this is not looking for the documentation. So the last thing to wrap up is why negativity was attracted to this post. Let's see, someone writes a sarcastic topic title: Why is DCS documentation so darned SPECTACULAR?nullnull Where not once but several times they state they can write a better manual than ED, proclaiming that if it were not a fail and was more prominent then they would be able to find out how to use a Windows dialogue box to save their campaign. Yes, the question was, where does it need to be saved. And the answer is that it is completely irrelevant. So we gotta go to the forums to be sarcastic because that's how adults behave, instead of simply asking the question "Does it matter where I save my campaign file?" without all the sarcasm and ranting. And folks wonder why, after years of seeing this behaviour (and the repeat quesitons) why we cannot hold people accountable to acting like adults and thus being treated like adults. It's simply a matter of how you ask attracts the answer in the format you asked it. That's why this happens and it shouldn't be a mystery!

Not to the same screen (anymore), but some displays can be exported to other screens and you can use multimonitor https://wiki.hoggitworld.com/view/Exporting_MFCD_Displays for exports too. There was some software that allowed some resizable export windows but I don't think it is developed anymore.

Yes Rudel most likely has it. If you have two networks separated by two different routers they are naturally unaware of each other, Networking isn't plug and play, each router is creating an internal network and its going to require some configuring that goes way beyond a forum post that includes how you configure your wiring, default gateways, subnet masks and DHCP. Luckily there are videos on the topic so you should find what you need. Good luck.

The Campaign editor works on a linear "did you achieve the set goals or not" basis. Yes>proceed to mission 2, No> refly. It's what all the DLC is based on, so you could review those or some of the existing campaigns that come with modules to see some ideas. To 'get the most out of the mission builder' you would generally not use the campaign builder and would use Lua scripting using the Simulator Scripting Engine which might be out of scope for you, I can't tell, but its not a mainstream activity. There are some off the shelf scripts that have very little configuration that can extend your play. You might like to try a bit more like DSMC and leave your PC on to keep coming back, or servers. But for the vanilla ME the depth is not in the campaign builder, but in the extensibility of the scripting.

So this is a thread about not finding the manual that changed to why the products manual aren't in the same place as the purchased modules and eventually ending up in some casual moaning about how much they are advertised to the surface. The part that irks me is when folks don't look and make the assumptions based on what they could see without looking first, then backtrack to find anything else to moan at to cover the fact they were in error and should not depart from that path with a simple "Ignore me, i found it, thanks for your help". Having written manuals, and being a techical writer with access to the analytics that show who reads them, I know exactly where the problem is. So when people say that ED needs a good <expletive> manual, I disagree. With evidence.

USS Bowen is looking a bit odd these days

Watching the love going into this project is so heartwarming. The lanc was my favourite bomber as a kid, no idea why.

I'd check the logs for compiling textures. If you just got this map then ran it this could be attributed. NTTR is normally one of the most performant maps in DCS. Read the dcs.log.

I did ask the Moose Community Discord, there was minimal and duplicating feedback, so no follow-ups here. Your average DCS pilot won't understand much of why adding more detailed terrain API's help them, right up until they ask why all the artillery is pointing into a tall building. Turns out that was true of the people that consume Moose in general. What had me absolutely baffled was not trying to use the 2200 folks on Moose Discord to get more visibility on this request. So much effort is still being siloed in the community amongst its time zones, languages, Discord servers and individuals. FWIW if any of the items turn up this year all communities would be delighted without reservation. You are welcome to use MOOSE Discord to announce project milestones or new technologies, we recently integrated a MOOSE voice class to optionally utilise gRPC as its cloud voice output, last year we ventured into a socket class, cloud speech and a couple of bots to see if MOOSE can break out of the mission environment so it more relevant for things that can interconnect to be mentioned than ever before.

So for context I did in fact do searches of areas going back to Nevada map and literally every fence and rubbish bin would report a bomb hit. I dont think anyone wants that, it made using this harder. I prefer the objects weren't returned. But above all, I really think consistency is the most important when we deal with code that can make DCS customers go wow. I'd rather know it was consistent and a goal of map development, than either of the possibilities.

Seems OK for me using the 5 lines of scripting. something else going on. beacons.miz

Thaaaanks!

I think this is a common thought shared by many. I don't think there's much comfort in this direction since the initial ww2 assets were funded by the failed 3rd party project many years back and there's another quote from Nick way back on the cost to create these assets being quite high. In this way i think DCS is a bit of a victim of it's own quality, i'd like a lot more AI planes and ships at the cost of some of that quality but it seems they want to model every nut and bolt these days.

Thats a display driver crash and partial recovery and you will see it in your System Event Viewer. This might be a driver issue, I think a while back there was some talk on a certain Nvidia driver version being bad and people rewinding version. Try the most obvious like updating that. Elsewise read out the event view system errors at the time it happens and it will give you enough to chase through to conclusion. GL.

Sounds like my old one when the cable went. If you hear the ding dong like a USB connect its the headset intermittently connecting. I'd humbly suggest you began troubleshooting on the headset without DCS, get it setup correctly first with the accompanying WMR software.

Did anything ever come of either a Greek or Turkish F-104 skin? I didn't find anything and was hoping to create some 1975 action on the Syria map.

This is our yearly mission statement and achievement wrap-up post. This continues in the theme of: Discord developments As of December, there are over 2160 Discord Community members. This is up y-o-y from 2021 by 600 contributors. Over 400 participants contribute 5 or more separate messages. From 2020 we can count double growth. The top ten list of Discord contributors is here taken by the MEE bot: One of our two main developers, AppleEvangelist, is almost single-handedly propping up other contributions to the Discord, to show that your questions are answered by a developer (as long as they are answerable and on topic). We are all very grateful for the time he and everyone else that contributes give up of their free time to help. Frank had a clean out of the Intro section and updates the #FAQ and we now have a dedicated Moose Discord bot that parses logs and offers advice when it sees log parses. GitHub statistics Master branch commits 2015-2022 (green) File size December 2022 - 8.7MB File size June 2020 - 5.9MB Over 4600 commits, 46 releases, to master branch from 33 people Yearly over 1MB of growth in code. 1MB = over 1 million characters a year! Thats a lot of fingers on keyboards! MOOSE is a community project, the code is open source and we very much appreciate all participation. We have participants in many ways, by committing code or documentation updates, by responding to people's questions in Discord and online, by providing feedback and suggestions and even just asking questions to stimulate interest. MOOSE was originally created by Sven (Flightcontrol) in 2015 and is now over 7 years old and we can see from above that maintenance of it continues regularly. For interest, Flightcontrol ceased development at the beginning of 2019, FunkyFranky began developing on MOOSE in 2018 and AppleEvangelist began in 2021. We welcome any new developers, no matter how small the contribution. The above statistics are relevant to the main branch. There are two main branches, Main and Develop and the primary difference right now is that the Ops AUFTRAG hierarchy classes are only available in Develop (more on that later). This slightly distorts figures as the commit rate to Develop can be higher due to the extra classes. These are the commits for this year: As you can see, if MOOSE is dead, it's going to need a stake through the heart at the very least. Class developments 2022 was an excellent year for innovation! New classes, additions and fixes: Ops.FlightControl. This class provides Audio Air Traffic Control just like AIRBOSS class, to land installations. We've iterated on basic sound files to utilise @Ciribob's excellent Text-To-Speech and deliver audio messaging via SRS direct to your ears. https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/OPS.FlightControl.html Ops.Playertask. This class supersedes previous Task classes by providing a framework for players to have a task system give them things to do in a mission based on automatic discovery or manual provision on any single unit or group of units and including scenery. This amazing class also uses our modern, localisable, Text-To-Speech system from Google. https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Ops.PlayerTask.html Ops.AWACS. This class can guide and direct both AI and player clients together, in multiplayer, to intercept trespassing enemy planes in defined friendly airspace using Google TTS over SRS for the messaging delivery. We use NATO brevity as much as is possible within the remits of simulating a Human controller (anchoring is nigh impossible and simplifications to process are required). This would typically replace crude text to screen for BRAA and attempt to provide realistic engagement using human like voices for targetting allocation with a number of reality and era options. Whilst it won't exceed a human attempting to provide a AIC job, it better than any other scripting solution out there and represents a world-class solution not seen in any other simulation to date. Ops.PlayerRecce. Inspired by Gazelle helo scripts used on MP servers, the Recce class simulates optical detection by the Player which is otherwise impossible to script (because a computer doesn't know what you can see). The class features a number of hooks that can be used to link to other scripting actions - passing the target, for instance to AI for prosecution. Ops development. We are now at the end of the second year of Ops development. The Ops classes comprise of the AI Tasking system of "Auftrag", a three tier hierarchy of land, sea and air controlling classes. Over the top are two classes, COMMMANDER for direct execution to a subordinate class, and CHIEF. CHIEF represents the automation of spawning and attacking by an AI commander. These classes have been actively developed and refined since 2020 and represent MOOSE 3.0 in the evolution. SSE API additions (ToUnit) MOOSE will incorporate most API functions if they work and are useful. Additions from time to time are made by Eagle Dynamics. Fixes/enhancements: A great deal of work has gone into reducing on-screen messaging and migrating to Google Wavenet voices via Ciribobs TTS executable in the SRS installation. The future of DCS scripting is communicating via radio, not via imaginary writing on your canopy. L10N: We have begun innovating localised options for language in our code since we have embraced TTS. MOOSE Usage in DCS Missions Moose is used by 4YA and Enigma servers and many more, representing many of the large MP servers or 30% of the top ten populated individually named servers. This is quite an achievment given the Administrators are often already technically adept. Offline, MOOSE is used by @deadlyfishes very popular Through The Inferno (TTI) representing over 82,000 downloads and most of the top ten downloads. A vast number of administrators discuss MOOSE every week in Discord across the world, even in heavily firewalled countries like China. It is fair to say that MOOSE has had a huge impact on DCS whether realised by the individual consumer, or not. Legacy classes and supportability statement 865 closed tickets, 19 open Since many of the MOOSE classes were written by FlightControl it is fair to say that after he ended his contribution in 2019, we were left with a large support deficit that was not feasible to sustain as a hobby. Frank created the OPS classes as a result and we have concentrated development on fresh ideas, because sustaining someone else's hobby is hard enough at a code level. Here is the current list of "class health". Use the documentation to understand the class names (develop is used here) https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/index.html All Tasking classes - Deprecated (known issues) Superseded by Ops.PlayerTask All AI - Deprecated (known issues) and superseded by Ops.Auftrag and related Ops.Chief, Ops.Target combinations. No parity with the originals. All Cargo classes - Superseded by Ops.OpsTransport Functional classes (the mixed bag) Functional.Detection was superseded by Ops.Intel - Intel is simpler and has groupings and decay but not threat. It also hooks. Functional.MissileTrainer was superseded by Functional.Fox several years ago Functional.Escort was superseded by Ops.Auftrag (and appropriate task) Functional.ZoneCaptureCoalition superseded by Ops.OpsZone Functional.PseudoATC - Developer has indicated that using Ops.FlightControl is prefered Functional.Suppression - working, best effort support Functional.Movement - Deprecated, does not work, do not use Functional. ATC_Ground - limited repairs being made - best effort support All Ops classes have an active developer owning them. Wrapper, UTILS, Core are always supported Sound is supported with a nod to more effort going towards converting sounds to Google Text To Speech as static sounds are less scalable. Supportability definitions Deprecated - The guidance is to no longer use this class due to one or more known issues. (We never remove classes from Moose) Superseded - There is an equivalent class that is performing functions that are the same or close enough in design. "Best Effort" - The owner of the code is no longer supporting this and any volunteer dev is probably going to spend limited time Troubleshooting. Supported - The developer is active and answering questions. There are no guarantees or Service Level Agreements on what constitutes "supported". You may check the MOOSE Discord class channel and the history of discussion for a better idea. Future MOOSE continues to grow, evolve and innovate. MOOSE and it's community thrive based on the principle that a free community has no barriers. We are agile, useful and relevant to DCS World with a huge majority of DCS customers using MOOSE without even knowing. If you want to help, please use the code and talk about it here: https://discord.gg/gj68fm969S FAQ MOOSE has two main branches (master and develop). master: https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/ develop: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/ Download MOOSE (save as a file.lua): Release version: https://github.com/FlightControl-Master/MOOSE/releases Master branch: https://github.com/FlightControl-Master/MOOSE_INCLUDE/tree/master Develop branch: https://github.com/FlightControl-Master/MOOSE_INCLUDE/tree/develop As the documentation of MOOSE is created via luadocs on-the-fly from the respective Moose.lua, every class that is in the docs is also in the Moose.lua. User Guide A good place to start is the MOOSE User GUIDE: https://github.com/FlightControl-Master/MOOSE_GUIDES Youtube Even though a bit outdated, FlightControls YT channel contains a lot of useful information on MOOSE https://www.youtube.com/channel/UCjrA9j5LQoWsG4SpS8i79Qg/featured Especially the MOOSE for Dummies series is a good way to get your scripting juices flowing https://www.youtube.com/watch?v=ZqvdUFhKX4o DCS Scripting Environment All scripts including Moose eventually use the DCS API or Simulator Scripting Engine (SSE) to interact with DCS: https://wiki.hoggitworld.com/view/Simulator_Scripting_Engine_Documentation DCS Version Info: https://updates.digitalcombatsimulator.com/ LUA Resources - Learning LUA YouTube videos : https://www.youtube.com/playlist?list=PLxgtJR7f0RBKGid7F2dfv7qc-xWwSee2O - Programming In LUA (First Edition): https://www.lua.org/pil/contents.html - The Implementation Of LUA 5: http://www.lua.org/doc/jucs05.pdf "The best things in life are free"

I don't disagree AI could be better, however, it's irrefutable that you'll get closer to what you need by concentrating on solutions that are actually available to you. Waiting for wishlists is something i do not advocate, i'm still waiting a decade later, for dynamically created player spawning. Let me help your decision-making and solution. Things are not as simple as "When AI are in recovery stop players spawning, lock up cats and allow them to dictate players play times" Why would enforcing wait times for a cat work better than disallowing spawning hot on a catapult? Both restrict what a player can do for their own convenience. You either allow players to do what they want and work around that or you accept you have the forces of chaos in play and you can only limit the risks. AI waves off, that was implemented but it doesn't acknowledge players in the pattern. If you care about those things, implement AIRBOSS mod and ask players to follow its instructions as it will seperate AI and player. It doesn't mean they will, of course. If you want to advocate an AI change where they remain in pattern as your wishlist, then, whilst we would prefer to have AI crash into the sea, all it takes is for a player to sit on the deck twice in a row doing cold starts and a typical fuel load for AI would be expended and they would ditch in the sea. Which means AI are somewhat useless when Players are wanting to have their cake and at the same time, eat it. Your real issue is players not doing what you want, rather than AI who are predictable enough. The thing I inferred is that the start time of the player cannot be hard set for your scenario. Which follows it's a server that you can enter immediately and have unrestricted take off at any time regardless of what AI are doing. I'm wondering if you even set the wind for the takeoff because if you have a carrier that is always into the wind, its not 24/7. Which also raises other questions on the use case that render the potential solutions as 'out of scope'. Things you can change that can help - Limiting cat starts for players will always stop a crash from an aircraft on finals seems to be the most obvious solution - There is a network block switch to stop a slot being used called slot blocker. It would require heavily edited to be adapted to only get half of your requirement. It cannot stop the dynamic cat allocation, you cannot infer planes departing, you would have to create an incredibly complex layout of moving trigger zones to check in order to deny a player entering a cat and chances are, it will just block people from doing what they want anyway. Arguably pointless because you want hot starts on the cat so time is of the essence. - implement AIRBOSS scripting mod which will alleviate some of the organization for landing, create recovery windows with the wind which it sounds like you dont have, and provide insights to AI in the pattern via the comms it does. - Plan recovery windows to coincide with carrier movements and AI flight cycles in your mission (doesn't work with 24/7 servers and perhaps your use case) - Leave AI off the player carrier or drop them entirely (moving AI to another carrier is often done but players will still screw up your decks because ... reasons) - Spawning AI with proximity checks for other planes (there's no API for planes recovering as a query, you cannot tell from the mission environment, only their proximity) - Implement a scripting solution for recovery windows on demand (helps with the wind and carrier placement) - Delay the non-cat hot starts by putting no fuel weapons on which makes players be a little more careful as they have enforced waiting - Having a human coordinate the deck whilst players are involved - (this is done in some squadrons, over the top of ATC) Things you cannot change easily - How AI is coded - How players in a game will behave - What additional scripted control is available Take your pick and good luck!

You are right! I was wrong, I was thinking of take off from runway (ground based) which exhibits that behaviour as a server. That doesn't make any difference to your issue though because YOU are setting that configuration (start from runway/start from parking). I would not expect the issue is as simple as you state though, I've seen all sorts of results when blocking cats and my hunch is (feel free to test) that if you sit on Cats one and two, and start a slot that is set to start from Cat1, it might put it on cat3. The reason for that is that cats are dynamically assigned and the ME scrapped being able to spawn direct to any cat way back during early access. I don't think there is any scenario you want players spawning directly to catapults. Variations of this topic occur weekly - You must observe the AI for recovery options, they WILL force a deck open wether you think players should be clear to spawn in or not. The issue is not really about cats at all but the fact that the ATC will always allow planes to recover if they are AI or player. At worst they get wavedoff (if you are lucky).

It cannot be managed with any scripting engine. But the only reasons those locations could ever be picked would not be in the normal design of the spawn, typically with no other deck parts blocked, in MP you spawn on the 6 pack. If these are occupied or in use, there's a system of spots that doesn't cover spawning directly onto a cat. In fact, spawning to cat is the same as runway start and not deliberately done in multiplayer, only accessible in single player. Having said that, you see it happen if something jammed up.

Hi Dolfo, DTC and similar has been talked about as being in medium term development for some time, there's no news on it, ED haven't forgotten but no one knows how far they have made it. One day, i am sure, it's been a very popular wishlist item.

Still solving problems for people in November by removing this junk. Now I can give you actual numbers based on a fix I did for someone logging a bug in the ED Discord. Before: Customer complains about over 30ms CPU frametime, DCS is terrible, ED don't care, 2.8 is bad, yadah yadah. Title of post: "VR unusable" After removing exports: CPU frametime down to 14ms. Happy customer, ED, we are sorry for blaming you. It's literally the difference between green and red frametimes. In VR this is about half of your FPS. HALF. Trouble is, if people don't know what exports are doing and how they work, then people will just blame the sim again. The only export I will put my trust in is Ciribobs SRS. As much as I love Tacview, it scales atrociously with large MP missions. Use servers where the Tacview acmi file can be downloaded afterward. As for other products, you choose, pretty lights or a working simulation.

It's quite a weird use case for sure. `This is needed for DSMC mod, to detect if the user launching DCS have access to the options menù or not. ` The fact that it was a requirement to be run before the mission executes in the plugin environment seems to me only be asking if the UI "could have" supported the options dialog boxes, not whether it was a server at mission runtime. If my logic is flawed we can rethink, there is always more to these questions!