MisterFister

Really enjoying the series thus far, dude! Please, keep 'em comin!

Scott Manley is widely regarded as one of, if not the single, best KSP pilot on YouTube. To be fair, the first of those two links is Part 1, which doesn't address your underlying question of flying and maneuvering, but he does showcase some of the new parts in the VAB and demonstrates the new ion engine stats. Worth a look, but skippable if you're jonesing too hard for the answer to your question.

Gotcha. Understanding has occurred. Nice.

So, in technical terms, "huh?"

Follow up question: From your pictures, I can see you've clip-mounted 6x radial clampotrons. Are you also using stack-aligned clampotron sr.'s? I'd be curious to know if the actual number of mated docking surfaces contributes to the actual amount of sproing you encounter. Though, I'd be confident in assuming that moar is better once you clear the pad, so reducing them to counteract sproing might not be pragmatic.

You mention the sproing issue. It occurs to me that since you're scattering launch clamps along the height of your outer shell (sensible, since you need to support it while physics loads and your docking ports lock) you're launch-rest state is of distributed pockets of structural tension alternating with compression. When the engines light from below (especially if the clamps all release at the same time) you're actually compounding your problem by compressing the sections in tension with the thrust and momentarily taking previously compressed sections held by the clamps and exterting tension with the freefall.* My suggestion is to actually stage-release clamps in sections. Cross-possibilities include having liquid boosters radially attached (liquid so that they can throttle to mitigate release sag) at strategic points corresponding to the clamp release stages; lighting the main stack at low throttle to compress gently from the bottom, possibly in concert with an upward-cascading clamp release setup; strutting directly to the launch clamps pre-ignition. Secondary thought -- with such tall clamps as you would obviously need to survive physics-load, the problem emerges of sliding smoothly enough out of your vertical coccoon of released clamp towers. Possible solution: inward-aimed sepratrons at the clamp heads so as to literally knock the clamp heads outward as they release? Leave a rosette starburst of spent launch clamps at the pad? *Note: It's a peculiar testament to Whackjob's kerballing might that such a sentence could even make sense.

All keyboards have some ability to emulate the numpad keys on the right (even non-English keyboards.) This is most often an issue with laptops due to size considerations, but desktop keyboards can be made without the permanent numpad keys as well. How you go about emulating the numpad keys will vary VERY widely by keyboard manufacturer and the intended market for the keyboard / laptop. Generally, you may note that many of the keys on your non-numpad keyboard have secondary characters in them, often printed in shaded or off-color tones so as to distinguish the keys from the primary QWERTY layout. Often, there is a "secondary function" key somewhere, sometimes labeled "fn" or "{f}", or possibly something in no way similar to that. Worse, maybe the symbol you're looking for has been rubbed off of the key entirely, if it's old enough. At any rate, some careful google-fu will likely tell you how to use numpad key references on a keyboard that has no numpad on the righthand side, but I am absolutely convinced that there is no such thing as a keyboard that is completely incapable of it. And indeed, since use of those secondary function keys often remaps the entire keyboard while the activation key is pressed, this may create for some awkward flying situations in KSP where the remapped key is something you also need access to, like throttle controls or what have you. I know that you can get separate external USB-enabled numpads for very cheap, often for less than $10 over the internet.

TheWinterOwl has a pretty in-depth and entertaining video series on how to design VT/HL shuttles, culminating in a trily brilliant and beautiful design he dubs the Roc. I've downloaded and flown it in .22, and it flies beautifully. I even managed to tweak it (mostly moving fuel around)so that I could runway launch it as well with a payload, and to allow for a payloaded landing (his original design assumes an empty landing, which I can respect.) My own tweaking efforts on his design were of mixed results. He then used his Roc design on a live mission in his Mission Controller video series, with stunningly hilarious results. (Spoiler: The mission fails spectacularly with his shuttle disintegrating into a debris cloud within sight of KSC, but this was due to flight stresses that resulted from a Mach 5 banked turn in atmospheric flight while also running 4x hardware time compression. Without the high speed bank, or alternatively without the time compression unwittingly left on, I am convinced that he'd have made a soft touchdown on the runway with room to spare.)

Big fan of the ROC Shuttle, and also of the Open Cockpit series. Question, I'm trying to run Dynamic Warp on my install, so I can intentionally set time to progress at fractional rates (.25x and lower, in addition to 2x, 3x, etc). My game isn't crashing, but I CANNOT activate anything but the stock time acceleration function. Does anyone know if this is this a .23 problem?

What of your opinion on Kethane / KAS? And speaking of Kethane, I remember months ago the talk about as-yet-unseen career mode being based on resource gathering instead of science gathering. Harvesting radioisotopes from Eve's oceans, jet fuel from Jool's upper stratosphere, etc. The lastest devblogs explicitly renounce this idea. i don't question their right to renounce anything, I'm just disappointed that maybe we couldn't "eventually" get both. Perhaps a planned expansion down the road? KSP 2.0?

Perhaps so, but I think Hodo's point was that maybe if you had ailerons, you could control the uncontrolled roll oscillation. (I'm speaking out my nose here, since I've never experienced your problem, but if Hodo's point was that a lifting surface goes completely without a control surface, then I speculate that shenanigans may result within the game.) My next suggestion is for you to upload the .craft file for us to take a look at. For that to be helpful, we'd need to know more about the mods you've installed beyond just a folder listing in your GameData directory. (Many of those mods that I see are plugin related, and many of those mod writers publish several modpaks that all use the same consolidated folder, so a folder list will not provide a complete idea for a crafttester.)

The main issue causing .23 to hang, from my experience, is the ModuleManager1_5.dll no longer works in .23. I suggest upgrading to ModuleManager1_5_6.dll. Solved the hanging issue for me.

I'm not sure if you're trying to accomplish your project a certain way in terms of folder structure, but what about keeping the endemic "mesh =" format and just renaming the mesh files so they're unique and able to be consolidated in the same folder with no conflicts? I still don't think I'll quite understand why almost all parts, even tock squad parts, ALL use the part.cfg / model.mu filenaming scheme, except to artificially necessitate subfolders. I understand that having subfolders has some advantages, and that artifically necessitating the use of repetitive subfolders is one way to realize such advantages; I just can't imagine that the advantages are so monumental, or so impossible by alternate means. (I recognize that modding is made easier by grouping modpaks into their own folders, I speak only of the enforced need to nest folders and subfolders within each modpak on pretty much a per-part basis.

This works wonders for .craft files that have the same issue -- though the renaming scheme doesn't know how to handle the *.craft filenaming convention, which is easily fixed by renaming the file after conversion.

Here's my version of the same tank you're playing with. Feel free to copy it wholesale, if you like. And FYI, the way you do this is by using the CODE /CODE [in brackets]. PART { // Kerbal Space Program - Part Config // FL-T500 Fuel Tank // --- general parameters --- name = fuelTank_long module = Part author = NovaSilisko // --- asset parameters --- mesh = model.mu scale = 0.1 // --- node definitions --- node_stack_top = 0.0, 15, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -15.1, 0.0, 0.0, 1.0, 0.0 node_attach = 5.01, 0.0, 0.0, 1.0, 0.0, 0.0, 1 // --- editor parameters --- TechRequired = advRocketry entryCost = 4800 cost = 1600 category = Propulsion subcategory = 0 title = FL-T800 Fuel Tank manufacturer = Squad (Jebediah Kerman's Junkyard and Spaceship Parts Co.) description = GameData\Squad\Parts\FuelTank\fuelTank_long\part.cfg. A stretched variant of the FL-T400, the FL-T800 holds twice the fuel in a slightly stronger container. The black stripes along the side make the rocket go faster, our engineers tell us. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,1,0 // --- standard part parameters --- mass = 0.5 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 6 breakingForce = 50 breakingTorque = 50 maxTemp = 2900 RESOURCE { name = LiquidFuel amount = 360 maxAmount = 360 } RESOURCE { name = Oxidizer amount = 440 maxAmount = 440 } } PART { // Kerbal Space Program - Part Config // FL-T500 Fuel Tank // --- general parameters --- name = fuelTank_long_mt module = Part author = NovaSilisko // --- asset parameters --- mesh = model.mu scale = 0.1 // --- node definitions --- node_stack_top = 0.0, 15, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -15.1, 0.0, 0.0, 1.0, 0.0 node_attach = 5.01, 0.0, 0.0, 1.0, 0.0, 0.0, 1 // --- editor parameters --- TechRequired = advRocketry entryCost = 4800 cost = 1600 category = Propulsion subcategory = 0 title = FL-T800 Fuel Tank manufacturer = Selfmod (Squad) description = GameData\Squad\Parts\FuelTank\fuelTank_long\part.cfg. While this tank is indeed empty, we still don't suggest huffing the fumes from within. At least, not where anyone can see you, that is. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,1,0 // --- standard part parameters --- mass = 0.5 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 6 breakingForce = 50 breakingTorque = 50 maxTemp = 2900 RESOURCE { name = LiquidFuel amount = 0 maxAmount = 360 } RESOURCE { name = Oxidizer amount = 0 maxAmount = 440 } }

Oh, and speaking of downloading fresh files -- .23 ships today. If you run the Steam version, the update will happen automatically, and depending on what files get changed, you may lose your modded versions. This is another good reason to backup your files before modding.

First of all, the double-decimal point WILL cause a problem, so I suggest fixing that. At this point, given that I've been in your position before, I suspect that you may want to at least download fresh copies of your files if not installing from them entirely, just so you always have a reference for your modding hijinks. Anyway, I've been on a part-modding binge recently, as I'm trying to find a way to sort my parts in the editor partlists. (I have numerous screens under each tab due to having downloaded several parts-heavy modlists, including B9 and KW.) Why this is important to your issue: I find that it helps to take an existing partfile and adjust the tab alignments so that all the nested arguments are easier to follow. Also, I personally appended the "manufacturer" value so that I could always see, in-game in the VAB / SPH partlist editos, what mod a particular part came from. I modified the "description" value to always indicate the exact folder and filename of any part listed, especially useful since there are some partfiles that come with multiple parts described in them. (Hypothetically it's possible to consolidate ALL parts in the entire game into a single partfile, though this gets complicated and problematic quickly.) What I've done is taken all parts that contain LFO, jetfuel, and monopropellant and self-duplicated them in order to make empty versions. I assemble my payloads with the empty tanks, thereby saving on launch weight, since I launch everything to a fueling station in LKO anyway before they head anywhere. I duplicate those empty tanks into the same .cfg file, and I modify the "manufacturer" to read "Selfmod" so I can prevent accidentally choosing the wrong one while designing a craft. I pasted an example below from the Squad folder. Hopefully, this forum will not truncate it. PART { // Kerbal Space Program - Part Config // FL-T500 Fuel Tank // --- general parameters --- name = fuelTank module = Part author = NovaSilisko // --- asset parameters --- mesh = model.mu scale = 0.1 // --- node definitions --- node_stack_top = 0.0, 7.72552, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -7.3, 0.0, 0.0, 1.0, 0.0 node_attach = 5.01, 0.0, 0.0, 1.0, 0.0, 0.0, 1 // --- editor parameters --- TechRequired = basicRocketry entryCost = 1600 cost = 850 category = Propulsion subcategory = 0 title = FL-T400 Fuel Tank manufacturer = Squad (Jebediah Kerman's Junkyard and Spaceship Parts Co.) description = GameData\Squad\Parts\FuelTank\fuelTank\part.cfg. The FL series was received as a substantial upgrade over previous fuel containers used in the Space Program, generally due to its ability to keep the fuel unexploded more often than not. Fuel tanks are useless if there isn't a Liquid Engine attached under it. They can also be stacked with other fuel tanks to increase the amount of fuel for the engine below. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,1,0 // --- standard part parameters --- mass = 0.25 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 6 breakingForce = 50 breakingTorque = 50 maxTemp = 2900 RESOURCE { name = LiquidFuel amount = 180 maxAmount = 180 } RESOURCE { name = Oxidizer amount = 220 maxAmount = 220 } } PART { // Kerbal Space Program - Part Config // FL-T500 Fuel Tank // --- general parameters --- name = fuelTank_mt module = Part author = NovaSilisko // --- asset parameters --- mesh = model.mu scale = 0.1 // --- node definitions --- node_stack_top = 0.0, 7.72552, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -7.3, 0.0, 0.0, 1.0, 0.0 node_attach = 5.01, 0.0, 0.0, 1.0, 0.0, 0.0, 1 // --- editor parameters --- TechRequired = basicRocketry entryCost = 1600 cost = 850 category = Propulsion subcategory = 0 title = FL-T400 Fuel Tank manufacturer = Selfmod (Squad) description = GameData\Squad\Parts\FuelTank\fuelTank\part.cfg. This is an empty FL-T500. Just remember, if *we* mix it up with the fueled version, it's a "clerical error." If *you* mix it up... *shrug* not so much. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,1,0 // --- standard part parameters --- mass = 0.25 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 6 breakingForce = 50 breakingTorque = 50 maxTemp = 2900 RESOURCE { name = LiquidFuel amount = 0 maxAmount = 180 } RESOURCE { name = Oxidizer amount = 0 maxAmount = 220 } } Hope that helps!

While I do not endorse the unfriendly sarcasm of the above reply, I'd think the multiple decimal points would be your issue. I ran into something perhaps even sillier than your issue recently: I duplicate all of my LFO and RCS tanks, so that I can assemble payloads and launch them without the fuel weight. By sending the empty payload to an orbiting fuel station, I can save on launch weight, thereby achieving greater overall payloads to orbit. (The added benefit is that, once fueled, my payload is 100% fuel capacity, whereas launching fueled payloads generally means using some of its own internal fuel to simply achieve parking orbit to begin with.) Any at rate, in doing so, in one of my recent edits I accidentally entered "-" (hyphen) instead of 0 (zero) for the fuel content. The load screen got to that part file and just hung. Took a few minutes of trial and error to button down the problem. Always backup your files before modding them, sir.

Wow, such a flame comment. FAR generally displays it for you with one of the in-flight readouts. I recommend spending some time on the launchpad actually reading all of the readouts word for word, and clicking on all the ? buttons as they appear. Same in the craft editor. All abbreviations and variable notations are explained and described in accessible terms. While the numbers are indeed different between FAR and stock, I can say from experience on both sides of that divide that in practice, keeping a launch TWR of ~1.8-2 will be fine. In fact, for the most part, with FAR it is quite difficult to attain tV during launch for extended periods, even at full throttle. (The forces needed for sustain upward tV would usually end up g-stressing your craft if you have DeadlyReentry installed.)

If this had been a game-breaking issue, in a pinch you could always re-download the files (whether or not you reinstall) from Squad / Steam.

Everything described here is true and useful, but I think the OP is also asking "why" this happens. First, it's true that realworld GSO satellites drift and have to consume fuel for stationkeeping purposes over their operational lifetimes. I highly recommend the wikipedia pages for this topic, and I specifically refer you to mentions of "graveyard orbits." Generally, realworld orbit perturbations result of myriad underlying causes, including faintly off-kilter calculations to begin with, along with fuel impurities (resulting in slightly-less-than-optimal thurst vectors, resulting in burn times being minisculely off-mark) and 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 (resulting from variations in the distribution of mass in the Earth's liquid or semisolid mantle). Also, there is something called insterstellar and interplanetary drag, such as the cumulative slowdown you get from floating through faint dust clouds and debris stemming from Keppler Syndrome, as well as naturally occuring events such as the leonids. 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. Indeed, in KSO all SOIs are perfectly spherical, because each planet's mass is perfectly uniformly distributed, resulting in a featureless gravity well. For example, there is no such thing as lagrange points in this game. All fuel is uniformly pure, as another example. There is one obvious issue with maintaining accurate KSO paths and two subtle issues. The obvious issue is human input, just as with realworld. If you design 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 amd fuel efficiency on maneuver nodes begins with good calculations in the VAB / SPH, and continue to include dividing the total burn time evenly across the node point (for example, a sixty second burn should hypothetically begin exactly 30.00 seconds BEFORE the designated time, and end exactly 30.00 AFTER, though with the fraction of a second it takes to actually go from zero to full throttle, this is never exactly possible) and accurately following the node indicator on your navball -- when you are down to the last few m/s of burn, it's generally a good idea 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. Generally, everything I've said so far makes an immediate sort of sense, when it's laid out. The two other reasons why KSO orbits drift the way they do are much less obvious, however. First, we can agree that the actual math (advanced conic calculus) that goes into figuring and plotting (and subsequently simulating and rendering) any non-linear path, either through realworld space or through KSP space, is highly complex, with numbers that have unending decimal places. Simply put, in order to "work," the game engine at some point is forced to say "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 time lapses, become significant -- ESPECIALLY in a situation like yours where you 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 discrepancies become more and more noticeable. As if all of that wasn't enough, there's also the fact that when comign 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. As you play your game, whether you simply blast forward at 100,000x time compression for 5 realworld days, or you simply place a satcomm network for RemoteTech2 and then go about your merry ways, 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 realworld second. (FYI, the fact that it crunches such heavy numbers is the specific reason why this game can become a slideshow when it has to keep track of large and complex craft in close proximity to each other.) So, ultimately, there is nothing that any player of this game could ever do, including savefile editing, that will absolutely eliminate this problem. Savefile editing will, of course, come the closest to totally eliminating it, since doing so will eliminate all of the human-introduced and even a significant portion of the game-introduced factors and floating point errors that I described above. Ultimately, just as in realworld 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, so that when one drifts out of position, it won't IMMEDIATELY result in a blind spot in your coverage, and by launching those satellites with extra RCS for better finetuning over a longer operational life.)

I'm knee deep in experimentation with this. Any idea what the category or subcategory variables do? I've decided to be extra thorough with my methodology, since .23 is releasing today. I've backed up all of my mods and my savefiles just to be sure. I'm working with some selfmade macros to do edits of many files en masse, but in order for that to work (for the moment) I need to have all the part.cfg files formatted the same. Some use indents to indicate argument nesting, some do not, some use tab for indents, some use spacing. One mod in particular, ExtraplanetaryLaunchpads, I have no idea what caused it (perhaps the mod was designed on a mac?) the part files were smooshed together with ... "hidden"? carriage returns? Took me hours to untangle that mess. I formalized my previous notions, of embedding the mod origin in the manufacturer variable and the filename and location in the description variable (so that that info would always be visible from the editor partlist in-game.) This will allow two different things. First, I intend to experiment with what you mentioned, the notion of consolidating parts across many folders in a single .cfg file. This info will allow for reversion, typo and asset tracking, etc. Second, I have re-confirmed that part load order determines editor partlist display order. By mixing and shuffling the folders themselves, I hope to be able to influence this. Before doing any of that, though, I want to experiment with those two variables I mentioned at the beginning.

Well, if nothing else, this validates my instincts up until this point. As I type this reply, I am taking a break from manually overhauling my own mod folders. I'd thought to consolidate the .cfg files to one master folder with embedded URLs to the ancilliary infrastructural files that remained in their author-assigned folders, but I'd been put back by the fact that so many files are named simply "parts.cfg". Before experimenting with that rat's nest, I've already begun going through and simply tagging all ~part~.cfg files (because not all of them are named "parts.cfg") by modifying the "manufacturer" values to read the part source. For example, most of the B9 part files list "Tetragon Projects" as the manufacturer in the VAB partlist display, and all of the Squad-released parts have humor-coated manufacturer names, making parts tracking difficult for self-modding purposes. To avoid interfering with the spirit of any mod licenses, however, I retain the author-generated manufacturer tags in parentheses, so it reads "manufacturer = B9 AeroSpace (Tetragon Projects)". Note that not all parts in the B9 modpak even all read "Tetragon Projects," so retaining that info on a per-part basis seems like it would perhaps be useful, but at least keeps true to the creative spirit of the mod developer. Usually right below or near the manufacturer value, there is a "description" value (both being readable from within the VAB). I am currently, as I type this forum reply, in the process of inserting the URL of the .cfg file into the beginning of the value string. So, taking from the first one that I performed the change to (just going through my GameData folders in the order in which they were displayed by Windows) one reads "description = GameData\B9_Aerospace\Parts\Adapter_C125\part.cfg. This product was created as response to [...]". My my estimate I'm perhaps halfway done with this step for the dozen-some-odd parts-containing mods that I run (I'm not counting the handful of plugin-only mods I use, such as EnhancedNavBall). During both of the above processes, I noticed that all of the .cfg files that I'm manipulating include "subcetagory = 0". This tells me that the game itself tracks something called a subcategory, and I have yet to run into a part file that does not have that value at all, or that has it for any value other than zero. My intentions are to complete my manual edits, and to attempt to experiment with subcategory values to see what happens. Given that my modlist takes 5-8 minutes to load, I may consider hiding my mods and working with them one at a time during the experimental phase -- perhaps just B9, since the fact that it is mod-heavy (along with the Squad parts, obviously) I can limit my load time while still benefitting from a healthy petri dish of examples to experiment with. Right away, one problem that I foresee with my efforts is that these manual changes will not track well with new modpaks that I may download / upgrade to as KSP evolves, or the Squad-based parts that may auto-upgrade through Steam. (This was one particularly strong reason I chose to tailor my efforts in such a way that they'd be visible in-game, so that seeing even a single part in the VAB / SPH parts list would reveal if there'd been a change to that part.) This thought had occurred to me, as well. I share your concerns of potential size limit, as well as the further possibility of simply breaking part functions due to poor URL mapping to the ancilliary files that each part may / would need. I'd planned on experimenting with this as well, though the process would likely be very slow. One significant reason for optimism on this idea, though, is that while I was spelunking through my folders, I ran across a .cfg file that belonged to my RemoteTech2 mod. That modpak has perhaps less than a dozen individual parts shipped with it (antennae, since the mod's premise is that you require an active comm uplink with actively relayed line-of-sight signals to KSC or another qualifying manned control craft for an unmannd probe core to be controllable). The mod developer there came up with a shortcut that was sheer genius: [B]@PART[/B][RTShortAntenna1] { [I]various lines of code specific to that part[/I] } @[B]PART[/B][RTLongAntenna2] { [I]various lines of code specific to that part[/I] } @[B]PART[/B][RTLongAntenna3] { [I]etc.[/I] } This proves that, in theory, it is possible to insert information for multiple parts into a centralized .cfg file, even if the affected parts are located in separate subfolders. I agree with you that size limitations may become an issue. This also seems plainly doable. Speaking for myself, as of now, I'd prefer that such duplicated parts be paired, since my only known use for multi-part files is for empty fuel / monoprop tanks, as I described in a previous reply. Now, I admit that my preference to keep them together stems from the fact that with the dogpile that is my parts list, -- keeping the duplicates specifically paired so that the first one has fuel, the second one has none, is one of the only ways to keep track of my modded parts in the chaotic sea of parts that I have right now. I remain open minded to the future possiblity of perhaps wanting to keep my modded parts as a group segregated from my un-modded parts, as long as I can keep them together as a group. This seems very doable. From having peeked at the .txt files that your previous version generated, I know that the process you're describing is something that can easily be appended with // comment tags at the front end of the file as a human-readable as well as sorter-readable boilerplate. That's the rub. To know what is or is not easy to implement would require a few tutorials in how to design, as well as access to the software. About twenty years ago I spent a few months fiddling with a then-current version of VisualBasic, so I basically know enough right now to get myself in trouble. That said, while I like your idea here, I liked what I thought your last version was beginning to try to do. If your app can ask me to type in a few of my own keywords of each part , I can then sort based on keyword. I envision your app being something that is designed to be run externally alongside a windowed instance of KSP. I suspect (hope, really) that Squad will build some of this functionality into future versions anyway.

Interesting. Well, please keep me on a list of people to scream at when your new version comes out. As for multi-part .cfg files, I can understand that. At one point I became enamored with FatNose's empty fuel tanks (I like sending up payloads with empty tanks to save on launch weight, to send up a second fuel tanker with the additional crew afterward.) In my "holy crap I cannot keep all these mods running without crashing" bonanza of August 2013, I decided to cheat and actually modify my own tank .cfg files to accomplish this with duplicate {part} parameters the way I wanted them. Not only did that save my footprint by a whopping 135MB, but the original modpak that gave me the idea didn't even have a full selection of tanks, AND they obviously didn't include empty-modded tanks from other modpaks, AND by doing what I did at least I was able to pair the full with the empty tanks in my partlist display in the VAB. To my knowledge, this is the only example I know of where I use multi-part .cfg files, but from what I've read from you and a few others, I get the feeling that it's an increasingly common practice. (Aside: I feel less smart for having thought of it.) At any rate, I'd presumed that my own multi-part .cfg files wouldn't be an issue, mainly because like you said, part display order at this time is determined by load order -- since consolidated parts like that would likely best be adjacently displayed anyway, I'd thought that loading the master or "first" part would accidentally bring the dupes in along with it, which is what I would want anyway. At this time I cannot say with any certainty that this was the problem I experienced, though it sounds plausible. Would I be wasting my time to continue troubleshooting this current version and report back to you? It sounds like I would. :-\ Which reminds me: I'd be glad to do playtesting for you on my system if that would help you.

Currently running Steam version of KSP (0.22.0.351) With the following mods: Deadly Reentry RemoteTech2 Ferram Aerospace Research Kerbal Attachment system Kethane KWRocketry NovaPunch2 TAC Life Support MechJeb2 And others that are more puglins than part packs (EnhancedNavBall, KerbalAlarmClock, KerbalJointReinforcement,NavyFish's docking port alignment) My question: Generally, have you run into issues with these not accepting your sorting attempts? I'm just in the beginning of my troubleshooting, and I'll provide more detailed info as I discover it, but preliminarily I seem to be getting some... odd behavior. Occasional exception errors crop up, but those do not concern me, as I can click "continue" and work past them. With so many parts, I find it helpful to run KSP in widowed mode and to scroll through the VAB parts list on the right while I add category information in your sorter to the left; my plan is to categorize parts by type first (probe cores, then manned capsules based on seating capacity; tanks, liquid engines, jets, SRBs; RCS, SAS... etc), close KSP, apply first-run sorting changes, then reload KSP and tweak my preferred order of parts within each category. (Too bad that the VAB itself doesn't offer this, but they should.) At any rate, a large part of this is nothing your utility can help solve, because parts like NovaPunch are pissing me off by placing SRBs in the control tab, tanks in the pod tab, etc. Notwithstanding, there are a lot of parts in my VAB display (numerous dozens) that are not even showing within your utility to begin with. Closing KSP, applying the sort changes, and reloading, results in missing parts (using your restore function correctly reverses this.) As a result of those missing parts, I cannot confirm or deny that the subcats I placed are working properly within KSP. Is this a version issue? Thanks!