MathigNihilcehk

Well, I've finished a first attempt of this... 1 hour 24 minutes, 55 seconds. I could upload it to YouTube, but I'm definitely not proud of that time :P... I had to re-do the mun landing a seven times and the kerbin landing twice. I mean, my potential 85 minute record isn't that awesome, but consider that if I got the landings on the first try I'd be closer to 34 minutes. I guess I could try bigger rocket + bigger lander, for stability... The longest part is the pin-point accuracy return. I suppose if you did it right, you could figure out where/when to burn on the mun to go directly to KSC. The best I've found is if you circularize to 100km then you can methodically land close to KSC. However, this means you can't "just" leave mun and land straight on Kerbin. You have to leave mun with enough dV to re-orbit Kerbin. My current rocket has around 3200-3500 dV in atmosphere, 3100 to get to and land on the Mun and 2625 to take off, orbit kerbin, and land.

That IS the hardest part. With something like Mech-jeb it's easy. Otherwise... not so much. Even if you have enough dV to do something like that, precision aiming is a pain, especially if you have to do it in a short period of time. Can I use quicksaves? If so, it'd make the challenge a tad easier, maybe.

There are a number of problems with this challenge. 1: Various computer load times heavily effect your game speed. 2: You didn't attempt your own challenge. 3: There is nothing spectacularly new or innovative about this style of speedrun. 4: etc.? Some improvements you could make to it include. 1: Finding a way to factor out the computational power. For example, you could allow people to compile their in-game time and time-acceleration factors to adjust for time-dilation. (divide the run into segments every time you switch time acceleration factors. For simplicity you must round each segment to the nearest 10th of a second of your footage. Take the in-game time of each segment and divide it by the acceleration factor. You now have a time that is independent of your computer slowing down the computations.). Another option is to cut any loading screen time from the total time (although NOT from the footage). 2: Attempt the challenge. 3: 1) would provide some innovation to the run. Another idea is to do this in career mode. That would be a lot more interesting, because you would have to get enough science/contracts to go to the moon and do so in a short period of time. Although you would probably want to outlaw the booster glitch, if it still works (stacking boosters head-tail without decouplers). 4: Also... just make it stock only. Do it! Otherwise, you'll find people who somehow find an advantage to having some mod or another. IE part mods. Even if you don't use the parts, you can install a part mod that repositions the parts to make it easier to build your spaceship. In all honesty, no one would care if you told them they can't have their precious texture mod for a speed run... this is a speed run, you are an idiot for asking for a texture mod that will make your game run SLOWER. If it makes your game run faster, then you are giving yourself an unfair advantage. No you can't get rid of bugs, because that essentially changes the game. It's critical to have a fair playing field, if you're going to have this.

I was thinking of issuing a similar challenge, after I finish editing videos, for Mars Permanent Outpost... RSS style. I mean, the cool thing about that challenge, is if you could complete it, then theoretically someone could ACTUALLY set up a permanent base on mars for the same price... excluding the billion assumptions made that say all your mods === real life.

Dangit. I am disappointed in myself. I over-designed way too much, the ship catastrophically failed at launch, and I still managed to get to moon the OK. I failed when I forgot how to land on the moon. Second time around I launched perfectly, landed on the moon perfectly, and returned home saftely all in one trip, but... damn, haven't been to the moon in forever. I bet you I could, however, complete the challenge to Duna in one attempt.

How does designing a rocket with basic delta V and thrust calculations not fit into the theme of the challenge? This is Rocket Science. In real life, you don't run simulations, (well you might run a couple to double check everything) you run calculations. You run worst-case-scenario calculations, and you make it viable even then. In Kerbal Space Program, through time, you get good at running those calculations in your head. Sure, you might not know if you are stocking 1600 dv or 1700 dv, but you know roughly what fuel and engines can accomplish what, with time. That is the same thing as actually doing the calculations, except you are doing them on paper, as opposed to in your head. If anything, I might say utilizing notepad, a piece of paper, or a calculator to assist in those calculations is against the rules. Try ACTUALLY RUNNING dv calculations in your head. The ONLY tricky part, is the natural logarithm. I think I'll try this challenge, after some review on how to do logarithms without a calculator. It's really not that hard. Just have to memorize a couple of numbers... that's all.

Finally, I've posted the first video discussing my plan. If you prefer text, I've included it here. The video is . I'll post some of the execution videos once I finish post-commentary and editing. It shouldn't take nearly as long as the opening video, as I won't edit as much. Enjoy!Overview: This is my entry to the challenge. Included is a theoretical, and practical analysis of the challenge, a detailed design description of each component, a detailed mission outline for each mission, and a detailed report of the execution of each mission. I will also attempt to create a YouTube series that animates this to some degree. Goals: 1: Be unique. We choose to go to duna and to do the other things not because they are easy, but because they are hard. 2: Achieve everything. While I may not invent any new achievements, I seek to score all existing achievements. 3: Be practical. One of the achievments is execution. A theoretically perfect design includes no structural support, excess fuel, and demands superhuman piloting. I can't execute that. 4: Be realistic. I will bend some rules, and create harder rules to my entry, because some rules lead to unrealistic play. 5: Be optimal. Everything else held equal, I want my challenge to get the most points it can. If that means cutting things close, then so be it. Theoretical Analysis: To achieve the maximum number of points, you want to send the most kerbals to duna in the shortest time period possible. This depends on how many kerbals you can send and support in each launch window. The most effective way to do this, is to launch an infinitely large rocket, with an infinite number of kerbals and food storages in the first launch. This will yield an infinite number of points. Unfortunately, this rocket can not be constructed in finite time. Since all launches must be equal, you can send the product of your launch size, and the number of launches into orbit. The number of launches you have depends on the time between launches, which depends on your launch size. In our scenario, we have up to day 739 to send mass to duna. We also have a bonus launch at day 10. So, this gives us a total number of launchers of Round down((739-10)/1.5*payload mass)+1, or Round down(486/payload mass)+1. The total mass sent to duna, is then payload mass*Round down(486/payload mass)+payload mass. The round down function is maximized for a serious of steps, where 486 mod payload mass = 0. For these steps, the equation simplifies to 486+payload mass. For each step, there is also a distinct number of launches equal to (486/payload mass)+1. Thus, the lower the number, of launches, the higher your total payload to duna, which means the higher your total point score. For practical reasons, I am going to pick 7 launches. This gives us a maximum payload mass of 69.429. Now, the mass we can get to duna is less than this maximum payload. The change in velocity required to get to duna is at least 860dV. This is assuming that you create an intercept with mun, and gravity assist all the way to duna, and aerobrake in duna's atmosphere into a perfect landing. The best engine to use is the LV-N "Nerv" Atomic Rocket Motor, which has a mass of 3, and a specific impulse of 800 s. Additionally you are getting mass to duna in stages, assuming you use the launch windows. I'd call that a safe assumption, since otherwise you use more mass, and may get there in more time. The first stage gets one launch (50-10), the second two (55+228-10-104*2), the third two (55+228*2-10-104*4), the fourth two (55+228*3-10-104*6). Using the rocket equation, this means we can get 860=9.81*800*ln(full mass/(full mass - fuel)). For the first case, this is 860=9.81*800*ln(69.429/(69.429 - fuel)) or 860=9.81*800*ln(69.429/(69.429 - fuel)), or a fuel mass of 7.206. This will take 8.75 mass for the fuel tanks, for a total mass to duna, less engine and fuel, of 57.679. For the other cases, this is 860=9.81*800*ln(69.429*2/(69.429*2 - fuel)) 14.41 or 16.25 using fuel tanks, thus we have a to duna mass of 119.608. We also need mass for food. Each kerbal will spend 960 days in transit. Using the most space efficient food and realistic food, this is FL-R1 RCS Fuel Tank at 220.6 food per mass. If we wanted the most space efficient food, it'd be PB-X150 Xenon Container at 5833.4 food per mass. In my opinion 100 grams is not a full day's worth of food. 400 grams, on the other hand, is reasonable, assuming you recycle 100% of your water. Anyways, assuming we utilize the 40 days of food in our rover and housing we get 4.17 mass per kerbal, for food. We also need long term housing. The cheapest option, is for kerbals to live in a pair of EAS-1 External Command Seats, which duplicate as their rover. However, for realism sake, I'll pick something else. How about a pair of MK1 Lander Cans? MK3 Passenger Module? MK2 Crew Cabin? All would work, but I feel like all of those options would be kind of unrealistic. A more realistic option is the PPD-10 Hitchhiker Storage Container. It's roomy, spacious, and linked. It's quite large, and so I can EASILY see a couple of kerbals living years in one. However, this means it will require 1.25 mass per kerbal. For the kerbals to get home, let's assume they are just lifting their storage container into orbit and then to ike. This is a dv of 1690, and using 24-77 "twitch" liquid fuel engines(what I am actually using). This gives us 1690=9.81*290*ln(2.5+fuel/(2.5)) or 2.475 with fuel cans considered. This gives us a grand total of 6.68 mass per kerbal, not including a lot of stuff. So, in the first trip we can get 8 kerbals, to duna, and during each subsequent trip, we can get 16, assuming we don't spread the food out. This gives us a theoretical score of 832*8+717*16+489*16+261*16+33*16 or 30,656. Practical Analysis Next up, the explanation for how NeilC gets larger than this score... he manufactured fuel on site. Basically, if you do that, you get to drop the food cost entirely, and you get 275% more kerbals per trip. This actually means that had NeilC found a way to do his mission with a 0 mass mining operation, and more improbably assumptions made in this calculation, he could've scored 84304 points. Obviously, at some point we have to stop making wild assumptions like "If you could somehow get to duna by intercepting mun and using a gravity assist, it'll only cost 860 dV", because I am not building my entire program based on my capability of performing a perfect gravity assist off of Mun. Not even going to try for a gravity assist in the first place. I'm pretty sure if I tried, I'd end up spending more dV than I would've just going straight to duna. Anyway, the process of actually designing a ship is, well, a process. Start with the theoretical max, include all the components, then ask yourself "Am I missing something to actually launch this into space", like an engine, or a some way to connect the blob of parts I just stacked other than stacking them, or docking ports, or even a light. Instead of going through the whole process, I'll show the results. I've created three modular ship types. The first I call the Food Supplier. It consists of RCS cans to store 1870 food, nd a few RCS engines(with RCS fuel) to land. It's total mass is 9.7. The second I call the Inhabitor. It has a hitchhiker housing unit, 360 units of fuel, and a bit of food. The third I call rover. It has seating for four kerbals, and four scientific tools. All three ship types include power generation, parachutes, wheels, and docking ports (except the rover). These parts come together to make a primary payload and a secondary payload. The primary payload consist of two rovers, four inhabitors, and a food supplier, along with a pair of nuclear engines, liquid fuel, food, docking ports, and structural parts. The secondary payload consists of four food suppliers, excess fuel for the return trip, docking ports, and structural parts. Each tops out at just under 69.42 mass. The launch schedule is as follows. Launch and transfer schedule Day 10: Launch Window(Base) Day 55: Duna Transfer Window Day 114: Launch Window(Suppliers) Day 119: Duna arrival Day 218: Launch Window(Base) Day 283: Duna Transfer Window(3 Food) Day 322: Launch Window(Base) Day 347: Duna arrival Day 426: Launch Window(Base) Day 511: Duna Transfer Window(1 Food) Day 530: Launch Window(Suppliers) Day 575: Duna arrival Day 634: Launch Window(Base) Day 739: Launch Window(Base) Day 739: Duna Transfer Window(1 Food) Day 803: Duna arrival Day 843: Launch Window(Suppliers) Day 947: Launch Window(Suppliers) Day 951: Kerbin Transfer Window Day 967: Duna Transfer Window(5 food) Day 1015: Kerbin arrival Day 1031: Duna arrival Day 1051: Launch Window(Suppliers) Day 1155: Launch Window(Suppliers)

Several weeks, 55 hours of recording, and 181 Gigabytes later, and I've FINALLY finished recording my attempt at the challenge. I've compeleted everything by the rules, with the possible exception of flame effects. Considering how the new game rules seem far harsher, in regards to displaying flame effects, AND since the new rules will actually destroy your craft, if you suffer too much re-entry heat, I'm going to kind of ignore the "absolutely no flame effects" rule. Theoretically, if I had done a gravity assist off mun to get to duna, I'd have had enough extra fuel to deorbit burn myself, instead of letting the atmosphere do it for me. I don't mind losing points on the execution, if we assume I completely failed (didn't try) the gravity assist, and therefore the plan is good, but my execution doesn't count. If I were doing the points, I'd consider this a different version of KSP, deserving slightly different rules. Since the game can destroy your craft quite easily, if it doesn't actually burn up in the atmosphere, it didn't burn up in the atmosphere. That's up to the OP, though, not me. Heck, if the OP doesn't count my attempt at all, I probably won't care. I'm happy with my attempt, at least. Oh, and the Kerbals might have to ration their food a bit. Probably not, and definitely not according to my proposal, but perhaps on the actual mission. The dates given for duna transfer burns didn't exactly work for me. I'll have to double check the timing, though. It'll be a few more weeks for me to take a look at editing this footage into... I don't know, something. I'm thinking of cutting this into one succesful continuous video, and highlights of various failed attempts. Perhaps 5x-10x speed, correcting for time dilation, with overlayed commentary... Bah, I'm no entertainer. I'll think of something, though. The straight-up recording was so boring, that even I didn't watch it, while recording it. Anyway, just saying that I will enter my attempt eventually... probably. It won't top the leader-boards, but it's on the order of 10,000 points, and there is a good reason I didn't have room for "heatshields".

Well, I've finally started the challenge, after months of breaks... Yesterday I did about 10% of the execution... I actually got nauseous and had to stop playing. Where did that happen, might you ask? While piloting the darned rover, I built. I forgot to include an SAS module, so landing it was a pain, and I ended up 100km+ away from the landing site. I had saves to reload, but that would've meant landing again. It was incredibly light weight, but also incredibly likely to flip over on the slightest bump on the road. I tried going 10m/s, but it'd flip over within 1km. Eventually I tried going 3m/s, and it seems to work fine... but by then I was too sick to keep playing. I ended up turning on MechJeb's auto-pilot (which likes to flip over too) for 3m/s on 4x time acceleration and I left the room. Unfortunately for me, I don't have just one rover to do, but 10. Note to anyone attempting this challenge. ADD SAS TO YOUR ROVERS!

It is true that any craft outside the physics bubble, and inside a planets lower atmosphere disappear due to magic. I don't think you need to perform all flights to complete the challenge. In fact, I think you only need to do one of each to show that your architecture is plausible or something. You get bonus points for flying everything. If you don't want to risk lots of explosions, I'd recommend Mech-Jeb. Some times it can help you land exactly where you wanted, within 80 m. Warning, at other times it will fly your craft into deep space, because it "feels" like it, and it will often waste fuel spinning 360's because magic. Seriously, it can run an entire mission perfectly and then it'll suddenly decide "for this ONE landing, you fail. Time to use all your fuel 500 m above ground so we can descend at 0.1 m/s.".

*I had forgotten about you... *I thought you had forgotten about me... *You may have thought me crazy, arrogant, or lazy... *Back then you were right... *You are still correct today... *But now after all this time... My name is on the front page under incomplete?!? (My fault for that ) *Soon... *Or perhaps never, but probably soon... *I will return... *And I will finish... Duna Permanent Outpost Mission Architecture Challenge (This is just some early prototypes of my first payload with launcher. Once I finish testing the components, I'll get started on the report. I just wanted to say "Hi, I'm back, and working on the challenge again, for now.") Test Results: The Alpha module shown failed horribly. After some adjusting, all alpha testing is completed. All that remains is to find a good recording software that works with my computer, and attempt the challenge itself. I'm still debating doing video or pictures... I'm anticipating a very long challenge, either way. Some 12 launches of 350 parts each, 20 minute burn times, and 70 separate landings. Only 4 landings, 3 docking maneuvers, and 2 launches are unique, but I'd hate to not go all the way, after all this time.

Regarding the Genetic Algorithm paper(I'll have to read more into it, in the future, it is quite interesting), I've learned that it basically takes a number of random valid inputs, and then breeds them together and checks the offspring for better or worse engine design. It takes the best sets and continually breeds them until one solution is found. However, this solution is not guaranteed to be the global maximum or minimum as stated in the paper "However, finding this global optimum is not guaranteed." page 11, paragraph 2. IE: some rocket components could be lost for reasons completely unrelated to their value (ie, the rocket they were in failed as a whole). This is avoided if a large enough sample size is used, but the larger the sample size, the more generations will need to be checked, and computational time is exponentially related to sample size. As the second paper explains, the optimization is partly random, as in page 9 paragraph 2 "This is a result of the randomness inherent in a heuristic optimization algorithm, and suggests that more computation is necessary to give confidence with the results." While this may lead to an optimization function that generates good rockets that qualify our constraints in a short period of time, it may either miss better rockets, or eat up more computational time than desired. In contrast, my method takes more of a thorough approach and scans every rocket within a range of valid rockets. A finite range can be picked to include the most optimal rocket, and thus the best rocket can be found given enough time.

Still having trouble figuring out what you are doing... So, you generate a matrix that will look like [table=width: 500, class: grid] [tr] [td]m(dV,P)_x_1y_1z_1[/td] [td]x_1[/td] [td]y_1[/td] [td]z_1[/td] [/tr] [tr] [td]m(dV,P)_x_2y_2z_2[/td] [td]x_2[/td] [td]y_2[/td] [td]z_2[/td] [/tr] [tr] [td]m(dV,P)_x_iy_iz_i[/td] [td]x_i[/td] [td]y_i[/td] [td]z_i[/td] [/tr] [/table] Then you search for the minimum mass given a certain P and dV and display the appropriate x, y, and z? On another note entirely, I found a way to optimize my guesses. I just plug in my limit condition into a for-loop to scan for valid guesses, then immediately test the dv and TWR followed by comparing with the optimal set and resorting it, if needed. And... since someone replied fairly quickly, I'll set up a working model in Matlab, before transporting to C# (I'm thinking Unity for GUI would work best, unless anyone has a better idea). After-all, who can say what the best model is, until the model is put to the test.

LOL... with those two lines you summarized your entire attempt at the solution. Care to elaborate a bit?

Thrust plates are methods for stability, not for increasing thrust or change in velocity. This system would include any combination of allowed engines and tanks, but it would not handle large numbers of allowed engines easily.