Starman4308

Superfetch should not be doing that. The point is that virtual memory should always be accessible, even if it has to go to the pagefile, and Superfetch should only be compressing seldom-used items. If your physical memory is under significant load, I wouldn't be surprised to see half of KSP compressed and/or moved to the pagefile, because the KSP devs had the bright idea to load enormous texture files straight into memory, few of which you will be using at any given moment. Compressing memory is a good idea when programs are really sloppy about what they decide to load. Let's say you're playing KSP, and for the entire session, you never even glance at Eeloo. Your system is under memory pressure from the 127 parts mods you decided to download with max-res textures, and it needs to make some space. It makes sense to the OS to either compress the Eeloo textures or send them to the page file, because they haven't been accessed in forever, and it's unlikely they will be needed in the future, so the OS says "I'll just move these out of the way; the chance it'll actually be needed and slow down the system is minimal". RAM is not truly randomly accessed; there are distinct usage patterns that the OS can take advant

It's entirely plausible that 7 GB of KSP plus 1 GB of everything else is a low-load condition. It is extremely hard to be certain from what simple tools like Window's resource monitor tells you, because memory management is a complicated topic, and modern programs are extraordinarily lazy about freeing up unused memory if nothing else needs that memory. To be clear: #1: KSP runs on Mono, which is a garbage-collected language. This means that, instead of explicitly allocating and de-allocating memory for objects and arrays like you might in C or Fortran, you just declare the object or array, and trust that Mono will de-allocate that memory when it runs a garbage collection sweep. #2: Garbage collection sweeps are when Mono goes through, and finds all variables which can no longer be accessed by any thread. This occurs when something goes out of scope or is de-referenced. For example, in pseudocode: int[] someIntegers = { 1, 2, 3, 4, 5}; if (rocketUnexploded) { List<Part> rocketParts = rocketPartTree.getParts().asList(); doSomething(rocketParts); } // The rocketParts list is now rootless, and subject to garbage collection, as it only lived inside the scope of the now-finished if block. someIntegers = { 6, 7, 8, 9, 10 }; // The old someIntegers array is now rootless, and subject to garbage collection. #3: Any decent garbage-collected language will garbage collect as infrequently as possible. This takes a fair chunk of CPU time, and simple GC implementations generally have to stop the world, halt all program execution while the GC sweeps through. #4: As a consequence, if Mono can get away with it, it'll just allocate loads of memory to itself until the operating system cuts it off, and garbage collect as infrequently as possible. #5: The operating system is doing that as well, refusing to clear stuff out of virtual memory or move it to the page file unless it absolutely has to. #6: Therefore, "KSP is using 7 GB!" is a terrible metric of whether KSP is actually stressing your system's physical memory. You might look into MemGraph to see if there is really any substantial memory problem with your installation; memory is only a problem if you have frequent garbage collection pauses.

Are you sure it's putting everything that isn't KSP into swap/page file, and whether those pieces of memory are actually being used? Slowdowns due to memory can be hard to properly diagnose; it can be hard to know whether that 95% memory usage is actually you running out of memory, or just the OS/KSP being lazy about garbage collection. Neither your OS nor KSP will bother to do garbage collection if there's plenty of memory available.

I think it's safe to say that the "or" in your statement is a mathematician's "or"; even careful operators will have accidents. I'll point out, though, that A, reactors go supercritical all the time (i.e: when they want to increase reactor output), and B, getting a mushroom cloud* is extraordinarily difficult, requiring a fissile mass to go prompt-critical very very quickly so that a large fraction of the nuclei react before your nuclear weapon ceases to be a nuclear weapon and starts to be a rapidly expanding cloud of plasma. *You know what I mean.

Probably the biggest issues are: #1: Very difficult to intercept a comet; either large amounts of delta-V or a multi-slingshot trajectory will be required, neither of which plays well with manned missions. #2: In order to maneuver the comet, sophisticated equipment would be needed to mine the comet for LH2+LOX and attach an engine. #3: Good luck keeping said comet intact during thrusting.

Am I correct in understanding that, by the time you're at Ganymede, Jovian radiation has dropped to levels practical for manned/Kerballed exploration? Even at the most distant point, Ganymede will be at most a few light-seconds away from the inner Jovian moons, potentially making tele-operation of probes from Ganymede or a similar orbit a reasonable thing to do.

Try reading the thread. There is literally a status update by Ferram on the page before this one.

That's intentional: if you can't figure out how to get the dev version yourself, Ferram doesn't want you using the dev version. This helps ensure that he doesn't get needless bug reports from people who are A, using the dev version, B, don't understand how to make a decent bug report.

There's also hydrogen-oxygen engines, which are run very fuel-rich. They're typically run as hot as possible without melting the combustion chamber, so there's no real point to trying to increase burn intensity, and hydrogen is the best possible exhaust gas, having less molecular mass (2 g/mol) than anything else we could feasibly use... unless you can somehow figure out how to eject monoatomic hydrogen out an exhaust, anyways.

Not really; the only metric by which hydrogen has less energy is on a per-mol basis, and that is heavily misleading due to how many atoms methane and kerosene have. Hydrogen has a spectacular energy-to-mass ratio (part of why it's the most efficient practical chemical rocket fuel), with its primary disadvantages being that it's incredibly cryogenic and very low-density. If I did the math right, hydrogen should provide 572 kJ of energy per mol of oxygen (assuming stoichiometric ratios), with methane providing 445.11 kJ per mol of oxygen consumed. I can't necessarily address the energy needed to compress the intake gases, and I am pretty sure atmospheric fuel + oxidizer will be inferior to fuel + atmospheric O2, but it'd still be a great deal more efficient than rocketry would be. If you wanted a minimally-cheaty probe to send as deep into Jool's atmosphere as possible and still return, these engines would be an excellent choice to get you out to upper atmosphere. When it comes to Eve: its closest analog (Venus) has mostly just inert atmospheric gases (carbon dioxide and nitrogen), both of which could be used as reaction mass for an air-assisted rocket, nuclear turbine, etc, but could not contribute as either fuel or oxidizer to a chemical reaction.

I'm pretty sure that's intentional, as in "you are throwing an aerodynamically unstable object into a very high-velocity airstream, of course it's going to break into a thousand little bits" intentional. This is why a lot of real-world decoupling occurs well above the atmosphere, so that the airstream doesn't do unfortunate things to the discarded stage while still in proximity to un-discarded stages.

I have no idea if the .cfg still works in 1.2.2, but here's a patch I hacked up in 1.1.3 to add convert-to-real-fuels functionality: https://www.dropbox.com/s/sm8nt0df10qbz86/StockISRU-RealFuels.cfg?dl=0 Tweak as desired: I know I was not-that-great at doing anything fancy like saying "okay, instead of writing out the exact outputs for every engine and every conversion type, multiply a converter-specific constant by a recipe-specific constant to get output". I'm also pretty sure the UDMH and MMH recipes are in the realm of fantasy, requiring far too many steps to convert raw NH3, CO2, and H2O. https://www.dropbox.com/s/09e08kp5qey2g17/Spreadsheet.xlsx?dl=0 Also, do note that it assumes Karbonite or Ore are exactly what they need to be, and don't use real resources like water, ammonia, carbon dioxide, etc. Getting a fully satisfactory real ISRU mod without hand-waving is a major project.

There are quite a few people who do manually edit their save files, including me. It's entirely reasonable to use a quick hash function to double-check that it hasn't been changed, so that the .loadmeta always reports valid information regardless of whether the user was mucking with it or not. Granted, I like Snark's suggestion of putting the .loadmeta (with the hash) in a subfolder, but eliminating the hash function breaks the existing functionality of "always reports the state of the save, even if the user decided he'd rather load a file slightly different from what was saved".

As a heads-up: Notepad++ is Windows-only, though it does make a decent text editor. I've started to use Sublime a bit, in addition to my usual Vim* shenanigans. *Vim is a command-line based text editor, used mostly by those who are comfortable with the command line. I'm going to take a wild guess that you are not super-familiar with the command line, and as such, I wouldn't recommend Vim

How I'd approach it with limited time: Plot a trans-Jool slingshot (capture in front of Jool, eject behind Jool), burning at peri-Jool to take advantage of the Oberth effect and minimize delta-V expenditure to get a retrograde solar orbit. If you've got MechJeb, just tell it to execute the burn, and go do something else for the duration. Without that, I'd have gone insane playing at 6.4x scale with my penchant for low-TWR vehicles. With unlimited time: Transfer to Eve, slingshot to Kerbin, back to Eve, back to Kerbin, out to Jool and near solar escape velocity (may take a second Jool slingshot, I don't know), reverse course at apohelion, use Jool slingshots to brake to target orbit. This sort of gravitational ping-pong, combined with a bi-elliptic transfer for the plane change, leads to very efficient but not particularly quick transfers.

One possibility: some gaming laptops have a button to force the computer to use the integrated graphics rather than the dedicated graphics chip; make sure that's toggled correctly. Do you have similar problems with other games, or is it just KSP? Potentially, you might try reinstalling KSP; the other possibility is that you're trying to control a 1000-part monster vessel, which will lag any computer. The other possibility that springs to mind is that your computer isn't being cooled very well; at the least prop the back up to get airflow, and there are dedicated cooling pads.

One of the usual culprits is NVIDIA ShadowPlay, which by default remaps alt-F12 to something (screenshots? I forget). Remap that, and alt-F12 should work again... assuming that was the problem in the first place.

The specs I'm seeing for HP Stream 14 are dual-core 1.6 GHz... which may probably be better than a quad-core 1 GHz; at least originally KSP was a single-thread monster, and I'm unsure how well they've distributed the workload to other threads. As to the home desktop: yep, sounds reasonable. For the HP Stream, I've suggested all I can; increase delta-T, reduce graphics settings, close background processes... and in the end, just accept that it's a very weak machine. Best of luck to you; fortunately KSP is at least playable on weak machines for times such as "can't haul desktop on the flight to visit family over winter break".

First, I am very, very unsurprised to see that dinky little laptop running KSP poorly. The HP website boasts "industry leading processor so you never need to worry if it's powerful enough"; that is a colossal joke. Second, there are three main elements KSP hits: CPU, GPU, and memory, of which the first is limiting for high-end computers. For memory: you need enough of it to load KSP, any mods involved (particularly parts mods with memory-hungry textures and models), hold any background processes, without putting anything important into swap memory (basically using the hard drive/SSD as extra memory as a last-ditch effort). 4 GB can be kind of tight, 8 GB is usually enough unless you're one of those "Mod It Till It Crashes" types, and 16 GB would be overkill. The speed usually doesn't matter too much; generally, standard DDR3-1600 or DDR4-2133 is more than sufficient for the task. For the GPU: This is usually the limiting factor for AAA games, since those games tend to be computationally simple, but packed with very demanding graphics elements. The general advice is to set graphics settings down until either your FPS plateaus (GPU is crunching frames faster than the CPU can push them to the GPU), your FPS exceeds the refresh rate of your monitor (usually 60 FPS), or you're just generally happy with it. For KSP, fortunately, graphics are rarely limiting, particularly when notched down to minimum. Even with the relatively wimpy integrated GPU on that laptop, I doubt it's the issue. When it comes to the CPU, this is usually (unless there are memory problems) the limiting factor for KSP, which is a very physics-heavy simulation game that puts huge loads on the CPU. You've got to calculate forces on every part by every other part, manage on-rails vessels, manage CommNet, aerodynamics, heating, solar panels, and many other things which hit the CPU for each and every simulation timestep. The quick-and-dirty way is to increase the maximum time per frame, which lengthens the KSP simulation timestep at the cost of making the simulation slightly less accurate. For this, all I can suggest is to keep your craft small, avoid any CPU-hungry background processes, keep your laptop cool (prop it up so the bottom fans are unobstructed, etc), avoid some of the more CPU-hungry mods (my best guess is that FAR will be the worst offender), and, well... It's a 1.6 GHz dual-core Celeron. Were you really expecting much out of that thing?

My best guess is that it makes ensuring .loadmeta validity much simpler to implement; the game checks to see if the hash of the save file matches the hash stored in the .loadmeta. If the files were combined into one, then you'd need some slightly complicated logic to ensure it only hashed the savefile contents, and not the meta-data, because otherwise the hash would never match (since you're re-writing it each time with the hash generated from a file with a modified hash generated from a file with a modified hash...). While one could theoretically try to manage things so only the non-metadata portion of the combined savefile was hashed, it's much simpler and more maintainable coding-wise to say "hash this file and compare to string in this other file" than say "hash only certain parts of this file and compare to a string inside it"; you need to figure out how to exclude certain bytes from what you're feeding into the hashing function. Furthermore, if more metadata needs to be stored, you don't need to add another exception into your "exclude some bytes" mechanism, you just have to write it to the .loadmeta file. It could be done, but the cost/benefit ratio of making that change is very unfavorable.

For launch abort in particular: because you want your escape tower to fire and get the capsule clear, then pop the chutes, and quite possibly ditch the escape tower itself. As to action groups: I try to put repeatable science (i.e. thermometer, gravitometer) on 4, non-repeatable science (goo pods, etc) on 5, and haven't really needed much else for action groups yet.

Second, it's clear to me that the 1.25m and 2.5m parts were intended to fill different roles, that they were never meant to be balanced against each other, and might be considered parts of two different systems, with the 2.5m with large drills filling the role of heavy-duty, industrial-scale ISRU operation, and the smaller parts intended for small probes where you don't necessarily mind if it takes months to fill up the tanks. If you want something efficient and effective, go to 2.5m. If you just want something that will fill up eventually, go with 1.25m, which was never intended to be efficient.

I think the edits were made successfully to BaseConverter; could you check to see it was done properly? Also, if I understand that formula correct, if you think engineers increasing ISRU yield by 25x is completely and utterly ridiculous, you can swing it back towards less engineer bonus by increasing SpecialistBonusBase towards 1.0, and reducing SpecialistEfficiencyFactor down to something vaguely reasonable. Personally, I might go for SBB of 0.65 and SEF of 0.1; that makes unmanned ISRU something vaguely useful, while still preserving the max output of having a 5-star engineer.

Given the sheer ease with which this "bug" could be fixed by the devs (literally just a quick config file edit), I am given to suspect it is an intentional design decision. If you don't like it? There's this thing called "config file editing" and another called "module manager".

Generally speaking, quasi-realistic ISRU should assume the net loss of energy; for example, converting ice or hydrates to hydrogen-oxygen fuel means a large investment in energy, because not only do you have to drill the raw material out, you also have to convert it to a useable propellant. Only in a few places will you find either a raw fuel (such as hydrocarbons) or a raw oxidizer, and so far as I know, Earth is the only planet where those two coexist, and that's mainly because of this weird little thing called "life". In terms of game balance: while it's probably a bit exaggerated, I see why they did it; by making ISRU so heavy, and by benefiting so much from engineers, they encourage Kerballed exploration, with the 1.25m ISRU mostly as something to stick on a small probe that, so long as it eventually fills up, you're happy.