Pikey

Interestingly I was in the aerobrake camp until it was shown that what happens in the sim is that the sim prefers to get on three wheels as soon as possible to make the overall stopping distance as short as possible. I think the quoted distance all told was about .65 NM for 3 wheels and .75NM for aerobraking until nose down. The tests weren't amazingly detailed, but its still some data. Hearing that aerobraking is more effective in stopping distance IRL means that the sim has some work in this regard. I think the same is true of the Mirage 2000C module, this is probably an "edge of envelope" example where FM's tend to deviate from published data. The great thing is, you can know this and still (attempt to) do it the right way without any major logic flaws or feeling of shame, but be prepared to defend your choice of doing it the less effective way in the sim.

Just some thoughts. I love listening to anyone who wants to add to DCS. I have great concerns over DLC management, multiplayer and divides. I would like to see everyone able to log into a server with said DLC and not be excluded. I dont mind the method, e.g. Supercarrier method, is fine, but creating missions and having to exclude people without, damages the community. I'm mostly interested in assets that exist to fill the numerous gaps in DCS right now - Insurgent vehicles, static objects of better quality buildings, civilian ships and aircraft, COld war assets, missing aircraft, and so on. Many gaps. And a repeat of the important one again... I have a group, in that group, its a 40/60 divide on who owns/does not own the WW2 assets pack. I don't get to use it because of that. It really really sucks to have something, and have no one to use it with. I cannot tell you how important this matter is, it requires being addressed as a primary goal from the outset. Potential solution - offer extremely low level detail lods or specific services and capability that allow everyone to use the content but only those that have purchased to get decent usage. Thanks.

I think to sum up the post the request is for a feature that clamps the mouse pointer to cockpit switches. Apparently this is like the civilian sim. It's not a feature in this sim. Some requirement to be able to move the head in conjunction with a mousepointer is normally required for DCS VR. The mitigations for lack of the feature are: 1) Using the key binding. 2) Binding the more common keys to HOTAS peripherals 3) Using zoom to minimise the movement caused by the head. If Im honest, my head isnt the most accurate pointing device, my mousing hand more than makes up for this though and it comes fairly instinctively. Anything you need in a hurry is best bound to HOTAS. The feature request is definitely something I can get behind though, its not just helping people with poor necks we all have to contend with lots of motion and the feature would help.

Hi there again. So you dont need to explain your design, it is what it is and it is SP centric . What I was outlining is just possibilities. I see you have technical skills, don't be afraid of Lua, it's fairly easy to copy pasta learn. What you could do is look at Simple radio mod https://github.com/ciribob/DCS-SimpleRadioStandalone/releases to see a Lua plugin and options. The difference between ED core plugins and 3rd party mod plugins is their location. The latter is in your saved games. A plugin is a format designed to be used to allow a UI in game on the games options page. It then configures global variables. There are two sides to looking at additional scripting - from the mission, a locked down environment, designed for limited scripting api to the simulator scripting engine https://wiki.hoggitworld.com/view/Simulator_Scripting_Engine_Documentation mainly used to enhance the mission by allowing direct lua to be run rather than the mission editor conditionals, and the server side API which plugins only can access (but can also access the mission environment) )look in your install\API\DCS_ControlAPI.html for the extra API functions. The kills, takeoffs, landings etc are realtime simulator events. You can attach handlers to them and do what you want with them. The Sim takes these and creates that debrief log you use. However, you can do all this yourself. So, one such approach would be to run a plugin that captures exactly what you want, in a format you want and writes it to your own file, or indeed as others have done, export to json or other mediums and sent directly (or entered into a local sqllite). Because these are realtime, you can even have the game crash and save the statistics for MP and be better than the game. There are lots of examples over the years of people creating statistics. SLMOD was fairly defacto at one point. The last one I saw is still WIP but you get the idea: Hope this broadens your experience anyway. I dont know if its entirely what you want or need but feel free to PM me or find me on the MOOSE scripting Discord.

The visibility range is not related to ugra, its set by the engine and your own settings. Some ranges are tied like the night lights are a fraction of total view distance.

Oof what a tease! Did you see Cyprus and the new clouds rogether?

Sorry to say, ED do not provide Empirical feedback, this is why people do this themselves. ED do read, and often they learn from the feedback, but they always ask us for tracks and empirical data because often the vague feedback doesnt help them refine the product. So, passing that on, an opportunity was missed to see what frame times, stutters, FPS changed with what settings. Thats all.

Don't read things into something that was never said. Read what I said, to quote myself, "This was a worthy post". You specifically asked for feedback in the title. If you don't want feedback then don't ask for it! I'm letting you know, I didn't see 'no stutters' myself. I also explained that stutters have multiple sources and configuration alone is unllikely to fix some sources (mission). Have a good day!

Tacview is an absolute murderer on large missions. How much it hurts you will depend on the size of the mission, but just in case you wanted to know qualitatively, how wrong you can be, then: 1400 units On a few hundred units it will cost not an entire Frame, so use this guidance appropriately.

Dont take it personally, you might have many people read your post searching for VR improvements. If it worked for you, you should probably say 'what' worked. What is a "massive difference", for example? One less stutter per minute? Is it quantifiable? I'm feeding back because the time people put into VR tweaks is... let's say a non empirical word here.... "too much" There is also a lot of overlapping setting suggestions which causes duplication of reading, writing and loss of time. A few good posts would be better. Additionally i am compiling this data in case that can actually be done, but there lacks any empirical data to say what is worth doing, sadly To me, I consider it better for the community to have more information in fewer places, rather than many posts with little tweaks here and there. Don't worry the post is helpful, it oculd be better. I tried to google "CPU priority registry setting for DCS,VRServer, VR Compositor site:eagle.ru" and the only hits were this post. So this is a prerequisite but its not referenced? That sort of thing woudl help to go from good to awesome! Thanks.

I didn't 'notice' any positive gains following this, but its' fairly hard to tell because to introduce one of the many different types of stutter you have to introduce complexity to the mission which affects your overall performance - so very difficult if not impossible to say. The PD was three tenths larger, the SS much lower (this is contrary to the low PD, high SSS ratio that has generally been found to give back many frames.) I didnt understand the saving on AA which doesnt cost according to extensive testing. I also added Kegetys Shader mod at the same time, so again, very difficult to tell. I also didnt follow all of the prerequisities which were many, they required searching and I'd prefer not to guess at them. 90 FPS in the menu is normal for any settings of course. I can get 90 in single player in cockpit up high in many cases, where this stops is on the ground and in multiplayer and with mission complexity. 1400 unit server with scripting and lots of AI - 35/50 is really good for my 2080S and i5 8600. The parts I think where this is interesting are the NV shader cache and low latency mode, which I believe is the point of this post. Maybe its doing something, maybe its intereacting with the slower IO of a disk, I dont know. Id like to say it did something but removing the windows virtual monitor for VR did way more in effect, so rather than say, 'it feels good', I will just say 'it doesn't feel bad'. The word "stutter" is overused and misused by many people, which unfortunately doesnt help the community progress and spreads misinformation. So I cannot say, I do or don't get stutters following this advice. I certainly get some pauses which last visibly a very long time inside the second, but I think the cause of the pauses are many. Texture loading is defintely one of them and this post does address in that ballpark. Your settings on visibility are interesting. Medium. I run extreme. This is for one reason I cannot avoid. Object pop in, especially city night lights is tied to view distance. You cannot see from one side of a city to another at night with Medium view distance, despite the large savings. There are good savings in view distance cutting coupoled with preload radius. You also state medium textures but show High in the screenshot. Confusing. I believe the terrain texture doesnt impact or change much in testing, but the cockpit texture does impact performance, especially when using high end stuff like VR. These factors are important to some types of stutter which affect quickly changing your view direction in VR. You can reproduce that by switching on a TGP, it costs....'something'. Overall its a worthy post but lacks decent empirical data to make it convincing and thus falls into the many tweak-guesses that VR users chase. By decent empirical data i mean before and after frame counts and stutter counts on a cited test mission. The OP is also devoid of the links that provide the backbone of the prerequisities so these all become uncertain. Also the screenshot disagrees with the words and doesnt explain all of the settings. A good post wont have follow up posts saying, "I forgot to mention ..." Also combine the third post with the second into the first, people don't read well! Please edit the original and keep it updated with any new information, this is complex stuff and we need good contributors to the VR performance scene in DCS!

Hi, lovely setup. I'm an MP only player, I tested it out and I thought I'd pass my early observations. I do this from what I found personally missing, but without mentioning all the existing features you implemented, so it will sound like that entitled rubboish you see a lot, but the idea is that it's just feedback without emotion. It's just an opinion . Your work is outstanding and I know the level of effort involved and how these projects are all encompassing Great stuff, I love it. That said, for MP, here's my observations. The debrief.log we dont actually use much in scripting or anything really in MP. Items like 'what pilot we were' (we were... "me") are irrelevant and even a bit confusing. Having multiple pilots, is also a confusing concept, I get you can have multiple pilots and they have nationalities and awards in single player but in MP, this is largely irrelevant and adds nothing, we have a playername. Also, "what side we are fighting". What!? . When filling out my first online flight I stopped at the log uploader and wonder.. well who was I really fighting and why does it matter at all? Most of the time we have to make it up like Westeros, Easterbly and Southeria. Simply isnt interesting (in Player vs Player), but what is missed is the mission name, the server name and that sort of thing. Maybe picking the answer... humans or AI makes more sense to MP players! Then the debrief.log deficiencies came into the light. Why did we have to enter our aircraft type? This should be autodetected, its definitely available to mission based logging events. We have three checkboxes which are utterly alien to me. "Set as training, show in the timeline, ignore undisclosed targets". Well we are dealing with data here and presenting it. You did such an amazing job with the presentation (i'm a DBA by trade) but have no idea how this impacts the presentation and data itself. For some, this is a serious matter. I would say when dealing with personal statistics, that this entire thing can be quite a critical thing Then another obvious and critical difference between SP offline and MP online statistics in step two. "In game flight date". What?! Oh right, we can create a historic pilot story with this... right, there are loads of people who will love this, but for logging for MP, nope, not in the slightest bit interesting, we want the timestamps of when we flew and inventing dates for the flights is absolutley strange for statistics, even to the point that its lying, it goes against what a flight log book actually is. So having two dates to track... that is confusing yes and even a little concerning. I didn''t have any expectations. I did have a wish I could make this useful for my virtual squadron, but no expectations. In order for this to be useful without grossly deviating from it's intended design, I'd have these goals in mind for Multiplayer with perhaps these design choices. Read that - this isn't entitled requests, this is explaining the different concepts and needs of two different userbases (and potentially more). It might help, I don't know, generally I'd be interested in the feedback if I were new to MP in DCS. - I'd scratch a lot of the fluff around the system that MP doesn't use. I'd use different designs. Out would go multiple pilots, multiple dates of flight, selectable aircraft, training/timeline toggles. In would come the data from the server, the playername, the birth events and aircraft types, mission data and automation. - The data would be set as a custom file to export, it would be a rolling log extract of what happened, what server, mission and events detected and it would upload to the pilots database online with one click, not 3 steps (thats the goal anyway ;)) - The representation online could remain very similar and show pilots by playername, hours in airframes, weapons and hit recorded, ejections, landings and such, however with very little customised changing of the data - it simply shows what happened without the story or pilot names/alleigances/fluffy stuff. - An optional empty segment to attach the data that can be added after (and I think in both SP and MP they have the same meaning) which is the After Action Report. An AAR usually consists of the "story element" to the log data explaining any notable things that happened. It's missing in the UI for SP and for MP. For MP it can hold data per flight and existing of commentary on weather, exceptional difficulties, damage, things that went right/wrong, lessons learned etc. Depending on the mission, you might add recon details and it is still relevant. For SP, it's almost identical, but you can add some more roleplay elements. - This might take the form of a Lua plugin, with options and UI in game, that have dialogues. Using the plugin could bypass the requirmeent to write and format your own log export and also protect the data with some obfuscation to make data poisoning less attractive. I undertand the usecase isnt the same and it's fundamentally hard to incorpporate these ideas, but it might be worth mentioning in case you wanted to embark on a branch of your work that deals with Multiplayer. If not, then to have the differences explained. I hope it's taken in the right way. I think what you did is incredible!

That its happening.

+1 its the only bomber on that side, its such a shame to have no bombing missions by bombers.

There's no racing and there's no winning. ED would be delighted for Kiowa to do amazingly well. I've heard much more noise about the Kiowa, at least seen complete streams with its operation. Both videos showed only what each developer wanted to show, for the Kiowa, appeared mostly done, in the case of the Hind it's way further out, assume if you didnt see it, its not ready to be seen. Might seem like a cynical view, it's not, its very very simple, the marketing machine shows you cool stuff if its there. No marketing, no stuff to show, not done, simple RoT. There are people like Wags itching to create content on new things, he's not holding back because he thinks it's amusing!

25MB a second which is unrestricted throughput from my provider, which beats Steam servers, amongst the fastest downloading of updates of any software on the internet, certainly faster than the company I work for terrible customer portals. The updater also doesnt look pretty but its also better than most commercial software, lean, to the point and moves like lightning. World class delivery imo. So possible the issue lies elsewhere I would say.

I've now got a prototype RTS conquest map using this, where these are spawned by CTLD, from crates picked up from airfields via a C-130. Just about to test slot saving and I'll be set to conquer the world. I like this new ED that gives us what we want, it's awesome

would love to have these please, have a virpil with two very similar knobs that are begging to be volume knobs for SRS. Many other plane modules have bound volume.

Regarding the Friday news: Maybe I missed the post that says thanks for adding in elements that weren't ever stated they would be in the Syria terrain module, but from myself, since I asked so much about them, I want to say thank you, because it (will) make the map absolutely amazing. Cyprus adds a Greek-Turkish possibility and turns the sea into a contested oil zone, future proofing the interest in the module being relevant to a broader amount of countries. It makes Turkey stand as potenital friend or foe on the map. It add the British base which is used in this theatre quite a lot, by other nations too. Greece becomes relevant country faction to create simulations with, which i'm sure the Greek guys are delighted about. WHen the Eurofighter comes out, it will have a home and we can plan modern misisons that we've seen in the last few years. Dier-e-Zor was the scene of most of the late war ISIL strikes, on the Euphrates and in terms of missions, key and featuring often. It makes 350nm between Akrotiri and Deir E Zor across the map. Shayrat and Tiyas' omissions were very obvious from the begining. Tiyas being strongly connected to Iran and both involved in several airstrikes, both being active, militarily. I missed them when looking to make real scenarios. If anyone was on the fence about the Syria map, get off and get your credit card out, it's beyond worth it, its got the highest number of unique model buildings on any map. Just Damascas alone - I recently made a mission to attack the Ministry of Defence and found I could use real world pictures for the brieding, because it was recognisable that clearly. Again, thanks Ugra.

Britain is a small country but, in terms of invention, a massive target for poking fun at. You could have picked any one of dozens of stupid designs created or excercised in the realms of aviation, in that period and we could have had a giggle. There are some truely hideous creations that barely flew. But, instead, you threw the dart at the board and missed the wall. Opinion is fun and all that, yes, you are welcome to it unreservedly. But the empirical data is very much at odds with your opinion. And it's an awful lot of combat data. Since it wasn't difficult to use the aircraft, for at least the majority of the pilots who used it successfully, we can only conclude that it's just difficult for you. That's a shame for you. And very brave of you to let us know. :)

I have no idea what this thread is going on about. It flies hands off. And, very easily. It's super stable. Whats more, after I got my friend flying it, 5 minutes after take off I asked him, OK, trim it for hands off and see how stable it is. He told me he'd already trimmed it and was hands off. He's an F-18 FBW guy.

People say that synchronous development of 2 or more seperate modules must make it longer to produce only one. Whilst that is true, it's so narrow minded as it considers only one module ever and not the larger picture of multiple, or indeed a continuous pipeline. Let's use some rough figures. 5 years to do the Hornet features mostly to release. You could say that doing any other similarly complex aircraft also takes 5 years. Then we have the copy-paste effect, which is actually not copy paste, but experience. Developers need to be familiar with the topic. Generally you forget things fairly fast. Does it make sense to do two similar-but-not-the-same radars at the same time or do one, wait 5 years, then do another? It does to me. Keep the skills current, od as much in parallel, even if it lengthens out the first module (which I dont actually think it really has, but whatever). I would argue this is the vital part people completely miss in their undertanding of (software) development. At the core of it, there are humans, with memories and skill. 5 years is a long time in someone's life. 5 years ago, I was doing very different things with different skills. You can see plain examples of how they release similar things together and move on to new topics. The A-10C II was a classic. Next you have the JHMCS for the Hornet. It's not a random occurence but part of a plan. The only problem here in the way ED are doing it is that they didnt quite tell you how long it might take. You have to figure that out. You have to figure out, as a customer what early access means to ED, not what you think EA is because <insert company here> does/did. This takes a long time. It shoudl be obvious by now :) The Hornet is a good benchmark for everything to follow. I would rather they had the F-16 out and you can fly around and shoot things down, but its woefully gutted on it's features, than the alternative, which is "nothing". That is your choice. Nothing, or something. And the guys that choose "nothing", you can have that too! So really, no one loses at all and this entire discussion is a waste of time.

Stars twinkle as an effect of atmospheric disturbances and imperfect heat. It will change from place to place and weather to weather. The current rendition I like, feels more realistic than no twinkling.

I've been considering an update for a very long time. I originally said I wouldn't edit this but there are two compelling reasons to, especially since I have used my own templates so well, since I made them, in whole or in part for missions or training. 1) A chap approached me with adidtional helpful information about the Incirlik Patriot site and layout. We nerded for ages on the topic but the outcome would have been a realistic attempt to template the Incirlik site, especially the Patriot battery in all its various configurations over the years, but additonally with the point defence Rapier sets which surround the site. I balked originally at the effort vs reward because the site wouldnt have any substantial differences in its capability in DCS and would add a small load with new unit types. 2) The new Desert skins. Holy crap... this would not be a simple task. The fastest way to swap all the green for Desert liveries post that release would be programmatically in the file. And I'm a bit tired of doing that with the sim, what with all the testing I already do, running a small group and finding time to actually fly. No guarantees but I'm warming to an overhaul consisting of those changes, but not quite yet because I've alot on my plate and I need energy and time to go through 900 units :/

the TF-51 is the free plane that comes with DCS, not sure why you woudlnt have access to it or how you can even uninstall it, but if my memory serves correctly, there was an old bug about this. I'd suggest troubleshooting that bug, the miz doesnt require additional DLC.