VGlusica

So, ever since about two updates ago my DCS crashes about 30 to 40 minutes in if I zoom in or turn my head. I have tried Flappies's troubleshooting guide but to no avail. DCS log is included. - All mods have been removed - Completely uninstalled and reinstalled GPU driver. - Asus GPU Tweak disabled - BIOS latest version - XMP disabled - Resizable BAR disabled in BIOS - Power plan on High - GPU set to "prefer maximum performance" - Renamed to DCS.bak - This seemed to work for couple of missions. - Ran MemTest86 As things stand right now DCS is unplayable for me, so I am hoping someone can help. Also, this issue seems to be confined to DCS as everything else appears to work fine. dcs.log

Have the same issue.

I will be entirely candid here, for me DCS is a tertiary hobby, so I am not all that invested in this, but since I am now semi-retired I have time to ruminate on various esoteric subjects. @Lord Vader The 13m CEP came from F-16.net. However, this is actually somewhat irrelevant. First, I want to be clear that I am not directing any of my comments at you but rather to the "team," this is what I mean when I say "you." In large part the point that I am trying to make is that if you are relaying on publicly available information the CEP modeled should not be 13m or 30m it should be 5m. All publicly available open-source literature references this as JDAM accuracy. Both @Sinclair_76 and @KlarSnow provided you some very good reference materials to this fact, I would suggest that you take what they are saying into consideration. One thing that seems to happen any time a discussion like this comes up, is that "realism" is brought up in defense of the underlaying decision. When, however, that definition of realism is brought into question, the second thing invoked is "official sources." What ends up frustrating number of us is that you don't have access to "official sources" either, as these sources carry various levels of classification and are not in public domain. So, making a statement like "we cannot use websites without official sources" feels very disingenuous to some of us. I would like to make my point one more time, the "team" does not have access to "official sources." The best you have is access to SMEs whose qualifications are known only to the "team." I am somewhat skeptical of some of those qualifications, because a few years ago we had an SME who did not know how an ASL properly functions. Regardless, even the best of the SMEs in this subject field are bound by oath, duty and law not to disclose classified information. This leaves us all back at the beginning and my original point from my previous post. All of the publicly available open-source information points to 5m CEP not anything else. No open-source documents point to error stacking between launch platform and the weapon, and this is exactly what is currently modeled. If the "team" wants to be accurate it should model things and behaviors that can be verified. What is being modeled is the conjecture based on unverified information provided by someone who is only peripherally familiar with architecture of GPS/INS guidance systems and not reflective of real-world behavior and performance.

That makes sense, thank you. I was curious where it came from since it does not seem to be the operative factor currently.

One of the few things that I can speak to intelligently is this particular issue. @Lord Vader I must ask, where are you getting the 13m CEP, as this is not published anywhere? If you are you are referencing error stacking, this could be an INS issue, but GPS system architecture is particularly designed to eliminate this problem. I will not go further into the subject as this forum is not an appropriate venue. Suffice it to say that if you label what is being put forward here as conjecture, because there is no reference provided you must then provide reference documenting accuracy of your statement. If such reference cannot be provided, then we must all agree to adhere and abide by those things which can be directly verified. F-16.net can be quite a good reference, put together by individuals with high degree of familiarity with the aircraft and its systems. Dismissing it out of hand might be somewhat presumptuous. My second question here is, do you (and I mean plural you here) have access to "official" documents, because frankly you should not. So, your statements also must be viewed as conjecture. Modeling based on conjecture is also unrealistic. One thing that I think we can all agree on, is open source published and generally accepted notion that current class of JDAM's operate with 5m CEP, so make it easy on yourselves and us and just model that. With 5m CEP 50% of shots should land within 5m of the target. Fortunately, or unfortunately, that is all we have to go on here. Now, If I am to give you the benefit of the doubt, which I don't want to, but will for the sake of this exercise, and we assume that you are correct in you conjectures and CEP with GPS is 13m, once again half of the shots should land within the 13m radius circle centered on the aimpoint. Under the currently accepted theory of CEP calculation this means that that some number of shots will be closer than 13m to the aim point and some further away. What we are seeing in the sim right now, at least in my experience, I dropped about forty (40) shots, is every single one was more than 13m from the target point. To the best of my ability, due to sim limitations, I tried to figure out what the dispersion was, and it seems that no matter what one does or what the environmental factors might be the CEP for these weapons is 13+m. What is even stranger, is that the weapons seem to be avoiding the target point. What I mean here is that if the inaccuracy presented here is due to random target point shift due to system error, then within a certain subset of shots the introduced errors should cancel out, this never happens as the weapons always miss the aimpoint. I do not want to be overly harsh here, but it seems to me that there is something rotten in the state of Denmark and all the conjecture in the world will not fix it, especially if we are closed to any form of outside facts.

Had this same issue only with GBU-10. You can add the bomb though PACS and then it works fine. This must be a bug of some sort, because it is only an issue with GBU-10 and only on the left side of the jet.

I had a chance to do a little more testing on this. I could not find any combination of settings that would drop more than one weapon at the time.

Do you mean ripples with longer intervals? I tried several different things with different ordinance with same results. I also tried higher and lower quantities. Thank you for trying it out.

It appears that this has still not been fixed. I've tested only in Multi Tread. AV8B Multi.trk

I followed this advice and it helped a bit. My cores were definitely being parked. What appears to have solved the stuttering for me was to go to Nvidia control panel and limit FPS to 90.

For me the update to 2.9 has been an unmitigated disaster. I am running a Nvidia 2070 card and the sim is unplayable due to stuttering. This occurs in regular and MT versions. I have tried everything I can think of and nothing has resolved the issues. I have checked, and I don’t appear to have a CPU bottleneck. Prior to 2.9 everything ran without any issues. It seems to me that 3 and 4 series cards have seen significant benefit while earlier ones have significant problems.

Is this going to be fixed anytime soon?

Thank you for your responses, I am glad to know it’s not just me, hopefully it gets fixed soon.

I did my best to search if this has been posted before, but I could not find anything. Problem is fairly self explanatory, once CPG engages the target and if that target is not neutralized CPG will not re-engage unless you de-was the gun. Currently I am not running any mods on my installation. Below is a short track. Of course, there is always a possibility that I am missing something here. 64D Gun.trk

Dear ED, Your decision to lock weapons .LUA files is one of the most inexplicable decisions you have ever made. Your statement: "On popular demand we have locked the LUA files relating to weapon systems," I suspect to be patently false. I have spent some time combing forums available to us here and I have failed to find one entry calling for this. As a matter of fact, as recently as a couple of months back you repeatedly assured the modding community that you would not do this. I am not part of the "online community." I am, however, aware that "online community" and server operators have always had an ability to run integrity checks and by means of this level the playing field and ensure that no cheating occurs. What has changed? In addition, I am aware that a number of online groups and squadrons who used personal modds to suit their own purposes. Do they not count? Ultimately I can only speak for myself. I never fly online, so if I make modifications to the game files it affects absolutely no one. Why isn't my enjoyment of the game, and those others like me, just as important? Apparently I do not count and you do not want my business. One of the things that especially irks me is the underhanded way in which this change was brought about. If you were truly so concerned about the input of the community, why not announce this decision and allow the "community" to sound off on it in an egalitarian and transparent way. I fully understand that DCS is ED's platform and that ED has the ability to change how that platform is used, but it is also important to understand that ED has established a certain pattern of use and changing that pattern without any warning or notification might represent a problem for some of us. As for me I have to say that by popular demand I will not spend a red cent with ED or any other developer until these files are unlocked. Good night and good luck, VGlusica

I have to agree I think community modding is near death. I personally don't see any reason to restrict access to these files. I understand some potential issues with online flying (I personally never fly online), but that is easily solved with IC checks, so I don't see what the issue is. I do also understand tech support problems with modded games, but again all ED should do is make it clear that they will not support modded game. Not sure where this is all going, but I do hope that ED will at least give us an explanation.

No official explanation or alternative that I am aware. This is actually what bothers me the most, some sort of explanation would be more than warranted. I don’t want to level too much criticism at this point, this might just be an oversight, as it did happen in the past.

I went through the entire directory and cannot find anything like what we were used to. What I did find seems encrypted.

For me this is more than disappointing. Taking away our ability to mod those files is entirely uncalled for. I wonder what their reasoning behind this might be.

I did a little snooping around just to see what changes were made to different files and these were significant. I also hope RAZBAM will provide us a solution. However, I do tend to agree with Hawkeye about their efficacy when it comes to resolving issues.

So I had a chance to do a bit of testing and the mod works, however, you do end up loosing some symbols on the stores page. Imacken thank you for your efforts trying to sort this out.

I did some testing and I get the same artifacts. After creating a backup I deleted the indicator folder and replaced it with the downloaded one. I am wondering if there might be another file somewhere that need to be reverted. Maybe materials.lua, or something in the displays folder.

Imacken thank you for posting that, I have some time later today, so I will do some testing.

Is it possible that someone could post an entire cockpit folder for those of us who want to revert and don’t have it.

I dont have it handy right now, but I believe there is a chart that you can use to figure out which load would give you unacceptable asymmetric load. When I have a chance I will look it up and see if I can give you guys a basic idea without running afoul of any rules. One thing to keep in mind is that in a certain flight regime you might end up in a situation where your flight controls do not have enough authority to overcome the load asymmetry.