Pand5461

@eloquentJane OK. I'm not stock elitist, just "you need to install mods to be on top of stock scoreboard" looked as a glaring hole in the rules. Also, maybe reduce life support bonuses for Mun missions? Kerbalism adds 5 days worth of food, water and oxygen to pods, the whole "go there, plant flag, get back" mission takes 2 days tops. Added weight is maybe 100-200 kg, not something that requires total vehicle redesign. Electricity is a concern but only with solar panels, and all you need is just time the launch properly. That said, I think 1 bonus point for 10 days of mission is somewhat fair.

@Andiron First thought: RAPIERS??? Next thought: ah right, four nozzles...

I don't like the idea of life support mods being counted as stock and adding extra points for them. I would argue that some mods like life support, RemoteTech, FAR, Deadly Reentry, kOS, kRPC can be accepted as "stock" but without any extra points. Or give said extra points if submitted as a modded entry.

А, ну это можно.

Great name! Care to add some explosions to this picture? That's my imagination of a 'normal' Kerbal flight.

@Kerbal101 смотря что под этим подразумевается. И у меня небольшие проблемы с игрой на русском языке - почти физически больно видеть остатки английских фраз в переводах, поэтому играю только на английском.

Ok, but that is not the point. That is exactly the point. MechJeb is very good as it is and, more importantly, very flexible. Trying to make it handle complex missions from start to finish will restrict vehicle designs or mission profiles possible. I've already said about gravity assists already but there are other things. Let's say you want to get to Jool orbit. How do you capture? Will this be assist from Tylo? Laythe? Aerobraking? Good old retroburn? The transfer maneuver plotted and executed. What to do next: timewarp to destination or leave controls to the player? Player wanted 100 km orbit at target planet, and after departure burn the periapsis was exactly 100 km. After entering solar SOI and timewarping a bit it's 500 km. When do we correct - in the solar SOI or in the target SOI? Being a fan of Unix way, I'd say that providing basic tools and letting users build complexity themselves is better than trying to make a silver bullet.

True. But consider an Apollo-style mission. How is a generic autopilot supposed to know you need to redock on the TLI trajectory, ditch the stage and use spacecraft propulsion to capture in the Moon orbit? Interplanetary trips are even more complicated. There may be multiple gravity assists on the way, or you may want to depart at one of the nodes and wait several revolutions around the Sun before encounter, or you want to launch to an intercept trajectory rather that Hohmann because you have some dV to spare and want to just get there faster... Bootom line is, writing generic autopilots is hard. The reason some of them are available for free may be that completing such a task is a reward by itself. But there is a limit to what a program can do without the need to read player's mind. Yes it can, if we speak of eliminating the need for manual input on launch. And no it can't, if we speak about the delay between activating the stage an SRB is in and actually lighting said SRB.

I also learned the hard way that using solar panels for kermanned Mun landings with life support mods installed requires more planning than usual. Choose wrong lighting conditions, and you're caught in Kerbin's shadow near the apoapsis of an elliptical trajectory (either on the way there or back). As you run out of electricity, life support stops, kerbals are dead.

That would be my ultimate answer to all "we need better autopilot mods" whines but almost no one ever actually considers it, alas. What I absolutely love about kOS it that it encourages you to learn the "rocket science". Because "I want to fly like Scott Manley but don't want to learn the maths 'cos it's just a game"... Well, that people might as well try making an omelette without breaking eggs. OK, I'm starting to insult people at this point... I perfectly understand if the OP is tired of the same "Get to orbit - Plot a transfer - Execute maneuver - Do midcourse corrections - Do the capture burn - Land" routine and would like to automate it but that's making an omelette without breaking eggs again. You need to invest either your time (either coding that autopilot or convincing someone else to do it) or money (supporting a person who would code this).

Could you please clarify this: Clearly, Surveyors and Lunar Orbiters had solar panels. Are they banned for manned craft only? And I wish we had non-tracking extensible panels but there's none of the kind in stock. So, the choice is limited to OX-STAT and OX-STAT-XL, right?

@Hotaru I think there is no CrewCapacity field in plain tanks, so my idea is that your patch (which excludes anything with ModuleCommand) includes ModuleBreakableFuelTank for regular tanks, and my patch adds it to probe cores only. And actually there are things like hitchhiker's containers that have no ModuleCommand but have CrewCapacity and can have resources. Being no MM expert, I'm suggesting anyone concerned to deal with it

@Hotaru is it possible to make any tank with non-zero-density resource breakable through MM patch? And maybe add this to your last patch to allow tank failures on unmanned control parts @PART[*]:HAS[@RESOURCE[MonoPropellant],!MODULE[ModuleBreakableFuelTank],@MODULE[ModuleCommand],#CrewCapacity[0]]:FOR[BARIS] { MODULE { name = ModuleBreakableFuelTank } }

I did not make myself absolutely clear with "given that you can restart engines" thing. The extreme example I had in mind is the engine that can switch between "full steam ahead" and "stop thrusting" infinitely fast, which gives it, in essence, any TWR needed. So (surprise!) the rocket which always has the most optimal TWR is the most optimal. This is not even remotely realistic, of course. And I don't think TWR of 5-10 on solid motors will be much better than 2. The reason for not improving after TWR=2 is, I guess, because this is just shifting maxQ region closer to ground and prolonging its duration. The Goddard's problem solution for vertical ascent is that most fuel-efficient way to get straight up is to keep drag force equal to gravity. In case of constant-density atmosphere, this transforms to "get to the velocity when drag=gravity as soon as possible, then keep TWR=2", therefore that magic number.

Challenge accepted! To clarify: 1. Do this have to be dedicated kOS parts and -1 point for each or adding kOSProcessor module to capsules via MM patch is OK? 2. Does LK-style landing (block D makes most of the braking, lander engines kill the last 100-200 m/s, lander then uses the same engine for the ascent) count as 2-stage?

Actually, there is also something here that KSP does not model properly. Higher TWR is always more efficient (given that you can restart engines, so you can include coasting phases between burns) in terms of delta-V for a given rocket design. But there is a huge BUT here: for a given rocket design. Rocket structure must withstand engine thrust, so increasing TWR means you need a stronger rocket, fairings, payload adapter and payload itself, meaning you need to include more "dead" weight. And you will need heavier engines of course and a way to ensure they can restart in flight. So a weaker but lighter rocket might actually deliver a heavier payload, despite losing more delta-V on gravity.

USSR. @DAL59 May I launch from Baikerbanur? Shore KSC just does not seem right.

What about removing that one for both teams then? Really, you make the person who submits it miss all the fun.

Can team USSR skip it?

This is what I meant by 2/3rd power. I was thinking in terms of mass, so drag force scales as mass2/3 if two rockets are perfectly similar. Acceleration scales as force / mass = mass2/3 / mass = mass-1/3. What I also wanted to say is that it's probably even worse than mass-1/3 in reality because most of sounding rockets have large (compared to their diameter) stabilization fins space rockets typically lack. In your example, Sounding / Saturn deceleration ratio is probably even greater than 16. However, I sincerely doubt that those 1000 m/s overwhelm reduced gravity losses with high-g launch.

@Shpaget said probably the main reason. Sounding rockets often have a few gees right from the launchpad, so they reach high speeds low above ground. Also note that sounding rockets don't always have gimbaled motors (more often than not they have just simple solid rocket motors), so they need relatively large aerodynamic surfaces to maintain stability and those increase drag even more than 2/3rd power law.

May be a slight violation of But reminds me of Hayabusa probe and ground crew that managed finding a way to make a working ion engine from two broken ones on a probe flying Kraken knows where that was not designed to repair itself. THIS FEATURE IS A-W-E-S-O-M-E! (maybe lacks a 50% chance of insta-kill instead of repair for true Kerbal experience but even Jeb doesn't seem to complain about that).

У меня работает. Или вопрос про вставку альбомов?

I'd recommend moving KSPI and NF folders somewhere outside your GameData folder and then adding them one by one until you locate which one is causing trouble. You will need a fresh save for testing of course, don't try to resume an existing one without mods it was started with, or it is likely to break.

Interstellar + NF pack, maybe?