RKunze

You are literally breathing that nitrogen source :-)

The computer you read this on can probably do it in a grossly inefficient, interpreted language running within a space simulation game. For examples, see all those working kOS scripts out there that manage accurate boost back and landing...

If you mean the Novel by Arthur C. Clarke, make sure to also watch the movie. One of the best SF films ever (Clarke actually worked on both the novel and the movie script in parallel). And if you like classical SF, I can highly recommend The Fountains of Paradise, also by Clarke.

Because it has been "shivering" in the same direction (outwards) for as long as we can observe - which means for the last dozen billion years or so (thanks to the finite speed of light, we actually can look back in time). And there is absolutely no indication that this trend will stop (in fact, it seems to be speeding up).

What exactly do you mean with "tipping over"? Does the rocket go out of control and tumbles? or Does the tip of the rocket follow the (surface-)prograde marker, but that marker keeps falling down leading to an eventual crash? My guess would be 2, because 1 usually means your rocket is aerodynamically unstable, and your design looks OK in that regard (I'd have used a fairing for the payload, but you should probably be able to get to orbit without if you don't go too fast in atmosphere). If it is 2, then your rocket is actually following the ideal trajectory, a "gravity turn". The only problem is that you start that turn by tipping over too far. From the image, my guess is that your rocket has an initial TWR of well below 2 (which is actually realistic, real launch vehicles usually have a starting TWR of 1.2 to 1.5), which means you need to tip over just a very tiny bit (no more than 2° off vertical, usually less, but that depends on a lot of factors) after the launch, and then just leave the rocket alone. My usual launch procedure is: launch straight up until the rocket is clear of the launch tower and fast enough to be aerodynamically stable (for my designs, 20-30 m/s is usually fast enough) tip over very slightly (somewhere between 1° or 2° off vertical, depending on the rocket - as I use kOS to automate my launches, that's actually handled by a script, and the code that calculates how much to tip over is the most complicated bit of that launch script by far) keep the rocket pointing prograde (if your rocket is aerodynamically stable, this just means keep your hands off the controls, it will follow prograde automatically) If you reach apoapsis too soon, retry with a smaller initial tipover.

It's the type wheel from a type wheel printer. And I'm actually old enough to have used that kind of printer. And its close cousin, the type tape printer, which was much faster because it could print multiple types on a line at the same time. And much louder - especially if you fed it finely crafted input that caused it to fire all the types on the line at the same time (and no, the university compute center sysadmins where definitely not amused when we did that).

Should be around 2. Principles are well understood, engineering does not need any obvious unobtainium, but nobody built one yet. Could have something to do with the fact that its exhaust is the same kind of highly radioactive fission products that are carefully not let out of containment in terrestrial fission reactors

But the two sequels ("Fuzzy Sapiens" and"Fuzzies and other people") have never been published as an eBook - at least as far as I know. If I'm mistaken, please point me to a source - as @Vanamonde said, the sequels are almost impossible to get even on paper, let alone as eBook. I'd dearly love to read them. As for the original "Little Fuzzy", you don't have to go to Amazon. Copyright for that one lapsed, and it is available from Project Gutenberg at https://www.gutenberg.org/ebooks/18137 Edit: @Gargamel is the fellow Little Fuzzy fan - sorry for the mistaken ping...

In vacuum, at almost lightspeed. But where neutrons are generated deep within the sun is anything but vacuum, and most of those neutrons are considerable slower than c.

Small wonder. Neutrons are generated deep within the star, in the middle of a dense plasma. Which means they are either absorbed quickly by some other atom, or deflected often enough to decay while still deep within the star. Heck, the interior of a star is so dense that even the photons generated in the fusion zone don't normally get outside the star. They basically just heat up the plasma, and the photons we see from a star are generated at the "surface" (or more correctly, the "photosphere", because a ball of hot plasma does not really have a surface) of the star. That's why a stars' spectrum is very close to an ideal black body spectrum, which in turn means you can directly tell the stars' "surface" temperature from its spectrum.

Nope. Most fusion reactions (including those occurring in stars) also put out plenty of neutrons. And some events (supernovae and neutron star mergers) put out huge quantities of neutrons (if they did not, most heavy elements would not exist). The reason that there are almost no neutrons in cosmic radiation around earth is that free neutrons decay in about 10 minutes and thus don't reach us.

If you don’t mind that you lose the relative timestamps, you could pre-parse the page on scraping, strip out "data-short", replace the "16 hours ago" text with a formatted version of "datetime" (eg. "July 17 2024 21:59 UTC") and feed that edited version to the deduplication code. That should give you identical hashes even for new pages, and won't lose any relevant info for archiving.

Hmm. How do you get the power from the wire to the pantograph in this case? At the voltages involved, I'm pretty sure an electric arc will work technically (or rather, will be pretty much unavoidable), but I’m equally sure having a constant arc with enough current to drive a train will be quite hard on both the wire and the pantograph. Probably harder than having the pantograph scrape along the wire...

If the only problem left is patching the labels to show the correct resource, how about changing the labels with a standard MM patch to something generic like "extraction rate", "start harvesting" and "stop harvesting" and just leave them alone in the part switch config? Edit: Forget that, I didn't read your description correctly. As a wild guess for why patching the labels may fail: Could that be some interaction with the i18n system?

Because you need way more energy to go from aluminium ore to aluminium metal than to go from iron ore to steel. That is why Iceland's second most important export (after fish) is aluminium, even though both the ore needs to be shipped in and the finished product needs to be shipped out. But Iceland has lots of cheap electricity to run the smelters.

Sort the federated hosts into "stable" (is up with the same IP longer than a reasonable DNS TTL for the domain name) and "unstable" (everything else), have the stable ones play redirectors for the unstable ones (as well as serving their own share of contents) and put A/AAAA records for the m (1<=m<=n, choose to fit your redundancy needs) most stable ones under the main domain name into DNS (should give you also a bit of load balancing on the DNS level, since multiple A/AAAA records for the same name are usually used in round-robin fashion by clients). Can even be automated if you have a DNS provider that allows zone transfers (or zone updates over some other API), and you don't even need to worry about changing the DNS glue (just put the DNS providers' servers as glue into the parent zone and update those from a subset of the federated servers acting as "hidden primaries"). Been there, done that, works pretty good.

That will just clog up your (now smaller) filters faster....

No. At the point where the (hot) exhaust enters the tanks, everything ist gaseous. The water and CO2 freeze out when the exhaust gas mixes with the (very cold) LOX in the tank.

Should be no problem. Simply require Principia :-)

Errm - no. Actually, facts are those pesky things that stubbornly refuse to vanish when you stop believing in them...

It does (both run in each engine tick and handle each part on every tick). And though it does approximate (can't actually do anything else, both because the problem usually does not habe an exact analytical solution and even if there is, floating point math has limited resolution anyway), that is not really the problem. The problem is that the solver iterates: It starts with something that is (hopefully) already close to a solution and then does a couple of refinement steps until it reaches the solution (actually, an approximation that is close enough to the solution). This works very well if the starting point already is close to the solution - for example, if the starting point is the solution from the previous engine tick, and the solver just needs to catch up some 100 milliseconds or so. But on a "cold start" of the solver, the starting point is usually very far from a solution, and the solver needs to run quite a bit longer until it finds a solution ("converges on a solution" is the technical term you usually read in papers). Or worst case, the solver does not find a solution at all in this situation - that's called "the solution diverges" or "does not converge" in scientific papers, and "Kraken attack" in KSP.

Well, it is the first ever solar powered probe that operates in the Jupiter system, and getting enough energy from solar panels that far out is quite an achievement. All other craft visiting Jupiter so far were powered by RTGs.

In KSP1, it's called "Final Frontier". That mod is even mentioned here on the first page of the thread, as the inspiration for Wayfarers Wings...

If you are referring to the "metal scar" mentioned by @JoeSchmuckatelli then the star in question is a white dwarf and not a neutron star. White dwarfs are dense, but still formed of "normal" (at least compared to the stuff neutron stars are made of) matter. If you were posing a new question: According to most models, neutron stars have a thin crust of more or less "normal" matter (nuclei and electrons), with the nuclei getting gradually more neutron rich with increasing depth (and pressure), until the pressure gets high enough to force all of the electrons into protons. And maybe the inner core of large neutrons stars may be composed of even more exotic matter than that.

Ah, I see - thanks for explaining. Just tried it out, and the "clean slate" now forces me to explicitly enter all the other necessary fields (author, license, download and so on). And since all those optional mods are actually part of JNSQ and included in the JNSQ zip, they share all of these fields with JNSQ and I'd need to duplicate all of it. So, I think I'll go back to the "crufty" version for $kref to automatically fill in the whole JNSQ info and just manually overwrite the parts that not applicable to the optional mods (should mainly boil down to including an empty "provides")... Edit: Seems to work fine with editing just the relations. Will open a NetKAN PR for the optional JNSQ rescale mods now.