cpast

The equation is "Aerospike vacuum ISP is about equal to aerospike sea-level ISP, so the aerospike thrust is approximately the same in atmo and in vacuum." The whole *point* of an aerospike engine is that its performance doesn't vary that much with pressure.

It's smaller instead of larger, but the KSO station parts have an octagonal KerbalLab with the same functionality, which is ~1.875m.

The more I look at her, the less weird the eye spacing is. I think the model is good as-is, and mostly looked odd because it's new.

RealFuels will cover most resources (though I don't think it has an ElectricCharge replacement), and I think some of the UI is in the Squad directory (rather than in KSP_Data, which is where the actual code of the game goes).

I think there's some form of ROM inside the processor itself, to store microcode for more complicated instructions.

The basic reason is that patents have to be for something new - you can't patent what's already known. When you allow someone to work with their patents publicly and only file later, it means that you can have situations where someone else has built on your work before you file the patent application, which means that your application is pulling something that had been free for all to use out of the public domain and into patent protection. That's particularly problematic if they filed patent applications building on your invention before you filed your application -- the patent office then has to sort through who invented what when, knowing that they can't rely on a patent application's date to establish by when something was invented (the whole idea of first-to-file is based on the notion that the first person to file the patent application must be the inventor, because they knew about it before anyone else). Letting you file after disclosure also goes against the point of patents, which is to promote disclosure -- a patent is an incentive to tell the public how your invention works (you give up your trade secret in return for extensive protection for a term), and there's not really much reason to give you that protection if the public already knows what the invention is.

This is true for modern RAM as well. It's because values are stored in a capacitor with a transistor used to prevent the charge from decaying; as transistors aren't perfect, it has to be refreshed every so often (the refresh rate these days is generally 64ms between refreshes, and is required to be at least that often). That's what the 'D' stands for in SDRAM (which modern RAM is). It's just that modern DIMMs have the refresh handled on the DIMM, so the CPU doesn't have to worry about it (but it does still draw power).

From what the screenshot looks like, that only allows more variety as long as the hair is totally flat and fits on a cylindrical head without sticking up anywhere. If you want hair that's *not* basically close-cropped, you have to model it.

Of the things you list, one (Mechjeb) isn't in the game and isn't going to be, and one (nodes) already *is* something you have to unlock. Of the orbital map, not having it until you unlock it would be the *opposite* of good progression: it means that initially you need to already know orbital mechanics and spreadsheet your rockets in order to get past LKO (actually, you'd basically have to do that to *enter* LKO as well, as you otherwise wouldn't know you were in LKO until you'd finished an orbit and so would end up expending all your fuel and wouldn't be able to land without getting out and pushing, which you can't do right away). Altimeter/barometer is likewise a really odd choice of progression: I guess it could theoretically be used, but when your first contracts ask you to reach a given altitude, it's somewhat cruel to not tell you what altitude that is.

I actually like the eyelashes. They're one of the main things making her look awesome.

I thought that too, and it is why *that* picture looks odd, but we're not looking head-on at her, so I think it might be an effect of the angle (the area between her eyes cuts off the left side of her right eyeball).

IIRC, a KSO launch is around $70k, with around $25k of that being the EFT and boosters (so you pay $25k/launch, but have an additional $50k tied up during the mission).

I think you used autopilot wrong. With Mechjeb, the part you're controlling from needs to face forwards -- if the navbal is all blue when the rover is flat on the ground, it thinks your rover is facing vertically. On a flat surface, the dot in the middle of the navball should be on the line between the blue and brown halves of the navball. Autopilot used to work really badly for me, but once I changed that (and turned off torque, as stability control was being annoying), it works really well (I let it run a rover on Minmus with 10 m/s top speed, and while I checked in from time to time, it never had issues except when it reached and inevitably overshot the destination).

Valgrind is a tool to let you hunt memory leaks (and more generally to track memory usage in your programs); it's used by developers to try to eliminate them.

You can't just send it to orbit and turn it on; it's extremely expensive to get the precision equipment you need into space, and you have to work out how you're going to even measure what you want to measure. Running experiments in space is very much not trivial, and far less flexible than on Earth (as you're limited to what you sent up, instead of being able to fairly easily reconfigure stuff). Validation in orbit is something that's basically only worth doing once you're pretty sure you understand what it'll do (so that you know what measurement equipment is needed). It's a safe bet most "BS" experiments you've heard of (like geckos mating) are actually rather more complicated than reported in the media, and the groups launching them managed to convince funders (or a space agency, which works like convincing funders) that the experiment was worth doing in space and the necessary preparation had been done (so they were pretty sure they'd get good data, instead of the experiment just failing [i.e. failing to produce any decent data, not just not giving the expected result] and needing to be redone). It would not be cheap to test this in orbit; probably significantly more expensive than an ISS experiment.

That's...no. First, calling 64-bit "native" and 32-bit "emulated" is somewhat inaccurate. There are things that the kernel does to provide the same system call interface on amd64 as on x86, but "emulation" implies it actually provides an x86 processor interface itself, which is not true. Likewise, the kernel also has to stand in between 64-bit programs and hardware; the only things that aren't managed by the kernel are kernel-mode things. IA32 on an amd64 system is fairly "native." For a 32-bit OS on a 64-bit processor, there's no emulation at all; the processor is actually running in protected mode, where it is literally running as a 32-bit processor. The CPU isn't more than happy to run a 64-bit program in protected mode. Binary interface has nothing to do with it; the CPU itself won't allow it. Furthermore, there is a pretty good reason to have emulation: you don't want to break applications if you can conceivably avoid it. *nix does exactly that: it doesn't necessarily include it in all copies, but Microsoft made the decision to ship compatibility with all versions of Windows by default. They did the same thing for 16-bit on 32-bit; in cases where it's *not* relevant anymore (e.g. new versions of Windows Server), it's not included by default. The actual *kernel* aspects that manage 32-bit process are, AFAICT, unchanged - they're just part of the kernel. WOW64 is mostly about handling system calls, and has very low overhead; one of the main issues is just having the libraries, but that's not really all that big a problem (most of the libraries on WOW are also the same as on 32-bit versions of windows). From what I can tell, Linux does it exactly the same -- the kernel can handle most 32-bit stuff just fine, it's just libraries that are missing by default. "Emulation is bad" is also utterly irrelevant to your observations, which are that 64-bit stuff can run badly. That's because you can't put 32-bit processes in a 64-bit address space, so things that have lots of proprietary addons won't be recompiled to 64-bit, and 64-bit on Windows requires knowing that an int can't store a pointer (unlike Linux, where it can). But WOW64 works extremely well, and there is no advantage other than saving disk space to not including it. Porting to 64-bit on Windows is somewhat harder on Linux (you can't put pointers in ints), and since WOW64 works so well there's really no reason to bother in most cases. People who think "64-bit is key! That's the only native thing, and the rest is bad 'emulation!'" are just wrong - 64-bit gives zero advantage in most applications, requires annoying conversion work, and 32-bit is perfectly suitable.

I didn't actually know that much about SIMD, actually. To clarify a bit, though: That applies exactly the same to 64-bit and 32-bit stuff, right? I know Unity has SSE2 enabled, so it seems like there's no difference then between what it could do in 64-bit and what it can do now. It also seems like floats' smaller size means it's better for memory-restricted uses (e.g. GPUs, stuff that you want lots of to live in cache). Again, it works the same between 32- and 64-bit. The point's roughly the same, though: Processors can actually have all manner of more complex stuff than just "operate on WORDLENGTH registers addressing WORDLENGTH amount of RAM;" Intel actually made 32-bit processors that could handle 36-bit physical addresses (if the OS supported it), working with the OS to coordinate longer physical addresses (because there's no reason the physical address should be limited to the same size as logical address); they handle high-precision floating-point numbers natively on a separate unit; they can do a round of AES with a 256-bit key on a 128-bit block in hardware; word length matters for many things, but it's best not to assume that it controls everything, because it doesn't.

Er, no. Double-precision floating point is exactly as fast in 32-bit and 64-bit, and any processor with an FPU (aka any processor in the last well over 10 years) will actually natively support doubles at *least* as well as floats. Floating-point arithmetic is not done in general-purpose registers, and Intel FPUs actually use 80-bit values internally (they support doubles *and* floats but execute at 80 bits of precision). GPUs generally don't support double-precision natively in hardware. At no point is 32-bit or 64-bit relevant at all; many GPUs just don't have the circuitry to natively handle doubles, while CPUs push floating-point calculations off to an FPU that operates past double-precision regardless of 32- or 64-bit, and at all levels the relevant factor is the actual circuitry in the hardware (a 32-bit program takes a tiny bit longer to load a double from memory, but that's not really a significant performance factor), and there's no difference in circuitry between 32- and 64-bit. Furthermore, many graphics and physics systems, including Unity, use floats, because GPUs happen to generally work better with floats than doubles, for reasons of hardware.

Hopefully, nothing because they'll fix a bunch of memory leaks. (by the way, should it be "by *no* means very high?" as it is, it looks almost more like you're saying it's now pretty common).

So there's absolutely no reason to be talking about them as "the explanation," and it's actively misleading to refer to it as a preferred explanation. "We don't know what causes this" is better than "Eh, we don't know, so we'll make something up." If the virtual particle theory relies on vague claims that completely misstate the nature of virtual particles (which have very specific properties, and aren't some vague ill-defined concept), then it is not a theory until it gets more precise about what it's talking about (the proper term is "random guess"). Unless it's specific about what is happening with virtual particles and how that interacts with the rest of physics, it is not an explanation (because it's not falsifiable). You don't get to say "virtual particles" if it violates what we know about virtual particles unless you have solid reasons for thinking it's that ("we have nothing better" is not a reason at all), or unless you explain what you're saying is different about virtual particles compared to the way they're treated in physics today. On the other hand, if we don't know what's causing it and our one guess is nowhere near specific enough to be used to explain anything (which it seems like that explanation is), then pushing that as the reason is *worse* than not knowing. You don't have to try to explain everything even if you really don't know. If you have no idea what causes some effect, then admitting that is better than throwing out terms and calling it "better than the alternative." This is not a business. Theories are not competing to be accepted by the general public, and there is no first-mover advantage. Theories stand or fall based on how well they predict experiments and interact with the rest of physics. The rest of physics is pretty well-tested, so any change you propose there has to also explain why we haven't noticed it yet -- note that QM and GR didn't invalidate Newtonian physics at human scales, and you can actually show exactly how the effects are miniscule at human scales and why we hadn't noticed the issues before. Whatever you propose has to do something similar - it needs to show why this happens here, but is negligible in all other situations we've ever tested.

You're confusing incompetent implementations of microtransactions with actual, proper expansions. Expansions aren't exactly new; they've been around around as long as gaming, and have never been some inherently awful thing (in fact, it used to be that you would just about never get new features added for free, you'd always have to pay for significant new features). The fact that something is DLC/expansion doesn't mean it's pay-to-win, or that it's something you really aren't getting a proper game experience without (that doesn't mean a significant number of people don't get the expansion, and there are cases where the expansion is useful enough that game+expansion becomes the standard version of the game, but it means that the game is designed to work perfectly well and then an expansion is added later that happens to contain good additional stuff).

I'd also note that I'm normally about the last person to complain about graphics. The issue I have with KSP's graphics (specifically, terrain) is that it's so bland at the scales I play at as to totally break immersion.

Radiators dump heat with photon drive efficiency (i.e. *not* efficiently). It isn't imparting momentum to particles in the void, it's *creating* particles, which takes the exact same amount of power as a photon drive does for the same thrust, and without a ludicrously impractical radiator moment arm won't be effective at stopping the spin of a spacecraft (if the spin were entirely due to radiation pressure it might be sort of possible, but it's not, so it really isn't). Conservation of energy and of momentum are facets of the same law (conservation of stress-energy), but it's extremely inefficient in terms of power to momentum. The kinetic energy of the rotation is nowhere near enough to stop that rotation without some reaction mass. As for spinning up particles on brake pads: We already tried spinning up something to take the angular momentum. That was our reaction wheel. If you transfer that to the brake pads, the brake pads are now spinning at high speed - they've become a reaction wheel. If our brake pads could take more angular momentum than our reaction wheel, then we should just get rid of the reaction wheel and use the brake pads instead. The angular momentum has to go somewhere. It can't stay inside our craft, because our reaction wheels were the best way we had of having lots of angular momentum inside the craft without it flying apart. Because our reaction wheels are saturated, we have to dump more angular momentum than anywhere else in the craft can take (else that would be our reaction wheel system). I mean, sure the reaction wheel has stopped, but now your brakes are in small pieces that are flying around inside your ship, or your ship is spinning just as fast as it would be if you hadn't had reaction wheels in the first place.

The issue with that is I think the Mk 1 lander is bigger than the Mk 1 capsule.

It being a thing for joysticks isn't enough for the game; you can't assume people have joysticks (you pretty much can assume they have keyboards).