MisterFister

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!

Sorry to pigpile so late in the thread, but I just downloaded 1.2.7 from http://kerbalspaceprogram.com/?p=38721. KSP stops loading when it runs across the GameData\RemoteTech2\Parts\GigaDish1\parts\RTGiga[the rest not visible] and pauses. Note, the flavor text on the load screen (Biding time / pointing correct end toward space / etc) continue to advance, so I don't think this is a freeze or crash issue. Yes, I was able to repeat this issue by deleting the mod, redownloading, re-extracting, and reinstalling. I upgraded from RT1.2.0 (...? I think) and there were no similar KSP loading errors before the switch, though I did decide to upgrade to attempt to nail down some wierd throttle issues, noted to have been addressed in the devlog. I also had problems loading the RT interface textures on the map screen, so I wanted to see if I could replicate that problem with a mroe recent version as well. I also note that the item visible on the load screen refers to GameData\RemoteTech2\Parts\GigaDish1\parts\RTGiga... Under Parts\GigaDish1, there is a parts.cfg file, but no Parts subfolder, and no subfolder in the entire download has any file or folder that begins with "RT". I finally note that a few of the parts.cfg files (such as those in both GigaDish folders) have some wierd formatting issues within the file itself. No carriage returns, all the text and the arguments are smooshed together in a single runon line. I attempted to parse it into separate carriage returns, but that had no apparent effect on my loading issue. Any help?

Ok. So, how would you suggest establishing comms with Jool?

It sounds to me like you have three distinct phases of your operation. Extraction, refinement, and transport. You're trying to combine the first and third in your rover. Why not split those three jobs across three different platforms? Have a rover that's only design strength is extraction, design a separate tanker transport (rover or lander) and design a third refinement platform. You can refine in Munar / Minmar / Kerbal orbit, or on any surface. It can be a static installation, or one with its own propulsion.

You speak of testing its lift capacity at KSC, but this still not telling you what would happen with full K-tank. I've seen someone host a savefile (possibly even a testbed savefile, one used for limited purposes such as this one) wherein they mine a quantity of kethane, and specifically haul it, unrefined back to KSC, just so they can have some unrefined kethane in a tank near the launchpad. Then, using either KAS, quantum fuel transfer, or even a complicated floating transfer boom nearby for those who wish not to use those mods (can't call them mod-purists, since we're talking kethane, which is a mod itself) they can test a design such as yours here, with full or even simulated-full (equivalent weight) in the k-tanks.

Thanks for this, I'll check them out forthwith. Though, to clarify on my OP, I guess I was just noticing that wth all the functions of the node system, there's a lot of fine-tuned input functionality, but I was hoping to fine tune my output. As it stands, I need a much better understanding of orbital mechanics than I already do to be able to work on the input-only side of things (and commensurately, I'd also need much better flying skill than I already have to pull that **** off.)

Incidentally, it's listed in my craft list (inaccessibly, mind you, due to a MechJeb version mismatch) as havign 779 parts. Seven hundred seventy nine. Even my computer would struggle to run that, and I have a pretty high-end machine that can run Crysis at full settings with 16xAA.

Are there any plugins that work with the maneuver node system to display realtime values of projected result orbits? I want to better understand how to work with maneuver nodes, and while the visual dotted lines do help, I'm also a numbers guy. I'd care to know what a projected orbit's inclination, semimajor axis, rotational period, or perhaps even corresponding-ground-location data would be on a new orbit prior to a burn. The existing node system allows me to manually modify input variables on a m/s basis, but it won't tell me anything about the results of my input changes other than visually. For example, which this function, I can imagine that it would be a lot less enticing to use MJ's circularize functions, especially seeing as working with semimajor axis values and rotational periods in mind would very quickly allow me to surpass MJ's abilities entirely. Any suggestions?

Could it be that the obscure numerical notations for rotation and alignment and whatnot are in terms of radians? It would make sense, given the polygonal geometry. ... No, I just plugged it into a calculator. A 90 degree rotation would effectively be half-pi, .8976... ish, nowhere near your number. It is, however, exactly half of 2^.5, so... Sorry.

So, you are running a legacy version of MechJeb. I run v2.0.9. Please remove MechJeb and resubmit.

I have the same mods installed already anyway. I'm in class right now, but will download this later and try to fly it and let you know.

I'd be glad to help you write text descriptions and titles for achievements.