• Content count

  • Joined

  • Last visited

Everything posted by steve_v

  1. #1: Fix GC stutter. #2: Fix DOA console port. #3: Fix janky wet-noodle physics. #4: Reduce memory consumption. #5: Fix janky collision detection. #6: Properly guard physics calculations to eliminate NaN kraken & co. #7: Fix patcher. #8: Wheels that are round and don't behave like catapults. #9: Fix sliding while landed. #10: Update to current Unity version. #11: Fix bugs introduced by #10. #12: Fix horrendous lag during explosions / disassembly. #13: Improve miserable performance of aero effects. #14: Improve miserable performance in general. #15: Career mode that makes sense. #16: Multiplayer, as promised. #17: Clouds. #18: Something to do on planets etc. #19: GP2, as promised. #20: Some end-game goals. .... #237: Update textures. Textures are so far down my list, I might as well say "don't care". So I did.
  2. Switching to a ship or base I have not visited in a while, wondering if it's going to explode, sink into the ground, or just vanish into the NaN. Possibly deleting a bunch of other vessels in the process. Deploying anything that's mounted near a cargo bay, since it's a 50/50 as to whether it says "cannot deploy while stowed". launching anything with bi/tri/quad couplers, watching carefully for the spaghetti-copter effect. Switching to a vessel that is splashed down, for fear that it will "collide with terrain" and explode. landing with 'chutes, in case the game randomly crashes when I'm 50m above the ground and the 'chutes don't redeploy when I load it again. Loading a large station, waiting for it to start thrashing itself to death. Bugs. The most stressful moment is the bugs.
  3. Restart it. I'm used to KSP crashing or randomly bugging out. It's "when", not "if". If it crashes too many times in a play session I'll ragequit and stop playing KSP KCP for a week or two. This is why I'm mucking about here, rather than playing.
  4. Use a less annoying operating system. I recommend a UNIX derivative. That message is Windows UAC (User Aggravation Controller) warning you that (shock and horror) KSP is trying to write to the hard disk. Why it sees this rather mundane activity as a problem is a question to ask Microsoft. My guess is that it's getting excited because a) you're running KSP as administrator, or b) KSP is installed in a "system" directory (e.g. Program Files). If KSP is in a system directory, moving it somewhere else might be a good idea. I think the desktop is probably safe, but you never know with this thing. UAC is fickle and easily riled. Alternatively, you can kill UAC popups permanently from the Windows control panel, under "User Accounts". Do so only if you understand the implications.
  5. The patcher built into the launcher is broken and has been abandoned. As no valid reason for this has been offered, I'm assuming a certain game vendor is simply too lazy to maintain it. Don't use it, it won't work. The current "update" procedure is to download the (entire ~700MB) new version from wherever you got KSP in the first place (e.g. kerbal store, GOG), unpack it somewhere, and copy your saves over. Not sure how well save files from 1.0.5 will work in 1.3 though, they're supposed to be compatible, but YMMV. Probably just the usual game engine screweyness we all know and love. So much so that the phenomenon has a cute name: The Space Kraken. Back up your saves regularly and avoid doing things that freak out the physics calculations, such as trying to land on Kerbol... The game will probably implode sooner or later anyway, so back to point one: Back up your saves. Indeed, but you might as well say "update to 1.3", as it's functionally the same thing. Evidently SQUAD finds distributing patches or fixing the updater far too difficult. Yes, I'm going for equine mince here. The "I'm using the patcher and it doesn't work" question is still appearing, so I guess it's not quite dead yet.
  6. No log, so speculation it is... * Open the debug window (MOD+F12) and see if anything is logging errors when this performance drop occurs. * Install Memgraph, see if the framedrops line up with garbage collection runs. If they do, it's almost certainly the crappy (and ancient) managed runtime that Unity uses, probably exacerbated by poorly coded mods. That it occurs every 5 seconds and gets worse as your career game progresses (more craft in flight) makes it sound like this is a likely cause. This problem exists in stock installs, is exacerbated by mods, and lies squarely in the 'too hard' basket as far as Squad is concerned. No fix. Only mitigations are to remove mods that create a lot of garbage and/or use Memgraphs 'heap padding' feature. If there's no correlation with either, start removing mods a few at a time until you isolate the culprit. I'd start with math heavy mods (e.g. USI, KER, Trajectories) and graphics mods, if you have any installed. Are you running the same list of mods you were in 1.2.x? Are they all properly 1.3 compatible? Using mods that aren't built for 1.3 will create all manner of problems. As you have not mentioned which OS you are running, I can't really comment on potential external influences. That said, if it's Windoze, check out the usual suspects - background services, antivirus and the like, and use whatever system load monitor it ships with to see if something else is chewing up CPU time / disk IO.
  7. ModuleManager is required by (and bundled with) heaps of mods, and I'm sure NF is one of them. You have ModuleManager.2.8.0.dll in your GameData directory?
  8. So reinstall it? Nothing special needed here, just delete averything but your saves/screenshots etc. directories, reinstall KSP, then reinstall your mods. Make sure you also install their dependencies. If you think you have mod issues, just add mods one at a time until you identify the problem. Automatically (or otherwise) 'fixing' a modded install is more trouble to do right than it is to just nuke and rebuild. Using CKANs export / import feature can be a time-saver here. That said, your current list of problems does sound like you're missing some common dependency, you have got ModuleManager and co., right?
  9. When talking about RAM clock speed, you also need to look at the rest of the timings - particularly CAS latency. Most workloads care a lot more about latency than raw throughput. A lot of vendors back off the timings to get a bigger MHz number on the box, and when they do, it doesn't translate to faster memory at all. I'd say just get good quality modules at a clock your board supports as standard, ignore 'overclocked' (=overpriced) RAM and non-standard speeds. Memory throughput is only a minor contributor to overall system performance. What you have is probably okay as far as speed goes (though 300MHz doesn't sound at all right) anyway, if you're hurting for RAM just get some more of the same.
  10. Unix is that 'other' operating system that has been there all along... While DOS and early versions of MacOS were making their way onto small household 'mini' or 'micro' computers, Unix was running on the the big commercial and scientific mainframes. While DOS was built to be easy to program for a single user, Unix was designed to handle many simultanious users and varying workloads. These basic principles have remained through countless variants, forks, and changes of ownership. MacOS X is probably the modern commercial Unix most are familiar with, but there are many others. Linux is a free, open source, Unix-like operating system kernel (the bit that talks directly to the hardware). Most of the time when people say "Linux", they really mean "GNU/Linux" (which is a mouthfull). Linux is the kernel, GNU is the rest of the operating system. GNU stands for GNU is Not Unix, apparently, but it is pretty much a free version of Unix written from scratch, one component at a time. Linux allows it to run on a wide variety of hardware. Richard Stallman would beg to differ The kernel is useless without a userland to run applications and a toolchain to build those applications (including the kernel itself)... all that comes from the GNU project, which predates Linux and contains considerably more code. Linux is what it is today because Linus released it into an environment where a complete Unix system (GNU) already existed... all it needed to become a viable operating system was a kernel. That's one "claim to fame". The real advantage of the Linux kernel is that it is highly customisable, and customisable by the end-user. Not only does it run on smart fridges and smart phones, it also powers a majority of the worlds supercomputers and webservers. It scales from the smallest processors all the way to superclusters. To go back a bit: GNU/Linux can be as light or heavy as you want it to be. And as with any ecosystem, diversity is good, monocultures breed disease. Windows everywhere is a monoculture, and that's why there's so much Windows malware. I run CAD just fine, there are a bunch of applications available, both open-source and commercial. The only problem is the lack of the 2 'industry standard' applications (AutoCAD and SolidWorks), but there's nothing that you can't do without them if you're willing to learn something else. Have you tried BricsCAD or VariCAD? If you only need 2D drawing (90% of the time for me), QCAD/LibreCad is also rather good (and free). As for games, I play lots of games. Don't feel I'm missing out on anything important. There are too many examples to list, if you want some, just look at the selection on Steam. The "Linux doesn't have enough applications" argument is an old one, and it's getting less valid by the day. It's also a chicken-and-egg problem: In a capitalist society, consumer choice dictates production (in theory anyway), so to get more GNU/Linux applications one only needs more demand... You see where this is going of course. The situation is slowly improving, as more users eschew the 'default' Windows environment and ask software vendors for alternatives, more of those vendors see *nix ports as a viable business proposition. There are holdouts, of course, and for those there's complaining... and VirtualBox or Wine. In other news, I binned that power supply. On closer inspection, it appears that one corner of the fan controller / monitoring board actually caught fire . As the board substrate is damaged, it's not really worth my time to fix it. Here's a (lousy phone camera) pic, for anyone curious. And it's an Antec EA-750 Green, if you want to avoid them. The EA series was awesome, not so much the "green" refresh. And don't give me lip about the state of my coffee cup... I've heard it all before.
  11. No. If you have a 64bit OS & >= 4GB of RAM you should run the 64bit binary. If you want to install many mods, you will need to. But you still haven't posted your log. If you are running out of RAM this will be obvious from said log, and posting it when Galileo asked for it would have spared this needless guessing game...
  12. True, though the root of the problem is most likely that KSP is installed in a location that has admin ownership by default, like Program Files. Find your KSP install directory and "own" it as your unprivileged user. I don't use Windows often, but this looks about right. Or you could just put up with the UAC prompt every time you want to modify files there.
  13. Seems I was looking at the wrong mod. That'll teach me for doing 5 things at once...
  14. Your .version file is correct, so this may be another CKAN bug... It wouldn't be the first, another mod hit much the same issue recently.
  15. Indeed, this is pretty annoying. @linuxgurugamer, the CKAN metadata includes: "EditorExtensionsRedux": { "module_version": { "3.3.13" ... "ksp_version_max": "1.3.0", "ksp_version_min": "1.2.0", Which indicates it's compatible with any KSP version from 1.2 - 1.3, is this correct? From what I see it's incompatible with 1.2.x, and should be marked as such...
  16. My "Standard" interplanetary craft, loading crew and fuel for a trip to laythe, with a surface base and light VTOL as payload (everything forward of the 'orca' command module): Cargo spaceplane docked to the rear (fuelling) port, from there on up: NF MPD engines, reactors (4) & radiators (retracted), primary lithium tankage, propulsion/crew module coupling & manoeuvring fuel, auxiliary (life support) reactor, fertiliser tank, external lithium tanks (radial docking ports) x2, greenhouse, crew quarters, command module. As shown it has ~8.5k DV and ~9 years life support / habitation for 3 kerbals. Another departing ike, no ETs required for Duna, or Jool without payload: This sucker is expensive though, launched in 2 parts and totalling ~3.5M IIRC. Most of the cost is the reactors. Mods: NearFuture & MKS. M2X & M3X for the spaceplane.
  17. As soon as the GNU/Linux build was available. No GNU/Linux build == no purchase.
  18. Does that actually replace all the system files though? I'm not sure I'd trust such a thing to remove e.g. an entrenched malware infection. I do like my destroyer of disks, for its complete obliteration... Eh? that's odd. This automerge thing is a fickle beast.
  19. Perhaps I should have said "everything else that I have seen". My current arch nemesis (and chosen example) is AVG free, which certain people keep reinstalling after I remove it... Resource hog? Check. Nagware popups? Check. Scareware popups? Check. Browser toolbar: Check. Doesn't have ads though... Except ads for the paid version of AVG. So, adware: Check. As for creating security issues, if you keep up with the news on emerging exploits, there have been several nasty issues found in both free and paid AV products recently. Such as unpacking potential malware in kernel space with ring0 privileges, and laughably insecure update mechanisms. Then of course there's the utterly idiotic "feature" of intercepting SSL and messing with certificates. if you can point me at a free AV product with no nag (upgrade to premium) popups, no scareware (everyone can see what you do on the internet!) "alerts", no "PC tuneup" interruptions, and no browser toolbars - essentially nothing but unobtrusive antivirus, and one that doesn't do moronic things like flog the disk to death scanning a 100G VM image while I'm trying to work... Maybe I'll recommend that instead. AV is the ambulance at the bottom of the cliff anyway. You shouldn't be acquiring infected files to begin with.
  20. RCS Build Aid all the way. Not 1.3 compatible yet though, AFAIK.
  21. At least we're getting somewhere now. output.log.txt? Also, installing under C:\Users has been known to cause issues (Or so I have heard from those that use that Windows thing). Might be worth moving it elsewhere (not Program Files either) in case Windows is being stupid about permissions.
  22. And all those mods are compatible with 1.3, are they? Incompatible mods will crash the game... The first step is to see if it still crashes with no mods installed. I looked around that site for about 15 seconds, didn't see an "add DMP" button, closed the window. If you can't be bothered listing your mods, why should I go hunting around for them? You are the one wanting help with a crash, no? Go read the "how to get support" sticky at the top of this subforum, then upload your output.log.txt (to e.g. Dropbox) and post a link.
  23. Version? Mod list? output.log.txt? Crystal ball?
  24. Must be all that coffee you Ubuntites drink over there. I'll stick to my calming fermented beverages.
  25. Not so fast buddy. You'll need to change your sources.list to point at the new release first, or not a whole lot will happen... But don't do that anyway, read the post I linked on upgrading Mint, the procedure (mintupdate) appears very different to Debian. The alternative is to go hunting for backporting instructions or some kind soul that fired up a GCC 4.9 repo for trusty. You might get lucky here, but I don't know enough about Mint / Ubuntu to provide either. <grumble> There's no reason for Squad to build their library against GCC 4.9 libs anyway, it's not using anything new. If they had compiled it with 4.8 this problem would not exist, and it would work on a bunch more distros. </grumble>