NeilC

According to one of the lovely devs on #RSS(Pap, I think?), RemoteTech "Coverage" is currently buggy and not working as intended. It may be that you've set up everything correctly, and it still won't work. I had the same problem with the 4-sat network and 3 dishes+omnis on each sat. Each had 2 dishes pointed at neighbours, 1 dish at Earth. This should have done the trick, but my coverage never went above 20%. Alt-F12 was my friend. I force-completed the contract and moved on with my space program.

Actually, in my opinion 1.3 did add something groundbreaking: the ground literally stopped being broken. With the added precision issues that playing at RSS scale brings, I find that the SPH runway is totally unusable in 1.2.2. Better to roll off onto the grass, and that still breaks my planes half the time for no good reason. Until RSS/RP-0 get 1.3 support, I find planes are not a worthwhile option. So I, for one, hope that this two-version thing ends ASAP!

@magico13: Oh wow, thanks for the detailed response! I didn't realize I could get 0.8 throughput with 2 lines, I'll have to give that a try. The trouble with launching my small thing first is that the big thing includes the lifter.... maybe I can rearrange and do the small+lifter, and launch that while parallel building my in-situ refueler payload. I have a bigger & better refueler design too, so maybe by going parallel I can squeeze that in. Good to hear that the presets are so customizable, that's really cool! This challenge has really got me back into KSP, and I love what KCT brings to the table. I'll have to create a custom preset for the next career I play, and I'll be sure to share it if I do. Great mod, Magico13! I'm loving it!

TL;DR: This is a public service announcement. When building with KCT, do only one build per launch window and then recover and rebuild the individual payloads! It works out to less build time, because reasons! I'm really liking the build time aspect that KCT adds, and playing around to optimize it. However, the way it calculates build time from cost seems to be very strange. I was getting a bit frustrated when I started combining payloads I'd designed separately, because the times didn't come out how I expected. Then I watched an early showcase video by Magico13, where he mentioned that build time is related to the square root of cost, not any kind of linear function. For example, my re-usable lifter is very simple - Delta-IV style design, with each booster being an orange tank and a skipper, plus parachutes. When I build this subassembly on its own, it takes 105 days. However, when I add it to one giant craft containing all my payloads, it only adds 36 days to the build time. Incidentally, the tiny hex strut I had to place first in order to add my subassembly took 2 days on its own, but only added 5 minutes to the build time of the finished craft. This leads to some.... perverse incentives, shall we say? Namely, this monstrosity. Build time 173d. Rollout 26d. Separate on the pad, recover the dangling payload, and fly the prime payload. Rebuilding the separated payload plus recovered lifter parts takes 28 days, then another 26d rollout. Total: 253d. That's in time for a 1,100dV transfer. Building this as 2 separate assemblies would take 151 days for the first launch + 81 days for the dangling payload + 2x26d rollout = 284d. That's a 1400dV transfer. Incidentally, I tried recovering the dangling payload as an entire craft using KCT, instead of the normal recover button. It took 26d to refurbish, and then 5 more to add on the lifter. So.... it's actually faster to break it all down and rebuild it from parts? I think maybe that system is not working as designed? @magico13, are you still watching this thread? Any more tips on how to optimize builds for KCT? Or is this more of a balance issue than a valid strategy in your opinion?

Perfectly clear now, thanks!

I'm still working through various design concepts, having tons of fun. I'm pretty sure I will ditch the refuel-on-Duna concept above since it doesn't scale well - it's actually only 2t of fuel, vs 0.75t of drilling equipment + a whole bunch of added cost. I also did a trial landing and didn't happen to strike Ore, stranding me on the surface... not worth the risk. DE, can you clarify the OP regarding module re-use? I seem to recall reading a clarification somewhere in this thread, but I wasn't able to find it again.Specifically: - There are prestige points for orbiting SCIENCE LABs around Duna & Ike. Must these be separate LABs, or can I re-use the same LAB hardware? -If I can re-use, what are the orbit rules? Would this LAB flight plan achieve both goals: Aerobrake into Duna capture, orbit once, Ike intercept and burn to capture around Ike. What if I didn't complete a full orbit before the next SOI, eg Duna aerocapture into Ike intercept without a full orbit around Duna? -Similarly, there are points for orbiting SHUTTLEs around Duna/Ike. Can I meet both requirements with 1 shuttle? What if I take 3 shuttles - do I get 3x the points, one for each shuttle? - There are prestige points for HAB landings in all 5 biomes. Must these be separate HABs, or can I liftoff/rove and re-use the same HAB to capture all 5 (or 10) biomes? More pics soon!

It's a 0.625m nuclear reactor, provides 30/sec charge from a very tiny amount of enriched uranium. Low mass, but very high cost - 3,220 for the reactor, and I have the converter filled with 0.4/2.0 units to get the fuel cost down from 1700ish to only a couple hundred. It's about the same, in weight and cost and power generation, as 20 3x2 solar panels. There's also a radial ore tank on there that's about 0.625m. The resource converter is actually part of the Comm lab, the yellow box opposite side of the hab module and not shown very well in my pics. This is the module that feels a bit overpowered - it's a science lab, it's an antenna, and it's an ore->fuel/ox/monoprop converter, and it weighs 0.75t. Granted it's very inefficient, power hungry and a total pig on Ore - 5.5 ore for about 1 unit LF/O. But just the fact that it converts at all means I can launch this dry and fill after landing, saving 2t launch mass and thus a bunch of Tsiolkovsky cost.

DE, thanks so much for resurrecting this challenge! My Duna InSitu mission for the original was the most fun I've had with KSP by far. I actually haven't played much for a year or so, and both KSP and its mods have come a long way since then. I'm looking forward to this, should be a blast. I'm developing a mission using the latest versions of USI Life Support, KCT, and Stage Recovery. After looking through RoverDude's impressive mod collection I've also decided to install the Exploration Pack and MKS Lite. I've started planning the first transfer window to get the early prestige points, and I'd like your opinion on this Duna lander/ascent vehicle with respect to balance. You've specified no "cheaty" mods - do you think this design with the MKS Lite/Exploration combination gives an unfair advantage? I haven't tested this design at all, but with minor tweaks I think the concept will survive landing. It meets the letter of your "KERBAL HAB" definition: once expanded it can hold 7 kerbals, has an antenna and power generation, and has a mod science lab. However, it can only support 3 on descent - is that an issue? For the 2nd and 3rd transfer windows I think I will shuttle kerbals LDO-> HABs and back in an SSTO spaceplane, refueled on the ground. Still very much a work in progress, but before I go any further on this concept I wanted to get some feedback on what these mods seem to be letting me get away with. 6.5t dry launch mass and 38.5k cost just feels... low... for a Duna hab that can also do in-situ refueling. What do you think, DE? Jasonden, DBowman, Enginerdy - how does this compare to what you guys were flying? Note that I'm using the higher supply consumption from latest USI life support too, so our missions won't be strictly comparable no matter what. Tanks are full to show delta-v of ascent stage, should be capable of rendezvous with plane change to anything in LDO without trouble. Tanks are dry, so this shows the intended 6.5t launch/landing mass. HAB is ready to start refilling them with the ore drill / Comm-Lab converter combo. Powered by the 0.625m nuke reactor and cooled by a hilariously large radiator panel. I don't think I truly need this much cooling, but it will let me refine at full speed and the 0.25t weight balanced the drill perfectly. **EDIT: I honestly have no idea what's going on with imgur albums /KSP forums right now... I've created an album and set it public. It's at https://imgur.com/a/c0WTZ and I hit the "i" in the top right and entered c0WTZ... and it's broken. Reverted to image links instead. If anyone can help, much appreciated.

Are you making any course corrections to stay in orbit? My intuition is that if you drifted that far from the equilibrium point, you'd fall towards either Mun or Kerbin instead of continuing to orbit L4 for as long as you did. Or maybe my intuition is just way off because everything Kerbal is much denser and closer than it is on this side of the screen. How wide and deep is the L4 potential well, anyway? Yeah, that! This would change as the track is plotted though, right? Easy to show instantaneously, but it wouldn't help understand the overall track shape. Maybe you could allow selection of points on the track and draw phantom bodies and potential wells for the selected point? Maybe more trouble than it's worth?

Thanks for the update and the screenshots, eggrobin! I'm having trouble visualizing what you call the barycentric rotating reference frame. Your pics 6 and 7 show the same trajectory in the usual Kerbin-centric and the rotating-barycentric, correct? I understand your co-ordinate system has the origin at the barycentre, and if I'm parsing your description correctly its axes are always aligned with the kerbin-mun connection line, but I'm having trouble figuring out why that would generate the track shown. I can see the trip out to the Mun being tough to visualize since the relative velocity in that frame would be changing throughout the track, but I must be missing something fundamental because I really lose comprehension when the orbits about the L-point come into play. Once you're near L4, shouldn't your position be (nearly) fixed in the barycentric frame? Isn't L4 fixed in a frame that's centered on the barycenter and rotating at the same rate as the Mun? Those tracks look like the craft is wandering within ~1/16th of an orbit of L4, which seems huge. What am I missing? Is there any insight that comes from looking at the trajectory in this frame? If so, do you think it would help to illustrate the motion of the co-ordinate system in the track plot somehow? I hope your exams went well! - - - Updated - - - Thanks so much for this link, very cool read. The concept of a universal, geometric math that's taught early and often really appeals to me. Whenever I try to wrap my head around quantum mechanics I just get totally bogged down in obscure, specific notations and math that doesn't seem to have any physical interpretation. Made me drop out of the physics minor in undergrad and choose robotics instead. At least I could visualize the quaternions in forward and inverse kinematics!

Thanks so much, that nailed it for me. I get why that would be really important for co-ordinate transforms. We engineers get SUPER lazy with the things you call "Pseudovectors". Gear trains with parallel axes don't really lend themselves to learning about co-ordinate transforms... I'd just represent angular momentum as a scalar in all my calculations, and then do a manual balance pass at the end if anything was spinning in a different direction. I'm rarely asked to design a gear train as seen through a mirror. That lazy approach leads to passing our exams with study bandwidth left over for metallurgy and thermodynamics and such, but we never learn those formalisms. Cool stuff!

Heh, nope I'm afraid I don't recognize any of those terms. Closest I could come was "Wedge product... that must be kind of like a general cross product?" I'm afraid my brain gets firmly locked into 3D geometry, as a mechanical engineer I've never studied these concepts in a general way - 4D applications don't come up very often in our courses. Thanks for the paper suggestion though, I'll check it out. Neat, I was afraid perturbations from the Mun would be significant enough to lower a ~100km periapsis below 70km within, say, a round-trip trip to Duna. Glad to hear it isn't so! Right, of course, the "conics" part of patched conics - sorry, momentary brain fart. I guess what I was thinking of improving was the "patching" part of patched conics where KSP is just terrible at predicting intercepts, periapsis after frame change, etc. That would be the gameplay value: say, being able to reliably predict a mid-course correction burn to set up a Duna aerobrake before entering its SoI. But you're right: that's just numerics, not integration. No overlap with your project, poor suggestion... Wow, that is a whole mess of crazy. Left-handed co-ordinate frames seem to abound in computer graphics applications, but I'll never understand why... For sure, totally fair! But since this is the first thread I've seen approaching an n-body solver for KSP with anywhere near this rigor, I have plenty of reason to want it to become stock! Didn't mean to assume anything about your motivations, just thought I'd ask the question. Thanks for answering. Good luck on your exams! May the coffee and skittles be with you.

First off, eggrobin this is a fantastic thread! Good work! I really appreciate the effort you put into your explanation documents and your extensive references. I'm one of those engineers with funny conventions so I can't pretend to follow your Grassmann algebra, but I know enough about RK solvers to follow most of the papers cited in broad strokes. This thread taught me a lot. Kudos, I'm looking forward to seeing this project develop. I'm pretty sure this is an issue with the setup of orbital parameters in KSP, not a fundamental issue. If you changed the parameters a bit, it's definitely possible to set up a Jool system that would be stable for hundreds of years. Jupiter's moons really are in a 1:2:4 resonance, and I think the universe's symplectic n-body integrator is almost as accurate as eggrobin's. I think things only go haywire in the Jool nbody video because the orbital parameters used are the ones in stock KSP that produce a "resonance" in the 2-body solution - that is, they are set up to have 1:2:4 orbital periods around jool using the 2-body assumption, without taking the interactions between moons into account. Of course this would be unstable when you suddenly add in the interactions! They need initial orbits that give them a 1:2:4 period AFTER taking n-body perturbations into account. (As an aside, it would be interesting to see how far off the initial conditions could be and still have the moons correct themselves. The resonance must be a low-energy state compared to the surrounding parameter space, otherwise Jupiter's system would never have settled there. That implies there's a basin in which the initial conditions can lie, and still evolve to the same final orbits) Though I don't think N-body gravity would significantly affect any planetary orbits in terms of gameplay, I do worry that making low orbits unstable would make the game less fun. I know stationkeeping is a planned feature, but that's a whole layer of complicated code that needs to be written to make Principia playable without untenable levels of orbit management. Trouble is, the N-body solver is kinda an all-or-nothing deal: Correct me if I'm wrong, but it's not just Lagrange points that would break: you can't have some stuff on Keplerian rails and other stuff following a path defined by conservation of energy: the Kepler bodies would break that conservation and things would go screwy. The whole Principia solver is based on symplecticity. Making it 2-body isn't "set n=2", it's "ground-up rewrite". Eggrobin, do you see any value in using the libraries you've developed to implement an improved Kepler integrator with the same interfaces as Principia? Is that a lot of work? I'm just thinking it might help you (somewhat) as you develop the annoying and untestable part of your code that interacts with the KSP API, to have a built-in test case: you'd be solving the same case as KSP, so could check your answers against it each frame. Should be within a small tolerance, otherwise something screwed up (probably a reference frame transform which I gather are kinda obtuse in KSP). Also, you would then have a much-improved integrator that doesn't affect gameplay at all, which would allow a playable Principia(Lite) before you've had a chance to develop stationkeeping. And would be much more likely to get integrated into stock KSP, which would be super cool. One last thing: I just finished reading The Martian, and I really really want to play this plugin so I can build an Ion-engine Mars transfer vehicle like Hermes. SOOOOOOO cool!

I think the funds mechanic is a good one, but currently its one-size-fits-all nature means it can't suit everyone's experience level and play style. Meaning, I believe it has been balanced for new players who take a very "Kerbal" approach to launch count and kerbonaut safety: improve designs by watching old ones blow up, and kill a kerbal every time it does. Designing the Contracts system to allow this playstyle means that funds and reputation are very easy to manage, and experienced players who revert to VAB every time they hit a staging problem will not find them to be limiting factors at any point in their Career. I suggest adding three difficulty levels to balance funds & reputation for different playstyles: "Jebediah Kerman" - What we have now. Contract rewards and advances are high, prestige hits for dead kerbals are low, running out of money is difficult. "Launch ALL THE THINGS, kill ALL THE KERBALS!" "Gene Kerman" - Contract advances and rewards are reduced significantly. Advances should be based on 0.5x-1x the cost of the minimal craft required to complete the task. Rewards should be ~2x this amount. Idea is that the advance barely (or does not) cover the cost of the mission - you must complete contracts to build a bank and invest that bank into completing future contracts. Design too big a mission or flub a couple launches and you should not be able to complete the contract due to lack of funds, unless you have slowly built up a large enough bank. Losing a kerbal should be a very large prestige hit, limiting your contract selection. "Iron Kerman" - Contract advances as in "Gene Kerman", with slightly reduced rewards for completion. Prestige hit for lost kerbals is larger than "Gene Kerman". Reverting to launch/VAB is disabled - every launch counts.

I really like this idea! So much so that I suggested it 6 months ago. Please take a read of my previous post proposing Engineering Experience Points, and let me know what you think of the ideas we fleshed out there!