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?