Aeroboi

Too? You mean instead... To me personally the only engines of best choice are Aerospike, Vector, Mainsail, Twin boar and Mammoth. The mastodon is ridiculously overpriced and then the amount of Thrust and it's horrendous ISP. I know you can make nice working mastodon type EAV's but they're a lot bulkier, heavier and more costly. Totally agree! That's kind of the shorter answer I gave Xurkitree above. Does the density layer change across many versions and has been done in the past? I have tested this and I always thought it was 12.5 km? I can't recall which version, I believe 1.3.1

I never understood why the altimeter digits went into the red when altitude became negative. Can we have that with a navball toggle so we can see amount of meters above seabed also? I always wanted to know how low to the ground I were. While it completely depends on how 'good' you build your sub mine can be slow and cumbersome so I want to see the seabed coming before it met me. Such seabed altitude level readings are good for science and giggles anyway. This is not a hijack but I just wanted to add this to it. When submarine parts do come we need ballast tanks. Not sure how they'd work in KSP but we need one. On another note, we don't need a impeller but what is a sloop *cough* ship without a impeller. Now imagine everyone tweaking the impeller so it can be used as aircraft propellers

Aren't all chemical rocket engines in KSP Liquid fuel and oxidizer? Anyway, we have the Rapier, it uses LF or LFO. Or isn't that then considered hybrid because LF is treated as a single fuel? This may be peoples opinions but there are ISP variances among chemical engines that propose the only answer which is that LF as a placeholder term for anything really. You name it, Bill Pumps it. You can also create a stock Hybrid propulsion system by having any engine of your choice and then use a landing leg or decoupler spring to eject solid propellant mass using any parts of your choosing, I'll choose Kerbal Sounds almost like pokemon...

What ^they've^ said, luckily there are these BIG-S thingies that do 2400K.

Tip 1: Launch from Moho to Kerbin or Eve, but do it only when Moho is at it's Pe around the Sun. The reason being is that you use the Oberth effect around the sun when doing your ejection burn at LMO. This shaves off some Dv requirement when doing the final ejection burn. Tip 2: It's recommended before by ZL647. To further explain this. Try to leave Moho when it's plane intersects the ascending/descending node of Eve's or Kerbin's. When targeting your destination (Kerbin) it will visualize the An or Dn in map view. (you probably already knew this, just saying) The plane change is the biggest Dv waste when coming from Moho. Even if Eve is not at the proper location I can park in a 1:3 or 1:2 Eve-Moho resonant orbit until Kerbin or Eve catches up to the desired spot and then do a burn at Pe around the Sun to get to Eve/Kerbin. Tip 3: I take it you only want to bring the Kerbals back to Kerbin? So a small Mk 1 or Mk 1 lander can per each pilot should suffice? Have you thought about electric propulsion yet? (Dawn electric motor) I know this puts people off due to their long low TWR and consequently longer burn times, and then a Moho ejection burn, am I nuts? ... If one or two dawn engines have to push one or two lander cans the vessels peak TWR can be quite reasonable. For reference a single Dawn can orbit a small lander can from the Munar surface so it's doable for a Moho ejection burn at 4x timewarp. You may not like the slow electric dawn motor because many of you don't but it will seriously take the complexity from a entire vessel when used for transferring Kerbals from Moho back to Kerbin.

I couldn't agree more. I really want to make a shout out to @linuxgurugamer for the effort in maintaining a collection of mods that is as numerous as all the honeycombs in a beehive. That they guy hasn't died yet from a mental, neurological or physiological breakdown caused by the effort to maintain these mods. I'm not even talking real life here. Honestly @linuxgurugamer I think I can conclude you like it much otherwise you wouldn't do it. I also think it's your domain and you really don't want to exchange that work. Sorry for making assumptions, maybe none of that is actually true. But something makes you do this on your own and even if hypothetically you would say today that you would never leave this work there are these stories of people that had their change of mind that packed their stuff with even friends and family that were kept in the dark about said persons new whereabouts. I hope your not like that I hope you already made a temporary appointment with someone else willing to take over your work in the unlikely event that there's gonna come a day where this might happen.

You don't understand me correctly. While I should have mentioned it I consider "part updates" and "Aerodynamics properties" as a way to change aerodynamics. Why does Squad do this by changing a part aerodynamic properties without a clear reason? That would only be clear if the part itself changed in it's shape. A 1.25m circular decoupler remains a 1.25m circular decoupler, it's aerodynamics shouldn't change, so why is that then? When I say I don't want aerodynamic changes then it is based on realism ironically. Realism in my view is that aerodynamics don't change. Something doesn't become more dynamic through gas or fluid or becomes lighter without changing it's shape. But, I agree lol. I said I'm not happy about these "constant" changes to aerodynamics. And again, that means part aerodynamic parameter updates also. In a complete overhaul it will be a real aerodynamic update. When it changes all the bits you summarized and does it good like a typical flight sim does I will rejoice. Changing aerodynamics on a 1.25m gasket ring (= decoupler) is nonsensical to me and it fuels my my comment to stop all these minor and frequent changes to aerodynamics whether that is directly or via a part configuration on i.e. a decoupler.

I'm gonna test this. I'm not sure how profoundly I'm gonna do this but if it turns out to be profound I'll post the findings. I did a lot of aerodynamic testing already in 1.5.1 for a project I'm working on so I already have things to use. Furthermore I'm not very happy about these constant changes to aerodynamics. One universal sheet of physics laws across all the upcoming versions of KSP from now on. @SQUAD Because, why not?

Just snatch one from the Internet, Elon won't sue you

That doesn't happen. Posts will wander for ever to face the test of time so intriguing curious players can still read the questions and answers of others like in this case. Bending or the loose joints can also be benefited from by making springs for suspension or stock made cords. I used the spring effect lately to create a stage activated engine pivot for thrust realignment. The only reason I begin about it is that these wonky physics are beneficial for creative out of the box ideas so I hope this will always remain.

Why not introduce some in game vote based time acceleration thingy. The way it works is that every player starts in 1x timerate *duh* Whenever someone joins 1x timerate is resumed for obvious reasons. Now imagine 2 modes, the first one being suggested by Rocketinmypocket earlier in this thread to complement physical timewarp. Everyone will select their preferred physical time acceleration. Now, if you have it at (4x) and everybody else has selected no time acceleration then it won't be activated. If all the others have (2x) and you the only one having (4x) the game will run at (2x), you get the picture. With on rails timewarp there can be a in game voting mechanism. If people want to timewarp they can use "timewarp to here, soi change, node" If other people would want to do on rails time acceleration they have to activate a timewarp destination themselves. Everyone in the session will have to vote "yes" if there is more then one person in the session that has selected a timewarp destination. When everyone does anyone in that session will timewarp at the fastest setting until anybody arriving soonest at the timewarp destination will have everybody halt when that person (a) decides to by selecting to do this with the intention do change orbit or decelerate and (b) there is another satellite on a possible intersect course at the destinations SOI. If neither is the case the whole party will continue to timewarp. Anyone within that session will have to have it's game halted to do maneuvering and the game will have to be re-voted for time acceleration each time this happens. Using Teamspeak and a Chatbox anyone can take extra effort in being able to join in with random people and so that there is always a method of communication to delegate anyone willing to process through time acceleration. Since this game is played by sensible people where session moderators are *again* sensible people I assume such a system is managed adequately. A few notes on this. Don't be turned away on this one. Out of time acceleration you can still perform stuff in the SPH and VAB. Isn't that where 95% of all the action takes place? So if 20 people are in line to do time acceleration 18 of them are actively playing, at least, in the VAB and SPH and perhaps near the surface on a planet. At other times things can be cozy, after several session votes and herding a whole party to Moho it is cooperative sun bathing 4EVA. What's there to not agree about, tell me?

@The_8_Bit_Zombie Yes, it has this when parental control is activated in your Windows settings.

A few pointers from me about overheating which I tested extensively. The Mk1 cockpits can all be protected against this to some degree by using wings on it. You can attach something like a main wing to the Mk1 cockpit and then move it to a desired spot on the spaceplane. This way you can have the attachment points of all wing pieces on the most heat intolerant part like a Mk 1 cockpit. Wings are basically radiators It also works when not directly attached but better when you do. To easily move parts far away from there parent part I use the Editor extensions redux mod by linuxgurugamer. This is a mod I can't play without, even stock Also, if you place a small heatshield without ablator vertically on top of a stack you can extend the heat resistance of the part below it like a nosecone for instance. Sometimes by many hundred degrees... The overheat ceiling also is determined by the other parts like type of nosecone or if there is more then one end cap protecting the Mk 1 cockpit or any other heat intolerant part that is the first within the stack. Heat tends to bleed through so having multiple parts protecting a cockpit can help also. Usually nothing so drastic is required, but maybe people can use this. You can test by reading active part temperatures to see where there is heat bleeding using the Thermal UI interface within the debug menu. Heat bleeding would be a part behind another part (in the cross section of the front part "nosecone") that still gets most of the heat effect. Sometimes a critical temp of let's say 2.000K is achieved at a higher speed then in another case. Using a better thermal nosecone or other part there in between often means that part is able to stay cooler and less heat will bleed through. Sometimes placing the Mk 1 cockpit aft instead of fwt on the fuselage allows it to go a lot faster because the bow shock of the other parts at the front lessen the heat load on parts that are less heat resistant. Max temperature is also reached based on the orientation of a part against the plasma stream. I'm not sure how it works in KSP at all or what's the story with Mk 1 but since the glass canopy is supposedly less heat resistant I would expect it melts under negative pitch.

Doing it at all is hard. I wish I'd already seen more submissions or W.I.P. and I have a gut feeling we haven't seen more because people are held back by the launch cost optimization goal of this challenge. Getting it low cost from launch is just endlessly creating stages, reducing drag, trying out new engine combos and improve ascent profiles. It's not even fun to test that much, but the fun in explosions and eventually getting somewhere through effort is glorifying. If I hadn't had that attitude I wouldn't have made jack gooey. IMO I think a best "cost" submission should be a category. I think low cost is a intriguing goal for me personally so I try to reduce it as much I can. While it's hard and perhaps not for you partial reusability is possible and ultimately full reusability also. It has been done a few times already. I hope there's a place for people that devise these type of missions. I also hope this thread is going to be a showcase on many different design choices from which I can learn. Unfortunately it is not the most popular challenge yet, maybe it's because of Eve, I hope that changes. I had the same. I haven't tested enough to be 100% sure but it might be due to the Hyperedit mod. You use it? Anyway, it seems to be only graphical. You can still get a gilly encounter if you know it's actual location.

I remember this. I exploited it often during career so I wouldn't need anything like a Mun transfer ship in LMO to get back to Kerbin. Just use my jetpack from LMO to get back to Kerbin and this would end up with lower cost rockets of the launchpad. I did was a bit more nooby back in the day because when I think back that I used it to make Mun missions cheaper I feel rather embarassed. Because seriously, who makes Mun missions actively cheaper these days?

When I played KSP for the first time I remember looking at the clock when it was 5 AM, I had to go to work and forgot to have dinner the evening before. I also ended up with rockets that had 6 times the required size but that is noobishism.

No! The gains are ultimately to little for the effort required to make it. And the gains are only noticeable if you balance the spring on the engines very precisely which is very finicky and not worth any design. But it does work an I'm happy I made it. I still look for ways to perfect it. I assume that the mentality for challenging people to do this is to find ways how to cash in on that particular contracts as much as possible. Or is it me assuming that such a mentality is for everyone? I think all options should be on the table to achieve that. Also remember that a pod, fuel tanks and engines are supposed to get into LEO regardless. I think it is better then to have fuel tanks as a rendezvous then another return ship when you want to reduce cost. You already brought engines into Eve orbit so why would you want other engines and another pod to sit in? I'm not going to post the mission as I still have to fly it but you'll see that I jettison my top assembly into smaller segments when reaching LEO to later dock into a small return vessel around gilly. The actual rendezvous vessel in LEO is pure fuel tanks and some verniers for maneuvering. Ok, I expected this and of course it's OP. I ho hope you understand it doesn't deliver. I tried to make it as aerodynamic as possible by creating a design that has 4 fuel tank stacks plus a center core. The less individual stacks the better the aerodynamics. Improving on reducing the amount of stacks can have the same aerodynamic benefit as changing a adapter for a nosecone at every attachment node. To make it compact was by using a lot of slanted tanks so the outer tanks move outward so they don't hit the center stack when decoupling. These slanted tanks are less aerodynamic, but a fifth or sixth stack is draggier anyway. These and other things decide the looks of it. The fuel tanks hanging on the underside is what is left in LEO as rendezvous to get the ore to gilly and the kerbalnauts back to Kerbin. The amount is considerable indeed and uses asparagus. I personally wouldn't use the LV-N for this at all. A LV-N costs 10.000 funds. 4 x LV-N = 40.000 Funds. It's much cheaper to use terriers or poodles with only a few extra fuel tanks.

I don't know about the greatest experienced. I do think that having debris of 10.000 will noticeably slow down your save. Having a faster computer will run saves with larger amount of vessels better and I think having anywhere close to 10.000 vessels will be a slideshow. I expect anyone boasting the hightest number of vessels in a single savegame also has a lot of game slow downs. I think people stop playing their game when the amount of used vessels becomes that big as it will become to difficult to organize.

I've done a lot of testing on this because this mission is so very intriguing. I concluded that there is no best type of EAV (Eve Ascent Vessel). There is the option of creating a single stage rocket that can get to minmus from Kerbin to refuel there as suggested by Laie. However, these rockets are the low twr/high Dv type EAV's because only such types have the sufficient dry/mass ratio to come with the required Dv to do this. I tried building many types but ultimately builded most of my favorite type of EAV's which are high TWR and streamlined rockets. These are the type I normally create and have a eve SLT of 1.8 and much more dead engine mass off of the launch pad compared to other designs like any of yours. These type of rockets can never get to Minmus in one go. The only theoretical way for them to do so is use a mission specific LV-N. But then you require 10k, 20k or even 30-40.000 extra funds. So making it all single stage isn't ultimately a deciding factor in making the mission more cheap. It turns out that a rocket that does not have the required Dv to get to Minmus turns out to be just as expensive when it uses drop tanks. Scenario 1:I made a very complex, high part count vessel that costed just over 400.000 Funds and could get to Minmus from Kerbin. Scenario 2:I also made a less complex vessel with higher TWR and less Dv and could get to Minmus using drop tanks from the KSC also for just over 400.000 Funds. Fact: If you care for the cheapest Eve vessel you don't care about playing inconveniences like endless aerobraking. Right? I needed some heatshielding as I didn't had all the Dv to do propulsive aerobraking only. I could be SSTO and have more fuel tanks and more Dv and not use a heatshield system at all. But is that cheaper then? A inflatable heatshield is only Funds 1.500,00 a piece. What's ultimately cheaper, more fuel/funds for more dv or more funds for braking system? Furthermore, there are some points of criticism about the challenge as it stands. The TS @Laie has a problem with the Wolfhound engine like many of us do as it is OP. I tried the Wolfhound anyway because I tried testing all aspects of this mission. I concluded that nothing is OP about the Wolfhound on a Eve rocket. The flight conditions where the Wolfhound becomes useful on Eve is at altitudes above 30Km. And that is when it has just more ISP then i.e. a Skiff. That means that you would design your Eve vessel to have a functionally used Wolfhound at 40Km altitude. From there on it is ~2.000 <> 3.000 Dv into LEO. A Wolfhound has a advantage from that point on in the flight plan and eventually gives more Dv but only a little. It's the last stage so the profit you'd be expecting is ultimately marginal. The Wolfhound itself is a lot heavier then any other engine and you still require a few of them to have enough thrust for the final push into orbit on the final stage. The way I tested it the Skiff comes out on top because it has the lowest mass per unit of thrust while having excellent vac ISP of 330. Also, because the Atm ISP of the Skiff is 265 it can be used at lower altitudes of ~10Km on Eve. This way you can use Skiff engines as late stage vac engines that can already be fired at lower altitudes for which you would otherwise require other engines for. The way I see it the Wolfhound is optional and used under specific circumstances can have a design specific performance perk. This perk is indistinguishable from any other engine combination or legal stock peripheral that would be considered allowed. So the Wolfhound should be a optional engine. Allow reusability? I also think that reusability can be a thing to drastically lower the cost. I envision a EVE two stage to orbit so that a larger more complex final stage can be salvaged one which you would have thrown away otherwise. The argument that a single stage to Minmus vessel is cheaper is correct. But a SSTO bringing the EAV to LKO can be just as cheap. Cheaper perhaps since a lower Dv EAV is often less complicated and cheaper on its own so that a SSTO carrying still has less fuel/engine cost. Bring the EAV to LKO with a SSTO will also consume less time. Landing on Minmus and refuelling is more time consuming I think then de-orbiting a mission specific cargo SSTO with which you launched your Eve rocket. So far I created a rocket that costs just under 500.000 Funds and checks all the mission rules/objectives. It's a rocket that uses drop tanks off of Kerbin to have enough Dv in LKO to reach Minmus or a near Kerbin asteroid. It uses a combination of Aero and propulsive braking. The module on the right near the bottom engines is jettisoned at Eve which is a tug for the ore to Gilly and refueler to get to Kerbin. It decouples around Minmus so the rocket can refuel and then recouples around Minmus before going to Eve.

The 7540m mountain is near the equator. I wondered there's a even lower one that is not around the equator?

I'm all for MOAR 1.875m parts. And I agree, the typical SRB of the Titan 3-E would blend in well with the rest. As for 1.875m parts in general. If a new form factor of parts is added into the game I think it's collection should be complete. That means it should consist out of all the part variety options 1.25m, 2.5m and 3.75m has. Currently that is not the case and there are mods that cover this and I will use them anyday. I just think if squad starts on something it should be released as a complete package.

I have on some installs. But this vessel is for a stock challenge so no KJR. Excellent idea. I feel more comfortable just changing the craft file for this. I'm not always ..... careful Still, a mod for this would be even better.

It's all varieties of autostrut and "root part" autostrut also which is the problem of course. Didn't thought of it since I haven't ran into the issue since "ever" and understood it would only happen when docking as opposed to undocking. The craft works fine with heaviest and grandparent autostrut Unfortunately however there are quite a few parts autostrutted to root as the docked vessels are part of a large multistage rocket. Many of these parts are better strutted towards heaviest and unfortunately root. I need this for the method I use to bring these stages along on the main lifter. Is there a mod with which you can auto autostrut all parts or have some of them autostrutted with a action group? If not I have to individually re strut all the root strutted parts. It would be annoying.

I have this test vessel in orbit around Eve. Launching it, reloading it the consequences are the same. Whenever I decouple this vessel weird stuff happens. First notice the black edges on the fuel tank adapters. And another thing, the camera is shaking, as in vibrating for no apparent reason. For some reason the ore tank broke off seen in the lower right corner And sometimes the graphical glitch covers the entire vessel with black tints and stripes. I've forgotten to screenshot the event but during one instance Gilly seemed to accelerate out of the solar system but only graphically, I could still get a encounter. The kraken also seemed to auto decouple all the individual parts off of my ship. It wasn't explosive, all the parts just let loose from their joints. It was pathetic to look at. Remember, the camera is shaking, virbrating or perhaps better interpreted as jittering. I really want to test out this ship. What do you guys make of this one? Should I rebuild it? Any known editor applications that are known to trigger this behavior? Thanks