Cunjo Carl

So my little one and I were playing with legos the other day, and I somehow managed a Sojourner! Here's the same little rover after he made some creative contributions. Also, ♩♯ Oh Canadarm! ♬♩ (Re @DoctorDavinci) SO. Sciencey toys. What sorts do you have lying around?

All good people of humanity appreciate the Geneva Convention. Sadly so do all good termites of termitity.

@IncongruousGoat The CS/.NET RTE just finished downloading, and hopefully I can give it a shot tonight! Would you like to send me any pictures or things to put in topic? Now I finally got a moment to rearrange the topic, I think it's fine as is, just if you want.

@Ultimate Steve If you want to keep going in vein with the rocket designs, you can always stage or see how _fast_ you can make it to the 10km mark?

@IncongruousGoat Fixed! I'm looking forward to checking it out, by the way. Good luck, and sorry you had to fight with portability issues; those are never fun.

Staging Optimally A spreadsheet planner and conversation place. We've all been there. After all the hours building a launcher to put X tons in obit, you want to make sure that payload can do just as much as kerbally possible! But it's hard to know exactly how many stages to put in the thing, and how large to make each. If your stages are too small, you're wasting deltaV pushing around extra decouplers and engines, but if your stages are too big, you're wasting deltaV pushing around empty fuel tanks! So where's the magic happy balance inbetween? Now you can find out*! *Software provider does not assume liability for engineers trying to saw engines in half to achieve "The most optimum ratio!!" At the moment, there are 2 programs which can find the optimum relative sizes of stages for your rocket: One option is @IncongruousGoat's C# & .NET automatic version available here: Github Link! It'll suggest engines for you: The other option is a GoogleDoc spreadsheet program, which you can also use as a planner. More info on that follows: Instructions: 1. Open the doc, and make your own sheet by clicking the "down" arrow by the "Template" tab at the bottom, and click the duplicate button. Rename your sheet and you're set to play around! 2. Write in the names of each stage your rocket will have, and the TWR they'll need as well as their engine specs (see the ksp wiki for a quick reference). 3. Then for the stage's scale, type in a guess of 1 (scale is just a convenient measure of size). Down below you'll see a huge field full of information for how changing this scale for each stage will change the final rocket's efficiency. Simply make the best changes, and soon enough you'll have the very optimum of rockets! Notes: The template has a rocket already loaded in so you have something to work from. Here's a picture! The underlying math doesn't care how big your rocket is, or what order the stages are in, but if you give it your payload mass and stage order, it'll read out how big each stage should be and how many engines it should have. The optimum efficiency tends to be fairly broad, so there's typically plenty of wiggle room to choose a slightly-sub-optimal scale to get a whole number of engines. You can also tweak the TWR requirements if you really want to see a whole number of engines at an optimum . IRL just round the sucker It handles asparagus staging and drop tanks, because I figure'd it'd be fun! It doesn't handle weird fuel tanks that don't have a 1/9 ratio, but I can add that in if it's desired? This system does scoot mass around between stages to let more efficient stages cover for less efficient ones. You'll notice if you have a particularly inefficient engine (thud), the optimizer will tell you the most efficient scale for that stage is so small it has a negative deltaV. This means that it would be better deltaV-wise to not even give those engines fuel tanks... that's sad, thud. Sorry. Whatever, I'm using them anyway! If you don't want to optimize a certain stage, you don't need to. The solver will optimize all the rest around it. Final Thoughts: Please let me know if it winds up being confusing in any way. I'd like to make it convenient and intuitive, but I have a peculiar design aesthetic by nature. I encourage community additions and am happy to share the math behind the calculator. There's also ongoing development thread for the underlying math here, and I'll be making a tutorial thread on how the system works in a few weeks. Huge thanks to co-conspirators @Abastro and @IncongruousGoat who helped with the math development! If this stuff happens to be your jam, please kick them a like in posts here and here. Thanks! Oh, once again, I'm flagging the good banana mod banana @Vanamonde in case another board is better. I'm planning to make a separate tutorial thread for the actual how-to stuff, but if tutorials is the best place, I can always roll the two threads into one? In any case, let's see where we end up. Brace for warp drive!

@FancyMouse Er, I believe @Abastro was actually referring to my n-variable unbounded case not having a bunch of local maxima is hard to prove. Edit: Missed Abastro's reply, n/m! Fortunately, it seems to have only one max with some beautiful tapering near it in all directions. Solver central! Hey! Speaking of which, the new spreadsheet optimizer is up. Link I'm planning on beautifying and triple checking it Sunday (perhaps Sat) before posting it.... in discussion, I guess? I was thinking to link back here, and also link to prominently your solver when it's ready @IncongruousGoat if you'd like?

Oh... I was wondering how to prove that! My "it's just a buncha things plussed together, shouldn't have local non-global maxima!" seemed a bit hand wavey. For your equation that found the expression that equaled out to constant C for all stages, I'm impressed you found the thing that balances the stages! I'm also happy it didn't have a log . My similar analyses of the n stage equations all hit dead ends at this point with pretty but unsolvable relations, so I'm glad this one worked out. I was starting to give up hope of finding a starting point to launch a heuristic approach, but this would be key. I followed right up to here! I wish I could say more, but I'm impressed with the result. How did you make the constraining equation g = <1,1,1,...>? I tried the old engineers tricks of linearization, and forming systems of seperable PDEs, but it all gets sticky or pretty-but-unsolvable. It's frustrating, because I feel like I keep getting so tantalizingly close. I hope one of your deeper analyses into the specific rocket systems pan out! Anyways, I've hit my head against the analysis enough, I'm thinking I'll try making the google sheet nice enough to post for others to use... Maybe with asparagus stages supported; I have a feeling that the folk who would like a deltaV optimizer are the same as the folk who like them some asparagus! It's all just book-keeping math from here, but would either of you like to join? If so, I'll send the link for the new version.

A continuous number of stages isn't actually such a bad thing- it's pretty much the only difference between the specific-rocket and general-rocket case. The general rocket (where we don't declare a size or anything) doesn't care whether you have .25 of each stage or 1000, so long as the relative number of each stage to the others is known (or a variable). In this way, I think allowing yourself to go ham and declare the number of stages to be continuous is not a bad thing, it should apply nicely to the general case! Unfortunately, like you said, if you don't choose something to constrain the relative number of each stage, the math will just tell you to use your best engine and none of the others. My constraints are stage number ratios that need to be hardbaked into the optimization calculations, but maybe there's a cleaner way?

Good luck, @Ultimate Steve! *nibbles snacks*

Let's try this again. It'll be a lot less polished sadly, because I need to go to bed very soon. Yaay. The nice part about this is it doesn't have any mixed terms! It's not completely separable, but since the effect of each type of stage (each i) appears only in sums, you can make a crazy easy solver which just adjusts 1 variable at a time and works its way to the global optimum (there's no local optima or cross dependencies). We don't need to handle it as 17 simultaneous variables, we can do them one at a go with a bit of itteration. Not nice for analysis, but very nice for computation. We just need to choose a starting x for each, and 1 happens to be a good choice. Ok. It was the big sigma and pi that crashed it. Weird, it handles big delta ok... I'm really looking forward to reading your posts! I kinda feel like a spreadsheet solver is a copout, but at the same time I'm also looking forward to optimizing a lander I've been tinkering with . I'm looking forward to seeing the deeper analytical solutions afoot tomorrow.

@xendelaar Great run! I like the 'jump for joy' the rover gave on launch. I get those sometimes too when there's lots of rotated parts for some reason. All of the longer 'jumps' were when the ground was rapidly dropping away from you on the backsides of bumps and hills. Especially in situations like this (without aero control and like you were saying for TWR>1) the difference between driving and flying is entirely driving style, and you kept it nicely grounded (and dangerous) through the whole run. Any fun crashes?

I made a spreadsheet solver for the general-ship multi-engine case... and it works! Before I forget things (a problem with me) I'm going to post the link/description, the math, and then I'm really looking forward to reading your post on the analytic solution for the specific-rocket multi-engine case, @Abastro and the your constraints for the general-ship multi-engine case, @IncongruousGoat. Link to the spreadsheet solver The idea is to insert your engines and stage requirements, and then insert "1" as a starting guess for stage scale on each stage type. IN a big matrix below, it then shows what the deltaV efficiency would be for a given change to each stage scale, and you just start picking all the best changes, and plugging them back in. A couple iterations, and you're set! Stage scale is ln(masspayload/massfullstage). So far, it's matching values I'd expect from fussing with rockets, but I haven't run it quantitatively by KER yet. ok. Gonna start editing the post. The original link wasn't an editable link. Just updated, so try clicking again if it didn't give access. Oh my gosh, the forums just ate my 3 hour long edit to this post. aggghhh.

@IncongruousGoat Sweet! I've nailed down the base formula for the general multi-engine case, but finding a way to extract optima from it is a whole 'nother story, and I'd be very happy to have your help. I actually did exactly as you had suggested by starting with the specific-craft multi-engine case (fixed size and stage count) and then generalizing to undetermined size. The result was pretty unsurprising! I'll make a better writeup of it to get us on the same page tomorrow, but for now the result worked out to: for a general craft with many stages using engines p or q, we need to specify what portion of stages will use each engine(other wise the math goes slippy-fish and just uses all of one engine or another). If we choose a 50/50 mix, we get: deltaV/ln(craftMassRatio) = -g0 * (1/(p+q)) * ( Ispp*ln(1/9 + 8/9 * (TWRmin/TWRenginep) + 8/9 e^p) + Ispq*ln(1/9 + 8/9 * (TWRmin/TWRengineq) + 8/9 e^q) ) <<<p and q are the e-fold scale of each stage... aka. ln(stageMassRatio), I also use them for subscripts... sorry. Will fix! >>> It's basically exactly the equation from my reply with the two engines grafted together in (to my surprise) the obvious way. I'll need to doublecheck my math and starting principals, but call me 90% sure! It should also extend to further engines following the same pattern. There is an analytical solution to the two engine case.... I wish I still had it, I tossed a version of this equation into wolfram alpha and it spat back a 20 term jungle of gibberish. I made a this face . Hey, I like the engine plot! That's a good way to look at them. I'm not quite following the engine/fueltank ratio, but the optimal engine to tank ratio can be determined by the end-user in the form of a minimum TWR requirement for that stage... I've been calling it TWRmin for lack of a more creative term. Given this (and the engine's TWR) we have the mass of the engine required for the stage, and with it a link to Isp through the rocket equation. MassEngine = MassStage(w/payload)*TWRmin/TWRengine I'm really not sure what next steps are. What end result are you looking to make from this? For me the ideal solution would be a set of plots showing the ideal stageMassRatio for each engine by itself across the TWRs. Then a set of plots showing how far from this deltaV optimum you fall for having a higher/lower stageMassRatio given a handful of different (TWRmin/TWReng), and finally a set of plots showing how these need to be altered to handle multi-engine chicanery. Or, maybe a little webapp would show it all more easily? Hm... Ignoring the Thud is something I'm good at . For now do you have any questions or comments from the stuff I've got up in the topic? It's not the best organized yet, but it should be a good starting point.

HAHAHA! Awesome run, @Tidus Klein- That airplane looks sick with the monster truck wheels and the panther fire rays shooting out the back. I'll get you on the leader board this evening. Best of luck, @Tetragon213 and @xendelaar!

@Abastro I like the plotter you recommended, the grid makes it all much easier to see! Now I'm feeling more confident about the results (huge thanks for checking through them!) I was planning to make a tutorial thread with a big friendly diagram for what all the terms refer to. I'm also planning on writing a solver to make some nice boiled down graphs, which I might send back to the discussion section at some point. I've just started using the results from my google graphs, and it's helped pushed a couple of my designs further than I was able to with just my normal educated guess and check, so the final proof is in the pudding. Thanks for doublechecking the limit mathematically. That ln/ln was giving me trouble (though given there was a 1/x in the top it probably shouldn't have ) @FancyMouse You're absolutely correct that if we consider the engine and fuel tank mass to be fully burnable, we would expect a non-zero limit. I like your idea of making a relative Isp term for comparing cases, I'll have to give it a shot and see if it leads to any new ground. In the meantime, the mass of fuel tanks and engines seems to be driving the limit down to zero eventually, which is very relieving to me. Thanks for the ideas! @Spricigo It's looking like the specific-craft different-engines case is going to require a solver, though I still have some hope of finding a graphical or heuristic solution. While it's easy to make some simple test cases and plots, I'm having a hard time figuring out what assumptions to make and where to even start! The problem is coupled with the case of requiring different TWRs from different stages (same engine), which I was able to solve generally. Unfortunately, the different Isps have been much stickier to deal with. Even so, I've been using the plots and getting good results in my recent craft design, which ranges from ants through skippers. I feel like for engines with equivalent efficiency (the max y value from plot in section 4 : DeltaV/ln(mcraft/mpod) ) the values will lean towards making the engines with the better TWR the somewhat bigger stages... I may totally change my tune on this in 10 minutes though. Asparagus stages (and drop tanks) can be handled by treating the TWRmin as the TWR being provided by the engines on just this stage (or 0 for a tank). Though unless you count in decouplers, the drop tank result will tell you to just use infinite stages! Math is great. I totally want to crack the general multi-engine case though! It's one tough nut. I'm going to mark the problem as solved and keep trucking through the next steps. If anyone gets a yen to do some math and join along, just let me know and I'll put you in the loop. Thanks again! Edit: I'm also not exactly sure how this will relate to the general multi-engine case in the end. I have plenty of equations, but I'm yet to get a good feel for it. Solver's my fallback plan, but I'm still hoping a good heuristic solution will emerge from the depths.

@xendelaar For this particular challenge, we gotta bring the Kerbals back. The trip out is fun, but it's that getting them back part that's the real trick! I didn't know you became a caveman- Congrats! That's a tricky challenge. Come to think of it, you'd probably be able to run some serious caveman missions from your experience in the early parts of your low return runs.. I hope you enjoy the stock playthrough! It's very freeing in a lot of ways, but also very limiting. Maybe.... maybe keep Kerbal alarm clock . Sweet- yeah, give speed running a try and see what you think. My guess is it'll become apparent pretty quick whether the rush happens to make things exciting or just stressful. I'm assuming this will be for after your 10% run, but here's a bite-sized speed running challenge that might be a good barometer: 6 Minutes to Critical. Though are you sure we can't look forward to a 5% returns career mode run? I learned recently that the MPL has an action group for resetting experiments, which gobbles up loads of electricity but can reset science probes with the click of a button. Sounds neat! Too bad scientists can't wave the same magic wand...

Maybe I finally got it? It might all be correct after all, and I was just looking for a decay-to-zero that was way farther out there than I expected. I just realized that if we're plotting efficiency relative to a logarithmic mass ratio, the value actually shouldn't decline very quickly. We should only be able to see the decline on an exponential scale, so I replotted in terms of one, and got something I'd really like to believe! It seems to be working out, but I'd still love a second set of eyes on all this. If the urge to take on some math strikes anyone, some corroboration (or rebuttal) would be hugely appreciated.. Otherwise I'll probably mark it as solved in a few days.

Math is part of the fun! Edit: It's possible I've answered my own question (see the reply) but a second set of eyes would still be super appreciated, if it sound like a fun puzzle to solve through. I feel so close, and yet so far... I was honestly expecting to figure out the problem while rubber-ducking this post together, but alas no such luck. Best of luck on your analysis, and thanks in advance for the help or consolations! Oh, and as a personal request, thanks for poking holes in my equations, but please don't poke a hole you're not willing to fill back in 0. Premise So, we have a lifter that'll get mcraft tons to LKO, and a final unpowered reentry stage weighing mpod tons to finish the trip, and we want to maximize the amount of fun we can have in between. By fun, I mean ΔV with a given TWRmin! We should be able use the rocket equation to find the optimum size of each stage relative to the next (so long as we're using the same engine specs everywhere.) Let's solve for the deltaV of a specific case, and generalize from there. Yeah, that's the craft we're describing! 1. ΔV of a single stage, given masses and TWRs: 2. Extend ΔV from individual stages to a full craft 3. Generalize to a form that's irrespective of craft size ... Results seem mostly good. 4. Plot in terms of more convenient (mfull /mpayload) ... where things are probably definitely wrong So, I hit this road block on Friday and attacked the problem from every angle I could think of over the weekend, rederiving the first 3 sections from different conceptual starting points. I slept on it, mulled over it and triple checked everything, but there's obviously something amiss because the graph in section 4 is obviously wrong in the limit of stages being very large compared to their payloads. Can you figure out the right answer? Best of luck! Terms Future works Finally, I'm flagging friendly neighborhood mod @Vanamonde in case another board would be more appropriate. I think this is the most fitting place, but let's see where we end up!

Nice presentation, @LazySoUseHyperedit! I love the challenge rules/setup, and figured I'd post in a previous mission as an entry to the challenge. It has the additional stipulation of no facilities upgrade and normal career starting cash only. I had been having problems with decelerating the rocket on return from space, so I put a couple basic fins on the reentry stage and turned it into a glider! It was surprisingly stable and fun to fly, and may be able to gather a couple biomes worth of data if reentered in the right place. It gathered 61 science (including world's firsts, vehicle recovery, etc.) and made it loftily to space, but the picture shows 77km, so let's go with that. Points: 138,000! Mission Pics inside By this do you mean no science above the very first node (only use the starting parts), or no science from the nodes that require the tier2 R&D complex? From your pictures I'm assuming the prior? Edit: Just reread the title of challenge, which kinda answered this one

Warning, text wall incoming!! You bring up a good point about continuing to drive up the tech. Finishing the tech tree by hitting those biomes sounds cool, and it's something I always keep on the table when planning a new section, but the problem I always run into is.... what would I do with it? Would the extra tech save enough time to warrant the time spent gathering it (and the 1.5M for the tier 3 R&D facility)? Well, this time around I have a pre-made science gatherer with the new science container on it... Just as a thumb-in-the-wind guess, it would probably take an extra 10-20 minutes to run up the extra science (and particularly funds) to get some tasty tier3 goodies before going to Jool/Eve. So could the tech bring back the time spent getting it? Yeah, 6 hours is pretty breakneck fast. I'm on track to hit it, but by the time I'm through I may be cursing myself for not saying '7' instead! One aspect that I've mentioned, but hasn't really become apparent yet is that mental fatigue plays a huge roll in this final time. It's not unpleasant, just noticeably limiting- I often describe it as being 'cottony'. The last time I did a speedrun, I had to play from 8pm-4am while I was already quite sleep deprived. This time, I'll be better slept, but the run is much more complicated because I'm going glitchless v1.2. I think the two will work out about the same fatigue-wise, taking about 40% longer than possible if I was fresh the whole time. As for stock? That stuff's easy! Go take a check out @ManEatingApe and the rest of the caveman crew for some real diehard KSPers! Silly brashness aside, I've never felt limited by stock KSP. All the abilities and challenges I've wanted from a game, I've been able to find there! I haven't picked up other mods simply because I've never felt the need, with a few exceptions (KER Hyperedit and AeroGui) for fine testing and refinement of craft, and my time programming with KOS which was a wonderful aside. The original reason I made the speedrun challenge 'ideally' mod free was to create a common playing field where people could swap tech and craft without difficulty, but it's never been a big deal for me if folk choose to run with mods set up the way they like it. ... For me though, crashing because you mistimed your suicide burn from interplanetary space is part of the fun As for the level of difficulty, it's certainly different, but there's nothing more difficult to an 8-minute Mun mission than there is in say scouring all Laythe science in one shot on a tight cost budget. It's all just starting with an idea, and incrementally improving it until it shines! Can you action group experiment resetting with a scientist? I tried earlier on, but couldn't get it to work.

I've been working on an airplane platform for delivering @JebFederation's craft to landing sites around Laythe, in prep perhaps for another small land base. Much to my surprise, the plane seems to be working! Now I've got to test it under load, so we'll see how that goes . Also, I have no idea how Jeb federation makes all those rovers! I tried making a little test rover to doublecheck things can drive on wings, but I can't even get it to drive on the tarmac. The wheels just clip through the ground and spin ineffectually. Ironically my test is the part that needs the most testing. Well, the plane will be carrying the real deal soon enough, so trial by fire! My favorite way. We have a mission flag! It's nothing official so no obligation, but @Cratercracker made us a cool flag to hold high as our banner. I may have also enjoyed it enough to crop part for my profile pic Delivering @DoctorDavinci's Can Can 177 is still on the list. I'm looking forward to getting that one up and running. There's still a ton of craft in Laythe orbit that need delivery to their final destinations- comsats, station parts, submarines. I'm thinking about putting a classified in my sig to attract a pilot. Thoughts?

Mission Summary: 40min - 2.3MFunds - 3.7kScience - Flags: Mun, Minmus including crashes, misclicks and all! Let's go! I finally finished polishing the first leg of the speedrun, and boy it's fun to go fast. The music was my system audio at time of recording, which included 'Random Chiptune Mix 30' assembled by Krelez on Youtube. If you enjoy the music, definitely go give it a 'like'! With a few more tries, I could hammer the time down another 5 minutes by avoiding crashes and zipping through Minmus with a bit less hesitation... but to be honest I'm really happy with these segments, slowdowns and all! I'm going to call the route for the first part of the speedrun a success, and march on to one of the next challenges: Eve, Jool, or all the rest. I'm looking forward to doing the hardest one first so with that in mind- From here I'll be rushing straight into the Jool leg of the mission, with a particular eye towards Laythe. I think once I conquer that old demon, I'll be feeling a bit better. My plan is to launch a double craft, have it separate in enroute to Jool, and have one half do Tylo/Bop/Pol while the other does Laythe/Val. We'll see how it goes! There's a lot to learn. Perhaps it's surprising, but as much as I love the epic shots of flags, these pictures are some of my fondest memories of the trip. It's fun to fly fast!

I think this one will go in the 'tub' category. It thoroughly answers the question: "If SRBs are so great, why not use them for everything!" When they unveiled their Intercontinental Ballistic Submarine concept at a trade show a few years back, the folks from Krunk Works got laughed right out of the room! Miffed and flustered, they vowed to build all future submarines secretly inside a featureless building on a remote and unmarked dock. No one has seen or heard a Krunk Works submarine since, and when approached for comment, their president cracked a wry grin and responded "That's the point."

@sevenperforce Thanks! I've got the dry mass for the trip home in the form of extra crew storage. There's room for 17 Kerbals, but we're bringing 12 (maybe 13 so there can be a cameraman in deference to Mars One ) Anyways, one of those hitchiker storage containers is the drymass coming back. As I continue working, I'll find somewhere to put another one for the trip there. Those hitchiker storage units are the spitting image of the hab module in the old mars direct proposal, so I feel obligated to use them over the more convenient options! If it's permitted, the most cost optimal way of transporting Kerbals is by cramming them into chairs in service bays. It's lighter, cheaper, and much more resiliant during reentry. There's really never a reason to do otherwise, except it gets a little old, so I'll stick with my hitchiker cans for now. Still with that trick this mission could be made 1/4 the size (and cost)! Example from an old challenge Thanks for requiring demonstration of reuuse, not reuuse every time! It makes a big difference.