cami

I am experiencing strange behavior with the part "Avionics [Procedural]". "Toggle Power" has no actual effect on the part, it still consumes power and it is still functional, even when it is "off" (at least kOS says it is). I am not sure whether that is an intentional behavior change by KSP-RO or RP-1. Is it? Additional Info: I'm using the default upper stage configuration. Procedural Parts 1.3.18 KSP-RO 12.5.0 RP-1 1.00 KSP 1.3.1.1891

So basically one is plain save to disk, the other is more like apply/activate.

I don't think so. Thank you for the hint! That kind of double-save is unusual. I'm not going to test that just yet, as that runway is gone now.

I tried adding a second runway to KSC but now I'm having trouble removing it. removed the instance in the KK editor, it kept reappearing removed the .cfg in GameData\KerbalKonstructs\NewInstances, it kept reappearing removed the Launchsite entry in the .sfs save file, still keeps reappearing I couldn't find where that second runway is still coming from, can you help me get rid of it? KerbalKonstructs 1.3.9.14 KSP_x64 1.3.1.1891 RO 12.5.0 RP-1 1.00

I have a puzzling phenomenon with KCT 1.3.9 (KSP 1.3.1.1891 + RO 12.5.0 + RP-1 1.00) when reusing planes. Because of the runway gap problem, I opted to just launch planes with a small rocket booster (obviously a very kerbal solution!). However, this means I have to reattach the booster. This however drops the reuse percentage to zero (see screenshots). Even just a single decoupler reduces the reuse percentage from 99% to 75%. This is an average complexity plane much bigger than the booster, so I'm quite surprised. Also worth mentioning, I also recovered the booster, then scrapped it for lack of a merge option. What is going on here? Could I tweak the craft or some formula to remedy the situation? https://s11.photobucket.com/user/MoiraLachesis/media/Kerbal/screenshot28_zpsvvvczkle.png.html https://s11.photobucket.com/user/MoiraLachesis/media/Kerbal/screenshot29_zps25icfvmr.png.html

That's a very useful hint, I'll keep that it mind. Thank you very much! In this particular case, it appears that the stock mini chute, when attached to the side of a rockomax tank, partially embeds itself into the tank (that is probably a bug). I pulled it outwards a little and the chutes opened just fine.

Addendum: I found a way for additional intel, and the parachutes arent actually cut, they dont really deploy (the still show up briefly until they realize that, which made me think they were cut). The deployment fails because "parachute is in fairings" which doesn't make any sense, as the craft doesn't have fairings. They are simply attached to the outside of your ordinary cylindrical tank. Is there anything else that triggers this message than actual fairings?

I tried taping some chutes to a booster for fun (the booster "only" reaches 250 m/s). The chutes deploy, but as soon as I detach the booster, the chutes cut. Is that supposed to happen? I don't know what's going on. KSP log doesnt mention anything. Maybe StageRecovery is interfering?

Awesome! You may want to make that a little more pronounced :-)

What is that supposed to mean? Should I use KSP 1.3.1 with MM 3.0.4 or MM 4.0.2, or do both work?

How do I use this? This really needs some better explanation. Tried everything mentioned in that reddit thread: But just nothing happens. EDIT: KSP 1.3.1 with RO, PWings 0.40.13

(retracted)

I know there was a way to show the resource flow/transfer graph in the VAB (possibly using a popular mod like engineer), but I simply can't find any information on how to do that. If you know, can you please provide instructions?

I just wanted to step in and thank you for all the comments. I didn't notice this came with 1.0 as I was mostly using spaceplanes in vanilla at that time and their mass ratio didn't change much (about everything else in the design did, but that was to be expected). I also switched to Realism Overhaul shortly after. Recently my gf started the game in vanilla. 4.5km/s is still found in my old spreadsheets and I remembered using two stages at 2.3 km/s dV, so just like you I was quite surprised these old designs could easily escape the kerbin system.

Sort of, accel is at least g-force minus 1g (depends on attitude and altitude). However I saw 2g force and only about 0.1g accel, which doesn't fit the math. Ok if you have 3.4km/s then this seems to either really have changed, or my memory is wrong. I always used a little less deltaV than most others. :p

Hi there, maybe my memory is tricking me, but I believe deltaV from Kerbin to LKO was about 5 km/s. But somehow I use only 3km/s. Did I mess up with some setting? I also noticed the spacecraft hardly accelerating while the g-meter is at 2g. Ground gravity is 1g, v1 = 2250 m/s. Kerbin radius is 600 km, LKO altitude is 80 km. I only use stock parts, mod list: Kerbal Engineer Environmental Visual Enhancements Docking Port Alignment Indicator PlanetShine ScienceAlert Stock Visual Enhancements Kerbal Alarm Clock Any numbers in the save file / settings files I could check that affect this? Regards, cami

@magico13 Is there any way I could help? Just let me know.

Oh, perfect. I'll see where this goes before proceding, then.

@Red Iron Crown thank you for the feedback. I guess my suspect is at least correct to some extent, then. I'll keep that in mind.

KSP: 1.1.3 Linux 64bit Problem: Distance calculation wrong on vessel recovery When recovering a vessel, distance is calculated to Cape Canaveral (?) instead of my default Launch Site (Kourou). Mods installed: KSCSwitcher v1.0.5956.23563 RealSolarSystem v0.11.4.0 (for launch sites) RealismOverhaul v0.11.2 (for RSS) Reproduction steps: Switch Launch Site to Kourou Restart KSP Launch a vessel Land near KSC (but outside KSC biome) Recover the vessel

I set up some configuration for KRASH with ballpark numbers intended to be more realistic, mostly based on typical personnel cost and electric power usage, assuming that a kerupee is about 1000-2000 USD. I ramped up all per-minute cost by a factor of 50, as you'll likely run a lot less sims-inside-a-sim than you would run sims-in-real-life. There are no per-ton costs, as bigger is not necessarily more complex to simulate, and part costs capture part complexity pretty well. Note that setup costs make up the bulk of costs, as preparing all the data and software pieces for a simulation is much more effort than actually running that simulation. KRASHCustom { RO { description = Somewhat realistic costs with compensation for reduced playtime flatSetupCost = 5 flatPerMinCost = 0.05 perPartSetupCost = 0.3 perPartPerMinCost = 0.001 perTonSetupCost = 0 perTonPerMinCost = 0 percentSetupCost = 9 percentPerMinCost = 0.05 AtmoMultipler = 1.3 TerminateAtSoiWithoutData = True TerminateAtLandWithoutData = True TerminateAtAtmoWithoutData = True ContinueIfNoCash = False } } The results feel quite reasonable for my crafts with RP-0, but I there was no serious attempt at balancing yet.

I would recommend it to be 1 by default, because that's how all KCT presets behave so far, there is no effective cost in replacing a used item with a new one (module some procedural part softening) other than the refuel cost. Short names are nice in formulae, but bad for readability. I just used [R] as a placeholder name like you did, it cannot be [R] anyway as that is already used for research upgrades. Depending on the formula, it could also be a "refurbishment cost multiplier" (100% = rebuild from scratch, 0% = reuse as-is), instead of a "reusability percentage" (0% = rebuild rom scratch, 100% = reuse as-is). In that case, the default value should be 0, of course. Formula should include it in the dry-cost computations, as with most other variables, so that even a perfectly reusable engine can still have some cost for things like hypergolics (TEA/TEB, HTP) refill for its ignitors. There is one thing I noticed in the code though which causes a problem. While procedural part amounts are stored by total value, non-procedural part amounts are stored by item number. I guess this code branching came from pluggin-in procedural parts in a late stage. The RF engines are non-procedural parts, so in order to make this work, I would have to make used engines pretend they are a different part than new engines or alternatively, pretend they are procedural. One way to solve that problem, that would also reduce code at the same time, is that all items be stored by total value. This works fine if the value of a non-procedural part cannot change, and removes quite a bit of code. It also allows to use a single formula for both, to see that, lets take a closer look at a typical procedural part formula: (([c]-[A]) + ([A]*10/max([I],1))) / ... By the way, you probably want this to read like this: (([c]-[A]) + ([A]*10/max([I],10))) / ... otherwise very small inventories (less than 10 √) can have a crazy effect on effective cost. Now that 10 is looking rather arbitrary in that formula, so let's make it a variable, .e.g. inventory variation: (([c]-[A]) + ([A]*[IV]/max([I],[IV]))) / ... Basically, IV defines the smallest inventory that gives you some benefit in building the part. In case of non-procedural parts, you can just set this to 0, and ... ok ok you cant, but you can set it to a vary small value, say 1e-10, and it will just reduce to [c] - [A], which will again reduce to 0 when the part is not procedural (and in an improved formula: fully reusable). I can bring reusability in here easily with some assumption that if a part is in your inventory, it has already flown and depleted its ignitions: (([c]-[A]) + ([A]*[IV]/max([I]*[R],[IV]))) / ... Alternatively, I could modify [c] based on the number of remaining ignitions and reusability, which however would allow you to trade two half-used engines for one unused engine. The other way to solve that problem is to have multiple inventories. This would go a similar way to how TweakScale is integrated, likely in a less hard-coded version. For instance, you could allow other mods to add variables that should be considered when separating inventories, instead of hardcoding the part name and TweakScale size. I'd then just track Parts like Merlin1C[ignitions=1] an Merlin1C[ignitions=0] in different inventories, with different part values going into effective cost formulae. That'd need a way to link both in some way telling KCT "you can use Merlin1C[ignitions=0] in place of a Merlin1C[ignitions=1], but at some additional cost". I need to leave now, so I'll have t leave this idea for a later post, but Ill have to think about a simple way to make this work anyway.

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: Listen to the new event and add a new variable [R]. [R] = 1 means as good as new, [R] = 0 means it's scrap. 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.

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: I dont edit the craft at all. I get 1000 BP cost but the engine is still unusable 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.

It's unrelated to part failures. There is just one aerobee, and it's on the spin axis. The other two motors are SF separation motors.