steve_v

Members
  • Content Count

    3,329
  • Joined

  • Last visited

Community Reputation

2,414 Excellent

About steve_v

  • Rank
    Grumpy Sparky

Contact Methods

  • Skype Array
  • Twitter Array

Profile Information

  • Location Array

Recent Profile Visitors

5,827 profile views
  1. Excellent. Makes an otherwise pretty crappy probe core useful. I do, though I was kinda hoping you'd get enough from the log to avoid all that. I'm not running any mods I haven't successfully with BV before, but if that's what it takes then that's what it takes.
  2. The only thing more obnoxiously loud than a 2U cooler is a 1U cooler... But it's a Dell, isn't it? Ick. Supermicro all the way.
  3. Sweet music it is CPU1 Temp | 60.000 | degrees C | ok CPU2 Temp | 60.000 | degrees C | ok System Temp | 51.000 | degrees C | ok Peripheral Temp | 47.000 | degrees C | ok PCH Temp | 56.000 | degrees C | ok P1-DIMMA1 TEMP | 58.000 | degrees C | ok P1-DIMMB1 TEMP | 54.000 | degrees C | ok P1-DIMMC1 TEMP | 52.000 | degrees C | ok P1-DIMMD1 TEMP | 55.000 | degrees C | ok P2-DIMME1 TEMP | 55.000 | degrees C | ok P2-DIMMF1 TEMP | 59.000 | degrees C | ok P2-DIMMG1 TEMP | 60.000 | degrees C | ok P2-DIMMH1 TEMP | 59.000 | degrees C | ok FAN1 | 2850.000 | RPM | ok FAN2 | 2850.000 | RPM | ok FAN3 | 1950.000 | RPM | ok FANA | 1200.000 | RPM | ok FANB | 1200.000 | RPM | ok A pair of 92mm Nidec UltraFLOs at 2850RPM is, uhh, moderately loud? Flat out at 3800RPM is... Louder. Never seen it get there though. Still pretty quiet for a dual-socket server though, the 2U coolers I took off it rev to 8400RPM... Ed. 550W, without a GPU in sight... welp. My power bill will love me.
  4. Pretty sure it's just the included BV controller part, the probe core is an octo, and I haven't patched it for BV nor does it show in it's PAW. On closer inspection, I see: [LOG 06:15:19.114] [HighLogic]: =========================== Scene Change : From FLIGHT to FLIGHT ===================== [LOG 06:15:19.127] Camera Mode: CHASE [LOG 06:15:19.128] [ApplicationLauncher] SetVisible: [LOG 06:15:19.132] ScaleModList: listSize 410 maxListSize 573 [LOG 06:15:19.132] ScaleModList: listSize 410 maxListSize 573 [LOG 06:15:19.132] ScaleModList: listSize 410 maxListSize 573 [EXC 06:15:19.146] NullReferenceException: Object reference not set to an instance of an object BonVoyage.RoverController.Update (System.Double currentTime) (at <32eb7dad6e444dd78672072e1a996b3c>:0) BonVoyage.BonVoyage.Update () (at <32eb7dad6e444dd78672072e1a996b3c>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [LOG 06:15:19.300] -INFO- Tac.LifeSupportController[FF847CA2][20014.08]: OnDestroy So something is borking. Full log here.
  5. Yes. No. No. A "blue screen" (or BSOD) is a generic term covering a multitude of fatal Windows errors. Don't be ridiculous. Why should a game, of all things, nanny broken hardware? Monitoring hardware is the job of the hardware monitoring ASIC or microcontroller (like this one), and sometimes the OS or BMC. Individual applications have neither the need nor the privileges required to access or control hardware limits. Monitoring hardware temperature isn't the applications job (and would mean including drivers for a multitude of systems), and changing hardware limits or cooling targets would require interfering with the BIOS or CPU microcode, which no game could or would even attempt. Now you're really grasping at straws... And you should probably quit while you're ahead well, something anyway. My overclocked and still perfectly operational machines might beg to differ, a couple of them are going on 20 As long as you're not pushing silly voltages or running silly hot, overclocking is just "re-binning" the CPU anyway.
  6. Is it intended that a rover with insufficient power generation to drive continuously (but plenty of battery) stops immediately on scene change? The "Insufficient power, average speed reduced by x%" message in the control panel suggests that the average speed will be, well, simply reduced. As in, not zero. Yet I get a message stating the vehicle has stopped, and the controller shows as "idle" as soon as I switch away from it...
  7. Hardware problem. Hardware problem. Hardware problem. Still not seeing what this has to do with games or any other application, and as I said, I'm done arguing about it. If you want to continue believing that your shoddy or ill-maintained hardware dying on you is somehow the fault of a game developer, you're welcome <snip>
  8. I'm done here. TBF I probably shouldn't have let myself get sucked into this old argument to begin with, it's one of those myths that get regurgitated in "gamer" circles fairly regularly and it seems to yank my chain every time. KSP may have 99 problems, but damaging hardware isn't one of them.
  9. Sure. Not disputed. Perhaps you would like to explain how all those overclockers and system builders are able to run stress tests, applications specifically designed to use all available resources, for hours or days on end without "over stressing" the hardware then? How is it the machine on my desk, which runs at 100% CPU usage (folding) whenever I'm not using it, somehow managed not only to never crash but also to run near-continuously at full load for some 7 years now? Magic? Heat can cause hardware damage. Heat that is not being removed by the cooling system whose only job is to do exactly that. Applications can only request the system to do work for them. If the system is busy, they have to wait, this is why slow machines are slow. The system is in control of what gets done and when, if it promises more than it can deliver it's not the fault of the application for asking. A background in electrical engineering, 25 years building and administering PC based systems, and a reasonable physics education will do that to you...
  10. If your system crashes under load, there's something wrong with it...That something is likely insufficient cooling or unstable power delivery, and those are hardware faults, it has nothing to do with any game. Applications merely utilise the resources the system makes available to them, if the machine can't actually sustain that level of performance without crashing, the machine is the problem. Running at excessive temperatures may indeed reduce the life of components, so if your system runs hot under load you might want to investigate why the cooling system is not doing it's job.
  11. Games don't damage hardware, or any other application for that matter. Nor do CPUs "wear out" on any relevant timescale. If software causes your hardware to overheat, the problem is inadequate cooling.
  12. Sure, if your code is an unmaintainable mess. A great many "non-trivial" software projects manage relatively bug-free releases, just not this one. Somehow they even manage to ship .0 releases free of obvious bugs most of the time... Perhaps it's by magic? I'm using a relatively bug-free web browser on a relatively bug-free operating system running a relatively bug-free kernel right now in fact. How strange. An end goal that KSP does not appear to be coming any closer to... 7+ years in "common" and "problematic" bugs like the awful wheel model, craft sliding around, craft spawning underground or far above the surface, kerbals sliding on ladders, flickering orbits, shifting orbits, pervasive collision detection jank, recurring fairing and cargobay bugs, parts displacing permanently on reload, garbage collection stutter, and various physics kraken to numerous to list are still not "eliminated". Add to that the multiple-facepalm-worthy game engine borkage we see every couple of versions, like continual crashing, broken HID support, broken settings system, and broken graphics... Yeah, "eliminate the most common and problematic" my ass. More like "release broken, hotfix the easy stuff, hype the next version". As for the "right now" situation, I'm pretty sure broken resource transfer fits the description of both common and problematic.
  13. Flex at the weak docking nodes is likely the original cause of the displacement, but parts becoming permanently displaced is a bug that goes back to alpha. The problem is more obvious when robotics are involved (and used to plague IR in a big way), but any joint that moves under physics forces has a chance to be permanently screwed up on game reload. Such accumulated displacement is a prime suspect for those mysterious "my perfectly fine ship/station explodes on load all of a sudden" reports that pop up from time to time too. That report I linked is just the most recent, and the only one post bugtracker "cleanup". Amazing how all those old bugs go away when someone starts deleting things from the tracker... KJRn might be worth a look, as it attempts to strengthen connections where they should be, rather than where they are. YMMV though, IME a (complex) craft infected with this bug is krakenbait forever more.
  14. The docking ports aren't the parts that have moved... I'm betting it's this one. Note the "acknowledged" status, which until informed to the contrary, I'm assuming means "Too hard, won't fix".