Pikey

ehhh. Don't like this advice. Setting specific swapfilesis fruitless and I challenge anyone to find any data that DCS runs better with a specifically set pagefile. Why would read/write IO to a file not on the system or DCS disk actually delay anything that DCS was going to use anyway? Why would a specific size help if it doesnt change the fact that IO is happening anyway and you just need to remove the contention point? My own advice is based off common sense and a simple fact: Windows expects a pagefile wether we like it or not, that is the way the code is written. It uses as much or as little as it likes according to code that you will never understand, so go with it. Stick your page file on an NVMe, remove any disk IO from the NVMe and leave it be to self inflate and deflate as it likes. It's not a SQL index that requires pre allocation, its a swap file. If you want a windows setting that actually does something try the monitor preallocation or something you can measure in gain visibly. Most of these are placebo.

No I wouldnt expect so, one of the main statements in favour of wholesale replacement was that you dont see them in cockpits, mostly large exterior pieces. But the sorting is also a stumbling factor. As Taz said, he optimised his, tested it and liked what he saw. Yet there is an element of "manual" about the testing and specific about the type (A-10C II). I dont think a single answer fits all. And it was pointed out that the A-10C was in fact an anomaly, and that was also used for much of the OP's testing. So its not such an easy topic to wholesale provide answers to. One question i would have is to the people producing textures with the modules, how hard is it to be more selective about what you target for what bit size? Is this all about process and saving time?

If I can summarise my last four months since trying to get a better understanding of it, the SteamVR crash still occurs, it's not often, it is annoying, its 100% a Steam VR crash and often needs a reboot to clear up, I dont use VR for anything else other than DCS but we know DCS is demanding, so we could say that DCS's hardware demand might be the cause without being too inaccurate (I dont subscribe to saying its DCS fault entirely, if it's a timeout, the middleware could still be tweaked to have more tolerance in its values). I found the issue was often with the F-14, often involving the F10 map, but neither was required and all SteamVR crashes are preceeded by a state of being laggy, low FPS and then a pause and then the headset goes black, SteamVR shows it crashed, DCS continues in a choppy unplayable (but alive) state. Steam cannot then find the headset (not everyone has specificied that).The errors are in SteamVR and iirc relate to a timeout. The issue never happens immediately, always after 15 minutes (for me) and requires a mission with CPU load. Multiplayer could help exacerbate this, although I suspect MP is just a CPU load and its more about the CPU than actually MP. You can defintiely get there sooner swapping planes, and defintiely zooming on the F10 map will bring it sooner. It also cannot be purely CPU based because you can stretch CPU usage (loading screens) and the tracking can stop completely but the applicaiton and VR is perfectly fine once it recovers... its something other than pure CPU. I did consider power draw and USB. I moved my Headsets USB to a powered hub from the onboard and this reduced the issues occurence anecdotally - who knows probably placebo? I dont have HAGS enabled, by default its off, so I dont think we can say its a cause, unless the work that MS did to put it into Windows changed something. Not sure I want to turn it on. My gut feeling based on the evidence but not being able to tie the evidence to the root cause, is that the timeout is caused by the graphics handling, especially the texture loading and unloading of DCS, under stress, which is caused by extremely large textures in DCS and limits on Graphics cards, which is noted in this link for which we are still in an endless loop of not being able to explain that there is actually an issue that needs to be addressed: But I dont think I should have offered a partially substantiated conclusion based on thin evidence. I desperately would love to hear the views of Steam VR developers on DCS, its really time for us users to begone from pseudo science and have developers work this out.

I think @twistkingmakes a good summary. In a bubble, having quality is the most important to an artist but that bubble doesnt extend to cover the user bases needs. User perspective: We see examples in some cases where there doesnt seem to be a gain from such large textures, and in fact these are hurting performance with no gain. Artist perspective: There are specific cases of rounded materials and shiny surfaces where we must use the 32bit normals to achieve good quality And ideally we would live in the intersection of both the artists and the users needs, but we appear to be living only in the artists and this ignores issues of optimisation and good performance. I think there is a disconnect, I think the perspective of the user is missed or diregarded because the line between 32bit texture size and GPU performance in the average consumers machine is not publically and absolutely proven to create performance issues. And I beleive myself that there is a problem and it's evidenced by mine, and others simulations running badly and performing badly because we play the game, we don't test it in these bubbles. I don't know what else there is to do but keep showing the link between performance and texture size. It's not easily done. I think it causes this: https://forums.eagle.ru/topic/246886-dcs-causing-steamvr-fail-description-evidence-and-how-to-replicate/page/6/?tab=comments and this https://forums.eagle.ru/topic/264164-extensive-vr-bug-my-research-around-it-f10-other-view-changes-kicks-you-out-of-vr/ which looks like this which is explained by this post and also this post: And I evidence it with reproducing more often with textures set to high than textures set to low. But if I'm wrong, then how is this proven that I am wrong? Because it seems that the burden of proof shows there is an issue with large textures and they are causing poor simulation performance, especially for VR users. Obviously these texture sizes hit VR players harder - symptoms of issues are not correlating to VR users because of the relatively low proportion of the user base comapred to the 2D folks. This is the extent of my subjectivity on this matter, I've been judged for trying to keep people data driven, but I know for a fact if you offer subjectivity, anecdotes and no data, you will get mocked in this forum, hence I've kept my final conclusions away from posts like this. I dont have the knowledge to link the symptom to the data, not many people do. But I can offer my experience as data, and my experience is in general agreement that textures are the root of quite severe issue in performance that can cause the entire sim to stop functioning normally.

Questions of which modules develop seem imo to fall behind the simpler deficiencies of AI planes, AI behaviour and tweaks to the periods on the maps we have and the ones in the future. The last list of the Asset packs contents falls quite short, its not rounded enough on both sides - its not just what you fly, but what you fight. As long as the list of opponents is small, the periods are tight and the AI does predictable behaviour, we are stuck asking for more depth of modules and can only fly them in the case of Normandy, between 3 months of a year or in the case of the Channel, specifically late war post Manston paved and so on... It's restricting. Whilst modern air combat was this companies bread and butter, the WW2 community are much more demanding with their accuracy and keep ED to account on facts quite fastidiously. I'd rather focus time on getting the bedrock in, the ability to produce module variants faster, more AI bombers, ships, technology... You just know all the clamour of a far east conflict and Pacific era will produce other standalone modules lost in time and space as ED tries to please everyone and the inevitable happens.

Actually that was what prompted me to ask, but after I researched and went to that Discord, I found it was not released just being used there for a video or something.

Did we miss a release?

I wish for one in the Spit specifically. It's conspicuous by its absence. The flood lamps do not allow you to see many of the switches for manipulating them. Its a matter of moving the mouse around until it changes colour when in the dark. And I know the thing didnt do night stuff but starting pre-dawn is reasonable.

I asked a community manager to ask to have a developer look again at the thread. ED are on a long weekend right now. We are aware that a reason provided was due to artefacts and you cna see the example in the link I posted. Whilst one set of people might say that unit not supporting 32bit is a good argument for not needing it, another set of people might say the post indicates a desire to have for better appearance. And the question revolves around the percieved performance vs the percieved quality(or specific issue since there doesnt seem to be many downsides)

They might be, but the data cannot be easy to come across, unless you know otherwise?

For a minute there I thought you were talking to me!

There's some fantastic brandishing of "industry standard" as a term, yet it's never been referenced in this post. It would carry more weight to have that here, can one of you experts find it perhaps?

If i'd said that, then i would have... said that. Learn the difference between infering and implying. You infered it, I did not imply it. Or say it. Here's some game industry texture arttists crying out for unity to support 32bit textures https://forum.unity.com/threads/normal-map-artifacts.417741/ It's not as cut and dry as you keep saying. I have no issues with the ED textures, in fact the Heatblur F-14 is the one that my gfx card consistently starts chugging at so I can't follow the end to end flow of what you call so obvious. Thats all i'm saying.... it's just not as simple as you keep making out else there would be absolutely no evidence to the contrary and there is a quality consideration that has been raised both online and by artists in working with the sim. Thats it. No personal bone. I suspect you hope there was because no one from the dev teams is answering you. I also wish they would, because I still believe your message has lots of merit.

@twistking The reason was provided by a texture artist from Heatblur. Choosing not to believe that is a valid reason is fine. But I would ask everyone that doesnt beleive their reason is valid to consider why, not only ED, but most of the third party developers are doing the same with the textures. Have they all got group hallucinations? Why would something so unbelievable only be unbelievable for people who aren't creating modules for DCS? For me, I never tested how much the distortion is really apparent, others here claim its not a factor, so for me, its like choosing between several companies that have people working on this or someone that makes a counter claim. I pick the majority until I become able to do better for myself, but I realise that is an uneducated position. Still, I don't claim any of this, from either side, is unbelievable. Nothing is unbeleivable and that word keeps going around.

the ai can't take off from this carrier. it thinks the positions are like a nimitz

Aircraft stationary on the ground should not be targeted, let alone hit with radar guided air to air missiles. That's all there is to that. Doppler gate is what 40kts at close range for DCS air targets? This is a vestige of the fact that DCS sees a unit as "something" and not as a moving object through 3d space. However I can't speak for helicopter blades because that's a different thing and should be possible. Still, its all moot because no trackfile.

Its got to be something that is possible. With data, good public documentation or at least records and extrapolated data. Su-30 seems to be a pipedream. Stick to simple and realistic.

ground level. Not sea level.

is this because of the EPLRS task? (It's not available for red awacs) So is there some lua we can add to the misison that can add the task manually?

Regarding the question of what lua can do - whilst LUA can execute in a mission, it has restricted access to modules and libraries that is enforced by the game. A certain file in core DCS "nils" these so they cannot be used by default. One of these is the operating system module which allows access to the "execute" method. Other sanitised modules are the local file system and IO. as well as not being able to load the loadlibrary command and so on. Whilst you can uncomment this (and its done a lot for server side which is less restricted), you can't guarantee everyone does and getting a userbase to de sanitise themselves so you can run arbitrary code via the mission is obviously not ethical. Not to mention, new skins require the game to reload anyway so that's kindda blown away. I have tested os.execute and lua gives you a dirty great big DOS prompt on yourscreen whilst flying whilst it works away... not even good, lua is terrible for this, has to be done from the core C engine. Also this has been suggested, even this year internally, that we could get missing skins to download from the server. I can't see it happening fast, but at least you know its something that many others have wanted.

I had a set group recently and it populated new spawns itself. So the problem would be somewhere around the name or the specifc type of object and most likely would then have an error in the log.

No. 3D objects are "dropped" by the core sim onto the ground and bury themselves at their own discretion, not by anything scripting has accessible. They don't rotate and th eonly height change can be via some spawning onto another object then deleting that (so the only way is up) Sadly.

absolutely fantastic work

Hi, I feel cheeky to ask for more, but considering the Collossus class was so widely sold on and preserved post war, such key ships above demonstrating this, I'm asking for something that is sort of obvious given the heritage and that is the original Collosus light carrier or whichever derivative is easiest to port into a WW2 British Pacific Fleet carrier https://en.wikipedia.org/wiki/1942_Design_Light_Fleet_Carrier The Leatherneck Corsair is getting closer to release, the Marianas islands by ED also getting closer. There is an obvious desire for some to have fleet WW2 action, so I think a WW2 version of this makes a lot of sense. Thanks for the consideration.

Fantastic!