magico13

Shoot. I thought it was packaging them correctly but I clearly messed that up. It should be in its own folder. I'll manually fix that today and will have to adjust my build script again. Edit: Alright, I think I fixed that and I updated the build script so it shouldn't happen again.

Build #26, link here.

Let me know if you see it again and try to send the logs if you do. I wouldn't be surprised if it did mess up but hopefully it'd be something I could fix.

I did that enough times that I set up the build server so that I wouldn't be able to mess it up anymore. I can give you some space on my build server if you want.

So I'm still testing it, but the latest builds of ScrapYard (#60) and KCT (#30) should work together better than before. Recovering things to storage and editing existing vessels should behave better now. For instance, if you edit a ship that has inventory parts on it, it'll still have those parts assigned while editing and if you remove any they should end up back in the inventory. I need to still test the overall behavior of KCT with the "override funds" option of ScrapYard since there may be a few cases of double charging or not charging at all for some parts.

Done. Also added a direct link to the last build for 1.2.2

30+Vsync is alright for gaming, since your monitor is probably at 60hz. Then you get a full frame every second refresh with no tearing. Some people are really against vsync but I personally prefer slightly lower framerates with correct images. Though FreeSync / GSync are really the best solutions for that. I built this rig after a summer internship and have progressively updated it through the years. The first incarnation of it was a few months after I started playing KSP but about a month before I started modding, so November/December of 2013. It's got an i7-4790k (gotta get that nice single core performance for KSP), GTX 1070, and 32 gigs of RAM (I bought 16 more when I was going to need to run some big simulations for work a year ago). The motherboard was replaced due to it failing, and the CPU and GPU were swapped out at different points (from an i5-4690k and a GTX 770). You can build something pretty capable for around $750 these days if you've got peripherals. A 1060 is plenty capable and even i3s are capable of a lot (but an i5 is a good middle-ground).

I can run Overwatch at 4K and 60fps without any problems, but KSP will only run at 40 (but that's with Scatterer). I should maybe set up an "average" computer to test performance with at some point since I don't notice performance issues as much on my desktop

Eventually I'll replace all that debug info with a single line that's a summed up version (since the full ID isn't needed by 99% of people unless debugging).

Were any parts replaced with their inventory versions? You can check by right clicking them and looking for "Inventoried: true" rather than "Inventoried: false". I'll try to look into it, but if you see it again send me a log since it's pretty verbose about that.

If you scrap a vessel that is in progress, it is supposed to loop through all the parts and send any that were from the inventory back into the inventory. If you edit an in-progress vessel I don't think it will behave properly right now.

Yeah, that's the next thing I'm working on. Definitely not ready yet, sorry.

It is inherently multiplied by the BP of the vessel built. So a vessel with a BP of 86400 (24 hour build time at 1 BP/s) would generate 0.5 science per upgrade. Science is only generated once per vessel.

The main thing right now is that ScrapYard won't work right in all cases. Specifically when editing a vessel or recovering one to storage, it straight up will do the wrong thing, meaning the inventory will get out of sync with what it should be and build times might be a bit funky. After I fix that I might just release it, then work on other bug fixes and features. I also want to work on ScrapYard's UI at some point, but might put that off until after I release KCT.

Made the change through GitHub. It should be firing that now in the latest dev build.

Try this build, it's the last for 1.2.2: http://magico13.net:8080/job/ScrapYard/55/ Would it be fair to just fire OnSYInventoryAppliedToVessel again, or would you prefer a different event? I should probably just make an event that fires for every part whenever the ModuleSYPartTracker is changed in the editor, but that'll fire a lot when applying inventory, which is why I opted for the other call.

Close. ScrapYard replaces the part inventory (recovered parts make builds faster) and KRASH replaces simulations. SimuLite is/was a simulation mod I started working on but I haven't gotten a chance to finish it.

It's for a couple reasons. One is because you're supposed to choose parts out of the inventory as you build, the automatic option was added as a stop-gap until that is working (but will likely stay in). Another is that when you're overriding funds it will cause the cost display to update correctly. And a third is that other mods that might use ScrapYard can display different things based on the current vessel that are pertinent information. For that last one, KCT is a clear example as it shows the build time for the current vessel and that's highly dependent on if you're using inventory parts. UPFM I believe has plans (or is currently) showing you the failure chance of parts while in the editor, which is a design decision. If you don't care about all that, you can just manually click the Apply button when you're done and ready to build. I don't intend to have it auto-apply at build time since the decision of which parts to use (if any) is supposed to ultimately be an active part of building the vessel, so if you don't want inventory parts you shouldn't be forced to use them, but I might consider adding a pop-up at build time asking if you'd like to apply the inventory if you haven't already, just in case you forgot. Also, I made a new update. This one is for KSP 1.3 only. It's got the auto-apply (which was previously just in dev builds), added a "reset parts" button that resets the current vessel back to brand new parts (auto-apply kind of prevents that from sticking though), and fixed several bugs.

Well, the processing SY does isn't small, so it could be adding some lag even under normal conditions. I used half a second since it felt the most comfortable while still being a decent amount of time (without that setup it runs multiple times a frame. Like, hundreds of times a second). If you've got Auto-Apply on and are getting lag you can turn it off and see if the lag stops, if it does then that's probably why.

These are all optional ideas btw, stuff that would be added as options on top of the defaults. The part unlock times would only make sense if part unlock costs are on. That would be a new formula with variables like part cost, part mass, unlock cost, and base node science cost. Maybe I'd define a short time by default just to show it's an option, but I might leave it off by default and just offer a different Preset.

Sorry, that wasn't the implementation in question, that was just an extra thought I had since some people might want to slightly modify times based on the number of parts (in addition to some base time for instance). The thing in question right now is whether it's worthwhile to have individual parts take time to unlock when playing with part purchases enabled. In a way that makes the time dependent on the number of parts in the node (since you'd have to take time to unlock them all), but with default KCT you can work on an unlimited number of nodes at once.

It should only be doing it at most twice a second and then only when OnEditorShipModified has fired... I'll look into it. Edit: Well, it looks like it fires the onEditorShipModified event when it's done applying the inventory, which then tells it to apply again and then causes an endless loop. I'll fix that tonight.

Well, do you think the current method of node unlock times is ok for you, or would you rather see nodes unlock instantly but individual parts take time? Or some combination of the two? I just realized I should probably add a variable for the node unlock times that's just the number of parts that would be unlocked, in case people wanted the times to be based on that.

ScrapYard may actually result in an interesting situation where if you use the test part and then recover it, you can then use those parts again even if they're locked. You could abuse that by building a vessel that's just a bunch of the test parts, but once you complete the contract (or in this case you start researching the node) you'll have access to a finite supply of those parts. Though KCT right now would let you have an infinite number of new parts. A solution might be to give you 5 or so test parts into your inventory and you can only use test parts as long as you're using one of those inventory parts. If you try to use more than you have, you can't build the vessel at all, and if you accidentally destroy them all then you have to wait until you fully unlock the node before you can do the contract. Unlocking the parts within a node is definitely possible, but I don't think that setting is used all that often so I'm not sure if it'd be worth the effort. I know I only used it when I was playing with Tree Toppler and was unlocking the tech tree entire chunks at a time as I upgraded buildings. Essentially I was playing without science at all and just playing with funds+rep.

It's an issue I have tried to fix before without much luck. There's a workaround, which is to make sure to put the part on a build before you unlock the node, since KCT will let you launch with parts you don't have unlocked. The "debug logging" that I generally recommend is a setting in the KCT settings, but if you're using the dev builds it's already forced on and can't be turned off (it's a compile-time constant in debug builds). Thanks for the report anyway, it's only been mentioned a small handful of times (if it's actually been reported or just something I found in my own testing) so I'm not too surprised you couldn't find any discussion on it. Here's the github issue for it, #18. I really need to go through that list and close things that shouldn't be open anymore.