MisterFister

New Question -- I just installed this mod earlier. I tried this on a new career save, and I usually place just a pod on the Launchpad and the runway a few times to do crew reports, EVA reports, goo samples, etc., because "Launchpad" and "Runway" are each separate biomes. ;-) It allows me to warp until ready time when I do so, but doesn't force me -- there appears to be no penalty for ignoring this. Also my TAC LifeSupport spawns drained (zero in all respects) but my kerbonauts do not seem to die. I see no option to "build" or "simulate" launch in the VAB, as the regular launch button works. I do, however, see the KCT readout in the VAB displaying the build time for my vessel. (No toolbar support?) Did I install the mod correctly? I followed the readme file by copying the .dll file directly into my KSP\Plugins folder, not the GameData folder. Was this correct?

Yes, I saw that thread, too. Is that the only mod that enforces downtime for kerbonauts (as distinguished from this mod which enforces downtime for the Launchpad)?

Fine, but my question was subtler than that. The notes here suggest that repeatedly-used parts have diminishing build times (four times launched halves build order, I think is the ratio.) Does that mean if we make lots of modular subassemblies we can exploit this? (I'm installing the mod as I await your reply, I'm just curious.)

How does this mod treat subassemblies? Also, I use Editor Extensions, allowing me to use the Tab key to switch between VAB / SPH mode (radial vs. mirror symmetry, mostly, though it allows me to launch from runway at the VAB and vice versa -- saves me the hassle of moving files around if I want to make a subassembly in the VAB for launch in an SSTO on the runway.) Will this cause any unforeseen issues?

What is this? Is it a mod of some kind? I am intrigued. I did some Google fu. Very nice. http://forum.kerbalspaceprogram.com/threads/59704-WIP-Kerbal-Construction-Time-(Alpha-Version-3)

Lots happened while I was typing and editing that post above. Largely, my point remains unaffected. To your follow-up question -- pay close attention to your MechJeb windows. You can circularize "in X seconds [default 0 = now]", "at periaps," and "at apoaps." Use those left / right scroll buttons, dude. They ALL have a VERY SPECIFIC function.

Again, sir, the picture you posted is of an impact trajectory. You need to FIRST convert it to a flyby by nudging the periaps outward to [theoretically any] altitude BEFORE you circularize. On a more general point, you're revealing what is essentially the heart of the MechJeb Debate. Now, full disclosure, I use MechJeb too. The real space program uses autopilots, the Space Shuttle was only flown manually twice (evidence suggests the third time was an attempt to do so during the Shuttle Columbia disaster, though if so, it was obviously inconsequential and futile) and both known attempts were planned to be limited. One was aborted fourteen seconds prematurely, and the second time almost resulted in the loss of a mission objective. The problem with manual OR autopilot inputs, in KSP or on Earth, is the Oberth Effect and something that I think may be called "arc distances." Essentially, think of it this way: If you're standing at the front of, say, a bus. The two sides of the windshield of the bus are wider apart than your whole armspan. If you go to the rear of the bus, however, you can cover the width of the windshield with your hand with outstretched fingers. The further away you are, the smaller adjustments you have to make to effect a HUGE course correction at the other end. In the game, the Mun, Duna, even Kerbin itself are huge when compared alongside the actual size of the craft you're piloting. But the distance of even a few centimeters in travel direction coming out of an escape burn can literally mean the difference between crashing into the center of your target body such as in your photograph, and conversely being flung outward on a gravity assist, albeit an unintentional gravity assist. Some elementary explanations are in order here. Orbits, you might need to know, are calculated around the CENTER of a planet. That's why you actually have an "orbital velocity" when sitting still on the Launchpad. The surface of Kerbin is rotating around the center of the planet, so technically you are orbiting. You may already realize, however, that the orbit is slower than escape velocity, so gravity takes hold. This is a fair approximation of what is happening here on Earth, too -- as you sit playing KSP, you are literally "orbiting" the center of the earth once every 24 hours. The International Space Station also does so, but at an altitude (above the average-sea-level surface of the planet, not above the atmosphere, and certainly not above the center of the Earth) of ~277km. To get your altitude there in your chair, or the altitude of the space station, above the center of the Earth, you need to take your "indicated altitude" (close to zero for you, ~277,000 meters for the station) and add that number to, literally, the radius of the planet from the center of the core to the surface. When you see impact trajectories like the one you display in that imgur link above, that "escape angle" from the Munar SOI is deceptive, since it "looks" like you're going somewhere afterward. Mathematically, you would, if the entire mass of the Mun were a dimensionless dot in orbit around Kerbin. You'd swing around that center of mass at ostensibly extraordinary speeds, and fling outward in nearly the opposite direction on a parabolic trajectory. So, as far as MechJeb is concerned, you already "have" a periaps. The problem is that the Mun takes up space. It has a radius at its equator of two hundred thousand meters. That means a periaps of 200km from the gravitational center would be a [very high speed and likely crash] landing. In terms of orbital mechanics however, we consider that center-radius of 200km to be "zero." A negative periaps is therefore an impact. An "orbit," as far as we're concerned, of 25km is actually an orbit of 225km above the Munar center. I mentioned the MechJeb Debate. Some people see it as cheaty, and would mock you and me for using it. Others find the game frustrating without it and "need" it. I personally tend to fall into the middle: I use it to give me suggestions, but I modify my maneuver nodes the way I want them (using the PreciseNode plugin, I highly recommend it) and I consider myself capable of burning them myself. Now, since a smidge left or right will sometimes result in missing my intended capture angle, I am willing to let MJ perform the burn for me, as well, but I don't let it go off uncorked; I pay attention to it with my mouse cursor hovering over the "Abort Execute" button. MechJeb, or the autopilot on the Space Shuttle, is a wonderful tool when it is used to augment your flying skill as opposed to replacing it. Think of the game of pool on a billiard table. Show someone a birds-eye-view picture of a set of billiard balls in random arrangements like they do on television and any person can intuitively guess on some of the easier straight-line shots. But ask the average novice to hold the pool cue and actually execute them, that's a different story. You have to work on your aim and your cue-control, and this is the same with golf, or baseball, or hockey, rugby, or either of the two major forms of football. The same here: I can plan my burns well enough, but sometimes, even with fine-controls enabled on my keyboard, and my admittedly huge-*** high resolution monitor, sometimes a single button push to the left or right will be three times what the burn actually needed, and I'm thrown off elsewhere. So, I use MJ to perform those very sensitive burns that are often reported by the maneuver node to be less than 2s in length, or in situations where using PreciseNode tells me that even .01m/s in antiradial burn vectoring will change my capture periaps by more than 20km in altitude. Can you use your mouse or your keyboard to precisely burn .01m/s along a specific antiradial vector? Or change an existing burn plot by exactly .01m/s antiradial? I can't, and that's when I choose to use MJ. I am gathering (and not mocking you for this) that you need MechJeb for more reasons than I do. The question you pose here leads me, and others I'd wager, to believe that you don't quite grasp basic orbital mechanics. And that's fine -- even the people who designed the Apollo program in the 1960s didn't fully understand them at first, either (lots of history to be studied there, if you like learning cool things about what people did yesteryear, I highly recommend reading up on it.) We, as a community of Kerbal Space Program players, weren't born knowing orbital mechanics, and I'm fairly certain that unless a KSP player among us actually happened to go to school for something where orbital mechanics was a thing, or happened to work for some point at JPL (such as the author of http://www.xkcd.com/1356/) chances are we didn't even know much about orbital mechanics before playing this game at all. So, I'm not knocking you for your obvious reliance on MechJeb to tell you what's possible and how to do basic things. That's the great thing about this game -- it appeals to so many even without the mods, but with the mods that audience is increased by what I think is an entire order of magnitude. But I can say that your problem is rather easily solved when it happens, and PREVENTING it is even easier than solving it. I'm not talking down to you, this is the actual answer to your question: the Munar "orbit" pictured in your imgur above is preventable by tweaking your Kerbin transfer burn, likely by less than 1m/s in VERRRRY sensitive and finicky increments along what could end up being divided among all three axes (grade, normal, radial). Alternately, you can perform a correction burn, likely less than 1m/s at a midcourse node as well. Absent that, then you change your periaps to a desired level IMMEDIATELY after transitioning to the Mun SOI, and THEN you circularize at the new periaps. Sorry dude, but there exists no other answer to your question in any form at all. If this answer does not help, then you need assistance understanding the fundamental elements of the answer, but again, there exists no other available answer other than the ones you've been given here. And I do not apologize, because that would be a cop-out and my saying, essentially, "You're on your own dude." I'd be happy to Skype with you and walk you through it, step by step, soup to nuts.

For the record, the term for what you've experienced is "asymmetric high-altitude jet flameout." It's a thing, and must be somehow accounted for in the design stage. One way, mentioned above, is to leave one jet engine along the thrust vector, and shutdown all other outboard jet engines, usually using action groups. (For fancy-pants multi-engine designs, you can shut off engines in pairs from outboard inward toward the center -- and like the suggesting party said above, with every engine shutdown [or flameout, as you've discovered] the same "pool" of IntakeAir becomes re-available to the still-running engines.) Another way to address this is with onboard staging -- you can assign engines to various stages, and there even exists a "stage" action group. (Just because it's a stage-activation doesn't mean you need a decoupler to decouple.) At high altitude, you can switch from jets to [other type of jets, perhaps ramjet, or to] rockets, for an SSTO ascent profile. To better understand the engine behavior, I recommend right clicking one or more of them at low altitude, and pay attention to all the complex-seeming numbers. None of those numbers is "eye candy," they ALL have an extremely specific purpose for being displayed. After a few test runs -- and one of the greatest things about .23.5, in my view, is that you can quicksave in atmosphere, allowing you to replay from the same point repeatedly -- you should be able to anticipate when flameout becomes inevitable just before it actually occurs. Once you can identify it with the readouts, identifying it without the readouts will begin to become easier as well. Eventually, you'll be able to feel it happening just by the engine sound, throttle setting, and navball / altimeter readings. It is once you can do THAT, that "designing around it" becomes the easiest. God I love this game.

I'd be interested to see this .craft file, if you don't mind. I run a similar modset and I've had ghost-staging issues in the past. This may help me tackle other problems, as well.

Not only all of the above suggestions, which I endorse, you're starting your transit from HKO at 600km. You're losing a lot of the benefits of the Oberth Effect by beginning your Kerbin escape from such a high parking altitude (assuming you're not using a mod that alters the size of Kerbin.) Also, according to your OP, you're entering the Eve SOI on an impact trajectory, not on a flyby. MechJeb doesn't work with impact trajectories very well, necessitating breaking up into two separate maneuvers. (Also, this is the first I've heard of the devbuild of MechJeb, but I can assure you that understanding what you're trying to accomoplish -- at least in theoretical terms -- can allow you to methodically work through these problems either manually, or using the official MechJeb release. You'd just need to break the request into smaller pieces, such as here.)

I like this mod, and I'm just beginning to use it now. Two thoughts: First, is there a way to re-hide unneeded windows when they appear in the editor? In clicking through the consoles in order to familiarize myself (I just installed in yesterday) causes screen-clutter regret. Or, at any rate, it's entirely not clear to me how to close these windows, if there's a function already to do so. Second, what about designing a bit of a tutorial, possibly a YouTube video tutorial? I read the OP in this thread, and yes, that gave me some idea as to what each button was called, but it doesn't give me ideas for how to use this mod and leverage its abilities. (I admit that with further updates and features, a tutorial might be a tad premature since it would become obsolete rather quickly. But as it stands right now, I know that I'm only aware of how to use like 5% of what this mod can do, and until I get better at it, it feels kind of bloaty.)

Yeah, for those others following, I've given up. There seem to be too many permutations of the symptoms with this problem, and debugging the savefile is ludicrous, especially since I have a caterpillar chain of more than seven pairs of malfunctioning docking ports.

I'll have to delay my reply to this, since I am just now downloading your latest version and spelunking my way into a new career save (I got blasted by the "docking port won't undock" bug and I got tired of savefile editing when I'd made so many other poor choices to get there anyway.) So I'll provide some feedback after a few missions! (I anticipate that this mod is more useful once knee-deep into the tech tree anyway, which I hadn't even gotten to in my broken savefile.)

Not having the latest ModuleManager installed (or having multiple versions installed at the same time) will cause mod errors that are quite unholy.

Better yet, a slider allowing us to set our own alert threshold -- I for one prefer to suck a biome absolutely dry, but in time-crunch situations where I need to get a launch out on time (for the ARM, or to upgrade a station before life support runs out, etc.) I can imagine wanting to only keep track of the big-bite science missions. ^^This. Please, my fair fellow kerbonaut, take some rep.

Can someone please reexplain the OP here? I totally understand the theory behind it, and the root part tracing that's necessary. My problem is that the OP just throws partIDs around without explaining where he got them, and without explaining the before and after. I totally get tracing the problem with disabling crossfeed and searching for the false flag. (Does it matter that my problem involves a string of no fewer than seven inline pairs of docking ports that won't unmate, including a refusal to unmate from the station entirely?)

How do you embed and clip parts, such as for burying landing gear into the fuselage? Also, when in the SPH, how do you switch between mirror symmetry and radial symmetry without cutting and pasting craft files between the SPH and VAB? Great video out today, sir!

Sorry to reply so late in the thread's lifecycle, but this reply above didn't receive enough attention. Frankly, it's shortsighted in terms of scope -- if the OP were discussing a CoL / CoM imbalance of the size we're discussing, and the plane massed hundreds of tons, dozens of meters wide, five or six meters tall, etc., then this Co[X] discrepancy as a function of overall fuselage length, wing chord length, and the length of distribution of pitch authority surfaces fore and aft... then yes, this would be an insignificant imbalance. But look at the photo in the OP, d00d. He's designing a piloted mosquito for crying out loud -- the margins are razor thin, and the imbalance we're discussing here is ginormous as a proportion to the overall vehicle size. Be nicer next time.

Loving this plugin, nifty idea! I'm tooling around in a new career save, v0.23.5, and I did update the Toolbar after installing. I could run it for a while, but now the toolbar button is unresponsive (the logo changes from green to grey and back as if it were responsive, though...). Alt+F is similarly nojoy. The half of fame savefiles seem to be updating, I just cannot display and gloat over them in-game. Any thoughts? (This problem persists even on a separate virgin-save, and after reinstalling both this mod and Toolbar.) Edit: I see that a few pages ago someone commented on what seem to be the same issues. Something about deleting the toolbar info and perhaps some other file? I'll try it when I get home tonight.

New info: http://forum.kerbalspaceprogram.com/threads/59005-0-23-Release-3-0-Active-Texture-Management-Save-RAM-without-reduction-packs%21 This mod has two settings, and I just finished some experiments with the "aggressive" setting. As far as I can tell, it actively (on the fly, during startup) compresses part textures as they get loaded into memory. The texture reduction packs that I described above are pre-compressed texture models that are already saved to your GameData folders, ready to be loaded. This mod takes the actual "as intended" textures and compresses them all during startup, thereby allowing you to receive the benefit of texture reduction across all parts in all mod folders, and not just those for which texture reduction packs have been made available for separate download. I am apparently able to use this to support running a truly astonishing array of mods without hitting the same 4GB ceiling you are running into. I highly recommend it. Edited to add: Note that this mod loads first before all other mods if installed correctly, and it does "appear" to hang while loading, perhaps even for a minute or two. In fact, during one trial run, the KSP loader even showed under Windows Task Manager as unresponsive, though doing nothing still allowed it to finish loading with nary an error. As far as I can tell, this is normal. I recommend exercising some extra patience when attempting to start KSP after installing this mod, and it should be fine.

What about going the noob route? Can something silly like Windows Task Manager tell me this info reliably? I see some Processes and whatnots that seem to be KSP-related, but are the numbers shown relative to the question I'm asking?

I respectfully hope that someone can make more constructive use of that info than I can. I intuit, however, that it was helpful information and I gather that it is indeed possible to develop a user-friendlier method of deriving the answer to my question, possibly with an external widget of some sort. (My programming familiarity ended with BASIC twenty years ago, and my only modding familiarity with KSP is reading the [part].cfg files. This is something I hadn't realized, though upon your explanation it makes sense. Generally, however, my motivation for asking me original question was load-failure-type crashes, where KSP simply refuses to launch to title screen at all. Your statement imparts to me a back-of-the-mind need to always factor a healthy margin when using plugins. Inspecting the code, however, is well beyond my ken, and beyond that of most end-users, I'd wager. To the unifying theme of both of your replies above that speak of textures; I'm aware that graphics and modeling textures tend to be highly compressible, but not uniformly so -- this means that the size of the asset files within the GameData folders may or may not correlate to the memory consumptive footprint of a mod. This is especially the case with regarding WIP mods that have yet to implement "aggressive memory optimizations" as you describe.

To clarify, I am already aware that smaller plugin-type mods generally tend to have less footprint impact than a part-heavy mod such as B9 / KW / NovaPunch, and that part-centered mods tend to scale in footprint in loose proportion to the amount of parts contained therein. Still, I was kind of hoping that there's a way to look either on a per-mod basis, or even a per-part basis, as to how much memory is being allotted. (Per-part allotment would allow me to experiment with cutting individual parts or entire sections / categories of parts from specific modpaks. For example, procedural wings tend to render most pre-fab wing parts (generally over-represented in any given modpak to begin with) almost or completely obsolete. I already feel comfortable reading the user-parsable [part].cfg files, such that I have a general feel for parts that are longer or shorter... but those file contents, to my admittedly vague understanding, constitute a paltry sum in comparison to the "rest" of the part asset, particularly the model and texture meshes. This is why, for example, texture reduction modpaks (mod-of-a-mod) bear so much fruit when implemented. What I want to know, however, is if the size of the mesh files is directly correlated to memory footprint. Do memory-hungry part assets always derive from modfiles that take up more file space? Is this a linear relationship, exponential, logarithmic, or an uncorrelated random relationship? While I would be very surprised, based on what I know of the broad outlines of how computer programs work in general, if I could track these on a per-file or per-asset basis, I would at least like to know if I can macro-snapshot the footprint usage. To explain by analogy, sometimes at the vet's office a dog won't sit still on a scale long enough to be weighed. Therefore, you use a human handler to stand on the scale, holding the pet, and then you weigh that handler with no pet in his or her hands, so you can deduct the weight of the human from the combined total to derive the weight of the dog; I can run sterile-KSP, get a snapshot of footprint size, install my first mod, get a snapshot, and the difference is then an approximation of the footprint size of that mod. As long as I uninstall that first mod, sterilize my KSP install, and then install any additional modpak individually, I should be able to always deduct the size of my sterile footprint to calculate the approximate footprint size of any given mod. I should like to emphasize here that I'm convinced that something along these lines has to exist already. With the texture reduction packs (Squad, B9, KW, and NovaPunch being the ones I browse past repeatedly and often on SpacePort) advertise average memory reductions in the real of XXXMB, often several hundred megabytes each. So someone already did what I'm asking about -- they ran a non-reduced install, took something like my snapshot idea, and then reduced it, to derive what benefit the reduction yielded. I guess I'm asking how that information was obtained, so I can turn around and experiment on my own. (For example, I might find interconnective patterns. Perhaps Mod1 might have a footprint difference of 100MB, Mod2 of 55MB, but running Mod1 and Mod2 together would mean a footprint size of 135MB above the size of sterile KSP -- or even 160MB. I'd care to identify and troubleshoot those differences, as I'm convinced that such mod conflicts (or benefits) have to occur somewhere at least occasionally.

This is a common problem. KSP, for now, is supported by Squad primarily in Unity-32bit. 32-bit programs in general (not just Unity or Unity-based programs like KSP) have a hard ceiling of not being able to use more than 4GB of RAM, in total, at any given time. This is even if your system has many times that amount of RAM available for the entire system. Unity does have a 64-bit version that does not have this particular issue (more to the point, its hard ceiling is way way higher, I think 2TB but don't quote me) but up until very recently, Unity-64bit was extremely buggy in Windows due mostly to "politics" and shenanigans behind the scenes at the company that designs and maintains the Unity engine. A few months ago in early 2014, Unity's developer unveiled a new 64-bit version that shows a lot of promise for improving upon the poor track record it has had to this point, but we'll see. At any rate, Squad had back-burnered 64-bit development for KSP a while ago pending improvement in the Unity-64bit engine, which may or may not be upon us. Even if Unity-64bit's limitations are indeed completely addressed by the recent improvements, given what's publicly known of Squad's priorities list for KSP, even then we'd prolly have to wait a good year or so (my personal guess is final sales version of the game) before large-scale 64-bit implementation is seen. It should be noted that Unity-64bit has been MUCH less buggy in non-Windows environments, particularly Linux. I don't use Linux or Apple, however, so I cannot report on this. (Also, to run any 64-bit program, whether a game or an internet browser, one's operating system has to also support 64-bit processing. Many "starter" versions of Windows and other economy-class laptops and desktops eschew 64-bit operating systems in order to justify a lower price point, so if you're running a 32-bit system, the improvements to Unity-64bit would pass you by anyway.) As for wrapping the above computer-history lesson back to your question: I, too, run into the same problem you describe of not being able to run all of the mods I want to run at the same time. The sterile-KSP base-footprint is already sizeable on its own, and each new mod a user installs expands that footprint size upward bit by bit until, eventually, you hit the 4GB ceiling and Unity-32bit collapses, causing fatal runtime errors. Frankly, it's a testament to Windows at all that such crashes don't tend to cause bluescreen hanging instances except for rarely. At any rate, comparatively speaking, small plugin-type mods tend to sip memory, as most memory usage is in loading meshes and texture models for individual game parts (tanks, engines, SAS modules, etc.) Therefore, during startup, the part-heavy modpaks such as B9 / KW / NovaPunch tend to eat through memory like it's going out of style -- hence, modmakers have made available "texture reduction packs" (a mod-of-a-mod, if you will) which reduce the resolution at which the meshes and textures are loaded (making them appear blurrier in the game) thereby compressing the memory space that those mods would otherwise consume. Try those reduction packs first. For the record, I dislike the fact that they would even be necessary, since much of my own enjoyment of the game comes from the attention-to-detail items such as greebles and "Warning: Don't Touch This"-type markings on the parts that really lend to the fun satire-but-serious-rocket-science atmosphere of the game. I cannot believe that I would speak for no one else on this point. Anyway, if those reduction paks don't solve your problem by themselves, the only thing I can suggest at that point is to go through your mods, one by one, and delete / uninstall / disable them one by one in the reverse-order of how important you think they are to your mission ideas. After uninstalling each least-important mod, re-attempt to run KSP, and until that solves the problem, repeat the process on up the chain until you get KSP to work. (Sucks, I know.) If it helps, I just posted a thread asking my own question in the same field of concern, any answer to which may be helpful to you here. http://forum.kerbalspaceprogram.com/threads/76549-Any-way-to-track-how-mch-memory-each-mod-consumes?p=1091151#post1091151 *Disclaimer* -- All of the above advice presumes the likelihood that there are no other latent "conflict" errors preventing your KSP install from running. If there is a conflict preventing your KSP install from starting up that has nothing to do with the 4GB ceiling issue, that would require separate troubleshooting.

I'm a non-purist when it comes to KSP, and I constantly run into the 4GB ceiling for installing and running mods. It's difficult to know how much of that problem is generated by any given mod install. When troubleshooting, I have no problem simply uninstalling mods one by one in reverse-order of how important I think they are to what I want to accomplish in my savefiles. However, I have to do this blindly, since I have no way of prioritizing them based on actual memory footprint. Something tells me that at least sometimes it might be possible to uninstall one mod to solve my problem rather than pulling three smaller mods to accomplish the same goal. Is there a way to monitor or log memory footprint size on a per-mod basis? Or even a per-install basis (I'd take a baseline sterile install, then install one mod at a time, running the utility after each one, to generate a holistic view)? I run Windows 8.1 and Windows 7 on two different machines, and this seems like good info to know. I can use the log files to generally pinpoint "where" in the startup the memory crash occurs, but I cannot identify how culpable any one mod might be. Yes, I know I can run texture reduction packs. I'm not asking how to REDUCE memory consumption, I'm asking how to TRACK it. Any thoughts?