[Win][0.23] Kerbal Orderly Parts - Dec 27 - New Version Available

[MisterFister]

The utility is sorely in need of an update, as it's got a number of problems that are known to me. When KSP .20 came (I think), it became unable to handle multiple parts defined in a single .cfg file (the utility still assumes there is only one part per folder and per part.cfg file, so only identifies the first defined part in the file if it finds any at all), which many mods are now utilizing to share textures between parts and consolidate things. This is what I think is causing parts not to show up for you.

Since I am rebuilding this app from the ground up, I don't plan on bugfixing this version (Sorry ), but expect to see a better one some time after .23 comes out.

[Edit] Also, (if the feature hasn't broken at some point), you can use the utility to move parts from one category to another by dragging the part to the category button at the top you want to move it to. I always consolidate my RCS tanks into control, and air-breathing engines to Aerodynamics myself.

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.

[JumpsterG]

Yeah, this version is pretty much getting scrapped for a new one. I don't have a build of the new one available yet as I'm still ironing out the new design on paper at the moment. The second something is actually usable (or I need a feature tested), I'll throw something up here.

So it doesn't look like I've done NOTHING, let me post some of the design changes I'm playing with:

-Replacing model/mesh references in .cfgs with URLs to the appropriate files. This is really important because this is what allows the next 2 points:

-During the reorder action, only move the .cfgs to a special folder within Gamedata. This maintains the original Gamedata folder structure (easier to revert changes) and allows plugins that save or load data to/from specific folder locations, to not be affected by the tool. (I've also considered cramming ALL parts into one GIANT .cfg, but that sounds scary, harder to revert, and I'm not sure if there's a limit (KSP/Unity/OS) to the size of a .cfg!)

-Splitting out multi-part .cfgs into separate .cfg files (one-per-part). This allows them to be sorted individually.

-Storing sort data within the .cfgs themselves in a special comment section. This is instead of using additional sorting files the old utility put in the same folder with them. Information on reverting changes, like original settings and file location, are immediately recognizable if a player needs to fix a problem and, no matter where the .cfg has been moved to, both the player and the utility will know where it came from and what to do with it.

Designing the interface is the hard part... I want to do away with the click and drag functionality, due to flaky windows form behavior. My current concept is a simple listbox, where a selected part (or subcategory) in the list can have it's order adjusted by clicking "move up" and "move down" buttons. This is logical and WAY less prone to errors and strangeness but it irks me because you won't be able to quickly eyeball where you want it and stick it there. Any suggestion on effective and easy-to-implement UI design will be appreciated.

[MisterFister]

-Replacing model/mesh references in .cfgs with URLs to the appropriate files. This is really important because this is what allows the next 2 points:

-During the reorder action, only move the .cfgs to a special folder within Gamedata. This maintains the original Gamedata folder structure (easier to revert changes) and allows plugins that save or load data to/from specific folder locations, to not be affected by the tool.

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.)

(I've also considered cramming ALL parts into one GIANT .cfg, but that sounds scary, harder to revert, and I'm not sure if there's a limit (KSP/Unity/OS) to the size of a .cfg!)

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.

-Splitting out multi-part .cfgs into separate .cfg files (one-per-part). This allows them to be sorted individually.

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.

-Storing sort data within the .cfgs themselves in a special comment section. This is instead of using additional sorting files the old utility put in the same folder with them. Information on reverting changes, like original settings and file location, are immediately recognizable if a player needs to fix a problem and, no matter where the .cfg has been moved to, both the player and the utility will know where it came from and what to do with it.

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.

Designing the interface is the hard part... I want to do away with the click and drag functionality, due to flaky windows form behavior. My current concept is a simple listbox, where a selected part (or subcategory) in the list can have it's order adjusted by clicking "move up" and "move down" buttons. This is logical and WAY less prone to errors and strangeness but it irks me because you won't be able to quickly eyeball where you want it and stick it there. Any suggestion on effective and easy-to-implement UI design will be appreciated.

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.

[JumpsterG]

I think when I encounter .CFGs with multiple parts, they will logically be placed one next to the other at first. Perhaps it would be logical to automatically generate a subcategory when they are encountered so they are grouped by default? Not sure what the auto-assigned name for the subcat would be, maybe pulled from the first viewed "manufacturer" variable...

Anyway, here's an example of what I'm playing with for the new management window:

This is non-functional at the moment, but shows the general layout that I'm shooting for.

The whitespace on the left is a table that will list parts within the selected category alongside their order number, title, description, mass, etc. This box will take up more of the screen by default, as the white space on the right (Labeled .CFG View) is intended to be collapsed to the right when not being used and all buttons would shift appropriately.

The autosort listbox at the top would have sorts based on statistics like full/dry mass, thrust, etc that would apply automatically to all parts in the currently viewed subcategory or to all parts if no subcategory is being viewed (allows subcategories to be sorted via different criteria).

Any part or subcategory shown in the table can be selected and the buttons in the middle used to change it's order. Each part can optionally be assigned to a subcategory.

The buttons at the bottom are common tasks I have either done myself to .cfgs or heard of other people doing either by hand, or by using ModuleManager. They make direct changes to the Part{} segment that are saved to file. Ideally, these will switch from "Add" to "Remove" if the selected part currently has the module in question.

The white space on the right would fill with that part's Part{} segment and allow you to directly edit it and save the changes just as if you were in notepad.

I am obviously not yet a GUI programmer . But this is a great learning experience. In the future, I hope to steer away from Visual Basic controls and start learning best practices for GUI design so that I can pull off the more intuitive interfaces like the Click-and-drag icons.

At this time, I am working on the part discovery routines and how sorting information is stored and read. I've decided, the best way to proceed is to have the utility remove the Part{} segments from all Gamedata .CFGs, replaced with a tag like "//KOPSortedPart = 1" so that the segment can be pasted back in upon reverting at that spot. This has the benefit of leaving the .CFGs where they are in case comments or other tags (like resource definitions or something) are also present, and the numbered tag allows multi-part .CFGs to be put back in their original order when reverted (no matter which part is looked at first, since each part will "remember" which number it goes to). Once the Part{} segment is removed from it's original .CFG, it gets placed into it's own part.cfg file in a sorting folder named after it's newly assigned order number.

[MisterFister]

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.

[JumpsterG]

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.

I know how category is used, and I'll describe it below, but I believe that subcategory, as it is defined in .cfgs at this time, has no function. You can try setting it to different values to see if it changes anything, but I don't expect anything would happen if you were to outright remove it or set it to a non-zero value. Short-term, it might be a handy place to store a variable, but be aware that Squad may give it some behavior at some point down the road. For my own utility, I track subcategories separately from that value and ignore it altogether. It's worth noting that subcategories are merely a convenience I decided to implement; it would have been easier to just track all parts individually within a category, but subcategories allow you to group stuff and reorder entire groups relative to one another.

The Category value is pretty straightforward. Every part that shows up in the VAB/SPH has Category set to one of the following: Pods, Propulsion, Control, Structural, Aero, Utlility, Science. This corresponds to which tab it belongs to in the construction screen.

Some parts still use an older convention for Category, so you'll occasionally see a number instead of the category name. For reference:

0 is Propulsion

1 is Control

2 is Structural

3 is Aero

4 is Utility

5 is Science

6 is Pods

If the category is not one of the numbers or category names listed above, it will not show in the VAB/SPH, since it doesn't get assigned to any tab. I think (requires testing) that the part is still loaded into memory, so this theoretically means you could still have crafts with that part in flight, while the part is not available during construction. I didn't think the distinction was useful before, but I may test this out and make a difference between "Hidden" parts and "Disabled" parts in my utility if it is possible.

Part load order is absolutely determined by the order the folder and filenames appear (though there are plugins that can change the order during or after the parts loading). The previous convention I used was moving all installed part folders to one "sorting" folder and then adding a prefix to all part folders corresponding to their desired position. So you'd get something like "_001_00001_ReactionWheel" followed by "_001_00002_RCSBlock" where the first number was a subcategory number and the second was the order number within that subcategory. My new take on this is creating the more generic part .cfgs with one Part{} segment per file and placing them in generic sort folders that look like:

A part that has no subcategory:

"Gamedata\_KOPSorting\Pods\_00001\Part.cfg"

and for a subcategorized part:

"Gamedata\_KOPSorting\Pods\_00002_UnmannedProbe\_00001\Part.cfg"

I probably wont have a version 2 out until the weekend comes, but let me know if I can advise in any way. I'm no genius, but manipulating text files is part of my day job.

[Dvarx]

It looks like this mod have a lot of potentian to be a good organiser, supporting you with trying to make it for 0,23 version guys

[JumpsterG]

I've told myself I can't play .23 (except for testing) until I roll out a useful version.

Discovery of parts, placing them into sorted folders, and resetting them is almost done. I still have to implement automatically changing file paths from local to url formats. Once this is done, KSP will load all parts from the sorted folders correctly.

Then comes the hard part. Implementing the management UI. I think I'll make an initial version with just the ability to sort things, and tack on the .cfg editing features in a future version (so I can start playing .23 get the tool out sooner!).

[JumpsterG]

Update available. There's a few features I didn't get around to finishing, like the autosort and the module presets, but other than that, it should be fit for purpose. Any and all suggestions and bug reports are welcome.

[KeithStone]

nice mod! I kinda wish this was around during my older days of having no idea how to edit .cfgs, but nevertheless, I think I'll be picking this one up.

[JumpsterG]

nice mod! I kinda wish this was around during my older days of having no idea how to edit .cfgs, but nevertheless, I think I'll be picking this one up.

Hope you find it useful! Let me know if you come across any mod part in particular that fails to show (either in app or in game).

I've tested stock parts, KAS parts, and RemoteTech parts, but haven't taken the plunge to test the big part packs, yet. Everything SHOULD work at this point, but you never know when something exotic will pop up (like some stock parts still referencing .DAE files even though they're actually using model.mu files... )

[SorensonPA]

Sorry, pal, but I'd advise anybody who sees this to stay as far away as possible. Something in this starts screwing with parts after a while (fuel lines don't properly function, random explosions sending parts on system escape trajectories, etc) even if you reload and undo any changes, and the only thing that fixed it was a complete reload of the entire GameData folder. Never had anything like this before, so it's no mere coincidence it started with this.

Edited February 2, 2014 by SorensonPA

[JumpsterG]

Sorry, pal, but I'd advise anybody who sees this to stay as far away as possible. Something in this starts screwing with parts after a while (fuel lines don't properly function, random explosions sending parts on system escape trajectories, etc) even if you reload and undo any changes, and the only thing that fixed it was a complete reload of the entire GameData folder. Never had anything like this before, so it's no mere coincidence it started with this.

Eww. Thanks for mentioning. I have played infrequently over the last few weeks. Once or twice I saw strange, splodey behavior, but chalked it up to Kraken attacks, since most everything worked as expected. :/

The only functional, global change this tool makes to parts is to change them from using the old "mesh = model.mu" system to the newer "MODEL{}" system for loading models from a remote folder (Required when splitting parts out from multi-part .cfgs and for leaving mod resources in their installation folder). This could be an indication of a bug in KSP if ordinary parts using the exact same models are spazzing out when loading their model the new way. (Note that ALL of squad's parts still use the older way, possibly for this reason?).

It's true that, currently, reset does NOT put the .cfg back to using it's original method of loading model, so if that's what's causing the problem, reseting will NOT fix it. Only reinstalling the part .cfgs or adjusting them manually to uncomment the "mesh = model.mu" line and eliminate the MODEL{} tag will revert them.

Thanks for trying it out, though. I will update the original post to indicate that some buginess may accompany use of the tool, and consider options for making a variant that does not change existing .cfgs to use new "MODEL{}" system. I don't have a great amount of time to test things, so if anybody can submit a .craft file that ALWAYS explodes or does something strange, I'd appreciate looking at it to see if there's anything I could change that will fix the issue.

I might also post a thread to the bug report forum and see if it's any help to the devs (though I'm sure they're aware the MODEL{} tag needs work, since there seems to be a known issue with the rescaleValue variable being used incorrectly in calculations).

[a__gun]

This sounds amazing! I love the idea of actually being able to use the subcategory system, but I don't really like the sound of making changes to the cfg files.

Would it be possible to make a version of this that uses ModuleManager patches to set/change the category and subcategory of parts whilst maintaing the integrity of the original file? I don't know exactly how your plugin works but if this were possible it would be awesome

[JumpsterG]

Hi a__gun. I have considered using ModuleManager to help maintain file integrity. I would absolutely love a solution that allows me to leave the .cfg files exactly as they are. I've seriously considered building a feature (or a separate tool) that acts as a ModuleManager-Manager...

The biggest reason I have to "touch" the files is that they need to be relocated to a sorting folder in order to be loaded into KSP in the desired order. Further, I've taken the approach of just lifting the "PART{}" content from the original .cfg, so that .cfgs with multiple part definitions can be split up into separate files. Finally, I integrated the .CFG editor as part of the tool, with the intention of exposing Part definitions for direct changes, so it's basically designed to modify the .cfg files directly.

All that said, I'm always concerned about the "Revert" function not working correctly or people accidentally breaking their parts, so If I update the tool again, I might start leveraging ModuleManager just so that I can more reliably revert changes. I just need more time and energy to work on this (both in limited supply due to some big life changes going on right now).

[a__gun]

I just need more time and energy to work on this (both in limited supply due to some big life changes going on right now).

First things first: thats absolutely fine RL always has to come first!

The biggest reason I have to "touch" the files is that they need to be relocated to a sorting folder in order to be loaded into KSP in the desired order.

So am I right in thinking this doesn't actually re-order parts in the editor as such, but rather forces KSP to load them in a certain order?

[JumpsterG]

Yes, that's right. This isn't a plugin, as much as an external tool. The idea is, you install KSP, then, after a little playing, realize you don't like how the parts are ordered. So you close KSP, open up this tool, and allow it to reorganize the part.cfgs in your preferred order within a sorted folder. The next time you load KSP, it will load the parts in the order they appear in the sorted folder (essentially alphabetical/numeric order).