Starman4308

How to use the PB-NUK: Step 1: Put it on the rover Step 2: Enjoy 0.75 EC/sec per RTG forever. In the real world, RTGs decay over time, in large part because your radioisotope, usually Pu-238, has a half-life (~90 years for Pu-238), but KSP doesn't model RTG decay. There may also be decay of the thermoelectric elements, but there's no getting around the radioisotope decay. Step 3: Try not to smash your RTG into a cliff wall. Overall, for gameplay, the RTG is very expensive, and has a poor electricity production-to-mass ratio, but that electrical supply is completely independent of sunlight. As such, they're popular for night-time operations, and operations out near Jool and Eeloo, where solar panels diminish to near-uselessness because of how far from Kerbol you are. If you're into mods, Near Future adds some full-up fission reactors, which provide electrical output (per kilogram) on par with solar panels, but require cooling, and they do use up enriched uranium.

A, it'll probably get kicked to the computer megabuying thread: B, a 1050 Ti will not adequately drive a 4K monitor for AAA titles. You're probably looking at somewhere between a 1070 and 1080 Ti if that's what you want to do. It'd probably do fine for games with minimal graphical demands (such as KSP without visual mods), but the 1050 Ti is not a 4K gaming card, not even remotely. It's not even a top-flight 1080p card. C, keep the 4790K. CPU technology is not advancing nearly so fast as GPU technology; while the GTX 1070 I bought this year blows the GTX 970 out of the water, the i7-7700 has only a thin, ~10-20% margin over the i7-4790*. A Haswell i7 is still a very effective CPU today, particularly if you're running mostly non-threaded and poorly threaded programs (like KSP). For that matter, if you overclock the i7-4790K, it will almost certainly run faster than a non-overclockable i7-7700. *According to cpu.userbenchmark.com. The exact amount is up for debate, but in general, advances in CPU technology slowed to an absolute crawl once we hit the heat wall and ILP wall. Overall, I would strongly recommend replacing the PSU, shelling out for a GTX 1080 (or AMD equivalent) card*, and keeping that still-very-usable i7-4790K for the foreseeable future. EDIT: And keep the mobo, unless you have some strong disagreement with it. Generally speaking, the important part of a mobo is that it works, although it can help to have a good mobo if you plan to overclock anything. *Assuming you want to run AAA titles at 4K resolution at close to max graphics. If you have your sights set lower, you can drop down significantly from that $500+ price point.

1) It appears resolved in the 1.5.8 pre-release. Quick question: is all the other stuff in the 1.5.7 release .zip (example missions, etc) still good, or did that get moved into the 1.5.8 .exe file? 2) Will investigate further; there is a very non-zero chance of this being a PEBKAC from a novice user. 3) I demand a refund. 1) Provided above 2) I'm aware of what SMA is. It was a truly impressive chain of illogic that lead me to plotting subterranean ejections from Gael. First: in circular orbits, SMA == apoapsis and periapsis. Second, 800 km (at 3.2x scale) would be subterranean, so clearly you're referring to the in-game convention of apoapsis/periapsis above the surface Third, 800 km above the surface is ridiculously over-conservative Fourth, enter in a more reasonable 150 km and profit Logic! EDIT: Also, to make sure it's completely clear, I'm being sarcastic about the refund thing. Thanks bunches for creating and maintaining this tool; I look forwards to doing some real mission planning instead of "stuff it full of propellant and go".

Alrighty, two logs. This one comes from a run that works perfectly well, and probably has superfluous information because I was actively using KSPTOT. https://www.dropbox.com/s/4dhkfkxbypwskxa/ksptot-preFailure.log?dl=0 This one comes from when it fails to start: https://www.dropbox.com/s/mnjtfek126i4cie/ksptot-fails.log?dl=0 I shall continue to, on my own, debug such PEBKAC bugs as starting transfers from subterranean orbits...

It's almost like it's 2014 again and we're all building giant asparagus pancakes. Really, I prefer my mom's buttermilk pancakes, but to each his own. In practice: most of my current rovers have been sent under a painfully oversized fairing with a skycrane, with the rover parallel to the ground, although my next big one is probably going to be perpendicular and come down under a detachable parachute/ballute system.

I know Procedural Parts has a procedural thrust plate with multiple bottom nodes, and SpaceY has a good series of adapters. Also, I think Ven's Stock Part Revamp eliminates a lot of the tankbutt that makes clustering needlessly difficult. In terms of stock: yeah, mostly just abuse the Cubic Octagonal Strut for all its worth.

Nope; I just double-click on the executable from a file explorer window. As a side note: I was wondering why A, KSPTOT used such a large default SMA of 800 km, and B, why all my Gael ejection burns required so much delta-V. Palms have recently been applied to faces as I have realized I have started every single Gael departure plan from over a thousand kilometers beneath its surface*. I swear, one day, I shall actually get the hang of this tool. *On reflection, I suppose I should have realized that, while you can sort-of describe apses relative to the surface, SMA makes no sense whatsoever unless defined from the center of the body in question. I swear I'm usually smarter than this. This new run is vastly more reasonable; I got a Gael-Tellumo-Otho-Gauss-Grannus grand tour for just 3.301 km/sec of delta-V, using just 5 optimizer runs.

So, I'm getting a bug trying to load KSPTOT v1.5.7 (Windows 10, Core i5-6600K that I should really get around to overclocking someday). On program start, it pops up an error message, saying this: Reference to non-existent field ". Error in => projectMain.m at line 49 The problem disappears if I delete appOptions.ini, which has these contents: [ksptot] bodiesinifile = C:\path\to\KSPTOT\Gal32.ini rtsHostName = localhost timeSystem = Earth Of course, this means I have to delete appOptions.ini each time I load KSPTOT. Otherwise, though: it's a wonderful tool that I'll have to learn how to use a bit better. I think I mostly have the hang of the multi-flyby sequencer*, and have found a Gael-Niven-Icarus path that saves a couple hundred m/sec off a direct Gael-Icarus transfer. Granted, that's not much relative to the overall >17 km/sec cost of getting there and circularizing at 3.2x scale, but it's entirely plausible to me that's mostly on account of astrodynamics being utterly unforgiving, particularly when going inwards instead of outwards. *One thing I'm trying to get the hang of is setting appropriate min/max time bounds. Empirically, I think the time bounds are in 6-hour days (despite setting it to use Earth time), and one could use Hohmann transfer times as a loose guide for how much time to set, but I can still get some wonky results. EDIT: Also, is there a way to plug in a programmed set of "try these flybys and see if anything works"? I know fully unconstrained flyby optimization is basically "do you have a supercomputer?" territory, but I might want to, say, have KSPTOT grind through a dozen or so ideas overnight or while I'm at work, stuff like "try Gael-Tellumo-Gauss, Gael-Gael-Gauss, Gael-Niven-Gauss, Gael-Otho-Gauss, Gael-Tellumo-Otho-Gauss, Gael-Tellumo-Gael-Gauss, Gael-Gael-Tellumo-Gauss".

Not all that much. Ran my second Icarus flyby (the third will probably be the terminal flyby on account of it being a pain to set up, and not much more science to be gained). This one was once again at 14 km/sec relative velocity, with a periapsis of 9 km, skimming probably ~1-2 km from terrain at the lowest point. I should've F5-F9'd to check; I was too busy grabbing this screenshot: Such a close flyby was risky, but necessary for screenshots bragging rights science. I also finished design of my Iota/Ceti ground station. With TAC LS installed, I equipped it with: Over a ton of food, water, and oxygen, enough for almost 180 days EDIT: 180 days with the planned crew of 4. A Sabatier reactor and water purifier to further extend life support (will probably bring a hydrate-mining module to make food the only necessary input) All sorts of KIS/KAS goodies 4 Gigantor panels 2.4 tons of capacitors 22.1 tons of batteries The enormous battery capacity is there because of the 15-day Ceti night. I'm not sure how realistic nuclear reactors would be, less because of the power output, and more on account of the radiation shielding that would be necessary. if anybody has some real-world info on what it would take to shield a ground base from the radiation produced by a small nuclear reactor, I'd appreciate it, as I'm striving for some realism in that regard.

You could probably run a lot of KSPTOT processes in the background, though. For those who are less computer literate, the OP links to a rather spectacular 18-core CPU. Unfortunately, while KSP can kind of use extra cores, it's still stuck doing a lot on the main CPU thread. The usual framerate killer for high-end PCs is just running rigid-body dynamics on high parts-count vehicles. While multi-threaded implementations of rigid-body dynamics exist, they might not have the same degree of fidelity as the more established single-threaded solvers, and they certainly aren't implemented in Unity, the game engine on which KSP runs. As such, the 18-core monster is no better than an i5, because, at least at equal clock rates, they have the exact same single-thread throughput*. *Unless you get cache issues, in which case the i9's enormous cache could help. I doubt it's a huge issue for KSP, though, not unless you have a real monster of a vessel.

Wait, did you mean to say the Space Shuttle didn't make a Hohmann transfer followed by 150 m/sec velocity-matching burn 5 meters from clipping the solar panels, followed by just jamming into the nearest docking port any which way? The real world is truly strange. They still have claws in case you forgot the right-sized docking port, right?

I don't know why that in the general case, but in the specific case of TRAPPIST: don't red dwarfs emit primarily in infrared? You'd probably get the best signal in the longer wavelengths.

Somehow, I just don't think anybody expected anything else of you. Though, that does raise the point that even with RCS, infinite ignitions, absurdly deep throttling, hilariously silly magnetic attraction, and grossly overpowered reaction wheels, docking is still one of the hardest tricks for new players to master. I once tried doing the final approach at real-world (< 10 cm/sec) velocities. Even for me, that was painful. I thoroughly respect your patience.

Ooh, mafia style. I like how you make that C&D sound. Dangerous. Exciting. Like something straight out of Grand Theft Auto. I may be a tad frustrated with yet another kneejerk anti-big-business reaction garnering far too much support from people who know far too little about the situation, and those who make mountains out of molehills. Okay, I totally get what you're saying, but I have one very important question. What's a shark card? Yes, you could go complain on your blog. You have a right to free speech. You don't, however, have the right to speech on somebody else's platform. Steam reviews have a specific purpose, and reviews complaining solely about business practices are not that purpose. You are not entitled to GTA mods. You are not entitled to abuse Steam reviews to complain about topics unrelated to the quality of the video game in question.

Version 1.3 is out of beta, which is why KSP was updated on you. To downgrade to 1.2.2, follow these instructions To avoid problems like this in the future, copy the KSP folder (under Steam/steamapps/common), and then play KSP from the copy. That way, Steam doesn't auto-update the copy, and you always have a pristine installation of the latest version if you want to try it.

Two small additions to Snark's post: #1: You also have equatorial ascending/descending nodes, which mark where your orbit crosses over the equator of the body you are orbiting. Don't confuse those with the ascending/descending nodes of your orbit relative to a target orbit. #2: It's most efficient to change planes at the node closest to apoapsis: this is because you are going slower at apoapsis. For sufficiently large plane changes (of about 85 degrees), this effect becomes so pronounced that a bi-elliptic transfer is the most efficient way to make a plane change. For a bi-elliptic, you burn prograde at one node (preferably the lower-altitude node) until you are almost at escape velocity. Then, you can make a plane change near apoapsis, and then burn retrograde at periapsis to bring your altitude back down again, and you can overall spend less delta-V with this maneuver. Again, it's only for very large plane changes of ~85 degrees or more that bi-elliptic tends to beat "just make the plane change wherever".

Time to catch up some more on the backlog. Also to confess that I've downloaded KSPTOT, I love it, and I have no idea how to actually use it well. Daphne: The Second Tellumo Lander To investigate the oceans of Tellumo, a second lander was conceived. While not hugely more complex than the original Tellukhod, Daphne required a substantially larger propulsion unit to allow for a precise, targeted landing. After splashdown, Daphne made a number of important measurements, and discovered, among other things, that its seas have a high degree of salinity, helping explain their continued existence as liquid water instead of ice, that dissolved oxygen levels (at least locally) were below the Gael mean value, and that these seas are home to very curious, very large, very hungry predators. Our astronauts have recently expressed preference for a continental vs. sea landing on Tellumo, should we mount a manned mission to this world. CLOSE-I: The Sungrazer CLOSE-I is the only CLOSE-program probe that has not and will not orbit its destination, due to the high velocities on approach. At exit, CLOSE-I set a speed record for Gael escape, reaching a peak of 8.4 km/sec relative to Gael, so as to cancel a great deal of Gael's velocity around Ciro. At Icarus, CLOSE-I had a very brief window for data collection, as the relative velocity was in excess of 14 km/sec. In the all-too-brief pass over Icarus, CLOSE-I revealed a highly varied terrain, one worthy of closer study... if, at least, we can deal with the tremendous insertion delta-V. In the meantime, CLOSE-I has over a kilometer per second of delta-V remaining, allowing subsequent flybys to be arranged. CLOSE-E: Estimated Time to Eta. The first orbiter intended for a moon outside of Gael, CLOSE-E launched aboard an Ike-C During its eight-minute, 3.6 km/sec insertion burn, CLOSE-E's sensors detected overheating of the propulsion module, forcing heavy throttling down, such that when the burn completed, CLOSE-E was on an escape trajectory. Fortunately for Mission Control, that was a relatively gentle escape trajectory with a close flyby of the destination, Eta, allowing a small correction and gentle Eta insertion burn. Ballute Development Project Daphne, while not enduring the 30G descent of Tellukhod, nevertheless hit a peak of 15G during Tellumo entry, an acceleration considered too fast for delicate instruments and Kerbals. One of the proposals was to use ballutes for extra drag in upper atmosphere. Tests from low Gael orbit have been a success, and ballutes are planned for use in future missions to Tellumo and possibly other worlds. Project LTHab: Lunar long-Term Habitation As a stepping stone to further destinations, enormous orbital and surface installations are being planned for Iota and Ceti. To loft the core module, the Ike-E booster was devised, with a 5m stack and 75 tonne payload capacity to Gael escape. The first stage is powered with a 6-tonne Emu and two 2-tonne Mainsail liquid fuel engines, as well as two 100-tonne solid rocket boosters The second stage is a modification to the typical Ike upper stage. Instead of nine Poodle hydrolox engines, the Ike-E uses a stretched tank and replaces the central Poodle with another Mainsail, which is ejected after the additional thrust is no longer needed. The station cores themselves feature a habitation module with theoretical capacity for sixteen, plus a laboratory, cupola, life support supplies for a year, and a Sabatier reactor and water purification plant to extend endurance in orbit. While initial operations will likely be supplied straight from Gael, later operations may harvest water from Iota and Ceti themselves, requiring only food and spare parts from Gael. The second module to be added to the LTHab stations was the ELSIE Extended Life Support and ISRU Extensions module. Not quite as heavy as the first, core module, the ELSIE modules are connected to the 5m docking port at the bottom of the core module. This module supports ISRU operations to convert hydrates into usable propellant and provides backup Sabatier and water purification plants. Note: while it may seem like the core station's attitude thrusters are firing, it is simply a bug optical illusion. Miscellaneous Updates CLOSE-G completed its primary mission to map Gratian from orbit To replace the abandoned Thalia relay, I sent up a replacement, after removing the upper two sub-relays from the standard design. Lots of extra delta-V when your payload is reduced by almost 2/3.

Personally, I'd blame the combination of EULA and business model. With GTA V, TT/Rockstar were aiming for an online game that encouraged microtransactions, and OpenIV had the misfortune of being between TT and money. That probably wasn't the case with XCOM, and probably will not be the case with KSP. Alternately, what we could do is get Take Two executives hooked alternately on Realism Overhaul, Roverdude's mods, KSP Interstellar, etc...

CLOSE-I flew by Icarus. There was a panicked moment where I realized I was timewarping straight past the low-orbital space. Then I realized, no, I wasn't timewarping, I was just approaching Icarus at 14 kilometers per second. Fortunately, I appear to be in something resembling a resonant 95-day orbit with Icarus, and the probe still has ~1 km/sec of delta-V to arrange later flybys. Not enough to capture into Icarus orbit, but I can do some radar mapping just with repeated flybys. I also realized that if you're not careful, Thalia can and will melt your engines even if you have radiators; the last minute of an 8-minute Thalia capture burn became more like 3 minutes once I realized my engine was about to melt. The steering losses were bad enough that I didn't actually fully capture into Thalia orbit; fortunately my destination was Eta, and I wound up getting an intercept from the capture burn, so I could just finish it off at Eta.

So, so very evil for enforcing that mods don't use a library that helps crack into protected content. It's not like they're the IP owners or anything; who are they to say how GTA V can or can't be used? A large, experienced group of fellow developers to help polish up the game and produce DLC? I think you underestimate how much work it is to take a mod and turn it into commercial-quality code. It's not nearly so simple as "fork Github repo, profit". This not-terribly-important thread is exactly where it should be: in the forum for things not KSP related, such as GTA V modding.

Truly stable orbits are impossible even with ridiculous precision and overpowered jet engines. The only way to maneuver in space without a rocket is via gravity assists, and that necessarily requires that you end in an orbit crossing that of what you used for the gravity assist... meaning you'll encounter that body again at some point, meaning either your orbit will change, or you'll never re-enter orbit of the original body because of a terminal lithobreaking event. Landing on atmospheric bodies is a maybe, but requires absurd precision... and overpowered jet engines.

I could turn that around on you. Don't blindly accept the claims of the OpenIV team either. As mentioned by Kerbart, the issue isn't solely that the GTA code was copied using a legal dodge that is very difficult to prove, it's that the mod itself violated EULA by permitting access to locked content. Don't be one of those people whose kneejerk reaction is to think "the big evil company is at fault, of course they're going after the little guy!" That is a one-way ticket to being "sheeple", just for a different set of greedy liars. In general, my primary disagreement is this: who gave you or the OpenIV team the right to decide what could and couldn't happen with the GTA software? Who said Take Two had to take the time to go after every little EULA violator instead of going after the EULA-breaking tool that enabled such? Who said they had to permit mods at all in their software?

To eliminate a bit of confusion: recent posts by @klgraham1013 and @TheRagingIrishman were in response to somebody creating another "Take Two DOOOOOOOM" thread, that got merged into this one. I would like to reiterate: Take Two is DOOOOM. They are staffed solely by creatures who desire the end of all fun, and will step upon all Squad has created simply to reap their tears, making all KSP content heavily DRMed microtransactions, retroactively forcing updated EULAs on KSP players and shutting down any mod that might make the game fun. Uninstall KSP now, that this future may not come to pass for you. Alternately, Take Two's actions are being taken badly out of context by people who immediately leap to the worst possible interpretation of corporate actions, and don't for a moment stop to consider things like "hey, maybe Take Two had every right, legal and ethical to take down a mod that enabled cracking into protected content".

As a heads-up: unless you guys really want me to, I'm not going to put as much effort into recording exact dates; it's a distraction from what I want to do: play the game and write about it. CLOSE-T Mission Completion: Scorched, Blasted, and Beautiful The CLOSE-T probe completed its primary mission of surveying Thalia, giving our scientists important information about Thalia's origins. One hemisphere is dominated by the Face Scar, which appears to be ground zero for a tremendous collision, throwing enormous amounts of material around the impact site. Supporting the impactor hypothesis: Thalia has no surface water deposits, not even in the deepest, most shaded polar craters, suggesting that Thalia's poles were not always at the same spot. Thalia's moon Eta is thought to possibly be formed from the impact, although a more careful study will be required. Thalia is even hotter than would be expected from its distance to Ciro, suggesting a relatively recent influx of energy. Also, I really wish I knew the slightest thing about what I was talking about, and could spin a convincing science story. Alas, I'm a biochemist, not a doctor physicist. Long Range lunar Roving Project: LRRP One issue with all our prior landings has been a lack of mobility: immobile unmanned landers, and manned missions limited to walking speed and EVA endurance. As responsible scientists, there is only one way to address this problem. The LRRP project used a skycrane to place unmanned, solar-powered rovers on Iota and Ceti. Equipped with laser ablators, thermometers, accelerometers, and numerous other scientific instruments, these rovers have gone many places that the one-site landers have not, sharing pictures of our beautiful moons along the way. These investments have been treated responsible at all times, with risky maneuvers and joyriding banned. For example, observe this photograph of a rover which is definitely heading in the same direction as it is oriented and not screaming towards a boulder at nearly 50 m/sec with just one bounce to avoid destruction. Numerous landmarks have been visited by these rovers, such as the site of the first landing on Iota: A curious rock formation: And these str... Hold on, there are technical difficulties, please hold... And these perfectly normal vistas of Iota and Ceti The Gael Space Center would like to remind everybody that giant space monkeys need not be invoked to explain the perfectly natural origin of our universe. oh god who put these things here? That's clearly writing for Kerb's sake. Who was here before us? Thank you all for your continued support of exploring our universe and the beautiful Gael system.

I dunno; getting to the Mum is an important part of any Apollo mission. Mums tend to get rather upset when that doesn't happen. Also, for illumination, you might try Ambient Light Adjustment, which kills a little bit of realism, but makes screenshots in the dark much brighter. I've also learned to slap a lot of spotlights onto my space stations, and possibly other vehicles I might use for docking. Finally, nice job. You might try submitting it to the Apollo Style Redux challenge if it'd score well.