MisterFister

Without getting too technical, I think it would be fair to add that keeping general tabs on what other mods you have installed would be helpful. In this case, "BoulderCo" is a folder that might already exist from other mods (notably Better Atmospheres and EVE). In which case, make sure to click YES to "merge" and "overwrite" all duplicated subfolders and files.

Already got it implemented into the next version. You can't launch or do anything in the little side window (through the * button) but you can rearrange and view vessel names/times. This is awesome, as I'd intended to ask. Also, I like playing with Final Frontier http://forum.kerbalspaceprogram.com/threads/67246-0-23-5-Final-Frontier-kerbal-individual-merits-0-3-15. For those unfamiliar, it's a per-kerbal achievement tracker, most notably tracking "firsts" (first launch, first orbit, first SOI change, first landing on X / Y / Z, etc.) I noticed today in a relatively new save that the ribbon window (where it tracks the achievements for my kerbonauts) keeps getting reset. I have more troubleshooting to do, as I do have a metric butt-ton of mods active, but the Simulate option from KCT seems like it might be a culprit. Is there any known interactivity issue between these two mods? Related: For StageRecovery, is there any desire to allow the SR module in the VAB to be able to give recovery readouts on a per-stage basis? As it is, I need to use subassemblies and probe cores, else I need to weight different stages' ratings on the fly.

Awesome mod! Quick question, is there a known issue with NovaPunch? My engine exhaust effect works fine on launch and scales correctly with throttle, but when it cuts out the HR effect disappears and is replaced by a vectorless and thrustless stock exhaust. Same thing happened with the stock SRB available at the start of career. Would a screengrab help?

I've been out of commission, KSP-wise, for a few weeks now. Apparently, on August 21, there was a rule change with respect to mod hosting and download links? A lot of forum posts have had their download links manually scrubbed by forum moderators due to compliance issues? Something about an actual real-life law change? Does anyone have any info on this?

Howdy folks! I apologize for asking here what I would assume is a somewhat common question. I'm recovering from a full hard drive wipe and Windows reinstall from scratch. In KSP, this means new savefile, using 0.24.2 for the first time, and cherrypicking the mods that I'll be running with for the next while. (I'm likely going the x64 route, but I'm wondering if it might be a good idea to learn for the first time how to run Linux, as I know that is the only x64 version of KSP that runs stable.) I like the idea of RSS or RSK installs, but aircraft landing gear sinking into the runway and ground textures swallowing my EVA-kerbonauts really bothers me from a visual standpoint. I understand in broad terms that this is actually something that happens in miniscule fashion on a stock install, and realsize-ing the planets simply magnifies it to the point where it's more noticeable. I'm wondering if there's a setting I can modify to reduce or minimize it though, as it would really interfere with my plans to construct bases on Mun and other bodies. Perhaps incorporating references to this issue in this mod's FAQ? Also, I know that the ground often flickers with EVE, but this flicker is somehow more noticeable on RSS / RSK installs. Is this related to my above concern? Thanks in advance!

Hey Matt, are things ok? Haven't seen any posts from you in a while. Your episodes are always awesome, hmu if I can help!

KAS isn't broken for 24.2 necessarily, but it has been semi-confirmed to throw silent errors for x64.

RasterPropMonitor allows glass cockpit designs. You can literally see mapview on your instrument panel in cockpit view.

It should, but the interface can be wonky, especially at extreme range. If you get within a kilometer or so you should be fine.

What are Fscience Transfer and KIDS about?

No one speaks of Scott Manley when discussing this? Specifically on-point: Secondary, somewhat dated, but same theme:

This is not intended as a how-to on setting up satellite networks (for example, comsat constellations for RemoteTech) as that is addressed in countless other threads. This is an explanation of why maintaining those multiple overlapping orbits can become such a headache on older career saves, with satellites falling out of phase with each other and multiple satellites / stations "bunching up" resulting in coverage gaps that might not have been there when you first set them up. Many people are surprised by this, and often, the discussions of how this happens to begin with ends up involving comparisons between GSO (Geostationary Orbit, which refers to real-world space technology [since "geo-" is a word prefix that specifically means Earth, as in the actual planet -- if it's not actually the planet Earth you're talking about, the prefix "geo-" isn't appropriate]) and KSO (KeoSationary Orbit, since "keo-" refers to Kerbin). * First, it's true that real world GSO satellites drift and have to consume fuel for stationkeeping purposes to counteract this over their operational lifetimes. I highly recommend the wikipedia pages for this topic, and I specifically refer you to mentions of "graveyard orbits." Generally, real world orbit perturbations result from myriad underlying causes: including faintly off-kilter insertion calculations to begin with; fuel impurities (resulting in slightly-less-than-optimal thrust vectors, and burn times being minisculely off-mark;) and other n-body outside gravitational influences. Over extended periods for extremely accuracy-sensitive satellites, influences such as the moon's orbit, solar activity, and minute irregularities in Earth's own gravity well can interfere with orbit calculation (resulting from variations in the distribution of mass in the Earth's liquid or semisolid mantle, and unequal distribution of mass means an unequal distribution of gravity, which means that the gravity well is not a perfect sphere to begin with.) Also, there is something called insterstellar and interplanetary drag, such as that from the cumulative slowdown you get from floating through faint dust clouds and debris stemming from Keppler Syndrome; as well as naturally occurring events such as the Leonid; or even the cumulative drag effect of the "solar wind," which is literally the result of being constantly bombarded with countless photons from the sun's light and radiation (photons and other subatomic particles are funny things, but they do have mass, even though that mass is very small -- if you keep getting slammed with them at the speed of light for long enough, they WILL eventually send you off course.) Obviously, since KSP is a game, the Unity engine is not designed to (nor could it ever) faithfully model every single one of those conditions in an n-body-type system, though there have been mentions by people like Scott Manley that people are trying to make it happen anyway. Indeed, in KSO all SOIs (Spheres of [gravitational] Influence) are perfectly spherical, because each planet's mass is perfectly uniformly distributed, resulting in a perfectly spherical and uniform featureless gravity well. For example, there is no such thing as Lagrange points in this game. Further, all fuel in this game is uniformly pure, as another example -- you don't have to worry in KSP about suboptimal burn times due to poor fuel mixtures unless you have a mod that specifically introduces that level of complexity. Despite all of these differences between real world orbital environments and KSP, however, there are three big items that can interfere with orbital maintenance (one is an obvious issue, and there are two others that are perhaps more subtle.) The obvious issue is human input, just as with real world scenarios. In this game, even if you design and plan your maneuver nodes well (which even then is not entirely sufficient for the accuracy we would like, due to the two subtle reasons below) it's still necessary to aim and burn them well, too. Good form, good practice, and good fuel efficiency on maneuver nodes begins with good calculations when designing your craft in the VAB / SPH. Good practice continues beyond the design phase to then include the practice of dividing your total burn time evenly across the node point (for example, a sixty second burn should hypothetically begin exactly 30.00s BEFORE the designated time, and end exactly 30.00s AFTER, though with the fraction of a second it takes to actually go from zero to full throttle, this is never mathematically possible without leaving your throttle maxed and controlling them by toggling the engine on and off at the correct times) and accurately following the blue node indicator on your navball. The blue node indicator is another key item of good orbital planning in this game. especially since it's so impossible to be picture-perfect on the craft-design, maneuver-node design, and maneuver-burn elements -- when you are down to the last few m/s of burn, it's generally a good idea in this game to lower your throttle, puff those final m/s out, and actually follow the drifting node marker on your navball whenever possible, since the location of the marker DOES calculate your new trajectory live by applying any burn imperfections into the original node calculations (and it does so by pretty-accurately recalculating the actual m/s needed to get your final intended course change.) Generally, everything I've said so far makes an immediate sort of sense, when it's laid out clearly here or in other how-to posts on the forum. The two other reasons why KSO** orbits (or any orbital arrangement, for that matter) drift into disarray the way they tend to do are much less obvious, however. First, we can agree that the actual math (advanced three-dimensional conic calculus) that goes into figuring and plotting (and subsequently simulating and rendering) any non-linear path, either through real world space or through KSP space, is highly complex, with numbers that usually have unending decimal places out to 10^(-200) or even further. Simply put, in order to "work," the KSP game engine at some point is forced to say "meh, that's close enough" and stop calculating past the umpteenth decimal place and just fly with that. Those rounding errors, particularly when projected forward over simulated lapses of time acceleration, become significant -- ESPECIALLY in a situation like yours where you probably have multiple satellites involved, and one realizes that you can run the same calculation a hundred times, and round it the "same way" each of those hundred times, and little eensy-teensy math discrepancies become more and more noticeable between iterations of the same satellite, the same launch, the same orbital insertion, but with minute and subtle differences in burn accuracy and launch efficiency, etc. As if all of that wasn't enough, there's also the third fact that when actually coming into and out of time compression, and when OTHER craft in your savefile change SOIs, all of those calculations are reset and recomputed and re-rounded anew, from scratch. As you play your game and progress in your save, whether you simply blast forward at 100,000x time compression for 5 real world days, or you simply place a satcomm network for RemoteTech2 and then go about your merry ways like Scott Manley, this repetitive rounding will compound and worsen all of the above factors that I've described, each time the engine calculates it, which can often be hundreds of times every real world second. (FYI, the fact that it crunches such heavy numbers is the specific reason why this game can become a slideshow with poor framerates when it has to keep track of large and complex craft in close proximity to each other -- when physics load onto a craft or station, it calculates all of this orbital mechanics stuff for each individual part.) So, ultimately, there is nothing that any player of this game could ever do, including savefile editing, that will absolutely eliminate this problem and prevent it from coming back. Savefile editing will, of course, come the "closest" to totally eliminating it, since doing so will eliminate all of the human-introduced elements of uncertainty and even a significant portion of the game-introduced factors and floating point errors that I described above. Ultimately though, just as in real world satellite maintenance, you just have to in some way incorporate this inevitability into the design of your craft and your mission profiles (for example, by periodically re-editing your savefile, or by launching more satellites for your network for extra overlapping coverage, so that when one drifts out of position, it won't IMMEDIATELY result in a blind spot, and by launching those satellites with extra RCS for better fine-tuning over a longer operational life.) I hope this explains a few things, and I invite discussion below. With new input and insight, I'd enjoy editing and maintaining this thread as an educational codpiece for the forums. *Note that other proper-noun celestial bodies have their own prefixes that parallel this linguistic construction, we just don't hear them as often. For example, Mars is named after the mythical figure Ares (yes, like the zodiac sign) so Mars-stationary orbit would be "areostationary" orbit. Jupiter is named after "Jove," the Latin / Roman name for the god originally called Zeus by the Greeks, so Jupiter-stationary orbit would be "jovistationary" orbit, etc. This linguistic construction applies to other terminology, too; we refer to "geography," which literally translated to "Earth-recording," or "land-mapping," which is exactly what it is. On Mars, then, it would be properly referred to as "aerography." For the moon, called Luna, we'd have lunography. **I'll briefly note here that actual synchronicity in any orbital arrangement is totally unnecessary in pretty much any scenario I can think of. Synchronous orbits have the managerial benefits of always being easy to visually identify on the mapview, and the ability to predict where and when coverage blackouts might form, this much is true. And also, of course, synchronous orbits in any case cater very well to the OCD that we all have to some degree large or small. Otherwise, however, the important element in setting up any orbital pattern of multiple satellites is coverage and overlap. The orbital period for KSO in the stock game [day length of 5h59m[XX]s] is an orbital period of the length of a Kerbin day. If you wanted to keep your satellite network at lower altitude, perhaps with an orbital period closer to thirty minutes, then obviously the satellites would not remain stationary with respect to the rotating surface of the planet, but you could still achieve continuously overlapping coverage by simply sending up more copies of the satellite and keeping them properly spaced (which admittedly brings us back to the original point of this post: maintaining the spacing between orbiting objects around the same celestial body.)

I'm just curious, for the OP or anyone else reading: I'm trying to decide between this mod, Kerbal Mechanics at http://forum.kerbalspaceprogram.com/threads/85798, or both. Is my instinct correct, that installing them both at the same time is asking for trouble? As an overlapping-but-separate issue, very early on in that other thread, someone there thinks out loud that these two mods would do well if combined, and that other modder hints that it may be possible (and that these two mod authors might be communicating.) What's going on with that?

Surry dude, but you're wrong. ElectricCharge is a "fluid" resource -- it can be sloshed around between components, and routed in the same was as fuel or any other resource. It's a lot simpler to treat ElectricCharge in a way similar to all other resources than it would be to make two different systems in the code. This is the same reason Kethane refineries actually "draw" negative-amounts of Kethane, which makes for some counterintuitive piping schematics. As someone explained previously in this thread, ModuleAlternator has to have a "repository" that will "accept" the ElectricCharge within the same part.cfg BEFORE it can be routed elsewhere (such as to a battery) as any other resource / fuel overflow would. The opposite also happens -- whenever an engine (or a light) draws a resource, the default fuel routing calls for the resource to be pulled from the most-distant part first (as defined by the .craft file's listing of the daisy chain of parts). This means that resources are drawn across crossfeed-enabled docking nodes, but not across dead-end nodes such as non-crossfeed panels and / or decouplers (even though resources can be manually pumped between them by rightclicks.) Resource GENERATION works the exact same way but in reverse -- it first goes to the NEAREST part, then so on as they fill. If the engine partfile has a ModuleAlternator, the ElectricCharge will be generated, but without a {RESOURCE} parameter, there's a dead end and the logic will "burn" (discard unused) that quantity of ElectricCharge.

You just described the current system. Higher rep, beefier contracts ("goals"). Miss a goal, you get dinged.

Hey folks. I am NOT asking if this mod is 0.24-compliant, because I CAN see by reading through previous pages that it is. My request -- can this please be noted on the front-post at the very top of the thread? Otherwise, thanks for an absolutely fantastic mod!

First, I have to admit I was going to say this too (as did a few others, no doubt) but then I watched the video and saw that this was accounted for in the OP's original troubleshooting attempts captured on video. The fact that it registered as an acceleration on the g-meter AND for purposes of time-acceleration, as well as the truly massive perturbations to your orbital pedigree (large radial changes in perikee and apokee by tens of thousands of meters each) really support the hypothesis that the ghost-forces being applied were parallel to your Center of Thrust, further implicating (but not confirming) that the QS was the problem. Second, I'm glad that the video showing no QS means that your originally reported symptom seems to have been solved. Perhaps post your before / after video links on a QS-centered thread, as it seems like something that might be fixable. (The modder might have incentive to dig for this, given the .24 release.) After seeing the before video, this too would have been a response, and I hark back to a Scott Manley video (I just spent a few minutes looking for the exact one, but he's been way too damn prolific for me to find it) where he combined Infernal Robotics rotatrons with Quantum Struts and, with well-designed action groups, can literally "walk" a pair of rotatrons up an invisible staircase because the Quantum Struts leverages some kind of ghost-of-a-bug in the code to "halt" [my word] movement of parts within the skybox itself. Given how freaky that sounds on a simulated-physics-involved basis, the kind of spontaneous oscillation you described doesn't seem far-fetched to me. Third, had your solution not worked (or alternatively, if you find at some other point that some sort of residue of this issue remains that might not be obvious in your after-video) I'd suggest further tracking it down to see if it may be a problem of competing control wheels or competing probe core problem. Frankly, based on what I've seen with your two videos here, it remains technically possible that the Quantum Struts were actually not the cause of your problem -- since you recorded the after-video with a re-launched, re-designed vehicle, it's possible that you may have inadvertently flipped / eliminated some other subtle cause of the problem. Troubleshooting this may be tedious, and in any event would require you re-simulating your problem under the previous doomed conditions (either by recreating it with the original QS-enabled design from launch again, or restoring from a quicksave.) One thing that I've always done, even on my savefiles where I don't use an Action Groups Editor / Extender (I rotate through a few of them and get infatuated with one from time to time, but nothing really strikes my fancy wholeheartedly, and I have no ability to make my own plugin) I always use universal control groups, so that no matter what docked configuration my monstrosities could ever be in, the control group schemes always match up. For some reason that I can only partially articulate, I always assigned all probe-core / capsule / SAS / reaction wheels to control group 0 (zero) to deactivate them, and 9 to reactivate them all at once. I may have developed this habit when I was running .19 prior to my recent computer hardware upgrades and I was trying to dock large-part-count stations with framerates averaging 2-5 frames / sec. I know you were deactivating SAS and RCS globally on your before-video, but my suggestion allows you to turn them off globally and then manually reactivate single ones in order to observe the effects of ONLY using certain ones, possibly in certain combinations of multiple parts working or off. For troubleshooting purposes, you might wanna consider assigned the Quantum Strut emitters to a control group toggle, possibly combined with different docking orientations (maybe the issue wasn't so much the QS themselves, but the fact that you entered a docked state while the QS were active -- as your craft drifted into maglock range, the QS were blasting empty space, but once the docking node finally engaged and the craft rigidized, THEN they were pressing on those external pods you were trying to reinforce... maybe this caused an initial flex that never resolved structurally, and it was a flight design problem and not a KSP or QS code problem.) On a design level, consider addressing your dynamic flexion problem with KAS struts, or perhaps a three-way docking node setup (lining up docking ports at the ends of your arms to perform the same lateral support function as your QS were designed to.) Hell, even eschewing the end-docks and just putting in girder segments for the modules to rub up against it like pressure points would at least limit the free range of lateral motion you're trying to arrest when the main engine fires. Another possibility is to either assemble in Minmar orbit entirely, or redesign the whole station to allow for convertible assembly (one docked configuration for transfer such as inline or pendulum style, and then disassemble and re-dock / reassemble at destination -- which would likely necessitate adding some form of a small RCS-powered assembly tug for the purposes of performing and managing such reassembly in destination orbit). Ultimately, I can rather confidently speculate as to some benefits of doing it the way you're attempting to, assembling it with outcropping bits in LKO before sending it on a Minmar transfer burn. For one, it's a pretty good proof-mission for an interplanetary run. For two, admittedly, it is simpler your way. And for three, lateral assembly does allow for more possibilities to control CoM and CoT during transfer (more possibilities to skafooz it, too.) At any rate, stay cool dude. Next time in addition to posting a video, perhaps consider offering the .sav and .craft files, because sometimes just a video recording can fail to capture other possible indicators of trouble. (Posting those files, of course, would require a DETAILED list of the mods you run, and we saw in your video that you at least run Quantum Struts and KWRocketry). Some people don't keep track of what mods they run (I keep a spreadsheet, a spreadsheet I might have to upgrade with the x64 options in .24, since one of the primary things my spreadsheet currently tracks is what versions to run -- especially with the SpacePort shutting down and everything migrating recently -- and which I leave inactive in order to keep my memory usage below the magic 3.5gb threshold) and making a list on the fly by someone who's not used to doing so can sometimes be a wasted exercise for both the person disclosing the list as well as the person relying on receiving it so that they can run and test your .sav.

Bear in mind that any command pod or capsule that lands on another body generates boatloads of science if you manage to land and recover it upon return to Kerbin (independent of the science experiments it may contain -- this means that it would be a good idea to design landers with decouplers, allowing you to jettison the ascent stages / landing gear / whatnot and just land / splashdown with the lander cab and perhaps your command capsule docked and have it as light as possible.)

I also run RT2, and I see the same issue. I cannot confirm that it's an interactivity issue, though it would make sense to me that it were. I can however say that, warping aside, if I were to actually launch a readied craft from anywhere outside of the KSC screen, I can launch... and it doesn't seem to deplete my inventory. I think it's possible to spam launches this way. A blind spot in the code? Perhaps a decent temporary solution would be to remove warp and launch buttons from all interfaces except from the KSC main screen. In lieu of that, perhaps arranging for better interactivity with Kerbal Alarm Clock?

Agreed. Though don't go crazy. I suppose the "useful greeble threshold" would at least partially rest on what exactly this part were intended to do. The person asks an interesting question.

I don't recommend eating it. Or letting Jeb anywhere near it.

For the record, I was not meaning to imply that Editor Extensions was causing unexpected behavior with your mod, or that I was doing something that your mod did not expect. I was merely responded to your prior request for me to report to you on how the two mods interact, and I was simply attempting to describe that they do so flawlessly. Editor Extensions allows VAB / SPH seamless switching, which essentially means that a player can use one or the other (with a single consolidated list of subassembly .craft files as well as finished .craft files) while in no way sacrificing use of both launch points. I'd initially wondered in my previous statements (I was accessing the forum from school and was not at my home computer, which meant that I was asking questions here instead of actually installing the mod and trying it out) if Editor Extensions's mechanism of switching between build modes within the same editor building (in my case, I prefer the VAB) would in some way negatively affect how your mod intercepts .craft build orders and forces downtime prior to launch. I can say that the two mods work together brilliantly. This allows me to simply double-order without actually having to back out and move to the SPH. I order a build, then I hit the Tab key, then I design my second order if applicable (such as my subassemblies for future use) and send that second one, and it automatically goes to the proper launch point. Or I can double launch the same rocket (for example, for high- and low-altitude flybys of Mun / Minmus) in consecutive launches, thereby halving build time. Without Editor Extensions, I'd be forced to save a .craft file, order the build, back out of the VAB, alt-tab to my Windows desktop, physically copy the .craft file from my VAB to my SPH, alt-tab back into KSP, enter the SPH, and order the build that way. Here, I use the Tab key once to accomplish literally all of that.

After some rudimentary testing, I can report with reasonable confidence that Editor Extensions (and Action Groups Extended, incidentally) appear to work as intended and present no immediately-visible difficulties for your mod here. When I hit the Tab key to switch between SPH and VAB mode (I remain in the same workspace, it just switches "mode" -- I cannot speak highly enough about this mod, you really do have to try it http://forum.kerbalspaceprogram.com/threads/38768-0-23-5-Editor-Extensions-v1-1-2-Apr-2014-%28EdTools-Editor-Tools-replacement%29) KCT seems to keep up accordingly, and as far as I can tell so far, does properly assign the craft to the appropriate build queue. Oddly, this opens up the possible exploit of using one (for example, the Runway) for making lifters and other vehicles (there is no in-game penalty for launching vertically from launch clamps placed on the runway) whereas the Launchpad can be used to generate assemblies for scrap, payload modules, and the like. Or vice versa, using the Launchpad for launches and the runway for catchup / secondary production work. It is my preliminary opinion right now that this is not a "cheat," or at least is not a cheat enough to warrant any changes to the mod logic as I understand it. I like the idea of having two "shops" actively pumping out hardware, as Cape Canaveral had the capacity to send shuttles up within days of each other as emergency contingency plans post-Columbia-disaster, even though any individual shuttle would need about 15-20 months for turnaround. This meant that a minimum of two shuttles could be conditioned concurrently. Given that I intend to launch multi-science platforms to Munar and Minmar orbit once I advance far enough into the tech tree to get docking nodes and other whatnots, being able to stockpile the actual science payloads now for individual landings later is something I'd care to incorporate into my workflow now. It does occur to me that I could, conceivably, use my "secondary shop" to just spam engines, tanks, docking nodes, and other flotsam in non-flyable configurations, just to scrap them. I could do so with a reasonable chance at efficiency by spamming, say, a hundred docking nodes attached in series from the bottom of a Mk-1 pod, just to have them for future orbital construction projects. I could do the same for solar panels, batteries, life support modules for TAC-LS, fuel lines, and other somesuch obvious high-demand parts. Not sure if that qualifies as cheating, though. I'll have to report back with further experience as I spelunk into my new career save. (I'm running a metric crapton of mods right now, on a KSP Interstellar tech tree, with B9, KW, IR, DREC, and more than a dozen others. I think your mod shines in proportion to the number of mods in play, since it emphasizes streamlines priorities. With a greater selection of parts and a greater breadth of mission parameters and considerations beyond stock such as with FAR-related builds or RT2, spamming scrap parts becomes a riskier proposition -- no guarantee that any one part would be needed in high quantities enough to justify delegating it to spam.) The MechJeb in-flight delta-V displays do seem to be buggy, however. I'll attempt to troubleshoot this.

Magico -- Fantabulous mod! I downloaded from your mediafire and all system appear to be go. lol

Ah. I downloaded from Spaceport, I think. Lemme try it your way. I'll report back soon.