[1.4.1] Kerbal Construction Time 1.4.0.69 (2018-03-24) - Unrapid Planned Assembly

[magico13]

1 minute ago, cami said:

One generic way could be to make ignitions behave like fuel

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.

[Errol]

I would just like to say that I went and created a Patreon Account just so I could back you for this mod. I consider it to be absolutely essential. 

Just to add to this conversation, there is a currently working version of engine igniter for the stock parts and resources which can be found here:
 

I'm not entirely sure what would be involved to make it compatible with KCT, but would like to vote that it at least be looked at. 

[cami]

27 minutes ago, magico13 said:

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.

Oh, I didn't know you have access to that kind of information. Do you somehow extract that from the part's prototype?

[magico13]

9 minutes ago, cami said:

Oh, I didn't know you have access to that kind of information. Do you somehow extract that from the part's prototype?

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.

Edited March 23, 2017 by magico13

[cami]

Great, that would be a cool feature.

A completely unrelated thing: the "disable part failures" button doesn't seem to do anything for me. If it does, then likely increase failure rates instead. Im using Testflight 1.7

[magico13]

17 minutes ago, cami said:

A completely unrelated thing: the "disable part failures" button doesn't seem to do anything for me. If it does, then likely increase failure rates instead. Im using Testflight 1.7

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.

Edited March 23, 2017 by magico13

[SkyKaptn]

New to this mod (today) and enjoying the concept very much. I was wondering a bit if the edit-times are a bit high for the vessels in one's storage? My tiny 25 part plane took some 30 days at 0.3 BP/s, which is fine. But when I was going to edit a single thermometer to it, it took a whopping 9 days to complete. This cannot possibly be the intention? 

- I realize that things in KCT can be tweaked a lot, but the default setting seems a bit harsh for editing a simple little low tech thing.

[Rodhern]

7 minutes ago, SkyKaptn said:

... it took a whopping 9 days to complete. This cannot possibly be the intention?

Some times KCT can get a bit fidgety with the edits. Try to cancel the edit and try it again (before committing), the editor probably misread your intentions.

[SkyKaptn]

29 minutes ago, Rodhern said:

Some times KCT can get a bit fidgety with the edits. Try to cancel the edit and try it again (before committing), the editor probably misread your intentions.

I tried this now. Several times and still 9 days to complete. It would seem as KCT regards the thermometer as something really advanced. In comparison, a modular girder takes just 7 hrs to edit onto the (already existing, 100% finished) plane.

[Rodhern]

1 minute ago, SkyKaptn said:

I tried this now. Several times and still 9 days to complete. It would seem as KCT regards the thermometer as something really advanced. In comparison, a modular girder takes just 7 hrs to edit onto the (already existing, 100% finished) plane.

Ohh, ok. Thank you for trying it. Guess the thermometer is really advanced then. :-)

[storm6436]

15 hours ago, magico13 said:

How midwest are we talking? I live in Ohio, but spent two years in Illinois working on a Masters, so I'm already somewhat midwest  I'm still trying to figure out where I'm gonna go for the solar eclipse this year and am thinking southern Illinois so I can visit some friends on the way there who are still working on their PhDs at the school I went to.

Hah, IL side of St. Louis.  I will say this much, it's weird going back to college in your 30s.  Partially because it feels like you're in a room full of kids, partially because of the perspective difference between you, your fellow students, and your profs... and partially because of the feeling of missed opportunity, both prior for not doing this earlier... and future as going after a PhD would mean I'd be damn near 50 before I managed the degree.  I guess I shouldn't grumble too much though... I wouldn't change anything I've done if given the chance to do it over again.  I just wish there was more time.

[magico13]

32 minutes ago, SkyKaptn said:

I tried this now. Several times and still 9 days to complete. It would seem as KCT regards the thermometer as something really advanced. In comparison, a modular girder takes just 7 hrs to edit onto the (already existing, 100% finished) plane.

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.

[SkyKaptn]

21 minutes ago, magico13 said:

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

I guess I can live with that role-playing aspect and just gotta be more careful when building and not forget anything. Thanks for the explanation of the formula Maybe in the future there could be a optional discount of sorts for editing only?

Edit: 1.2.2 with the very latest dev build and the cost of the plane is 9600 (from memory)

Edited March 23, 2017 by SkyKaptn

[magico13]

3 hours ago, SkyKaptn said:

Maybe in the future there could be a optional discount of sorts for editing only?

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.

Edited March 24, 2017 by magico13

[cami]

On 23.3.2017 at 5:15 PM, magico13 said:

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.

One more thing: could refurbishing the engines come with an increase in construction time, like with adding spare chutes? I have no idea how much, I've also asked in the RF thread what would make sense. Most of the engines with limited ignitions were never designed for reuse, so a quick estimate could be assuming they need to be rebuild completely. There are exceptions, however, a famous example being the SpaceX Merlin 1B-1D which can only start once but ideally just needs a TEB/TEA refuel before reuse. TEB/TEA tank modules are already in the KSP parts so these kind of engines already work the way they should in KCT.

Edit: Whoops, I overlooked your last post. I guess I'll make a thread for that integration mod, if you can help me get it going I might have a take on it.

Edited March 27, 2017 by cami

[magico13]

1 hour ago, cami said:

One more thing...

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.

[magico13]

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.

Edited March 28, 2017 by magico13

[cami]

My current idea is to assign each engine part a reusability percentage, based on whether it was designed for reuse or disposal. It could initially be as crude as 100% if ignitions are infinite and 0% otherwise. Ideally, I'd like to make the part value decrease linearly towards reusability% of what it was as ignitions go down (so that no matter how you recover, the penalty is there). I don't know if thats even possible, though. I might just add the value difference to the costs upon refill.

For BP calculation, I think I'd just go "reuse reusability% and rebuild the rest", so essentially it is a percentage of the initial build points of the part. Do I have access to this initial number of build points? I've never tried anything similar before. Tweaking reusability% would then tweak both costs and BP simultaneously. Seems good enough, maybe it's oversimplifying? This only applies to "ignitions", TEA/TEB refill is another matter that I'd just leave up to the ordinary tank refill.

Edited March 28, 2017 by cami

[magico13]

On 3/28/2017 at 5:48 AM, cami said:

Do I have access to this initial number of build points?

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)
	

Edited March 29, 2017 by magico13

[VShadow]

Hi really sorry if this has been said somewhere (but 112 pages is a lot to go through) does this work with Kerbal Konstructs/ Kerbin -side?

[magico13]

48 minutes ago, VShadow said:

Hi really sorry if this has been said somewhere (but 112 pages is a lot to go through) does this work with Kerbal Konstructs/ Kerbin -side?

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.

[cami]

1 hour ago, magico13 said:

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.

I  think thats upside down. On recovery you calculate the engine was originally 2000 BP when it was new. Then you subtract 2000 BP from whatever it becomes after editing. This cannot possibly work correctly, no matter what value I calculate during editing. Lets assume I go with your figures and beef up the BP to 3000 when detecting that ignitions are 0/2. Consider the following two scenarios:

1. I dont edit the craft at all. I get 1000 BP cost but the engine is still unusable
2. I rip the engine off the craft and add a new one. I get 0 BP and have instant refurbishment.

Note that scenario 2 is completely independent of whatever formula I come up with for the case of reduced ignitions. The problem is that the recovered craft is considered "new", which it isn't. I'd need away to make the recovered engine worth less than 2000 BP, so when it is replaced by a really new one, there is a BP cost.

[magico13]

@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.

Edited March 29, 2017 by magico13
I apparently can't decide on how to spell reusability

[cami]

Theres another thing, I have no idea what all the single-letter variables mean. In my default preset, there is:

EffectivePartFormula = min([c]/([I] + ([B]*([U]+1))), [c])*[MV]*[PV]

It looks like your version, but where I expected to find [E], there is [MV]*[PV].

So, to be done:

1. Listen to the new event and add a new variable [R]. [R] = 1 means as good as new, [R] = 0 means it's scrap.
2. Put a .cfg with a KCT_Preset {...} somewhere that replaces the formula.

To be frank, the meaning of [R] is so general that I would prefer to only modify its value, rather than introducing it myself and replacing the formula.

[magico13]

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).