magico13

Not yet, I'm still working on that unfortunately. I was hoping to have it done a while ago but June was super busy for me.

So I forgot that the NodeFormula is a rate, not the total, since the total is fixed as the science cost times 86400. If/when I rewrite it it'd make way more sense as a total and just a fixed 1 per second kind of thing. All you need to do is put that formula in the denominator and the total science in the numerator, like so: [S]/(max(43200,l([S])*86400)*30) or [S]/(max(0.5, ln([S]))*30*86400) I tested that out and got the numbers I was expecting.

The other comments are correct, the last official release was for 1.1.3, there are builds for 1.2.2 available on SpaceDock (and only SpaceDock, except for the build server) per the request of the RO/RP-0 folks so that CKAN can install RP-0 that are still Beta builds (these are also occasionally updated with changes from the 1.3 builds), and there are now Beta builds for 1.3. The next release will happen for KSP 1.3. It's all great and confusing since I hadn't gotten to a point where I was satisfied with calling any particular build a "release" and I should just suck it up and make an official one ScrapYard adds a part inventory that makes it so KCT's build times are shorter when you reuse recovered parts. Even if you don't use recovered parts, ScrapYard also has a part tracker that causes builds to get faster if you use the same types of parts (e.g. you use the same command pod all the time, the command pod adds less to the build time), so it's helpful to install just for that purpose. You can timewarp through any time constraints in a completely reasonable amount of time, usually just a few seconds. If you choose to only manage one mission at a time then using KCT will just make it so some time passes between launches and you come up on transfer windows (or life support constraints) considerably faster. KCT is highly customizable on a per-save basis, including turning it on and off. Each save has it's own individual settings (except for a handful of global settings that don't affect balance). You can turn the mod off for a save by opening the Presets selection UI with that save loaded, clicking the "Mod Enabled" button so that it is off, then pressing save.

It looks like it should work fine but it sounds like something about it isn't being parsed correctly. Is there anything mentioned in the log? You could try replacing the l() with ln() since that should be supported now as well. I'll try to put that formula in myself later and see if it breaks for me as well. I think I usually put a space after the comma, so the fact that you don't have one could be the reason as well, in which case that's a bug with the parser.

@Gordon Dry it had been mentioned to me in the past that Kopernicus might have an incompatibility. I'm guessing that was it. I've had a lot going on IRL lately so I haven't gotten a chance to look at anything yet.

KCT 1.3.4 is for KSP 1.1.3 and was before ScrapYard existed. If you're on 1.2.2 then you should be running KCT 1.3.5.7 and you may want ScrapYard build 55 (but 51 should be fine). Updating KCT to the latest should allow them to work together, but remember that with ScrapYard you have to manually apply the inventory. It's not automatic like it was when the inventory was only in KCT.

I haven't messed with the max temp or other attributes like that on parts, so I'm not sure how simple they are to interact with, but I don't expect it to be too hard. You might be able to do it pluginless with , but it'd probably be way easier with a plugin, but it doesn't sound like it'd require anything too fancy so it should be alright to learn through. I'd maybe create a new module, read your data off the module, then apply it to the parts. If you wanted it to work with ScrapYard, you'd just create a new module template so that your module gets loaded. Then when the part gets instantiated you'd pull your data off your module and reapply it to the part. Nothing really ScrapYard dependent actually.

Sorry about that. I used to ship the config file with it but didn't want to overwrite people's settings when they update. For now you'll just have to make the folder yourself (although if you're ok with all the default settings then it doesn't hurt to leave it as-is) until I get to a computer later this week.

Hmm, I've got an idea of how that's happening but it'll require testing. I won't be able to fix it until I am back at a computer next week. You might just have to scrap it and just build a new one. Editing it and saving it might work as well as a workaround.

All of the module templates are Module Manager-able so that should make things even simpler.

@NathanKell it's not actually that crazy, @severedsolo does something similar when a part has reached the end of its useful life. Right now you could take advantage of the forbidden modules and either pop a new module on the part so that it matches a forbidden one, or change a flag on an existing module and write a matching forbidden template. I should probably also just add a flag on ModuleSYPartTracker so that people don't have to implement workarounds, but can just call a method on a part to mark it to not be recovered. I'm away from a computer for a week, so for now you're stuck with the forbidden module/template approach. Hmm, there's also some merit to just completely disabling ScrapYard's event listened for the recovery event if a mod wanted to implement an alternative processor for that. I may look into that as well.

That's actually the opposite. I don't believe parts care as much about their folder structure as plugins do, since plugins need to read and write specific files but parts have little to no control over anything as they can't run code (unless there's a plugin with the parts, as some mods have) and they exist only in the loaded memory of the game. The plugins do not know what folder they live in. It might be possible to extract the folder their running from, so I can look into that, but it's definitely not standard.

Alright, thanks! A lot of people have had that issue since the install directory for it changed halfway through 1.2.2 per the request of the CKAN folks.

In the future, the log files are also recommended (posted to dropbox or other similar sites). Without the log I can only make general guesses. My guess is that you've got an older build of MagiCore sitting at GameData/MagiCore.dll, which you have to remove and make sure you only have the latest one at GameData/MagiCore/MagiCore.dll. That would potentially exhibit those symptoms, but the log would confirm it.

Fixed, and then some It should now populate the list correctly, should wrap the list in a ScrollView so that if it's really long it won't go off the screen, and you should be able to launch at any open site without having to go into the editor and do any funky workarounds. It should just be that you set the site with KCT and can launch right away. Let me know how it works (and also that stock isn't broken...)

This should be fixed now in the latest build on SpaceDock and at the new automated build site for the 1.2.2 backports (and also fixed in the 1.3 builds). Let me know if you're still seeing issues, thanks!

Yeah, doesn't sound unreasonable. I test that code with really small ships and use less fuel than that. A mostly empty stage won't require too much, especially because its terminal velocity (assuming that calculation is working even remotely correctly) shouldn't be too high. Like, less than 200 m/s of dV probably was required. Powered landings are remarkably cheap in requirements.

@Kerbas_ad_astra I'll try to take a look at that soon. Hopefully is as simple as changing a few strings in a few places. Hopefully I can also fix the issue with having to manually load sites before going to them to avoid crashes. Just a heads up, since 1.2.2 is still fairly popular I've started up a new automated build process for the 1.2.2 backports branch. I'm still preferring active development in the 1.3 development branch, but the 1.2.2 backports branch will include any changes I think are important enough to backport (mostly bug fixes, maybe some new stuff). I have to manually cherry-pick the commits from the 1.3 build into that branch as of right now, but I've at least got them automatically building whenever I do that. You can access the builds for 1.2.2 from here: http://magico13.net:8080/job/Kerbal Construction Time 1.2.2 Backports/

How many completed vessels do you have? I'm betting it's the log spam due to calculating rollout non-stop. Try the latest version from SpaceDock since it removed that log spam.

I mean, if you think it's harsh that you have more options than other people (assuming you're playing with the option where each site gets full access to the pool) then I can't stop you. With KSC Switcher you've got the option to make one KSC specialize in one type of construction and another specializes in another. Stock KSP doesn't have separate sites, that's only with KSC Switcher, and I've already added more support and options for KSC Switcher (a mod I don't use btw) than I need to. If you have a balance problem with RP-0, bring it up with the RP-0 folks or edit the Preset yourself. Or use a single KSC. I could have just made it so there was only a single KSC you could do anything with, even with KSC Switcher, which is essentially what it was before I spent a bunch of time adding support for mods I don't use.

Because the VAB is the closest approximation to a construction facility we have in KSP and it allows for natural progression since the player would be upgrading that anyway. Default KCT only uses the VAB level to restrict the number of build rates you can have (2 per level). I don't know what RP-0 decided to do with that, so if you've got a question about the RP-0 Preset you'll have to ask them about it. You are more than welcome to change an existing Preset or create a new one, if you're interested in that then check out the wiki as there are several pages talking about it. You can completely redefine the formulas that are used for everything through the Preset system.

I'm not sure what the problem you're having with ScrapYard is, so feel free to send a log my way (.zip it if it's big). A few people have mentioned still being on 1.2.2 and having issues with that logging, so I'll see if I can backport that change without it being a huge pain. Edit: There you go. Backported that change and at least one other one to 1.2.2, then uploaded it to SpaceDock (and thus also CKAN). Have fun.

1. This is true, but isn't important for the tracker. 2. Every instance of every part has a unique ID. The tracker is indexed by a full InventoryPart and so all of the InventoryPart's fields are required or else it will break the game while loading, _id is one of those fields. Those specific examples are actually individualized by their stored MODULEs. 3. No, every part can be turned into an InventoryPart, even if it hasn't ever been part of an Inventory. That's actually how comparisons are made, by turning every part on a vessel into an InventoryPart and then calling IsSameAs. The extra fun that resulted in Inventoried having to exist is that you can put a part in the inventory without recovering it. For example, KCT does this if you build a vessel and then scrap it without ever launching it. Other mods (or ScrapYard itself) may come out that allow you to purchase parts ahead of time in bulk for reduced per-unit costs, without counting as a recovery. I only need the tracker section from KCT_Data to convert things, but you're free to attempt it as well. You'd have to take the count from the old save and put it minimally into buildsTotal and usesTotal. You can split the usesTotal into usesNew and usesInventoried however you like (those must add up to usesTotal). Splitting buildTotal into buildsNew and buildsInventoried is fun because those don't have to add to buildsTotal (they just can't exceed it), since a build could have used a new instance of a part and an inventoried one. The actual counts don't ultimately matter that much. As for the ScrapYard.InventoryPart, copy an existing one but change the _dryCost to 0, keep the _id the same, _timesRecovered as 0 and _inventoried as False. Only the _name matters and it just has to be the actual name of the part (if the name in the tracker section of KCT_Data mentions anything about size,like "liquidEngine2,2.5" then don't keep the size part, just the base name). The reason the rest of the stuff doesn't matter is that the tracker is (by default) only set to compare by name, but it is capable of comparing by any amount of strictness (including all the way up to ID) if desired (by the modder using it).

You can migrate the tracker, but not the inventory. It might be easiest if you just send me your save file from 1.1.3. The tracker really just uses the name like KCT's tracker did, but the inventory is way different.

It's due to some logging I added to diagnose a bug someone was having that I've since removed from the 1.3 builds. I'm not officially supporting 1.2.2 anymore, but may make a build with that logging disabled.