magico13

It'd probably be something like the stock one, using all the same backend code, but it'd try to grab parts out of the inventory automatically as well. So for the Falcon 9 for instance, you could save stage 1 as a subassembly and then grab that out and automatically use all the parts you recovered when you landed back at LZ-1. If you were missing any or all parts, it would just swap in new parts. That's all just how it would work in my head right now, actual implementation might be different.

Right now, no. But I've got ideas for storing subassemblies and entire vessels that may come into play later. As of right now there's no need for it, but I could see it being useful later when you don't use the "Apply Inventory" method as often. I'll keep it in mind.

You can forbid parts on the basis of modules by creating a FORBIDDEN_TEMPLATE in the ModuleTemplates.cfg file (see the already existing KerbalEVA template). You'd have to have a module that is different though. As of right now you can't blacklist parts, but that is something I'd like to add. I might also add an option so you can right-click a part in flight and set it to not be added to the inventory on recovery since that'd be easy to add. Partial discount is harder, especially on a per-part basis. I might try to come up with a general way of allowing modules to set that and then someone could make a small mod that allows that, but I'm not sure the creation of that small mod is something that should be in ScrapYard, just the backing code that allows for it to function. Could be because of the changes for CustomBarnKit. Send me the log if you don't mind as it should say what rates are being set. Also make sure you're using the latest MagiCore and KCT versions and don't have two MagiCores installed anywhere.

Delete any MagiCore or KerbalConstructionTime folders in your GameData folder. Then take this .zip file and merge the GameData folder with your GameData folder. Make sure you're running KSP 1.2.2. If that doesn't work then read through the thread that @TheRagingIrishman linked and grab the log file for me to look at. Without the log I can't help any more.

With or without KCT it works the same way. There's a button on the stock toolbar (that needs a real icon, if anyone wants to volunteer one ) that when pressed opens up a small window with another button that says "Apply Inventory". When that is pressed ScrapYard loops through all of the parts on the current ship in the editor and tries to find parts in the inventory that match that part. It defines a "match" as both parts have the same saved Modules (defined by which modules are saved in ScrapYard), so with tweakscale the two parts have to have the same scale and with procedural parts they have to have the same dimensions, tank layout, graphics, and such. If it finds a match, it copies over the ModuleSYPartTracker from the part in the inventory onto the part in the editor, so you'll see the ID, TimeRecovered, and Inventoried status on the editor part update to reflect the values of the part in the inventory. When you build that vessel (through KCT or normally) all of those parts that were copied from the inventory are fully removed from the inventory. This has a side effect of requiring you to be able to reproduce a part exactly in order to pull it from the inventory. That might not be possible with things like parts with upgrades that can't be downgraded, so some parts could get orphaned in the inventory. In the future you'll be able to discard/sell those parts at least to get rid of any useless parts, but once you can grab individual parts out of the inventory you won't have to manually recreate them in the editor first since that'll be handled automatically. That's one of my next goals along with the override funds option.

I too am looking forward to it. If nobody does it I might just make a simple one. Or I might at least put in an option where parts can only be used x times before they're automatically discarded/sold (up to infinity). That at least might help a bit with inventory bloat.

Release thread now open! I still have some work to do on it, like add pictures and rewrite about a thousand words in the history part that all got wiped out by some accidentally messed up spoiler tags... But it exists! Stuff shouldn't change too much now, just bug fixes and polish mostly. Plus the override funds setting and a new GUI.

ScrapYard: The Common Part Inventory ScrapYard is a mod that provides a part inventory that can be shared between multiple mods. Parts are added to the inventory when you recover a vessel and are removed from the inventory when you build a new vessel. If you have ever played with Kerbal Construction Time, it's a significantly improved version of the part inventory that KCT had, that is also able to be used by other mods. As of writing, ScrapYard does the following: Parts are added to the inventory automatically upon vessel recovery Parts are applied in the editor (not automatically like with KCT) Parts are then pulled from the inventory on build (mods can change when this happens) Parts are stored individually in the inventory along with any modules that “define” the part (think TweakScale and Procedural Parts) The number of times “like” parts are used is tracked and available for mods, both total uses and number of builds (KCT’s part tracker feature, expanded) Parts are trackable from the moment they are placed in the editor until they are removed from the game via a unique ID that transcends recovery and new builds The number of times an individual part is recovered is tracked, perfect for consumption by part failure mods (WIP) Funds can be overridden so that using parts from the inventory do not contribute to the cost of the vessel. You do still need to have the full amount of funds (for now). ContractConfigurator support for adding or removing parts from the inventory as part of contracts Download: 1.1.0.107 (2018-03-18) SpaceDock GitHub Source: GitHub Absolute latest builds available from my build server here: http://magico13.net:8080/job/ScrapYard/ ScrapYard is licensed MIT and includes both MagiCore (magico13, MIT) and ModuleManager (sarbian, CC-SA). Special thanks to @SiriusSam for the original idea of creating a separate part inventory way back in 2014 and for the name, and to @enneract for discussion and design help. As a player, why do I want this? If you are using Kerbal Construction Time, all balance is assumed you have this mod. It will substantially reduce build times for both vessels that use parts from the inventory and new vessels that use frequently used parts due to the part tracker. As of writing, no other mods are using this framework, but when they do this mod may be required. And this mod can be used by itself with the override funds option to play with a very different play style. As a mod developer, why do I want this? Mods using ScrapYard: Kerbal Construction Time by @magico13 Untitled Part Failure Mod by @severedsolo Changelog:

Infini Space Program Factory. It's like KSP, but ships get built by automated assembly lines?

You can install mods with CKAN but still launch KSP the regular way. Virtually all mods do not care if they're run with 32bit KSP or 64bit, so just point CKAN to your install directory, install your mods with it, and then launch the 64bit .exe yourself. You can also use SpaceDock to search for mods. I'm pretty sure SpaceDock has a way to search by compatible version but I can't find the list of ways to search off hand.

Fixed several ScrapYard bugs, some of them decently major. Examples are TweakScale not working, but that was a config thing. Another is that you could change a part after applying inventory and it would still "count" as being from the inventory (fixed by checking at processing time and once a second in the editor that the parts are valid configurations). TweakScale and Procedural Parts seem to be working as expected, but the SRBs in Procedural Parts aren't because the dry cost is getting set too high (I'm pretty sure that's why). I haven't figured out what's causing it to fail for the SRB but work fine for the tanks. I also reduced the amount of stuff that's stored for regular parts as the ModuleSYPartTracker isn't stored in its entirety anymore, but instead only the 3 values I care about are stored. On Vessels the whole thing is stored, since it's an actual Module there. The old setup will load correctly and will save it in the smaller form after a scene change. I'll remove loading the old way after the first Beta. Additionally, the latest Module Manager is now automatically added to the .zip file thanks to a python script that runs before the build, so that's cool. I'm going to try to do a bit more testing before setting up the Beta thread, but I'd still like to do that tomorrow evening. Also, there's only about 16 hours or so until this month's poll on Patreon closes. I'm still trying to decide on when to do the dev livestream (and what to actually show, maybe some UI development?). I'm thinking either the 13th or the 20th of May around 12pm EDT (16:00 UTC), but I could also do the 12th or 19th at ~7pm EDT (23:00 UTC).

No, it just tracks the part name, dry cost, a unique ID*, times recovered*, whether it's from the inventory* (since times recovered can be 0), and any modules that are defined to be tracked (TweakScale, everything procedural, any part that has had an Upgrade Applied. This list is designed to be highly configurable.). Right now there's no UI, just a button that when pressed goes through all the parts on the vessel in the editor and sees if there are any exact matches in the inventory, minus the ModuleSYPartTracker. If there's a match, the part tracker gets copied onto it (therefore the ID and times recovered are updated on the part), and then on build those parts are pulled out of the inventory. (* Through the ModuleSYPartTracker module applied to all parts upon creation.) For instance, if you've got a part that uses tweakscale to go from 1.25m to 2.5m and you have the 2.5m version stored in the inventory, if you have the regular version on a vessel in the editor then applying the inventory won't do anything. But if you use tweakscale to make it 2.5m and then apply the inventory it will pull the part out of the inventory. That means that if you can't recreate the part in the editor, you can't get it out of the inventory right now. I plan on making a UI where you can see all the parts in the inventory and "grab" one of them, turning it into a part stuck to the cursor with all the right modules applied. So if you've got parts with some upgrades but not others, you could still use the old version (in theory). I have a few designs in my head for that: A) Alt+Right click a part in the part list on the left to see a new window pane with the list of all the forms of that part in the editor (click a procedural tank and see all the different ones you've made, click one of those to make a part with those dimensions appear), or B) in the right click menu on a part in the editor, press a button to see a list of all forms of that part, then click one of those and it will automatically apply it to that part (resizing and such), or C) press the ScrapYard button to open a new window where you can see every part in the inventory and click it to make it appear in the editor. I might do a combination of all of those. Or I might do A with a little symbol next to the source part in the part list if it's got forms in the inventory, with a special category that only shows parts in the inventory. I like A since it works nicely with stock.

That's one of my concerns. ScrapYard itself won't slow down much, except maybe during scene changes (I might be able to fix that if it becomes a problem). I don't think Flight will slow down much if at all since that would be affected more by the number of ships active (which increases save size) but I don't think increased save size will affect Flight. Saving might take a bit longer (I might run some performance tests on it). Unfortunately it's the only way to make it work. Fortunately, only some modules are tracked, so for each part substantially less lines are needed in the save for an InventoryPart than for a regular part on a Vessel. I might be able to strip down how ModuleSYPartTracker is saved on the InventoryPart so that regular parts take up tiny amounts of space (like only 5-10 lines, whereas a part on a Vessel can take 30+). Basically, bloat, yes. I can maybe reduce it a bit more, but the only "fix" is a separate file, which introduces a bunch of other problems. Lag, probably not, other than increased save/load times in late game since there's more to store. Also, as the Override Funds option comes into play I expect people will keep their inventories decently managed since you'll want to sell off any parts you aren't using regularly. Same with older parts that have been recovered a bunch of times.

I'm not surprised by editing a vessel being a bit goofy. It's one of the situations I need to look at. Currently you can't view the inventory, it's one of the main things I want to work on during/post Beta. Not required for the mod to be fully functional, but definitely required for it to be easy to use. The inventory isn't a Dictionary anymore, it's a HashSet, meaning every single part in the inventory is stored individually (and no duplicates are allowed). Since every part has a unique ID (stored in the ModuleSYPartTracker) every single part is trackable from the moment it is placed in the editor, to the point where it is destroyed in flight. So there's no count stored anywhere. TimesRecovered is the number of times an individual, particular part has been recovered. That same exact part. Which is a core feature of ScrapYard (that KCT doesn't care about yet, but part failure mods might be very interested in). I'm pretty sure it's been that way forever, but I might be able to allow you to unlock in-progress nodes. Actually, I think it used to work that way but KSP changed some stuff and the UI doesn't update properly when I manually unlock a node. Hmm. No promises, but I'll look into it again.

Alright, I need all of your help. Per the ScrapYard Trello, ScrapYard is officially ready for Beta! I'm going to set that up a release thread in the next few days, but before the official Beta drops I'd like for you all to hammer it with anything you've got to uncover any bugs that are hiding under the carpet, behind the curtains, and in the cupboards. Interaction with KCT isn't as important as just ScrapYard itself, but it is important to also run tests with KCT since that will test the API as well. Basically both situations need to be tested thoroughly. What doesn't matter is the Override Funds option, since that's not an official feature yet. What needs to be tested: All parts get added to the inventory when they should (you have to watch the save file for now) Builds/uses get tracked in the part tracker properly Applying the inventory grabs the right things out of the inventory and applies them correctly Launching a ship (or building with KCT) pulls those parts out of the inventory as expected Recovering a part increases the TimesRecovered counter With KCT, scrapping a not launched, but completed, vessel sets Inventoried to true but keeps TimesRecovered at 0. Disabling the mod in the game settings actually disables it (no parts added/removed from inventory, no part tracker increasing, no button in the editor, and KCT doesn't reduce build times) Disabling just the part inventory actually disables the use of the part inventory (adding or removing) Disabling just the part tracker disables the part tracker as expected (won't increase with builds, KCT build times don't get better) TweakScale parts with a default scale don't have the tweakscale module stored TweakScale parts with a non-default scale DO have the tweakscale module stored Procedural part modules are stored (hit me with every procedural part mod you can think of, and give me .craft files for any parts that don't save correctly) With Procedural parts/tweakscale, when applying inventory only exact matches are applied (sucks right now with the UI, I promise it'll get better later) Find a mod that applies upgrades to modules and verify any modules that aren't normally stored (for instance, ModuleEngines) are stored if they have upgrades applied (porkjet's engines from here maybe? http://forum.kerbalspaceprogram.com/index.php?/topic/147582-update-12-pre-release-is-here/) Make sure EVAs don't get stored as parts Test out creating new MODULE_TEMPLATE and FORBIDDEN_TEMPLATE templates in the PluginData/ModuleTemplates.cfg file. It's not ModuleManager-able yet, but I want to do that during the Beta. I'll explain the details of this in a separate post later, but you can use the notes in that file to figure out how to define which modules to store or forbid. Right now it's stuck using MagiCore's math parser. Any result > 0 is counted as "true" for a requirement and <= 0 is "false". That does mean it can only check equality of numbers and not strings, for now. I need to either expand the parser to support strings or create something different. Probably tons more. Report anything and everything funky. I know for a fact that KCT isn't using ScrapYard correctly in some instances (recovering directly to storage is probably incorrect, editing a vessel might mess it up too). If you want to hunt down those too I'd appreciate it. At the very least, just let me know if something seems wrong and I should be able to quickly figure out whether it's working correctly or not. That can wait for post-Beta since that's a KCT issue and not a ScrapYard one. Again, thank you all for your support and help so far. It's not done yet, but it's so much closer than it was a month ago. With the Beta I want to clean it up and work on some desired but not required features. To be at a point where it actually seems to be working as I imagined it two years ago when enneract and I first discussed the design (though the name goes back to an earlier venture with SeriousSam) makes me incredibly happy. I've been wanting to break out and rewrite the part inventory for a long time, so I'm very happy that it's almost a reality (I know it might seem silly to be so worked up about limited value mod for a 5 year old game, but KSP modding is what enabled me to be in the career I'm in right now, and although ScrapYard's code isn't perfect it's still miles ahead of where I was when I wrote KCT or even StageRecovery, and it's nice to make something that doesn't totally suck that I've wanted to make for a long time. If even one other mod uses it then I'll be ecstatic, and if it's just KCT that uses it then oh well, at least KCT users will have an inventory that makes sense and will [hopefully] not break with weird mods.)

In this case I'd almost prefer the use of the PluginData folder that already exists in the main Kerbal Space Program folder, but it adds a problem when including config files in the download since there's not just a single GameData folder to merge. As a mod author, I'll do whatever is the most common (and thus expected by a user). I don't anticipate it moving away from GameData/<mod>/PluginData since that provides a single repository for a mod where it can do whatever it wants without accidentally messing with anyone else.

Yeah, see the few posts above your previous one, they're all about that. The build times shouldn't be any more crazy than they were before. If you're seeing super weird things I'd be interested in reproducing that (so a mod list preferably), but I'm guessing it's still just using 6 hour or 24 hour days. I have to look into how they're changing times to see if I can support it automatically and/or provide a config option for it. They seemingly aren't changing it the way that I would expect, which is potentially the easiest way. Edit: They are doing it the way I thought they would. But then they went and (incorrectly) hardcoded some values to Kerbin time, which happen to be the ones that I'm referencing. Edit 2: I submitted an issue on Kopernicus' GitHub. When they fix that, MagiCore and KCT should start working correctly. It's possible that other mods may start working automatically as well.

Not sure on the issue with build times. It's likely just a display thing. As for the spam of stuff in the editor, are you using Editor Time? It's probably because of that. I haven't fixed that bug yet, but KCT and Editor Time aren't working together correctly in 1.2 yet.

I'm guessing they're not changing the dateFormatProvider then. I'll need to look at their source and either provide a configuration option or try to come up with something that works automatically. Could you please link me to the appropriate thread?

KCT isn't executing the MagiCore methods correctly according to the log. Not sure why. I'm gonna look into it and will get back to you. Nevermind, figured it out. You've got two MagiCores installed. The way it gets installed changed from going straight to GameData (ie GameData/MagiCore.dll) to going into a subdirectory (GameData/MagiCore/MagiCore.dll). Remove the one that's in GameData and make sure the other one is the up to date one.

You can make it a .zip file and that should make it much smaller. Another thing you can do (in addition to zipping the file) is to start up the game, load the save, try to open the window, and then close the game. The log shouldn't be too big at that point and it should contain enough info. A worst case scenario is that you could open the log file and search for an exception involving KCT_GUI.DrawBuildListWindow() and copy a bunch of text before and after it and just post it here on the forum in spoiler tags. If you do forget to check back, hopefully the problem just goes away on it's own, as that sometimes happens Unrelated edit: Wow. I just did a few small updates to the OP and read through the entire changelog again. One, that was a weird trip down memory lane. Two, this mod has come so far from where it started, entirely thanks to the community really, but it's so freaking cobbled together that it makes me sad. And three, it's been almost a year since the last official update... Oops...

I linked it earlier, but here it is again. About half way down that post should have the location for each OS. Assuming you're on Windows, it'd be in the KSP_Data or KSP_x64_Data folder (those are in the KSP folder, next to GameData) and is called output_log.txt.

Try KCT 1.3.4 but I don't expect it'll fix the problem. The log would help. That bar is the build list, except an error occurred and so it failed to draw properly. Unfortunately there are about a thousand possibilities for why that happened. The log should (hopefully) tell me which thing went wrong.

What version of the game? What version of the mod? What version of MagiCore? Can you provide a log? I can't help without answers to those (at least the first three) questions.

May's Patreon poll is now open until the 5th of May: https://www.patreon.com/posts/9607929 This is a poll where my patrons can decide what they want me to work on for the month of May. For April I focused on KCT and ScrapYard and was able to make significant progress on getting a working part inventory system up and running. A public Beta build of ScrapYard (rather than the Alphas that are available now) should be available soon (as soon as I finish some configuration work, which might take a few days with testing). What I focus on in May is entirely up to you! I likely won't post when new polls are available on my threads in the future, but people may have missed that I started a Patreon last month so I am mentioning it again. I will make a post when I decide when the May live stream will be, since that's open to everybody