magico13

I'm just stopping by to mention how weird it is for something I did over 5 years ago to have butterfly effected like this. I don't remember exactly the reasoning for swapping to persistent id off of the guid that I was using, except perhaps a somewhat ironic desire to use more stock functionality and less custom code. At the time it didn't seem to cause any issues but I'll admit I wasn't always the most careful developer.

As the original dev of Kerbal Construction Time, StageRecovery, ScrapYard and a bunch of small mods, I'm in agreement with a lot of this letter (consider me signed). I won't touch modding KSP2 until there's an official loader. An unstable API is fine by me at this stage of the game's development but I'm not going to go through a third party loader when the base of one exists in the current code. There's danger in too many competing standards and the fragmentation it can cause.

I hadn't made any real progress on it, been working on other things so I haven't spun up the Jenkins docker container. I'm still alive, don't worry but I can't promise whether this will ever get to a useful state.

If/when I've got something remotely usable I'll get it onto CKAN. I use CKAN for pretty much all mod installs personally so I'd definitely want to support it.

Stage Recovery (the mod) and simulations would remain separate, though I do have a simulation mod I had been working on at one point that's half-finished. Sorry for the lack of updates on this, I've actually been playing a bunch of KSP lately in part to get familiar with everything that's changed and also because it's just fun...

I've been running the latest version in 1.12 without issues. Sounds like it could be a conflict with a different mod? Most likely you won't get more detailed help without providing the log file from when you try to run the game.

I don't really want to keep the system as it is now, where KCT takes the active vessel and tries to turn it into a craft file with often mixed results. I instead want to recover+refurbish a craft back to the original state, so for a plane it would basically reload it to as if you launched a new one, and for a booster it would revert it back to the subassembly state. It's a similar system but would eliminate any manual steps to refuel/replace parachutes/etc. It also eliminates the issues that crop up all the time with converting a vessel to a craft file.

That's roughly what I'm intending. I want to have it so if you build a "standard" design, ie one you've built before, then the design time is zero. Then with ScrapYard I can also detect that those parts were used often so I can cut time down even more due to that. So if you look at what I've got roughed out as the different build stages you can see that the design time would be zero, part acquisition might be reduced, testing would be greatly reduced, etc. So if you reuse a booster design and reuse a payload design then you can cut back a lot of build time, then the merge process (which I'm definitely still doing planning on) would be super short with basically just the "Final Checks" phase. Ship Construction Phases: Design - 15% Based on total complexity, 0 if using existing design. Reduced if using parts that have been used frequently. Part Acquisition - 25% Based on the most complex part, 0 from inventory. Reduced if using frequently used parts. Cancel after this: add parts to inventory Construction - 45% Based on total complexity, reduced with frequently used parts. Testing - 10% Based on total complexity, especially new parts. Less for existing design. Final Checks - 5% Based on total complexity

Again, not really set in stone yet. First versions will probably be pretty much hardcoded, but I may enable the formula system again but maybe only within config files. Personally I like making things configurable but it's a lot of extra work when 95% of people will probably just use the defaults or make minor changes. I know I definitely don't tweak the settings in every mod I use, I just sorta want things to work in a reasonable way.

Right now nothing is particularly set in stone but it would definitely be lower on my priority list. Since RO has their own KCT fork I imagine they will likely keep running with it, especially because this version is probably not going to be quite as configurable as the old one.

That's basically the plan. The current breakdown I have for how to split up the build stages for a vessel has reusable, standardized launchers taking about half the time compared to a new ship. Also related, I want to have merging of two already built items (ie launcher and payload) be super short, if not instant, to further incentivize that. It'll definitely take some playtesting and tweaking to get it right.

That was one of the features of KCT I was particularly proud of getting working from a technical perspective but with the stock game having multiple launch sites in it now there's not much of a reason to keep that feature around. Plus with Kerbal Konstructs adding even more sites as an option, I'd rather just tie into those systems more and keep this mod a little simpler

Speaking of that version, I've got a thread for that started over here. Not much to report on it yet, still mostly planning and trying to remember how to make mods

Kerbal Construction Time: Reconstructed (KCTR) is a complete rewrite of Kerbal Construction Time with some notable changes. The main goal of this project is to rewrite the mod with cleaner, more maintainable code, but also to rework features that I felt could use some TLC. That means some features of the original KCT may be removed, tweaked, or new features may be added. The original KCT will still be available if that's what you prefer to use, infinite thanks to @linuxgurugamer for maintaining that in my absence. Here is a rough set of ideas for this project, which are definitely subject to change. Keep: Time for building ships, ksc upgrades, tech node unlocks Time for rolling to/from pads, recovery, reconditioning (though revamped) ScrapYard integration Support for multiple launch sites Alarm clock support (stock yes, KAC tbd) Remove: Button to quick build a ship Upgrade system (instead focus on ksc upgrades and/or spending science/funds) High levels of configurability/presets (some will be retained) Science for building ships Multiple launchpads at the KSC (note, not launch sites/ KerbalKonstructs) New: Higher integration with stock UIs Try to reuse or emulate the ship picker. Allow queueing from the KSC scene. Do something with the awful crew select screen. Drag and drop functionality to reorder ships in a queue Increased focus on subassemblies instead of individual parts Build done in discrete stages (eg design, part sourcing, integration, testing, final checks) "Build Points" replaced with "Complexity", rates replaced with "Efficiency" Development builds will be available on my Jenkins build server, source code is available on GitHub. This thread is for discussion of these changes and for beta releases as features get implemented.

If you're alright with it, if you want to handle that update and stay as maintainer over this, I might start up a new dev thread/repo for my idea. That way I can take some more creative liberties with less risk and if it never gets finished or it sucks then this fairly stable version is available unchanged. Sound good to you?

Speaking of updates and weird situations, since KSP 1 is at its end I've been toying with the idea of coming back to this and making a more "finalized" version of KCT. Basically finally go in and break out the UI code from the processing code, rewrite some stuff to be more streamlined and less hacky, fix weird things, etc. Potentially a full rewrite from the ground up, though in the past that's been an overly optimistic goal. I haven't started anything with that idea, it's only an idea at the moment, and I honestly have only a vague idea of what's changed over the years since I've been gone so I definitely don't want to step on any toes/disrupt any plans if I did this. I have not fully decided whether this project would be "rebuild KCT as-is" or "make a new KCT with slightly different features, some new some removed". I guess consider this post a request for comments/thoughts on this idea. I also want to once again thank LGG for all of his excellent work on maintaining and upgrading this over the years. If you need any assistance with the upgrade to 1.12 let me know.

That formula gives the rate of the research in science points per second. So with N being 0 (no upgrades) it's 2 / 86400 or 2 science per 24 hour day, with N = 5 it's 64 / 86400 or 64 science per day. Easiest way to make things take a flat 2x as long would be to just add a " / 2" to the end (formulas don't follow order of operations, just left to right) but you could also change 86400 to 172800 or change the "([N]+1)" to just "[N]". All of those are equivalent and are just dividing the rate by two. Edit to add that that's safe to do for any in-progress stuff since it affects the rate and will update right away. Changing formulas that control the "cost" of something, like the BP cost of a ship, won't update right away unless you force it to recalculate by editing a ship or completing another vessel.

Yep, that sounds right. I would usually make it so that a negative value gets treated as "disabled" and treat 0 as positive in the sign function, so index 0 would have a positive rate and index 1 would be negative. You could do sign(1-I) to have two positive rates instead. So @Strych74if you modify that formula to multiply by sign(-I) then it should end up only allowing one node at a time. Note that the "I" should be in square brackets [] but the forum thinks I'm trying to italicize stuff.

There's a way to do it with the formulas but I don't remember it off the top of my head. I don't recall if there's a preset that uses that functionality. I think that RP-0 did. Once you force it to be limited I think it will give you buttons to change the order in the queue and other management stuff like that too but I gotta be honest it's probably been like 3 or more years since I used that functionality.

Yep, you got it. That one gives you science for building vehicles. If it's non-zero you'll see a small message in the top left (either that or top center) when a ship is done building that'll say how many science points you got for building it. You only get science for new builds not for editing existing builds.

At 0.9 for the second one you should definitely see a third if you've got points available and an upgraded VAB. First goes up by 0.05, second by 0.10, third by 0.15 iirc. So for the third you should only need a rate of 0.20 in the second rate.

It used to be tied to the upgrade level of the VAB iirc and that might still be the case. Each of the three tiers would add two slots, up to six at the highest level. A different preset would have different scaling rules, it'd be defined by one of the formulas but not in a way that's immediately clear, most likely a sign() function that causes the formula to go negative once the index of the build rate is too high.

Not exactly. That other mod would physically move the KSC locations so it just whichever one you currently had selected. Launch sites are generally treated like launchpads, not a whole other KSC. Theoretically the support for other KSCs is still in there but I haven't perused the source in a few years at this point.

Funny that you mention that because with KSCSwitcher installed KCT would treat each KSC almost completely separate. Different build queues, different ship inventories, different upgrades. Some stuff was shared though, like the tech tree.

It's already in KCT, although only from the KSC and not other locations. https://github.com/linuxgurugamer/KCT/blob/master/Kerbal_Construction_Time/KCT_Recon_Rollout.cs#L135