magico13

Well, not necessarily. If you're actually changing the manifest in the editor then KCT can just grab the manifest at build time and store that internally. The reason KCT just grabs the default crew for a vessel is that the crew you might want to use could have been sent off in another ship (or dead) between building the ship in the editor and launching it. There's no reason why it can't store a "preferred" list and default to that, falling back to the default crew if all the kerbals from the preferred list are off adventuring. Alternatively if the data is stored in the ship's config node then I can read that without any dependencies. Worst case scenario I use reflection which I've used to integrate with plenty of mods with either no API or a lacking one. Note this isn't me saying I'm definitely adding support to KCT, I might not have time, but I don't know that it'd be too hard to add when I do get time, assuming there's interest (it seems that way).

It's easier for me to maintain as a modlet and I don't intend on doing a whole lot extra on it (I've got other projects that eat up a lot of time). Mobile beacons are not a thing yet, but I don't think will be too hard to create so I may try to do that this week, depending on what project I end up working on.

I have, only one though. I believe it did something with crew on the vessel before launch. They put in a check for KCT and just didn't override if KCT was present, which worked fine since crew assignment goes through KCT anyway. I just don't like completely overriding things if I can help it, but in this case I can't so it's gonna have to work this way.

I took back the launch button! Just had to completely override the event and put my own method in, but not using the methods that Unity provides and instead just totally wiping out the event (and any other listeners, which is stupid and breaks compatibility with other mods that need to use the button as well). Just using the Unity method that removes all listeners doesn't work because of how they add their listener for the event, so instead it's nuke it from space and start all over. I don't like it, but it works. Unfortunately the changes to support Custom Barn Kit may have also broken time estimation in the editor. So there's that. I'm going to try to just cache the rates (you won't be changing them in the editor) but I need to figure out how to go about that. It still works for building, but it's definitely annoying.

This is amazing. You've definitely done a lot of work and it shows. In other news, I'm going to be updating NIMBY as one of my modlets. I just got it working in 1.2.2 and will post it shortly. Forum thread for the modlets is here:

I'm on my phone and about to eat dinner, but the formulas are all here: https://github.com/magico13/KCT/wiki/Preset-Formulas-and-Math-Parser-Documentation I may have added a variable or two since I'm not seeing those two extras and I don't remember what they are... Modifying the variable and adding it isn't really any different. Either way the integration wouldn't need to know anything about if the variable existed previously if it didn't want to. KCT could add it in but it's meaning is so general that I couldn't assign any real value to it. It also doesn't have to be R or even one letter, that's just how I originally wrote them. R wouldn't get used unless the active preset actually used it and extra variables aren't an issue (each formula already gets extra variables sent at it).

@cami you're right, I think I did do it upside down because I was caught in the "0 ignitors means it needs fully refurbished, so time must be maximum when at 0" except that you can just plop a new engine on instead and it doesn't take any time, since I was thinking backwards. Alright, so instead you calculate it so that the BP is reduced at recovery and goes up to "normal" when you restore the ignitors. For a simple example of 0% reuseable with 2 ignitors you just say the BP is 0 at 0 ignitors, 50% at 1 ignitor (1000), and 100% at 2 ignitors (2000). So BP = "2000 * ([ignitors] / [maxIgnitors])" at all times. With reusability I think it would be "2000 * ([ignitors] * (1-[reusability])/[maxIgnitors]) + [reusability])". Again, either each variable can be sent to KCT so the formula can be changed easily within the preset, or it can be computed within the integration and just sent as R (or whatever) to give "2000 * [R]". Sound correct this time? At recovery with both used it's at reusability, at 1 out of 2 it's halfway between reusability and normal, and at 2/2 it's at normal. When you restore it it goes back to normal (whether you "fill tanks" or manually swap the engine) and takes up to (1-reusability) times a new engine.

Yes and no. Maybe. It's supposed to, but there's a fairly specific order that you have to follow for it to work correctly but I can't find the post that somebody made explaining it. If I remember correctly, it's to set your desired launch site in the editor when you build, then build it and go about your business, then when you go to roll out the vessel to the pad (maybe only when you press the launch button) you have to go back into the editor and make sure that launchpad is selected. Otherwise everything blows up. It used to work nicely without requiring you to switch the launch site in the editor but a change in Kerbal Konstructs or KSP caused it so it goes nuts if KCT tries to launch at a site that isn't the one selected by KK. That might be fixable, but I haven't looked at it in a long while.

Unfortunately no. Once you recover it has to recalculate all the BP values (since it has no memory of the initial ship once you launch it) using current settings and the parts don't store their BP values at all. Only the overall BP for the ship is cached once calculated. You can freely recalculate at any time though and can cache those values manually in this theoretical integration mod. If it's just based on some "reuse reusability %" that is defined in the integration mod you can just pass that into the BP formula(s) and write the formula to give one value while editing and another value for new builds (or in this case, the recovered build). Let's try a theoretical example. Say you have a part that is 50% reusable and has 2 ignitors by default. So fresh with two ignitors it takes 100% of normal, after one ignition it's at 125%, and after both ignitions it's at 150%. Let's say all parts normally contribute a flat 2000 BP each (definitely not true, but we're making this example easy). So when we recover the vessel we recalculate it as if it were brand new (this might sound wrong, but it'll work out in a moment), so each part contributes 2000 BP no matter the remaining ignitions. Now we edit it and we want ignition replacement to take extra time, simulating refurbishment. Our BP formula then should be 2000 * ((2-[reusability]) - ((1-[reusability])/([maxIgnitors]) * [remainingIgnitors])). With full ignitors it's 1x (or 100%), with one out of two used and 50% reusability it's at 1.25x (meaning the vessel's BP goes up after editing instead of remaining the same), and with both ignitors used it's 1.5x. The integration mod can calculate everything between the parenthesis itself and pass a variable to the formula, then modify the actual BP formula to just be: "2000 * [R]", where R is our calculation. One caveat, R MUST be equal to 1 when we're not editing in order to properly calculate what the BP would be for a new engine, otherwise the time increase doesn't work right. That can maybe be worked around with a more complicated formula, but I can't think of a good way to do it off the top of my head. If the integration mod doesn't want to set [R] to 1 internally (or is only running in the editor scene) then we can utilize if statements and a new variable that KCT will add that I am tentatively going to call E for "editing" (I have yet to check for collisions). So we can set the formula in KCT to "2000 * if([E] == 1 ? [R] : 1)" using the (rather new) "if" command, or the old fashioned way of "2000 * max([E]*[R], 1)" where the max is either R if E is 1 or 1 if E is 0. Except the actual BP formula is more complicated, so the end result would actually be: min([C]/([I] + ([B]*([U]+1))), [C]) * max([E]*[R], 1)

Without yet looking at the log, make sure you've only got one of the .Dlls in the Kerbal Construction Time folder in GameData (and any subfolders of the KCT one). I had that issue myself because I had one of the old builds from Dropbox that didn't use the same name so it didn't get overwritten.

I've posted a poll on Patreon asking what people would like me to focus my development efforts on for the month of April. Normally these will be patron only polls (they're the ones giving me money each month after all), but since my Patreon page is fairly new I'm opening it up to everybody for the month of April. You're welcome to vote on it at the following link, though it might require a Patreon account to vote: https://www.patreon.com/posts/what-should-on-8591938

I've posted a poll on Patreon asking what people would like me to focus my development efforts on for the month of April. Normally these will be patron only polls (they're the ones giving me money each month after all), but since my Patreon page is fairly new I'm opening it up to everybody for the month of April. You're welcome to vote on it at the following link, though it might require a Patreon account to vote: https://www.patreon.com/posts/what-should-on-8591938

I've posted a poll on Patreon asking what people would like me to focus my development efforts on for the month of April. Normally these will be patron only polls (they're the ones giving me money each month after all), but since my Patreon page is fairly new I'm opening it up to everybody for the month of April. You're welcome to vote on it at the following link, though it might require a Patreon account to vote: https://www.patreon.com/posts/what-should-on-8591938

I've posted a poll on Patreon asking what people would like me to focus my development efforts on for the month of April. Normally these will be patron only polls (they're the ones giving me money each month after all), but since my Patreon page is fairly new I'm opening it up to everybody for the month of April. You're welcome to vote on it at the following link, though it might require a Patreon account to vote: https://www.patreon.com/posts/what-should-on-8591938 @cami, here's that (rough) roadmap. Basically, you'd recover a vessel with engines that require ignitors and they wouldn't automatically be replaced while KCT runs a calculation of how much BP the vessel is worth. You edit the craft and press "refill tanks", causing KCT to fire an event saying "hey, I'm refilling tanks and if you want to do anything as well then here's your chance". The "integration" mod sees that event and refills all the ignitors back to their default values (and could optionally spend some funds to do it, if that was desired). KCT recalculates everything and the integration mod uses this chance to add a variable to the KCT formula that's the number of ignitors replaced on each part. Since the integration mod also came with a Preset overriding the standard formula, the variable gets used to make the BP of the edited craft higher, resulting in additional build time. The formula would likely need a bit of trial and error, but the rest is pretty straightforward I think, once KCT gets the "refilling tanks" event added in.

FAR, RemoteTech, and DeadlyReentry are all mods that came before stock implementations and they're all still more or less active, and that's when their features were implemented in a way that is free for everyone, not just a small subset of players. Mod authors have no requirement or responsibility to continue providing updates, with or without the features they provide being added into the Stock game. If there's a need or a strong enough desire for something, someone will step up. And if no one does, then maybe you should be the person to step up. That's how our open source modding community has always been and will hopefully always remain.

You're welcome to try out the development builds from the build server (linked on the first post and right here). You might want to check out the changes by pressing the "Changes" button on the left and then the "githubweb" link on the right to view the entire change message. Sometimes things might break between builds even if the build itself appears fine, but that's pretty unlikely at the moment. I'll usually make a note on this forum thread if I change something that will potentially cause issues (but I don't always know if a change will break things). As for FMRS, that's more for testing StageRecovery (all my mods share this thread for development discussion), but you can find the newest version here:

The way things are set up now there's not an easy way to change the construction time due to refurbishment. An integration mod (really it'd just be a single class, super small) and Preset might actually be easier. I can (probably) write that if I know how you all think it should work. Based on what you've said and on how KCT works, I think adding some extra value on to the EffectivePart formula based on the number of ignitors should work best. If there are no ignitors it should be less time than if there are the "correct" amount (that way when your refurb it the time goes up). I can add in a variable that is 1 if the ship is being edited or 0 if it's original, that way you don't need to rebalance regular builds. I'll also need to provide an event for when the "Refill Tanks" button is pressed. I'll road map it in a bit, but I have to go right now.

Known issue for a long time. It's been there since the beginning. I have an idea of where to fix it, but need to figure out how to use quaternions.

Easily reproduced with just KCT. Probably related to issue #119. I'm guessing the rates just aren't being recalculated at scene start, even though they should be. Hopefully an easy fix. Actually, it's probably related to the change to support CustomBarnKit, since the facility levels aren't fully up to date right at scene change. They'll report 0 for max levels for a little while until it actually loads, and then they'll say the right amount later. It's probably caching the 0 value, since a level 0 VAB only allows two rates. @thunder175 it should be fixed in build #8 from the build server.

You can just increase the number in the settings. It's the third number in a field that should say "15,15,45". In career it's based on how many tech nodes you've unlocked.

Well, editing is still faster than rebuilding, which is the point, and the earlier you do it in the build the less of an effect it has. Either way, at minimum the total time taken has to be the same as for the post-edit vessel as if it were brand new. There's just an added penalty to your current progress based on how big of change your making.Unfortunately science equipment is just really expensive. A formula based on mass (or a combo of mass and cost) would reduce the penalty considerably. KCT2 will likely be adjusted to be at least partially mass based, but cost is good for conveying complexity. Hmm, I think this is one instance of a formula that isn't configurable... @cami I didn't get a chance to get the ignitors working yet, but I did update MagiCore to have an event that gets fired before processing any formulas. So other mods could add in their own variables (but cannot change the formula itself), which opens up the door for integration mods. For instance, a small mod could provide a Preset where ignitors are part of the build time calculations and could fill in those values based on the current ship, without KCT ever actually knowing anything about ignitors. I haven't actually tested it yet, but in theory it should work and means that a mod could completely override KCT's processing of virtually everything with a just Preset and listening to that event.

There are a few reasons for this. If you're running the 1.2.2 dev build then there's no part inventory, which ironically might be a benefit here, so you can't pull things from the inventory to have reduced rates. Since the part tracker is gone too, everything is treated as "fresh" and build times are generally a bit higher than they should be. The second, and probably biggest in this instance, is that the thermometer is pretty pricey. The default formulas use cost as the driver for build times and at 900 funds the thermometer is a big contribution for small and inexpensive ships. The girder you mention is 25 funds, which is tiny in comparison. Build time is roughly "(2000*sqrt(cost)) / rate" in seconds, where cost is just the entire cost of the vessel. Edits are calculated as "progress = BP_old - 1.1*(BP_new - BP_old)" so you're probably losing a good chunk of progress by adding on that thermometer. Looks like your vessel cost about 9500 funds, with a BP of about 195,000. Adding a 900 funds thermometer has a new BP of 204,000 with a difference of 9,000. Your new progress would be 195,000 - 9,900 = 185,100 so you have to make up 18,900 BP (the loss for editing plus the now higher BP due to adding a new part. Consequently removing parts takes less time). At a rate of 0.3 BP/s that gives 63,000 seconds or 3 days. I'm either missing something or something's up. If you have the part inventory (KSP 1.1.3) that will massively complicate those formulas and can very easily make that edit take longer since the thermometer (assuming brand new) would have a much, much higher weighting than the rest of the parts. Here's a reasoning: If you had a plane ready to go and then decided to go back and change up some of the parts, there'd be a whole hell of a lot of paperwork and delays. If you changed it at the beginning of construction it isn't as big of a deal. Here's the actual reason: The BP formulas were created long before the ability to edit the ship, and the end result was reasonable to me.

It was designed for a much older version so things probably have changed. Simulations don't exist in the KSP 1.2.2 version of KCT anymore so I don't intend on fixing it. KRASH is the recommended simulation mod from now on, although I am also working on one called SimuLite (that's turning out a lot less "Lite" than I anticipated). I don't believe KRASH has anything for TestFlight and SimuLite doesn't yet either. SimuLite's got other problems that need fixed before I start looking at other mod support.

I can get any and every module that comes by default. Usually. Getting the information I need off the module isn't always easy when I'm doing it without full references (anything's that calculated off of other info normally [chute area given a diameter for instance] I can't get since I don't have the full module), but the ignition amount should be pretty easy. I can get what's called the AvailablePart and from that I can get a "partPrefab" which I'm pretty sure is the part you get when you click something in the Editor. That Part has all the default values and modules on it, which I can (selectively) copy over to the parts on the actual ship. That's already how refilling the tanks works (since not every resource should be set to the maximum) for stock things. Procedural Parts complicates that, since the Prefab isn't going to be anything like the actual part on the ship (story of my life. Biggest reason I wanted to redo the part inventory) @Errol I can look into that. Should end up being pretty much the same thing.

True, I could just tie it into the "refill tanks" option when editing. That'd be quick and easy since I'd just set it to whatever it was before and wouldn't require refactoring anything. And RealFuels wouldn't need to change anything since I could do that entirely on my side. As of right now that wouldn't incur any sort of cost or change of time, but neither would having it happen automatically on recovery.