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!

How is this not a major change to the game engine? Right now there are exactly two types of bodies in KSP: - The active craft and anything within load distance of it, which get force-based physics treatment - "On-rails" orbital objects, which all obey Kepler's 2-body patched conic approximation Neither of those objects could be used; you are not proposing a quick hack, but a significant development effort. Just because you can partially describe the desired behaviour of a new type of object in one sentence doesn't make it easy to implement. For instance, your "distance and angle offset" - I know what you mean of course, in visual terms looking down at the Kerbol system. But the solver doesn't work that way. The rule "keep this object at the same angle around the sun as Kerbin, but at this distance" doesn't translate well into parameters like semi-major axis, eccentricity, and time since epoch. Whenever we users come up with a super-simple idea like "Can't we just <x>?", you can be pretty sure that we didn't just solve some big challenge in a new, easy way the devs never thought of. You can be pretty sure the idea only seems easy because we have no idea what we're talking about and we aren't seeing all the problems with "just" doing that.

It could be altered, of course. Anything's possible with code. My point is, it would not be trivial as the OP suggests. It would mean building a total hack job on top of an existing, elegant solver, to allow it to break its own rules. It would introduce bugs. It would be more difficult than writing a new n-body solver from scratch - building that is actually fairly easy, it's just that running it is computationally expensive. My point is, it's a lot of work that just isn't worth it.

Are you sure, sal_vager? The "on-rails" solver in KSP puts objects on rails, alright - Keplerian rails. Here is how you specify an object's orbit in KSP: ORBIT { SMA = 76875.4600066045 ECC = 0.136808532664149 INC = 32.6082297441138 LPE = 91.4665699628126 LAN = 305.802690796769 MNA = 0.556028537338098 EPH = 19189976.1161395 REF = 3 OBJ = 0 } There is no combination of those parameters that says: "Put this thing in circular Kerbol orbit, 100M meters inside Kerbin's orbit but with the same orbital period". If you want the same period and a circular orbit, then the radius must be equal to Kerbin's. If you want a different radius and circular, then the period must change. You could set up L1 to be in retrograde Kerbin orbit with a period of exactly 1 year, and that would give you an object that stays on the line between Kerbin and Kerbol, appearing to orbit Kerbol inside Kerbin's radius. But it could only do so at a fixed orbital radius - the one corresponding to 1y period. This would, by definition, NOT be the same position as the true L1 point - it would be closer to Kerbin, since Kerbol's gravity is not being taken into account. To have "on rails" lagrange points "always be in the right place", you would first need to build an entirely new set of rails. That's my point.

One difficulty that hasn't been addressed here is how to keep the fake-Lagrange-point body in the right spot. If you just set up a body using the current orbital mechanics system, it will have a certain relationship between the size of its orbit (Semi-major axis) and its orbital period. This relationship is based on 2-body physics: "fake Lagrange" SoIs would orbit their parent body just like any other planets/moons. There is no Keplerian orbit around either Kerbin or Kerbol that will keep L1, L2, or L3 at the correct position: put it at the right position and its period will be wrong, give it the right period and its position will be wrong. The properties of Lagrange points come from n-body dynamics, where n is greater than or equal to 3. Adding lagrange points isn't as simple as just adding another 2-body SoI. You would need to write a whole new subsystem in the orbital mechanics solver that keeps the lagrange points in the right spot. Writing a system that fakes 3-body positioning inside a 2-body solver would actually be more complicated than writing an n-body solver. Lagrange points: No matter how often they get discussed, they still don't work in KSP and they're still not worth implementing.

TUFOM, your stage 0 is different than the challenge rules. Check the other designs - it must be just the probe core, mechjeb, and the decoupler. Stage 0 has 0 delta-V, you only get 5 "real" stages to play with. tavert, what does the on-paper 37km/s design look like in terms of # / type of engines? Does it use Aerospikes? Even if the 48-7S is theoretically more efficient, I found 1xaero to be more practical than 16x 48-7S in terms of actually building something that flies. Hopefully 0.23 will correct some of the issues in the VAB. Right now, building rockets this large is a challenge unto itself.

I gotta give up on this one too. I've got a design that should be able to top Tavert's dV.... but I can't even get MechJeb to calculate its dV in the VAB due to bugginess. Not structural problems, mind: straight up bugs in the VAB editor that corrupt the craft. I can get 1/6th of it to build and calculate correctly. All I do between the 1st and following images is pick up the inner radial separator and switch to 6x symmetry. If it worked, it would be the biggest thing I've ever built: 12x Giant boosters with 13x Aerospike 6x In-Line sustainers with 49x 48-7S 6x Orange drop tanks for nuke engine 1x Orange nuke sustainer 1x 48-7S final payload stage Details below.

Done, thanks. Blind C&P from clicking on my album, didn't realize "#0" wasn't part of the base URL.

Here's my entry. Riding the mass vs Delta-V curve way up past the point of diminishing returns, I give you this behemoth: 271 parts 469.17 tons 24840 delta-V 0.10 min TWR The design uses 4-way asparagus on the LV-N orbital stage for the bulk of the delta-V, a central sustainer booster using a TON of those overpowered 48-7S engines, and 4 crossfed first-stage boosters using aerospikes for high-ISP TWR during the early launch. Although the engines are definitely overlapping visually, part clipping was not used. I think it's a combination of the collider mesh for the 48-7S being smaller than the model, and part attachment being pretty buggy in general.

I voted for sgt_flyer's craft. Almost all the finalists were very good craft, but to me sgt_flyer's is the best improvement on the Kerbal X because it remains true to the basic style: large central core booster with small asparagus boosters and a stacked 3rd stage. Delta-IV designs are cool, but that's not the motif the Kerbal X was using. I'm a bit disappointed that sgt_flyer's craft isn't Mun-landing capable - if any of the Kerbal-X-alike Mun landing entrie had made it to the finals, they would have my vote. In my opinion, calling something an improvement on a stock craft means it should do one of two things: take the basic size and building style used by the stock craft and extend it to accomplish a broader mission, or take the basic mission accomplished by the stock craft and do the same thing more efficiently. Either is good, but if you change both the style and the mission you're out of the "improvement" zone and into "build a new craft to do... stuff!" territory. Since this challenge was pretty vague, I picked option A for both my submission and my voting.

(emphasis mine) I think the problem is the "maybe". A Munar orbiter is a very different mission than a munar lander. Doing either with 3 Kerbals is a very different mission than doing it with 1 Kerbal. Doing it with direct ascent is very different than doing it with an Apollo-style Lunar orbit rendez-vous. All of the things I just mentioned have representative entries in this challenge, when they're really not the same class of mission. We're largely debating philosophy and personal preference because there's no objective way to call a 3-man direct ascent Mun lander "better" than a 1-man Munar orbiter. The rockets aren't even comparable on objective terms, so we have to be totally subjective. And/or just game the voting system and never bother to leave Kerbin orbit.