kksnowbear

Well...to try and estimate the loss (I am assuming you mean performance loss) from moving to 4k from 1440p, the difference is basically 2.25 times the number of pixels - so it's going to be a lot more demanding, for sure. Note I'm not saying it's linear, in other words I'm not saying it will cut your frame rate by that same 2.25 times...but it *will* be a lot more work for the GPU, no question. I built a system for a guy from the forum here not that long ago, using a 4070, and I was actually pretty impressed with it even at 4k. I recall frame rates in the 60-70 range, but a few things apply: 1. That was using DLSS, which as you may know does have some trade-off in quality for the performance gain. 2. I believe it's accurate to say that the map you use will also have a significant effect on performance. The 4070 testing I did at 4k was fairly limited, only using the Caucasus and Marianas maps, and with a fairly limited amount of other activity as well. As far as how close you sit...well, generally and broadly, the closer you sit, the more the size of the pixels matters. Here's a (very general) way to get an idea: Try getting even closer to the monitor (if that's possible), just as a test, to see what it looks like. How close to the monitor can you get before the pixels look 'too big' to you? Basically, by moving closer, you're simulating the effect of a larger monitor with the same number of pixels...but again, this is very broad and general. EDIT: Also, @Hiob mentioned OLED instead of IPS above, which I think is definitely worth considering. OLED screens are *very* good-looking, so maybe your desire for 'eye candy' can be satisfied that way.

In large measure this depends on how close you are to the monitor. I know someone with a 1440p 32" monitor which I've seen first hand, never occurred to me that the pixels were too big. I will say that, if you want to avoid larger pixels, the obvious 'next step' would be 4k, but then you have to consider your GPU (which you don't specify).

Yeah...before you try adding more to the equation by installing (completely unnecessary) fan control software etc... The logical thing to do is find out why the fans are running so high. For instance, you make no mention at all of temperatures. Even if the game isn't running at all, there could be some issue causing the fans to run as they are. For one, if your GPU is hot, it doesn't matter what's running, the fans are going to run hard. So...GPU temps? Something else - just a clarification, please: You said the 'fans are full on' - how are you determining that? Based on noise, or looking at the fans, or maybe some monitoring utility telling you the fan speeds? if it's based on noise, people sometimes confuse noise from chassis fans with GPU fans. Depending on how they're set up, they can operate independently or similarly. Also, another question please: Are you saying this started happening recently, or has always been this way (with that GPU/system)? In other words, did it change? If so, when? (i.e., was it associated with something else - for example "Last week I cleaned my computer and now the fans run high all the time"...just an example but hopefully you can see what I mean). Sorry, but one other question: Who built the system? (The intent here is to establish how familiar you are with that specific machine, as well as machines in general.)

The part about Updater being hardcoded was my own misunderstanding, caused by my own lack of research, for which I took responsibility and made corrections. I'm not perfect...you? But that's a small detail that changes absolutely nothing about the rest of what I'm saying. I'm not getting pissy, I'm simply stating my position. Please keep personal attacks out of it, and debate the topic, not the person. You may have been "joking" (as you say) but you weren't happy and you made that abundantly clear. Sorry if we disagree. It didn't come off as a joke to me, just saying. Either way, what you ultimately did is what I'm "on about" - and by the way, I'm "going on" about it because people like you keep arguing. You expect to be able to post a comment, and I'm not allowed to respond? It's a discussion forum. I'm simply presenting a different way to see things, and I'm providing details and facts to back my perspective. Sorry if that bothers you, but that's kinda what discussion forums are about. Back to the actual topic (i.e. The blank map in ST). Just for the sake of discussion let's look at it your way: If "There is no repercussions[sic] to launching dcs.exe directly." then why did the people in this thread have the map problem? Fact is, if it weren't possible for them to do it wrong, they wouldn't have had the problem, and this thread wouldn't exist. Moreover, if I'm not mistaken, there are no fewer than *three* separate threads about this same issue now, in this subforum alone. All with the same purported fix: "Run MT"...even though ED set up the game to run MT, by default, almost a year ago(!) (Three: This one, >two< and >three< ) Doesn't matter how you look at it, there's just more effort required. More questions that need to be answered; more confusion. This problem (ST map blank) exists for one simple reason: Users were allowed to choose, and that choice caused the map problem (in most cases, though not all). It is not a question of which choice they make; either ST or MT version can have/cause problems. That's not the problem; the problem is that users were allowed a choice. Take away that choice, the problem cannot exist. Simple. Updater already calls the appropriate version (and has for almost a year), and ED has said it's stable and they are happy with it. So why does anyone need to be able to run anything manually? It only serves to create the potential for confusion and problems. Your own misunderstanding (that you still *must* do it manually) proves that point, and so does this thread. At an absolute minimum, if there was only one way to run the game, then no one would ever have to worry about what happens when someone runs it a different way. Support is easier, period. (Again, there are *three* separate threads right now, for the same issue.) Speaking of easier support: As I believe you know, I actually have spent decades in various professional capacities, working directly with software and developers, and (in my experiences) they aren't typically very fond of leaving choices to users. This situation very clearly illustrates why. Oddly enough, in my experience, it's always the users who want the choices. The developers I worked with wanted to hard code stuff so the users couldn't cause problems by choosing wrong. Sound familiar? My point is to help avoid the misunderstandings. No rules against it that I'm aware of. You yourself could've benefited if you understood better. Incidentally, this also conclusively demonstrates that factually, the game absolutely can have the map problem even if the user wasn't running the ST version *and* never edited any cfg file. Your own experience also proves that. So there's another misunderstanding. That's what led to Skatezilla saying "can bet his autoupdate.cfg points to the the ST dcs.exe " - which we now know simply isn't accurate (also not my fault BTW). The user being left the choice *is* the problem, and this thread *is* the repercussion of the user having that choice; it is exactly what caused this entire thread and the problems discussed herein. Now, I'm truly sorry if you cannot see that, but (as a matter of opinion in the form of professional advice) the reader would do well to recognize this. (PS, No, it's not accurate to say all the changes to the game have to be made to dcs.exe in the bin-MT folder, at all. That's exactly my point, which most regretfully seems is still being confused. They can be made anywhere ED programs them, and neither you, I, nor Skatezilla control that; we don't have source code. And, just as a point of clarification, compiling source code does not take place on the target installation).

You assume wrongly kksnowbear. I have not changed any internal files within the DCS folder in years. I am and will continue to run DCS from the MT.exe shortcut as i have never had a problem with doing that. Nope. Not at all what I'm saying. Sorry if that isn't clear. I didn't assume anything about what you did, that would be Skatezilla, whose quote is above. I didn't say (or assume) you changed anything, he did. I'm saying that ***IF*** what Skatezilla said were true, then it would mean that you had altered that file (but we both know you didnt). And I said you did exactly what you did: Read here on the forum to run MT, which you then told me was working. That takes me to what I am saying, and will keep saying: Factually, it is not the best approach, for all the reasons I've explained already, and more important still, it's absolutely not necessary (since October '23) if your Updater is working as intended by default. And that is directly per ED themselves. Fact is, if your installation hadn't been messed up, it would've worked just fine, precisely as I said it would, and just as ED says it should. You've also now confirmed that it does work exactly this way: "run Updater click later, get into mission goto map, exit, attach dcs.log. " I did the above and the map works in both instances. Here is the entry in the Autoupdate.cfg "launch": "bin-mt/DCS.exe" Updater works as intended, map displays fine. Just as I said; no need at all to run dcs.exe from the bin-MT folder directly. You and everyone else can do whatever you want. What I said about running from the MT dcs.exe is still entirely accurate. That 'fix' applies to people who were running the ST version (as mentioned above) - but obviously that's not what was going on in your case. As I immediately indicated when you first told me about this: It appears the update process screwed up somehow. And it's certainly not my fault your installation got jacked up somehow - I didn't write the software.

It's really not that puzzling (unless you're a 14th gen Intel CPU owner who insists on looking at it as some sort of proof the 7800X3D has issues running DCS lol). Probably worth considering there are lots of people running DCS on a 7800X3D without issue. The thread also mentions other CPUs, including at least some Intel models if I'm not mistaken. So it's misleading to suggest this mysteriously indicates much of anything about the 7800X3D alone.

Yeah, pretty sure I had looked over that last time you mentioned it. Admittedly didn't read the whole thing, but IIRC it wasn't just AM5 CPUs, there were Intel CPUs too. So it's not an exclusively mysterious issue with AMD CPUs; the 7800X3D is still currently the best CPU for gaming, and the Intel 13th/14th gen CPUs are still prone to destroying themselves

Link?

Yes, yes I understand all that...what I'm trying to get at is that what bypassing Updater *can* also do is cause problems. Ill advised for those lacking certain experience, we'll say. In fact, one could argue that - if you're right about the Updater being pointed at ST - then that (almost certainly) means it was messed up by jacking around with it, since we know it doesn't do that by default It would mean my friend has somehow altered what Updater does, then when it did what it was told, the map problem shows up. He decides (wrongly) that the fix is to run the MT dcs.exe directly (even though that is based on advice in this very forum). The real cause, if you're right, and the real solution, is "don't mess with Updater if you don't know what you're doing". Updater runs MT as intended, no map problem, everybody's happy. Otherwise, people walk away with the idea that Updater doesn’t work right, and the fix is to just always run the MT version directly - which again, could cause problems at some point, since none of us control what ED codes into a compiled executable. Also, can't rule out that at some point trying to run the exe's directly might not even be an option, since again, we don't control that.

And I have no argument...could easily be that. Still, it remains that there is no real need to run dcs.exe from bin-MT in order to "make sure" you're running the MT version of DCZ. And it is possible that doing so might cause problems at some point. Hence, "ill-advised" in my estimation. ED can change whatever they want (in the Updater executable), and the average user might have no idea. Particularly since ST won't even be applicable soon enough, no reason at all for most players to jack around with the way it's set up to work. In fact, one could argue that - if you're right about the Updater being pointed at ST - then that (almost certainly) means it was messed up by jacking around with it These were kinda my points in posting.

It's not hardcoded, it's the 2nd to the last line in the autoupdate.cfg Ah...I stand corrected. Thank you. (lol never actually checked it) Yes, I see your point...not sure then why he has/had the map issue. I gather he hadn't updated in some time. But he indicates he did update most recently, so (I assume) his Updater link/version would be calling the MT version as expected. I say "circumventing Updater" because he's now convinced that is why the map works, thus making it a good idea to bypass Updater. He's not taking into account that (assuming a proper default Updater), there's no need to run dcx.exe directly from the bin-MT folder. Something else is wrong (as you indicate). (lol All I know is I got blamed for the map issue because I told him he didn't need to run dcs.exe manually, since the Updater has done it by default fir almost a year now). Like I said, though, this entire discussion reinforces why circumventing Updater is not the best idea *unless* you know what you're doing. And it *is* still a compiled executable, so it can do whatever ED programs it for - doesn’t have to be configurable at all or exposed to the user in any way.

It is "hard coded" Updater is configured by default to call the MT version. It can't be changed without source code, but people have been circumventing Updater by running the MT version directly from the bin-MT folder. That's the reason I posted, to illustrate why it's a bad idea to circumvent Updater, unless you know what you're doing (and actually understand the repercussions.)

I'll leave it to him if he wants to do that. He's already pissed at me for telling him to stop running MT directly, because when he did it broke the map (not that it's my fault). PS I think the difference might be related to the fact that when it happened to him, he actually updated. That's why I said above that it didn't happen to me because I picked Later. Sorry if that wasn't clear. To be clear none of this changes my point that Updater calls the MT exe, (has for a long time), and that running MT "directly" from the folder is not necessary, is ill-advised, and can cause problems of itself (since Updater is an executable that *can* do whatever ED decides).

I understand what you're saying (basically same thing I said, sorry if it wasnt clear) with one exception: I am currently working with a fellow DCS player who says he has the map problem when running from Updater, but not when running dcs.exe directly from the bin-MT folder.

https://forum.dcs.world/topic/357053-st-map-is-blank/?do=findComment&comment=5519016

This. Yes, ST has been deprecated for some time now - but, more significantly, it's not whether you run MT directly that actually resolves the map problem. As mentioned, the typical Updater desktop link has long since run the MT version of DCS.exe (since ~October 2023?) See here: In order to prove that the Updater link does in fact call the MT version of DCS.exe, I can (and have) gone into the bin-MT folder, renamed the DCS.exe to DCS.old, whereupon running from the Updater link will fail (because there's no DCS.exe in the bin-MT folder anymore). This proves conclusively that Updater does run the MT version of DCS. (Also, I further verified this by doing the same test with the ST folder version of DCS.exe, which of course had no impact on running from the Updater link, because Updater doesn't use the ST version anymore). My map still shows up fine when I run from the Updater link (which, again, runs the DCS.exe in the bin-MT folder). The difference is I didn't actually update yet. When Updater presents the dialogue box showing my current version and asking me if I want to update, I've been clicking "Later" (for my own reasons, not related). Some players are apparently confused regarding the fact that Updater actually runs the MT version for some time now... ...but now this issue with maps (etc) is being confused as "You have to run MT directly". If you're using the Updater, you're already using the MT version of DCS.exe - the exact same file that people run manually by navigating to the folder and running it from there. There is zero difference; none. Nada. Zilch. You can prove it for yourself by doing the simple renaming test I described above. The difference is that once you've updated past a certain version, something in Updater is actually doing something else which in turn causes the map problem. It's not the MT version of DCS itself that's causing the difference (because if it were, running the MT version manually would presumably still have the map problem). It is NOT whether you run the MT version of DCS manually. Again, you're already doing that even if you use the Updater link created by a default installation. The problem is elsewhere, related to Updater. Running the MT version directly isn't solving the problem at the source, it's simply bypassing Updater (which is causing the issue). You have to understand that there's no rule or law anywhere saying that Updater is only allowed to update. "Updater" is just a name; the program will do whatever it's written to do (in this case including, unfortunately, breaking the map somehow). Why does this distinction matter? Well, it doesn't matter at all to me personally, but if a player - out of convenience, laziness, lack of understanding the problem, some combination of these, or whatever other reason(s)- decides to get wise, delete the Updater link, and create a link directly to the MT version (which many players have done)...this creates the potential for actually causing a problem. How? Well, this very set of circumstances with the map illustrates conclusively that Updater is absolutely capable of doing other things besides just running DCS.exe from a specified folder. Updater is a compiled executable, and that means that unless someone has access to source code, they can't change what Updater actually does internally, and they cannot directly 'see' what it does, either. The developer(s) at ED use the Updater mechanism for a reason. Whether we like it or not, that is their decision, not ours. While it might seem clever to bypass the Updater by going directly to a folder and running DCS.exe, doing this is factually skirting the intentions of the people writing the software. For example: Updater is capable of messing up the maps, and it's also capable of doing other stuff. Suppose ED modifies Updater in such a way that it fixes some problem(s). Again, not up to us how they go about it, and the Updater link would do exactly what they intend, Updater itself being an exe that can also be updated at ED's discretion. It can do whatever they want it to. If, however, a player decides to get clever and go directly to the DCS.exe in the MT folder, they won't get whatever benefit exists from any changes ED might make to Updater. Also, since the developers don't necessarily know you've circumvented their intentions, it could be more difficult to help find/fix a problem caused by having doing so. And no one could really blame them since you're not running the game the way they provided (via Updater). At that point, it's potentially created additional burden on what limited support resources there are. That doesn't help anyone, and in fact could hurt everyone. Let me re-emphasize that although I am absolutely running the MT version of DCS, I can still choose not to update, even when I use the Updater link. And, in this case specifically, my map still works fine - not because I run DCS.exe from the MT folder directly (I don't), but because I chose not to update when asked. If somehow the map got messed up, that's unfortunate and I imagine it'll get fixed...but that doesn't mean it's a good idea to always run DCS.exe from the bin-MT folder directly. It's important to understand the difference, because otherwise you can actually cause problems. Sorry for the long post but I hope this clarifies an important distinction which could cause harm if confused. (Note: There is the possibility that the most recent version of Updater has been changed such that it doesn't call the MT version of DCS.exe anymore. I don't know, because I haven't updated and I don't have source code, either. If someone wants to know, it can be proven by doing the renaming test above. And if it's been changed in this respect, well, that's an entirely different conversation. Maybe this is the change where ED doesn't use the bin-MT folder or the ST versions...don't know, and I'm not gonna update and break my map just to find out...but it's possible. Regardless, always running DCS.exe directly from the MT folder is not necessary and is also ill-advised, as outlined above...if you don't want to update, simply choose "Later" when Updater asks)

"He’s an expert too, and it still happened to him." He's an expert who is creating a video that is explicitly intended to demonstrate failures. Generates clicks. Generates views. Generates money. A failure like that is so easy to replicate it's not even funny (if I wanted to make a video). Among other things, I've been re-pinning cables like that for a long time, and with the tools I use, I can make the connector do pretty much whatever I want. (The wife and I both have military and civilian experience building aircraft cables which have to pass FAA certifications, too - so this is not an uninformed opinion). He also states that "This is a Corsair (Type 4?) cable that I've been using for quite a while..." So, the guy frequently does videos explicitly demonstrating failures...yeah, I'm gonna guess the hardware he's 'been using for quite a while' has been torqued on quite a bit, including intentional mishandling (as the video shows/to demonstrate failures) and so on. Naturally, this isn't recommended. I do plenty of mean and ugly sh*t to equipment I own to test things at times. I don't recommend others do it, and equipment that's been subjected to "failure analysis" isn't made available to the clients. I've had my 4090 in and out of three different platforms (probably more, kinda wasn't keeping count), a number of times each including both in and out of a case...no black screens, no funny business, no melting. Again, I'm not saying the guy's wrong. I'm saying perspective and context are critical, and not everything is what an (uninformed) viewing might lead someone to believe.

Ya sure...I think Der8aur is great as a source, too. Got one of his delidding tools. Used it many times to successfully delid many units. But then, see, it's his business to find fault with the big guys. Generates clicks. Generates viewers. Generates money. He's the little man's champion against the big evil tech monsters... Not saying he's wrong but, again...lots and lots of people who don't have problems. Can't just dismiss that, and if I'm Nvidia, that's among the first things I'm bringing up in court. (EDIT: PS If I understood what he said, I also strongly disagree that it doesn't matter which GPU you use. There are absolutely cards that are more and less likely to have problems with this connector, and they will also suffer more or less damage if something goes wrong. There are a lot of factors involved, and we're already pretty far off course here, so I think I'll leave it at that. Hey, I just noticed...did you know that (at 0:28) he actually says he doesn't think it's a good idea to use his WIreView device? Crap...now I gotta watch the whole thing lol

I absolutely don't dispute the "bean counter" part. What I'm saying is that (if they're even halfway worth a darn) they don't plan that it results in their being sued. What I mean is they do it, sure...but they do it so that they squeek by, even if barely. Otherwise they'd fail as a company. And it's not even a problem, until you couple that with the "better idiot" which society has produced. In other words, the stuff isn't built such that it will withstand the lack of expertise that laypeople possess. It fails earlier because the tolerances no longer allow for the sort of things that experienced people are trained to avoid. In (other) other words lol The more experienced and skilled the user is, the less likely the device is to have to problems. The less careful the user is, the more likely the devices will fail from said mishandling. These 12VHPWR connectors remind me (a lot) of various connectors I worked with after the military. Trained maintenance people learned to work with them, while so-called equipment "operators" broke them constantly.

Well, as much as we may hate what the business needs dictate from time to time.... ...we'd probably all hate it a lot more if Nvidia weren't around, due to crappy business decisions. I admittedly haven't done the legwork myself, but it is my assumption that the manufacturers did the math on the current/wattage/heat capacity of the connector. They don't generally have meetings where they all agree "Let's put this connector on here which isn't capable of handling the power, so we're sure to get sued..." In my estimation, what happened was they may have 'cut it close' but can readily defend it's within tolerance for the application. Perhaps not as 'idiot proof' as today's idiots are capable of. Then what happened is (as I described earlier) in genuine human form...society built a 'better idiot'.

Oh I'm not saying you're wrong about heat. I'm saying there's obviously a reason it wound up where it did (perhaps even despite the heat)...they don't generally spend the kind of money that goes into designing these things by accident - and my thought is that it's because of space. I get what you're saying, but you can't assume that. Plenty of cases don't have intake fans, obstructed by drive cages, etc. If you assume the case has intakes there as part of your cooling design, that's a mistake IMHO. In fact, it could actually be that the designers felt that residual airflow from the GPU fans was enough to cool the connector area, much the same as both Intel and AMD stock CPU cooler designs used residual airflow to cool motherboard VRMs, chipset, RAM etc. Where you can't count on front intake fans, the GPU fans will always be there - and you can control their speed, too.

LOL Well, we might agree to disagree about the 8pin PCIe connectors. Yes, they're more robust, I wouldn't argue that. But I myself have cursed the 'hose monster' that 3 8p connectors entails, along with routing/management/dressing, etc etc etc...and I'd bet anyone who's done this more than a few times knows what I mean. Not to mention that per the PCIe specs of the time, those connectors were already at their limits (never mind they are capable of more, I'm referring to what the specs said). I could be wrong, but I want to say that three 8pin connectors doesn't even technically meet spec under PCIe at the time - GPUS were limited to 300w, I seem to recall(?) And I actually own two eVGA 770 Classifieds, as well as a couple other models that have three 8p connectors. A better solution was long overdue (Whether the 12VHPWR concept was that 'better solution' is another matter). LOL The eVGA pic looks very familiar...I'm sure that's the tail end of the 3090Ti I had. And yes, it's a damn shame about eVGA...but we also have to acknowledge, 'end' connectors like that don't work for everyone either (these cards are long enough as is). I think it's likely that the industry settled on the side connector because (of the two admittedly tight places) there was less likelihood of space constraints with the side connector than the end type. Lesser of two evils.

Of course, I see your point, and it's reasonable (at least initially). But... TBH, what this actually reflects more than anything is that computers are (and have always been) somewhat complex devices. Somewhere along the line - I can only imagine to increase sales - the industry convinced consumers it's a totally "DIY" matter. They simply sell a *lot* more if everyone believes it's easy to build your own. I strongly disagree, and always have. The problem is, it actually has gotten fairly easy. Pretty much anyone can walk into a computer store (or buy on Amazon) and check out with an entire machine worth of parts. They don't have to know crap - and boy, does it show sometimes. They're not going to stop selling this way just because I don't like it, of course. But I do spend a considerable amount of time working to overcome mistakes that were made by other, less experienced builders. And let me promise you, some of the stuff I see is horrendous from a technical perspective (if not dangerous outright). I spent several years pursuing formal education in this field. More still on advanced technical training (like micro-mini electronics repair in US Navy avionics; arguably the best in the world). And decades honing a skill set. I'm sorry, but you just cannot replace that with a box of parts from Amazon. End users are responsible for more problems with hardware and building by far than anything associated with design. For some reason, everyone seems to understand that doctors exist for a reason. And we all know what they say about a fool and his lawyer. But for some reason, some people seem to think that spending money on parts and/or paying others to build things for them somehow makes them an expert. But, somehow, people are still paying me to fix their f*ckups. I would respectfully submit that what's happening (and has) - at least in part - is that these people are in over their heads. They simply lack a level of skill and training appropriate to the stuff they're messing with. To contend anything else is to dismiss the lifetime of training and experience earned by professionals just like me. TBH the smart ones are the ones who seek out and commission qualified expert help, with verifiable references. If nothing else, they'll stand behind their work. As I saw once on a plumbing truck: "Do it yourself first, then when it breaks, call us." (Now this is straying a bit off topic and I'll apologize; I am only responding to someone else's comment)

Hi again @nephilimborn I am grateful you shared the pics and are also willing to invest the time in actually understanding what could well be going on. Yeah, that bend seems a little tight for me; maybe not terrible but as you said, not within the guidance (thanks BTW for the correct figures, lol I was too lazy to go find them). I am very relieved you actually understand the 'root cause' factor at issue here. It always makes things so much easier to work with someone who's actually capable in that regard. I was concerned about it because it is among the issues that cause the connector failures. I do sincerely appreciate your acknowledgement in this respect. I am flatly amazed at the number of people who will file lawsuits etc, rather than take responsibility for their own/their builder's work. As I've said (and as Nvidia will surely say, if pressed in a lawsuit) there would have to be a reason that so many people have used the exact same connector and *don't* have problems (and if I understood correctly, we're talking into 6 figures). Like I said I wouldn't really have any reason to blame my mechanic or Toyota because my wife rides the brakes (and believe me, those maintenance guys appreciate that I understand what's taking place! LOL) Someone reading this might ask why the distinction matters so much to people like me. If I can take the liberty, the reason is that if one assumes it's just a 'bad cable' and simply replaces the cable in the same fashion...then given the same heat, time and mechanical stress...(as I bet you already know) the replacement cable will also fail, possibly quicker than the one that was replaced. The 'repair' didn't really correct the problem, because the user failed to recognize the cable issue was a symptom of the problem, rather than the problem itself. That's why the 'root cause' matters so much (for the benefit of the reader who actually wants to learn) - and I can't tell you how glad I am that you seem to actually understand this. BTW the example I just made actually assume the cable is even failed...the problem could easily be that mechanical strain is causing poor mating of the contacts - meaning the cable isn't even bad at all, just needs to have the bends remedied. I'd honestly prefer to think that would be the case, as opposed to that nice MSI PSU actually having a "bad" cable. Again - actually understanding 'root cause' matters. A lot. Hopefully the stuff you've ordered will help overcome the root cause and thus correct your issues once and for all. I'm glad if my input helped. Now if you'll excuse me, my mechanic is calling...says the wife's car needs brakes (again? lol)

As i said, it's all good...you go right ahead, keep posting links to cables that'll melt someone's motherboard if they don't know any better. Hopefully nobody decides to sue you lmao