Starman4308

If they're up on GitHub, GitHub archives everything. There may or may not be a nice neat zipped archive, but the source code can still be compiled: you just have to roll back to the last pre-0.25 commit.

Apparently the AMD drivers for Linux are abysmal, which is probably the root of some of your problems. Also, Steam forces KSP to launch with absurd, out-of-date libraries, so you want to launch KSP directly.

In addition, there are structural concerns. A bit thing with FAR is keeping your rocket slim and aerodynamic, which poses a problem, because long, slim rockets also tend to be wobbly rockets. If you clip a bunch of fuel tanks into one, you end up with a rocket with similar aerodynamics, but which is much easier to keep stable.

To clarify: are you talking about deployed solar panels, or retracted solar panels? Deployed solar panels are going to be impossible: there's going to be way more shearing force on reentry than any realistic solar panel arrangement is going to be able to take. Use surface-attached panels like the OX-STATs: nothing else will survive. In terms of retracted solar panels, I'm not sure how much effect you will see out of FAR. I believe FAR simulates a concave shape over any object, so it might not do a good job distinguishing solar panels with aero casings from naked solar panels. Again, I don't know of any mod solar panels which have aero casings.

My current effort is going to be the death of me. I'm in the process of writing a mod which rescales contract payouts for RSS, to have a more sane accounting of delta-V requirements. I've having trouble, though. I think I've figured out how to do something when a new contract is offered, but I can't figure out how to find and modify the contract which was offered. I then thought of adding a dummy parameter to mark rescaled contracts, but that approach is creating duplicate contracts on me*. *I think what is going on is that I modify, say, the Orbit Kerbin contract, KSP no longer recognizes it as the Orbit Kerbin contract and re-offers it, it gets re-scaled, and this repeats each time the contract list changes. Thus: does anybody know how to catch new contracts as they are offered, or a good way to prevent duplication of the scripted contracts after I give them a new parameter?

I think he's asking if there are additional solar panels which have aero casings like the SP-L 1x6 and 2x3 panels. Not that I know of, though shielding solar panels against reentry should be as easy as making sure they're in the shadow of your heat shield: aero forces have nothing to do with Deadly Reentry. So long as they're in the shadow of something else, they're shielded from reentry heat. Aerodynamic disassembly with FAR might be a trickier issue, because the only way to solve that is to either use a 1-time fairing or stick it in a cargo bay. EDIT: Also important to note: as far as I know, the SP-L solar panels don't get special treatment by Deadly Reentry. They've got the exact same maxTemp, and don't have any heat shielding (reflective or ablative).

AFAIK, copy away. On Linux, I've got one heavily modded installation for playing the game, a second near-stock installation so I can test craft for new players, and I'm thinking of splitting off a third one with 95% of the parts deleted for mod development.

I'm not sure what you're trying to ask. Gravity is a force, atmosphere is stuff you have to fly through. Atmospheric drag can be 6x gravity, but it is dependent on how fast you are flying. If that's what you're asking, Eve's atmosphere at sea level is 5x thicker than Kerbin's, which makes things difficult and almost painfully slow. Back to the purpose of the thread, I've used Ants at times. I usually have bigger payloads, but if I just want to get a Stayputnik somewhere, I usually use an Ant engine (helps that RealFuels rebalances it so the O-10 is not completely superior for low-mass probes of delta-V around 3 km/s).

I'm not 100% sure 5m parts are necessary for stock: I can't think of much which would require 5m stacks until you get to either modding or undertaking absurd missions, and parts eat RAM.

You're badly overestimating Eve's gravity. Eve has a surface gravity of 16.7 m/s^2, kerbin is about 9.81 m/s^2, and Tylo is 7.85 m/s^2. As such, an Eve TWR of 2 is about 4 on Tylo.

Oh. Right. That is silly. Maybe Saab wanted tank volumes to be mostly independent of fuel mix, regardless of how unrealistic it may be?

It depends on exactly what you mean by "high/low delta-V" and "high/low Pe". In general, there are two things going on. #1: the Oberth effect favors burns at high velocity, because you can better change your orbital energy at high velocity*. This favors a low Munar periapsis, so you can do your braking burn at a higher Munar orbit velocity. *The Oberth effect comes out of the fact that kinetic energy is proportional to the square of velocity. Thus, braking from 100 to 0 m/s eliminates 5,000 J/kg of kinetic energy (KE = 1/2 m*v^2), while braking from 1100 m/s to 1000 m/s eliminates 105,000 J/kg of kinetic energy. Same expenditure of delta-V, but the second changed your kinetic energy much more. This also works in the reverse direction, and explains why Kerbin escapes are more efficient with low periapsis. #2: you want to spend the absolute minimum amount of dV necessary to get into the Mun's SOI. At periapsis, your orbital velocity will be, at absolute minimum, escape velocity (as your trajectory in is, at best, Munar escape in reverse). The less velocity you have remaining at Munar capture, the less you will have to cancel when you hit periapsis. The conclusion from this is that you want a transfer which just barely puts you in the Mun's SOI long enough for its gravity to pull you in, and gives you a projected periapsis as close to the surface as you dare. The only exception I can think of is if you are planning a Munar flyby only: for that, you want to do a free-return trajectory, which is a different story.

I'm pretty sure that happens with anything: KSP's raycasting for solar panel effectiveness doesn't seem to be terribly effective.

It depends. If you're looking to create parts, you need SketchUp or Blender and Unity. If you're looking to write a plugin which modifies game behavior, you need a C# IDE such as Monodevelop, and add two DLLs from Kerbal Space Program/KSP_Data/Managed, those being Assembly-Csharp.dll and UnityEngine.dll. The first pretty much requires Windows or OS X (because you need Unity), whereas pretty much any decent Linux distribution should have some mechanism to write C# code (technically speaking, an IDE is unnecessary, all you need is a text editor and a compiler, but it helps a lot).

As mentioned, courtesy of buffs to the Rockomax engines, the Kerbal X is now capable of Munar round trips. It's still not a good design for a few reasons, which I'll elaborate on later. In general, it's not very hard. 7.5-8 km/s should be sufficient, and other than that, all you need to do is have a decent launch profile and enough TWR for a Mun landing. This can be achieved rather simply with just two stages, though three can help a bit. I made a 2.5-stage modification to the Kerbal X which squeezes out 700 m/s more delta-V (mostly by replacing the Poodle with an LV-909), costing 11,000 less funds, and massing just 8 tonnes more (including a better solar panel arrangement). As to the Kerbal X, If you're going to use asparagus staging, you don't add six wimpy little tanks and call it a day: you need your asparagus stages to be comparable in size to the central stage, because otherwise you won't benefit from asparagus for very long. For example, the Kerbal X's radial fuel tanks last about 50 seconds, by which time you're just barely about to start your gravity turn. The solar panel placement is sub-par: a whole circle of angles exists for which neither solar panel gets any light. A tetrahedral arrangement is the minimum necessary to get light from any angle onto OX-STAT panels, though it can be difficult to make that look good on most craft (though the Stayputnik core makes it look easy). The outer stages could also use struts to keep them from bending towards the rocket. It's got some excess mass on the first stage. Hydraulic detachment manifolds are meant for particularly large 3.75m stacks, and could easily be replaced with TR-18As. Aerodynamic nose cones, while aesthetic, actually make drag worse in stock, because stock applies drag to every part in proportion to its mass, including nose cones. The FAR and NEAR mods help correct this deficiency, but they do significantly alter gameplay. Six fins could be replaced by three, particularly if you rearrange things a bit and place them a bit further down on the rocket, because fins help you more if they are farther from the center of mass. The Rockomax Poodle is mostly just dead mass: an LV-909 has the same Isp, will give you a Mun TWR of 2.10, and the mass reduction will give you 550 m/s more delta-V.

Well... I abandoned my first Mun lander. And my first Mun rescue mission. And my second Mun rescue mission. The third time was the charm for "not tipping over like an idiot". In my current game, I made a couple one-way probes to the Mun and Minmus, which are still there. Some transfer stages are either in elliptical Kerbin orbits, or in at least one case, in a solar orbit. Had it been short of fuel, my Apollo-style LEM would've been abandoned, but it had plenty of fuel left to crash itself into the Mun after delivering its science and Kerbal back to the CSM.

Hey Arsonide, I figure you're the person to ask, since Fine Print is being integrated into stock. I'm working on a mod to adjust contract payouts to make sense for any RSS config you throw at it. My hope is to allow it to parametrize itself by estimating dV requirements, assuming a certain Isp value (probably 370s for stock), and then multiplying the contract payout by (stock payload fraction / adjusted payload fraction). In order to do this properly, I'm going to need to know what all the possible situations for a contract are. Unfortunately for my purposes, I've never played with Fine Print, and haven't gone farther than Duna in any career game. Ergo, my knowledge of what contract situations there are is limited. Could you fill in any blanks for possible contract situations (both stock and Fine Print)? Also, I'm guessing I should include return trips for orbital stations and surface bases, because I dislike encouraging the stranding of Kerbals. Sun I have no idea if Sun-related contracts exist. Kerbin Landed (why do these exist?) Splashed down Aerial survey, planetary base, rover search (these are going to be a bit tricky) Atmosphere Suborbital Low orbit Molniya, geosync, geostat, tundra orbits Escape trajectory Airless bodies (Mun, Moho, etc) Landed, planetary base, rover search (should be about the same multiplier) Orbit (does this include Molniya orbits, etc?) Suborbital? Flyby (escape trajectory) Atmospheric bodies (Duna, Laythe) Landed, planetary base, rover search, aerial survey, splashed down Atmosphere? Suborbital? Flyby Orbit

Unless you accidentally neglect to account for changes in CoM as your plane loses fuel, and it lawndarts on reentry. That was a √250,000 disaster for me (back when I was trying to build a stock aero SSTO to bring 2 Jumbo-64s of LF/O to orbit).

That is because LH2 is a very low-density fuel, at only 0.07 g/mL, compared to 0.8-1.0 g/mL for RP-1 (kerosene). If you look at the Saturn V, the LH2 tanks were gigantic compared to the LOX tanks. It is still very mass-efficient, but the size of the tanks cuts into that a bit, as you need more mass of fuel tank to carry the same mass of propellant. It's part of why RP-1 (kerosene)/LOX is preferred for most first stages; the much greater density of RP-1 means a smaller volume, which makes for easier engineering, and efficiency does not matter as much for your first stage.

Very much sounds like you've got center of lift/pressure in front of center of mass (screenshots would help). If you haven't seen it before, I strongly recommend reading this guide to spaceplane design.

No, don't worry, I think it'll be an interesting poll, and Sal's on hand to edit the categories. I think you just underestimated certain players' determination to make sure that, when they launch KSP, what they're playing has only a vague resemblance to the stock game. I'll admit: I'm working on something which might be incorporated into RP-0, the Realism Overhaul career mode, which will very much not be like the stock career.

Theoretically, payload fraction = e^(dV/g*Isp). In practice, you won't be able to get that much useful payload up, because some of that payload capacity gets swallowed up by stuff like staging equipment, aerodynamic control surfaces, command pods/drone cores, RCS, structural elements, etc. Also, the amount of delta-V to get to orbit is variable based on how well you handle the ascent: as a rough guideline, it takes 4400-4500 m/s to get to low Kerbin orbit if you don't mess up your ascent. Good ascents in stock feature a straight vertical ascent followed by a gravity turn. For the vertical ascent, the most efficient speed to go is terminal velocity*: go faster, you lose fuel burning against atmospheric drag, go slower, you lose fuel burning against gravity drag. A stock gravity turn is to gently tip over eastwards at ~6-12 km until you are straight horizontal. *Terminal velocity is how fast you would fall. There's a chart on the Wiki, else MechJeb and probably Kerbal Engineer tell you what terminal velocity is for your craft. As such, you want to design for a TWR of 1.6-2.0: while you need slightly > 2.0 TWR to hit terminal velocity, you burn fuel as you go up (increasing TWR), and engines are dead mass for the rocket equation. The theory behind this is simple. Barring atmosphere (and lithosphere), the most efficient way to get to orbit would be to point dead east (in the direction of Kerbin's rotation), with just enough vertical pitch to keep yourself from hitting the ground, and just burn until you're in orbit. Horizontal thrust good, vertical thrust bad but necessary. However, Kerbin also has a thick souposphere which eats velocity: you need to go up to escape it, and gradually start turning over eastwards as you get to thinner and thinner atmosphere. EDIT: Rainstorm, the rocket equation (dV = g * Isp * ln(start mass/end mass)) is the simple equation, although as mentioned, delta-V is not the entire story. EDIT #2: The simple way to get to orbit is to have a launch TWR in the aforementioned range (1.6-2.0), about 5 km/s of delta-V (for safety), and tip over 45 degrees at 10 km, holding that until apoapsis is 80-100 km; you then wait until apoapsis, and burn prograde until you're circularized.

You... could have stood to make some broader ranges, like 20-50, 50-100, 100+, etc. FAR, DRE, Real Fuels, RF Stockalike config, Near Future Solar, RSS, 6.4x RSS config, AVP, EVE, Trajectories, Mechjeb, Docking Port Aligner, MRS, SpaceY, KW Rocketry, RPM, Kalculator, KAS, Kerbal Flight Data, KJR, Mission Controller Extended, NRAP, RealChute, Pfairings, Oblivion Aerospace heatshields, Procedural Parts, Sane Strategies, ScanSat, TAC Fuel Balancer, TAC Life Support, Tweakable Everything, KAC, Transfer Window Planner, Yarbrough's 2-man pod, SelectRoot, Adjustable Landing Gear, and three more I rarely use (Radial engine mounts, Zero-Point fairings, Chatterer). You can then add 4 of Claw's stock bug fixes and the Firespitter DLL. I think that's around 36-ish, and I have zips for other mods hanging around as well.

I can't find those .file files, though I suspect they may be simply extensionless on Linux. In any event: if it's plain text, literally every text editor ever (I prefer Notepad++ for most things, VI for other things) will open it, and if it's binary, I'm pretty sure a hex editor can let you look at it, though it won't really be readable for humans in most situations.

So that must be why I keep on getting "test Basic Jet Engine on Minmus" contracts. The Kerbals at C7 Aerospace are all playing KSP with infinite fuel turned on.