Diche Bach

@FullMetalMachinist Nice article. Very instructive. I'm fairly "challenged" when it comes to physical sciences, so don't laugh but . . . this one point has me wondering So, humanity has effectively "extracted" some of the energy from Jupiter, Saturn, Uranus, etc., etc. Tiny fractions of the total energy of motion of these planets, but an appreciable quantity (at least from the standpoint of a spacecraft). I wonder if using this effect, it might be possible (distant future of course) to "harvest" energy from celestial bodies?

On my rig this plane has zero fish-tailing. Seagull 104AB on KerbalX Uses a few mods, sorry about that, but only a half dozen . . . The main thing was: I followed the advice of the more knowledgeable forumites who responded to my "Aircraft Design: Need Help" thread (link to it in the KerbalX page). ADDIT: if anyone requests, I'd be willing to redesign it with the modded parts left out and upload a stock version. None of them are essential to flight (just alternative engines/fuel tanks and science gizmos).

Do antenna actually generate heat? I had a look at that article you linked to and . . . well, a fairly quick skim didn't reveal anything about "antenna heat generation." Can you refer to a specific point in the article? Given the article is about a probe that is intended to go as close as possible to the sun, It makes sense that HEAT is a major consideration, but I didn't see where heat FROM the antennae was the issue I am a social/biological scientist so my skepticism is merely a reflection of "innocence" on the topic, not of an informed counter position. I can understand how high amounts of radiation going into and coming out of a chunk of metal/plastic/fiberglass WOULD result in heat generation . . . but I'm impressed if that is ever enough to be of any significance. I also don't know if this tweak the mod allows in the configs (the range stacking for omnis) is in anyway realistic or not, and would be interested to hear anyone who knows more comment on that point.

@FreeThinker: Interstellar contracts sounds cool. How many additional star systems which are compatible with your mods are there available to download now? Only ones I know of are Valentine and Kumar's Dwarves.

@Streetwind & @SpricigoNeat! I hope you guys enjoy teaching what you know about the physics/maths of it. I just might wind up learning something I like to try things seat of the pants and then go back to the technicalities of it. It seems to "gel" better in understanding that way. So how will this turn out to work!? I'm guessing that: 1. There will be portions of the surface of Minmus (on both faces) that will NEVER be in contact (and wouldn't be even it is was completely flat): basically a region around the axis of the ascending/descending nodes? 2. This part is a bit more murky but . . . I'm guessing that: because the orbit is around the center of mass for Minmus, as Minmus rotates and revolves, the orientation of the orbit relative to Kerbin will also shift (probably in a predictable manner?) and the result will be eventual periods where portions of the orbit are "behind" Minmus relative to Kerbin. 3. I would think that, if I were to put a second one of these up there with a virtually identical orbit that was at a right angle relative to this one, that would accomplish more or less the goal? 4. Going back to point #1: there must also be an altitude at which the "blind" strip along the axis of the ascending/descending node is eliminated?

If I want to set up a communications satellite to always be on the far side of minmus (and slightly above/below and/or behind/in-front-of the moon relative to Kerbin . . . the goal here being to provide permanent RemoteTech linkage to anything on the far side of the moon at any given time: I would assume it is as "simple" as: 1. matching Minmus inclination; 2. getting an apoapsis of Kerbin that is positioned in the rough position I want, then 3. burn prograde at that apoapsis in order to match Minmus orbital period and velocity (274.1 m/s) around Kerbin? Which orbital period is it? The wiki provides values for about half-dozen different ones. I'd assume it is the Sidereal orbital period, which is = 1 077 311s or (49 d 5 h 15 m 10.5 s)? Or is this just a bad idea?

There is a config file in which you can disable the plugin's reference to the plugin that checks for compatibility. I cannot remember the details off the top of my head, but I used that to disable those alerts at one point and it might work for your purpose. I gave CKAN a whirl, but decided against using it to install my heavily modded build (like ~60+ mods) for exactly the sort of reasons you describe. Plus, it doesn't seem to always know how to install things properly. Re: the topic of "how high can jettisoned stages be recovered:" Communotron 16 + Launcher Ship I've basically configured that ship so that two lowest stages are consistently recovered. 0 = probe with RCS thrusters (not intended for recovery, but does have a docking port for maintenance/retrieval long term) 2 = orbital completion/encounter booster (enough to achieve orbit at Mun/Minmus or to put into a highly eccentric/inclined Kerbin orbit) Of course neither of the above is recoverable when the ship is used as intended. 4 = upper atmosphere module / suborbital extension --> generally achieves ~75 to 90k plus a bit of prograde burn toward orbital and also (surprisingly given how high it is being jettisoned) is well recovered. 8 = initial SRB boosters + main engine --> generally achieves ~47,000 m and always well recovered (both SRBs and the main engine) I've found that the trick to successfully recovering stage 4 is, when that stage is depleted of fuel, to point the ship RADIAL normal (or very close anyway), turn throttle to 100%, engage stage 3 and then immediately stage 2. The thrust from 2 pushing the debris of stage 4 toward Kerbin seems to change the angle of reentry (and the radiators probably help too) so that it doesn't burn up and the chutes are still "counted" by Stage Recovery as functioning.

Thanks Komodo! I think for now I'll just leave them be and see what transpires in 5 years or so. Lots of other missions to do, but making slightly adjustments to sats might be fun to do in a few years. But thanks for reflecting on the technicalities of it a bit I find the whole thing fascinating and can literally sit and play with the maneuver node thing when I'm getting an encounter with a celestial body and observe what various types of maneuvers do for hours. Last night, I managed to get a Mun explorer probe (basically exact same design as these CommSats [one Comunotron 16; four DTS-M1 dishes] plus a magnetometer and an RPWS antenna) into the necessary orbit to fulfill a mission (after he has been orbiting for 75 days) and I literally just played with the orbit for an hour till he was nearly out of fuel. I find the Flight Computer in this mod, combined with the considerations of range, numbers of targets/numbers of dishes and the planet shadowing effect to be a pretty ideal balance between playability and 'realism.'

oh hell yess, that tutorial is fantastic! Will have to revisit that when I'm not on a: Mun/Minmus mission kick.

I docked this huge ass space ship with this wobbly looking space probe (my first ever attempt at docking mind you). I got those babies SUPER close together and then just figured they'd do their thing and join up . . . they were a bit misaligned mind you, but it seemed within reasonable tolerances. Damn I wish I had a cam program running cause what happened next was amazing. The two objects started waltzing each other! Like the magnets at the dock ports where rotating around one another and "trying" to get perfectly lined up, but the other factors (like their different radial velocities, etc., etal.?) were messing this up so they were spinning against one another! I watched it with awe for about five minutes. Then I remembered something I read in some "how to" thing somewhere and clicked "unset target" on the target probe's docking port: Presto! they merged into one! Only problem was, they merged all clipped and off-kilter and when I hit an RCS thruster or something the whole thing stretched into some godawful looking piece of modern art. The thing then proceeded to rip itself to pieces if memory serves. But I hit escape and when I went back to the new space station, all was well. So while I did vote Yes, there is a kracken, I think it is really more of a "placebo" effect within the game. If the game THINKS that it needs to send all the bits sending every which way, it will, even when it doesn't actually send them flying . . . . or something like that . . .

I have this mod installed (one of ~60) and am slowly progressing through my career campaign to the point where I actually use the stuff in it . . . Couple questions: 1. I notice there have been a couple updates to the mod, but given I'm not really using it yet, I figured I can hold off on updating? 2. Apart from Kumar's Dwarves, and the Valentine system, are there any other solar system mods I might want to eventually install? 3. I notice a great deal of lag in VAB and SPH as my game progresses . . . my inclination is to chock it up to just the sheer number of mods I have installed, but given the performance issues (game starts using enormous quantities of RAM) in certain specific situations (e.g., flight view no problemo, map view no problemo, but VAB and SPH = problemos!) maybe the problem's I'm experiencing are ones that could be mitigated by tweaking else eliminating certain mods. I'll forego posting my mod list here, but thought that-- given the gigantic size of this mod--this general topic might be one that I might get some good guidance on from folks in this thread: basically optimizing a mod permutation that includes this mod, and several others. However, some other thread might be a better place to get into the nitty-gritty on it, so I'll leave it at that for now.

The appendix for the tutorial I followed has this: K1 - K2 = 0.011 ~<10 years to drift out of contact (and I guess the direction should be pretty obvious based on their relative velocities) . . . I'm guessing number 2 is catching up to number one? K2 - K3 = - 0.002 >~10 years for them to drift and presumably the sign means they are drifting in the opposite direction relative to the first and second ones K3 - K4 = - 0.006 K4 - K1 = - 0.003 So it seems that the only one that is "concerning" (if I'm doing this right) is the K1 to K2 comparison. It seems that K1 is just a tad bit "too fast?" . . . but then K1 compared to K4 is "fine" . . . so where is the best place to "fine-tune" in this set? I'd presume that determining the mean value for orbital period for the whole set (well just that final fraction of a second) and then determining which ones to adjust to move one or more of them "toward" that central value? Or . . . do I want to just adjust ALL of them to be slower? (so they are closer to 1 hour 30 min?) How does one do this? I would guess: if you want to slow the orbital period, you burn prograde at peri (just a bit) then circularize at apo

That mod seems to be pretty awesome. I have yet to use it to great effect, but I think it can be (maybe) used to achieve landing on a fairly precise point. The panel it opens up lists all of your waypoints along with their lat/long coordinates. Using this and Kerbal Engineer's "Lat at Impact" and "Long at Impact" and setting up a "reentry" maneuver node, well before you are close to any atmospheric disturbance, may well allow for a fairly accurate landing site to be specified. The two problems I've encountered with it so far: 1. One has to pull the periapsis pretty far back into the negative before KER seems to recognize that there is an "impact" event (else it is a matter of closing then reopening a window or something) and when I first was examining it, I wasn't even sure that those "Lat at impact" values related to a vessel on reentry (thought they might have to do with "impact" experiments mod I have installed). Now that I see that they DO relate to the impact of a reentering ship I may be able to make better use of them. 2. Making adjustments to ones re-entry trajectory in upper atmosphere seems to be completely irrelevant and result in absolutely unpredictable results. I'm guessing that one must set up a good reentry trajectory well in advance (and probably one within a certain fairly narrow margin of angles) and then simply hold bow on retrograde until one gets through the turbulence zone at which point some degree of navigability is restored . . . Probably deserves its one thread on "re-entry dynamics," or else revisiting an existing copy of such a thread . . .

I blame "MK Ultra" You have to ask yourself, if a beautiful, talented start like Britney isn't safe, are any of us?

Past couple days have been very 'productive' KSP wise: Got my RemoteTech Kerbin "medium omni" communications satellite network setup. Got Kerbal Space Station setup Rearview on night side . . . sort of put too much light on the fore and not enough on the aft, eh? Some more views at different angles.

So I followed the tutorial on setting up an Omni-Only Network . . . whooph! That was a challenge! Problem I had was: With number 3 (and 4 to some extent) I'd manipulate the burn to get the apoapsis in the ballpark and at 1947km distant from the previous target . . . do the burn . . . only to realize: YOU SET THE DAMN THING ADJACENT to the previous target! (e.g., setting 3 to be behind 2 and winding up setting 3 AHEAD of 2 and nearly the exact same position as 1! ) . . . but I did eventually get it sorted out. Thankfully I sent them up with plenty of extra dV. I think they all still have like 1500 to 2000 dV of hydrazine in them! Managed to get most of them setup using the last couple hundred dV in the next to last liquid-fueled Vesta engine stage. Here is the design I used

Thanks guys!

I've had my fair share, but the one that sticks in my head is a caving trip to SW Missouri (Perry County) back in the early 1990s. This part of Missouri is extremely karst, meaning most of the hydrology is underground. Longest caves in Missouri are in this county (been so long, memory is a bit fuzzy, and the numbers might have changed . . .) Rimstone River Cave and . . . damn the other one I cannot remember. Both of these are in the 30 miles of total surveyed distance ballpark, and what they consist of is: a dendritic network of downstream phreatic tubs with some vados modification. Far upstream ends either in a surface infeeder or a blockage. Downtream ends in either a blockage or a "sump" (meaning the "roof" of the cave goes below the water level). Essentially this is an "underground river system" (which not all caves are by a long shot) in which the amount of water (and air, the important part) in the cave system is HIGHLY dependent on the amount of water currently in the immediate environs on the surface. To put it simply: these caves are extremely dangerous flood risks, particularly in the smaller infeeder (with the entrance sections especially) passages where the quantity of water coming in at the surface can easily exceed the volume of the passage itself = no air. Base on observations, there are very few if any places in this entire cave system that are always safe from flooding, though in some of the largest downstream trunk sections (the biggest trunks are in the 40 x 30 feet cross-section ballpark), the highest points in the passageway only flood about every decade or less. So, one must be quite attentive to the current situation of the aquifers as well as weather forecasts when visiting these caves: true for pretty much the whole of Perry County, MO (though in many caves, particularly in the Ozarks, flood risk is effectively a complete non-issue). I had driven from Columbia where I was in school and unfortunately the weather forecast was not good. Not terrible but not good. It was drizzling the whole time I was driving. Basically, the risk that the cave(s) would flood was not particularly high, but it was obviously above "safe threshold." My inclination was to get the Perry County locals I was going to meet to head to some destinations that were "zero flood" risk, but the fellow who was leading the trip we had planned (which was a no-go as a result of the precipitation) suggested that we could do a useful trip just inside one of the entrances to Rimstone River cave. This particular entrance is a small sinkhole with small tube that leads about 150ft to a T-intersection with a larger tube that more or less has permanent water flow. The infeeder section is normally dry and flow into it only occurs under exceptionally high aquifer conditions. The larger tube is a near sump to the right and goes as a low airspace stoopwalk/crawl for a hundred feet or so before it too sumps. When this entrance was "discovered" it was no entrance at all, but merely a short cave, which by plotting against the Rimstone river map revealed that it must be the upstream side of the cave system. There is a large gravel bar immediately downstream of the T-part I referred to above, which was simply excavated a bit, which lowered the water level in the pool it was holding (which formed the "sump") and this 'created' the entrance to the cave; quite a handy thing to have. However, this gravel bar tends to progressively block the flow over time, so periodic trips to scoop it out are necessary to keep the entrance passable without diving. So we went in and did some digging and yep, the airspace in the low-crawl "near sump" was nicely increased from 8 or 9 inches to nearly 16" . . . There were some other guys in the group who at least wanted to see the main trunk, but me, I was playing it safe. I headed back to the entrance to check the weather and the other cavers went downstream for quick tour, promising to be back in no more than 45 minutes or so. Back at the entrance I found things had cleared up quite a bit, not quite a sunny day, but no longer drizzling. So I headed back in and proceeded down the belly crawl infeeder to the T-intersection . . . and this is when the OMG moment happened. I got back to the small "chamber" where the entrance belly crawl intersected the tube and peeked both up and downstream . . . yep all looked good. The lowering of the pool was continuing a bit still and the airpsace was even a few inches larger now. Suddenly I started to hear something. My heart froze as the prospect of drowning like a rat in a mudhole leapt into my mind. It started like a whistle, but quickly progressed to more of a howl, and thence on to what I can only describe as "like a train horn" except just constant, i.e., not going on and off like the engineer actually does I raced back to the entrance and was surprised to note no inflowing water as I did, and when I got to the entrance and wriggled my way out, I was even more surprised: even sunnier than it was 10 minutes before and absolutely no sign of precipitation or impending flood disaster. I was of course a bit baffled and clambered back down into the sinkhole . . . yep, that noise was still down there . . . it was coming from somewhere inside!? So cautiously, I decided, well it seems this isn't an existential thread moment so why don't you go see what the hell is making that noise. Back down at the T-intersection, it was now obvious the howling noise (which continued and had done so for some 10 minutes, but did seem to be starting to lower in intensity) was coming from the UPSTREAM section of the T-intersection. The water level in this section had obviously been lowered somewhat too, though not as dramatically as the pool that formed the original sump that blocked the entrance. When I went upstream I found that the sump on the other side had been opened as well, and the noise was a result of the air rushing into the previously water-filled upstream sections that had been "opened" by this higher pool having been lowered! I stooped there in knee-deep water for a few minutes watching the water ripple at the small 4" gap between cave roof and water surface as the air rushed upstream, listening to the howl as it slowly died down and disappared. One of the most amazing things I've ever seen, and not only have I never heard any other cavers report anything similar, but of course . . . by the time my buddies got back it had completely quit and they didn't believe a word of it!

Ah thanks! Will check out MechJeb more closely.

I think the misconception I had above about how anti-normal / normal works was a simple fact that: my burns were taking so long relative to the amount of inclination change I was making that by the time I was "half-way" through my burn, I was already "half-way" to the next AN/DN node, thus, my burn stopped having the intended effect and instead having the opposite effect. My next questions: 1. Is there a mod that makes the application of very small maneuver node changes easier to do? I find the only really tedious and frustrating part of the game at this point is the overly sensitive response to mouse movements when I'm trying to set up a very precise maneuver node. I've seen some mods that sound like they do this mentioned, but I'd be curious to hear what folks suggest. What I would imagine is a mod that allows you to click a hotkey, and open a small interface where you can A. adjust key/mouse input speed and/or B. switch to using keys to adjust a particular node change ( arrow keys or whatever). I have MechJeb, RemoteTech, etc. installed, and I use KER constantly, but at this stage I still prefer to setup my maneuvers manually and build more understanding of the whole thing. I may eventually let MechJeb do a lot of the work for me, but for now manual maneuver node setup and the flight computer in RT for certain situations. Is there a mod that would fit into that niche, just basically change the UI sensitivity for maneuver nodes and not much else? 2. What is "flight planning?" I saw that an upgrade I made to the Tracking Center enabled this, but I have yet to comprehend what that means or if it simply means using maneuver nodes? 3. I find the way the maneuver node displays change when you start changing Spheres of Influence to be a bit strange. I did just manage to do a Minmus flyby at 24,000m periapsis above Minmus (to complete a lucrative tourist mission as well as a nice training mission that bumped my best pilot up to level 3) where I setup the A. Encounter burn from Kerbin orbit (obviously). Then after the encounter "node" was established, I set up; B. the "close fly-by" node, using primarily retro and either radial or anti-radial burn to go from 635km peri of Minmus down to 24km (to get below my 30km threshold to complete the tourist mission); C. I then (while still many hours away) setup a "post-flyby" node to lower my Kerbin peri from 1,800km down to like 42,000m The main part I find strange is: Once I setup A. it seemed I was unable to place any additional maneuver nodes along the teal-colored leg of the trajectory, though I _was_ able to click right at the "Minmus Encounter" point to setup the "B." and also I was able to click on the teal arc between that point and the "Minmus Escape" node, as well as the orange node that showed my trajectory after the flyby and back toward Kerbin. I find gravity-assists (whether braking or accelerating) aero-braking, etc. to be absolutely fascinating and I'd like to really get a solid mastery of how to use the UI to setup exact things, even if it is all setup long in advance. Would be very cool to be able to: Get an unmanned probe into Kerbin orbit, then setup a sequence of three or four "delayed execution" manuever nodes in the RT flight computer that put it into a stable orbit of some other celestial. Is that even possible? I did notice that, referring to the "close flyby node" I setup at 3B above, once I actually got "into" Minmus SOI, and the incoming portion of the arc from Kerbin disappeared, the actual burn that had been setup for this maneuver was a tad bit off and I had to adjust it before I executed it. Can anyone point me to a good resource for this sort of stuff?

Wow, awesome answers Street. That is the clearest description of the basic principles I've ever read!

Decided on a simple zero inclination equatorial with apo at ~249,868 and per at ~249,836. Whenever I'm feeling OCDish I'll use up some more hydrazine and nudge it toward perfect circularity. 240,000 is the min to get the X100 warp speed, and I figure nearly circular has benefits as far as it being a "central node" of sorts. Still only docked in real-time play (and only twice in Kerbal Construction Time "simulation" mode) so the idea of more eccentric seemed appealing from the standpoint of making docking easier, but that is probably a fallacy in my thinking.

*Gazes with envy and wonders "Tutorials, where are these tutorials?"* Ah yes! Small link in the "github intro" page! RemoteTech Tutorials

Awesome!

So I got KSS setup last night . . . just getting my orbit to as close to precisely 0.0 inclination as I can. I brought up a crap ton of monopropellant (must've been a total of ~10k units of it between the first and second modules), but it nearly all gone (using it with those RCS thrusters as I understand RCS is far more efficient, higher IsP or whatever . . .) so I guess I'll have to bring up more if I want to change it's orbit subtantially . . . Question: 1. I had not realized this before but: one can only effectively change the orbital inclination for any given orbit for a small arc of the orbit (well, I "got" that before, but I didn't realize it was as "limiting" as I now see it is). I realize that the "best" most efficient place to burn one way or the other is immediately around the Ascending or Descending Node, but what didn't click is that: beyond some certain angle around that point, one will begin to make the orbit go in the OTHER direction. Moreover, the size of this "effective" arc seems to get smaller as the inclination gets close to zero? I generally have used Lq/O engines for this in the past, so maybe it is something specific to the low acceleration of the RCS thrusters? Any general guidelines, principles there? (short of elaborate mathematical proofs ) 2. I'm a bit perplexed by how "carrying" science works. I've got many modules on this KSS and of course, most of them once you use them in that "area" (altitude, biome or whatever it is) any additional observations become useless. But a couple of them (goo and materials analyzer I think) will "save 1.2 points (but 0% value for the science lab or to transmit it). If I want to "recovery" that science, will I have to send the scientist out to EVA to that module, then put it in the command module that is going back home? (before he returns to his duties analyzing stuff in the science lab for the next year or so). 3. Any modules in stock (or mods) that allow for additional science packets to be cached (obviously each science device itself allows one packet to be stored but is there one that is a "generic" science storage device?). I had sort of expected that some of these modules in DMagic or the other mods I have installed worked this way but it so far has not become obvious how it works. ADDIT: Ah NVM! Looks like Ship Manifest does all this (and probably the science stuff I asked about above) I just didn't see in Blizzy's toolbar but it is on the right side bar. 4. Any simple way to transfer all of a resource from one set of containers to another? I've got about 100 hydrazine spheres on my space station, and the idea occurred to me that the top module (which has now been instrumental in completing two missions) could go on to do other things if I transfer all the monoprop to its tanks. I've got "ship manifest" installed, but not even seeing the GUI icon for it now so not sure what is up . . .